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

["Ketan Talaulikar (ketant)" <[e-mail]>]

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.

IMHO this draft is now very close to completion of that original goal.

I would like to see specific guidance from the chairs and WG for us to move beyond that scope to include more text. Extensions of BGP-LS are happening all the time with new drafts being introduced and adopted by the WG.

Thanks,
Ketan

From: Gyan Mishra <[e-mail]>
Sent: 08 May 2021 12:05
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: [e-mail]
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) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

Thanks for your review and feedback.

Please check inline below.

From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: 07 May 2021 21:36
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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

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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 03 May 2021 11:04
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347