Subject: RE: MPLS/BGP routing question

From: Eric Gray <[email-masked]>
Date: Thu, 5 Oct 2000 11:13:35 -0700

Curtis,

	Please see below.

Curtis Villamizar wrote:
 ... <snip> ...
> 
> For example, optical switches will definitely NOT run IBGP with the
> Internet routers.  They run an IGP and MPLS (plus LMP) but not BGP.
> (In any reasonably sane network).
> 

This is a confusing statement, mostly because it's not
clear what you mean by "Internet routers", "optical
switches" and "sane" networks.  

If, by "Internet routers", you mean routers outside of 
your AS, then the first statement is true but not new 
and useful information about optical switches.  Nobody 
runs iBGP with routers external to their AS.  

But, then again, they do not run an IGP with them either
- so I suspect that this is not your meaning.

If you mean AS boundary routers, then the next question I
have to ask is what do you mean by "optical switch".  

If you mean a box with only optical interfaces that does
switching and not routing, then - again - the statement, 
with regard to iBGP at least, is true and not especially 
interesting.  If it doesn't do routing, then it doesn't 
do routing.  Yawn.

But your assertion that they run MPLS and an IGP seems 
to indicate that this is not what you mean.

If, however, you mean a box with only optical interfaces
which is "packet aware" and participates in some form of
routing, then I have to ask which particular flavor of
"sane" you are referring to.

For example, I believe that it may be hard to distinguish 
an AS boundary router with all optical interfaces from a
packet aware optical switch - at least in some cases.  In
the case of an all optical AS boundary router, it is more
"sane" to run iBGP than it is to - for example - import
Internet routes into an IGP.  

If ASBRs run iBGP, they must be talking to other boxes also 
running iBGP.  If the ASBR is all optical, then chances are
good that they will be talking iBGP to neighboring optical
switches - at least in some types of "sane" networks.

So, I seem to have missed your point.  Can you elucidate?

--
Eric Gray

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 06 Oct 2000 12:12:09 -0400

Eric,

> > (In any reasonably sane network).
[...]
> So, I seem to have missed your point.  Can you elucidate?

Within an AS there is no strict need for any interior MPLS capable
device to run IBGP if there are MPLS LSPs between any two non-interior
(border) devices.  An interior device is one which has no EBGP peers.
A non-interior does have EBGP peers and is usually called a border
router.

Stating the obvious: You only run IBGP wtih peers in your own AS.  You
only run EBGP with peers outside your own AS.

The only potential reason to run IBGP is so that the interior routers
have full Internet routes and can handle ICMP and traffic to the local
device without resorting to a default route to a border.

Optical switches are not known for the robustness of their BGP
implementations if they have BGP implementations at all.  They may
also have more important things to do with their CPU cycles given that
they do no externalrouting at all.  It would seem to be a relly bad
idea to run IBGP to the optical switches.

I hope that was more clear.

Curtis

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 06 Oct 2000 15:58:26 -0400

Hello,

> I hope that was more clear.

Absolutely not.  It's certainly seems possible to have
a scenario where optical edge switches run E-BGP
with router clients to provide reachability information. Whether
the optical network is a separate AS or a sub-AS is another issue.
What's wrong with this?

Bala

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 08 Oct 2000 17:16:01 -0700

Sorry for being late ...

Two comments:

1. A lot of people mentioned that there is no need to run IBGP on core
routers with mpls-vpns or just prefix/tunnel based mpls in the core.
That is true but only for _unicast_ traffic. One I think quite important
point is no one has mentioned that if one is providing global multicast
service full table in every router is needed for RPF check. This will
hold until one comes with good proposal & implementation of mpls for
multicast.

Now said this there are two ways to keep rolling until this happens:

* Keep the ipv4 ibgp there, automatically populating routing table &
forwarding table with 85K entires which may not be used at all for
forwarding

* Turn existing ipv4 ibgp mesh into multicast-BGP full mesh and
propagate the full table for the purpose of m-cast RPF check while not
"waist" RIBs/FIBs RAM space.

2. Satoru Matsushima said:

> When a LSP of PE to PE broken, BGP has no way of LSP broken.
> I think this is one of most seriously problem of BGP/MPLS VPN.

Not true when we are talking about prefix based LSPs. If you are using
prefix based LSPs they will disappear only if ip route to bgp next hop
will disappear what in turn will cause bgp route withdrawn (invalid bgp
next hop) at a periodic scanner. If there is no route - you will not be
able to route anyway - no miracles here.

If you are talking about tunnel based LSPs (TE for example) - you have
got what you have configured. I would advise caution configuring your
network this way and I don't think this particular case can justify
calling a mpls-vpn architecture as a "serious problem".

R.

---

From: Alex Zinin <[email-masked]>
Date: Sun, 8 Oct 2000 21:41:03 -0700

Bala,

Note that with today BGP that border OXC will be the next-hop
for all IP prefixes it announces to the client via the e-BGP
session. This means that the client does not really know
much about the egress point per prefix and hence where it should
establish LSPs across the optical transport network unless we
add a kind of "suggested next-hop" BGP attribute as a part
of optical UNI (I don't think it makes sense to run e-BGP
in the peer model) to inform the client about the egress
points.

I think Curtis' point is that OXCs do not really need to
have BGP routes in their routing table for normal operation
of circuit provisioning protocols.

Alex.

---

From: Bala Rajagopalan <[email-masked]>
Date: Mon, 09 Oct 2000 10:52:32 -0400

Hi Alex,

> in the peer model) to inform the client about the egress

What you say about egress point is true. This is in fact what
we had proposed in our draft, draft-prs-optical-routing-00.ps (.txt).

> of circuit provisioning protocols.

Unless someone explains what Curtis means, it's hard to
get the point (usually). {A reluctant :-) here may be added
if desired.}

Bala

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]