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

<bruno.decraene@orange-ftgroup.com> Fri, 17 October 2008 15:27 UTC

Return-Path: <l3vpn-bounces@ietf.org>
X-Original-To: l3vpn-archive@megatron.ietf.org
Delivered-To: ietfarch-l3vpn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622EF3A6A8F; Fri, 17 Oct 2008 08:27:25 -0700 (PDT)
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC343A697F for <l3vpn@core3.amsl.com>; Fri, 17 Oct 2008 08:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFfZv4N6Cq8h for <l3vpn@core3.amsl.com>; Fri, 17 Oct 2008 08:27:23 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 8456F3A67AC for <l3vpn@ietf.org>; Fri, 17 Oct 2008 08:27:22 -0700 (PDT)
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 17:28:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-ietf-l3vpn-as4octet-ext-community-00.txt
Date: Fri, 17 Oct 2008 17:28:21 +0200
Message-ID: <5A0FF108221C7C4E85738678804B567C06AD3152@ftrdmel3>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-l3vpn-as4octet-ext-community-00.txt
thread-index: Ackorol8W8TNIvhWStSK3w5H9rxnIQHtpGjQ
References: <5A0FF108221C7C4E85738678804B567C06A15829@ftrdmel3> <200810071855.m97ItLM88396@magenta.juniper.net>
From: bruno.decraene@orange-ftgroup.com
To: yakov@juniper.net
X-OriginalArrivalTime: 17 Oct 2008 15:28:21.0643 (UTC) FILETIME=[FD0675B0:01C9306C]
Cc: tappan@cisco.com, rsrihari@cisco.com, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
Sender: l3vpn-bounces@ietf.org
Errors-To: l3vpn-bounces@ietf.org

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.