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

[Greg Shepherd <[e-mail]>]

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?
>
>
>
> 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 <[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)
>