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

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
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr