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

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

Yakov,

> Bruno,
> 
> > Yakov, Srihari, Dan,
> >
> > >From RFC 4893 (BGP Support for Four-octet AS Number Space):
"Currently
> > assigned 2-octet Autonomous System numbers are converted into
4-octet
> > Autonomous System numbers by setting the two high-order octets of
the
> > 4-octet field to zero.  Such a 4-octet AS number is said to be
mappable
> > to a 2-octet AS number."
> >
> > So it seems that a 2-octet Autonomous System would have two ways to
> > encode a Route Target or Route Origin:
> > - using a two-Octet AS Specific Extended Community as defined in
rfc4360
> > (BGP Extended Communities Attribute)
> > - using a four-octet AS specific extended community as described in
> > draft-ietf-l3vpn-as4octet-ext-community-00.txt
> >
> > It looks to me this could create interop issue for BGP/MPLS VPN,
even
> > within a 2 octet AS.
> >
> > IINM, may I suggest that you add a sentence in the draft to handle
such
> > case? (e.g., mandating the use of *Two*-Octet AS Specific Extended
> > Community, reserving the "mappable to a 2-octet" AS numbers, ...).
> 
> That seems reasonable. Could you propose the text.

Please find below a proposition. Feel free to reword it as you wish.

Thanks,
Regards,
Bruno



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.

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.