Subject: Re: [Idr] IBGP to replace IGP

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?

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

Regards,
Smith

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

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

---

From: Benjamin Black <[email-masked]>
Date: Tue, 23 Mar 2004 14:11:40 -0800

a) scheduling is a minor concern.

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.

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.

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.

e) if they can't understand ospf they shouldn't be touching the routers 
anyway.

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

your questions (and name) seem more like someone lost from nanog 
looking to do some trolling than someone interested in discussing 
protocols, but i could be wrong.

ben

On Mar 22, 2004, at 7:22 PM, john smith wrote:

> 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)
>
> 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)
>
> 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?
>
> 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
>
> they cant be scaled to carry so many prefixes (even assuming we add 
> enough TLVs to make
> 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.
> Cant we do away with IGPs (say in some small networks) and run only 
> IBGP there?
>

---

From: Benjamin Black <[email-masked]>
Date: Tue, 23 Mar 2004 14:11:40 -0800

ben