Scribd
Upload
73 views12 pages

E-TREE Requirements and Solution Space: Jim Uttaro Nick Delregno Florin Balus

E-Tree Enables Point-to-Multipoint Services with less provisioning than typical hub and spoke configuration using E-Lines. Traffic from one "leaf" being allowed to arrive at one of more "Roots" but never being transmitted to other "leaves"

Uploaded by

Veeresh Wadageri
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
73 views12 pages

E-TREE Requirements and Solution Space: Jim Uttaro Nick Delregno Florin Balus

E-Tree Enables Point-to-Multipoint Services with less provisioning than typical hub and spoke configuration using E-Lines. Traffic from one "leaf" being allowed to arrive at one of more "Roots" but never being transmitted to other "leaves"

Uploaded by

Veeresh Wadageri
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

E-TREE Requirements and Solution space

Jim Uttaro (uttaro@att.com) Nick Delregno (nick.delregno@verizon.com) Florin Balus (florin.balus@alcatel-lucent.com)

Services Using E-Tree Service Type


Ethernet Private Tree (EP-Tree) and Ethernet Virtual Private Tree (EVP-Tree) Services
Enables Point-to-Multipoint Services with less provisioning than typical hub and spoke configuration using E-Lines Provides traffic separation between users with traffic from one leaf being allowed to arrive at one of more Roots but never being transmitted to other leaves
Leaf
UNI UNI CE

Root
UNI

Leaf Leaf
UNI

UNI CE

CE

Carrier Ethernet Network

E-Tree is referenced in MEF 10.1 as Rooted-Multipoint EVC

CE

E-TREE challenges

CE

Root
UNI CE UNI

Leaf
UNI

Leaf

PE

PE
Carrier Ethernet Network

CE

Leaf PE
UNI CE

Root
CE UNI

Leaf PE
UNI

PE

UNI CE

Root
UNI

Leaf Leaf

1. Standardized, interoperable solution for all traffic types?


CE CE

2. How to distinguish Leaf from Root originated traffic between two Leaf & Root PEs?

3 | ETREE discussion | March 2010

E-Tree many scenarios: multiple technologies combined across different domains


L L
R

Leaf endpoint (MEF UNI, ENNI, VUNI) Root endpoint (MEF UNI, ENNI, VUNI)
L L L R L L R L L

Metro Access
L L

Metro Core
L

Long Haul

L L L L L

Domains Possible Technologies Use Case example 1 Use Case example 2 Use Case example 3 Use Case example 4

Metro Access/Aggregation Native Ethernet (PB/PBB) or VPLS/PBB-VPLS (LDP/BGP) Native Ethernet PB (QinQ) Native Ethernet PB Native Ethernet PB VPLS (LDP)

Metro Core Native Ethernet (PBB) or VPLS/PBB-VPLS (LDP/BGP) Native Ethernet (PBB) VPLS (LDP) VPLS (BGP)

Long Haul (WAN) VPLS/PBB-VPLS (LDP/BGP) PBB-VPLS (LDP)

VPLS (BGP)

4 | ETREE discussion | March 2010

Available technologies

Service Data Plane Ethernet switching common across technologies QinQ SVIDs, PBB ISIDs and/or VPLS PWs as Carrier service infrastructure Control Plane used for setting up the Service Infrastructure BGP - BGP VPLS or LDP VPLS with BGP-AD LDP - LDP VPLS with no BGP-AD Native Ethernet e.g. MRP, SPB/SPBB

5 | ETREE discussion | March 2010

E-Tree solution option 1 Control the PW topology

L
R

Leaf endpoint Root endpoint


L L L L R1

Metro Access
L L

Metro Core

Long Haul

L L L

Do not build PW infrastructure between Leaf PEs (no PWs between Leaf VSIs)
Control the PW topology, potentially using BGP RTs BGP RT approach used already in L3 VPNs for similar functions

6 | ETREE discussion | March 2010

E-Tree solution option 2 use Root/Leaf Tag to filter traffic between Leaf endpoints
L L
R

Leaf endpoint Root endpoint


L L L R1 L L R2 L L

Metro Access
L2

Metro Core
L

Long Haul

L1

L L

Tag traffic differently depending on the entry endpoint in the service


If incoming on a leaf endpoint add tag L, see example
L1
R2

If incoming on a root endpoint add tag R, traffic distributed everywhere, see example

Do not send traffic marked with tag L out on leaf endpoints, see example

L2

7 | ETREE discussion | March 2010

E-Tree solution option 2 use Root/Leaf Tag to filter traffic between Leaf endpoints
L L
R

Leaf endpoint Root endpoint


L L L R1 L L R2 L L

Metro Access
L2

Metro Core
L

Long Haul

L1

L L

What can be used as R/L tag? Option 2a. Use the PW information - CW bit (proposal discussed in IETF) Option 2b. Use a field from the Ethernet header VLAN (proposals discussed in IEEE, ITU-T) Option 2a or 2b can be combined with Option 1 where available

8 | ETREE discussion | March 2010

Comparison of possible ETREE solutions

Proposed solutions Option 1: Control PW topology

Pros Minimal/no standard work No tag required

Cons No support for native Ethernet (PW-only) No support for PBB-VPLS M:1 model (requires dedicated B-VPLS per service) May require standard work in L2VPN No support for native Ethernet Challenges supporting PBB-VPLS M:1 model (requires dedicated B-VPLS per service) Requires standard work in L2VPN May require 4 bytes overhead if additional SP VLAN is inserted Requires standard work in IEEE

Option 2a: PW CW bit

No overhead, re-using existing CW bit May re-use Option 1 as a complementary mechanism where available to optimize BW usage Common for all technologies No need for interworking at gateways Supported across technologies May re-use Option 1 as a complementary mechanism where available to optimize BW usage

Option 2b: VLAN-tag (IEEE/ITU-T)

9 | ETREE discussion | March 2010

E-Tree solution for 2 (Leaf + Root) PEs using only option 1 (PW only environment)

L
R

Leaf endpoint Root endpoint Split Horizon


L L R1

R2

L L

Metro Access

Metro Core

Long Haul

Do not build PW infrastructure between Leaf PEs (no PWs between Leaf VSIs)
Control the PW topology, potentially using BGP RTs Split Horizon Groups are required to prevent loops

10 | ETREE discussion | March 2010

E-Tree solution for 2 (Leaf + Root) PEs using option 1 + option 2b

L
R

Leaf endpoint Root endpoint Split Horizon


L L R2 R1 L L

Metro Access

Metro Core

Long Haul

Option 1: Do not build PW infrastructure between Leaf PEs (no PWs between Leaf VSIs) Option 2b: Use VLAN Tag to simplify the PW topology and to support native Ethernet

11 | ETREE discussion | March 2010

To discuss

Is IEEE proposed solution (Option 2b, VLAN-based tag) acceptable as a baseline?


If it is then we do not need multiple data plane based solutions If not should L2VPN do a separate solution? Or should we just send a liaison to IEEE explaining L2VPN position?

What kind of optimizations are required more than Option 1?


Do we need any L2VPN work here?

Need to keep the number of ETREE solutions to common and minimal set
Avoid duplication and/or multiple solutions where possible.

12 | ETREE discussion | March 2010

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy