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

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]>

> Manuel, Yuanlong,
>
> On Jul 23, 2010, at 06:56 MDT, <[email-masked]> <
> [email-masked]> wrote:
> >> -----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]
> >> Subject: Re: Are E-Tree requirements addressed in the VPMS requirement
> >>
> >> 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.
> >
> > [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.
>
> 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
> >>
> >>> 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: 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

> On Jul 23, 2010, at 06:56 MDT, <[email-masked]> <[email-masked]> wrote:
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >> Jiang Yuanlong
> >> For the general requirements of E-Tree, IMO there are at least 3 solutions
> >> possible:
> >> 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.
> >
> > 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
> 
> 
> > Thanks,
> > Manuel
> >
> >>
> >> Best regards
> >> Yuanlong
> >>
> >>>> I'm not sure I understand your definition of "single coverage" above. I
> >>> forward traffic into unique several P2MP PW's, each corresponding to its
> >>> frames are switched inside the "Bridge Module" between locally connected