> On Sep 3, 2022, at 4:46 AM, Ketan Talaulikar <[email protected]> wrote: > > 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.
So, are you saying it would be too messy to structure the registry that way (I don’t think it would), or that doing that work represents scope creep for the present spec (I agree)? Regarding scope creep, there are at least two ways to think of this — 1. It’s worth doing but this is not the place. Let’s propose a new WG draft that’s just a registry maintenance draft. 2. It’s worth doing, and we will take on the extra effort of doing it in this draft, to spare the WG the overhead of processing a whole new draft. Kind of the Boy Scout ethos of leaving the campsite cleaner than you found it. In case 1, I guess the question then becomes, if there’s a registry maintenance draft in the offing, is it even worth introducing the “X” state, which IMO seems like a bit of a forced fit compared to a simple matrix with Y/N in each cell? Maybe since you’ve already done that much of an audit on the registry, introduce two columns, one for L2BMA sub-TLV and one for RL sub-TLV, with Y/N in each column? > 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. I, too, would like to hear the WG’s input. Thanks, —John > > 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
