RE: Active Route - OT

["Abarbanel, Benjamin" <[e-mail]>]

Hans:

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> 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:[e-mail]]
> > > Sent: Wednesday, October 02, 2002 12:41 PM
> > > To: '[e-mail]'; [e-mail]
> > > Cc: BGP mailing list
> > > Subject: RE: Active Route
> > >
> > > Curtis
> > >
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:[e-mail]]
> > > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > > To: [e-mail]
> > > > Cc: BGP mailing list
> > > > Subject: Re: Active Route
> > > >
> > > >
> > > >
> > > > In message <[e-mail]>,
> > > > [e-mail] 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
> > >
>