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

Jeff,

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.

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.

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.

I find it much cleaner to define a new regular type and propose clear 
semantics allowing for 4 octets and 2 octets ASes to be encoded.

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.

Thx,
R.

> WG,
>
> My apologies for the confusion about this draft during the presentation on
> wide communities.  The following draft apparently became orphaned while we
> were trying to figure out what WG to get to adopt this - IDR or l3vpn.
>
> http://tools.ietf.org/html/dhrao-idr-4octet-extcomm-generic-subtype-00
>
> I believe this is a somewhat less contentious encoding for generic
> communities that are capable of containing 4 byte ASes.  Since I was also a
> contributor to the flexible community draft I believe that functionality is
> also useful, but if the primary goal is to get a 4-byte AS capable
> community, we offer this as a potential solution.
>
> I would like propose to the WG the following:
> - Adopt the above draft as a generic encoding of 4-byte communities.
> - Continue the exploration of solutions for the additional functionality
>    covered by wide communities and the flexible community document.
>
> I don't believe the flexible community authors are overly concerned about
> our specific encoding mechanisms for the additional functionality covered by
> the two different drafts.  However, I'd suggest continuing that discussion
> separately from 4-byte AS communities.
>
> -- Jeff
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>