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

From: Gyan Mishra <[email-masked]>
Date: Sun, 18 Oct 2020 03:07:20 -0400

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 *Silver Spring, MD

---

From: <[email-masked]>
Date: Tue, 20 Oct 2020 10:54:13 +0800 (CST)

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;[email-masked];
日 期 ：2020年10月18日 15:08
主 题 ：Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07

Dear Authors,

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.

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.

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

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 20 Oct 2020 00:07:49 -0400

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 <[email-masked]> wrote:

> According to RFC7752, the base usage of BGP-LS, is the domain information
> collection done by BGP-LS, so it with BIER as well.
>
> *发件人：*GyanMishra
> *收件人：*BIER WG;BIER WG Chairs;[email-masked];
> *日 期 ：*2020年10月18日 15:08
> *主 题 ：**Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07*
>
>
> Dear Authors,
>
> 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.
>
> 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
> *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>
>
>
> --

*Gyan Mishra*

---

From: <[email-masked]>
Date: Tue, 20 Oct 2020 15:13:49 +0800 (CST)

Hi Gyan,

thank you for your suggestion!

Please find my answer inline with Sandy>.

Thanks,

Sandy

原始邮件

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

Hi Sandy

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.

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. 

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 <[email-masked]> wrote:

> This BGP-LS extension is used for information collection in a BIER domain

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 20 Oct 2020 12:20:47 -0400

Hi Sandy

Please let me know if you are going to revise the draft and make any
updates from my suggestions, and then I can wait for that update and then
finalize my Shepherd write-up.

Kind Regards

Gyan
On Tue, Oct 20, 2020 at 3:13 AM <[email-masked]> wrote:

> *收件人：*张征00007940;
> *抄送人：[email-masked];[email-masked];
> [email-masked];
> *日 期 ：*2020年10月20日 12:08
> *主 题 ：**Re: Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07*
> Hi Sandy
>

*Gyan Mishra*

---

From: <[email-masked]>
Date: Wed, 21 Oct 2020 10:01:57 +0800 (CST)

Hi Gyan,

Ran will consider your suggestion and make some changes.

Thank you for your suggestion!

Thanks,

Sandy

原始邮件

发件人：GyanMishra
收件人：张征00007940;
日 期 ：2020年10月21日 00:21

Hi Sandy 

Please let me know if you are going to revise the draft and make any updates from my suggestions, and then I can wait for that update and then finalize my Shepherd write-up.

Kind Regards 

Gyan

Hi Gyan,

Thanks,

Sandy

原始邮件

发件人：GyanMishra
收件人：张征00007940;

Hi Sandy

network administrator.

Kind Regards

Gyan

-- 

Gyan Mishra

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

---

From: <[email-masked]>
Date: Wed, 21 Oct 2020 16:52:08 +0800 (CST)

Hi Gyan,

Thank you very much for your valuable comments, we will update it as soon as possible.

Best Regards,

Ran

原始邮件

发件人：张征00007940
收件人：[email-masked];陈然00080434;
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2020年10月21日 10:02
主 题 ：Re: [Bier] Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

Hi Gyan,

Thanks,

Sandy

发件人：GyanMishra
收件人：张征00007940;

Hi Sandy 

Kind Regards 

Gyan

Hi Gyan,

Thanks,

Sandy

原始邮件

发件人：GyanMishra
收件人：张征00007940;

Hi Sandy

network administrator.

Kind Regards

Gyan

-- 

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 22 Oct 2020 19:23:53 -0400

Hi Ran

Thank you

Will look out for the update.

Kind Regards

Gyan

On Wed, Oct 21, 2020 at 4:52 AM <[email-masked]> wrote:

> *发件人：*张征00007940
> *收件人：[email-masked];陈然00080434;
> *抄送人：[email-masked];[email-masked];
> [email-masked];
> *日 期 ：*2020年10月21日 10:02
> *主 题 ：**Re: [Bier] Shepherd’s review of
> draft-ietf-bier-bgp-ls-bier-ext-07*
> *日 期 ：*2020年10月21日 00:21

-- 

*Gyan Mishra*

---

From: <[email-masked]>
Date: Fri, 30 Oct 2020 13:59:17 +0800 (CST)

Hi Gyan， Chairs and WG,

We have updated the draft based on the Gyran's comments.The link is https://datatracker.ietf.org/doc/draft-ietf-bier-bgp-ls-bier-ext/. Please check it and see if it is OK.

Any comments are welcome.

Best Regards.

Ran

原始邮件

发件人：陈然00080434
收件人：[email-masked];
抄送人：[email-masked];[email-masked];[email-masked];
日 期 ：2020年10月21日 16:52
主 题 ：Re: [Bier] Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07

Hi Gyan,

Best Regards,

Ran

发件人：张征00007940

Hi Gyan,

Thanks,

Sandy

发件人：GyanMishra
收件人：张征00007940;

Hi Sandy 

Kind Regards 

Gyan

Hi Gyan,

Thanks,

Sandy

原始邮件

发件人：GyanMishra
收件人：张征00007940;

Hi Sandy

network administrator.

Kind Regards

Gyan

-- 

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 30 Oct 2020 12:50:33 -0400

Hi Ran

I reviewed the update and it looks perfect.

Thank you

Gyan

On Fri, Oct 30, 2020 at 1:59 AM <[email-masked]> wrote:

> Hi Gyan， Chairs and WG,
>
> We have updated the draft based on the Gyran's comments.The link is
> <https://datatracker.ietf.org/doc/draft-ietf-bier-bgp-ls-bier-ext/>
> https://datatracker.ietf.org/doc/draft-ietf-bier-bgp-ls-bier-ext/. Please
> check it and see if it is OK.
>
> *发件人：*陈然00080434
> *收件人：[email-masked];
> *日 期 ：*2020年10月21日 16:52

*Gyan Mishra*