Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

From: <[email-masked]>
Date: Mon, 13 Nov 2017 16:38:14 +0000

Hi WG,

I'm facing an interop issue between two PCEP implementations.
PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 in the SRP Object.
PCC from vendor2 handles it correctly and delegates the LSP to the PCE using PST=1.
When the PCE sends a PCUpdate message, it does not set the PST TLV in the SRP Object.
The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads the PCUpdate as having PST type=0.

Based on my reading of draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing.
PST draft tells that for the PCE Initiation case, the PCE MAY include the PST if the message does not ave any other means of indicating the path setup type. SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV". Unfortunately it does not specify explicitly in which message. From a reading perspective, we can understand from "In order to setup" that it applies to the PCInitiate message. But nothing tells about the PCUpdate message.
However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that: "if the path setup type cannot be unambiguously inferred from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages."
In our case (PCE initiated) as the LSP has initially been setup through a PCInitiate message having the PST TLV, the PCC can infer that futher updates will use EROs associated with the same PST.

Or do we allow to change the PST through PCUpdate messages which may require to  always set the PST ? (moving from RSVP-TE to SR or the other way for a particular LSP)

I would like to hear opinions of the WG on that problem ?

Thanks,

Brgds,

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>  NEW !
mobile: +33 6 71 63 27 50 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>  NEW !
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 15 Nov 2017 01:28:10 +0000

I think it should be acceptable for the PCUpd not to include the PATH-SETUP-TYPE, with the implication that there is no change to the path type.

Although I'm not convinced it would be a good idea operationally, I don't think there's any need to prevent the path type changing on the PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base draft, should allow that flexibility.  A given device may choose not to allow that, of course.

Does that sound reasonable?
Cheers
Jon

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 November 2017 00:38
To: [email-masked]
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi WG,

Thanks,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

---

From: <[email-masked]>
Date: Wed, 15 Nov 2017 05:52:20 +0000

Hi Jon,

Thanks for your feedback.
I see two possibilities here.

1)      When the PATH-SETUP-TYPE is not present in a PCUpd, it should be inferred from the latest one received (in a PCInitiate or in a PCUpd). When initiating an LSP, the PCInitiate contains the PST to let the PCC know about the path type. Then, it can be omitted in further PCUpd except when the PCE wants to change the path type. At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value and then it does not need to include it in further updates until the PCE needs to change it again.

2)      We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd.

IMO, solution 2) is easier for implementations and operation.

Brgd,

Stephane

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 14 November 2017 00:38
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi WG,

Thanks,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 15 Nov 2017 07:56:52 +0000

I read this in draft-ietf-pce-lsp-setup-type:

> The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-SETUP-TYPE TLV with an PST value of 0.

What it doesn't say, but I think it means to say, is "... unless there is some other way to infer the path setup type from the message."  So, if we follow my suggestion below, we would have to make it explicit that the path setup type for a PCUpd can be inferred from the current path setup type of the LSP (unless it is given explicitly), which is a change to draft-ietf-pce-lsp-setup-type.

Does anyone else have an opinion on this?

Thanks
Jon

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 15 November 2017 09:28
To: [email-masked]; [email-masked]
Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi WG,

Thanks,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

---

From: Hesham ElBakoury <[email-masked]>
Date: Wed, 15 Nov 2017 15:31:23 +0000

Dear Colleagues

IEEE ComSoc is having a special issue on current and coming disruptive technologies including Blockchain, Intents and  related technology. The details of the CFP is
in IEEE Comsoc website: http://www.comsoc.org/comstandardsmag/cfp/standards-major-internet-disruptors-blockchain-intents-and-related-paradigms

I do invite you to submit a paper detailing your current research or deployments in these exciting areas.

Please note the following important dates:

  *   Manuscript Submission: January 15, 2018
  *   Decision Notification: May 1 2018
  *   Final Manuscripts Due: June 15, 2018
  *   Feature Topic Publication Date: September 2018
Please do not hesitate to contact me if you have any questions.

Sincerely yours

Hesham ([email-masked]<mailto:[email-masked]>

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 16 Nov 2017 03:50:48 +0000

Hi Stephane

OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE is not present in a message, then it unambiguously means that the path setup type is RSVP-TE.  Then implementations don't have to try to infer the path setup type from other objects or previous messages.

I am revising draft-ietf-pce-lsp-setup-type at the moment to address an earlier comment from Julien, so I will include this clarification in the next revision.

Thanks for the input!
Cheers
Jon

From: [email-masked] [mailto:[email-masked]]
Sent: 15 November 2017 13:52
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi Jon,

  1.  When the PATH-SETUP-TYPE is not present in a PCUpd, it should be inferred from the latest one received (in a PCInitiate or in a PCUpd). When initiating an LSP, the PCInitiate contains the PST to let the PCC know about the path type. Then, it can be omitted in further PCUpd except when the PCE wants to change the path type. At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value and then it does not need to include it in further updates until the PCE needs to change it again.
  2.  We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd.

Brgd,

Stephane

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi WG,

Thanks,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 05:25:58 +0000

Thanks Jon.

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 11:51
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi Stephane

Thanks for the input!
Cheers
Jon

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 15 November 2017 13:52
To: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi Jon,

Brgd,

Stephane

Hi WG,

Thanks,

Brgds,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Nov 2017 13:36:01 +0800

+1

Thanks Jon!

On Thu, Nov 16, 2017 at 1:25 PM, <[email-masked]> wrote:

> Thanks Jon.
>
>
>
> *From:* Jonathan Hardwick [mailto:[email-masked]]
> *Sent:* Thursday, November 16, 2017 11:51
>
> *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked]
> *Subject:* RE: Clarifications on PST handling in
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>
>
> Hi Stephane
>
>
>
> OK, let’s go with solution (2).  That is, if the PATH-SETUP-TYPE is not
> present in a message, then it unambiguously means that the path setup type
> is RSVP-TE.  Then implementations don’t have to try to infer the path setup
> type from other objects or previous messages.
>
>
>
> I am revising draft-ietf-pce-lsp-setup-type at the moment to address an
> earlier comment from Julien, so I will include this clarification in the
> next revision.
>
>
>
> Thanks for the input!
>
> Cheers
>
> Jon
>
>
>
>
>
> *From:* [email-masked] [mailto:stephane.litkowski@
> orange.com <[email-masked]>]
> *Sent:* 15 November 2017 13:52
> *To:* Jonathan Hardwick <[email-masked]>; [email-masked]
> *Subject:* RE: Clarifications on PST handling in
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>
>
> Hi Jon,
>
>
>
>    1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be
>    inferred from the latest one received (in a PCInitiate or in a PCUpd). When
>    initiating an LSP, the PCInitiate contains the PST to let the PCC know
>    about the path type. Then, it can be omitted in further PCUpd except when
>    the PCE wants to change the path type. At that time, it sends a PCUpd with
>    a new PATH-SETUP-TYPE value and then it does not need to include it in
>    further updates until the PCE needs to change it again.
> *From:* Jonathan Hardwick [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, November 15, 2017 09:28
> *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked]
> *Subject:* RE: Clarifications on PST handling in
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>
>
> I think it should be acceptable for the PCUpd not to include the
> PATH-SETUP-TYPE, with the implication that there is no change to the path
> type.
>
>
>
> Although I’m not convinced it would be a good idea operationally, I don’t
> think there’s any need to prevent the path type changing on the PCUpd, if
> an explicit PATH-SETUP-TYPE is given.  That is,
> draft-ietf-pce-lsp-setup-type, as a base draft, should allow that
> flexibility.  A given device may choose not to allow that, of course.
>
>
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* 14 November 2017 00:38
> *To:* [email-masked]
> *Subject:* [Pce] Clarifications on PST handling in
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>
>
> Hi WG,
>
>
>
> I’m facing an interop issue between two PCEP implementations.
>
> PST draft tells that for the PCE Initiation case, the PCE MAY include the
> PST if the message does not ave any other means of indicating the path
> setup type. SR draft tells “In order to setup an SR-TE LSP using SR, RP or
> SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately it does not
> specify explicitly in which message. From a reading perspective, we can
> understand from “In order to setup” that it applies to the PCInitiate
> message. But nothing tells about the PCUpdate message.
>
> However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case
> that: “if the path setup type cannot be unambiguously inferred from ERO or
> any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd
> messages.”
>
> In our case (PCE initiated) as the LSP has initially been setup through a
> PCInitiate message having the PST TLV, the PCC can infer that futher
> updates will use EROs associated with the same PST.
>
>
>
> Or do we allow to change the PST through PCUpdate messages which may
> require to  always set the PST ? (moving from RSVP-TE to SR or the other
> way for a particular LSP)
>
>
>
>  <http://www.orange.com/>
> *Stephane Litkowski *
> phone: +33 2 23 *06* 49 83
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
>  NEW !
> mobile: +33 6 71 63 27 50
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
>  NEW !
> [email-masked]
>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Julien Meuric <[email-masked]>
Date: Thu, 16 Nov 2017 10:27:44 +0100

Hi,

Glad to see we are converging. To make sure we are on the same page
(solution (2) referring to a shortcut), the conclusion is that, as soon
as PST is not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq,
PCRep, PCUpd, PCRpt and PCInitiate: is that right?

This leads me to another question. Over a PCEP session supporting
multiple types, we do not have a mean to send a PCReq leaving the type
selection to the PCE (no TLV implying type 0). Do we consider a mean to
support that? (Could be 0xFF or a flag from the "Reserved" field.)

Thanks,

Julien

Nov. 16, 2017 - [email-masked]:
>
> Hi Stephane
>
>  
>
> OK, let’s go with solution (2).  That is, if the PATH-SETUP-TYPE is
> not present in a message, then it unambiguously means that the path
> setup type is RSVP-TE.  Then implementations don’t have to try to
> infer the path setup type from other objects or previous messages.
>
>  
>
> I am revising draft-ietf-pce-lsp-setup-type at the moment to address
> an earlier comment from Julien, so I will include this clarification
> in the next revision.
>
>  
>
> Thanks for the input!
>
> Cheers
>
> Jon
>
>  
>
>  
>
> *From:[email-masked]
> [mailto:[email-masked]]
>     inferred from the latest one received (in a PCInitiate or in a
>     PCUpd). When initiating an LSP, the PCInitiate contains the PST to
>     let the PCC know about the path type. Then, it can be omitted in
>     further PCUpd except when the PCE wants to change the path type.
>     At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value
>     and then it does not need to include it in further updates until
>     the PCE needs to change it again.
> *From:*Jonathan Hardwick [mailto:[email-masked]]
> *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked] <mailto:[email-masked]>
> PATH-SETUP-TYPE, with the implication that there is no change to the
> path type.
>
>  
>
> Although I’m not convinced it would be a good idea operationally, I
> don’t think there’s any need to prevent the path type changing on the
> PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is,
> *From:*Pce [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *To:* [email-masked] <mailto:[email-masked]>
> PST draft tells that for the PCE Initiation case, the PCE MAY include
> the PST if the message does not ave any other means of indicating the
> path setup type. SR draft tells “In order to setup an SR-TE LSP using
> SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV”. Unfortunately
> it does not specify explicitly in which message. From a reading
> perspective, we can understand from “In order to setup” that it
> applies to the PCInitiate message. But nothing tells about the
> PCUpdate message.
>
> that: “if the path setup type cannot be unambiguously inferred from
> ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in
> PCRpt and PCUpd messages.”
>
> In our case (PCE initiated) as the LSP has initially been setup
> through a PCInitiate message having the PST TLV, the PCC can infer
> that futher updates will use EROs associated with the same PST.
>
>  
>
> require to  always set the PST ? (moving from RSVP-TE to SR or the
> other way for a particular LSP)
>
>  
>
> Orange logo <http://www.orange.com/>
>
>  
>
> *Stephane Litkowski *
> Network Architect
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> NEW !
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> NEW !
> [email-masked] <mailto:[email-masked]>
>
>  
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 10:21:00 +0000

Hi Julien,

> Over a PCEP session supporting multiple types, we do not have a mean to send a PCReq leaving the type selection to the PCE (no TLV implying type 0).

I do not see the use case here.
 In addition, I'm not sure that the PCE always know what are the setup types actively supported by the PCC. As a consequence it may pick one which is not supported and the LSP setup will fail. For SR, the PCE may know it through the SR cap, but for RSVP, can the PCE deduce it from another information ?

Brgds,

-----Original Message-----
From: Julien Meuric [mailto:[email-masked]] 
Sent: Thursday, November 16, 2017 17:28
To: Jonathan Hardwick; LITKOWSKI Stephane OBS/OINIS
Cc: [email-masked]
Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi,

Glad to see we are converging. To make sure we are on the same page (solution (2) referring to a shortcut), the conclusion is that, as soon as PST is not 0 (i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt and PCInitiate: is that right?

This leads me to another question. Over a PCEP session supporting multiple types, we do not have a mean to send a PCReq leaving the type selection to the PCE (no TLV implying type 0). Do we consider a mean to support that? (Could be 0xFF or a flag from the "Reserved" field.)

Thanks,

Julien

Nov. 16, 2017 - [email-masked]:
>
> Hi Stephane
>
>  
>
> OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE is 
> setup type is RSVP-TE.  Then implementations don't have to try to 
> Although I'm not convinced it would be a good idea operationally, I 
> don't think there's any need to prevent the path type changing on the 
> path setup type. SR draft tells "In order to setup an SR-TE LSP using 
> SR, RP or SRP object MUST include PATH-SETUP-TYPE TLV". Unfortunately 
> perspective, we can understand from "In order to setup" that it 
> that: "if the path setup type cannot be unambiguously inferred from 
> PCRpt and PCUpd messages."
>
> ______________________________________________________________________
> ___________________________________________________
>  
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
>  
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> ______________________________________________________________________
> ___________________________________________________
>  
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
>  
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 16 Nov 2017 11:18:51 +0000

Hi Julien, see [Jon]s below...

-----Original Message-----
From: Julien Meuric [mailto:[email-masked]] 
Sent: 16 November 2017 17:28
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi,

[Jon] Yes.

[Jon] It could be done, but do we need it?  This could be added later without penalty.

Thanks,

Julien

---

From: Julien Meuric <[email-masked]>
Date: Thu, 16 Nov 2017 15:34:53 +0100

Hi Stéphane,

Of course, that type of request would only make sense when the PCE knows
about supported types. Static configuration could allow that, but the
update that Jon is going to include in the I-D allows the PCE to be
aware of the supported capabilities by the PCC.

Anyway, I am fine with leaving that open for the future. I just want to
make sure that we have consensus on the exact scope of the document
before we freeze it.

Thanks for the feedback,

Julien

---

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 16 Nov 2017 21:18:00 +0000

Jon,
While I do not have an issue with enforcing the PST TLV be included in the below message types, we still need to answer Stephane's last question in his original email. That is whether the PST is allowed to change during the lifetime of the LSP. I am hoping the answer is no meaning that once a LSP with a PLSP-ID is established, a subsequent PCUpd message with a PST type that does not match the type in the original message which created that PLSP-ID (PCReq or PCInitiate) should result in the PCC returning a PCErr message with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = 2 (Mismatched path setup type).

If that is the understanding of this group, we should explicitly document it in draft-ietf-pce-lsp-setup-type.

Mustapha.

> Sent: Thursday, November 16, 2017 6:19 AM
> To: Julien Meuric <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Glad to see we are converging. To make sure we are on the same page (solution
> (2) referring to a shortcut), the conclusion is that, as soon as PST is not 0 (i.e.
> RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt and
> PCInitiate: is that right?
> 
> [Jon] Yes.
> 
> This leads me to another question. Over a PCEP session supporting multiple
> types, we do not have a mean to send a PCReq leaving the type selection to the
> PCE (no TLV implying type 0). Do we consider a mean to support that? (Could be
> 0xFF or a flag from the "Reserved" field.)
> 
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.s
> so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root
> service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> NE
> W !
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.s
> so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26root
> service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> NE
> W !

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Nov 2017 22:32:06 +0000

Hi Mustapha, 

Jon said this in his earlier mail - 

> Although I'm not convinced it would be a good idea operationally, 
> I don't think there's any need to prevent the path type changing 
> on the PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, 

And I agree with that. In case of message which is in a "response" such as PCRep, PCRpt it MUST have the same PST. 
But PCUpd and PCInitiate are different and keeping a door open for allowing the change of PST could allow better migration from RSVP-TE to SR for existing tunnels. 

How about we update the text in the draft to explicitly say that this is about PCC's local policy and PCC MAY send an error in case the local policy doesn't allow changing of PST? 

Thanks! 
Dhruv 

PS. And for what's it's worth, I agree with leaving the selection of PST for a future extension.

> From: Pce [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha
> (Nokia - CA/Ottawa)
> Sent: 17 November 2017 05:18
> To: Jonathan Hardwick <[email-masked]>; Julien Meuric
> <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-
> setup-type & draft-ietf-pce-segment-routing
> 
> Jon,
> While I do not have an issue with enforcing the PST TLV be included in the
> below message types, we still need to answer Stephane's last question in
> his original email. That is whether the PST is allowed to change during
> the lifetime of the LSP. I am hoping the answer is no meaning that once a
> LSP with a PLSP-ID is established, a subsequent PCUpd message with a PST
> type that does not match the type in the original message which created
> that PLSP-ID (PCReq or PCInitiate) should result in the PCC returning a
> PCErr message with Error-Type = 21 (Traffic engineering path setup error)
> and Error-Value = 2 (Mismatched path setup type).
> 
> > Subject: Re: [Pce] Clarifications on PST handling in
> > Subject: Re: [Pce] Clarifications on PST handling in
> > (solution
> > selection to the PCE (no TLV implying type 0). Do we consider a mean
> > to support that? (Could be 0xFF or a flag from the "Reserved" field.)
> >
> > > <mailto:[email-masked]>
> > > don't think there's any need to prevent the path type changing on
> > > the PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is,
> > > PST draft tells that for the PCE Initiation case, the PCE MAY
> > > include the PST if the message does not ave any other means of
> > > indicating the path setup type. SR draft tells "In order to setup an
> > > SR-TE LSP using SR, RP or SRP object MUST include PATH-SETUP-TYPE
> > > TLV". Unfortunately it does not specify explicitly in which message.
> > > From a reading perspective, we can understand from "In order to
> > > setup" that it applies to the PCInitiate message. But nothing tells
> > > about the PCUpdate message.
> > >
> > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro
> > ot service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> NE W !
> > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26ro
> > ot service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> NE W !
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > > ce message par erreur, veuillez le signaler a l'expediteur et le
> > > detruire ainsi que les pieces jointes. Les messages electroniques
> > > etant susceptibles d'alteration, Orange decline toute responsabilite
> > > si ce message a ete altere, deforme ou falsifie. Merci.
> > >
> > > If you have received this email in error, please notify the sender
> > > and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that
> > > have been modified, changed or falsified.
> > > Thank you.
> > >
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > > ce message par erreur, veuillez le signaler a l'expediteur et le
> > > detruire ainsi que les pieces jointes. Les messages electroniques
> > > etant susceptibles d'alteration, Orange decline toute responsabilite
> > > si ce message a ete altere, deforme ou falsifie. Merci.
> > >
> > > If you have received this email in error, please notify the sender
> > > and delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that
> > > have been modified, changed or falsified.
> > > Thank you.
> > >
> > >

---

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 16 Nov 2017 22:47:21 +0000

Thanks Dhruv.

I am fine with making sure we have the proper PCErr message listed in case a PCC rejects such a change. However, it seems to me that we should describe the procedures for a PCC which honors it.

I am not sure that I understand how it helps migration. It seems too complicated for its own sake.

Mustapha.

> From: Dhruv Dhody [mailto:[email-masked]]
> Sent: Thursday, November 16, 2017 5:32 PM
> To: Aissaoui, Mustapha (Nokia - CA/Ottawa) <[email-masked]>;
> Jonathan Hardwick <[email-masked]>; Julien Meuric
> Cc: [email-masked]; 'Dhruv Dhody' <[email-masked]>
> Subject: RE: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type &
> draft-ietf-pce-segment-routing
> 
> Hi Mustapha,
> 
> But PCUpd and PCInitiate are different and keeping a door open for allowing the
> change of PST could allow better migration from RSVP-TE to SR for existing
> tunnels.
> 
> How about we update the text in the draft to explicitly say that this is about PCC's
> local policy and PCC MAY send an error in case the local policy doesn't allow
> changing of PST?
> 
> Thanks!
> Dhruv
> 
> > From: Pce [mailto:[email-masked]] On Behalf Of Aissaoui,
> > Mustapha (Nokia - CA/Ottawa)
> > To: Jonathan Hardwick <[email-masked]>; Julien
> > Meuric <[email-masked]>; [email-masked]
> > Cc: [email-masked]
> > draft-ietf-pce-lsp- setup-type & draft-ietf-pce-segment-routing
> >
> > Jon,
> > While I do not have an issue with enforcing the PST TLV be included in
> > the below message types, we still need to answer Stephane's last
> > question in his original email. That is whether the PST is allowed to
> > change during the lifetime of the LSP. I am hoping the answer is no
> > meaning that once a LSP with a PLSP-ID is established, a subsequent
> > PCUpd message with a PST type that does not match the type in the
> > original message which created that PLSP-ID (PCReq or PCInitiate)
> > should result in the PCC returning a PCErr message with Error-Type =
> > 21 (Traffic engineering path setup error) and Error-Value = 2 (Mismatched path
> setup type).
> >
> > If that is the understanding of this group, we should explicitly
> > document it in draft-ietf-pce-lsp-setup-type.
> >
> > Mustapha.
> >
> > > (2) referring to a shortcut), the conclusion is that, as soon as PST
> > > is
> > not 0 (i.e.
> > > multiple types, we do not have a mean to send a PCReq leaving the
> > > type selection to the PCE (no TLV implying type 0). Do we consider a
> > > mean to support that? (Could be 0xFF or a flag from the "Reserved"
> > > field.)
> > >
> > > > OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE
> > > > is not present in a message, then it unambiguously means that the
> > > > path setup type is RSVP-TE.  Then implementations don't have to
> > > > try to infer the path setup type from other objects or previous messages.
> > > >
> > > >
> > > >
> > > > I am revising draft-ietf-pce-lsp-setup-type at the moment to
> > > > address an earlier comment from Julien, so I will include this
> > > > clarification in the next revision.
> > > >
> > > >
> > > >
> > > > Thanks for the input!
> > > >
> > > > Cheers
> > > >
> > > > Jon
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > PATH-SETUP-TYPE, with the implication that there is no change to
> > > > the path type.
> > > >
> > > >
> > > >
> > > > The PCC rejects the PCUpdate because of a bad ERO subobject type.
> > > > It reads the PCUpdate as having PST type=0.
> > > >
> > > >
> > > >
> > > > indicating the path setup type. SR draft tells "In order to setup
> > > > an SR-TE LSP using SR, RP or SRP object MUST include
> > > > PATH-SETUP-TYPE TLV". Unfortunately it does not specify explicitly in
> which message.
> > > > setup" that it applies to the PCInitiate message. But nothing
> > > > tells about the PCUpdate message.
> > > >
> > > > that: "if the path setup type cannot be unambiguously inferred
> > > > from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be
> > > > used in PCRpt and PCUpd messages."
> > > >
> > > > Or do we allow to change the PST through PCUpdate messages which
> > > > may require to  always set the PST ? (moving from RSVP-TE to SR or
> > > > the other way for a particular LSP)
> > > >
> > > >
> > > >
> > > <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fcl
> > > ic
> > > voice.s
> > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26
> > > ro ot
> > > <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fcl
> > > ic
> > > voice.s
> > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26
> > > ro ot
> > > > <mailto:[email-masked]>
> > > >
> > > >
> > > >
> > > >
> > >
> > > > etant susceptibles d'alteration, Orange decline toute
> > > > responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> > > >
> > > > privileged information that may be protected by law; they should
> > > > not be distributed, used or copied without authorisation.
> > > > etant susceptibles d'alteration, Orange decline toute
> > > > responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> > > >
> > > > privileged information that may be protected by law; they should
> > > > not be distributed, used or copied without authorisation.

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 17 Nov 2017 00:40:59 +0000

Mustapha, Dhruv,

Thanks for the feedback.

The procedures that a PCC should follow to update the LSP setup type are a local matter for the PCC, and in any case are impossible to say in a draft that is agnostic of the specific LSP setup types being used.  The use case for doing this seems sufficiently unclear that I don't think we should add text to try to describe it in more detail.  I just don't want to artificially remove the flexibility from the draft.  If it is found to be useful in future we can consider whether any procedures need to be documented for the case at hand.

The PCC can always decide not to act on a PCUpd.  I think RFC 8231 already has this covered adequately:

   If the PCC
   decides that the LSP parameters proposed in the PCUpd message are
   unacceptable, it MUST report this error by including the
   LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
   parameters" in the LSP object in the PCRpt message to the PCE.  Based
   on local policy, it MAY react further to this error by revoking the
   delegation.

Regards
Jon

-----Original Message-----
From: Aissaoui, Mustapha (Nokia - CA/Ottawa) [mailto:[email-masked]] 
Sent: 17 November 2017 06:47
To: Dhruv Dhody <[email-masked]>; Jonathan Hardwick <[email-masked]>; Julien Meuric <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dhruv Dhody' <[email-masked]>
Subject: RE: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Thanks Dhruv.

Mustapha.

> To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
> <[email-masked]>; Jonathan Hardwick 
> <[email-masked]>; Julien Meuric 
> Subject: RE: [Pce] Clarifications on PST handling in 
> And I agree with that. In case of message which is in a "response" 
> such as PCRep, PCRpt it MUST have the same PST.
> But PCUpd and PCInitiate are different and keeping a door open for 
> allowing the change of PST could allow better migration from RSVP-TE 
> to SR for existing tunnels.
> 
> How about we update the text in the draft to explicitly say that this 
> is about PCC's local policy and PCC MAY send an error in case the 
> local policy doesn't allow changing of PST?
> 
> Thanks!
> Dhruv
> 
> > While I do not have an issue with enforcing the PST TLV be included 
> > in the below message types, we still need to answer Stephane's last 
> > question in his original email. That is whether the PST is allowed 
> > to change during the lifetime of the LSP. I am hoping the answer is 
> > no meaning that once a LSP with a PLSP-ID is established, a 
> > subsequent PCUpd message with a PST type that does not match the 
> > type in the original message which created that PLSP-ID (PCReq or 
> > PCInitiate) should result in the PCC returning a PCErr message with 
> > Error-Type =
> > > (2) referring to a shortcut), the conclusion is that, as soon as 
> > > PST is
> > not 0 (i.e.
> > > type selection to the PCE (no TLV implying type 0). Do we consider 
> > > a mean to support that? (Could be 0xFF or a flag from the "Reserved"
> > > field.)
> > >
> > > > is not present in a message, then it unambiguously means that 
> > > > the path setup type is RSVP-TE.  Then implementations don't have 
> > > > to try to infer the path setup type from other objects or previous messages.
> > > >
> > > >
> > > >
> > > > *From:*Jonathan Hardwick 
> > > > [mailto:[email-masked]]
> > > > Although I'm not convinced it would be a good idea 
> > > > operationally, I don't think there's any need to prevent the 
> > > > path type changing on the PCUpd, if an explicit PATH-SETUP-TYPE 
> > > > is given.  That is, draft-ietf-pce-lsp-setup-type, as a base 
> > > > draft, should allow that flexibility.  A given device may choose not to allow that, of course.
> > > >
> > > >
> > > >
> > > > indicating the path setup type. SR draft tells "In order to 
> > > > setup an SR-TE LSP using SR, RP or SRP object MUST include 
> > > > through a PCInitiate message having the PST TLV, the PCC can 
> > > > infer that futher updates will use EROs associated with the same PST.
> > > >
> > > >
> > > >
> > > > may require to  always set the PST ? (moving from RSVP-TE to SR 
> > > > or the other way for a particular LSP)
> > > >
> > > >
> > > >
> > > > Ce message et ses pieces jointes peuvent contenir des 
> > > > informations confidentielles ou privilegiees et ne doivent donc 
> > > > pas etre diffuses, exploites ou copies sans autorisation. Si 
> > > > vous avez recu ce message par erreur, veuillez le signaler a 
> > > > l'expediteur et le detruire ainsi que les pieces jointes. Les 
> > > > messages electroniques etant susceptibles d'alteration, Orange 
> > > > decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> > > >
> > > > If you have received this email in error, please notify the 
> > > > sender and delete this message and its attachments.
> > > > Ce message et ses pieces jointes peuvent contenir des 
> > > > informations confidentielles ou privilegiees et ne doivent donc 
> > > > pas etre diffuses, exploites ou copies sans autorisation. Si 
> > > > vous avez recu ce message par erreur, veuillez le signaler a 
> > > > l'expediteur et le detruire ainsi que les pieces jointes. Les 
> > > > messages electroniques etant susceptibles d'alteration, Orange 
> > > > decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> > > >
> > > > If you have received this email in error, please notify the 
> > > > sender and delete this message and its attachments.