Hi Mike, Olivier, Speaking as a WG member...
On Mon, Mar 29, 2021 at 2:42 PM Mike Koldychev (mkoldych) <[email protected]> wrote: > > Hi Olivier, > > > > I would not recommend using the BSID TLV for #2 (Signal the presence of a > Stitching Label in the path of a Tunnel/Policy). ERO/SR-ERO is the object > that encodes the label-stack/path, and the SL is part of the label-stack/path > of the previous Policy/Tunnel that uses it, so it belongs to the ERO/SR-ERO. I agree. > BTW I don’t believe there is currently a way in PCEP to represent a BSID ERO > sub-object, it would be useful to define it in some common way with the > Stitching Label. > For SR we can use the existing SR-ERO subobject itself as per the binding label/SID draft, and we also have a Label subobject that can be made to use for non-SR cases. > > > I agree about using flag(s) instead of allocating a new PST to represent the > SL in the BSID TLV. > > We should describe a clear relationship between binding and stitching labels. Then, TE-PATH-BINDING TLV could be used to report/request a stitching label with a flag set in this TLV. Thanks! Dhruv > > *IF* RSVP-TE RECORD_ROUTE is used, then RRO object is appropriate. > > > > Thanks, > > Mike. > > > > From: [email protected] <[email protected]> > Sent: Tuesday, March 23, 2021 2:11 PM > To: Mike Koldychev (mkoldych) <[email protected]>; Stone, Andrew (Nokia - > CA/Ottawa) <[email protected]>; Dhruv Dhody <[email protected]> > Cc: [email protected] > Subject: Re: [Pce] Implementation option of > draft-ietf-pce-stateful-interdomain-01.txt > > > > Hi Mike, > > Le 22/03/2021 à 21:03, Mike Koldychev (mkoldych) a écrit : > > Hi Olivier, > > > > I believe what you are trying to achieve is: > > Attach a Stitching Label to a Tunnel/Policy, similar to how a Binding Label > points to a Tunnel/Policy. > > [OD] Yes. Exactly > > > Signal the presence of a Stitching Label in the path of a Tunnel/Policy. > > [OD] Yes by using PCE to PCE exchange through PCEP to convey this information > > > > > > I believe that #1 can be achieved using the Binding Label TLV, by perhaps > defining another Binding Type. And #2 can be achieved by adding another > ERO/SR-ERO sub-object. > > [OD] I think that both #1 & #2 could be achieved using the TE-PATH-BINDING > TLV minus the addition of new flag to mention that the TE-PATH-BINDING TLV > transport a Stitching Label. I would not define a new Binding Type as we > could re-use which have been already define in the pce-binding-sid draft and > we would not go back to the same problem as with the multiple PST code point. > So, a dedicated flag to mention that it is a Binding Label for inter-domain > would be better. > > > > I do not think it’s a good idea to use the RRO unless there is an actual RSVP > RECORD_ROUTE being used. > > [OD] I tend to be agree after analysis all potential inconvenient, in > particular in term of management. But, in another hand, the Stitching label > is part of the Tunnel path reported by the Record Route Object. > > Regards > > Olivier > > > > Thanks, > > Mike. > > > > From: Pce <[email protected]> On Behalf Of Stone, Andrew (Nokia - > CA/Ottawa) > Sent: Thursday, March 11, 2021 11:11 AM > To: [email protected]; Dhruv Dhody <[email protected]> > Cc: [email protected] > Subject: Re: [Pce] Implementation option of > draft-ietf-pce-stateful-interdomain-01.txt > > > > Hi Olivier, > > > > Thanks for pointing this out. I think the presentation slide wording might > have been a bit stronger than what is currently written in the posted draft, > as the text does not prohibit the use of RRO but rather acknowledge and > document that there are implementations which skip inclusion of SR-RRO (Nokia > implementation does send SR-RRO), so it documents how to handle this scenario > on the PCE. The text indicates that SR-RRO may or may not be included, and if > omitted the PCE is to fallback to treating the ERO “like” it was an RRO. > > > > https://datatracker.ietf.org/doc/html/draft-koldychev-pce-operational-03#section-6 > > > > A PCC MUST send an (possibly empty) ERO/SR-ERO/SRv6-ERO in the PCRpt > > message for every LSP. A PCC MAY send an SR-RRO/SRv6-RRO for an SR- > > TE/SRv6-TE LSP (respectively). A PCE SHOULD interpret the RRO/SR- > > RRO/SRv6-RRO as the actual path the LSP is taking but MAY interpret > > only the ERO/SR-ERO/SRv6-ERO as the actual path. In the absence of > > an RRO/SR-RRO/SRv6-RRO a PCE SHOULD interpret the ERO/SR-ERO/SRv6-ERO > > (respectively) as the actual path for the LSP. > > > > > > I think the potential interdomain stitching label case you point out and the > S-Flag defined in RFC8664 mentioned by Dhruv during the meeting seem to be > valid use cases where an SR-RRO would need to be included. > > > > Thanks! > > Andrew > > > > From: Pce <[email protected]> on behalf of "[email protected]" > <[email protected]> > Organization: Orange Labs > Date: Thursday, March 11, 2021 at 5:17 AM > To: Dhruv Dhody <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Pce] Implementation option of > draft-ietf-pce-stateful-interdomain-01.txt > > > > Hello Dhruv, all, > > Following the presentation done during the IETF meeting, please find the link > to the presentation: > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-32-inter-domain-00 > > I also not a major point to take into account following the presentation of > draft PCEP Operational Clarification (draft-koldychev-pce-operational) see > https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/ and > https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-34-operational-clarification-00: > > => In this draft, authors propose to use SR-ERO/SRv6-ERO and to NOT use > SR-RRO/SR-v6-RRO for Segment Routing. > > As a consequence for the stateful inter-domain draft, proposed option d1, d2 > and d3 become invalid as it uses the RRO to convey the Stiching Label. Thus, > only option d4 with a specific new sub-Object to convey the Stitching Label > remains valid. > > As usual, comments are welcome. > > Regards > > Olivier > > Le 26/02/2021 à 05:35, Dhruv Dhody a écrit : > > Hi Olivier, > > Thanks for starting this thread. > > As a WG participant... > > > > On Tue, Feb 23, 2021 at 12:05 AM <[email protected]> wrote: > > Dear all, > > According to the remark about implementation we got during the WG call > for adoption, we would start a new thread to discuss this point. > The goal isto prepare the discussion for next IETF meeting and reach a > consensusin order to edit revision 2 of the draft. > > The stitching label principle requires at least a certain number of > modifications in the current PCEP version: > > a) A new PCE Capability to announce the inter-domain behaviour > b) A new PCE Association Group to associate the local paths identifier > to the inter-domain identifier > c) new PCEP Errors to manage the Stitching Label exchange > d) A mechanism to convey the Stitching Label > > If there is no other choice than to reuse existing PCEP Objects by > allocating new code points for modifications a-c,there is several > options for point d, which we have tried to list below: > > d1) Use ERO and RRO in conjunction to new Path Setup code points as > described in version 01 of the draft. It is the simplest > implementation but as mention by Dhruv, each time a new path > enforcement appear, a new PST code point must be allocated. > For example, when Segment Routing v6 will be standardized, we must > allocate a new Stitching label PST code point for SRv6. > d2) Use ERO and ERO in conjunction to a new flag in LSP. Simple as for d1, > but need to use the LSP Extended Flag draft as all LSP flags have been > already allocated. > d3) Same as d2 but find another place for the flag e.g. SRP or LSPA Object. > d4) Define a new PCEP sub-Objet TLV within the LSP Object to convey the > stitching label. This is more independent but need extra parsing from > an implementation point of view. > > > My preference would for d2 or d3 (in that order). > LSP Extended Flag is adopted by the WG and is ready for prime-time use -- > let's use it :) > Authors of LSP Extended Flag are waiting for the draft blockade to be lifted > to post the -00 WG I-D. > > Thanks! > Dhruv > > > > Please, give us your opinion about these different options and don't hesitate > to propose others. > > Regards > > Olivier on be-half of co-author's > > > > > _________________________________________________________________________________________________________________________ > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce > > -- > > > > Olivier Dugeon > Orange Expert, Future Networks > Open Source Referent > Orange/IMT/OLN/WTC/IEE/iTeQ > > > > fixe : +33 2 96 07 28 80 > mobile : +33 6 82 90 37 85 > [email protected] > > _________________________________________________________________________________________________________________________ > > > > 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. > > -- > > > > Olivier Dugeon > Orange Expert, Future Networks > Open Source Referent > Orange/IMT/OLN/WTC/IEE/iTeQ > > > > fixe : +33 2 96 07 28 80 > mobile : +33 6 82 90 37 85 > [email protected] > > _________________________________________________________________________________________________________________________ > > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
