Re: [Bier] Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07

[Gyan Mishra <[e-mail]>]

Hi Sandy

Do you think it would be worthwhile to mention the reasons for collection
maybe in the introduction.  I think it would be helpful such as inter-as
provisioning or any other reason but I really think that should be stated.
I understand that according to RFC 7752 is for collection of IGP topology
information of active or passive path instantiation for RSVP TE or SR-TE.
Here we are not doing any traffic engineering steering although BIER
behavior is similar to SR source routing.  So here you have new BIER
specific TLV code points being provisioned by taking the RFC 7752 prefix
attribute TLV to create three new BIER specific TLVs, BIER information,
BIER MPLS Encapsulation, BIER Ethernet Encapsulation.  Since the BIER
specifics have nothing to do with TE attributes prefix TLV you really could
have chosen of the three, node attribute TLV, link attribute TLV or prefix
attribute TLV.  Was their any reason why you chose prefix TLV over the
other two to populate the bier specifics.  I noticed that the BFR prefix
provisioning to each BFR is not in the any of the three new prefix TLVs
provisioned.

All the BGP-LS TLV code points provisioned to date are IGP LSDB related
topology information to rebuild the RSVP TEDs database or SR topology on a
Northbound PCE for active or passive path instantiation or TE or SR-TE
steered paths.

https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml


Can you give an example of an application that requires topology visibility
that cannot be satisfied natively without having to export the topology to
a controller. Is it maybe a ODL or Openflow or other 3rd party controller
use for NMS functions.

If it’s just data that is being gathered as this is BIER specific couldn’t
you gather via NMS netconf / Yang data model for proactive monitoring of
the BIER domain.  If the controller is not taking action or not doing any
provisioning and just passive monitoring then I think NMS functionality can
be accomplished by other means other than BGP-LS.

Kind Regards

Gyan

On Mon, Oct 19, 2020 at 10:54 PM <[e-mail]> wrote:

> Hi Gyan,
>
> thank you very much for your comments!
>
> As co-author of this draft, I'd like to answer your question.
>
> This BGP-LS extension is used for information collection in a BIER domain.
>
> It may be used for inter-AS BGP peering, but it mainly is used in a domain.
>
> According to RFC7752, the base usage of BGP-LS, is the domain information
> collection done by BGP-LS, so it with BIER as well.
>
> The controller can get the BFR-id and other BIER relative information
> through this extension.
>
> Best regards,
>
> Sandy
> 原始邮件
> *发件人：*GyanMishra
> *收件人：*BIER WG;BIER WG Chairs;[e-mail];
> *日 期 ：*2020年10月18日 15:08
> *主 题 ：**Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07*
>
>
> Dear Authors,
>
> Thank you for a well-written succinct document.
>
> I have a few  comments and questions on the use of BGP-LS extension and
> why it is necessary for BIER and what gap that exists that is being
> addressed by this extension.
>
> What is broken today?
>
> The abstract and introduction describes how BIER works which anyone
> reading the draft can read normative references RFC 8279 and RFC 8296.
>
> The last sentence says the following:
>
> This document specifies extensions the BGP Link-state address-family in order to advertise BIER information.
>
>
> The last sentence in the introductionstates the following:
>
>
> In order to satisfy the need for applications that require topological visibility across one area or Autonomou
>
> System (AS).  This document specifiesextensions to the BGP Link-state address-family in order to advertise BIER-specific.  An external component
> (e.g., a controller) then can collect BIER information in the "northbound"
>
> direction within the BIER domain.
>
>
> Section 3 goes on to describe how this new BGP-LS extension for BIER will
> be able to gather the BIER specific topology information and send
> Northbound to an external controller which will then build rebuild a
> topological graph of the BIER domain or multiple domains for multicast
> “applications” that won’t work for without this extension.
>
> I think in the draft it is important to note the gap that exists today
> without this draft and clearly what is broken that is being fixed by the
> draft.
>
> That should be spelled out clearly in the Introduction as well as stated
> briefly in the abstract.
>
> Inter-AS BIER trees can be built without a controller and this BGP-LS
> extension, similar to today inter-as MVPN mLDP PE P2MP TE stateful
> segmented or end to end LSP trees.
>
> I think we need to expand more on the application visibility and what
> applications I am guessing ASM, SSM trees over BIER inter-as, but I still
> don’t understand the gap as what won’t work with multicast applications
> today without this BGP-LS extension for BIER.
>
> Please help me understand.
>
> Also could BIER BGP-LS extension also be used for BIER inter-as
> provisioning of stateless tree?
>
>   So possibly be used for instantiation of all inter-as stateless trees
> based on the topological graph.  As the BIER trees are stateless in a way
> you could pre build all X-PMSI trees set the BFR bitmask for all egress PEs
> ahead of time provision inter-as from BFIR ingress domain to BFER egress
> domain.
>
> There maybe other use cases or reasons for BGP-LS usage by BIER but I
> think provisioning could be one of them.
>
> Once I have received feedback on the comments I will compile the Feedback
> and complete the Shepherds write-up.
>
> Kind Regards
>
>
> Gyan
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD