[c-nsp] MPLS - MP-BPG with multiple OSPF areas

Mark Tinka mtinka at globaltransit.net
Wed Oct 19 22:47:47 EDT 2011


On Thursday, October 20, 2011 06:39:38 AM Livio Zanol Puppim 
wrote:

> About MPLS features in multiple areas, aren't there
> solutions that can be implemented to overcome the
> limitations like LDP prefix leaking or some solutions
> with mGRE?

The IGP already knows about the individual infrastructure 
addresses between areas, which is what helps LDP to work.

But MPLS-TE is something else. Paths have to be signaled, 
and by default, ingress routers signaling paths tend to 
prefer that the tail-end of the LSP be in the same area or 
level. If that isn't the case, Inter-Area TE is required.

> What issue do you see keeping a lot of routers in a
> single area (let's say 400) versus routers in different
> areas?

In OSPFv2, Areas help the routing protocol to scale, 
primarily due to the close ties between Type 1 and Type 2 
LSA's. This isn't an issue in OSPFv3 or IS-IS, as Topology 
and Reachability information is separated.

At the risk of starting a routing protocol war, IS-IS has 
been known to scale very well in single level environments 
(see Vijay Gill's OSPF-to-IS-IS migration at ATDN).

We have two networks, one where we run IS-IS in one level 
(L2) and one where we use multiple levels. It scales very 
well in both, and both are fairly large.

There are rumours that OSPF can scale to some 10,000 routes 
on today's kit, but I'm not sure as I don't run it.

> Are there any recommendations about that or about the
> maximum number of routers in a single area, or maybe
> something about benefits/problems in both designs?

The problem with a single area/level is that one router 
sneezing a million miles away is heard by all other routers 
at the topology level. For such a problem, OSPFv3 or IS-IS 
will react better.

Areas/levels help to scale the network, but introduce issues 
like MPLS-TE. In our IPTv network, where we use NG-MVPN for 
Multicast (p2mp RSVP-TE), we use a single L2 IS-IS domain, 
just to avoid issues or configuration complexities with 
signaling p2mp paths across different parts of the country. 
The risk is increased noise, but the kit can take it.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20111020/2a5cb468/attachment-0001.pgp>


More information about the cisco-nsp mailing list