Subject: RE: Active Route - OT

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 4 Oct 2002 10:26:02 -0400

Hans:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 4:54 AM
> To: Abarbanel, Benjamin
> Cc: BGP mailing list
> Subject: Re: Active Route - OT
> 
> 
> Ben,
> 
> "Abarbanel, Benjamin" wrote:
> 
> > 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.
> 
> 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".
> 
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. 

One other way is to guarantee that a BGP route and IGP route never
match on a destination in the routing table, thus you never have this
problem.
That might require additional policies or such. Somehow I think there will
always be a case where they match and thus the problem occurs.

> 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
> > 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.
> >
> 
> 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.
> 
In some cases it is not important that a route took a particular AS path,
only
that it is reachable and not looping. In this sense, my solution will be
helpfull to external peers. 

Whether you call this condition "suboptimal routing" or "no guarantee of
path traversal", it flags the issue to external peers so that they could
treat the route with a lower priority than the ones that have guaranteed
attributes. Policies could be added that could be tailored on a case by case
basis to know
how to react to such a condition.

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: Jeffrey Haas <[email-masked]>
Date: Fri, 4 Oct 2002 11:02:15 -0400

Ben,

[is there any need to quote the entirety of messages?]

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

-- 
Jeff Haas 
NextHop Technologies