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

[Brian Dickson <[e-mail]>]

Jeff(rey),

Jeffrey Haas wrote:
> 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
>> communities whose characteristics need to correspond to those of the 
>> already-established well-known
>> communities.
>>     
>
> [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.
>
>   

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).

> 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.
>
>   

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.)

> 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.  
>
>   

Yep - see above.

> One could even use the vendor litmus test as "important enough to get
> 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
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr