re: MPLS Arrives in Access NetsCan anyone discuss relative the merits (or demerits) of using MPLS in Access as opposed to L2 and L2 VPNs? (I've actually been a believer of MPLS in access for a quite a while, but I admit my reasons for favoring this approach may be out of date.)
re: MPLS Arrives in Access NetsAnd what makes these companies believe that they've got what it takes? What differentiates these unknown, untried, unproven vendors over the more established companies like Cisco and Juniper?
Sounds like more VC money about to make a loud, sucking sound.
re: MPLS Arrives in Access NetsJust judging from the article, the new offerings appear use MPLS to provide logicaly separate "pipes" for each type of traffic from a customer to a PoP. This mechanism is useful for differentiated services. However, (and again, just judging from the article) the pipes terminate at the PoP. This is important for two reasons: 1) it only requires a relatively small number of pipes per subscriber in hte access boxes and 2) it only requires a relatively small number of pipes in the edge and core.
Given all this, there is no theoretical difference between pipes implemented as MPLS LSPs and pipes implemented as VLANs. There are practical differences, of course
VPNs are another story, because an L2 or MPLS VPN requires state in the core. If rhis type of VPN becomes pervasive, the core will need a massive amount of state information.
re: MPLS Arrives in Access Nets I guess the point is that ...
1. PWE3 LSPs differ from VLANs in that they can carry multi-service traffic - not just your 'new' Ethernet services - there's a lot of TDM frame relay pipes you could convert to packets at the edge to save metro bandwidth (there was an article on LR about AT&T's presentation at a conference where they said this would be huge for them)
2. It's not just about access - setting up an MPLS PWE3 LSP to carry end-to-end multi-service traffic across the MPLS core network to 'emulate' the switched layer 2 services of today might enable carriers to get off their legacy ATM switch faster ... moving to the converged MPLS core (isn't that what the Martini drafts were supposed to make happen?)
I guess it may make sense to do this in the metro and access if you can do it cheaper just at layer 2 ... the price of these types of interfaces on Cisco and Juniper routers is pretty high (everyone complains about this) as they carry the cost of all the L3 services that may or may not be needed. It sounds like a parallel for the same issue that led to the explosion in the ATM IAD market - service interfaces on ATM switches were just too expensive and in the wrong place in the network.
Interesting that multiple companies seem to be coming to market with this at the same time, although WWP seems to be more of a future story and Ethernet focused.
Mixing PWE3 and GFP sounds different ... is there a standard for this?
re: MPLS Arrives in Access Nets1. PWE3 over GFP is not standardized yet (ITU G.7041 work is in progress). GFP User Payload Identifier (UPI, which denotes the type of payload encapsulated by the GFP layer) doesnGÇÖt include MPLS yet. So until ITU refreshes the GFP spec, an MPLS encapsulated packet (such as PWE3 packets) must have a mediation layer such as PPP, Ethernet, or RPR, which have a formal GFP UPI.
2. MPLS in the access networks, is okay as long as it stays point to point, at least up to the first Metro edge equipment. When considering multipoint services (l2vpn/VPLS), the requirement for a full mesh of pseudowires between PEs doesnGÇÖt scale well enough [n x (n-1) LSPs] to start from the customer location or the low-end access switch. H-VPLS approaches this problem by allowing either QinQ, or Hub & Spoke pseudowires to be used in the access, while the full mesh starts only higher in the network.
3. ItGÇÖs becoming quite obvious that MPLS L2 VPNs (aka VPLS) will dominate the metro network. In addition, pseudowires are becoming the transport (as is E1, FR, ATM, etc.). It makes good sense to push it out as close to the customer as possible but, as stated above, the multipoint solution should be an Hierarchical VPLS.
4. Another point to consider is where you want your routing to start. The l2vpn relieves most metro networks from the need to do IP routing, leaving it to the edge routers at the IP/MPLS edge (where the L3VPN startsGǪ).
re: MPLS Arrives in Access NetsLayer 2 service is cheap and fast, while Layer 3 is pricier, but more intelligent. The question seems to be how far into a network you can go with Layer 2 without running into management or traffic interference problems. Could you get the dreaded "broadcast storm" in a Layer 2 metro network?
Sounds like more VC money about to make a loud, sucking sound.
Given all this, there is no theoretical difference between pipes implemented as MPLS LSPs and pipes implemented as VLANs. There are practical differences, of course
VPNs are another story, because an L2 or MPLS VPN requires state in the core. If rhis type of VPN becomes pervasive, the core will need a massive amount of state information.
I guess the point is that ...
1. PWE3 LSPs differ from VLANs in that they can carry multi-service traffic - not just your 'new' Ethernet services - there's a lot of TDM frame relay pipes you could convert to packets at the edge to save metro bandwidth (there was an article on LR about AT&T's presentation at a conference where they said this would be huge for them)
2. It's not just about access - setting up an MPLS PWE3 LSP to carry end-to-end multi-service traffic across the MPLS core network to 'emulate' the switched layer 2 services of today might enable carriers to get off their legacy ATM switch faster ... moving to the converged MPLS core (isn't that what the Martini drafts were supposed to make happen?)
I guess it may make sense to do this in the metro and access if you can do it cheaper just at layer 2 ... the price of these types of interfaces on Cisco and Juniper routers is pretty high (everyone complains about this) as they carry the cost of all the L3 services that may or may not be needed. It sounds like a parallel for the same issue that led to the explosion in the ATM IAD market - service interfaces on ATM switches were just too expensive and in the wrong place in the network.
Interesting that multiple companies seem to be coming to market with this at the same time, although WWP seems to be more of a future story and Ethernet focused.
Mixing PWE3 and GFP sounds different ... is there a standard for this?
2. MPLS in the access networks, is okay as long as it stays point to point, at least up to the first Metro edge equipment. When considering multipoint services (l2vpn/VPLS), the requirement for a full mesh of pseudowires between PEs doesnGÇÖt scale well enough [n x (n-1) LSPs] to start from the customer location or the low-end access switch. H-VPLS approaches this problem by allowing either QinQ, or Hub & Spoke pseudowires to be used in the access, while the full mesh starts only higher in the network.
3. ItGÇÖs becoming quite obvious that MPLS L2 VPNs (aka VPLS) will dominate the metro network. In addition, pseudowires are becoming the transport (as is E1, FR, ATM, etc.). It makes good sense to push it out as close to the customer as possible but, as stated above, the multipoint solution should be an Hierarchical VPLS.
4. Another point to consider is where you want your routing to start. The l2vpn relieves most metro networks from the need to do IP routing, leaving it to the edge routers at the IP/MPLS edge (where the L3VPN startsGǪ).