[Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

Amanda Baber via RT <iana-prot-param@iana.org> Thu, 02 July 2020 23:55 UTC

Return-Path: <iana-shared@icann.org>
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 9DE273A003E for <lsr@ietfa.amsl.com>; Thu, 2 Jul 2020 16:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqe3sqy8_uqc for <lsr@ietfa.amsl.com>; Thu, 2 Jul 2020 16:55:44 -0700 (PDT)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37FC3A00B0 for <lsr@ietf.org>; Thu, 2 Jul 2020 16:55:44 -0700 (PDT)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id A8919E0AA9; Thu, 2 Jul 2020 23:55:44 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id A560E2019B; Thu, 2 Jul 2020 23:55:44 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <iana-prot-param@iana.org>
Reply-To: iana-prot-param@iana.org
In-Reply-To: <rt-4.4.3-30749-1593699901-48.1173602-37-0@icann.org>
References: <RT-Ticket-1173602@icann.org> <MW3PR11MB457075D951B2EAD4E765BE6DC16F0@MW3PR11MB4570.namprd11.prod.outlook.com> <A1585595-0C7F-4457-B0B0-5B5E3B5F3767@cisco.com> <rt-4.4.3-19904-1593637843-1345.1173602-37-0@icann.org> <6da74fed-96c8-8ac2-697c-d3747ef5c3e4@cisco.com> <MW3PR11MB457052E70A7674E7A94B08F5C16D0@MW3PR11MB4570.namprd11.prod.outlook.com> <3A3F919B-5FBE-4BEB-B0B1-894609A55563@cisco.com> <CAMMESszaPwh-w7nYOwd-we05gnC_JBencTqHsxR6iAqah-FkHA@mail.gmail.com> <0785cce7-018f-37de-4366-22f4bb245127@cisco.com> <rt-4.4.3-30749-1593699901-48.1173602-37-0@icann.org>
Message-ID: <rt-4.4.3-30748-1593734144-1541.1173602-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1173602
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
To: acee@cisco.com
CC: ppsenak@cisco.com, mrajesh@juniper.net, lsr@ietf.org, ketant@cisco.com, gunter.van_de_velde@nokia.com, aretana.ietf@gmail.com, alvaro.retana@futurewei.com, acee=40cisco.com@dmarc.ietf.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 02 Jul 2020 23:55:44 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/vWqGarZwRhWzoyZ0LPERWYYA-kY>
Subject: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 02 Jul 2020 23:55:47 -0000

Gunter, as the remaining LLS Type 1 Extended Options and Flags expert, do you agree with the proposal to move the Flooding Request bit registration to 0x00000020 and assign 0x00000010 to this document?

For both Peter and Gunter: the Flooding Request bit registration is described in the registry as a temporary allocation, but this may have been an mistake The RFC 7120 temporary early allocation procedure is meant for registries that require RFC publication for permanent registration. In theory, if the experts agree, permanent registrations can be made in Expert Review registries at any time. Would there be an issue with removing the "TEMPORARY" designation from that registration?

thanks,
Amanda 

On Thu Jul 02 14:25:01 2020, ppsenak@cisco.com wrote:
> Hi Alvaro,
> 
> On 02/07/2020 16:04, Alvaro Retana wrote:
> > Acee:
> >
> > Can you please get positive confirmation from the authors of
> > draft-ietf-lsr-dynamic-flooding?
> 
> I'm one of them and I can confirm for myself.
> 
> thanks,
> Peter
> 
> 
> >
> > Thanks!
> >
> > Alvaro.
> >
> > On July 2, 2020 at 5:50:06 AM, Acee Lindem (acee)
> > (acee=40cisco.com@dmarc.ietf.org
> > <mailto:acee=40cisco.com@dmarc.ietf.org>) wrote:
> >
> >> Right - the in-progress dynamic flooding implementations are IS-IS
> >> rather than OSPF. I agree that moving the OSPF dynamic flooding is
> >> safter.
> >>
> >> Thanks,
> >> Acee
> >>
> >> On 7/2/20, 3:49 AM, "Ketan Talaulikar (ketant)" <ketant@cisco.com
> >> <mailto:ketant@cisco.com>> wrote:
> >>
> >> +1
> >>
> >> -----Original Message-----
> >> From: Peter Psenak <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
> >> Sent: 02 July 2020 13:11
> >>  To: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com>>;
> >> iana-prot-param@iana.org <mailto:iana-prot-param@iana.org>
> >>  Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Ketan Talaulikar (ketant)
> >>  <ketant@cisco.com <mailto:ketant@cisco.com>>;
> >>  gunter.van_de_velde@nokia.com
> >> <mailto:gunter.van_de_velde@nokia.com>;
> >> alvaro.retana@futurewei.com <mailto:alvaro.retana@futurewei.com>
> >>  Subject: Re: [IANA #1173602] Re: IANA early allocation request for
> >> draft-ietf-lsr-ospf-bfd-strict-mode
> >>
> >> Hi Ketan, Acee,
> >>
> >> On 01/07/2020 23:24, Acee Lindem (acee) wrote:
> >> > Hi Amanda,
> >> >
> >> > On 7/1/20, 5:10 PM, "Amanda Baber via RT" <iana-prot-
> >> > param@iana.org <mailto:iana-prot-param@iana.org>> wrote:
> >> >
> >> > Hi Acee, Alvaro, all,
> >> >
> >> > Alvaro: can you approve the request for early registration of the
> >> > B-bit in the LLS Type 1 Extended Options and Flags registry at
> >> > https://www.iana.org/assignments/ospf-lls-tlvs?
> >> >
> >> > Acee, Ketan: the document says that it's registering 0x00000010,
> >> > but that value was allocated to draft-ietf-lsr-dynamic-flooding
> >> > last year. If Alvaro approves, should we register 0x00000020
> >> > instead?
> >>
> >> I doubt there is any OSPF implementation of
> >> draft-ietf-lsr-dynamic-flooding, so it may be safer to use the
> >> 0x00000010 for draft-ietf-lsr-ospf-bfd-strict-mode and 0x00000020
> >> for
> >> draft-ietf-lsr-dynamic-flooding.
> >>
> >> thanks,
> >> Peter
> >>
> >> >
> >> > Yes. While a few implementations have the BFD strict-mode
> >> > configuration, I don't believe any have shipped the LLS signaling
> >> > yet.
> >> >
> >> > Acee, Ketan, Gunter, Peter: because it's using a different
> >> > registration procedure, I'm creating a separate ticket for the
> >> > Link Local Signalling TLV Identifiers (LLS Types) registration.
> >> > I'll send an expert review request from that ticket.
> >> >
> >> > Fine - Thanks,
> >> > Acee
> >> >
> >> > Best regards,
> >> >
> >> > Amanda Baber
> >> > Lead IANA Services Specialist
> >> >
> >> > On Wed Jul 01 19:38:00 2020, acee@cisco.com
> >> > <mailto:acee@cisco.com> wrote:
> >> > > Hi Ketan, IANA, Alvaro,
> >> > > I don't see any problem with early allocation of this LLS bit
> >> > > and TLV
> >> > > - pretty straight forward. It would make sense to put the
> >> > > respective
> >> > > registries in the IANA section (included below for info).
> >> > >
> >> > > Open Shortest Path First (OSPF) Link Local Signalling (LLS) -
> >> > > Type/Length/Value Identifiers (TLV)
> >> > > Link Local Signalling TLV Identifiers (LLS Types) RFC 5613
> >> > > IETF Review
> >> > > LLS Type 1 Extended Options and Flags RFC 5613
> >> > > Expert Review (Expert: Gunter Van De Velde, Peter Psenak)
> >> > >
> >> > > For the flag, the designated experts are Gunter and Peter
> >> > > (copied).
> >> > >
> >> > > Please initiate the early allocation process pending expert and
> >> > > AD
> >> > > approval.
> >> > > Thanks,
> >> > > Acee
> >> > >
> >> > > On 6/30/20, 4:58 AM, "Ketan Talaulikar (ketant)"
> >> > > <ketant@cisco.com <mailto:ketant@cisco.com>>
> >> > >  wrote: ts
> >> > >
> >> > > Hello Acee/Chris,
> >> > >
> >> > > The authors would like to request IANA early allocations for
> >> > > this
> >> > > draft.
> >> > >
> >> > > Thanks,
> >> > > Ketan (on behalf of co-authors)
> >> > >
> >> > > -----Original Message-----
> >> > > From: Ketan Talaulikar (ketant)
> >> > > Sent: 30 June 2020 14:25
> >> > > To: lsr@ietf.org <mailto:lsr@ietf.org>
> >> > > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-
> >> > > mode-
> >> > > 01.txt
> >> > >
> >> > > Hi All,
> >> > >
> >> > > This is mostly a refresh with editorial updates. We look forward
> >> > > to
> >> > > review and feedback.
> >> > >
> >> > > Thanks,
> >> > > Ketan (on behalf of co-authors)
> >> > >
> >> > > -----Original Message-----
> >> > > From: Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>
> >> > > On Behalf Of
> >> internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> >> > > Sent: 30 June 2020 14:20
> >> > > To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> >> > > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> >> > > Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-
> >> > > 01.txt
> >> > >
> >> > >
> >> > > A New Internet-Draft is available from the on-line Internet-
> >> > > Drafts
> >> > > directories.
> >> > > This draft is a work item of the Link State Routing WG of the
> >> > > IETF.
> >> > >
> >> > > Title : OSPF Strict-Mode for BFD
> >> > > Authors : Ketan Talaulikar
> >> > > Peter Psenak
> >> > > Albert Fu
> >> > > Rajesh M
> >> > > Filename : draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
> >> > > Pages : 10
> >> > > Date : 2020-06-30
> >> > >
> >> > > Abstract:
> >> > > This document specifies the extensions to OSPF that enable an
> >> > > OSPF
> >> > > router to signal the requirement for a Bidirectional Forwarding
> >> > > Detection (BFD) session prior to adjacency formation. Link-Local
> >> > > Signaling (LLS) is used to advertise this requirement of
> >> > > "strict-
> >> > > mode" of BFD session establishment for OSPF adjacency. If both
> >> > > OSPF
> >> > > neighbors advertise the "strict-mode" of BFD, adjacency
> >> > > formation
> >> > > will be blocked until a BFD session has been successfully
> >> > > established.
> >> > >
> >> > >
> >> > > The IETF datatracker status page for this draft is:
> >> > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-
> >> > > mode/
> >> > >
> >> > > There are also htmlized versions available at:
> >> > > https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-
> >> > > 01
> >> > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-
> >> > > strict-
> >> > > mode-01
> >> > >
> >> > > A diff from the previous version is available at:
> >> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-
> >> > > strict-mode-
> >> > > 01
> >> > >
> >> > >
> >> > > Please note that it may take a couple of minutes from the time
> >> > > of
> >> > > submission until the htmlized version and diff are available at
> >> > > tools.ietf.org <http://tools.ietf.org>.
> >> > >
> >> > > Internet-Drafts are also available by anonymous FTP at:
> >> > > ftp://ftp.ietf.org/internet-drafts/
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Lsr mailing list
> >> > > Lsr@ietf.org <mailto:Lsr@ietf.org>
> >> > > https://www.ietf.org/mailman/listinfo/lsr
> >> > >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> _______________________________________________
> >> Lsr mailing list
> >> Lsr@ietf.org <mailto:Lsr@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/lsr