Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: MPLS in metro access networks

  • From: Gary Blankenship
  • Date: Sun Nov 18 05:41:04 2001

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





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.