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:mustapha.aissa...@nokia.com] Sent: 17 November 2017 06:47 To: Dhruv Dhody <dhruv.dh...@huawei.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 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%2F > > > cl > > > 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%2F > > > cl > > > 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
