Subject: RE: Active Route - OT

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Thu, 3 Oct 2002 11:33:34 -0400

Hans:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, October 03, 2002 9:09 AM
> To: BGP mailing list
> Subject: Re: Active Route - OT
> 
> 
> All,
> 
> thanks for your feedback on this.  Now I tend to be  more in 
> favor of  leaving
> the text  and the restriction in the RFC.  The reasons i see 
> for this are:
> 
> 1. The effective use of policy is endangered. Supose a bgp 
> speaker announces to
> its external peer reachability for a route, and indicates 
> that this route
> passes through AS 1,2 and 3, while at the same time the FIB 
> of the same router
> would actually send the traffic so that in the end it follows 
> another path
> passing through a different set of ASses.  If this is allowed 
> why would we even
> bother to pass along attributes? (Also I learned of some 
> people trying to make
> tools that use the BGP RIB to figure out how traffic is flowing in the
> internet).
> 

According to Dennis you are gauranteed that the mix of BGP and IGP routing
will prevent any possible loops and get the packet to its destination. It
does not gaurantee that the packet will travel the AS_PATH defined in the 
(i/e)BGP route. Thus, in a way it works and it doesn't, if you are picky
about the attributes. IMHO, there should be a way to flag that suboptimal
routing is
taking place with this route so that any external peers can make a judgement
call on the validity of the route provided. For example, lets say a peer 
knows that this IBGP route is not really used for forwarding but an IGP
route
is for the same destination, it could flag the route with a new attribute
saying that suboptimal routing path is used with this route. The external
peer receiving the route can reduce its priority so that the BGP decision
process can pick another route over this one, thus avoiding the less
deterministic behavior. 

Your comment?

Ben

> thanks
> ---
> Hans De Vleeschouwer
> 
> > "Natale, Jonathan" wrote:
> >
> > > "What if your AS is not fully meshed as Hans pointed out?"
> > >
> > > Then you are mis-configured.
> > >
> > > Also, I agree with Curtis--redistributing BGP into IGP is 
> a bad idea.  A
> > > much better idea is to turn off synchronization (rumor 
> was that it will
> > > be/is off by default in newer IOS).  Juniper does not 
> even have a synch
> > > concept (a good thing).
> > >
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[email-masked]]
> > > Sent: Wednesday, October 02, 2002 12:41 PM
> > > To: [email-masked]'; [email-masked]
> > > Cc: BGP mailing list
> > > Subject: RE: Active Route
> > >
> > > Curtis
> > >
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:[email-masked]]
> > > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > > To: [email-masked]
> > > > Cc: BGP mailing list
> > > > Subject: Re: Active Route
> > > >
> > > >
> > > >
> > > > In message <[email-masked]>,
> > > > [email-masked] writ
> > > > es:
> > > > >
> > > > > Then I redistribute the routes into IGP, and at the same
> > > > time I forward
> > > > > the routes via IBGP (not full mesh) to all of the other AS
> > > > border routers (bu
> > > > > t
> > > > > to no other routers).
> > > >
> > > > This is an incredibly bad idea.  Only the BGP next_hop 
> needs to be in
> > > > the IGP.
> > > >
> > > > > At the other side of my AS, I allow the border router
> > > > (router B) to pass thos
> > > > > e
> > > > > routes learned via IBGP (form router A) to the (next) AS
> > > > via an EBGP connecti
> > > > > on.
> > > > > (I am using the  "synchronise BGP = TRUE" option.)
> > > >
> > > > Synchronise implies that the BGP next_hop is reachable 
> via the IGP
> > > > *not* the BGP prefix itself.
> > > >
> > > > There is never a need to put the destination prefix 
> into the IGP if it
> > > > is carried in IBGP except for the case where you are 
> originating a
> > > > prefix and you want it to go out with specific 
> attributes such as
> > > > specific BGP communities or indicate through BGP 
> communities some
> > > > special action such as punching a hole in an aggregate.
> > > >
> > >
> > > What if your AS is not fully meshed as Hans pointed out?
> > >
> > > The only way to get external BGP routes to non-BGP (IGP 
> only) routers is by
> > > redistributing them via IGP, and let IGP flood them, right?
> > >
> > > > > Now in this fairly straightforward example, the router B
> > > > will forward routes
> > > > > learned via IBGP to the next AS using EBGP, whereas for
> > > > those routes the
> > > > > reachability in the FIB is taken care of by IGP (who has
> > > > typically a higher
> > > > > preference in ther FIB then IBGP).
> > > > >
> > > > > So, in theory the rule : "one must focus on the rule that a
> > > > BGP speaker
> > > > > advertises to its peers  in neighboring ASs only those
> > > > routes that it itself
> > > > > uses." is broken, since it is clearly an IGP route 
> which in the FIB.
> > > > >
> > > > > ---
> > > > > Hans de Vleeschouwer
> > > >
> > > > The only way to fully address all of the instances of 
> this sort of
> > > > objection is to add to the spec "Most BGP 
> implementations allow the
> > > > user to do things that violate the protocol 
> specification in minor
> > > > ways, sometimes with valid uses, but also sometimes 
> with questionalble
> > > > uses and sometimes with dire consequences".  Although 
> this statement
> > > > is true, I don't don't think we need to add this.
> > > >
> > > This although is sometimes true, is bordering on being 
> rediculous for a
> > > spec. I agree, you do not want to add this or the reader 
> will stop reading
> > > the spec.
> > >
> > > Ben
> > >
>

---

From: [email-masked]
Date: Fri, 04 Oct 2002 10:54:12 +0200

Ben,

"Abarbanel, Benjamin" wrote:

> about the attributes.

Well, I tend to be picky on the attributes. Why do we forward them, or have long
discussions about then (as the ones I see ongoing for e.g. the AS-PATH) if in
the end the attribute is not trustworthy?

What is e.g. the value of a routing policy saying that "I do not want to use
routes that to pass via this particular AS".

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.

> IMHO, there should be a way to flag that suboptimal
> routing is

I am not sure that the other route which is used is in fact 'suboptimal'. The
only thing i really  know is that the attributes for the actual route that is
being taken, will differ from the advertised attributes.

So we would probaby end up with an indicator in the route saying " attributes
not guaranteed", but then again i think i prefer the restriction in the RFC.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Oct 2002 10:59:51 -0400

> the end the attribute is not trustworthy?

That was what ATOMIC_AGGREGATE was intended to signal.

One of the problems with creating aggregates without full path information
is that you can't tell if there are contributors that you might loop to.
You essentially must count on the more specifics being present
or being far enough away from things to not be affected by a potential
looping situation.

Thankfully, this seems to often be the case.

Dennis points out that people largely form aggregates along their
assigned address boundaries anyway.  So long as proxy aggregation
doesn't happen all over the place, we're fine with incomplete path
information.

> routes that to pass via this particular AS".

The fact that it lets you shape your packet flows.  Even a coarse
control is better than none.  And when none is available, people
will sometimes internally de-aggregate in order to get that control.

> case it would be good to indicate what can and cannot be expected from an

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.

> not guaranteed", but then again i think i prefer the restriction in the RFC.

We could also say that everyone must propagate every route that enters
the routing system.  I rather suspect network operators and other
implementators would tell us where to put that suggestion.

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 4 Oct 2002 11:27:19 -0400

>free routing.  The fact that you can *try* is an operational decision.

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

---

From: [email-masked]
Date: Mon, 07 Oct 2002 16:40:33 +0200

Jeffrey et al,

from the reactions on this topic, my understanding of the validity of the AS-path
attribute assigned to a route becomes something like:

   The AS-path associated with a route is meant to be correct.

   A well-kown and documented exception is when route aggregation is used.
   A new TLV "atomic aggregate" was defined to indicate this.

   Other execptions are also known to happen (the example of the IGP route
   in the FIB for a route route also learned by IBGP). Those cases will make
   that the AS-path  send along with a route may not be correct without
   notice of this fact. Those exceptions not not nessesarily cause problems,
   however they should be considered as 'bad practice'

   The main purpose for sending round the AS-Path attributes is to avoid loops.
   Any other use of the attribute (e.g. for applying policies) is not guaranteed
   to work in all cases.

Hope this is correct?

---
Hans.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Oct 2002 11:03:46 -0400

Hans,

>    A new TLV "atomic aggregate" was defined to indicate this.

And its important to note that this is not only explicitly configured
aggregation, this is implicit aggregation any time a less specific and
a more specific route are being aggregated by a less specific one.

>    however they should be considered as 'bad practice'

Any re-origination of a route that loses path information may potentially
lead to loops.

>    Any other use of the attribute (e.g. for applying policies) is not guaranteed

Pretty much.

-- 
Jeff Haas 
NextHop Technologies