Subject: [Idr] draft-cli-bgp-ext-com-registry-update: WG adoption and IPR Call and WG adoption (6/24 to 7/8)

From: "Susan Hares" <[email-masked]>
Date: Wed, 24 Jun 2020 21:21:05 -0400

This begins a 2 week WG adoption call for: 

draft-cl-idr-bgp-ext-com-registry-01.txt 

You can download the draft at: 

https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/

This document updates several BGP Extended Community registries in

   order to replace the "Experimental Use" registration procedure in

   some entries, since their use is clearly not experimental and thus

   misleading.

This draft should be consider as part of the group of drafts that are trying
to clarify and speed up the registry process. 

Christoph  you should send an IPR statement regarding this draft to the IDR
WG.   Since you normally prompt with your email, I am running the IPR call
and WG Adoption call in parallel. 

The other drafts which are in process for registry clean-up are: 

1)
<https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-chang
e/> draft-ietf-idr-capabilities-registry-change-09 

      John Scudder: in RFC editor's queue

2) https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/ 

     Adrian Farrell: In Shepherd's queue, top of list. 

These two drafts provide clean-up to the IDR capabilities and the BGP LS
registry process.    This draft provides a set-up clean-up instructions for
the Extended Communities registries. 

Please consider if this clean-up will lessen confusion and help us
streamline the process.  If you have other ideas for cleaning up the BGP
registries, you are welcome to include the information on this thread. 

Thank you, Sue

---

From: John Scudder <[email-masked]>
Date: Mon, 29 Jun 2020 19:25:02 +0000

(As an individual contributor)

I’ve just read through the draft. As advertised it is short, sweet, and to the point. I support its adoption, and thank Christoph for writing it.

I will note that it would be possible to carve out just the three mis-assigned code points without changing the registration procedures for the entire registry, i.e. we could leave the Experimental ranges as experimental, save for those three code points. However, as most of you know I’m not a big fan of Experimental for BGP protocol allocations, it doesn’t seem to be worth much, so I’m just as happy to see the change made. In any case, the WG should adopt the draft either way, since no matter what, the three code points in question should be clarified.

I do want to raise one potential concern about the reclassification of the ranges: since Experimental is completely ungoverned (see https://tools.ietf.org/html/rfc8126#section-4.2), there could in theory be implementations in the field already using code points from this space. I think it’s not very likely that there ARE such, but there could be. (If someone knows of an example of one, they should say so right now of course.)

Thanks,

—John

On Jun 24, 2020, at 9:21 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

You can download the draft at:
https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJrPzpyVA$>

This draft should be consider as part of the group of drafts that are trying to clarify and speed up the registry process.

Christoph  you should send an IPR statement regarding this draft to the IDR WG.   Since you normally prompt with your email, I am running the IPR call and WG Adoption call in parallel.

1) draft-ietf-idr-capabilities-registry-change-09<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJS6xrsfg$>
      John Scudder: in RFC editor’s queue
2) https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLfv03utQ$>
     Adrian Farrell: In Shepherd’s queue, top of list.

These two drafts provide clean-up to the IDR capabilities and the BGP LS registry process.    This draft provides a set-up clean-up instructions for the Extended Communities registries.

Please consider if this clean-up will lessen confusion and help us streamline the process.  If you have other ideas for cleaning up the BGP registries, you are welcome to include the information on this thread.

Thank you, Sue

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLWNNmtxw$

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 30 Jun 2020 05:43:54 +0000

I support this draft. It's an appropriate cleanup. The cement has dried on these codes.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Wednesday, June 24, 2020 6:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] draft-cli-bgp-ext-com-registry-update: WG adoption and IPR Call and WG adoption (6/24 to 7/8)

1) draft-ietf-idr-capabilities-registry-change-09<https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/>
      John Scudder: in RFC editor's queue
2) https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/
     Adrian Farrell: In Shepherd's queue, top of list.

Thank you, Sue

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 Jun 2020 10:34:24 +0000

I support WG adoption. I agree with John Scudder’s comments on the draft.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Wednesday, June 24, 2020 at 9:21 PM
To: IDR List <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Idr] draft-cli-bgp-ext-com-registry-update: WG adoption and IPR Call and WG adoption (6/24 to 7/8)

Thank you, Sue

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 30 Jun 2020 17:55:27 +0000

I think hard coded experimental code points lead to the problem with the code points named in this draft.
However, if an experimental code point is used in code where the code point is configurable, then
it is easy to change if and when the experiment becomes adopted.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of John Scudder
Sent: Monday, June 29, 2020 12:25 PM
To: Hares Susan <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] draft-cli-bgp-ext-com-registry-update: WG adoption and IPR Call and WG adoption (6/24 to 7/8)

Thanks,

—John

You can download the draft at:
https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJrPzpyVA$>

1) draft-ietf-idr-capabilities-registry-change-09<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJS6xrsfg$>
      John Scudder: in RFC editor’s queue
2) https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLfv03utQ$>
     Adrian Farrell: In Shepherd’s queue, top of list.

Thank you, Sue

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLWNNmtxw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLWNNmtxw$>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Jun 2020 11:09:15 -0700

I support adoption.
I concur with John Scudder.
I'd even go so far as to suggest a slight improvement/change, based on the
following logic:
Transitive and Experimental are mutually exclusive, IMNSHO.
Non-Transitive Experimental EC can be propagated among consenting parties,
by judicious use of route-maps (or equivalent) for matching and re-applying
the same or similar ECs to the NLRI(s).

I propose eliminating the Experimental Transitive category entirely, other
than the three Type codes which have been set up in the registry already
(previously or via this ID).

Brian

On Mon, Jun 29, 2020 at 12:25 PM John Scudder <jgs=
[email-masked]> wrote:

> I’ve just read through the draft. As advertised it is short, sweet, and to
> the point. I support its adoption, and thank Christoph for writing it.
>
> I will note that it would be possible to carve out just the three
> mis-assigned code points without changing the registration procedures for
> the entire registry, i.e. we could leave the Experimental ranges as
> experimental, save for those three code points. However, as most of you
> know I’m not a big fan of Experimental for BGP protocol allocations, it
> doesn’t seem to be worth much, so I’m just as happy to see the change made.
> In any case, the WG should adopt the draft either way, since no matter
> what, the three code points in question should be clarified.
>
> I do want to raise one potential concern about the reclassification of the
> ranges: since Experimental is completely ungoverned (see
> https://tools.ietf.org/html/rfc8126#section-4.2), there could in theory
> be implementations in the field already using code points from this space.
> I think it’s not very likely that there ARE such, but there could be. (If
> someone knows of an example of one, they should say so right now of course.)
>
> Thanks,
>
> —John
>
> On Jun 24, 2020, at 9:21 PM, Susan Hares <[email-masked]> wrote:
>
>
>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cl-idr-bgp-ext-com-registry-update/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJrPzpyVA$>
>
> This draft should be consider as part of the group of drafts that are
> trying to clarify and speed up the registry process.
>
> Christoph  you should send an IPR statement regarding this draft to the
> IDR WG.   Since you normally prompt with your email, I am running the IPR
> call and WG Adoption call in parallel.
>
> 1) draft-ietf-idr-capabilities-registry-change-09
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSJS6xrsfg$>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-registry/__;!!NEt6yMaO-gk!R5iRHCRaDtkyJ3GYqfAwIaQrt7Ok9-pEvV6eDArDVP5ayHp-23iXFSLfv03utQ$>
> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Jun 2020 16:56:04 -0400

> I support WG adoption. I agree with John Scudder’s comments on the draft.

Exactly the same here as well.

-- Jeff