Re: [Idr] 4-byte AS community encoding (was re: wide communities)

[Jeffrey Haas <[e-mail]>]

On Mon, Jul 26, 2010 at 03:39:14PM +0200, Robert Raszuk wrote:
> I was aware about the below draft, but it's proposed encoding has few  
> serious disadvantages as compared with the encoding in Wide BGP  
> Community draft.

For what it's worth, I happen to agree with your comments below, but we do
not consider these to be disadvantages.

> Let me list those:
>
> 1. It uses extended community type of extended communities rather then  
> regular type - the consequence of this deep nesting is loosing one octet  
> of action field which may be of real value. Today I have two uses of  
> actions and today I have heard comments proposing additional value about  
> drop flag at AS boundary even if it is supported.

The scope of this draft is meant to provide feature parity with RFC 1997
and company.  As I mentioned in the original e-mail, I find the additional
features of wide communities and flexible communities to have merit.
I also think we could use a simple and quick to deploy feature that provides
for the 4-byte AS representations of these generic communities.

I believe that the work on wide/flexible communities should proceed
simultaneously.

Given our perceived requirements we don't consider the loss of an octet to
be important.  See also below.

> 2. This draft is based on RFC 5668 4-Octet AS Specific BGP Extended  
> Community which explicitly says in it's section 3:
>
>    Therefore, for backward compatibility with existing deployments and
>    to avoid inconsistencies between 2-octet and 4-octet specific
>    extended communities, Autonomous Systems that use 2-octet Autonomous
>    System numbers SHOULD use 2-octet AS specific extended communities
>    rather than 4-octet AS specific extended communities.
>
> But regardless of this mandate text of the RFC the draft in it's current  
> form still tries to use it for both 2-octet AS and 4-octet ASes. To  
> follow RFC 5668 and base BGP communities encoding on it we would still  
> use standard BGP communities for 2 octet ASes and this extended  
> community of extended type for 4 octet AS.

We agree. :-)

We consider the use of this functionality as a way to utilize existing
code.  Very importantly, we are *not* trying to invent a completely new way
to encode communities.  In my opinion, not speaking for all of the
coauthors, this increases the likelihood of having this feature deployed by
a number of vendors in short order.

You are correct in that a set of 2 communities, one with a 2-byte AS and one
with a 4-byte AS would result in a RFC 1997 community and an extended
community.  On the wire encoding isn't terribly important as long as the
semantics are clear for overlap.

> Also last but not least the draft  
> dhrao-idr-4octet-extcomm-generic-subtype does not define a notion of AS  
> specific communities which clearly may have good applications even at  
> customer-ISP boundary.

That is not its intended purpose.  Again, see my original comment about
proceeding with the additional functionality work covered by wide and
flexible communities.

-- Jeff