Re: [Idr] I-D Action: draft-ietf-idr-rfc7752bis-06.txt

Gyan Mishra <hayabusagsm@gmail.com> Sat, 08 May 2021 06:35 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 CA6133A4018 for <idr@ietfa.amsl.com>; Fri, 7 May 2021 23:35: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 l-BG2MP_GAEW for <idr@ietfa.amsl.com>; Fri, 7 May 2021 23:35:00 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 F36EB3A4016 for <idr@ietf.org>; Fri, 7 May 2021 23:34:59 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id i5so4202624pgm.0 for <idr@ietf.org>; Fri, 07 May 2021 23:34:59 -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=gN7QhQ36KbVRuknqv9XJYVW9HbYCRv2KArXcxnLxgCg=; b=I6KBvxtpVIbXSvhJao77yp7kW/99+bCjw16RY1GpzHv78+jYg6y+MZdsCsAp8yIvv3 HNCixMZGA725Ix835Z9kOST3IG7LdJlzd6agxcKYP7OfdmCeiLl8KIO9Va984wYK01dZ 05/FhrsKrR+r5wKa/a8JTJQprRjfZx2up7sv9lgX/LGbBWhY4DUGR13focV8zEGByrP7 hr2c7NB8pEazPl4hv04+xJ0p0OBTv5VyyIX+2a3AG16zWKdt3V2jANlveujjWivU84c2 NQLKwd9lzO+99OtFzwCNJNtCR2hrbMZNmahBsVznj9C6UuTgnZX9EjO8KzpLzZoud7xt 5HNA==
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=gN7QhQ36KbVRuknqv9XJYVW9HbYCRv2KArXcxnLxgCg=; b=heH9hzcoQHKPcgwuc/5elIFVTjF/N+VymgxTVEpnD7HlE7ZNCdFShWFzThAOFXu+HS l5wVAiecizfdODtGIh4MnwaJWzeDWAIxodflgZg3e0HIkmMnMg6bMDmobsmiStlxztQN kPpZWE8s4AYc1mX+VzxLDNBK6SxhGlHcqDFb9qgHAQcUny3sC6qTNir0GLuxENh80Z2w 4cEdcqa9ndCdv8FZQS8As10sga4PXQH7ljSAC0QIi1WE5W5fVJlc0b5n3h38oKQcAaUe RBygeIzyMwO5feopcmcl94x3E+4bt42xkptbIs6hSc1+0dui5jlnZk+2ajtIpl2MPOFv Qgwg==
X-Gm-Message-State: AOAM531w8PnMtGSBiRj1lMpA98aVQq5Dl2+Lvkj1+G86it01m2zcXZPi /0UYIOmmrVgSBg4ZhBlaZfURm4wV2pL+wIra5OA=
X-Google-Smtp-Source: ABdhPJy3159Ddgsl97CJga57S451CTRex3y1+4FOr3nLCcDGLCB6TJtAW6e07fB/Sf74A66nH54UYIXfYQWGjeL11go=
X-Received: by 2002:a65:68d5:: with SMTP id k21mr8059990pgt.383.1620455698418; Fri, 07 May 2021 23:34:58 -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>
In-Reply-To: <MW3PR11MB4570257F12CF642C49F48CCBC1569@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 8 May 2021 02:34:47 -0400
Message-ID: <CABNhwV1UEHZQXM6eN1x6Cci0KE49Nj5c7U65SmuaGE78g6m9WQ@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000474e2e05c1cbbe9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QEWYiXFuABCZ9xKubpVv5Kskvys>
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: Sat, 08 May 2021 06:35:05 -0000

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 A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*