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

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 <sleibrand@internap.com> wrote:
>
> Date: Tue, 18 Jul 2006 20:19:41 -0400 (EDT)
> From: Scott Leibrand <sleibrand@internap.com>
> To: Joe Abley <jabley@ca.afilias.info>
> Cc: Tony Li <tony.li@tony.li>, Rex Fernando <rex_f@yahoo.com>,
> 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 <yakov@juniper.net>
> Date: 26 September 2006 14:12:26 EDT (CA)
> To: idr@ietf.org
> Cc: yakov@juniper.net, skh@nexthop.com, Joe Abley
> <jabley@ca.afilias.info>
> 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).
>

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