Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt
Gyan Mishra <hayabusagsm@gmail.com> Wed, 12 May 2021 05:16 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D713A348C; Tue, 11 May 2021 22:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypurHkZNKV0U; Tue, 11 May 2021 22:15:59 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7903A3488; Tue, 11 May 2021 22:15:58 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id z4so57857pgb.9; Tue, 11 May 2021 22:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F/Q/8LavCqnssh5alfUGMjPGCTGl0K7lujiJrL5Ytyw=; b=nMx7EZAfoK31ZujHYuVbsMuuBHMEWP4AjdxW4GP9NOgqRW/uwjeGiJIYzMvtEFSljm 1bGX5OyNBhK8zvB01YPYlonBg+Nc0VY5tU6GVkGmhDSv7vnRhh9bm95GXLg4dkHBIiYH LrWrY6GtRkS836aAE7YosXcvp9sR6eDptRkKsYhUlYItuiUWxCYWMUVJSyBGBsef++T1 9miWfKus/l+JdzB1MxHwP7eaMSrENxJe0gPcA9eXGuw2TLu/hR0pXeh8F5YTHLDAbSFh ztXrQQm2Y8EMpcruoyU+JBxMeJpMC6V3f/5fXxQrppCS7EgiNDdvob5X5/Q2Cdq9ezms TmLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F/Q/8LavCqnssh5alfUGMjPGCTGl0K7lujiJrL5Ytyw=; b=m4VplHE3qzBwxGIrMNIdG7PjJwxAO2xpl/pIjbCKnoZCaPJVFsNIVMuA5iJcentPgq sx1hDZ6/Il0tYjN0MFmmoo3HcFVc43VXZsU3QxNyQ1IiytMDxfu5a+I8yjLF8XJlcJIO UjU73LQ1QkXoLywM8hACeGDyFjO3+vVF6Jtz8kh2l4YqVrECkhCJvUWCFdvqaoLUmWCr dv91zW6ryOxtcuIMZgqEXZMZn9xNepMwVSqT5lsos4SYMjW6/qbLN1X8udPw+gqEdXqr 5CS+Kz2KzkxK9OOT7NvB0rpsqAXXUpWHm3C1LJve/oT+CGL8JghdcwNs2h9luKk0xBvs JmiA==
X-Gm-Message-State: AOAM532M9qxaoatdFUDHlxqJXQbDOxeB5+GUDp0ZRyS8Z/HJJmDXEj2U uCTgNxSCh2j59u23eg2yUka6miHAf8SX9CWg+r4=
X-Google-Smtp-Source: ABdhPJzgGm+jyxirtEBXNe9m0wA++5woc+yWBoJVepQkO5U1iVnTFljgXcs+3WDd/jWX+mFxVatVeHzo8wsUBMkjUCk=
X-Received: by 2002:a05:6a00:14cc:b029:2cb:cf3b:ce29 with SMTP id w12-20020a056a0014ccb02902cbcf3bce29mr4896293pfu.30.1620796557317; Tue, 11 May 2021 22:15:57 -0700 (PDT)
MIME-Version: 1.0
References: <162002005719.22909.5295741404461810295@ietfa.amsl.com> <MW3PR11MB457029CE737DEEB352095178C15B9@MW3PR11MB4570.namprd11.prod.outlook.com> <CABNhwV0-cnJW=iKiQ6FA2kmur57=S9v6gLcDLSmpZAJoo0=GZQ@mail.gmail.com> <MW3PR11MB4570257F12CF642C49F48CCBC1569@MW3PR11MB4570.namprd11.prod.outlook.com> <CABNhwV1UEHZQXM6eN1x6Cci0KE49Nj5c7U65SmuaGE78g6m9WQ@mail.gmail.com> <MW3PR11MB4570D419033142FF67B1799FC1549@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4570D419033142FF67B1799FC1549@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 12 May 2021 01:15:46 -0400
Message-ID: <CABNhwV2egZ8KAEL8BnmduXY1JDkY1W28qus2DdJK_Jn0a0OfpQ@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Cc: "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000d5be605c21b1b82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VS4VSoTwIcfh-6K5sdQgs64AVgM>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 05:16:05 -0000
Hi Ketan Completely Understand as to your scope as to fix issues and clarification on base specification. I agree with you on seeking guidance from the IDR chairs to move beyond the scope. Responses in-line Kind Regards Gyan On Mon, May 10, 2021 at 2:46 AM Ketan Talaulikar (ketant) <ketant@cisco.com> wrote: > Hi Gyan, > > > > As an editor for this draft on behalf of the WG, I am trying to stick to > the original mandate – i.e. to fix issues and include clarifications > related to the original/base BGP-LS specification (RFC7752). Things that we > have learnt from development and deployment experience. > > > Ack > > IMHO this draft is now very close to completion of that original goal. > > > Ack > > I would like to see specific guidance from the chairs and WG for us to > move beyond that scope to include more text. > > Ack Extensions of BGP-LS are happening all the time with new drafts being > introduced and adopted by the WG. > > > Ack. I think all the more reason to add explicit verbiage that BGP-LS > being a valuable tool can be the base for any new extensions that would > like to use it are not bound to be in the context of traffic engineering. > This will explicitly opens the door for development and more to come. As > we solicit feedback from the WG and chairs if the scope is opened up on > this draft we may want to provide some basic framework of guidance to > developers. > > > Thanks, > > Ketan > > > > *From:* Gyan Mishra <hayabusagsm@gmail.com> > *Sent:* 08 May 2021 12:05 > *To:* Ketan Talaulikar (ketant) <ketant@cisco.com> > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt > > > > Hi Ketan > > > > In-line > > > > Kind Regards > > > > Gyan > > > > On Sat, May 8, 2021 at 1:40 AM Ketan Talaulikar (ketant) <ketant@cisco.com> > wrote: > > Hi Gyan, > > > > Thanks for your review and feedback. > > > > Please check inline below. > > > > *From:* Gyan Mishra <hayabusagsm@gmail.com> > *Sent:* 07 May 2021 21:36 > *To:* Ketan Talaulikar (ketant) <ketant@cisco.com> > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt > > > > Hi Ketan > > > > Thank you for updating the draft and I do like the more appropriate name > change from > > > > “* North-Bound Distribution of Link-State and Traffic Engineering (TE)* > > > > Information Using BGP” > > > > > > *To* > > > > Distribution of Link-State and Traffic Engineering Information Using BGP > > *[KT] Can you please clarify why this change would be required or even appropriate. The bis is to fix some issues and clarify some aspects of the original BGP-LS specification. It does not aim to change the purpose of the extensions.* > > Gyan> Agreed. In the bis update you had the title changed so I was > commenting on that but now I see you are not changing the title and I agree > the original title is more appropriate and correct. > > > > Few comments. > > > > In RFC 7752 where does in mention BGP-LS AFI/SAFI? > > *[KT] > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-06#section-4.2 > <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-06#section-4.2>* > > > > I think it should be added if missing. > > > > Also since the same > > > > 71 > > BGP-LS > > [RFC7752 <https://www.iana.org/go/rfc7752>] > > 72 > > BGP-LS-VPN > > > > Also the SR BGP-LS extension uses the same AFI/SAFI above maybe mentioning > normative reference to the SR BGP-LS extension. > > *[KT] That would be backwards. RFC7752 (and this bis document) is the base > BGP-LS. The SR extensions for BGP-LS has normative reference to the base so > we cannot make a reverse reference. Please clarify if I am missing > something here.* > > Gyan> I see your point and agree > > I think we should add the AFI/SAFI reference to the draft below. > > > > https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16 > > > > Also in the abstract mentions Traffic Engineering referring to RSVP TE and > then in the introduction mentions TEDs. As referring to TE could mean > RSVP-TE or SR maybe in the abstract state RSVP-TE as this specification is > strictly for RSVP-TE. > > *[KT] I am not sure if that is necessary. The specification is about > providing IGP topology database – it does not provide only the subset that > is used by RSVP-TE. Also, the specification does not go into the protocol > extensions for signaling of the TE paths.* > > * Gyan> Understood. As this is the base specification which includes the > BGP-LS extension for IGP topology and TEDS to rebuild TE network graph for > PCE SBI path instantiation, the BGP-LS AFI SAFI base protocol function > can also be used for any other extension as well such as SR, BIER, Enhanced > VPN and future extensions. To your point maybe adding verbiage that this > base specification can be used for any future use cases that don’t > necessarily have to be related to traffic engineering path steering use > cases and can be literally any use case. That does make BGP-LS a very > powerful tool for developers to design other possibilities for BGP-LS as > the base specification allows it.* > > https://tools.ietf.org/html/draft-ietf-bier-bgp-ls-bier-ext-09 > > > > https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-06 > > > > > > *Thanks,* > > *Ketan * > > > > Kind Regards > > > > > > Gyan > > > > On Mon, May 3, 2021 at 1:38 AM Ketan Talaulikar (ketant) <ketant= > 40cisco.com@dmarc.ietf.org> wrote: > > Hi All, > > This is mostly a refresh that also includes fixes for editorial nits in > addition to the following changes related to the IANA considerations: > > 1) Includes updated text from draft-ietf-idr-bgp-ls-registry for the DE > Guidance > 2) Changes the policy from Specifications Required to RFC Required for > some of the flags registries that were missed by RFC7752 > 3) Removes the column for "ISIS TLV/Sub-TLV" from the IANA registry table > for BGP-LS TLVs/Sub-TLVs since only a subset of them have equivalent ISIS > encodings > > Thanks, > Ketan > > -----Original Message----- > From: Idr <idr-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org > Sent: 03 May 2021 11:04 > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Inter-Domain Routing WG of the IETF. > > Title : Distribution of Link-State and Traffic > Engineering Information Using BGP > Author : Ketan Talaulikar > Filename : draft-ietf-idr-rfc7752bis-06.txt > Pages : 63 > Date : 2021-05-02 > > Abstract: > In a number of environments, a component external to a network is > called upon to perform computations based on the network topology and > the current state of the connections within the network, including > Traffic Engineering (TE) information. This is information typically > distributed by IGP routing protocols within the network. > > This document describes a mechanism by which link-state and TE > information can be collected from networks and shared with external > components using the BGP routing protocol. This is achieved using a > new BGP Network Layer Reachability Information (NLRI) encoding > format. The mechanism is applicable to physical and virtual IGP > links. The mechanism described is subject to policy control. > > Applications of this technique include Application-Layer Traffic > Optimization (ALTO) servers and Path Computation Elements (PCEs). > > This document obsoletes RFC 7752 by completely replacing that > document. It makes some small changes and clarifications to the > previous specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-06 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc7752bis-06 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt internet-drafts
- Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-0… Ketan Talaulikar (ketant)
- Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-0… Gyan Mishra
- Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-0… Ketan Talaulikar (ketant)
- Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-0… Gyan Mishra
- Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-0… Ketan Talaulikar (ketant)
- Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-0… Gyan Mishra