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

[Greg Shepherd <[e-mail]>]

Thanks for the input! Yes, the WG process has always been to clear any
draft with WGLC in all affected WGs before moving to the IESG queue. We
usually WGLC in BIER WG first to ensure we've done our best before formally
asking for a WGLC to the other affected groups.

Cheers,
Shep
(chairs)

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