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

[Ketan Talaulikar <[e-mail]>]

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]> wrote:

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


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