RE: draft-ietf-l3vpn-as4octet-ext-community-00.txt

[<bruno.decraene at orange-ftgroup.com>]

Hi Pradosh,

> Hi Bruno, Yakov,
> 
> A nit below:
> 
> | > 3. Considerations for two-octet Autonomous Systems
> | >
> | > As per [RFC4893], a two-octet Autonomous System number can be
> | > converted into a 4-octet Autonomous System number by
> | setting the two
> | > high-order octets of the 4-octet field to zero.
> | >
> | > As a consequence, a two-octet Autonomous System could use both
> | > two-octet and four-octet AS specific extended communities. This is
> | > undesirable as both communities would be treated as
> | different even if
> | > they had the same Type, Sub-Type and Local Administrator values.
> 
> Would it be the same Type? Types are different based on whether
> a router encodes as a two-octet AS specific extcomm (00 or 40) or
> as a four-octet AS specific extcomm (02 or 42). So you should say
> "... even if they had the same Sub-Type and Local Administrator
> values.".

You're right.
Thanks.

Bruno

> - Pradosh
> 
> | >
> | > Therefore, for backward compatibility with existing
> | deployments and to
> | > avoid inconsistencies between two-octet and four-octet specific
> | > extended communities, two-octet Autonomous Systems SHOULD use
> | > two-octet AS specific extended communities rather than
> | four-octet AS
> | > specific extended communities.
> | >
> | > 9. Normative References
> | >
> | > [RFC4893] Vohra, Q., Chen, E., "BGP Support for Four-octet
> | AS Number
> | > Space", RFC 8993, May 2007.
> |
> | The text looks fine to me. In the absence of any objections
> | within the next week or so I'll integrate your text into the
> | draft and will issue a revised version.
> |
> | Yakov.
> |