Re: [Idr] Support for 4-byte generic communities in BGP

Jeffrey Haas <jhaas@pfrc.org> Fri, 21 November 2008 19:12 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531653A67C0; Fri, 21 Nov 2008 11:12:44 -0800 (PST)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CCB3A68CC for <idr@core3.amsl.com>; Fri, 21 Nov 2008 11:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 5AF-bia4PBuW for <idr@core3.amsl.com>; Fri, 21 Nov 2008 11:12:42 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 2673C3A67C0 for <idr@ietf.org>; Fri, 21 Nov 2008 11:12:42 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D6A84244050; Fri, 21 Nov 2008 19:12:40 +0000 (UTC)
Date: Fri, 21 Nov 2008 14:12:40 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Cayle Spandon <cayle.spandon@gmail.com>
Message-ID: <20081121191240.GA2615@slice>
References: <200811021527.mA2FR0M34537@magenta.juniper.net> <20081118185010.GD23366@slice> <20081121005130.GA27200@slice> <71c13900811210646u5fcb7e26s31a486c1d9e1dba4@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <71c13900811210646u5fcb7e26s31a486c1d9e1dba4@mail.gmail.com>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: idr@ietf.org
Subject: Re: [Idr] Support for 4-byte generic communities in BGP
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Cayle,

Thanks for your support and comments:

On Fri, Nov 21, 2008 at 09:46:08AM -0500, Cayle Spandon wrote:
> Only 2 bytes for the Local Administrator field seems very restrictive.

It is, however, consistent with the other similar drafts.

See draft-ietf-l3vpn-as4octet-ext-community-01.txt

> Do we need a capability (for capability negotiation) for this? (Just
> because a speaker supports 4-octet AS numbers does not necessarily
> imply it supports 4-octet AS numbers in extended communities).

I don't believe capability negotiation will be required.  Somewhat per
the draft's Deployment Consideration section, if the ISP doesn't support
a 4-octet extended community but does use 4-octet ASes, they can define
a two octet AS as their transition mechanism.

If you believe stronger text to address this point should be in the
Deployment Considerations, I believe that could be added.

> Do we need rules on what to do when a NEW speaker sends an UPDATE with
> a 4-octet extended community to an OLD speaker (similar to section
> 4.2.2. of [RFC4893])?

I don't believe so.  It is possible to support 4-octet communities
without supporting 4-octet ASes and vice versa.  It is, however,
necessary for ISPs to negotiate which communities they will use for
signalling.  This is no different than ISPs having to decide which
communities they'll send and accept.

My expectation is that transitionally ISPs will provide 2-octet
communities along with 4-octet ones.

> It seems relatively straightforward to include all relevant
> information in this draft and remove the references to
> [I-D.ietf-l3vpn-as4octet-ext-community
> <http://tools.ietf.org/html/draft-dhrao-idr-4octet-extcomm-generic-subtype-00#ref-I-D.ietf-l3vpn-as4octet-ext-community>]
> (this makes it a "stand-alone" draft).

Excellent point. Thanks.

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr