Subject: [Idr] IBGP to replace IGP

From: John Smith <[email-masked]>
Date: Tue, 16 Mar 2004 04:24:12 +0000 (GMT)

Hi,

I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as
they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make
them carry the BGP attributes).

What is not very clear to me is, why cant we use IBGP inside an AS to completely do away
with IGPs. IGPs compute the best path to reach a particular neighbor based on the link
metric. This can be achieved in BGP also, if we include a TLV to carry the link cost.
Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic,
because if a router isnt speaking BGP then it cant forward BGP traffic. 

Cant we do away with IGPs (say in some small networks) and run only IBGP there?

Any help/clues/pointers in this regard will be really appreciated.

Regards,
Smith

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Michel Py" <[email-masked]>
Date: Mon, 15 Mar 2004 21:44:33 -0800

> John Smith wrote:
> Moreover, it is *mandatory* to run BGP on all the routers
> if we are transiting traffic, because if a router isn't
> speaking BGP then it cant forward BGP traffic. 

Where does this come from? I have configured transit networks with an
IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at
the edge. What about this animal called NLRI?

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 15 Mar 2004 21:44:33 -0800

Michel.

---

From: John Smith <[email-masked]>
Date: Tue, 16 Mar 2004 05:58:39 +0000 (GMT)

Michel,

> the edge. What about this animal called NLRI?

Say your edge BGP speaker (R1) learns 10.0.0.0/8 from some other EBGP router (NH1). It
advertises the same to the other edge (R2) BGP router (which resides in the other corner
of the same AS) with the NEXT_HOP NH1. Now you have IGPs running in the core so all the
routers are aware of how they can reach NH1. When data traffic comes on the BGP router
R2, it looks at its FIB and determines that it needs to forward the packet to one of your
core routers in between the path to reach NH1. When the packet comes to that core router,
there isnt any information about 10.0.0.0/8 on that router. How is then that packet
forwarded.

One can use default routes on the core IGP speaking routers, but that isnt a good
solution and can easily lead to routing loops/black holes.

Hope i made my case clear.

Regards,
Smith

---

From: John Smith <[email-masked]>
Date: Tue, 16 Mar 2004 05:58:39 +0000 (GMT)

Michel,

Regards,
Smith

---

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 03:22:22 +0000

Hi Ben,

It would be great if you could share some more information on the "issues" 
of convergence time, CPU loads, and RP overloads.

>From my understanding
a. it makes more sense to have 1 routing protocol as we dont have multiple 
daemons scheduled on the CPU. (which ofcourse is not a problem but then so 
is the point you mentioned below)

b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we 
inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest BGP 
node.So does that help reduce the size of your routing table?

c. The cases u mention of changes, I presume you mean route-flaps. Well in 
that case, we eitherways have issues when IGP flaps, we eitherways wait for 
IGP to converge for BGP to converge etc? (I am sure "real traffic" operators 
do that)

d. We have the benefits of not having the "global view" dependent on 1 
protocol while the internal topology dependent on another

e. all i need to teach the network admins is BGP :)

f. Based on c, how would you say that it makes things more complicated to 
run iBGP only compared to IGP+0.0.0.0/0 (default originate and originate 
always) and all those things taken into consideration?

would be great if you could help clarify this.

-Smith

You could certainly run BGP and statics without another protocol for the 
IGP, but why would you want to? Convergence times, CPU load on RPs, etc., 
during changes would be rather unsatisfactory. If you want to run one 
dynamic protocol at all costs, then what you describe below will work, and 
has worked for some, but people with real traffic don't waste their time 
with it.

Ben

On Mar 15, 2004, at 8:24 PM, John Smith wrote:

Hi,

I am very clear with the concept that IGPs cannot be used to carry the 
entire BGP feed as
they cant be scaled to carry so many prefixes (even assuming we add enough 
TLVs to make
them carry the BGP attributes).

What is not very clear to me is, why cant we use IBGP inside an AS to 
completely do away
with IGPs. IGPs compute the best path to reach a particular neighbor based 
on the link
metric. This can be achieved in BGP also, if we include a TLV to carry the 
link cost.
Moreover, it is *mandatory* to run BGP on all the routers if we are 
transiting traffic,
because if a router isnt speaking BGP then it cant forward BGP traffic.

Cant we do away with IGPs (say in some small networks) and run only IBGP 
there?

Regards,
Smith

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

---

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 22:33:55 +0000

Hi Ben,

Thank you for your reply,
>
>a) scheduling is a minor concern.
>

I thought as much. CPU overload was something you mentioned. If you consider 
the point that OSPF carries only your IGP routes and BGP carries a lot more 
than that, the CPU overload problem will definately be there with BGP.

But then assume we were to do away with BGP what would be the problem? would 
an IGP like OSPF be able to do a better job with the whole routing table?

>b) certainly carrying a default helps reduce the size of the table, but 
>that is orthogonal to the question.  it is not common practice to carry 
>much in the igp (meaning bgp is not redistributed into the igp), so 
>carrying a default really is reducing the size of your bgp ribs which is 
>something you can do regardless of whether you have a second protocol for 
>the igp.

Exactly, so why add one more "protocol" to the network? What was wrong with 
just one?

As you see, 2 can load the RP and the CPU and lead to convergence issues a 
lot more :) that one (but that apparently now is hardly a concern?)
>
>c) yes, flapping routes are a problem regardless of protocol, so you 
>generally want one that converges very quickly.  a good link-state protocol 
>like ospf converges in seconds vs minutes for bgp in a reasonably complex 
>network.  again, the igp is only carrying limited information (links and 
>loops being a very common scenario) and has very detailed knowledge of the 
>network (handling per-link metrics in bgp would get very ugly very fast) so 
>it can do things that are inconvenient or impossible with bgp.

That is beause of the size of the routes handled by the protocol. What else 
do you think makes BGP slower? On the other hand, link state would have a 
lot more LSAs to compute the SPF against.
So if my "intermediate" nodes did not have the complete table but I was to 
use 0.0.0.0/0 just like I do for OSPF (seems like thats what was your 
intended IGP) Would not BGP on the intermediate nodes (the part that was 
covering my IGP) converge equally fast?

Incase you have a difference of opinion, please do tell me the reason.

>
>d) i don't know what benefits you mean.  decoupling the churn of the 
>"global view" from the stability of your internal network supports using an 
>independent igp.

which *may( work out if one was to use the same principals of IGP when using 
BGP as the IGP (0.0.0.0/0 to eBGP nodes etc?)
>
>e) if they can't understand ospf they shouldn't be touching the routers 
>anyway.
>

(Fine, I shall tell them that.)

>f) i'm not suggesting the use of a default route.
>

I am considering that as a possibility.

-Smith

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 22:33:55 +0000

Hi Ben,

-Smith

---

From: "Martin, Christian" <[email-masked]>
Date: Tue, 23 Mar 2004 17:35:58 -0500

Smith, 

Comments inline, as I have been following this thread.

>of convergence time, CPU loads, and RP overloads.

Convergence is typically nonlienearly proportionate to CPU load, and
vice-versa, and they often feed off each other in a negative way.  Network
meltdowns are typically the result of routing loads disrupting topology
maintenance mechanisms, thereby causing adjacency loss, which causes more
routing load, which inhibits adjacency recreation, etc.  I've seen networks
stay in persistent "ditches" because the
convergence-adjacency-divergence-adjaceny-...loop stayed closed due to
loading.  Not fun to have to rebuild all of your routers or reattach them to
the network one by one...

>is the point you mentioned below)

In either case, BGP will consume the vast majority of CPU cycles.  IGPs that
are properly tuned in stable environments hardly tickle the CPU, let alone
heat it up.  Take LSA/P refresh out of the picture, and all the IGP does is
send hellos and occasionally flood an LSA/P and compute an SPT once in a
rare while.  In the Internet, BGP is constantly processing updates and
withdrawals, all day, every day.  Sometimes, we see 100s of updates per
minute, sometimes just a few, but they are always there.

>node.So does that help reduce the size of your routing table?

Large SPs must run a full BGP load, at a minimum, to give routes to their
customers.  Unless you are talking about enterprise routing, we should avoid
discussions of default routes...

>IGP to converge for BGP to converge etc? (I am sure "real 

Modern IGPs, properly tuned, converge way faster than BGP.  BGP convergence
is designed to be slow, so as not to place too much load on the global
routing system.  Since BGP carries so many routes, and since the topological
density of the Internet Autonomous System graph increases every day, BGP can
often take minutes to converge.  IGPs take seconds, partly because they are
usually lightweight.

>protocol while the internal topology dependent on another

This is actually a sound design.  Think of the IGP as a topology discovery
mechanism.  All BGP routes have a next-hop.  The goal of BGP is to take
traffic to and from the "edges" of the network.  Sometimes, the edge is
within your network, like a server farm.  IGPs are very good at discovering
a topology and identifying the shortest path to each edge.  BGP is not
designed for this, and to make it do so requires considerable planning and
lots of policy.

>e. all i need to teach the network admins is BGP :)

It is much easier to learn simple IS-IS and OSPF than BGP.  Link State IGPs,
when employed for topology discovery, are exceedingly simple (particularly
IS-IS in a single area).  BGP, on the otherhand, is a much bigger protocol
that requires a lot of policy engineering in order for it to be effective.

>always) and all those things taken into consideration?

Are you talking about running in an enterprise?  Default routes will not
work in any large environment for next-hop discovery of your iBGP peer IP's.
Loops would abound...

One of the problems with your proposal, and the primary reason this is not
done, is that iBGP does not provide for transitive route dissemination in a
network.  All 'other' IGPs do this.  This means your network topology must
be highly symmetrical and/or fully meshed at layer 3 (at least in
subsections) to allow for end-to-end route propagation.  Unless you can
employ lots of confeds (ie, each router in a confed subAS), lots of
route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you
consider multiaccess networks fully-meshed), then this approach is not
possible.

BGP also has race-condition mitigation rules that prevent a BGP route from
being learned from a next-hop that is known via BGP, so injecting routes
into BGP and hoping to bootstrap the next-hops would be problematic.  This
restriction is subtle and perhaps vendor specific, but usually, the next-hop
is recursed through an IGP or connected interface.  If this were possible,
in any event, it would be slow-converging, as iBGP updates are typically
spaced at 5 second intervals (depending on the event type).  Also, you will
have to peer with every interface on the device, thus forcing traffic to
take certain paths that may not be the best path available, as most BGP
attributes are non-accumulating (ie, u have to statically increase, say,
local-pref via policy as routes propagate along a set of routers in your
AS).

The reality is that even if such an approach _were_ possible, the drawbacks
are much more severe than simply turning on an IGP and having it discover
your topology.  Then, you may do what you with with iBGP.

The best philosophy, IMO, is to place loopbacks and links in your IGP, and
carry externals (either self-originated or from another AS) in your iBGP.
Route-reflectors are useful if regionalized, as they make best path
decisions before reflecting (so u want to be careful who peers with what to
ensure path selection optimality).  Confeds afford more control, TE, etc.,
but at what some claim to be a higher admin cost.  Use them based on what
you are trying to do.

HTH,
Chris

---

From: "Martin, Christian" <[email-masked]>
Date: Tue, 23 Mar 2004 17:35:58 -0500

Smith, 

HTH,
Chris

---

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 22:43:10 +0000

Check my reply to Ben, it covers a lot of commong ground

I think you missed out the point that I was planning to put 0.0.0.0/0 in the 
intermediate nodes to cover the internet.

It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being 
considered for intermediate nodes.

Route flaps are a result of "actualy flaps somewhere" and if you were to 
follow the 0.0.0.0/0 principal neither would your intermediate nodes give a 
problem.

The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into 
the IGP, so maybe I didnt quite get that point

>From: "Martin, Christian" <[email-masked]>
>To: 'john smith' <[email-masked]>, "[email-masked]'" 
><[email-masked]>
>Subject: RE: [Idr] IBGP to replace IGP
>Date: Tue, 23 Mar 2004 17:35:58 -0500
>
>Smith,
>

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

---

From: "Martin, Christian" <[email-masked]>
Date: Tue, 23 Mar 2004 18:00:54 -0500

John,

We are drifting off topic for this list here.  Perhaps you should take this
up on a list that covers fundamental routing concepts.  Contact me privately
if you wish to engage further.

Thanks,
chris

---

From: "Martin, Christian" <[email-masked]>
Date: Tue, 23 Mar 2004 18:00:54 -0500

John,

Thanks,
chris

---

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 23:10:54 +0000

I am not saying that you do not need BGP "at all".

The default route to a node "with complete information"  only covers the 
case where you have intermediate nodes which cannot handle the complete 
routing table due to certain limitations highlighted by you.

The reason we use BGP today is the very reason we still need to use BGP.

Some one"has to be the *upstream*". There has to be a point in the network 
where you decide if A or B is the best way to send traffic outside your AS.

All I am asking is why do we need IGP when the same things that are done by 
IGP can be done within BGP.

If you plan to extend an IGP like OSPF (LinkState) to do the same things 
that BGP does today (provides a point in the network which has complete and 
accurate information), and you believe the performance will be better, I 
would be really curious to see the results and would be thankful if you 
could share the same.

>From: Benjamin Black <[email-masked]>
>To: "john smith" <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Idr] IBGP to replace IGP
>Date: Tue, 23 Mar 2004 15:01:43 -0800
>
>from the sound of things you don't need bgp at all, except to announce 
>routes to your upstreams.  rejecting all routes from a peer tends to limit 
>the size of adj-rib-in as well as reduce the cpu load of route flaps.  
>handle the rest with an igp and a default and you are done (and your 
>network admins need know almost nothing about bgp).
>
>
>ben
>
>On Mar 23, 2004, at 2:43 PM, john smith wrote:
>
>>I think you missed out the point that I was planning to put 0.0.0.0/0 in 
>>the intermediate nodes to cover the internet.
>>
>>follow the 0.0.0.0/0 principal neither would your intermediate nodes give 
>>a problem.
>>

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 23:10:54 +0000