Subject: RE: Active Route

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 2 Oct 2002 12:41:18 -0400

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: Curtis Villamizar <[email-masked]>
Date: Wed, 02 Oct 2002 15:44:02 -0400

In message <[email-masked]>, 
> redistributing them via IGP, and let IGP flood them, right?

{\begin{aside}

As someone formerly with two major ISPs, I'd say your AS is
broken.  Use route-reflectors if its just a matter of wanting to
reduce the mesh.  If you have routers or other device that don't do
BGP, get rid of them or arrange so that they can use a default route
(and then get then fixed or get rid of them).

This does happen with some very stupid and somewhat specialized edge
boxes which end up getting used because they are somewhat specialized
and do something right that is needed.  Its usually sufficient to give
them a default route to something with a bit more IP intelligence (and
then get rid of them if at all possible).  It is common to front end a
box like this with a small router just for this purpose.  This comment
on my part is really an aside though.

In practice, if you absolutely needed BGP injected into the IGP (and
hopefully a subset of the 250,000 BGP routes) you can export the IBGP
learned routes to EBGP so as not to lose the BGP attributes.  It is
out of scope for the spec as we've already stated numerous times.

\end{aside}

The stance as far as the protocol spec goes is that BGP/IGP
interactions are out of scope.  Special cases to support a broken AS
(one with incomplete IBGP connectivity) is definitely out of scope.

> spec. I agree, you do not want to add this or the reader will stop reading

I did mention it with the intent to show that it borders on ridiculous
to try to accommodate all ways in which you can build a semi-broken
BGP network or build one with semi-broken equipment and get it to
actually work.  We seem to agree that we don't want to go down that
road, either enumerating all of the cases or with the general caveat.

Curtis

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 03 Oct 2002 16:19:09 +0530

Curtis,
| >
| > 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?
|

[clipped]

| The stance as far as the protocol spec goes is that BGP/IGP
| interactions are out of scope.  Special cases to support a broken AS
| (one with incomplete IBGP connectivity) is definitely out of scope.
|

What if i have one non BGP speaking router lying in between the 2 BGP
speaking routers carrying transit traffic. I dont think its a broken AS if
i have this kind of topology. Things will work in this case by adding a
default route here on this transit non BGP speaking router. But it can turn
really messy if the number of such transit non BGP routers increase.

|
| I did mention it with the intent to show that it borders on ridiculous
| to try to accommodate all ways in which you can build a semi-broken
| BGP network or build one with semi-broken equipment and get it to
| actually work.  We seem to agree that we don't want to go down that
| road, either enumerating all of the cases or with the general caveat.

same comments as above.

Manav

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 03 Oct 2002 09:33:49 -0400

In message <[email-masked]>, Manav Bhatia writes
> really messy if the number of such transit non BGP routers increase.

Put in a requisition to replace that router and go find a dumpster.

Curtis