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

[Greg Shepherd <[e-mail]>]

Please. We need to progress this work.

Thanks

On Tue, Jun 25, 2019 at 10:43 AM Greg Shepherd <[e-mail]> wrote:

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