Subject: MEF E-Tree over MPLS/VPLS

From: Simon Delord <[email-masked]>
Date: Fri, 27 Nov 2009 16:05:44 +1100

Bonjour everyone,

We have recently submitted two Internet drafts to both the PWE3 and L2VPN WG
regarding how to implement E-Tree services (defined by the Metro Ethernet
Forum in MEF6.1 and MEF10.1 specifications) over MPLS networks.

Our approach relies on a simple extension to the current Virtual Private LAN
Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet
Encapsulation standard (RFC 4448). With such extension, VPLS can be used to
support both E-LAN and E-Tree services at the same time on an MPLS network.

*http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt*<http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt>

*http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt*<http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt>

Based on the comments and discussions we've had so far with a number of
vendors and carriers, no critical technical issue with the proposal has been
raised. We are currently working on the next version and would like to have
the working group members comments on the proposed extension.

In particular, if the authors of the current standards (RFC 4761, RFC 4762,
RFC 4448) can give us some feedback, it would be fantastic.

We also produced a third document on the L2VPN WG, a framework that explains
the need for E-Tree services as well as the problem statement with the
current situation.

*http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt*<http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt>

Many thanks.

Simon

---

From: Luca Martini <[email-masked]>
Date: Mon, 30 Nov 2009 20:19:48 -0700

Simon,

The main problem with this design is that it uses the CW to signal 
topology information. This is not an appropriate use of the CW. Now,  
having said that , let's explore the problem a bit further.
 Th E-tree construct was always envisioned to be used in conjunction 
with VPLS BGP autodiscovery. It is simple to use a scheme of leaf RT , 
and Root RT and BGP import filters to achieve the functionality you 
desire using today's standards.
There are a couple of corner problems , like when there are leafs 
co-located with Roots in the same PE. These I believe can be solved by 
using multiple VFIs in that particular PE.
Any more corner cases I did not think about ?

The reference  the P2MP PW , I do not understand.  Can you explain a bit 
more ?

Thanks.
Luca

Simon Delord wrote:
>
> Bonjour everyone,
>
> We have recently submitted two Internet drafts to both the PWE3 and 
> L2VPN WG regarding how to implement E-Tree services (defined by the 
> Metro Ethernet Forum in MEF6.1 and MEF10.1 specifications) over MPLS 
> networks.
>
> Our
>
> approach relies on a simple extension to the current Virtual Private 
> LAN Service (VPLS) standards (RFC 4761 / RFC 4762) and PWE3 Ethernet 
> Encapsulation standard (RFC 4448). With such extension, VPLS can be 
> used to support both E-LAN and E-Tree services at the same time on an 
> MPLS network. 
> _http://www.ietf.org/id/draft-key-l2vpn-vpls-etree-01.txt_ 
> _http://www.ietf.org/id/draft-delord-pwe3-cw-bit-etree-01.txt_
>
> Based on the comments and discussions we've had so far with a number 
> of vendors and carriers, no critical technical issue with the proposal 
> has been raised. We are currently working on the next version and 
> would like to have the working group members comments on the proposed 
> extension.
>
> In particular, if the authors of the current standards (RFC 4761, RFC 
> 4762, RFC 4448) can give us some feedback, it would be fantastic.
>
> We also produced a third document on the L2VPN WG, a framework that 
> explains the need for E-Tree services as well as the problem statement 
> with the current situation.
>
> _http://www.ietf.org/id/draft-key-l2vpn-etree-frwk-00.txt_
>
> Many thanks.
>
> Simon
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: "Mallette, Edwin" <[email-masked]>
Date: Mon, 30 Nov 2009 23:59:18 -0500

Luca,

This could be a simple question of terminology, but unless I'm missing something there is no real change to the CW signaling mechanism.  The CW signaling mechanism is really do I use a control word or not.  It strikes me that this draft simply proposes utilizing the CW as a forwarding mechanism.  Then the egress PE would have to look at the control word and the MAC header to determine where (if) to forward the frame.

The corner cases of how to handle leafs and roots in the same PE can be handled much like "private" VLANs are handled in traditional ethernet switches - given that you would actually define a leaf and a root AC in advance this would be a relatively simple logic modification within the PE.

Now I understand that the draft states it does not intend to address efficient packet replication or bandwidth optimization, though I think this could be accomplished with another step.  Thus to the next problem - how we learn if a root lives off a specific pseudowire.  Option a) we track the presence of the L-bit from a pseudowire (in a table like the bridge table) to ensure we correctly forward from leaf to root, root to root, etc.  Option b) we use a BGP autodiscovery mechanism to distribute whether a PE "owns" a root AC for a given VFI or not.

Ultimately, I still can't see a way around setting a bit somewhere in either the PW header or MAC header (if you say the CW is not the right place) to designate the source type (leaf or root) so we could ensure the frame is forwarded correctly at the egress PE.

Regards,
Ed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca Martini
Sent: Monday, November 30, 2009 10:20 PM
To: Simon Delord
Cc: [email-masked]; pwe3
Subject: Re: [PWE3] MEF E-Tree over MPLS/VPLS

Simon,

Thanks.
Luca

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.