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

[Gyan Mishra <[e-mail]>]

Dear Authors,

I have completed the Shepherd write-up.  The document is ready for
publication with some nits below.  Once cleaned up I believe we will be
ready for publication.

Attached is the idnits output. Please correct and update the draft and then
I will update the Shephard write-up to reflect update.

Have the 3 BGP LS IANA codepoints been requested?   I don't see them listed
yet on the IANA BGP-LS link below. Let me know once requested and the IANA
page has been updated and I will update the Shepherd writeup.

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

This draft under normative references is expired and noted in the Shepherd
writuep.  Please find the status of the reference and if necessary please
get it back on track or remove.

https://datatracker.ietf.org/doc/draft-ietf-bier-lsr-ethernet-extensions/

I believe RFC 4271 & 4272 should be made informative references as they are
not normative to understand the draft.  Also remove RFC 6952 & 3631
completely unrelated to this draft.

I would reference as normative RFC 8571 as that pertains to BGP-LS original
Day 1 original use case for RSVP TE link attribute
TE path computation as to why BGP-LS came into existence - as now BIER use
case would fall into new categorical use case for BGP-LS now being used to
gather BIER IGP extension information via BGP-LS to northbound to
PCE/Controller.

I think PCE arch should be referenced as PCE is noted in the introduction
as the PCE or any centralized controller for BIER  provisioning.
https://datatracker.ietf.org/wg/pce/documents/

I would add PECE WG RFCs RFC 4655 PCE architecture as normative and that
should be enough and reference in the draft where PCE is mentioned.  Then I
would add as informative RFC 5440 & 5376.

Thank you

Gyan



On Fri, Oct 30, 2020 at 12:50 PM Gyan Mishra <[e-mail]> wrote:

>
> Hi Ran
>
> I reviewed the update and it looks perfect.
>
> Thank you
>
> Gyan
>
> On Fri, Oct 30, 2020 at 1:59 AM <[e-mail]> 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.
>>
>> Any comments are welcome.
>>
>>
>> Best Regards.
>>
>> Ran
>>
>>
>> 原始邮件
>> *发件人：*陈然00080434
>> *收件人：*[e-mail];
>> *抄送人：*[e-mail];[e-mail];
>> [e-mail];
>> *日 期 ：*2020年10月21日 16:52
>> *主 题 ：**Re: [Bier] Shepherd’s review of
>> draft-ietf-bier-bgp-ls-bier-ext-07*
>> _______________________________________________
>> BIER mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>> Hi Gyan,
>>
>> Thank you very much for your valuable comments, we will update it as soon
>> as possible.
>>
>>
>> Best Regards,
>>
>> Ran
>>
>>
>>
>> *发件人：*张征00007940
>> *收件人：*[e-mail];陈然00080434;
>> *抄送人：*[e-mail];[e-mail];
>> [e-mail];
>> *日 期 ：*2020年10月21日 10:02
>> *主 题 ：**Re: [Bier] Shepherd’s review of
>> draft-ietf-bier-bgp-ls-bier-ext-07*
>> _______________________________________________
>> BIER mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>> Hi Gyan,
>>
>> Ran will consider your suggestion and make some changes.
>>
>> Thank you for your suggestion!
>>
>> Thanks,
>>
>> Sandy
>>
>>
>> *发件人：*GyanMishra
>> *收件人：*张征00007940;
>> *抄送人：*[e-mail];[e-mail];
>> [e-mail];
>> *日 期 ：*2020年10月21日 00:21
>> *主 题 ：**Re: Shepherd’s review of draft-ietf-bier-bgp-ls-bier-ext-07*
>>
>> 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 <[e-mail]> wrote:
>>
>>> 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
>>>
>>>
>>> --
>>
>> <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
>
>

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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