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

[[e-mail]]

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 AutonomouSystem (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

-- 













Gyan Mishra


Network Solutions Architect 


M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD