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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Putting flexible communities aside I really see very little development 
difference in providing support for the quoted draft encoding vs wide 
BGP community encoding.

It is just wide BGP community seems more flexible and less nested then 
what has been proposed in yr draft with the exact same parsing/matching 
simplicity in both. That is assuming that we are just talking about 
simple customer assigned local values.

I see no particular value of having customers forced to go via any 
intermittent step :).

And as discussed at the meeting today for that very purpose decoupling 
encoding from filling the registry for the actual recognized values 
seems a wise idea.

So what I propose we could do two things .. merge the drafts or have 
customers and WG pick the more preferred one :) I will split my current 
one and re-post after IETF and let's then resume the conversation.

What do you think ?

Cheers,
R.



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