Subject: [Idr] draft-ietf-as-pathlimit-02

From: Neil Matthew <[email-masked]>
Date: Wed, 18 Oct 2006 17:38:28 +0100

Hi Folks

I have a couple of questions regarding this draft.

1. Section 5.1 states that the route's AS_PATHLIMIT MUST NOT be 
modified.  Section 5.2 talks about attaching an AS_PATHLIMIT attribute 
but doesn't say anything about being permitted to remove it.  Am I 
permitted to 'change' a received AS_PATHLIMIT by deleting and 
re-adding?  Some email exchanges in the archive would seem to suggest 
the answer to this is yes.

2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm missing 
something here and I think that this has already been mentioned on the 
list before but it appears that the specified behaviour matches the old 
BGP RFC and not the latest RFC?  Are folks happy with the path-limit 
specification adopting the old style behaviour?  Actually I'd really 
appreciate it if someone could explain why this is required at all! :)

Cheers

Neil

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 19 Oct 2006 12:16:47 -0400 (EDT)

> appreciate it if someone could explain why this is required at all! :)

You may be referring (in part) to a comment I made a while back, which I
don't believe was ever answered:

> 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.

-Scott

---

From: Neil Matthew <[email-masked]>
Date: Mon, 30 Oct 2006 10:51:05 +0000

Time passes...

So, no takers on these?  Point 1 is just me looking for clarification 
but point 2 would appear to be a real issue.  I believe Jeffrey Haas has 
also expressed a concern 
(http://thread.gmane.org/gmane.ietf.idr/4001/focus=4005) so that's at 
least 3 of us!  If this is the way things are to be implemented I'd at 
least like to know why! :)

Cheers

Neil

Neil Matthew wrote:

> list before but it appears that the specified behaviour matches the 
> old BGP RFC and not the latest RFC?  Are folks happy with the 
> path-limit specification adopting the old style behaviour?  Actually 
> I'd really appreciate it if someone could explain why this is required 
> at all! :)
>
> Cheers
>
>
> Neil
>
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 30 Oct 2006 08:33:06 -0500

Hi Neil,

> Time passes...

Thorin sits down and starts singing about gold.

> So, no takers on these?  Point 1 is just me looking for  
> clarification but point 2 would appear to be a real issue.  I  
> believe Jeffrey Haas has also expressed a concern (http:// 
> thread.gmane.org/gmane.ietf.idr/4001/focus=4005) so that's at least  
> 3 of us!  If this is the way things are to be implemented I'd at  

I've been preoccupied with some other work; I apologise for not being  
behind. Interrupt contention.

>> modified.  Section 5.2 talks about attaching an AS_PATHLIMIT  
>> attribute but doesn't say anything about being permitted to remove  
>> it.  Am I permitted to 'change' a received AS_PATHLIMIT by  
>> deleting and re-adding?  Some email exchanges in the archive would  
>> seem to suggest the answer to this is yes.

My personal view is that it ought to be possible to remove an  
AS_PATHLIMIT attribute as part of the normal application of local  
policy within an AS, and that the draft should be modified to make  
this more clear.

[If you can do it with other, similar attributes (e.g. the  
NO_ADVERTISE and NO_EXPORT community string attributes) it makes no  
sense to me to prohibit this with AS_PATHLIMIT.]

It follows that removing an AS_PATHLIMIT attribute which is already  
present and then adding a replacement AS_PATHLIMIT attribute ought to  
be possible.

>> 2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm  
>> missing something here and I think that this has already been  
>> mentioned on the list before but it appears that the specified  
>> behaviour matches the old BGP RFC and not the latest RFC?  Are  
>> folks happy with the path-limit specification adopting the old  
>> style behaviour?  Actually I'd really appreciate it if someone  
>> could explain why this is required at all! :)

    BGP requires that a BGP speaker that advertises a less specific
    prefix, but not a more specific prefix that it is using, must
    advertise the less specific prefix with the ATOMIC_AGGREGATE
    attribute.  BGP speakers that do not advertise a more specific  
prefix
    based on the AS_PATHLIMIT must comply with this rule and advertise
    the less specific prefixes with the ATOMIC_AGGREGATE attribute.  To
    help ensure compliance with this, sites that choose to advertise the
    AS_PATHLIMIT path attribute should advertise the ATOMIC_AGGREGATE
    attribute on all less specific covering prefixes.

I think I'd be happy with removing this paragraph altogether,  
although it's before 9am and I have not yet reached my preferred  
caffeine levels so I reserve the right to disagree with myself at  
some later date. :-)

Joe