North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: MPLS in metro access networks
Forgive me for the config error on the previous post. Loopbacks on router D should have been X.X.50.X not X.X.5.X. Gary > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Gary Blankenship > Sent: Friday, November 16, 2001 5:34 PM > To: [email protected] > Subject: RE: MPLS in metro access networks > > > Srihari: > > I'm going to attempt to answer your original question: > > > -- If so, what motivates them to do so? Any analysis of the driving > > forces is appreciated. > > All: > > I've been consulting MPLS solutions for service providers here in Asia. > The main reason for running MPLS is traffic engineering. The main > reason for desiring traffic engineering is because of the > hyper-aggregation problem with the routing protocols. I talked to one > provider who was obviously stressed and showed emotion when addressing > this problem. Basically, they appeared just shy of desperate. > > You also have more flexibility separating the data and control planes. > Remember that the control plane (RSVP, IP Telephony, IBGP sessions > across the network core) follows the same best path(s) as the data plan. > Fortunately for RSVP, you can strict and loose route to avoid this > problem. I assume this is important because RSVP is how you signal the > LSP's to solve the original problem! You can engineer each plane and > classify flows into Forward Equivalency Classes (FECs). Think of the > example I will post below as the endpoints to the L2 VPN going towards > the Virtual Circuit (VC FEC). > > WARNING: Traffic Engineering can create more problems than it solves if > you do not engineer correctly. Data collection BEFORE traffic > engineering is essential. You should enter step 2 (configuring TE) with > full understanding of your network. > > How do I apply this in a metro access network? Before we talk about > MPLS, let's talk about a metro network that uses Super VLAN Aggregation > (not standardized, Foundry and Extreme support as well as other vendors > who I apologize for not mentioning if they do. If you work for one of > these vendors please let me know so I can tell my customers who our > competitors are :-). You can traffic engineer using 802.1s STP > groupings, but you have scalability limitations (12 bits of VLAN ID in > .1q tag) of 4096x4096. This is an excellent solution with all of the > other enhancements such as 802.1w (Rapid Spanning Tree for failover > times of less than 5 seconds and as fast as 50ms). Additionally, vendor > proprietary standards help out such as Foundry's Super Span for > segregating STP domains and tunneling BPDU's to arrive where they > should. > > Now let's talk about MPLS. Most of you are smarter than I and familiar > with Cisco IOS. Foundry uses a similar flavor of the CLI (like > different UNIX versions :-) I'll drop a config on how you can engineer > 4 VLANS through your network. > > The users think they are on the same Ethernet wire (Ethernet Psuedo Wire > End-to-End Encapsulation). One LSP transmits and one LSP receives (full > duplex). The technology involved is simple Layer2 VPN Draft Martini. > It is only point to point and this is not the forum to discuss the ever > evolving standards that are competing; however, the Martini drafts are > mature and I believe ready to reach informational RFC status very soon. > > I don't believe the market (NANOG folks reading this message for > example) wants the complexity of running BGP on L2 or L3 VPNs. This is > why you won't find too much support for the new draft Kompella (not to > be confused with the developing VPLS draft VKompella). Juniper showed a > configuration slide of this at MPLS Japan last week (original draft > recently released and not mature "00" with no revisions and missing > information). I would request someone from Juniper post a configuration > to this list showing my same example with Kompella support for > complexity comparison. If I were a Juniper customer already running L3 > VPN I would take a serious look at this. It reduces the complexity a > bit, but not enough for my liking. > > Everyone agrees that separating MAC address learning is essential for > solving MAC address scalability requirements. Targeted LDP sessions > appear to be a lot less complex than BGP and we may see some solutions > arrive soon. The Martini drafts got the LDP targeted sessions covered > nicely. I'm an SE who reads NANOG to help better understand my > customers' problems. I'm not a developer and I'm not caught up in the > whirlwind going on in the MPLS WG or back in San Jose. I'll leave that > task to smarter folks with better access to Starbucks. > > I also encourage you to take a look at using Super VLAN technology with > an MPLS core to solve scalability problems when you want the best of > both words. > > Example Terminology: > > LSP: Label Switched Path that uses the tunnel label. Signaled and > setup through RSVP in this example. > > VLL: Virtual Leased Line that uses the VC label. > > OSPF-TE: Opaque LSA support. Note that I've configured and I HIGHLY > recommend you do this whether you use CSPF or not. "show ip ospf > database link opaque" can be an awesome command and I believe it is the > same on Cisco IOS. For those of you that have this ability and > understanding, you may want to generate these LSA's regardless of your > plans for MPLS. > > Hot standby paths: Pre-signaled RSVP paths for faster failover in this > example. > > My example also uses statically defined VC label definitions. This > brings up the VC as soon as the LSP route comes up (show mpls route) and > reduces convergence time by eliminating the need for targeted LDP > overhead. NOTE: Consider this L2 VPN complexity that can be eliminated > if you think it is too complex to manage. These are the values you see > after the vll-peer statements. > > I will demonstrate the mixing and matching of tagged 802.1Q lines as > well. > > We have a topology as follows: > > B > A_/ \_D > \ / > C > > Please don't give me any feedback of "Why" I would run MPLS on such a > simple network. It is meant for simplicity only. Note that these are > working configs for the folks that knock MPLS for configuration > complexity. I cannot speak for other vendors. You would also need our > latest and greatest code (7.5.00) which is not available to our non beta > customers until next week. I've included configs for B, but not C. I'm > sure you can all figure out C. > > -------------------------------------------------------- > hostname A > > router mpls > policy > traffic-eng ospf > > mpls-interface p2/1 > mpls-interface p2/2 > > path B-to-D > strict 192.168.10.2 > strict 192.168.20.1 > path C-to-D > strict 192.168.30.2 > strict 192.168.40.1 > > lsp LSP1 > to 192.168.50.1 > primary B-to-D > secondary C-to-D > standby > enable > > lsp LSP2 > to 192.168.50.2 > primary B-to-D > secondary C-to-D > standby > enable > > lsp LSP3 > to 192.168.50.3 > primary B-to-D > secondary C-to-D > standby > enable > > lsp LSP4 > to 192.168.50.4 > primary C-to-D > secondary B-to-D > standby > enable > > vll VLAN10 10 > vll-peer 192.168.50.1 800001 900001 > vlan 10 > tagged e 1/1 > vll VLAN20 20 > vll-peer 192.168.50.2 800002 900002 > vlan 20 > tagged e 1/1 > vll VLAN30 30 > vll-peer 192.168.50.3 800003 900003 > vlan 30 > tagged e 1/1 > vll VLAN40 40 > vll-peer 192.168.50.4 800004 900004 > vlan 40 > tagged e 1/1 > ! > boot sys slot1 N2M07500.bin > route-only > router ospf > area 0 > ! > interface loopback 1 > ip address 192.168.5.1 255.255.255.255 > ip ospf area 0 > > interface loopback 2 > ip address 192.168.5.2 255.255.255.255 > ip ospf area 0 > > interface loopback 3 > ip address 192.168.5.3 255.255.255.255 > ip ospf area 0 > > interface loopback 4 > ip address 192.168.5.4 255.255.255.255 > ip ospf area 0 > ! > interface ethernet 1/1 > enable > ! > interface pos 2/1 > enable > ip address 192.168.10.1 255.255.255.0 > ip ospf area 0 > ! > interface pos 2/2 > enable > ip address 192.168.30.1 255.255.255.0 > ip ospf area 0 > ! > ! > ! > ! > ! > end > > -------------------------------------------- > > hostname D > router mpls > policy > traffic-eng ospf > > mpls-interface p2/1 > mpls-interface p2/2 > > path B-to-A > strict 192.168.20.2 > strict 192.168.10.1 > path C-to-A > strict 192.168.40.2 > strict 192.168.30.1 > > lsp LSP1 > to 192.168.5.1 > primary B-to-A > secondary C-to-A > standby > enable > > lsp LSP2 > to 192.168.5.2 > primary B-to-A > secondary C-to-A > standby > enable > > lsp LSP3 > to 192.168.5.3 > primary B-to-A > secondary C-to-A > standby > enable > > lsp LSP4 > to 192.168.5.4 > primary C-to-A > secondary B-to-A > standby > enable > > vll VLAN10 10 > vll-peer 192.168.5.1 900001 800001 > untagged e 1/1 > vll VLAN20 20 > vll-peer 192.168.5.2 900002 800002 > untagged e 1/2 > vll VLAN30 30 > vll-peer 192.168.5.3 900003 800003 > untagged e 1/3 > vll VLAN40 40 > vll-peer 192.168.5.4 900004 800004 > untagged e 1/4 > > ! > boot sys slot1 N2M07500.bin > route-only > router ospf > area 0 > ! > interface loopback 1 > ip address 192.168.5.1 255.255.255.255 > ip ospf area 0 > > interface loopback 2 > ip address 192.168.5.2 255.255.255.255 > ip ospf area 0 > > interface loopback 3 > ip address 192.168.5.3 255.255.255.255 > ip ospf area 0 > > interface loopback 4 > ip address 192.168.5.4 255.255.255.255 > ip ospf area 0 > ! > interface ethernet 1/1 > enable > ! > interface pos 2/1 > port-name NI800_D_POS_3/1 > enable > ip address 192.168.40.1 255.255.255.0 > ip ospf area 0 > ! > interface pos 2/2 > port-name NI800_D_POS_3/2 > enable > ip address 192.168.20.1 255.255.255.0 > ip ospf area 0! > ! > ! > ! > ! > end > > ------------------------------------------------- > hostname C > > router mpls > policy > admin-group OSPF-Primary-Link 2 > traffic-eng ospf > > mpls-interface p6/1 > admin-group 2 > mpls-interface p6/2 > admin-group 2 > > > > > ! > boot sys slot1 N2M07500B5.bin > route-only > router ospf > area 0 > ! > interface pos 6/1 > enable > ip address 192.168.40.2 255.255.255.0 > ip ospf area 0 > ! > interface pos 6/2 > enable > ip address 192.168.30.2 255.255.255.0 > ip ospf area 0 > ! > ! > ! > ! > ! > end > > > Gary Blankenship > Foundry Networks > Systems Engineer - Japan > CCIE #5009 > [email protected] > www.foundrynet.com > > PC Magazine Selects Foundry FastIron 4802 as Best High End Ethernet > Switch: > http://www.pcmag.com/article/0,2997,s%253D25109%2526a%253D17629,00.asp > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > Of > > Michael Cohen > > Sent: Friday, November 16, 2001 3:45 AM > > To: [email protected] > > Subject: RE: MPLS in metro access networks > > > > > > Maybe I'm getting confused. The original post asked the question > "what > > motivates them" (RBOCs, ILECs, and CLECs) to implement MPLS. You > answered > > that fast switching/routing was a reason. I disagree with this > because > > designing and implementing MPLS just for speed benefits is a bit too > > cumbersome and complex compared to using local caching mechanisms that > are > > just as fast, if not faster. Saying that using MPLS as an alternative > to > > using local caching mechanisms because of standardization doesn't make > > sense > > to me either because the local caching mechanisms are in place > regardless. > > In fact, you can't run MPLS on most vendor hardware without running > their > > proprietary caching (Cisco mandates using CEF before implementing MPLS > and > > Juniper uses it's FPC hardware architecture regardless of MPLS). So > to > > add > > to my point, there is no speed benefit in running MPLS if you are > already > > using modern caching techniques, which most service providers > interested > > in > > MPLS are already doing. > > > > To respond to your second point regarding using added services I agree > > completely that these services require MPLS labels to work. However, > this > > still has nothing to do with speed benefits. You say "these services > > depend > > upon the faster delivery" of MPLS but the RFC doesn't mention speed at > all. > > It just says "This approach uses MPLS running in the backbone to > provide > > premium services". Any MPLS added service uses label stacking which > > allows > > for the RFC stated "premium services". > > > > Cheers, > > > > -Michael Cohen > > > > -----Original Message----- > > From: Quibell, Marc [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 12:04 PM > > To: '[email protected]'; [email protected] > > Subject: RE: MPLS in metro access networks > > > > > > I guess you answered your own question: "And I'm not sure what faster > > switching/routing has to do with MPLS:)" > > > > As far as CEF and such goes, I couldn't disagree with that (as I was > not > > comparing MPLS to other optimized forwarding techniques), however, > MPLS is > > not a vendor-proprietary forwarding mechanism, which means that I can > > deploy > > it worldwide, or state-wide, whatever the case may be, in my network > and > > have the benefit of using only ONE protocol with MPLS-enabled/aware > > routers/switches. A definate plus over the other proprietary fast > > switching > > techniques you mentioned. > > > > Your last statement indicates "added services" have nothing to do with > the > > the fast switching processing of MPLS, when in fact these services > depend > > upon the faster delivery of the non-proprietary fast switching of > MPLS. As > > quoted from the rfc: > > > > "This memo presents an approach for building core Virtual Private > > Network (VPN) services in a service provider's MPLS backbone. This > > approach uses Multiprotocol Label Switching (MPLS) running in the > > backbone to provide premium services in addition to best effort > > services." > > > > Marc > > > > > > -----Original Message----- > > From: Michael Cohen [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 11:20 AM > > To: [email protected] > > Subject: RE: MPLS in metro access networks > > > > > > > > I still have to disagree that MPLS results in faster switching/routing > in > > modern service provider networks. Modern vendor caching mechanisms > are > > just > > as fast if not faster than MPLS processing. With the small overhead > of > > MPLS > > labels and LDP I highly doubt that you're getting any performance > increase > > over Cisco's CEF or Juniper's FPC architecture. I also doubt that > speed > > is > > a benefit that service providers consider when deciding whether or not > > they > > want to implement MPLS. Added services that run on top of MPLS like > VPNs, > > traffic engineering, and fast rerouting capabilities (all mentioned in > the > > original post) are more likely the benefits considered. Perhaps when > > label > > switching was first being marketed (Ipsilon and Cisco in 1996) there > were > > some speed benefits but now I think it's the services that use MPLS > that > > are > > the major benefit. > > > > -Michael Cohen > > > > -----Original Message----- > > From: Quibell, Marc [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 10:59 AM > > To: '[email protected]'; '[email protected]' > > Subject: RE: MPLS in metro access networks > > > > > > soooo...Label switching assigns labels to packet headers which results > in > > less time and processing looking up routes, and instead relies upon a > > label > > index for forwarding decisions? Hence my statement "faster > > switching/routing > > and less processing":) > > > > Marc > > > > > > > > -----Original Message----- > > From: Michael Cohen [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 10:56 AM > > To: Quibell, Marc > > Subject: RE: MPLS in metro access networks > > > > > > I hope so:) > > > > -----Original Message----- > > From: Quibell, Marc [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 10:46 AM > > To: '[email protected]'; [email protected] > > Subject: RE: MPLS in metro access networks > > > > > > Are we talking about Multiprotocol Label Switching? > > > > Marc > > > > > > -----Original Message----- > > From: Michael Cohen [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 10:45 AM > > To: [email protected] > > Subject: RE: MPLS in metro access networks > > > > > > > > And I'm not sure what faster switching/routing has to do with MPLS:) > I > > believe one of the ideas behind MPLS benefiting metro access networks > is > > using MPLS to deliver layer 2 VPNs across an MPLS enabled core thus > > simulating leased lines for access clients...but I'm sure somebody > will > > correct me if I'm wrong. There seems to be some hype for Martini > draft > > VPNs > > and large enterprise customers in metro areas. > > > > Cheers, > > > > -Michael Cohen > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]]On Behalf Of > > Quibell, Marc > > Sent: Thursday, November 15, 2001 10:20 AM > > To: 'srihari varada'; [email protected] > > Subject: RE: MPLS in metro access networks > > > > > > > > I would think faster switching/routing and less processing would be > wanted > > in any mid-to-large sized network...I'm not sure what load balancing > and > > fault restoration has to do with MPLS.... > > > > Marc > > > > > > > > -----Original Message----- > > From: srihari varada [mailto:[email protected]] > > Sent: Thursday, November 15, 2001 10:12 AM > > To: [email protected] > > Subject: MPLS in metro access networks > > > > > > Hello: > > > > I have heard some stressing the role of MPLS in metro access networks. > > It is difficult for me to visualize the need for it in them while it > > is not so difficult to understand the utility (load balancing and > fault > > restoration etc.) of it in the metro backbone networks. > > > > To characterize metro access networks in the context, the following is > > provided: > > -- aggregates traffic from residential (arriving via broadband access > > links such as xDSL, Cable) and business consumers (arriving via > > broadband access links such as > > xDSL and high speed links such as Ethernet or SONET) > > -- funnels aggregated traffic to metro backbone networks for > destination > > > > hosts in the local metro region or remote regions across the > > internet regional > > and backbone networks. Majority of such access networks are > SONET/ATM > > based (I didn't come > > across any case of Gig Ethernet. However, I do not preculde it). > > > > Thus, there are two questions: > > -- Are there known RBOCs/ILECs and CLECs entrenching MPLS in the said > > network scope? (I do not see many major ILECs in the un-official > MPLS > > service > > providers list being circulated but it may mean little) > > -- If so, what motivates them to do so? Any analysis of the driving > > forces is appreciated. > > > > Regards, > > > > Srihari Varada
|