[Lsr] Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

[John Scudder <[e-mail]>]

Hi Ketan,

Seems like a good plan. Comments below.

> On Sep 5, 2022, at 3:31 AM, Ketan Talaulikar <[e-mail]> 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. 

> 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.

> 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.

—John