Hi Samuel, <snip>
> If you choose to keep it generic, then this field should be variable > length and have its own flag, while making sure we are able to be > compatible with existing implementations - which could be tricky! Also note > that we are adding this generic concept only for SR-ERO and not SRv6-ERO! > > > > <S> If it will become variable length, then it may be really cleaner to > convert it into sub-TLVs, but that would practically break backward > compatibility with existing implementations of this draft (and we were > trying to avoid that). > > > > Dhruv: Suppose I need to add a 32-bit value next, I won't be able to use > this Subobject Extension Block and I would need to create a 'Subobject > Extended Extension Block' 🥴 to support that. If we want to solve this > problem in a generic way, we should then attempt to solve it fully. Just > leaving a 24-bit space is not future proof. > > > > Yes we would need a way to find the length of the block, the combination > of flags that we are making mandatory to include can play that trick, even > though I dont like it. > > > > <S2> If you check discussion with Ketan, idea here was to anyway start > discussion on mailing list about long-term solution (e.g. subTLVs) for > future drafts, which will try to extend ERO sub-objects and update current > solution to potentially allow re-use if possible, but in backward > compatible way with existing implementations. > > > > If some future draft needs to add 32bits then, that document can just add > another 32bits after extension (re-using remaining reserved space will not > save anything since object will have to be aligned to 4B anyway). I > requested slot to this IETF to present changes done to this draft and I > planned to mention this topic briefly as well (but still keep discussion to > mailing list then). > Dhruv: I am not as hopeful that there would be consensus to move to sub-TLV without overhauling the whole encoding. We had similar discussion in the SRv6 case and it led to adding this section - https://www.rfc-editor.org/rfc/rfc9603.html#section-4.3.1.2 which is a good guidance even for SR-ERO. This discussion is not new. For SRv6 it was not required, because of existing reserved space. Same > approach can be used by anybody in the future, who need more space in > SRv6-ERO. > > > > > > Dhruv: I am thinking about the next 32-bit value that might be needed in > both subobjects. Creation of this new generic Subobject Extension Block > mechanism would be across different RFCs for SR-ERO and SRv6-ERO, and then > we get complaints that finding related RFCs in PCE WG is hard :) > > > > <S2> Each sub-object has its own format, its own flags, fields,… > Specifically for 32b extension, we can use same approach as discussed above > for both. > > > > At this stage, my suggestion would be to simply call it "Algorithm > Extension Block". Yes we lose the capability to add non-algorithm related > fields in that case (not-ideal), but that aligns much better to various > optional additions to this sub-object we have done in the past. Thoughts? > > > > <S> Are there any existing optional additions to SR-ERO/SRv6-ERO? Can you > please point me to any of them? We can use approach with "Algorithm > Extension Block", but it is making encoding of ERO very inefficient for > future. Especially after consider how often it is encoded (e.g. for > policies with multiple segment-lists). > > > > > > Dhruv: Not that I am aware of. > > I understand and sympathise with your motivation. But, we should either > make the Subobject Extension Block variable length and truly extensible or > just keep it as an "Algorithm Extension Block" IMHO. > > > > <S2>I fully agree with you that variable length would nicer (no question > about that part), but that would either mean: > > 1. Breaking backward compatibility with existing implementations for > current draft (e.g. by introducing some “Length” field in that variable > block) > > Dhruv: We have to design an encoding without the length field. If just A flag is set, then the block is 32 bits only. Any future flag should state what should be the length. In the future suppose a 8-bit field is added called Z, we add a Z flag and state that the block remains 32 bits. In the future suppose a 32-bit field is added called X, we add a X flag and state that the block would be 64 bits ... This guidance can be added in the draft! > 1. > 2. Blocking other possible solutions from long-term (e.g. subTLVs) > > Since there is no conclusion about long-term solution, fixed size blocks > seems to me like good middle way. It will still allow migration to approach > with subTLVs for future documents (if we will have such agreement in WG), > it will allow more efficient (from encoding POV) direct extensions (like > one in this draft) and in the same time we are maintaining backward > compatibility with existing implementations. > > > > <snip> > > -- > > > > Section 5.2.2, 2nd paragraph, please add parentheses () when adding > reference for better readability. > > > > <S> Are you referring to specific references only or in general? I believe > those references were done based on recommended format from: > > https://authors.ietf.org/en/references-in-rfcxml > > > > > > OLD: > > The PCE must follow the IGP Flexible Algorithm path computation logic as > described in [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>]. > This includes performing the FAD selection as described in Section 5.3 > <https://rfc-editor.org/rfc/rfc9350#section-5.3> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>] and > other sections, determining the topology associated with specific Flexible > Algorithm based on the FAD, the node participation Section 11 > <https://rfc-editor.org/rfc/rfc9350#section-11> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>], > using ASLA-specific link attributes Section 12 > <https://rfc-editor.org/rfc/rfc9350#section-12> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>], > and applying other rules for Flexible Algorithm path calculation Section > 13 <https://rfc-editor.org/rfc/rfc9350#section-13> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>]. > While [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>] > defines > the base procedures for IGP Flexible Algorithms, these procedures are > further extended by other documents such as [I-D.ietf-lsr-flex-algo-bw-con > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#I-D.ietf-lsr-flex-algo-bw-con>], > a PCE implementation may need support these IGP extensions to allow use of > specific constraints in FAD. [I-D.ietf-lsr-igp-flex-algo-reverse-affinity > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#I-D.ietf-lsr-igp-flex-algo-reverse-affinity>] > introduced > IANA registry called "IGP Flex-Algorithm Path Computation Rules Registry" > within the "Interior Gateway Protocol (IGP) Parameters" registry group with > the ordered set of rules that MUST be used to prune links from the topology > during the Flex-Algorithm path computation. > > NEW: > > The PCE must follow the IGP Flexible Algorithm path computation logic as > described in [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>]. > This includes performing the FAD selection as described in Section 5.3 > <https://rfc-editor.org/rfc/rfc9350#section-5.3> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>] and > other sections, determining the topology associated with specific Flexible > Algorithm based on the FAD, the node participation (Section 11 > <https://rfc-editor.org/rfc/rfc9350#section-11> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350> > ]), using ASLA-specific link attributes (Section 12 > <https://rfc-editor.org/rfc/rfc9350#section-12> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350> > ]), and applying other rules for Flexible Algorithm path calculation (Section > 13 <https://rfc-editor.org/rfc/rfc9350#section-13> of [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350> > ]). While [RFC9350 > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC9350>] > defines > the base procedures for IGP Flexible Algorithms, these procedures are > further extended by other documents such as [I-D.ietf-lsr-flex-algo-bw-con > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#I-D.ietf-lsr-flex-algo-bw-con>], > a PCE implementation may need support these IGP extensions to allow use of > specific constraints in FAD. [I-D.ietf-lsr-igp-flex-algo-reverse-affinity > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#I-D.ietf-lsr-igp-flex-algo-reverse-affinity>] > introduced > IANA registry called "IGP Flex-Algorithm Path Computation Rules Registry" > within the "Interior Gateway Protocol (IGP) Parameters" registry group with > the ordered set of rules that MUST be used to prune links from the topology > during the Flex-Algorithm path computation. > > END > > > > <S2> Sure, I can add it - even if I don’t see it being done in other PCEP > RFCs, e.g. > > https://www.rfc-editor.org/rfc/rfc8231.html#section-6.1 > > https://www.rfc-editor.org/rfc/rfc8281.html#section-7 > > https://www.rfc-editor.org/rfc/rfc9604.html#name-introduction > > Dhruv: The text without parentheses was not readable. If you don't want to use parenthesis you can make it into full sentences such as "the node participation as per Section 11 of [RFC9350]" as an example. Thanks! Dhruv > … > > > > Thanks! > > Dhruv > > > > > > -- > > > > Thanks! > > Dhruv > > > > On Wed, Jun 25, 2025 at 6:06 PM Ketan Talaulikar <[email protected]> > wrote: > > 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] > > _______________________________________________ > Pce mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
