Re: [Lsr] AD review of draft-ietf-lsr-ospf-l2bundles-04

[Ketan Talaulikar <[e-mail]>]

Hi John,

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.

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.

In any case, I think we should wait for WG's input before making such
(feature creep) changes.

Thanks,
Ketan


On Sat, Sep 3, 2022 at 11:41 PM John Scudder <[e-mail]> wrote:

> > On Sep 3, 2022, at 4:46 AM, Ketan Talaulikar <[e-mail]>
> 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 <[e-mail]> wrote:
> > Hi Ketan,
> >
> > Thanks for the update.
> >
> > > On Sep 2, 2022, at 9:16 AM, Ketan Talaulikar <[e-mail]>
> 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
>
>