The MPLS-OPS Archive

["Daniel Holme" <dholme@mistral.net>]

To add to Shail and Rogers notes in respect to RRs and MPLS, keeping in
line with the list topic.

In a network running iBGP with RRs, when implementing MPLS into the
network and adding VPNv4 routing tables you are having to reflect more
and more routes, most of the time this means multiple different BGP
sessions to each peer from the RR if the RR is doing IPv4 and VPNv4. As
you add more VPNs to your network, and therefore more VRFs with
different RTs, the RRs will have to do more work. This is the second
phase of splitting the route-reflecting workload after removing the iBGP
mesh.

RE: Perfoming network resource optimisation

Generally, the best method for you depends totally your hardware,
network size and network topology. Route-reflecting in a single area
(multiple RRs for redundancy) is a good way to go if your AS is
Enterprise sized, however if it is REALLY big then a confederation would
probably be the best way to manage the tables and keep the memory
requirements down. It's also good to chop down the full table on
exisitng hardware that can't handle the routes.

RE: Supporting end-to-end services requiring QoS guarantees

This depends on your QOS requirements. RSVP and TE will work fine over
any network that has the right hardware and is in the same management
domain, I've always believed that you can only gaurantee latency and/or
bandwidth over your own network, everything else is essentially out of
your control. The BGP topology is mostly irrelevant in this case,
providing you have the right routes in the right places if you are using
partial-table in some areas for reachability.

RE: Providing fast recovery

Standard practice in convergence applys here. Timer tweaking (if
necessary), redundant RRs, multihoming everything, following 3 layer
network model... etc. I don't feel I need to elaborate here.


Have a good read through these:

For BGP, including route-reflector/confederation operation and
methodology:
Internet Routing Architectures - Bassam Halabi, Danny McPherson
ISBN: 157870233X

And for BGP with MPLS VPNs and route-reflectors:
MPLS and VPN Architectures - Ivan Pepelnjak, Jim Guichard
ISBN: 1587050811


--Dan

> -----Original Message-----
> From: Roger Clark Williams [mailto:rogwilli@cisco.com] 
> Sent: 25 August 2004 14:25
> To: MPLS-ops Mailing List
> Subject: Fwd: [MPLS-OPS]: Route Reflector and Areas
> 
> Ahmad, one reason for route reflectors is basically to keep 
> unnecessary traffic in check. If you have 100 routers all 
> peering with each other, there is a lot of updating of route 
> tables and such. If there are two RR on the network, 
> generally speaking the RRs do the peering and the other 98 
> routers don't say much (or as much), and don't talk at all to 
> the other routers on the network, only to the RRs.
> 
> Area, relative to route reflection, come in at least two 
> types. There are BGP areas that use route reflectors for IP 
> traffic, and when using MPLS VPNs there are VPNv4 route 
> reflectors. The reason for areas is that no one group can 
> manage all the routers in the world, so they break their 
> management into areas that tend to follow corporate lines and 
> international boundaries. Verizon manages theirs, British 
> Telecom manages theirs, and so forth.
> 
> The questions at the end of your note are really more "Layer 
> 8" problems: 
> It is a people or corporate issue more than a hardware issue. 
> The issues around end-to-end performance can all be worked 
> out assuming (in my example
> above) that Verizon and BT communicate and do things that 
> allow for perfect end-to-end QoS. In the real world, as with 
> many things, it depends
> 
> I hope that helps
> 
> Roger Williams
> 
> 
> >X-BrightmailFiltered: true
> >Resent-Date: Wed, 25 Aug 2004 06:02:12 -0400
> >X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 
> set sender 
> >to mpls-ops-request@mplsrc.com using -f
> >Date: Wed, 25 Aug 2004 02:45:14 -0700 (PDT)
> >From: Ahmad Suzaili Shaari <suzaili@yahoo.com>
> >To: mpls-ops <mpls-ops@mplsrc.com>
> >Subject: [MPLS-OPS]: Route Reflector and Areas
> >Resent-From: mpls-ops@mplsrc.com
> >X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/7570
> >X-Loop: mpls-ops@mplsrc.com
> >Resent-Sender: mpls-ops-request@mplsrc.com
> >X-PMX-Version: 4.6.1.107272
> >X-from-outside-Cisco: 128.107.250.145
> >
> >Hi,
> >
> >I'm new in IP and MPLS and a little bit confuse with the 
> existence of 
> >Route Reflectors (RR) and segmenting the network into 
> multiple areas. 
> >My questions are as follows:
> >
> >1. Why do we need to have multiple areas in the network?
> >2. If we have RR implemented in the network, can we maintain 
> a single 
> >area in the network.
> >3. Is it true that, if the network is segmented into 
> multiple areas, it 
> >is difficult to perform the following:
> >    * Supporting end-to-end services requiring QoS guarantees
> >    * -Perfoming network resource optimisation
> >    * Providing fast recovery -
> >  Thank you.
> >-
> >
> >
> >Do you Yahoo!?
> ><http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotion
> s.yahoo.co
> >m/new_mail/static/efficiency.html>New
> >and Improved Yahoo! Mail - Send 10MB messages!
> 
> Roger Clark Williams
> Network Consulting Engineer
> Global OSS/NMS Practice
> IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
> Cisco Systems, Inc.
> phone: 802.221.1104
> cell: 802.355.9933
> email: rogwilli@cisco.com
> 
> Leave it, change it, or accept it. Anything else is madness.  
> 
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml