Hi John, Thanks again for your quick response.
Regarding the OSPFv3 Extended LSA registries, it is a bit challenging to do what (I think) you are asking for. We have a bunch (8 today and a remote possibility of more being added) of E-LSAs and all of them share the same E-LSA TLV space (where more TLVs can be expected to be defined). And then, for all of these E-LSA TLVs, we have a single shared E-LSA sub-TLV (at any level of hierarchy). So potentially, we can have a rather complicated set of columns depending on how we want to go about it. That is why, here, we are limiting to the current need - to indicate the applicability of a sub-TLV to L2 Bundle Member TLV. I am open to your and WG's suggestions on this. Thanks, Ketan On Fri, Sep 2, 2022 at 10:23 PM John Scudder <[email protected]> wrote: > Hi Ketan, > > Thanks for the update. > > > On Sep 2, 2022, at 9:16 AM, Ketan Talaulikar <[email protected]> > wrote: > > > > Since the OSPFv3 registry is shared for all OSPFv3 Extended LSA TLVs' > sub-TLVs, we need another flag X for those sub-TLVs that are not associated > with the Router Link TLV. > > Good point. But, doesn’t that suggest that if we’re going to annotate the > registry anyway, it should be annotated to indicate applicability for each > sub-TLV type? That would clean up the presentation from Y/N/X to just Y/N > per column. It would add a lot more columns but we don’t pay by the column. > :-) > > If there’s some reason this wouldn’t be valuable that’s OK but I’d like to > understand what makes Router Link and L2 Bundle Member need special > treatment that the other sub-TLVs don’t need. > > Thanks, > > —John
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
