MPLS in metro access networks

Gary Blankenship garyb at foundrynet.com
Fri Nov 16 08:34:15 UTC 2001


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
garyb at foundrynet.com
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: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf
Of
> Michael Cohen
> Sent: Friday, November 16, 2001 3:45 AM
> To: nanog at merit.edu
> 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:mquibell at icn.state.ia.us]
> Sent: Thursday, November 15, 2001 12:04 PM
> To: 'mcohen at thrupoint.net'; nanog at merit.edu
> 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:mcohen at thrupoint.net]
> Sent: Thursday, November 15, 2001 11:20 AM
> To: nanog at merit.edu
> 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:mquibell at icn.state.ia.us]
> Sent: Thursday, November 15, 2001 10:59 AM
> To: 'mcohen at thrupoint.net'; 'nanog at merit.edu'
> 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:mcohen at thrupoint.net]
> 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:mquibell at icn.state.ia.us]
> Sent: Thursday, November 15, 2001 10:46 AM
> To: 'mcohen at thrupoint.net'; nanog at merit.edu
> Subject: RE: MPLS in metro access networks
> 
> 
> Are we talking about Multiprotocol Label Switching?
> 
> Marc
> 
> 
> -----Original Message-----
> From: Michael Cohen [mailto:mcohen at thrupoint.net]
> Sent: Thursday, November 15, 2001 10:45 AM
> To: nanog at merit.edu
> 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: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
> Quibell, Marc
> Sent: Thursday, November 15, 2001 10:20 AM
> To: 'srihari varada'; nanog at merit.edu
> 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:varada at txc.com]
> Sent: Thursday, November 15, 2001 10:12 AM
> To: nanog at merit.edu
> 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




More information about the NANOG mailing list