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

From: Joe Abley <[email-masked]>
Date: Mon, 25 Sep 2006 12:23:46 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 26 Sep 2006 15:11:50 -0400 (EDT)

Yakov and Joe,

Having just subscribed to idr-post, I'm not familiar with any WG
discussion of the draft previous to Sep 25, but I have read the draft and
provided some feedback to the authors (as evidenced by my name being on
Joe's message yesterday).  I'd therefore like to formally express support
for moving forward with the draft and allocating a new BGP attribute code
point to allow implementation to proceed.

-Scott

For the record, here are the comments I sent the authors a while back:

On 07/18/06 at 8:19pm -0400, Scott Leibrand <[email-masked]> wrote:
>
> Date: Tue, 18 Jul 2006 20:19:41 -0400 (EDT)
> From: Scott Leibrand <[email-masked]>
> To: Joe Abley <[email-masked]>
> Cc: Tony Li <[email-masked]>, Rex Fernando <[email-masked]>,
> Subject: Re: as-pathlimit capability
>
> Joe,
>
> Robert forwarded me your message, and I thought I'd reply with my
> expression of interest, as well as a few comments.
>
> Firstly, I would definitely like to see our router vendors implement this.
> We would definitely like to be able to set an AS_PATHLIMIT on a number of
> the more-specifics we advertise.
>
> Comments on the draft:
>
> I think there is one possible security issue you might want to address
> in Security Considerations.  Namely, if a route hijacker wanted to put
> himself on-path for a given prefix (to sniff the traffic or otherwise mess
> with it, then send it along to its real destination), then the
> AS_PATHLIMIT attribute would allow him to do so with more precision.  It
> would also reduce accountability if the looking glasses being used to
> detect injection of more-specifics don't happen to be within the
> AS_PATHLIMIT radius.  The same things are all true of NO_EXPORT, of
> course, but a more precise tool would be useful to the bad guys as well as
> the good guys.
>
>
> I'm also a bit confused by your ATOMIC_AGGREGATE comments.  Hopefully you
> can clarify things for me so that everything that follows is irrelevant,
> but here I go...  :)
>
> While I understand that ATOMIC_AGGREGATE is mandatory when automatically
> aggregating routes, in most cases an aggregate is simply redistributed
> independently into BGP, having originally been tied down to an interface
> (or Null0), while the longer prefix (sometimes with a different AS path)
> is dropped or passed along independently, based on policy or NO_EXPORT.
> My reading of the draft is that if I have a more-specific that I put
> AS_PATHLIMIT on, then any AS who drops the route due to my AS_PATHLIMIT
> will have to change my less-specific route and add ATOMIC_AGGREGATE to it.
> IMO this is a Bad Thing, to have my upstreams modifying my aggregate
> routes.  The draft recommends that if I do this I also advertise the
> ATOMIC_AGGREGATE attribute on my less-specific.  However, this seems to be
> a paradigm shift from the way most of the world uses BGP, in that it
> requires me to automatically aggregate my routes rather than advertising
> the larger aggregate separately as a null tiedown, or to somehow configure
> my null tiedown to be redistributed into BGP with ATOMIC_AGGREGATE set
> (which I don't think I can do on my routers today).
>
> IMO a much cleaner behavior is to simply extend BGP's current behavior as
> follows:
>  - If a route has AS_PATHLIMIT on it and the path limit is met or
> exceeded, drop it the same way you would a route with NO_EXPORT on it,
> without any regard to presence or absence of less specific prefixes.
>  - If routes happen to be aggregated with aggregate-address or similar,
> set AS_SET and ATOMIC_AGGREGATE as you do today.
>  - If an aggregate is created by redistribution from an IGP, don't set
> ATOMIC_AGGREGATE on it, and don't modify it later based on actions taken
> on a route that happens to be a more specific.
>
> Thanks for your work on this,
> Scott

Begin forwarded message:

> From: Yakov Rekhter <[email-masked]>
> Date: 26 September 2006 14:12:26 EDT (CA)
> To: [email-masked]
> Cc: [email-masked], [email-masked], Joe Abley
> <[email-masked]>
> Subject: [Idr] draft-ietf-idr-as-pathlimit-02 status, path forward
>
> Folks,
>
> This e-mail is to find if there is a consensus within the IDR WG for a
> request for an early allocation of a new BGP attribute code point
> as specified in draft-ietf-idr-as-pathlimit-02.
>
> Please send your comments on this request. The deadline for comments
> is Oct 10, 2006.
>
> Yakov.
>
> P.S. Please remember that silence does not count (either way).
>