[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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