Re: [Bier] ///Re: WGLC: draft-ietf-bier-bgp-ls-bier-ext

[<[e-mail]>]

Hi Ketan and chairs,


I am very sorry for the late of reply.


Please find replies inline with Ran>






Thanks,


Ran


---------------------------------------------------------------------------------------------------------------------------------


发件人：GregShepherd <[e-mail]>收件人：Ketan Talaulikar (ketant) <[e-mail]>;抄送人：[e-mail] <[e-mail]>;BIER WG <[e-mail]>;Alvaro Retana <[e-mail]>;日 期 ：2019年06月26日 01:44主 题 ：Re: [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext_______________________________________________
BIER mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bier

Can the authors please address Ketan's issues here?
Thanks,Greg
On Fri, May 31, 2019 at 12:23 AM Ketan Talaulikar (ketant) <[e-mail]> wrote:


Hello,

 

I’ve reviewed this draft and have some comments below. I do not believe this draft is ready until they are addressed.

 

IMHO the BIER WG should also cross-post this to the IDR WG so that it gets sufficient eyeballs from the folks working on BGP-LS there. Please note that there are couple of points in my email below  related to code point allocation and implementation requirements that are followed for documents in IDR WG. I am also copying the IDR chairs and Alvaro so that we can come to some common understanding across WGs producing documents related to BGP-LS extensions.

 

General :

 

In most cases, the BGP-LS extensions arise from similar extensions to the IGPs. I assume this is also the case with this document? It becomes important and necessary that the document talks about  the underlying IGP specs and the TLVs from where the information to be put into the new BGP-LS TLVs being defined. Otherwise, how would the BGP-LS producer implementation know what to construct the TLVs from?

 Ran> Yes, This BGP-LS extensions arise from similiar extension to the IGPs. For the IGP extensions,please see https://tools.ietf.org/html/rfc8401 and https://tools.ietf.org/html/rfc8444. We will add it.

If this information is not being sourced from the IGPs, then likely the BFRs would all need to setup a BGP-LS sessions and then this information is sourced locally. I doubt this is the case, but  please confirm.

 

Sec 3 : Please expand “BFR” and explain what it is on the first usage.

  Ran>Sure. We will add it.Thanks.

Sec 3 : There is no “BGP-LS Prefix Attribute TLV” in BGP-LS/RFC 7752. The name of the BGP Attribute introduced for BGP-LS is called BGP-LS Attribute (https://tools.ietf.org/html/rfc7752#section-3.3).  Some of the TLVs in this BGP-LS Attribute are called “Prefix Attribute TLVs” i.e. the ones that are associated with the BGP-LS Prefix NLRI. What we are introducing in this draft for BIER are more/new Prefix Attribute TLVs.

  Ran>Yes. We will change the name to " Prefix Attribute TLV".

Sec 3.1 : Why do we need the MT-ID in this TLV when we already have TLV 263 that indicates the MT-ID as part of the Prefix descriptor TLVs in the NLRI part?

  Ran>we wil remove the MT-ID and use it from the TLV 263.

Sec 3.2 : What is BS Length? I don’t find it in the equivalent IGP TLVs in rfc8444 and rfc8401.

Ran>BS Length is in the "BIER MPLS Encapsulation Sub-sub-TLV in rfc8444 and in the BIER MPLS Encapsulation Sub-TLV" in rfc8401, and we will revise the same as rfc8444 and rfc8401.

Sec 3.2 : Says It MUST appear multiple times in the BIER TLV as described in [RFC8444]


This is not true. It should be a MAY not a MUST.

  Ran> will update it.

Sec 3.3 : The BS Length is 4 bits in the IGPs while it is being introduced as an 8 bit field in BGP-LS. Normally, we should keep things aligned between IGPs and BGP-LS – however, if we want to not  do this, then this document should have some text to explain how the length is encoded. Perhaps somewhat similar to how it’s explained for the label field.

 Ran> Ok. will be updated to 4 bits. 

Sec 4 : IDR WG does not allow for “suggestions” or “recommendations” for code-points – since this is a BGP-LS document I would assume we follow the same rules even if this is BIER WG document? When  required, the IANA early allocation procedure should be followed and the code points updated in the draft once that has been done. Otherwise we will end up having squatting and conflict issues since we will also have BGP-LS drafts in the LSR WG going forward.  I hope we can come to some common understanding on this allocation process across the WGs. Another (unrelated) point is that the IDR WG expects implementation reports and progression to WGLC only after we’ve had 2 implementation reports – does this change  for BGP-LS extensions from outside IDR?

  Ran>will follow the same rules.Thanks for reminding.

Sec 4 : The IANA BGP-LS Parameters registry has the “BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” registry. Also, this document proposes to setup a new registry  for the Encapsulation sub-TLV. We’ve never done this in BGP-LS previously and everyone (including sub-TLVs) allocates from the same flat space. If this document is proposing a deviation from this, then I believe it needs to be reviewed in IDR WG since that  will likely change and set a precedent for how we allocate code-points for BGP-LS

 Ran> In my opnion, it would be better to assign a new registry for the Encapsulation sub-TLV. Beacuse the Encapsulation sub-TLV  has a strong  relationship with the BIER TLV,and of course we can discuss.

Sec 5 : I think the text in this section is inadequate and we will face questions during AD/IESG reviews. Please consider borrowing text from https://tools.ietf.org/html/rfc8571#section-3 (I assume this is straightforward case of taking info from IGPs into BGP-LS) on the lines of RFC7752.

  Ran>will update it.




Thanks,

Ketan

 

 

From: BIER <[e-mail]> On Behalf Of Greg Shepherd
Sent: 31 May 2019 01:09
To: BIER WG <[e-mail]>
Subject: [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext

 

Solid support in the room in Prague. Now to the list... Please read and respond to this thread:

 

https://datatracker.ietf.org/doc/draft-ietf-bier-bgp-ls-bier-ext/

 

Also need a volunteer Doc Shepherd. I'll buy you a beer.

 

Voting ends 13 June 2019.

 

Thanks,

Shep

(chairs)