Hi John, Please check inline below with KT for a quick clarification.
On Mon, Sep 5, 2022 at 8:39 PM John Scudder <j...@juniper.net> wrote: > Hi Ketan, > > Seems like a good plan. Comments below. > > > On Sep 5, 2022, at 3:31 AM, Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > > > > I am personally OK with adopting the "boy scout" approach here - even if > it might be seen as a scope creep. > > > > Following is a proposal for feedback from you and the WG: > > > > We'll first need 9 columns in the "OSPFv3 Extended-LSAs Sub-TLVs" > registry at this point to indicate the applicability of each sub-TLV to its > parent TLV(s). More may be required as we go along and new TLVs are added. > > > > 1) Router Link (RL) > > 2) Attached Routers (AR) > > 3) Inter-Area Prefix (IeAP) > > 4) Inter-Area Router (IAR) > > 5) External Prefix (EP) > > 6) Intra-Area Prefix (IaAP) > > 7) IPv6 Link-Local Address (6LL) > > 8 IPv4 Link-Local Address (4LL) > > 9) Extended Prefix Range (EPR) > > > > Then we will need the 10th column to indicate applicability to the L2 > Bundle Member Attribute (L2BM) Sub-TLV. > > > > These columns may become very complicated and not sure how they would > look in the IANA registry. > > When you say “very complicated” do you simply mean that the table would be > wide? Because all I’m envisioning is ten additional columns in the > registry, with each cell containing either “Y” or “N”; this doesn’t seem > inherently complex to me. This approach is familiar from some of the IS-IS > registries, consider > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information > for example. Only six columns in that one, not ten, but the idea is the > same. KT> The complication is when more/further TLVs are defined - it may get unwieldy. This is a little different from IS-IS in that sense. > > > > I am not aware of discussions (if any) that took place during RFC8362 on > this sharing of sub-TLV space. Perhaps the authors of RFC8362 and chairs > can also share their inputs. The other (more cleaner and traditional > approach IMHO) might have been to have separate spaces for each TLV. > > True, the WG could decide to reorganize it to give each type its own space > in its own registry, where the first 32 code points in each space just > happen to be the same. I guess the downside would be, for any sub-TLV > that’s applicable to more than one type, you’d have to do multiple > registrations — but you have to specify applicability for the multiple > types in the unified registry anyway, so it all works out to the same > thing. (I think we did this kind of reorganization for BMP, if I recall > correctly.) > > If the sub-TLV number space were small, there would be a stronger > motivation to reorganize into multiple registries, to conserve space, but > with a 2^16 space it doesn’t seem like a real concern. So AFAICT it comes > down to a matter of taste. > KT> Agree and just to clarify, I don't have anything against the share sub-TLV space that we have currently. > > > In any case, I think we should wait for WG's input before making such > (feature creep) changes. > > Agreed. To raise visibility and hopefully elicit more input, I’ve updated > the subject line and explicitly cc’d Acee (in his capacity as shepherd). > Probably there will be more engagement after the U.S. Labor Day holiday is > over. > KT> Ack. Thanks, Ketan > > —John
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
