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