Subject: Re: Are E-Tree requirements addressed in the VPMS requirement

From: Jiang Yuanlong <[email-masked]>
Date: Fri, 23 Jul 2010 19:56:03 +0800

Hi Shane and all,

With regard to VPMS, if multiple multicast groups are to be supported in the 
same VPMS, maybe using multi-VLANs (a VLAN per  logical AC) in a single P2MP 
PW also makes sense. The leaf PE could filter the VLANs on a AC port of 
which it is not a member. It scales well though the bandwidth may not be 
optimal...

For the general requirements of E-Tree, IMO there are at least 3 solutions 
possible:
1) VPLS (partial or full mesh P2P PW) + VPMS (P2MP PW),
We can use a VPLS instance to provide P2P connectivity, and another VPMS 
instance to provide P2MP connectivity.
Disadvantage: two sets of VPNs are needed; leaf-leaf traffic still needs to 
be filtered in the VPLS instance.

2) VPWS (P2P PW) + VPMS (P2MP PW)
We can use P2P PW per leaf PE to provide P2P connectivity, and a VPMS 
instance to provide P2MP connectivity.
Disadvantage: this may only work when the leaves are not so numberous.

3) VPLS (partial or full mesh P2P PW) + VPLS multicast (P2P PW) or VPLS 
multicast (P2MP LSP or P2MP PW)
We can use a single VPLS instance to provide P2P connectity, and VPLS 
multicast (P2P PW) to provide the basic P2MP connectivity.
OR we can use a single VPLS instance to provide P2P connectity, and VPLS 
multicast (P2MP LSP or P2MP PW) to optimize the P2MP connectivity.
Advantage: only a single VPN is needed for this option.
Disadvantage: Leaf-leaf traffic needs to be filtered.

If the leaf-leaf traffic can be gracefully filtered, it seems the 3rd option 
is the most scalable one:)

Therefore, I think maybe we should consider to include E-Tree in the scope 
of  L2VPN WG, and specify a detailed requirements for the general E-Tree.
Thanks.

Best regards
Yuanlong

> Date: Wed, 21 Jul 2010 16:32:11 -0600
> From: Shane Amante <[email-masked]>
> Subject: Re: Are E-Tree requirements addressed in the VPMS requirement
> draft?
> To: [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Raymond,
>
> On Jul 21, 2010, at 15:28 MDT, Raymond Key wrote:
>> Hi Shane,
>>
>> Quote from your message -
>>> VPMS provides single coverage of receiver membership.
>> I'm not sure I understand your definition of "single coverage" above. I 
>> believe you're possibly referring to the flexibility to define CE's/AC's 
>> as sender and/or receiver sites in a given VPMS. "
>>
>> Actually what I mean by "single coverage of receiver membership" is that 
>> there is no distinct differentiation for multiple multicast groups, as 
>> stated in the VPMS requirement draft
>> http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-03
>
> Thanks for the clarification.
>
> Two points:
> 1)  While a given P2MP PW will forward all traffic regardless of 
> destination MAC address, one /could/ use multiple (logical) AC's to 
> forward traffic into unique several P2MP PW's, each corresponding to its 
> own multicast group.  Admittedly, this would get cumbersome as the number 
> of multicast groups and/or CE's in a given VPMS service scales 
> significantly.
>
> 2)  OTOH, as the latter part of the paragraph in the VPMS requirements 
> you're looking at states:
> ---snip---
>   If MAC-based forwarding is preferred (i.e.,
>   multicast/unicast differentiation of MAC address), VPLS should be
>   chosen rather than VPMS.
> ---snip---
> ... assuming that MAC-learning is a fundamental requirement of E-TREE, 
> then:
> a)  VPMS, as its currently defined, is likely not an appropriate 
> technology solution, since it emulates a VPWS;
> b)  Multicast over VPLS is likely a more appropriate technology solution; 
> *however*,
> c)  As Florin stated in his presentation at the last IETF, there needs to 
> be a IEEE solution for E-TREE to limit flooding scope /within/ the 
> "802.1ad Bridge Module" function of a VPLS PE of I-Component of a PBB VPLS 
> PE:
> http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-bridge-interop-05#section-3
> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-vpls-pe-model-02#section-3
> ... since, there is a likelihood (IMO, certainty) that various types of 
> CE's (root and/or leaf) are going to be attached in: a) Native Ethernet 
> networks that have nothing to do with VPLS; and/or, b) directly to a VPLS 
> PE -- where in the latter case, if you notice in the diagrams, Ethernet 
> frames are switched inside the "Bridge Module" between locally connected 
> AC's/ports on a VPLS PE in accordance with IEEE's specifications of 
> bridging/switching.
>
> -shane
>

---

From: <[email-masked]>
Date: Fri, 23 Jul 2010 14:56:39 +0200

Dear All,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jiang Yuanlong
> Sent: Friday, July 23, 2010 1:56 PM
> To: Shane Amante; [email-masked]
> Cc: [email-masked]

[MP:] I'd like to second Yuanlong. 
I think, draft-key-l2vpn-vpls-etree-reqt provides a well defined set of requirements for this purpose.

Thanks,
Manuel

---

From: Shane Amante <[email-masked]>
Date: Sun, 25 Jul 2010 13:46:00 +0200

Manuel, Yuanlong,

> I think, draft-key-l2vpn-vpls-etree-reqt provides a well defined set of requirements for this purpose.

The part I'm having difficulty understanding is what adoption of the requirements draft would help with?  As noted above, in point (3) under "Disadvantage" is, technically, what can L2VPN do to solve the filtering of leaf to leaf traffic?  In my recollection of discussions at the last IETF:
- There seemed to be general consensus that using the Control Word as a filtering method, (i.e.: for leaf-2-leaf traffic), was not agreed to.  Furthermore, the PWE3 WG owns the definition of the Control Word and they would have to agree to it's use for filtering /before/ L2VPN could take on any work related to E-TREE, particularly if there was a contingency on using CW filtering as a solution.
- As Florin pointed out, it seems to make sense to look for a filtering solution in the MAC-layer since that covers all of the access network types currently supported by VPLS, in which case L2VPN would need to see the IEEE produce a solution, before L2VPN could take on E-TREE work.
- All of the suggestions myself, and others, have put forth during and subsequent to the last IETF have been rejected by E-TREE proponents without a compromise solution proposal that doesn't use the CW for filtering.

So, in summary, we should not only have a good idea of the reqmt's, but also of the _feasible_ solutions that are available to us to solve for those reqmt's.  It would be unwise for the WG to take on an open-ended work item, since L2VPN (or, any WG for the most part) isn't meant to be perpetually active.  :-)  So, unless someone wants to propose a set of _feasible_ solutions (that haven't been previously rejected), available in the near-term, I'm not sure it makes sense for the L2VPN WG to take on E-TREE, yet.

Thanks,

-shane

---

From: Simon Delord <[email-masked]>
Date: Mon, 26 Jul 2010 11:06:44 +1000

Hi there,
Taken from Shane's previous email:
"- Furthermore, the PWE3 WG owns the definition of the Control Word and they
would have to agree to it's use for filtering /before/ L2VPN could take on
any work related to E-TREE, particularly if there was a contingency on using
CW filtering as a solution."

The minutes in the PWE3 WG for IETF77 show that during presentation of
draft-delord-pwe3-cw-bit-etree-02.txt
"Matthew: would like to see what L2VPN does first then deal with solutions"
Does anyone have an idea on how to make progress on this situation ?

Cheers,

Simon

2010/7/25 Shane Amante <[email-masked]>

> The part I'm having difficulty understanding is what adoption of the
> requirements draft would help with?  As noted above, in point (3) under
> "Disadvantage" is, technically, what can L2VPN do to solve the filtering of
> leaf to leaf traffic?  In my recollection of discussions at the last IETF:
> - There seemed to be general consensus that using the Control Word as a
> filtering method, (i.e.: for leaf-2-leaf traffic), was not agreed to.
>  Furthermore, the PWE3 WG owns the definition of the Control Word and they
> would have to agree to it's use for filtering /before/ L2VPN could take on
> any work related to E-TREE, particularly if there was a contingency on using
> CW filtering as a solution.
> - As Florin pointed out, it seems to make sense to look for a filtering
> solution in the MAC-layer since that covers all of the access network types
> currently supported by VPLS, in which case L2VPN would need to see the IEEE
> produce a solution, before L2VPN could take on E-TREE work.
> - All of the suggestions myself, and others, have put forth during and
> subsequent to the last IETF have been rejected by E-TREE proponents without
> a compromise solution proposal that doesn't use the CW for filtering.
>
> So, in summary, we should not only have a good idea of the reqmt's, but
> also of the _feasible_ solutions that are available to us to solve for those
> reqmt's.  It would be unwise for the WG to take on an open-ended work item,
> since L2VPN (or, any WG for the most part) isn't meant to be perpetually
> active.  :-)  So, unless someone wants to propose a set of _feasible_
> solutions (that haven't been previously rejected), available in the
> near-term, I'm not sure it makes sense for the L2VPN WG to take on E-TREE,
> yet.
>
> Thanks,
>
> -shane
>
>
> > Thanks,
> > Manuel
> >
> >>
> >> Best regards
> >> Yuanlong
> >>

---

From: Shane Amante <[email-masked]>
Date: Mon, 26 Jul 2010 07:11:56 +0200

Simon,

On Jul 26, 2010, at 03:06 GMT+02:00, Simon Delord wrote:
> "- Furthermore, the PWE3 WG owns the definition of the Control Word and they would have to agree to it's use for filtering /before/ L2VPN could take on any work related to E-TREE, particularly if there was a contingency on using CW filtering as a solution."
>  
> The minutes in the PWE3 WG for IETF77 show that during presentation of draft-delord-pwe3-cw-bit-etree-02.txt

It seems like the PWE3 & L2VPN co-chairs will have to get together with our co-AD's and discuss how to resolve this situation.  I'll report back to the list after we've had a proper chance to discuss.

-shane

---

From: <[email-masked]>
Date: Mon, 26 Jul 2010 10:26:21 +0200

Shane,

Thanks. Unfortunately, due to my travel to Maastricht, I couldn't respond before the L2VPN session.
Please see inline below.

> Shane Amante
> Sent: Sunday, July 25, 2010 1:46 PM
> To: Paul, Manuel
> Cc: [email-masked]; [email-masked]
> >> With regard to VPMS, if multiple multicast groups are to be supported
> in
> >> the
> >> Disadvantage: two sets of VPNs are needed; leaf-leaf traffic still
> needs
> >> to
> "Disadvantage" is, technically, what can L2VPN do to solve the filtering
> of leaf to leaf traffic?  In my recollection of discussions at the last
> IETF:
> any work related to E-TREE, particularly if there was a contingency on
> using CW filtering as a solution.
> solution in the MAC-layer since that covers all of the access network
> types currently supported by VPLS, in which case L2VPN would need to see
> the IEEE produce a solution, before L2VPN could take on E-TREE work.
> subsequent to the last IETF have been rejected by E-TREE proponents
> without a compromise solution proposal that doesn't use the CW for
> filtering.
> 
> also of the _feasible_ solutions that are available to us to solve for
> those reqmt's.  It would be unwise for the WG to take on an open-ended
> work item, since L2VPN (or, any WG for the most part) isn't meant to be
> perpetually active.  :-)  So, unless someone wants to propose a set of
> _feasible_ solutions (that haven't been previously rejected), available in
> the near-term, I'm not sure it makes sense for the L2VPN WG to take on E-
> TREE, yet.

[MP:] IMHO the requirements draft helps to define/facilitate the mandate (coming from L2VPN WG) if and how to work/progress on the solutions for E-Tree (as a layer 2 VPN service defined by MEF). But MEF specs define the service requirements and obviously haven't helped much when taling about underlying technologies to implement so far.

To my best recollection, at the last meeting solutions were proposed and discussed in PWE3, but were put on hold, requesting a clearer use case from L2VPN first. As far as I remember, it was found not appropriate to prioritize or focus on any specific proposal at the time of the last meeting but none of the proposals were actually technically rejected.  

In L2VPN, we then discussed if the requirements are defined clear enough to progress E-Tree solutions vs. the requirements already defined for VPMS. 
So, it seems, that's where the token now still is (still the case after the WG discussion this morning). 
Of course, we want to overcome this sort of chicken & egg, which would be the hope for an outcome of discussion with PWE3.
  
> -shane

Regards,
Manuel

---

From: Jiang Yuanlong <[email-masked]>
Date: Mon, 26 Jul 2010 14:53:09 +0200

Shane and all,

With regard to E-Tree in VPLS, IMO, actually there are already 3 proposals up to now:
1) the Control word mechanism;

2) the VLAN based mechanism I had presented at IETF 77, which does not use the control word, and can be compatible with IEEE solutions;
BTW, an updated version is available by the following link: http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-01

3) the dual-PW mechanism discussed in the mailinglist, although a draft of detailed specification is still in need.

Although no concensus is achieved yet, I think it is clearly shown that this requirement can be fulfiled by these or other more potential solutions.
But first of all, a well defined draft of E-Tree requirements is the basis for any solution's developments. 

 Regards
Yuanlong

----- Original Message ----- 
From: "Shane Amante" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, July 25, 2010 1:46 PM
Subject: Re: Are E-Tree requirements addressed in the VPMS requirement

Manuel, Yuanlong,

Thanks,

-shane