+1 Thanks Jon!
On Thu, Nov 16, 2017 at 1:25 PM, <stephane.litkow...@orange.com> wrote: > Thanks Jon. > > > > *From:* Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com] > *Sent:* Thursday, November 16, 2017 11:51 > > *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > *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:* stephane.litkow...@orange.com [mailto:stephane.litkowski@ > orange.com <stephane.litkow...@orange.com>] > *Sent:* 15 November 2017 13:52 > *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org > *Subject:* RE: Clarifications on PST handling in > draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing > > > > 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 > <jonathan.hardw...@metaswitch.com>] > *Sent:* Wednesday, November 15, 2017 09:28 > *To:* LITKOWSKI Stephane OBS/OINIS; 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 <pce-boun...@ietf.org>] *On > Behalf Of *stephane.litkow...@orange.com > *Sent:* 14 November 2017 00:38 > *To:* 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, > > > > > > [image: 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 > > > > _________________________________________________________________________________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ > > 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
