Subject: RE: Active Route

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 2 Oct 2002 11:39:24 -0400

Hans

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

If the IGP route in the Routing Table and the IBGP route use the same
next hop address, it is not broken. The only time I think its broken
if the next hop address is different. What we say is broken is the gaurantee
that the peer is told correctly the path the forwarding plane will work.
Reachability could still be possible. But we know IP is not an exact
science.

Ben
> ---
> Hans de Vleeschouwer
> 
> 
> "Martin, Christian" wrote:
> 
> > Jonathan,
> >
> > >
> > >"one must focus on the rule that a BGP speaker advertises to
> > >its peers (other BGP speakers which it communicates with) in
> > >neighboring ASs only those routes that it itself uses."
> > >
> > >This means that if the speaker's routing table has a non-bgp
> > >route to a destination but does not have bgp route to the same
> > >destination (for example, based on administrative distance),
> > >then the speaker may not advertise that route to it's peers.
> > >This is true on Juniper by default for EBGP, but is NOT TRUE
> > >[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~=
> > >"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
> > >
> > >Now we are proposing that the quoted clause above be
> > >completely removed. This means that it will be allowable to
> > >advertise a route to a destination that is not locally
> > >reachable.  This is obviously (to me, but not to all-- which
> > >is why it should not be removed) bad.
> >
> > This, IMO, is not the spirit of the rule.  Juniper 
> interpreted the spec
> > differently.  As I see it, if the route is in the routing 
> table, you can
> > announce it.  To be more specific, and to your point 
> Jonathan, we should say
> > this - or say the converse:
> >
> > "one must focus on the rule that a BGP speaker advertises to
> > its peers (other BGP speakers which it communicates with) in
> > neighboring ASs only those routes learned via BGP that it
> > itself uses.  "Learned via BGP" means that a router's best path
> > to a prefix is one that was either learned from a BGP peer, or
> > deliberately injected into BGP by the local router."
> >
> > Regards,
> > -chris
> >
> > >
> > >Thank you.
> > >
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 12:09:19 -0400

In reference to:

""locally reachable"?  Do you mean BGP can't reach it (e.g. not
in Loc-RIB?)"

No, I mean that the router/speaker/switch/box can't reach it.  But you
bring up a good point--BGP must be able to reach it as well.  But I think
this is already covered by:

"A route shall not be installed in the Adj-Rib-Out unless the
destination and NEXT_HOP described by this route may be
forwarded appropriately by the Routing Table."

If you don't like "locally reachable", how about:
"installed in the routing table"
"in the local FIB"
...

-----Original Message-----
From: Michael C. Cambria [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2002 11:16 AM
To: Natale, Jonathan
Subject: Re: Active Route

Natale, Jonathan wrote:
> Folks,
> 
> This issue seems to have been convoluted into issue 32.2.  I am in
agreement
> with 32.2 (other than style/conciseness--I think it is a little long
winded,
> but I can live with it), but it is not what I raised.  
> 
> The issue I raised, and would like to be [re-]considered is with:
> 
> "one must focus on the rule that a BGP speaker advertises to its peers
> (other BGP speakers which it communicates with) in neighboring ASs only
> those routes that it itself uses."

I agree.  This should remain and be clarified.

I want to make sure I fully understand you.  If I do, I have the same 
concern.

> This means that if the speaker's routing table has a non-bgp route to a
> destination but does not have bgp route to the same destination (for
> example, based on administrative distance), then the speaker may not
> advertise that route to it's peers. This is true on Juniper by default for
> EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
> Cisco.

I missed something.  I understood until your "for example, based on 
administrative distance" example.   Why would admin distance come up if 
there was no BGP route for the same destination as that of the IGP?

Crossing out your example, I read the above to say if we delete the 
quoted text from the draft as proposed, one could advertise an IGP route 
that has no corresponding destination in Loc-RIB.

Is this what you are saying?

> Now we are proposing that the quoted clause above be completely removed.
> This means that it will be allowable to advertise a route to a destination
> that is not locally reachable.  This is obviously (to me, but not to all--
> which is why it should not be removed) bad. 

"locally reachable"?  Do you mean BGP can't reach it (e.g. not in Loc-RIB?)

Thanks,
MikeC

---

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

Michael:

Below

> Sent: Wednesday, October 02, 2002 11:49 AM
> To: [email-masked]
> > Christian,
> > Thank you for replying.
> > Your change would not cover the case, for example, where the speaker
> > uses a static route that is not redistributed into bgp to reach
> > a set of destinations that is also learned via bgp.
> > 
> > I was thinking of:
> > its peers only routes whose set of destinations
> > are reachable per the local Routing Table."
> 
> Would changing Martin's text:
> 
> to the text below work (removing the "best path" reference)?
> 
> itself uses.  "Learned via BGP" means that the route to be
> advertised is one that was either learned from a BGP peer, or
> This calls out that a speaker can't advertise a route to
> neighboring ASs that are not known to BGP.  Yet it does not 
> preclude a 
> route known to BGP from being advertised that has either the 
> destinaiton 
> or the NEXT_HOP (or both) reachable in the routing table via an IGP 
> route (e.g. due to admin distance) as required by 9.1.3:
> 
> destination and NEXT_HOP described by this route may be forwarded 
> appropriately by the Routing Table."
> 
> 
I would like to slightly rephrase your suggestion:

 "A route shall not be installed in the Adj-Rib-Out unless this 
  route or a similar route (i.e. IGP route) sharing the same prefix and   
  NEXT_HOP address, is present and used for forwarding in the Routing Table.
 
Ben

> fire away :-)
> > From: Martin, Christian [mailto:[email-masked]] 
> > Sent: Wednesday, October 02, 2002 10:28 AM
> > To: 'Natale, Jonathan'; [email-masked]
> > Subject: RE: Active Route
> > 
> > Jonathan,
> > 
> >

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 13:06:30 -0400

Ben,
No, the existing text (it was not Mike's suggestion) is fine.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2002 12:16 PM
To: 'Michael C. Cambria'; [email-masked]
Subject: RE: Active Route

Michael:

Below

 
Ben

---

From: "Martin, Christian" <[email-masked]>
Date: Wed, 2 Oct 2002 15:10:32 -0400

That is what I meant.  We have two choices:

1) Announce only if it is the best BGP route and the route exists in the
rib.
-or-
2) Announce only if it is the best route and the route was learned via BGP
and it is in your RIB.

This about covers it, I think.

-chris

>From: Natale, Jonathan [mailto:[email-masked]] 
>Sent: Wednesday, October 02, 2002 11:33 AM
>To: 'Martin, Christian'
>Cc: [email-masked]
>Your change would not cover the case, for example, where the 
>speaker uses a static route that is not redistributed into bgp 
>to reach a set of destinations that is also learned via bgp.
>
>I was thinking of:
>This, IMO, is not the spirit of the rule.  Juniper interpreted 
>the spec differently.  As I see it, if the route is in the 
>routing table, you can announce it.  To be more specific, and 
>to your point Jonathan, we should say this - or say the converse:
>
>itself uses.  "Learned via BGP" means that a router's best 
>path to a prefix is one that was either learned from a BGP 
>peer, or deliberately injected into BGP by the local router."
>
>Regards,
>-chris
>
>
>
>
>>
>>Thank you.
>>
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 2 Oct 2002 15:53:36 -0400

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2002 3:44 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'; [email-masked]; BGP
> mailing list
> In message 
> <[email-masked]>, 
> "Abarbanel, Benjamin" writes:
> > Curtis
> > 
> > > From: Curtis Villamizar [mailto:[email-masked]]
> > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > To: [email-masked]
> > > Cc: BGP mailing list
> > > 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?
> 
> 
> {\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.
>

My only point is, if its such a TABOO thing to not export BGP to IGP, then
we
need to find a home for this point that is made very clearly as a rule for
something NOT to do. Hopefully in due time vendors will remove the knob that
allows this to happen and thus eliminate the need to document the problem.
 
BTW: If we move to IPv6, there are a maximum of only 8196 global Internet
routes in the BGP table (for EBGP routes). Would this issue become
non-existant when that happens?

> \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.
>
 
> 
> > > > 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).
> > > > 
> > > > advertises to its peers  in neighboring ASs only those 
> > > routes that it itself
> > > 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
> 
> 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: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 17:25:59 -0400

How about(since the new proposed paragraph has a different meaning,
maybe this should be in separate paragraph):

"A BGP speaker MUST NOT advertise sets of destinations that are not
locally reachable."

Seems obvious, but the only place I have found this is RFC1812:

"Routers MUST NOT by default redistribute routing data they do
not themselves use, trust or otherwise consider valid."

--which seems to imply that you could configure a router to
advertise routes that you do not use ("by default").  Also,
the word "redistribute" now has a different meaning
(in RFC1812 it meant "advertise", whereas in common usage
now it means "leak"/"export" routing information from
one routing protocol into another routing protocol).

-----Original Message-----
From: Martin, Christian [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2002 3:11 PM
To: 'Natale, Jonathan'; Martin, Christian
Cc: [email-masked]
Subject: RE: Active Route

-chris

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Thu, 3 Oct 2002 14:31:05 -0400

I am not advocating that people do this, just that the knob is there and
we need to add a caution against it. Eventually the knob should be removed
by sensible vendors.

That is all,
Ben

> Sent: Thursday, October 03, 2002 2:27 PM
> To: Abarbanel, Benjamin
> Cc: 'Manav Bhatia'; [email-masked]; BGP mailing list
> <[email-masked]>, 
> > The world is too big and complex and it is too difficult to 
> make one size
> > fit all solution work. I guess that is why they have not 
> depracated the 
> > redistribution from BGP to IGP feature happen. IMHO, as 
> long as the main
> > stream vendors still support the feature, we must consider 
> it as a viable
> > configuration. To say your network is broken if you use it, 
> is a bit over
> > stating it. I would rather we add cautionary comments in 
> the base spec for
> > things like this that can lead into possible trouble.
> > 
> > End of Commentary,
> > Ben
> 
> 
> Ben,
> 
> If you've ever seen the results of injecting BGP into the IGP in an
> ISP network you'd know that it isn't something you'd want to do again.
> 
> The hacks for using BGP in an incomplete BGP mesh (to accommodate a
> deficient router) should be out of scope for the protocol specs.
> 
> I don't think its productive to continue this discussion so I won't
> comment further.
> 
> Curtis
> 
> 
> > > From: Manav Bhatia [mailto:[email-masked]]
> > > Sent: Thursday, October 03, 2002 6:49 AM
> > > To: [email-masked]; Abarbanel, Benjamin
> > > Cc: BGP mailing list
> > > 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
> > > 
> > 
>