Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi All,

The update has been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-10

Thanks,
Ketan


On Fri, Oct 7, 2022 at 2:21 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi All,
>
> Following is the updated text proposal for the part of the IANA section
> under discussion:
>
>    IANA is requested to introduce a column "Applicability to L2 Bundle
>    Member sub-TLV" (abbreviated as L2BM) in the registry tables for the
>    "OSPFv2 Extended Link TLV Sub-TLVs" registry with the initial updates
>    (Y/N) against allocations as indicated in Figure 2.  An explanatory
>    note is also to be added to this registry as follows:
>
>      The column for the Applicability to L2 Bundle Member sub-TLV (L2BM)
>      may be marked as follows:
>
>      Y - sub-TLV may appear in L2 Bundle Member sub-TLV
>      N - sub-TLV MUST NOT appear in L2 Bundle Member sub-TLV
>
>    Similarly, IANA is requested to introduce a column "Applicability to
>    L2 Bundle Member sub-TLV" (abbreviated as L2BM) in the registry
>    tables for the "OSPFv3 Extended LSA Sub-TLVs" registry with the
>    initial updates (Y/N/X) against allocations as indicated in Figure 3.
>
>      The column for the Applicability to L2 Bundle Member sub-TLV (L2BM)
>      may be marked as follows:
>
>      Y - sub-TLV may appear in L2 Bundle Member sub-TLV
>      N - sub-TLV MUST NOT appear in L2 Bundle Member sub-TLV
>      X - sub-TLV is not a Router Link sub-TLV; it MUST NOT appear
>          in L2 Bundle Member sub-TLV
>
>    Further allocations from these two registries are required to
>    indicate the applicability of the introduced sub-TLV to the L2 Bundle
>    Member sub-TLV that would get updated in these registries.
>
> Planning to post this update unless there are any concerns/suggestions and
> also once I get confirmation from IANA that this is OK with them.
>
> Thanks,
> Ketan
>
>
> On Fri, Oct 7, 2022 at 1:44 AM John Scudder <[e-mail]> wrote:
>
>> [posting to keep the WG in the loop]
>>
>> Hi Ketan,
>>
>> As discussed in the parallel thread with Amanda @ IANA, this looks good,
>> except that it would be a good idea to supply specific text for IANA to use
>> as an annotation on the registry. Amanda pointed to the Note on
>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information
>> as an example of how to write it.
>>
>> Thanks,
>>
>> —John
>>
>> > On Oct 6, 2022, at 10:46 AM, Ketan Talaulikar <[e-mail]>
>> wrote:
>> >
>> >
>> > [External Email. Be cautious of content]
>> >
>> >
>> > Hi John,
>> >
>> > We've posted an update of the draft with the changes as per option 1
>> below:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-09
>> >
>> > Please let us know if there are any other concerns. Will also let the
>> IANA team know of this update on the parallel thread so they can also
>> check/review the same.
>> >
>> > Thanks,
>> > Ketan
>> >
>> >
>> > On Thu, Oct 6, 2022 at 6:37 PM John Scudder <[e-mail]> wrote:
>> > Hi Ketan,
>> >
>> > Thanks for the analysis. A few comments below.
>> >
>> > > On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar <[e-mail]>
>> wrote:
>> > >
>> > > Hi John/Lars,
>> > >
>> > > I hope this topic can be discussed in the upcoming telechat to
>> conclude on the option to be adopted.
>> > >
>> > > To make it easier, let me provide a pointer to the text for each
>> inline below. I am not sure that I understand option 3 very well.
>> > >
>> > >
>> > > On Wed, Oct 5, 2022 at 9:42 PM John Scudder <[e-mail]> wrote:
>> > > Hi All,
>> > >
>> > > (To keep everyone in the loop since you weren’t all on the cc of the
>> IANA review email.)
>> > >
>> > > Amanda Baber at IANA pointed out that the added paragraph is a
>> problem for IANA since it’s too imprecise for IANA to carry out. The
>> options come down to:
>> > >
>> > > 1. Revisit the WG decision, and add a field to the registry for the
>> “Y/N” annotations that relate to this spec.
>> > >
>> > > KT> This was
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-05#section-3
>> > >
>> > >    IANA is requested to introduce a column "Applicability to L2 Bundle
>> > >    Member TLV" in the registry tables for the "OSPFv2 Extended Link
>> TLV
>> > >    Sub-TLVs" registry with the initial updates (Y/N) against
>> allocations
>> > >    as indicated in Figure 2.  Similarly, IANA is requested to
>> introduce
>> > >    a column "Applicability to L2 Bundle Member TLV" in the registry
>> > >    tables for the "OSPFv3 Extended LSA Sub-TLVs" registry with the
>> > >    initial updates (Y/N/X) against allocations as indicated in Figure
>> 3.
>> > >    Further allocations from these two registries are expected to
>> > >    indicate the applicability of the introduced sub-TLV to the L2
>> Bundle
>> > >    Member TLV that would get updated in these registries.
>> >
>> > Thanks. As mentioned earlier, this is my preferred option — the more so
>> after looking through your analysis. I think all the gyrations after
>> version 05 have demonstrated amply that “perfect is the enemy of good”.
>> >
>> > > 2. Change the policy to something like "IETF Review (Additional
>> Expert Review Required) or IESG Approval" and include advice to the experts
>> in the document. (Thanks to Amanda for this suggestion.)
>> > >
>> > > KT> This is a "quick" tweak on
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-08#section-4
>> as follows:
>> > >
>> > >    This document updates the guidance to IANA for further allocations
>> > >    from the "OSPFv2 Extended Link TLV Sub-TLVs" and the "OSPFv3
>> Extended
>> > >    LSA Sub-TLVs" registries to "IETF Review (Additional Expert Review
>> > >
>> > >    Required)" [RFC8126] and requests the addition of this document
>> > >    as a reference to those registries.  It requires that the
>> designated
>> > >
>> > >    expert appointed by IESG verify that any document
>> > >    requesting allocation of code point from these two registries needs
>> > >    to specify the applicability of the introduced sub-TLV to the L2
>> > >    Bundle Member TLV in a manner similar to Figure 2 and Figure 3 that
>> > >    cover existing allocations up to the point of publication of this
>> > >    document.
>> >
>> > That looks right. As previously mentioned I don’t see benefit to
>> choosing this option instead of (1) — all cost, no additional benefit.
>> >
>> > > 3. Move the “it requires” text out of the IANA considerations and
>> into a more appropriate section, and don’t try to put a gatekeeper into the
>> registry (yet).
>> > >
>> > > KT> I am not sure what this option involves. Putting this document as
>> a reference but no IANA actions or gatekeeper seems odd to me. Isn't this
>> option - "do nothing" - which is the state in which this draft came out of
>> the WG and AD review?
>> >
>> > Yes indeed, I guess I only mentioned it for completeness. It would
>> resolve IANA’s concerns but wouldn’t satisfy Lars’s DISCUSS, so I think we
>> can take this off the table.
>> >
>> > —John
>> >
>> > > What came out of the WG:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-04#section-3
>> also same as at the end of John's AD review:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-06#section-3
>> > >
>> > > Thanks,
>> > > Ketan
>> > >
>> > >
>> > > I think either option 1 or option 2 would be fine insofar as
>> resolving Lars (et al)’s concern. Option 3 would amount to returning to the
>> previous plan of record, which was to ship the spec without a registry
>> gatekeeper but ask the WG to produce a registry reorg that does so in a
>> more comprehensive way.
>> > >
>> > > Of these plans, I’m least enthusiastic about option 2 since it would
>> require us to appoint and instruct an expert reviewer, for what I hope will
>> be a short-lived function. That implies — to me — that option 1 is the
>> least bad way of breaking the deadlock.
>> > >
>> > > Until we resolve this the draft will be stuck in “IANA NOT OK”.
>> > >
>> > > —John
>> > >
>> > > > Hi Lars,
>> > > >
>> > > > Thanks for your confirmation.
>> > > >
>> > > > Acee/John, I haven't received any response (objection or support)
>> from the WG on this change. I believe this may be a good interim step until
>> the WG considers any IANA registry reorganization. Can you please share
>> your views as shepherd and AD respectively?
>> > > >
>> > > > Thanks,
>> > > > Ketan
>> > > >
>> > > >
>> > > > On Mon, Oct 3, 2022 at 6:31 PM Lars Eggert <[e-mail]> wrote:
>> > > > Hi,
>> > > >
>> > > > On 2022-9-30, at 16:37, Ketan Talaulikar <[e-mail]>
>> wrote:
>> > > > > In brief, the proposal was to introduce the following text in the
>> IANA considerations:
>> > > > >
>> > > > > <NEW>
>> > > > >    This document updates the guidance to IANA for further
>> allocations
>> > > > >    from the "OSPFv2 Extended Link TLV Sub-TLVs" [1] and the
>> > > > >    "OSPFv3 Extended LSA Sub-TLVs" [2] registries and requests the
>> addition
>> > > > >    of this document as a reference to those registries. It
>> requires
>> > > > >    that any document requesting allocation of code point from
>> these
>> > > > >    two registries need to indicate the applicability of the
>> introduced
>> > > > >    sub-TLV to the L2 Bundle Member TLV in that document.
>> > > >
>> > > > something along those lines would work for me.
>> > > >
>> > > > Thanks,
>> > > > Lars
>> > > >
>> > > >
>> > >
>> >
>>
>>