Hi Samuel (and co-authors), Thanks for posting this update to address all comments from the AD review.
Thanks, Ketan On Wed, Jun 25, 2025 at 6:22 AM Samuel Sidor (ssidor) <[email protected]> wrote: > Thanks Ketan for your suggestion. > > > > Please check submitted version 21. Finally, we called that extension block > as “Subobject Extension Block” since it will be used for RRO as well, so we > tried to avoid using “ERO” in the name. > > > > Regards, > > Samuel > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Monday, June 23, 2025 9:41 PM > *To:* Samuel Sidor (ssidor) <[email protected]> > *Cc:* [email protected]; [email protected] > *Subject:* Re: AD review of draft-ietf-pce-sid-algo-19 > > > > Hi Samuel, > > > > Thanks for posting the last update. > > > > Regarding this one outstanding point, thanks for clarifying that the > 32-bit Algo+Reserved field is optional (depending on the flag settings). > Can we name this 32-bit block as an optional "ERO Extension Block" and show > it as optional in the figure? Then at the bottom of the figure show this > ERO Extension Block to be composed of the Reserved + Algo fields? > > > > I now understand the proposal better with the example. However, the text > still needs work to reflect this scheme. I use the term "ERO > Extension Block" (please feel free to pick a better name) to indicate that > this is not Algorithm specific anymore. > > > > SUGGEST: > > A new bit in the Flags field: > > * A-flag (SR-Algorithm Flag): If set to '1' by a PCEP speaker, the > ERO Extension Block MUST be included in the SR-ERO subobject as > shown in Figure 1 along with the specified algorithm and the > length of the subobject is extended by 4 octets. If this flag is > set to 0, then either: > - the ERO Extension Block is not included and processing > described in Section 5.2.1 of [RFC8664] applies, or > - the ERO Extension Block is included (due to an extension > flag in a future document) and the Algorithm field MUST be > ignored. > > ERO Extension Block: > Reserved (24 bits): This field is reserved for future use and > MUST be set to zero when sending and ignored when receiving. > > Algorithm (8 bits): SR-Algorithm value from registry "IGP > Algorithm Types" of "Interior Gateway Protocol (IGP) Parameters" > IANA registry. > > Any future extension that uses the Reserved field in the ERO Extension > Block MUST be accompanied with its own flag (similar to the A flag) in > the ERO as well as a capability signaling for its usage. > > I hope I have got that correct, but please feel free to update/edit. There > may also be some other text changes for consistency around these new terms > and this concept. > > Again, I will leave it to the WG on whether or not this is the approach or > direction they wish to take. I am only looking for a tight specification of > these behaviors in the document. > > Thanks, > > Ketan > > > > On Mon, Jun 23, 2025 at 12:18 PM Samuel Sidor (ssidor) <[email protected]> > wrote: > > Hi Ketan, > > > > The draft version from previous mail is submitted now. I'll update draft > with those minor updates. > > > > For last opened comment: > > > > KT> I am afraid this is not very clear. Are you saying that this document > > is not just introducing a new A flag but also a fixed 32 bit container that > > is always present in the SR-ERO object (when the algo capability is > > advertised)? I just saw that those fields are not optional in the diagram. > > Then I am confused why the size of the object would change depending on the > > value of the A field (see text at the end of section 4.2). > > > > <S> SR-ERO Subobject is extended with 4 bytes to keep length aligned to > multiple of 4. Those 4 bytes are present if needed for any extension > included in them based on flags (not globally to all instances based on > capability advertised). For now, it will be included if A flag is set in > specific SR-ERO subobject. In the future if some other draft will add > another field in "Reserved" space and new flag, then same 4 bytes can be > included as well (including Algorithm field). That's why we are saying in > the draft even now that PCEP speaker will ignore value of Algorithm field > if A flag was not set (even if capability was advertised). > > > > We are trying to make sure that if in the future somebody will add new > extensions, which can (but does not have to combined with extensions from > this draft), then we will encode subobject in optimal way, so something > like: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |L| Type=36 | Length | NT | Flags |N|A|F|S|C|M| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SID (optional) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // NAI (variable, optional) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved | NEW FIELD | Algorithm | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Instead of doing sub-optimal encoding like this: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |L| Type=36 | Length | NT | Flags |N|A|F|S|C|M| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SID (optional) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // NAI (variable, optional) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved | Algorithm | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved | NEW FIELD | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Especially since ERO subobjects can be encoded a lot of times per LSP > (multiple hops in single ERO, possibly repeated in RRO, multiple > segment-lists, reverse ERO,…), so optimality of encoding is more important > than for example encoding of constraints. > > > > (We can still start discussion in mailing list about future extensions, > but encoding above is at least keeping doors opened even if we decide to > use sub-TLV or any other solution.) > > > > Regards, > > Samuel > > > > -----Original Message----- > > From: Ketan Talaulikar <[email protected]> > > Sent: Friday, June 20, 2025 5:54 PM > > To: Samuel Sidor (ssidor) <[email protected]> > > Cc: [email protected]; [email protected] > > Subject: Re: AD review of draft-ietf-pce-sid-algo-19 > > > > Hi Samuel/co-authors, > > > > Thanks for taking the time to discuss and incorporate the > suggestions/feedback. > > > > I would also suggest posting this update as an "intermediate update" so > the WG also gets the time to review and (if necessary) follow-up. We are > almost done anyway. > > > > Please check inline below for follow-ups/clarifications. There is really > only one major item where I am still not clear (related to the Algo field > in the SR-ERO). > > > > Also you can consider points where I have not responded as addressed > (either by the proposed changes or responses). > > > > On Tue, Jun 17, 2025 at 8:48 AM Samuel Sidor (ssidor) <[email protected]> > > wrote: > > > > > Hi Ketan, > > > > > > > > > > > > Please find inline responses <S> and version updated based on > > > discussion with other co-authors (thanks a lot to PSF and Andrew for > great discussion). > > > > > > > > > > > > Thanks, > > > > > > Samuel > > > > > > > > > > > > Hi Authors/WG, > > > > > > Thanks for your work on this important document that tries to leverage > > > IGP technologies like FlexAlgo in PCE and builds on top for delivering > > > new use-cases. > > > > > > I would like to start with a high-Level overview of the specifications > > > based on my reading and some questions/suggestions. Please correct me > > > if my understanding is wrong. > > > > > > 1) There are 3 main types of extensions: > > > > > > a) Extensions to Metric Objects: these aren't specific to SR path > types, > > > they aren't specific to FlexAlgo, they are more general. I suggest > that > > > this be brought out in the Abstract and Introduction sections. > > > Also, that > > > the specifications for this be brought out as a top-level section in > the > > > document. Please consider this as a major editorial comment. > > > > > > <S> Both abstract and introduction updated. > > > > > > b) Algo support in SR-ERO/RRO: this is purely a signaling extension to > > > convey additional algo information and unrelated to any computational > > > enhancements to the PCE functionality. E.g., it could be used for say > a > > > PCE-initiated explicit path. Would be great if this could be called > out > > > and the document sections were re-ordered accordingly. > > > > > > <S> Ack, moved to separate section. > > > > > > c) Algorithm Constraint: this is getting algo (both FlexAlgo and any > > > other specific IGP algo) related aspects into the path computation. > This > > > now enables the conveying of IGP aspects (e.g., for FlexAlgo the > > > optimization metric and other constraints from the FAD) in PCEP. > > > > > > Both (b) and (c) are covered by the same new capability being > introduced > > > and specific to the SR path setup types. Ideally, it would have > > > been nice > > > to use different capabilities, but I guess (b) is really a small > > > add-on and > > > hence covered together with (c). I hope there is no one that tries to > > > implement (b) but not (c). > > > > > > <S> Correct, it is small enough to create separate capability, but we > > > are open to change it if there anybody really plans to implement subset > only. > > > > > > 2) The (1)(c) functionality can be further split into two major types: > > > > > > a) FlexAlgo related (algo 128-255): this requires that the PCE is > aware > > > of IGP signaling information related to FlexAlgo (such as FAD, algo > > > participation, metric types including generic metric, ASLA, etc.). > > > It would > > > be good to call out that it is expected that this topology information > > > is conveyed to the PCE via existing mechanisms (viz. IGPs or BGP-LS). > > > > > > <S> Added explicit statement to “5.2.2. Path Computation for Flexible > > > Algorithms” section. > > > > > KT> Thanks. Please update the reference to BGP-LS to RFC 9552. > > > > > > > > b) non-FlexAlgo related (algo 0-127): Of these algos, only default (0) > > > and strict-SPF (1) are specified. Since the rest is undefined, they > > > cannot > > > be supported in PCEP as well - this needs to be called out along > > > with the > > > necessary error handling, if those are received. Further, default > > > (0) has > > > been already in use in PCEP for ages now - this needs to be called out > > > >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
