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

["Acee Lindem (acee)" <[e-mail]>]

Hi Ketan, John,

First of all, I think this IANA OSPFv3 Extended-LSA Sub-TLV specification, if it is to be done at all, should be done in a separate draft.

When we originally created the registry for RFC 8362, the purpose was avoid Sub-TLV code point collisions while affording maximum reuse of Sub-TLV definitions. It was NOT to avoid reading the specifications in order to determine everywhere a Sub-TLV is allowed. In fact, I don’t believe IS-IS had yet adopted this IANA practice when this became a WG document in 2007. OSPFv3 Extended LSAs took some time to standardize as we held it until there were implementations and there weren’t implementations until Segment Routing offered a strong incentive.

If this information is to be represented in the IANA registry, I’d stay away from columns with Y’s and N’s. Note that Sub-TLVs can nested so conceivably a given Sub-TLV could be used by other Sub-TLVs. Rather, one could list the Sub-TLVs with the individual usages and references (if different from the creation reference) as sub-bullets.

Thanks,
Acee



From: Ketan Talaulikar <[e-mail]>
Date: Monday, September 5, 2022 at 11:26 AM
To: John Scudder <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Acee Lindem <[e-mail]>
Subject: Re: Reorganizing OSPFv3 Extended-LSA Sub-TLVs registry [was: Re: AD review of draft-ietf-lsr-ospf-l2bundles-04]

Hi John,

Please check inline below with KT for a quick clarification.


On Mon, Sep 5, 2022 at 8:39 PM John Scudder <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan,

Seems like a good plan. Comments below.

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

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