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. > -----Original Message----- > From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com] > Sent: Thursday, November 16, 2017 5:32 PM > To: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissa...@nokia.com>; > Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; Julien Meuric > <julien.meu...@orange.com>; stephane.litkow...@orange.com > Cc: pce@ietf.org; 'Dhruv Dhody' <dhruv.i...@gmail.com> > Subject: RE: [Pce] Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & > draft-ietf-pce-segment-routing > > 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, > > 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. > > 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. > > > -----Original Message----- > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aissaoui, > > Mustapha (Nokia - CA/Ottawa) > > Sent: 17 November 2017 05:18 > > To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; Julien > > Meuric <julien.meu...@orange.com>; stephane.litkow...@orange.com > > Cc: pce@ietf.org > > 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). > > > > If that is the understanding of this group, we should explicitly > > document it in draft-ietf-pce-lsp-setup-type. > > > > Mustapha. > > > > > -----Original Message----- > > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan > > > Hardwick > > > Sent: Thursday, November 16, 2017 6:19 AM > > > To: Julien Meuric <julien.meu...@orange.com>; > > > stephane.litkow...@orange.com > > > Cc: pce@ietf.org > > > Subject: Re: [Pce] Clarifications on PST handling in > > > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > > > Hi Julien, see [Jon]s below... > > > > > > -----Original Message----- > > > From: Julien Meuric [mailto:julien.meu...@orange.com] > > > Sent: 16 November 2017 17:28 > > > To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; > > > stephane.litkow...@orange.com > > > Cc: pce@ietf.org > > > 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? > > > > > > [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.) > > > > > > [Jon] It could be done, but do we need it? This could be added > > > later without penalty. > > > > > > Thanks, > > > > > > Julien > > > > > > > > > Nov. 16, 2017 - jonathan.hardw...@metaswitch.com: > > > > > > > > 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:*stephane.litkow...@orange.com > > > > [mailto:stephane.litkow...@orange.com] > > > > *Sent:* 15 November 2017 13:52 > > > > > > > > > > > > > > > > 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:jonathan.hardw...@metaswitch.com] > > > > *Sent:* Wednesday, November 15, 2017 09:28 > > > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > > > > <mailto:pce@ietf.org> > > > > *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. > > > > > > > > > > > > > > > > Does that sound reasonable? > > > > > > > > Cheers > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of > > > > *stephane.litkow...@orange.com > > > > <mailto:stephane.litkow...@orange.com> > > > > *Sent:* 14 November 2017 00:38 > > > > *To:* pce@ietf.org <mailto:pce@ietf.org> > > > > *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. > > > > > > > > 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%2Fcl > > > ic > > > voice.s > > > so.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26 > > > ro ot > service%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> NE > > > W ! > > > > mobile: +33 6 71 63 27 50 > > > > > > > <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 > service%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> NE > > > W ! > > > > stephane.litkow...@orange.com > > > > <mailto:stephane.litkow...@orange.com> > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________ > > > __ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > ____________________________________________________________________ > > > __ > > > > ___________________________________________________ > > > > > > > > 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. > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/pce > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@ietf.org > > > https://www.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
