Hi Samuel, Thanks for the analysis! My preference is also for #3.
Ketan should be back later this week as well and would be good to get his feedback. During your presentation at IETF 123 you could also describe the proposed changes for this and get feedback and confirmation from the WG. Thanks! Dhruv On Tue, Jul 8, 2025 at 7:54 PM Samuel Sidor (ssidor) <ssi...@cisco.com> wrote: > Thanks Dhruv, > > I can summarize 4 approaches, which I can potentially see to: > > 1. Generic (re-usable) fixed sized extension block > > + Not blocking future possible future approaches > + Backward compatibility maintained with existing implementations > + Optimized size of encoded object (padding required in all cases) > - More complicated extensibility for extensions beyond reserved space in > the block (long-term solution required, e.g. by providing guidance in the > draft as you suggested) > > 2. Algorithm specific fixed sized extension block > > + Not blocking future possible future approaches > + Backward compatibility maintained with existing implementations > +/- Extensible for future (but still not easily extensible as future > drafts may update statements specifying length of subobject) > - Inefficient encoding (important considering how many times subobjects > are encoded for each LSP) > > 3. Variable length extension block > > + Extensible for future > + Backward compatibility maintained with existing implementations > + Optimized size of encoded object > - Blocking alternative approaches (e.g. subTLVs) or any other extensions > beyond that block (since length is derived by subtracting existing fields > from subobject length). > > 4. SubTLVs > + Extensible for future (probably best out of all options) > - Blocking alternative approaches > - Inefficient encoding > - Non backward compatible with existing implementations of SID algo draft > > To me, best options are #1 and #3. If discussion about usage of subTLVs > already happened (you mentioned that resulted in > https://www.rfc-editor.org/rfc/rfc9603.html#section-4.3.1.2) and it was > not preferred approach, then maybe we can really move to #3 and change > solution in the draft into variable length extensions block (length still > aligned to multiple of 4). > > Or do you see other reasonable options to consider, which are not covered > in summary above? > > (Ideally if Ketan can confirm as well, but he seems to be on PTO) > > For references - I'll add parenthesis. > > Regards, > Samuel > > > -----Original Message----- > From: Dhruv Dhody <dhruv.i...@gmail.com> > Sent: Monday, July 7, 2025 7:30 PM > To: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org> > Cc: Dhruv Dhody <d...@dhruvdhody.com>; draft-ietf-pce-sid-a...@ietf.org; > pce@ietf.org > Subject: Re: [Pce] Re: AD review of draft-ietf-pce-sid-algo-19 > > 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#RFC93 > > 50>] 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#RFC93 > > 50>], 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#RFC93 > > 50>], 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#RFC93 > > 50>] 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.i > > etf-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.i > > etf-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#RFC93 > > 50>] 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#RFC93 > > 50> ]), 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#RFC93 > > 50> ]), 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#RFC93 > > 50> > > ]). While [RFC9350 > > <https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-21.html#RFC93 > > 50>] 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.i > > etf-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.i > > etf-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 > > <ketant.i...@gmail.com> > > wrote: > > > > Hi Samuel (and co-authors), > > > > > > > > Thanks for posting this update to address all comments from the AD > > review >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
