[Idr] draft-ietf-idr-as-pathlimit-02 status, path forward

Joe Abley <jabley@ca.afilias.info> Mon, 25 September 2006 16:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtFd-0006jh-3V; Mon, 25 Sep 2006 12:24:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtFc-0006gI-3g for idr@ietf.org; Mon, 25 Sep 2006 12:24:12 -0400
Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtFa-00075X-P6 for idr@ietf.org; Mon, 25 Sep 2006 12:24:12 -0400
Received: from yxu1a18.hopcount.ca ([199.212.90.18]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.63 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>) id 1GRtFJ-00023f-2Q; Mon, 25 Sep 2006 16:23:53 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <274EA0E3-E124-4D42-8475-48A1C0F9FA40@ca.afilias.info>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@ca.afilias.info>
Date: Mon, 25 Sep 2006 12:23:46 -0400
To: Inter-Domain Routing List <idr@ietf.org>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Subject: [Idr] draft-ietf-idr-as-pathlimit-02 status, path forward
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Hi all,

A quick note on the status of draft-ietf-idr-as-pathlimit-02. There  
are some questions for Yakov and Sue down below, but since it has  
been a while I thought I'd also include a brief summary for the  
benefit of the wg. Skim down to "Operator and Vendor Support" to  
avoid the background.


Background

This draft proposes a new BGP attribute intended to help limit the  
number of ASes a prefix might propagate through. This is an  
complementary approach to the idea of include/exclude lists, which  
for example are available in IDRP: include/exclude lists for when you  
know the topology, as-pathlimit for when you don't.

This draft was originally published as draft-li-as-hopcount-00, and  
was adopted as an IDR working group document in November/December 2005.

The draft was discussed and revised in response to feedback from the  
working group. There have been no further issues raised since draft- 
ietf-idr-as-pathlimit-02, as far as I know. -02 was published in June  
2006.

In order to be implemented, the new capability needs a code point  
assignment from the IANA's BGP path attribute type code registry. For  
this reason the only available option for publishing this document is  
on the standards track (there are no code point allocations available  
for informational/experimental documents).

New BGP capabilities require an implementation report before they can  
be published, but without a code point assignment the new capability  
is hard to implement in any meaningful way. RFC 4020 contains  
directions for working around this apparent catch-22, in the form of  
an "early allocation code point".

The authors of this draft sent a request for such a code point to the  
IDR chairs in June 2006. The chairs replied in July requesting data  
to support the assertion that there was vendor and operator interest  
in the capability.

There was then a long period of silence during which I changed jobs  
and moved house. Sorry about that.


Operator and Vendor Support

The following is a brief summary of feedback received by people  
asking whether they would implement or deploy the as-pathlimit  
capability, following an oblique reference on the NANOG list.  
Affiliations, where given, are for identification purposes only.

Yakov/Sue: if you could comment on what specific additional support  
you would need before requesting an early allocation, that would be  
great. I'm very happy to do a less ad-hoc, more targeted survey.

"plans to deploy" below means "if supported by my vendors", obviously.


Document Editors

Joe Abley, Afilias Canada (Afilias plans to deploy)
Tony Li, Tropos Networks
Rex Fernando, Amoora, Inc.

Operators

Rob Seastrom (plans to deploy)
Jonny Martin, Citylink (plans to deploy)
Jamie Baddeley, FX Networks (plans to deploy)
Steve Gibbard, PCH (supportive, but no current need for it)
Leo Bicknell (supportive, but no current need for it)
Scott Leibrand, Internap (plans to deploy)
Philip Smith, Cisco (on behalf of pacrim operators that he consults  
for, plans to deploy)
Joao Damas, ISC (plans to deploy)
Brian Dickson, Afilias Canada (plans to deploy)

Vendors

Henning Brauer, OpenBSD/OpenBGPD ("if we get a high quality patch,  
I'm very willing to strongly consider it for inclusion.")
Srihari Sangli, Cisco (will implement in IOS XR if published on the  
standards track)
Brian Dickson, Afilias Canada (will implement in Quagga)


Joe

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr