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

From: Greg Shepherd <[email-masked]>
Date: Thu, 30 May 2019 12:38:31 -0700

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)

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 30 May 2019 19:49:45 +0000

Supprot.

Thanks
Mankamana

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Thursday, May 30, 2019 at 12:39 PM
To: BIER WG <[email-masked]>
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:

Thanks,
Shep
(chairs)

---

From: Xiejingrong <[email-masked]>
Date: Fri, 31 May 2019 01:26:00 +0000

Support.

Thanks
Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, May 31, 2019 3:39 AM
To: BIER WG <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext

Thanks,
Shep
(chairs)

---

From: <[email-masked]>
Date: Fri, 31 May 2019 11:11:27 +0800 (CST)

Support as co-author.

Thanks,

Sandy

原始邮件

发件人：GregShepherd <[email-masked]>
收件人：BIER WG <[email-masked]>;
日 期 ：2019年05月31日 03:39
主 题 ：[Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

Thanks,
Shep
(chairs)

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 30 May 2019 21:24:54 -0700

+1

On Thu, May 30, 2019 at 8:11 PM <[email-masked]> wrote:

> Support as co-author.
>
>
> Thanks,
>
> Sandy
>
>
> 原始邮件
> *发件人：*GregShepherd <[email-masked]>
> *收件人：*BIER WG <[email-masked]>;
> *日 期 ：*2019年05月31日 03:39
> *主 题 ：**[Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext*

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 30 May 2019 21:53:33 -0700

Yes, support.

Beer, you've said?

Regards,
Greg

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 30 May 2019 23:05:41 -0700

Yes/support

Cheers,
Jeff

---

From: <[email-masked]>
Date: Fri, 31 May 2019 14:20:04 +0800 (CST)

Hi,

Yes. Supprort as co-author.

Thanks.

Ran

原始邮件

日 期 ：2019年05月31日 03:38

Thanks,
Shep
(chairs)

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 31 May 2019 07:23:33 +0000

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 <[email-masked]> On Behalf Of Greg Shepherd
Sent: 31 May 2019 01:09
To: BIER WG <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext

Thanks,
Shep
(chairs)

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 31 May 2019 08:03:45 -0700

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) <[email-masked]>
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 : 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?
>
>
>
> It MUST appear multiple times in the BIER TLV as described in [RFC8444 <https://tools.ietf.org/html/rfc8444>]
>
>
>
> 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 <[email-masked]> *On Behalf Of *Greg Shepherd
> *Sent:* 31 May 2019 01:09
> *To:* BIER WG <[email-masked]>
> *Subject:* [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext
>
>
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 31 May 2019 15:16:05 +0000

Support

Regards

Hooman

From: BIER <[email-masked]> On Behalf Of Greg Shepherd
Sent: Thursday, May 30, 2019 3:39 PM
To: BIER WG <[email-masked]>
Subject: [Bier] WGLC: draft-ietf-bier-bgp-ls-bier-ext

Thanks,
Shep
(chairs)