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

From: Raymond Key <[email-masked]>
Date: Thu, 22 Jul 2010 07:28:09 +1000

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,
Raymond Key  

> Shane Amante <[email-masked]> wrote:
> 
> Raymond,
> 
> I believe there may be confusion over the characteristics of the 
> underlying P2MP PW's (which are being defined and worked on in PWE3: 
> draft-raggarwa-pwe3-p2mp-pw-encaps-01) and the characteristics of 
> signaling membership of senders and receivers within a given VPMS 
> service (which are being defined in L2VPN: 
> draft-raggarwa-l2vpn-p2mp-pw-03).
> 
> Please see below for why.
> 
> On Jul 14, 2010, at 02:20 MDT, Raymond Key wrote:
> > Quote from IETF 77 L2VPN WG minutes -
> > Shane: really would like to see review of the drafts and to see if the 
> ETREE requirements are addressed in the VPMS requirements draft.
> > 
> > I would like to share my view with the working group.
> > 
> > The focus of VPMS (Virtual Private Multicast Service) is to provide 
> point-to-multipoint connectivity.
> > 
> > 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.  If that is the case, I 
> would point you to Section 3 of:
> http://tools.ietf.org/html/draft-raggarwa-l2vpn-p2mp-pw-03#section-3
> ---snip---
>    A site could be both in the Sender Sites set and Receiver Sites set,
>    which implies that CEs within such a site could both originate and
>    receive multicast traffic. An extreme case is when the Sender Sites
>    set is the same as the Receiver Sites set, in which case all sites
>    could originate and receive multicast traffic from each other.
> [...]
>    Another way to look at a L2 MVPN is to say that an L2 MVPN is defined
>    by a set of administrative policies. Such policies determine both
>    Sender Sites set and Receiver Site set. Such policies are established
>    by L2 MVPN customers, but implemented/realized by L2 MVPN Service
>    Providers using the existing mechanisms, such as Route Targets, with
>    extensions, as necessary.
> ---snip---
> 
> 
> > A VPMS service supports single Root AC.
> 
> Technically, the P2MP PW /underlying the VPMS service/ sends data 
> traffic from a single Root AC to associated Leaf AC's.  From 
> <http://tools.ietf.org/html/draft-raggarwa-pwe3-p2mp-pw-encaps-01>:
> ---snip---
>    P2MP PWs extend the PWE3 architecture [RFC3985] to offer a P2MP
>    Telecommunications service. They follow the PWE3 architecture as
>    described in [RFC3985] with modifications as outlined in this
>    document.  One notable difference between point-to-point (P2P) PWs as
>    outlined in [RFC3985] and P2MP PWs is that the former emulate a
>    bidirectional service whereas the latter emulate a unidirectional
>    service.
> ---snip---
> 
> OTOH, the VPMS service allows one to discover whether sites are sources, 
> receivers or both (defined by L2VPN), which then drives [LDP] signaling 
> of associated P2MP PW's (defined by PWE3), depending on the type of data 
> distribution required between the different classes of sites.
> 
> 
> > All traffic from the Root AC will be forwarded to all Leaf ACs (i.e. 
> P2MP, from Root to all Leafs).
> 
> That is correct if you are referring to a single instance of a P2MP PW.  
> However, a VPMS allows one to define that a given source site may only 
> speak to a subset of all receivers in a given "VPMS VPN".
> 
> 
> > Destination address in Ethernet frame is not used in data forwarding.
> 
> Correct, as VPMS is built upon P2MP PW's which are a VPWS (Virtual 
> Private Wire Service).  If MAC learning is a requirement, then you would 
> likely be looking at a Multicast over VPLS solution.  In that case, as 
> Florin spoke about at the last IETF L2VPN WG meeting, there appears to 
> be a desire to use an existing IEEE data-plane mechanism and/or work 
> within the IEEE to define an appropriate standard in the native service 
> layer (Ethernet) so that the solution would cover not only VPLS, but all 
> associated access network technologies as well (802.1Q, Q-in-Q, PBB, 
> etc.), which are all supported access methods to a VPLS.
> 
> 
> > As an optional capability, a VPMS service may support reverse traffic 
> from a Leaf AC to the Root AC (i.e. P2P, from Leaf to Root).
> 
> Correct.
> 
> 
> > The focus of MEF E-Tree is that a Leaf can only communicate with Roots 
> but not Leafs.
> > 
> > A generic MEF E-Tree service supports multiple Root endpoints. Whether 
> a particular E-Tree service needs to support single or multiple Root 
> endpoints depends on the target application.
> 
> As I explained above, a VPMS can support discovery of either single or 
> multiple root sites, depending on configuration of RT's in PE's. 
> 
> 
> > A generic MEF E-Tree service supports all the following traffic flows:
> > - Ethernet Unicast bidirectional Root to/from Root 
> > - Etherent Unicast bidirectional Root to/from Leaf 
> > - Ethernet Broadcast/Multicast unidirectional Root to all Roots & 
> Leafs
> > - Ethernet Broadcast/Multicast unidirectional Leaf to all Roots. 
> > A particular E-Tree service may need to support all the above or only 
> a subset depending on the target application.
> 
> I would point out that P2P (unicast) PW's are bi-directional and P2MP 
> PW's are [today] defined as uni-directional.  If your goal is to request 
> support for bi-directional P2MP PW's, for example to cover the "Ethernet 
> unicast bidirectional root to/from leaf" case or other cases above, then 
> that would be something you should bring to the attention of the PWE3 
> WG, since PWE3 is the maintainer of the standards related to the 
> underlying PW's that VPLS, VPMS and VPWS services are built upon.
> 
> Thanks,
> 
> -shane
> 
> 
> > IETF's VPMS definition and MEF's E-Tree definiton are significantly 
> different. 
> > 
> > Only for special case E-Tree service where
> > - Single Root only
> > - No Unicast traffic from Root destined for a specific Leaf (or there 
> is no concern if such Unicast traffic are forwarded to all Leafs), 
> > VPMS will be able to meet the requirement. An exmaple is single-root 
> E-Tree service for content delivery application.
> > 
> > For generic E-Tree service, VPMS will not be able to meet the 
> requirement.
> > 
> > Thanks,
> > Raymond Key

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Jul 2010 16:32:11 -0600

Hi Raymond,

> 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:41:59 +0200

Hi Shane,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shane Amante
> Sent: Thursday, July 22, 2010 12:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Are E-Tree requirements addressed in the VPMS requirement
> draft?
> 
> Hi Raymond,
> 
> 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
> 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.
> 
> ... assuming that MAC-learning is a fundamental requirement of E-TREE,

[MP:] IMHO, yes it is, otherwise it'd be impossible for the root to reach each leaf in an individual P2P fashion.

> then:
> a)  VPMS, as its currently defined, is likely not an appropriate
> technology solution, since it emulates a VPWS;

[MP:] Agree. 

> b)  Multicast over VPLS is likely a more appropriate technology solution;

[MP:] For E-Tree, doesn't help for the P2P connectivity. But could help functionally as an option if MC/BC optimization is desired in E-Trees.

> *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:
> ... 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
> 

Thanks,
Manuel