Fwd: Re: [Idr] Last Call: <draft-ietf-idr-rfc4893bis-06.txt> (BGP Support for Four-octet AS Number Space) to Proposed Standard

Stewart Bryant <stbryant@cisco.com> Tue, 12 June 2012 14:25 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C331F21F85C7; Tue, 12 Jun 2012 07:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2Sc7O9l0O+Am; Tue, 12 Jun 2012 07:25:36 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0BEFC21F85AE; Tue, 12 Jun 2012 07:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3140; q=dns/txt; s=iport; t=1339511136; x=1340720736; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WOGT0lESNND4R+zquSAfl5kfhD9AHxG7YiFg/doMqKU=; b=Tzn8RXdQqdCc6RTjtN03PfVft/t/CKHxKwUjkJ+YiHUbazMgmcl+ZqAu lZa+zr4iFU75QxtFtf0BueSpvvItmNLd/SXKVHT+Hmk+iw4za2XOk1mqQ gH6PkbqWx8aHIXe9oaVaTmgg2iFb5i80nhS5M88l4KJx94cXSVebCpaVr U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="5694672"
Received: from ams-core-3.cisco.com ([]) by ams-iport-4.cisco.com with ESMTP; 12 Jun 2012 14:25:34 +0000
Received: from cisco.com (mrwint.cisco.com []) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5CEPYZw026352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 14:25:34 GMT
Received: from dhcp-bdlk10-data-vlan300-64-103-106-111.cisco.com (localhost []) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q5CEPYkH020306; Tue, 12 Jun 2012 15:25:34 +0100 (BST)
Message-ID: <4FD7515E.3000101@cisco.com>
Date: Tue, 12 Jun 2012 15:25:34 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0
MIME-Version: 1.0
To: "Ietf@ietf.org" <Ietf@ietf.org>
Subject: Fwd: Re: [Idr] Last Call: <draft-ietf-idr-rfc4893bis-06.txt> (BGP Support for Four-octet AS Number Space) to Proposed Standard
References: <20120612135455.GC18025@diehard.n-r-g.com>
In-Reply-To: <20120612135455.GC18025@diehard.n-r-g.com>
X-Forwarded-Message-Id: <20120612135455.GC18025@diehard.n-r-g.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: idr mailing list <idr@ietf.org>, "idr-chairs@tools.ietf.org" <idr-chairs@tools.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2012 14:25:38 -0000


Copying to IETF list as this is an IETF LC


-------- Original Message --------
Subject: 	Re: [Idr] Last Call: (BGP Support for Four-octet AS Number 
Space) to Proposed Standard
Date: 	Tue, 12 Jun 2012 15:54:55 +0200
From: 	Claudio Jeker <cjeker@diehard.n-r-g.com>
To: 	Stewart Bryant <stbryant@cisco.com>
CC: 	<idr@ietf.org>

On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote:
> On 01/06/2012 23:00, Claudio Jeker wrote:
> >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote:
> >>The IESG has received a request from the Inter-Domain Routing WG (idr) to
> >>consider the following document:
> >>- 'BGP Support for Four-octet AS Number Space'
> >>   <draft-ietf-idr-rfc4893bis-06.txt> as Proposed Standard
> >>
> >>The IESG plans to make a decision in the next few weeks, and solicits
> >>final comments on this action. Please send substantive comments to the
> >>ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be
> >>sent to iesg@ietf.org instead. In either case, please retain the
> >>beginning of the Subject line to allow automated sorting.
> >>
> >>Abstract
> >>
> >>
> >>    The Autonomous System (AS) number is encoded as a two-octet entity in
> >>    the base BGP specification. This document describes extensions to BGP
> >>    to carry the Autonomous System numbers as four-octet entities.  This
> >>    document obsoletes RFC 4893.
> >>
> >Just for the sake of clarity, OpenBGPD will not do the following:
> >
> >    In addition, the path segment types AS_CONFED_SEQUENCE and
> >    AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute
> >    of an UPDATE message.  A NEW BGP speaker that receives these path
> >    segment types in the AS4_PATH attribute of an UPDATE message from an
> >    OLD BGP speaker MUST discard these path segments, adjust the relevant
> >    attribute fields accordingly, and continue processing the UPDATE
> >    message.  This case SHOULD be logged locally for analysis.
> >
> >There is no point to do this fiddeling instead we will treat this like any
> >other parse error of AS4_PATH.
> >
> Claudio
> Since this is in last call, I have to ask whether you have objection
> to the publication
> of the above text, or have any proposed text changes?

I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping
on all AS4 implementations. It forces bgp implementations that don't have
confederation support to strip out something that will cause an error in
the regular path and for those systems ignoring the AS4_PATH attribute
is perfectly fine. I do not understand how a workaround needs to be a
MUST for something that is a MUST NOT at the same time? Why MUST we
workaround something that MUST NOT appear? Why do we need to add extra
code that is hard to test and maybe cause for further errors because it
modifies attributes in very uncommon way?

I propose to remove that paragraph entierly since it does only add
complexity to the protocol for no reason and therefor is only a source of
errors without any benefit.
:wq Claudio