Subject: [Idr] WG Last Call on Proposed IANA procedures for BGP Well-known communities

From: Yakov Rekhter <[email-masked]>
Date: Thu, 07 Aug 2008 07:24:08 -0700

Folks,

This is to start IDR WG Last Call on the proposal described
below. The Last Call ends Aug 20, 2008.

Yakov.
------- Forwarded Message
> From: David Ward <[email-masked]>
> Date: July 29, 2008 12:45:28 PM CDT
> To: David Ward <[email-masked]>
> Cc: idr <[email-masked]>, [email-masked], Yakov Rekhter  
> <[email-masked]>
> Subject: Re: [Idr] Proposed IANA procedures for BGP Well-known  
> communities
>
> 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:
>
>> 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
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Brian Dickson <[email-masked]>
Date: Mon, 11 Aug 2008 10:44:44 -0400

I'll be brief with my comments.

I actually *do* support the establishment of a formal process by which 
IANA allocations for BGP communities are made,
and the separation of the name space (number space) as proposed.

However, I *strongly* feel that it would be inappropriate to foreclose 
the ability to establish new
communities whose characteristics need to correspond to those of the 
already-established well-known
communities.

Here's the problem: If we make a mistake *here*, and later determine 
that there is a new need for a well-known
community, the steps required to actually establish a new WKC would be, 
at a minimum:
1) create a new RFC to replace this proposal, effectively overturning 
this proposal
2) do everything else that would otherwise be needed if this proposal 
included a WKC process, with a reliable and
guaranteed algorithm.

I further believe that RFC 4020 itself provides the necessary guidance 
for creating such an algorithm.

The main criteria should be, IMHO, that a proposal be Standards Track, 
and thus that the algorithm be simply
Standards Action, with Early Code Point Allocation.

The bar is pretty high for such allocations, much higher than for FCFS. 
And, the existence of a FCFS sub-block
should be sufficient for non-Standards-Track use.

The process itself, IMHO, *should* require that during the Early 
Allocation period, of 1 year with possibly 1 extension
of 1 year, that there be demonstrated multiple interoperable 
implementations of the "proposed WKC".

The recommendations to the WG on what criteria should be met by a 
"proposed WKC", i.e. those which the WG chair
as well as the WG members should consider, IMHO should be:
- (The following presume that Reserved values of BGP Communities are not 
in use anywhere, by anyone; any such use should not be a consideration. 
Caveat emptor.)
- ubiquitous deployment (in code, by router vendors), without changes to 
router configurations, will cause no harm
- implementation of desired function via router configuration, is 
impossible, impractical, or infeasible (e.g. introduces "catch-22", or 
massive scaling problems)
- is compatible with, and does not conflict with, and does not share 
dependencies with, any other BGP RFC (beyond the standard normative 
sense) - i.e. is standalone and doesn't break anything else
- has compelling benefit

The issues for WG approval of Early Code Point Allocation, and adoption 
of an ID as a WG item, should be different from those of the IESG 
Approval requirements.
The WG approval should *not* be contingent on any assessment of "global" 
deployment, to reach "well known" status.
It should be understood that, even in the presence of a new IANA 
allocation, that the support for the new allocations is dependent upon, 
and documented by, a Standards Track RFC.

As such, the question of compliance with Standards Track RFCs is for 
implementers (and their presumed deployment base, market, and community 
at large).

However, in progressing the RFC, the IESG *should* give reasonable 
consideration to the adoption of the new IANA code point by implementers.

In summary, I believe that BGP Communities are very valuable tools, and 
that Well-Known Communities are, and will continue to be, an important 
part of that set of tools.
We should both facilitate augmenting that set of tools, and protect the 
perceived value of those tools by ensuring a well-understood, practical, 
and effective process exists for adding to the set of Communities 
available, both on a First-Come, First-Served, and on a Standards Action 
(formerly Well-Known) basis.

Perhaps renaming Well-Known to Standards Action, with a 1997-bis, would 
be the most harmonious approach to this issue...

Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Mon, 11 Aug 2008 20:27:00 -0400

Thanks to Thomas M. Knoll, there is now a poll available for soliciting 
opinions regarding the subject of this message.

(Proposed IANA procedures for BGP Well-known communities.)

http://www.bgp-qos.org/forum/viewforum.php?f=12

In the interests of gauging the WG's collective opinions on the general 
proposal, and on my specific suggestions on how future community 
proposals might be evaluated, you are all invited to participate in the 
poll.

Of course, follow-ups (either in the forum, or on the IDR list) are also 
strongly encouraged.

It's a short poll, just a few questions, but will likely help inform the 
WG chair as to the sense of the "room".

Thanks,

Brian Dickson

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 11 Aug 2008 22:07:46 -0400

Brian,

On Mon, Aug 11, 2008 at 10:44:44AM -0400, Brian Dickson wrote:
> However, I *strongly* feel that it would be inappropriate to foreclose the 
> ability to establish new

[And you elaborate on that.]

I'll point out again that "well-known" has wording similarities going
back to the base BGP RFC.  We don't expect any more "well known" path
attributes to pop up.  Matter of fact, it'd be a protocol violation for
them to occur.

Well known communities similarly imply pervasive deployment.  Anything
"new" is unlikely to be pervasive for years to come.  If you're really
lucky, it's possible to similate the behavior of a new "well known"
community via configuration.  One should not count on this.

This isn't to say that new communities will not be standardized with
pervasive deployment in years to come.  Consider the examples of route
reflection and confederations.  You will unlikely encounter anything
beyond a toy BGP implementation that doesn't have these features
implemented and yet they're not necessarily "required" by the BGP
standards.

I continue to object to the labeling of newer communities as "well
known" since they won't meet the "pervasive test".  That won't stop
communities assigned by the other means from being "pervasively
deployed" over their lifetime.  

One could even use the vendor litmus test as "important enough to get
assigned via working group consensus."

-- Jeff

---

From: Brian Dickson <[email-masked]>
Date: Mon, 11 Aug 2008 23:44:04 -0400

Jeff(rey),

> attributes to pop up.  Matter of fact, it'd be a protocol violation for

Very true. It is also true that BGP has been significantly expanded with 
the addition of multi-protocol extensions.
As such, some of the terminology from the base RFC might not be 
sufficiently inclusive to describe the larger thing that BGP has become.

This is one reason I am suggesting that, rather than add to the set of 
things labeled "Well Known", that we instead consider the original set 
of WKC's to be the anchor tenants of a thing more inclusively (and more 
appropriately) call "Standards-Action Communities" - things for which 
Standards-Track RFCs have been issued, and which have been assigned IANA 
values from the Standards-Action range (versus First-Come, First-Served).

> implemented and yet they're not necessarily "required" by the BGP

Very good point. I totally agree, and I think this actually is in line 
with the point I was trying to make.

If we had made it procedurally very difficult to establish RR's and 
confed's, what would the result have been?
(Rhetorical question, of course.)

> deployed" over their lifetime.  

Yep - see above.

> assigned via working group consensus."

As long as we have the ability to break the chicken-egg deadlock which 
prevents any initiative in this regard, I agree.

Basically, what is missing, in addition to some formalization of the 
process, is the ability to use RFC 4020 Early IANA Assignments, from 
which early work can progress from draft, to initial implementation, to 
multi-vendor implementation, to working group consensus. The whole 
"consensus and running code" thing, which I absolutely agree with, 
particularly in the IDR area (where, more than anywhere else, 
interoperability is "it").

BTW - even if over the long haul, a non-trivial number of such Early 
Assignments are made, and subsequently abandoned, with the number of 
possible values available (32K), there is no substantial risk involved 
in actually using the RFC 4020 process.

While our positions aren't necessarily entirely in agreement, I think in 
the important aspects, they happen to meet at the place where this 
proposal sits...
Does this appear to be the case, from your perspective?

Brian

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 12 Aug 2008 06:31:15 -0700

Brian,

> proposals might be evaluated, you are all invited to participate in the 

Speaking as an IDR WG co-chair, please note that the IDR WG consensus
is determined using the IDR WG mailing list, and not by the results
of the poll you mentioned above.

So, "gauging the WG's collective opinion" on any proposal, is done
on the IDR mailing list, and not by participating in the poll you
mentioned above.

> WG chair as to the sense of the "room".

See above.

Yakov.

---

From: "Thomas M. Knoll" <[email-masked]>
Date: Tue, 12 Aug 2008 16:30:34 +0200 (MEST)

Yakov - 
you are right, the email list is the place to determine WG consensus.

The online polls are just there for convenience and in order to stick 
to the email list rule, their results shall be posted to the list _once_, 
say during the weekend.
I am neutral to the actual discussion, but I thought the online poll could 
serve as convenient service to the wg.
The available online poll options are documented below.
Thomas

--------------------------------------------------------------------------
{leave blank [ ] or tick [X] to indicate your selection}

Which way do you support Brian's proposal?
No selection limitation
   [  ] Support generally the adoption of such a proposal
   [  ] Do not support generally the adoption of such a proposal
   [  ] If yes to the first, support Standards Action plus FCFS
   [  ] If yes to the first, support just FCFS

Well-Known vs. Standards-Action
You may select 1 option
   [  ] Rename Well-Known to Standards-Action?
   [  ] Add an 'Also Known As Standards-Action' to Well-Known?
   [  ] Neither one

Assignment strategy options
You may select 1 option
   [  ] Support Early Assignment of Standards-Action Communities, per RFC
          4020?
   [  ] Do not support Early Assignment of Standards-Action Communities,
          per RFC 4020?
   [  ] Allow Early Assignment for Individual Internet Drafts?
   [  ] Do not allow Early Assignment for Individual Internet Drafts (WG
          drafts only)?

What does 'Well-Known' status represent?
You may select 1 option
   [  ] multiple implementations
   [  ] other -> please post a reply with the criteria

Allotted time for achieving 'Well-Known' (permanent) status for any Early 
Assignments?
You may select 1 option
   [  ] 6 months
   [  ] 1 year
   [  ] 18 months
   [  ] 2 years
   [  ] other -> please post your criteria
   [  ] never

--------------------------------------------------------------------------

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 12 Aug 2008 07:35:04 -0700

Thomas,

> to the email list rule, their results shall be posted to the list _once_, 

Just to make it clear, the results of this poll have no impact on 
determining the IDR WG consensus.

Yakov.

---

From: "Cayle Spandon" <[email-masked]>
Date: Tue, 12 Aug 2008 11:44:20 -0400

>  [ X ] Support generally the adoption of such a proposal
>  [ X ] If yes to the first, support Standards Action plus FCFS
>  [ X ] Add an 'Also Known As Standards-Action' to Well-Known?
>  [  ] Neither one
>
>  [ X ] Support Early Assignment of Standards-Action Communities, per RFC
>         4020?
>  [ X ] Do not allow Early Assignment for Individual Internet Drafts (WG
>         drafts only)?
>
>  [ X ] multiple implementations
>  [ X ] 1 year

---

From: "Tony Li" <[email-masked]>
Date: Tue, 12 Aug 2008 21:43:30 -0700

Poll response, with commentary in line...

Largely, I think this whole discussion is a semantic quibble because of a
misunderstanding of the ability to declare something 'well-known'.  If we
simply select some other arbitrary term (e.g., global) and define it
reasonably, this entire discussion becomes moot.

|Which way do you support Brian's proposal?
|No selection limitation
|   [X] Support generally the adoption of such a proposal
|   [  ] Do not support generally the adoption of such a proposal
|   [X] If yes to the first, support Standards Action plus FCFS
|   [  ] If yes to the first, support just FCFS

I have no objections to Brian's technical content.  However, I'm concerned
about the semantic usage of the term 'well-known'.  As has been discussed,
this bit of terminology has been around for a very long time and we can't
easily go redefining it without creating mass confusion.  Thus, I believe
it's very difficult to add new well-known communities (or path-attributes)
at this late date.  We should simply accept this reality and move on.

|Well-Known vs. Standards-Action
|You may select 1 option
|   [  ] Rename Well-Known to Standards-Action?
|   [  ] Add an 'Also Known As Standards-Action' to Well-Known?
|   [x] Neither one

Why not simply have a "standards action" (or similarly named) class of code
points.  One then says that compliance with a given RFC requires a specific
interpretation of a given community value?

|Assignment strategy options
|You may select 1 option
|   [x] Support Early Assignment of Standards-Action 
|Communities, per RFC
|          4020?
|   [  ] Do not support Early Assignment of Standards-Action 
|Communities,
|          per RFC 4020?
|   [x] Allow Early Assignment for Individual Internet Drafts?
|   [  ] Do not allow Early Assignment for Individual Internet 
|Drafts (WG
|          drafts only)?
|
|What does 'Well-Known' status represent?
|You may select 1 option
|   [  ] multiple implementations
|   [  ] other -> please post a reply with the criteria

As defined earlier, well-known implies that it is supported by ALL
implementations that support the base specification.  As those
implementations are already in the field, you cannot subsequently declare
those implementations non-compliant.

|Allotted time for achieving 'Well-Known' (permanent) status 
|for any Early 
|Assignments?
|You may select 1 option
|   [  ] 6 months
|   [  ] 1 year
|   [  ] 18 months
|   [  ] 2 years
|   [X] other -> please post your criteria
|   [  ] never

Why not just allow the standards track to progress?

Tony