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

From: <[email-masked]>
Date: Mon, 6 Oct 2008 11:40:11 +0200

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

Thanks,
Best regards,
Bruno

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 07 Oct 2008 11:55:21 -0700

Bruno,

> Community, reserving the "mappable to a 2-octet" AS numbers, ...).

That seems reasonable. Could you propose the text.

Yakov.

---

From: <[email-masked]>
Date: Fri, 17 Oct 2008 17:28:21 +0200

Yakov,

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

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 17 Oct 2008 09:07:48 -0700

Bruno,

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

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Fri, 17 Oct 2008 12:22:19 -0700

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

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 09:52:10 +0200

Hi Pradosh,

> "... even if they had the same Sub-Type and Local Administrator

You're right.
Thanks.

Bruno