Subject: [Idr] WG adoption of draft-heitz-idr-large-community; one week to comment on early code point allocation

From: "John G. Scudder" <[email-masked]>
Date: Wed, 21 Sep 2016 14:27:27 -0400

Dear WG,

Sue and I believe we have rough(er than usual) consensus to adopt draft-heitz-idr-large-community.

The urgent need expressed by multiple network operators was the key input to deciding to adopt this draft. One other option would have been to convene an interim to further discuss the technical issues that were raised. In light of the urgent need for this draft, the authors have kindly agreed to treat revising and finishing the document as a high-priority work item. We hope the WG members, old and new, who have engaged in the discussion will also treat review and comment as a high priority. Likewise we hope implementors will cooperate in updating the implementation report (https://trac.tools.ietf.org/wg/idr/trac/wiki/Protocol%20implementations%20Reports) quickly.

If you are willing to serve as document shepherd (see https://www.ietf.org/iesg/statement/document-shepherds.html) and can commit to providing quick turnaround, please unicast the chairs.

Thanks. If the energy shown so far can be sustained we're optimistic the document can be moved along to RFC quite promptly. We will be looking for a consensus that is a little less rough than we have today before submitting it to the IESG, though.

We also will be requesting an early allocation of a path attribute code from IANA. If you have any objections or concerns about this, please let us know. Barring objections, we'll submit the request in a week, on September 28. The authors have agreed to remove the "suggested" value that was in the individual submission.

FYI this practice of "suggesting" a code point is discouraged, see https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft. Maybe we should cover this in our next meeting to raise visibility of the topic.  

Authors, please remove the code point from the draft and resubmit as draft-ietf-idr-large-community.

Thanks,

--John and Sue

---

From: Job Snijders <[email-masked]>
Date: Sat, 24 Sep 2016 11:26:57 +0200

Dear Working Group,

> draft-ietf-idr-large-community.

https://tools.ietf.org/html/draft-ietf-idr-large-community-00 has been
posted!

Notable changes:

    o substantial rewording (thanks Heasley)
    o added BNF to replace the incorrect regex (thanks Peter van Dijk)
    o added security section (copy+pasted from RFC 4360)
    o added error handling (thanks Bush, Haas, Keyur)
    o remove squated IANA codepoint (squatting is a dutch tradition ;-))
    o updated currently known implementations (section 6)
    o updated the acknowledgements

I have some questions for the working group:

1) Is the BNF in section 3 helpful or should it be removed for
   document compactness?

2) Does the section 3 'textual representation' wording allow sufficient
   flexibility to accomodate BIRD- or JunOS-style syntax?

3) Should values in the range "65535:0:0 - 65535:4294967295:4294967295" be
   reserved to accomodate any future well known communities? 65535 is
   used in RFC1997 so i see merit in continuing to use that number.

4) is it sufficiently clear how to encode multiple Large BGP Communities?
   We all "know" what is meant because of rfc1997, but is the text actually
   documenting this good enough?

Thanks!

The full diff can be viewed here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-00.txt

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 24 Sep 2016 14:00:13 +0100

>    used in RFC1997 so i see merit in continuing to use that number.

It's taken us 20 years to reach 14 well-known communities in the rfc1997
WKC registry.  Extrapolating this out, this should give us enough bit
space for all requirements for the next ~100,000 years, at which point
I'd be happy to see the IDR working group re-opening discussion on the
issue.

In the interim, there are sound reasons for not duplicating WKCs in
another number space, e.g. precedence, vendor bugs, unnecessary
complication, additional overhead, etc.

Nick

---

From: Julian Seifert <[email-masked]>
Date: Sat, 24 Sep 2016 13:06:19 +0000

Hi,

> 1) Is the BNF in section 3 helpful or should it be removed for

It's a very short description that helps in understanding the representation
format. So I think it adds more clarity than complexity/length.

 >  flexibility to accomodate BIRD- or JunOS-style syntax?

As far as I understand the wording, the intent is to have everybody implement 
the 'part:part:part' representation as textual representation and _in addition_ allow vendors to
use their specific own representation. (Which might or might not be the default
for their product)

>  used in RFC1997 so i see merit in continuing to use that number.

I think there should be a reserved range but specific values/communities should
be defined in a separate document.

>  documenting this good enough?

To keep it short - for me it is clear and well documented.

> Thanks!

thank you as well :)

kind regards,

  Julian

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 24 Sep 2016 14:06:41 +0100

>    flexibility to accomodate BIRD- or JunOS-style syntax?

yes, I believe so - the language needs minor wordsmithing, but the
concept is sound.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 24 Sep 2016 15:37:18 +0200

​Nick,​

> WKC registry.

​It is not 20 years ... the topic has been discussed via those 20 years
number of times.

The problem is that it is impossible to call something "well known" and
depend on it in any way once the RFC is issued. ​

​So IMO ​reserving the space to be filled by some other RFC in the future
makes sense.

> Extrapolating this out, this should give us enough bit

​That even beat's ​Pando's tree roots !

Cheers,
R.

---

From: "Peter van Dijk" <[email-masked]>
Date: Sun, 25 Sep 2016 16:02:39 +0200

Hello Remco,

On 24 Sep 2016, at 12:39, Remco van Mook wrote:

> Personally, I don't see the merit in requiring all the integers - 
> instead, I
> think it's bad for readability (but then again I might have been 
> exposed to
> IPv6 for too long). I think there's nobody who's going to 
> misunderstand
> 65535::, 65535:1:, 65535::1 or even ::1:2.

For interoperability, management and for software testing, it is best to 
have a single canonical representation. Experience with the IPv6 
‘compression’ feature shows that vendors are unable to implement 
this consistently. Note for example the perl hack in here 
https://github.com/PowerDNS/pdns/blob/master/regression-tests/tests/basic-aaaa-resolution/command 
- this is because OSX (at least in 10.10 which I’m still running) 
*gets it wrong*. If you allow compression like this, even if you specify 
exactly when to compress (which RFC 5952 does a theoretically fine job 
of), vendors will mess it up. Look at your own ‘::1:2’ as an example 
of how confusing compression is especially on such short values. I 
understand why v6 has the compression - you get a heap of zeros in many 
cases. But for large communities we are talking a few zeroes max. Better 
to have a strict canonical format that is as simple as possible.

Also, without compression, there is no chance of mistaking a large 
community for a v6 address. Once you allow compression, is 2001::5 a v6 
address or a large community? Perhaps this is not the strongest point 
but if we can avoid this at zero cost, why not?

In short, the current approach with mandatory zero fields but no leading 
zeros looks sane to me. It is canonical, there is no confusion, and 
vendors should be able to get it right.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Brian Dickson <[email-masked]>
Date: Mon, 26 Sep 2016 12:49:41 -0700

>    used in RFC1997 so i see merit in continuing to use that number.

IMHO, the first of the 3 32-bit values, should be treated as per the IANA
registry for Autonomous System Numbers.

There are several values in both 16-bit and 32-bit ranges with special
purposes.

Those include documentation purposes, private use, and "reserved".
Currently, I see the relevant values in the table as follows:

0 (Reserved, RFC7607)
23456 (AS_TRANS, RFC6794)
64496-64511 (Documentation and sample code, RFC5398)
64512-65534 (Private use, RFC6996)
65535 (Reserved, RFC7300)
65536-65551 (Doc'n & sample code, RFC5398)
65552-131071 (Reserved)
4200000000-4294967294 (Private use, RFC6996)
4294967295 (Reserved, RFC7300)

I'm not sure what the preferred method is these days, either refer to the
ARIN table, or to the RFCs directly.
However, the corresponding communities should inherit the properties
(Reserved, Documentation and Sample Code, Private Use, and AS_TRANS).

Brian

---

From: Job Snijders <[email-masked]>
Date: Mon, 26 Sep 2016 23:18:52 +0200

Hi,

On Mon, Sep 26, 2016 at 12:49:41PM -0700, Brian Dickson wrote:
> IMHO, the first of the 3 32-bit values, should be treated as per the
> IANA registry for Autonomous System Numbers.

In most of the cases, probably.

> purposes. Those include documentation purposes, private use, and
> "reserved".  Currently, I see the relevant values in the table as
> follows:
> 
> 0 (Reserved, RFC7607)
> I'm not sure what the preferred method is these days, either refer to
> the ARIN table, or to the RFCs directly.  However, the corresponding
> communities should inherit the properties (Reserved, Documentation and
> Sample Code, Private Use, and AS_TRANS).

I agree with you that these are special values, but they are a different
kind of special than the '65535' from RFC 1997.

I don't see how these values have meaning in a BGP implementation, thus
are probably out of scope for IDR. I think this will be better covered
in the "Usage" document we'll submit to GROW in the short term.

Kind regards,

Job

---

From: Brian Dickson <[email-masked]>
Date: Mon, 26 Sep 2016 16:23:56 -0700

> kind of special than the '65535' from RFC 1997.
RFC 1997 does not specifically say so, but definitely derives its "special"
from the ASN registry "special" for 0 and 65535.

The WKC use of 65535:xxxx is something tracked in an IANA registry.

I suggest a similar registry be set up for (2^32-1):xxxx:yyyy, and I would
hope the other document handles that.

I think parity with 1997 would be the best course of action, and to
include-by-reference 32-bit values that are 16 bits of 0, followed by 16
bits of 1997 values that are reserved, as well as the RFC 7300 32-bit
Reserved ASN.
I.e. 0:xxxx:yyyy, 65535:xxxx:yyyy, and 4294967295:xxxx:yyyy.

I think referencing RFC 5398 is sufficient, and hinting that their usage
(as the first 32-bit value of a Large community) is strongly discouraged
outside of documentation and sample code.

And I think it is sufficient to reference RFC 6996 plus 1997, to point out
the local nature of communities associated with Private Use ASNs.

RFC 6794 currently recommends use of Extended communities; I think the
current document should also Update 6794 to suggest Large as an alternative
or as the recommended alternative.

> in the "Usage" document we'll submit to GROW in the short term.

The ASN values in AS_PATH or AS4_PATH have mandatory restrictions, for both
Private Use and for Reserved, even if the controlling RFCs are not
Standards track.

I do think this RFC will be read by operators as well as implementors, so
documenting the expected usage would not be superfluous, IMHO, even if not
directly relevant to implementations.

Brian

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Sep 2016 19:31:57 -0400

> On Sep 26, 2016, at 7:23 PM, Brian Dickson <[email-masked]> wrote:
> 
> RFC 1997 does not specifically say so, but definitely derives its "special" from the ASN registry "special" for 0 and 65535.

Given the practice of encoding an AS number in the first portion of the community, reserving 0 made some amount of sense.

There also tends to be common practice to try to reserve 0 out of things resembling code points to have as the "uninitialized value".  I'd recommend that practice continue for pretty much everything, including large comms.

> I think parity with 1997 would be the best course of action, and to include-by-reference 32-bit values that are 16 bits of 0, followed by 16 bits of 1997 values that are reserved, as well as the RFC 7300 32-bit Reserved ASN.

FWIW, I think things with "well known" semantics should stick to the reserved code point space in 1997 communities unless there's some motivation to have a common parameter/argument in it.  In that case, it fits the case for large comms anyway.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 27 Sep 2016 03:57:40 +0000

Maybe stating too much of the obvious, but it should suffice:

   It is not a protocol error to put an invalid ASN into the ASN field.
   For example 0 or 23456 are allowed.  It is up to the receiving BGP
   speaker to recognize (or not) any received large communities.  There
   are no routing semantics implied by the ASN field.  For example, this
   document does not require a receiver of a large community to know
   where the AS identified by the ASN of a large community is.
   The ASN field is simply a convenience that allows different ASes to
   define large communities without clashing with each other.  If an AS
   wants to use invalid ASNs in the ASN field privately within its own
   AS or even by agreement with a neighboring AS, then this document
   does not prohibit it.

To prevent junk communities from spreading throughout the internet,
a BGP speaker SHOULD NOT send a large community with an invalid or
unassigned ASN
unless it knows that the receiving speaker understands its meaning.
A receiving speaker is free to drop any large community, even if
it contains a valid ASN. A BGP speaker is under no obligation to
deliver a route containing a large community to the AS identified
by the ASN in the large community.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Monday, September 26, 2016 4:32 PM
> To: Brian Dickson <[email-masked]>
> Cc: In-Depth Review <[email-masked]>
> Subject: Re: [Idr] WG adoption of draft-heitz-idr-large-community; one week to comment on early code point
> allocation
> 
> 
> There also tends to be common practice to try to reserve 0 out of things resembling code points to have as the
> "uninitialized value".  I'd recommend that practice continue for pretty much everything, including large comms.
> 
> > I think parity with 1997 would be the best course of action, and to include-by-reference 32-bit values that are 16
> bits of 0, followed by 16 bits of 1997 values that are reserved, as well as the RFC 7300 32-bit Reserved ASN.
> FWIW, I think things with "well known" semantics should stick to the reserved code point space in 1997 communities
> unless there's some motivation to have a common parameter/argument in it.  In that case, it fits the case for large
> comms anyway.
> 
> -- Jeff
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Job Snijders <[email-masked]>
Date: Tue, 27 Sep 2016 10:24:43 +0200

On Mon, Sep 26, 2016 at 07:31:57PM -0400, Jeffrey Haas wrote:
> > RFC 1997 does not specifically say so, but definitely derives its
> > "special" from the ASN registry "special" for 0 and 65535.
> 
> Given the practice of encoding an AS number in the first portion of
> the community, reserving 0 made some amount of sense.
> 
> There also tends to be common practice to try to reserve 0 out of
> things resembling code points to have as the "uninitialized value".
> I'd recommend that practice continue for pretty much everything,
> including large comms.
> 
> > include-by-reference 32-bit values that are 16 bits of 0, followed
> > by 16 bits of 1997 values that are reserved, as well as the RFC 7300
> > 32-bit Reserved ASN.
> FWIW, I think things with "well known" semantics should stick to the
> reserved code point space in 1997 communities unless there's some
> motivation to have a common parameter/argument in it.  In that case,
> it fits the case for large comms anyway.

I agree with you Jeff. 

How about the following:

"""
    The Large Community attribute values in the following ranges are
    reserved:

             0:0:0 -          0:4294967295:4294967295
    4294967295:0:0 - 4294967295:4294967295:4294967295

"""

This way the lowest and highest possible value are reserved, and at some
later point (part of) these reserved ranges could be converted to
Well-known or something else if that need arises.

Going back to my earlier question, reserving 65535:*:*, just because it
was a meaningful value in rfc1997, does not make a whole lot of sense.
65535 was picked in rfc1997 because it was the highest value, we can
apply the same logic with Large.

Note: i propose just to reserve these two ranges, I don't see an
immediate need to open a registry given that we already have rfc1997
WKC.

Kind regards,

Job

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 27 Sep 2016 08:34:06 +0000

Jakob, Job, 

Also will be great to define a ³universal² mapping between
standard-communities and large-communities

If standard are X:Y

Then I see 3 options (of many more).
Option 1 X:0:Y 
Option 2 X:Y:0
Option 3 Z:X:Y

I personally do prefer option 1.
Could be 0 or any reserve number we agree on.

Best Regards Bertrand Duvivier
https://wiki.cisco.com/display/SLA/Segment%20Routing

---

From: t.petch <[email-masked]>
Date: Tue, 27 Sep 2016 10:43:24 +0100

Changing the Subject to reflect the adoption.

In section 7, I would like to give IANA a more specific instruction,
such as

'... in the IANA BGP Path Attributes registry in the Border Gateway
Protocol (BGP) Parameters group '

The less we ask them to do, the more accurate they are likely to be.

And the Abstract should not contain citations.

Which draft-heitz got right (otherwise I would have commented on it:-).
More generally, and perhaps being picky,
draft-ietf-idr-large-community-00.txt
is not the I-D which the WG agreed to adopt!  The convention I like is
that when a WG adopts an I-D, then the only change is to the title
because that is the text which has been adopted.  Maybe all the changes
you have made do have the consensus of the WG, I do not know (except, as
I said above, I would have commented on the addition of citations to the
Abstract had you done that beforehand).

Tom Petch

----- Original Message -----
From: "Job Snijders" <[email-masked]>
To: "I Don't Remember" <[email-masked]>
Sent: Saturday, September 24, 2016 10:26 AM
Subject: Re: [Idr] WG adoption of draft-heitz-idr-large-community; one
week to comment on early code point allocation

> The full diff can be viewed here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-00.tx
t

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 27 Sep 2016 10:07:55 -0400

On Sep 27, 2016, at 5:43 AM, t.petch <[email-masked]> wrote:
> because that is the text which has been adopted. 

For what it's worth, one of the changes was specifically requested and anounced by the chairs:

"Authors, please remove the code point from the draft and resubmit as draft-ietf-idr-large-community."

I take your point regarding the other changes, and perhaps we will make it a practice in future to explicitly request authors submit verbatim the text that was approved for adoption. I personally don't see this as a big problem though (and probably you don't either or else you wouldn't have referred to it as "being picky") since the mailing list archive and document history tells an accurate story and of course the working group can choose to roll back any changes that don't reflect consensus.

Thanks,

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Sep 2016 10:31:45 -0400

> On Sep 27, 2016, at 4:24 AM, Job Snijders <[email-masked]> wrote:
> 

I'm fine with such a reservation.  However, it'd be good to get the reasoning in the doc rather than letting it be inferred after the fact.

As one example, the "don't use AS0" seems like a reasonable thing since it's not permitted in the Internet, but I'm aware of provider policies that are using 0:* in 1997 format to signal stuff.  Arguably that case gets weaker with the additional field in -large.

The 65535:* in 1997 was fine since something had to be carved out for the well knowns.  Where this has been awkward has been the tendency of providers wanting to actually *use* 65535 as a private AS number, but now having an overloaded community space for what's being used as an AS.

> apply the same logic with Large.

I tend to agree.  This piece of the conversation mostly needs harmonization with "what do we do or don't do about automatically mapping 1997 into -large".  I'm agnostic on that point.

> immediate need to open a registry given that we already have rfc1997

I concur, modulo the above.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Tue, 27 Sep 2016 16:58:41 +0200

On Tue, Sep 27, 2016 at 10:31:45AM -0400, Jeffrey Haas wrote:
> I'm fine with such a reservation. However, it'd be good to get the
> reasoning in the doc rather than letting it be inferred after the
> fact.

Thank you for your feedback.

Would you be willing to (unicast) a couple of sentences to describe why
0 and 2^32-1 are special?

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 27 Sep 2016 17:09:05 +0200

Dear Bertrand,

> Could be 0 or any reserve number we agree on.

I do not think that mapping is as straight forward as it might appear at
first glance. I can see many more ways to map large & rfc1997 then the 3
you listed.

I am not sure whether mapping belongs in the draft-ietf-idr-large-community
document, or even in IDR. This was echoed earlier by John [1].

A mapping mechanism will have several requirements, those requirements
might differ from network to network. Ideally the mapping mechanism
helps you transition into your own namespace, but for others this might
not be a consideration. Maybe vendors should just provide the operator
with the tools to develop their own mappings & arithmetic.

I think both a mapping mechanism specification and the large community
draft will benefit from being able to proceed at different speeds,
possibly in different working groups.

I don't imagine that part of a mapping mechanism will be to change the
on-the-wire encoding, of negotiate bgp capabilities. If a mapping
mechanism _would_ require on-the-wire signalling of any sort, that would
be all the more reason for me to keep it separate from
draft-ietf-idr-large-community.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/idr/7NYMcTmNJuUnQZcya4S1B4Iof3Q

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Sep 2016 11:11:54 -0400

> On Sep 27, 2016, at 10:58 AM, Job Snijders <[email-masked]> wrote:
> 

https://tools.ietf.org/html/draft-haas-code-point-reservation-bcp-02 <https://tools.ietf.org/html/draft-haas-code-point-reservation-bcp-02>

The above draft got quite a bit of feedback from a few individuals with MUCH stronger opinions than I did as to how to write recommendations.  However, the document captures my own opinions.

This doesn't answer your specific request, but at least gives you an idea of my thinking.

-- Jeff

---

From: heasley <[email-masked]>
Date: Tue, 27 Sep 2016 19:52:14 +0000

> And the Abstract should not contain citations.

Why?  The citation defines the term, so it seems perfectly reasonable to do so.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 27 Sep 2016 16:08:42 -0400

> Why?  The citation defines the term, so it seems perfectly reasonable to do so.

The simplest answer to "why" is that it's standard IETF style – idnits complains if you have citations in your abstract, like so:

  ** The abstract seems to contain references ([RFC4271], [RFC6793],
     [RFC1997]), which it shouldn't.  Please replace those with straight
     textual mentions of the documents in question.

(See https://tools.ietf.org/tools/idnits/ or click the "Nits" link in the upper right-hand corner of the tools.ietf.org copy of the draft.)

The source of authority for idnits is the IESG, you can follow the links from the idnits page, to https://www.ietf.org/id-info/checklist.html requirement 3.1.B and https://www.ietf.org/ietf-ftp/1id-guidelines.txt section 6:

   An Abstract should be complete in itself, so it should contain no
   citations unless they are completely defined within the Abstract.

You'd have to ask the IESG if you wanted to know why they made this decision, but perhaps it's to keep the abstract as brief and to the point as possible? Almost by definition, anyone ready to dive into the references should be reading the main body of the text, and not just the abstract. I can say that prior to this guideline (and even subsequent, alas) some authors have seemed tempted to put the entire meat of their document into the abstract, which rather defeats the point. It's just supposed to be a teaser.

--John

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 27 Sep 2016 20:10:18 +0000

On 9/27/16, 3:52 PM, "Idr on behalf of heasley" <[email-masked] on

>Why?  The citation defines the term, so it seems perfectly reasonable to

This is an IETF RFC convention. The abstract may be extracted and should
be autonomous. Refer to section 4.3:

https://www.rfc-editor.org/rfc/rfc7322.txt

Thanks,
Acee

---

From: Job Snijders <[email-masked]>
Date: Tue, 27 Sep 2016 22:18:16 +0200

On Tue, Sep 27, 2016 at 08:10:18PM +0000, Acee Lindem (acee) wrote:
> This is an IETF RFC convention. The abstract may be extracted and
> should be autonomous. Refer to section 4.3:
> 

On Tue, Sep 27, 2016 at 04:08:42PM -0400, John G. Scudder wrote:
> The simplest answer to "why" is that it's standard IETF style – idnits
> complains if you have citations in your abstract, like so:
> 

Thanks Tom, Acee, John Scudder, we'll improve the abstract.

Kind regards,

Job

---

From: heasley <[email-masked]>
Date: Tue, 27 Sep 2016 20:39:29 +0000

> I concur, modulo the above.

I would reserve 65535:*:*, simply because it, like 0, is a reserved ASN and
if, in the future, there is a desire to create feature parity with rfc1997,
its been reserved.  I suppose all-1s could be used for well-knowns as well.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 30 Sep 2016 14:37:39 -0400

On Sep 21, 2016, at 2:27 PM, John G. Scudder <[email-masked]> wrote:
> We also will be requesting an early allocation of a path attribute code from IANA.

FYI this is done:

On Sep 29, 2016, at 1:36 PM, Amanda Baber via RT <[email-masked]> wrote:
> We've made the following early allocation in the BGP Path Attributes registry:
> 
> 30	LARGE_COMMUNITY (TEMPORARY - registered 2016-09-29, expires 2017-09-29)	[draft-ietf-idr-large-community]
> 
> Please see
> http://www.iana.org/assignments/bgp-parameters

I expect the authors will incorporate this info into the next version.

Thanks,

--John

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 30 Sep 2016 19:11:38 +0000

Yes. Thanks John.

Jakob.

> From: John G. Scudder [mailto:[email-masked]]
> Sent: Friday, September 30, 2016 11:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Early allocation for draft-heitz-idr-large-community [was: Re: [Idr] WG adoption of draft-heitz-idr-large-
> community; one week to comment on early code point allocation]
>