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

[[e-mail]]

Hi Gyan,


thank you for your suggestion!


Please find my answer inline with Sandy>.


Thanks,


Sandy





原始邮件



发件人：GyanMishra
收件人：张征00007940;
抄送人：[e-mail];[e-mail];[e-mail];
日 期 ：2020年10月20日 12:08
主 题 ：Re: Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07




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.

Sandy> As you found, the BFR prefix is sent as BGP prefix, because BIER 

info is used as sub-TLV or sub-sub-TLV of IGP protocols, the BGP-LS 

advertisement is the same with BIER. The reason can be added in introduction, 

but may not be many sentences, how to use it is depended on the 

network administrator.


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.

Sandy> BGP-LS is used for topology collection, and the existed collection 

does not include BIER information, one of the usecase is the controller 

decide the BFERs for a specific multicast flow. 


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.

Sandy> Yes, you are right. The information can also be got by NMS netconf 

or YANG data model. They provide different methods for network administrator.


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