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

Hi Greg,

The authors have responded (please see attached) to all the comments and baring one about TLV code-point space, rest all would address my comments. I would wait for the updated version and the author’s decision on the sub-TLV code-points issue before progressing this further.

Thanks,
Ketan

From: BIER <bier-bounces@ietf.org> On Behalf Of Greg Shepherd
Sent: 08 August 2019 01:34
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: idr-chairs@ietf.org; BIER WG <bier@ietf.org>; Alvaro Retana <aretana.ietf@gmail.com>
Subject: Re: [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext

Please. We need to progress this work.

Thanks

On Tue, Jun 25, 2019 at 10:43 AM Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>> wrote:
Can the authors please address Ketan's issues here?

Thanks,
Greg

On Fri, May 31, 2019 at 12:23 AM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> 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?

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.

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.

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?

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

Sec 3.2 : Says

It MUST appear multiple times in the BIER TLV as described in [RFC8444<https://tools.ietf.org/html/rfc8444>]

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

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.

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?

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.

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.

Thanks,
Ketan

From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of Greg Shepherd
Sent: 31 May 2019 01:09
To: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
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)