Subject: RE: Active Route - OT

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 4 Oct 2002 11:34:40 -0400

Jeff:

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 11:02 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: Re: Active Route - OT
> 
> 
> Ben,
> 
> [is there any need to quote the entirety of messages?]
> 
> On Fri, Oct 04, 2002 at 10:26:02AM -0400, Abarbanel, Benjamin wrote:
> > Agreed, but as your example shows its possible to violate 
> the AS path
> > traversel
> > and not really forward packets along the path that the peer 
> thinks is
> > happening. Therefore, one solution would be not to 
> advertise the route if
> > the Routing Table and the BGP Loc-Rib/Adj-Rib-out(peer) do 
> not agree 100% on
> > the useage of that route. 
> 
> Please see my long original post on deprecating atomic_aggregate.
> Then please read Dennis Ferguson's posts on how the lack of
> full path information in aggregates isn't too much of a concern.
> 
> These reflect deployed reality.  You're talking about a spec change.
> 

Denying a route is not a spec change, but a policy decision.

Ben

> -- 
> Jeff Haas 
> NextHop Technologies

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 4 Oct 2002 11:55:05 -0400

According to the definition of ATOMIC_AGGREGATE. It discusses loss of
information due to aggregation, not due to other means
like choosing an IGP route over IBGP. If that were mentioned I would agree
the ATOMIC_AGGREGATE covers it all. 

Plus, the ATOMIC_AGGREGATE says receiving peers cannot deaggregate the route
to a more specific components, mainly because all the AS_Paths of the
component routes are not present in the aggregated route. This is completely
different than choosing an IGP route over an IBGP route. In my case, most
likely none of the AS_PATHS are in the IBGP route. 

I think you guys are trying to merge everything into existing stuff that
does not cover it in all cases.

Ben

> From: John G. Scudder [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 11:27 AM
> To: Jeffrey Haas
> Cc: [email-masked]; [email-masked]
> At 10:59 AM -0400 10/4/02, Jeffrey Haas wrote:
> >  > Unless  of course, my whole appreciation of the atributes is 
> >wrong. But in this
> >>  case it would be good to indicate what can and cannot be 
> expected from an
> >>  attribute.
> >
> >Honestly, its best to *not* expect anything beyond guaranteeing loop
> >free routing.  The fact that you can *try* is an operational 
> decision.
> >It might even work.
> 
> Indeed, and this has been called out in the spec for a very long time 
> now, in the case of ATOMIC_AGGREGATE.  From 5.1.6:
> 
>     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>     attribute needs to be cognizant of the fact that the 
> actual path to
>     destinations, as specified in the NLRI of the route, 
> while having the
>     loop-free property, may not be the path specified in the AS_PATH
>     attribute of the route.
> 
> Consider this statement in combination with your earlier observation 
> that in effect, everything is an atomic aggregate (or at least, must 
> be treated as if it were).
> 
> --John
>