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 - 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%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 ! > 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
