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*