Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)
Ketan Talaulikar <ketant.ietf@gmail.com> Fri, 07 October 2022 08:52 UTC
Return-Path: <ketant.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D581EC14CE2C; Fri, 7 Oct 2022 01:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7jSxmi8u8o7; Fri, 7 Oct 2022 01:52:02 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1206C14CF16; Fri, 7 Oct 2022 01:52:02 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id d187so4369576vsd.6; Fri, 07 Oct 2022 01:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4Q0EVP+WWX46gsjk+x+OZqyt0dYwGaQad2Nd1+yMpM4=; b=m7Vp/xC0M5zKJ+Dth264QxzzkGiS+CW+GgBf9PrvZ8/ZQfo5BSC3J5AycRAwzQxHbH 6fE4DnYapXyMdxSmh1Rxp5PAx1dBwW/ffXHchHH4a6Ug9GMWxw/WJMXT3W8KVqw48ljb 6UYbdisjsBq9RHiL4JU2PzE89cRNETj31gGU76TlOYZmrhLFymkm+rN7v1D3d2pjvPfm W7C+G/IO3G2MVSwEgX3CusIlxeCU3VaAg6G6lyh4h3nEUbQHjz8VFRdexPFkVldKqysq QHrYVMyXJtwu4g3+BJ7mc50yBn5SzHCYfnSMp4GRYlR6Gn/kL6JUJ6MU4Sd9YSdwbmK7 hfBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4Q0EVP+WWX46gsjk+x+OZqyt0dYwGaQad2Nd1+yMpM4=; b=3oA3kx1eQnkaEBLfPSuUxLkRpQ2tjWtGK4CeeUI+MnR45LCrCsmj8GyO/9RUPGo++A Ii1/umFvz5+3FL+0VZEKp+kxaZioQfwAUZApOz0fPjLYrtYY5JPQTT9FImB/ecBYUiKP 793Qt6LMAZYUQ9kNs0SrfyrDNtLg2kF5x07ThFvTbrllUt5oNuWXqpiiwwh8VaW2j19f 49oo9Dz89iHpQ+TBZCz+9MamPt30BT2vgjM+M7xckpbhBnGBsTe5Mu/53FdVoEebWHyt E7OP0w467i9rpkMhxBTu1gEPx/0CbcIYEmeRjQKg8UoiOQ40CDhzLc9PtkI3S/aGXSvo M+Aw==
X-Gm-Message-State: ACrzQf38YA/fUZzdaYbukQWEHiBKdWx3xO6oKF8PIuBR4kfY/a9sY0+8 QVLCOYNk9tPGWiuJQz3CwZomCsoMhPjMzYBvokc=
X-Google-Smtp-Source: AMsMyM5mncfeMssKRMRUv6D5fBseqbRlz6XR1n7D9K0mWg6UdEgcpT6Wb84bVjDyTG785OGcIJ58d/ZnlQgREViC1Es=
X-Received: by 2002:a05:6102:304e:b0:398:c21f:cbaa with SMTP id w14-20020a056102304e00b00398c21fcbaamr2271978vsa.33.1665132721373; Fri, 07 Oct 2022 01:52:01 -0700 (PDT)
MIME-Version: 1.0
References: <166454386910.57862.16318198402251605185@ietfa.amsl.com> <CAH6gdPzWBbmAVDW_zEdQQjAjh5O3CoTBbd-pZXc5KfWBH0-0Nw@mail.gmail.com> <D953525F-4C3D-4019-B125-601D10E068D5@eggert.org> <CAH6gdPzRdOtxWuWOZU--mNsJAiiwAp65NxeAJiD06VUTpZbYGQ@mail.gmail.com> <6D6A555F-C338-441B-9959-C76D2E82A638@juniper.net> <CAH6gdPzqACDBMnDHURn_DU3bbEaMBdnQZ1CGeGxbZHaK0pa8oA@mail.gmail.com> <67F54DF4-DAF0-4F48-A206-800544A63468@juniper.net> <CAH6gdPzVcUwwRzFPmuQSuHsuy1pUM0bTutpSYKoeC7SGzFT1gg@mail.gmail.com> <D9A21586-DAE6-4B7D-A25A-DC998B5D769C@juniper.net>
In-Reply-To: <D9A21586-DAE6-4B7D-A25A-DC998B5D769C@juniper.net>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Fri, 07 Oct 2022 14:21:48 +0530
Message-ID: <CAH6gdPzQBW2uUkNdhSb74bLGKZ+vhpd1zC2fCA3Frhev=sTgYA@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>, "draft-ietf-lsr-ospf-l2bundles@ietf.org" <draft-ietf-lsr-ospf-l2bundles@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, lsr <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>, "acee@cisco.com" <acee@cisco.com>
Content-Type: multipart/alternative; boundary="0000000000005c881505ea6decb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/QyGTwz1KDtBgbHl4oa-2N831030>
Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2022 08:52:06 -0000
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 <jgs@juniper.net> 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 <ketant.ietf@gmail.com> > 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 <jgs@juniper.net> wrote: > > Hi Ketan, > > > > Thanks for the analysis. A few comments below. > > > > > On Oct 6, 2022, at 8:30 AM, Ketan Talaulikar <ketant.ietf@gmail.com> > 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 <jgs@juniper.net> 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 <lars@eggert.org> wrote: > > > > Hi, > > > > > > > > On 2022-9-30, at 16:37, Ketan Talaulikar <ketant.ietf@gmail.com> > 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 > > > > > > > > > > > > > > >
- [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-osp… Lars Eggert via Datatracker
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Lars Eggert
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Acee Lindem (acee)
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Lars Eggert
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… John Scudder
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar
- Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr… Ketan Talaulikar