Subject: [Idr] Proposed IANA procedures for BGP Well-known communities

From: David Ward <[email-masked]>
Date: Wed, 16 Jul 2008 21:37:33 -0500

All -

	The IDR WG chairs and and Routing ADs  were requested by IANA to  
clear up the lack of registration procedures for BGP communities  
specified in RFC 1997.

This registry exists;

http://www.iana.org/assignments/bgp-well-known-communities

but, there is no specified way to reserve new well-known-communities.  
Here is the relevant quotation from RFC 1997:

"COMMUNITIES attribute

    This document creates the COMMUNITIES path attribute is an optional
    transitive attribute of variable length.  The attribute consists  
of a
    set of four octet values, each of which specify a community.  All
    routes with this attribute belong to the communities listed in the
    attribute.

    The COMMUNITIES attribute has Type Code 8.

    Communities are treated as 32 bit values,  however for   
administrative
    assignment,  the following presumptions may be made:

    The community attribute values ranging from 0x0000000 through
    0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

    The rest of the community attribute values shall be encoded using an
    autonomous system number in the first two octets.  The semantics of
    the final two octets may be defined by the autonomous system  
(e.g. AS
    690 may define research, educational and commercial community values
    that may be used for policy routing as defined by the operators of
    that AS using community attribute values 0x02B20000 through
    0x02B2FFFF).

Well-known Communities

    The following communities have global significance and their
    operations shall be implemented in any community-attribute-aware   
BGP
    speaker.

       NO_EXPORT (0xFFFFFF01)
          All routes received carrying a communities attribute
          containing this value MUST NOT be advertised outside a BGP
          confederation boundary (a stand-alone autonomous system that
          is not part of a confederation should be considered a
          confederation itself).
       NO_ADVERTISE (0xFFFFFF02)
          All routes received carrying a communities attribute
          containing this value MUST NOT be advertised to other BGP
          peers.
       NO_EXPORT_SUBCONFED (0xFFFFFF03)
          All routes received carrying a communities attribute
          containing this value MUST NOT be advertised to external BGP
          peers (this includes peers in other members autonomous
          systems inside a BGP confederation).
"

I am proposing a 50/50 split of the upper range of currently reserved  
space between the "First Come First Served" policy defined in RFC  
2434 and those assigned by IANA using  either the Standards Action  
process defined in RFC 2434, or the Early IANA Allocation process  
defined in RFC 4020.

Here is the definition of the space:

0x0000000-0x0000FFFF                                                  
Reserved
0xFFFFFF01         NO_EXPORT                                      
[RFC1997]
0xFFFFFF02         NO_ADVERTISE                               [RFC1997]
0xFFFFFF03         NO_EXPORT_SUBCONFED          [RFC1997]
0xFFFFFF04         NOPEER                                              
[RFC3765]
0xFFFF0000-0xFFFFFFFF                                                
Reserved

Proposal of redefinition of space:

0xFFFF0000-0xFFFF8000 = FCFS
0xFFFF8001-0xFFFFFFFF = IANA Assigned

Note: The first 65535 comms remain reserved (0x0000000-0x0000FFFF).

Note1: there is a proposal in draft-pmohapat-idr-acceptown- 
community-01.txt that proposes that 0xFFFFFF05 be "ACCEPT_OWN." This  
request would follow the 50/50 split proposal if the draft is  
standardized.

I'll hopefully explain it in 3 mins or less at the IDR meeting at  
IETF72 so that we can give some procedures to IANA.

Please discuss now....

-DWard

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Jul 2008 22:47:19 -0400

Dave,

> http://www.iana.org/assignments/bgp-well-known-communities

[...]

>    operations shall be implemented in any community-attribute-aware  BGP
>    speaker.

I'd suggest taking the FCFS communities and putting them in a registry
other than the "well known" one.  Well known implies that an
implementation should be aware of them and implement their semantics.

Beyond that, go for it.

-- Jeff

---

From: David Ward <[email-masked]>
Date: Thu, 17 Jul 2008 14:40:27 -0500

Jeff -

I brought this up during the IESG telechat today and there is  
precedence to have FCFS space in something titled "well-known." If  
others feel strongly, they should speak up.

-DWard

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Jul 2008 16:06:51 -0400

On Thu, Jul 17, 2008 at 02:40:27PM -0500, David Ward wrote:
> I brought this up during the IESG telechat today and there is precedence to 
> have FCFS space in something titled "well-known." If others feel strongly, 
> they should speak up.

I'm fine with this.  As I mentioned in another mail, I'd recommend that
IANA include some verbiage noting that FCFS communities are not
guaranteed to be widely supported as implied by RFC 1997.

-- Jeff

---

From: "Tony Li" <[email-masked]>
Date: Thu, 17 Jul 2008 13:09:55 -0700

Dave,

My concern is related and is perhaps entirely procedural.  If a "well-known"
community is supposed to have universal support and given that we already
have implementations in the field, how can any new community (or for that
matter, path attribute) truly become "well-known"?  We have to assume that
there will always be at least one box in the field that will not support it.

Further, if it's not practical to add to the set of "well-known"
communities, is there really a reason to have an IANA registry for that
subset?

Regards,
Tony

|>> Well-known Communities
|>>
|>>    The following communities have global significance and their
|>>    operations shall be implemented in any community-attribute- 
|>> aware  BGP
|>>    speaker.

---

From: David Ward <[email-masked]>
Date: Thu, 17 Jul 2008 15:25:00 -0500

Tony -

I don't think that it is entirely procedural given the semantics of  
the well-known set. Rephrasing ...

point 1: The only well-known communities are those specified in 1997  
as they are old enough and widely deployed to the point that they are  
considered part of the foundation of BGP communities support.

point 2: calling any extensions to that subset (e.g. "ACCEPT_OWN")   
as well-known isn't appropriate as there is no guarantee of ubiquity  
of support

Issue: we know that we want to be able to add to the reserved set of  
values

If we care about the deployment ubiquity  of those titled "well- 
known" vs "allocated." Do we need a mechanism to signal that  
standardized communities are supported? Config mechanisms? Options  
include:

- dyn cap for each new value = painful signaling for each
- notion of "sets of allocated comms" that can have dyn cap for each  
set (insert issue of defn of the set) = move the problem to tomorrow
- required installation of configuration on devices for "identifying"  
comms until a version of SW can be loaded that supports the allocated  
comms
- do nothing and apply hope that an operator knows what they are doing

I prefer not to get caught in a chicken-egg situation of the  
semantics of "well-known" vs "allocated." There is clear precedence  
of being able to extend allocations of bits, flags, opaque_ids, etc  
and have incremental deployment.

-DWard

---

From: Brian Dickson <[email-masked]>
Date: Thu, 17 Jul 2008 16:39:04 -0400

> considered part of the foundation of BGP communities support.

I think that this can be handled, by analogy, by the status of the RFCs 
which cause new "well-known" communities to be allocated.

We have, in theory, a maturity level on standards-track RFCs, which can 
include:
Individual ID submission
WG ID
Proposed Standard
Draft Standard
Standard

I would submit that once a community's RFC-of-origin reaches DS, that it 
can be called "well-known".
Prior to that, perhaps some other term could apply, such as 
"soon-to-be-well-known community"?

I definitely am of the opinion that there is room for new well-known 
communities, and that, as such, the IANA registry makes a lot of sense.

I don't think how often we expect to expand the set, so long as we 
contemplate expanding it, it needs a registry.

If we intend on closing off the set at some point, we should do so in a 
standards-based manner, with a new RFC that memorializes the complete 
set, and terminates the IANA registry, all in one fell swoop, including 
text that reads "updates and obsoletes RFC 1997 (et al)".

Brian

P.S. Don't let the fact that I have an ID I'm presenting in Dublin, 
about just such a community, color your judgment on my opinion on this, 
please. :-)

> point 2: calling any extensions to that subset (e.g. "ACCEPT_OWN")  as 
> well-known isn't appropriate as there is no guarantee of ubiquity of 
> support
>
> If we care about the deployment ubiquity  of those titled "well-known" 
> vs "allocated." Do we need a mechanism to signal that standardized 
> communities are supported? Config mechanisms?
[...]
> I prefer not to get caught in a chicken-egg situation of the semantics 
> of "well-known" vs "allocated." There is clear precedence of being 
> able to extend allocations of bits, flags, opaque_ids, etc and have 
> incremental deployment.
>>
>> Dave,
>>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Jul 2008 16:42:56 -0400

On Thu, Jul 17, 2008 at 03:25:00PM -0500, David Ward wrote:
> point 1: The only well-known communities are those specified in 1997 as 
> they are old enough and widely deployed to the point that they are 

Indeed.  Much like RFC 4271 defines well-known as "implementations MUST
recognize all well-known attributes" I think the same could be said of
the well-known communities.

We're not going to be seeing any new well known BGP path attributes any
time soon I think.

I think all we're really looking for is:
- An IANA community registry
  - It should list the well-known communities
  - It should also provide registration for:
    - FCFS assigned communities
    - assigned by working group conensus.

-- Jeff

---

From: David Ward <[email-masked]>
Date: Tue, 29 Jul 2008 12:45:28 -0500

All -

I'll fire this off again so that folks have context for the  
discussion in IDR today and we can try to get consensus. The proposal  
is to effectively end the notion of allocating "well-known  
communities" and have "reserved code space." The well-known  
communities we have today are what we get. The claim is that given  
the state of the internet today, we are unable to determine when  
something is ubiquitously "well-known."

Please discuss as we will have no allocation of well-known or  
reserved BGP communities until some procedures have reached WG  
consensus. If it is felt that we must maintain "well-known  
communities," a reliable and guaranteed algorithm as to when a  
community is ubiquitously deployed has to be given otherwise we are  
simply stuck w/ the notion of "reserved."

Thanks

-DWard

On Jul 16, 2008, at 9:37 PM, David Ward wrote:

> but, there is no specified way to reserve new well-known- 
> communities. Here is the relevant quotation from RFC 1997:
>
> "COMMUNITIES attribute
>
> I am proposing a 50/50 split of the upper range of currently  
> reserved space between the "First Come First Served" policy defined  
> in RFC 2434 and those assigned by IANA using  either the Standards  
> Action process defined in RFC 2434, or the Early IANA Allocation  
> process defined in RFC 4020.
>
> 0x0000000-0x0000FFFF                                                 R 
> eserved
> 0xFFFFFF04          
> NOPEER                                             [RFC3765]
> community-01.txt that proposes that 0xFFFFFF05 be "ACCEPT_OWN."  
> This request would follow the 50/50 split proposal if the draft is  
> standardized.
>
>

---

From: Danny McPherson <[email-masked]>
Date: Tue, 29 Jul 2008 12:19:14 -0600

> simply stuck w/ the notion of "reserved."

I'm fine with this proposal, I think it makes sense.

-danny