Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS

From: "HENDERICKX Wim" <[email-masked]>
Date: Tue, 1 Dec 2009 13:56:07 +0100

The whole reason why this proposal was retained after long discussions
is because it does not add any additional signaling on the PW
infrastructure and does not touches the PW infrastructure for VPLS
services. 

When we create multiple VSIs we end up setting up more PW which we want
to avoid in this proposal.

As Edwin indicated the idea is to complement the draft with
auto-discovery procedures to optimize the traffic flows which are
unnecessary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mallette, Edwin
Sent: dinsdag 1 december 2009 5:59
To: Luca Martini; Simon Delord
Cc: [email-masked]; pwe3
Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS

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,

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
>

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

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.

---

From: David Allan I <[email-masked]>
Date: Tue, 1 Dec 2009 11:12:36 -0500

Hi Wim:

Just to clarify. If I have redundant roots, two of them, and a root co-located with a leaf I am only actually saving one PW... One from the alternate root to the node that hosts both root and a leaf...as otherwise I would need one root to root and one root to leaf....

Is my math correct?
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of HENDERICKX Wim
Sent: Tuesday, December 01, 2009 1:56 PM
To: Mallette, Edwin; Luca Martini; Simon Delord
Cc: [email-masked]; pwe3
Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS

The whole reason why this proposal was retained after long discussions is because it does not add any additional signaling on the PW infrastructure and does not touches the PW infrastructure for VPLS services. 

When we create multiple VSIs we end up setting up more PW which we want to avoid in this proposal.

As Edwin indicated the idea is to complement the draft with auto-discovery procedures to optimize the traffic flows which are unnecessary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mallette, Edwin
Sent: dinsdag 1 december 2009 5:59
To: Luca Martini; Simon Delord
Cc: [email-masked]; pwe3
Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS

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,

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

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.

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Tue, 1 Dec 2009 18:16:50 +0100

Dave,

In terms of PW yes, but you also need to add a bunch of configuration to
ensure you have proper split-horizon behavior between leafs, leaf and
root, etc.

Also when you have leafs and root ACs on the same node it becomes even
more interesting.

So all in all I believe that the draft ensures operational simplicity of
deploying an E-TREE solution with VPLS.

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: dinsdag 1 december 2009 17:13
To: HENDERICKX Wim; Mallette, Edwin; Luca Martini; Simon Delord
Cc: [email-masked]; pwe3
Subject: RE: [PWE3] MEF E-Tree over MPLS/VPLS

Hi Wim:

Just to clarify. If I have redundant roots, two of them, and a root
co-located with a leaf I am only actually saving one PW... One from the
alternate root to the node that hosts both root and a leaf...as
otherwise I would need one root to root and one root to leaf....

Is my math correct?
Dave 

-----Original Message-----
Of HENDERICKX Wim

-----Original Message-----

Luca,

Regards,
Ed

-----Original Message-----

Simon,

Thanks.
Luca

---

From: "BALUS Florin" <[email-masked]>
Date: Tue, 1 Dec 2009 12:38:39 -0600

Operational simplicity is important indeed here and configuring 2 sites
as root beats in my opinion the additional provisioning required for
VSIs, RTs etc. 

In addition and maybe the main argument for considering other options
than the BGP-AD one is the existence of other use cases, already
deployed and/or discussed in MEF and IEEE: i.e. HVPLS with no BGP-AD,
PBB-VPLS (where one PW could be used for different ETREE topologies and
even for ELINE, ELAN) and native Ethernet environments (QinQ or PBB with
no PWs) or a combination of these use cases. 

In my opinion the best option is to reactivate the discussion in IEEE to
get a solution based on the Ethernet data plane that is the simple to
use and works across technologies. From what I remember there was an
IEEE proposal to use two tags (I think by Steve in cc): one assigned to
traffic originated by Root site (say 1), a different one assigned for
traffic originated by Leaves (say 0). Then as the traffic passes through
the network, controls may be applied as required to limit its
distribution. These controls can be technology dependent mechanisms
(BGP-AD/T-LDP/manual provisioning/IEEE protocols) that build knowledge
in the network of leaf-only PEs/regions so that traffic tagged as leaf
(tag=0) is not distributed to a leaf only PE/region. In some use cases
these optimizations might not be required and the leaf originated
traffic can be dropped only at the leaf UNIs.

The solution proposed by Simon & Co uses a CW bit as a tag somehow
similarly with the IEEE approach. Ideally we should try to find though a
flag/tag in the Ethernet header that works for all use cases instead of
just VPLS. If there is no flag available in the Ethernet header maybe we
should consider the past IEEE proposal to use a VLAN tag for this
function. This is a bit of an overkill but it has the advantage that
everybody supports it right of the bat. But this is a discussion to have
first in IEEE rather than IETF.

Florin

> HENDERICKX Wim
> Sent: Tuesday, December 01, 2009 9:17 AM
> To: David Allan I; Mallette, Edwin; Luca Martini; Simon Delord
> Cc: [email-masked]; pwe3
-----------------------------------------------------------------------
> -

---

From: "Pugaczewski, Jack" <[email-masked]>
Date: Tue, 1 Dec 2009 11:00:23 -0600

Luca,

Does this mean E-Tree is not envisioned to be used without VPLS BGP Autodiscovery ?

Jack

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

Simon,

Thanks.
Luca

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.