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

From: Raymond Key <[email-masked]>
Date: Wed, 14 Jul 2010 18:20:21 +1000

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. A VPMS service supports single Root AC. All traffic from the Root AC will be forwarded to all Leaf ACs (i.e. P2MP, from Root to all Leafs). Destination address in Ethernet frame is not used in data forwarding. 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).

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.

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.

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: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Thu, 15 Jul 2010 06:31:09 -0400

Agreed..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Raymond Key
Sent: Wednesday, July 14, 2010 4:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Are E-Tree requirements addressed in the VPMS requirement
draft?

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.

The focus of VPMS (Virtual Private Multicast Service) is to provide
point-to-multipoint connectivity.

VPMS provides single coverage of receiver membership. A VPMS service
supports single Root AC. All traffic from the Root AC will be forwarded
to all Leaf ACs (i.e. P2MP, from Root to all Leafs). Destination address
in Ethernet frame is not used in data forwarding. 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).

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.

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.

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: Tue, 20 Jul 2010 21:37:09 -0600

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

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

---

From: <[email-masked]>
Date: Wed, 21 Jul 2010 11:36:44 +0200

Hi Shane,

Please let me recap the drafts so far written around P2MP PW, just to make sure that everyone has a common view.

2 requirements drafts
WG L2VPN http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-03 defines the VPMS requirements
WG PWE3  http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02 defines the P2MP PW requirements, the network enabler which should be used to provide a VPMS, and also to support unknown, broadcast, muylticast trafic in VPLS

1 data plane solution draft
WG PWE3 http://tools.ietf.org/html/draft-raggarwa-pwe3-p2mp-pw-encaps-01 defines the encapsulation of P2MP PW

2/3 signaling solution drafts
WG L2VPN http://tools.ietf.org/html/draft-raggarwa-l2vpn-p2mp-pw-03 describes the BGP based solution to offer a VPMS (VPLS multicast was already defined in http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06)  
WG PWE3  http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01 describes the LDP based solution to create a P2MP PW (to be used  for both services, VPMS or VPLS when using LDP as signaling)
WG PWE3 http://tools.ietf.org/html/draft-jounay-pwe3-leaf-initiated-p2mp-pw-02 describes the LDP based solution to create a P2MP MS-PW, MLDP like signaling (to be used to both services, VPMS or VPLS when using LDP as signaling) 

"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"."

The requirement drafts does not allow what you propose. That would imply the root PE to forward the traffic based on a L2 info, what is out of scope of VPMS (AC<=>P2MP PW, no MAC learning, forwarding, etc). 
Extracted from the VPMS requirements:
"A single VPMS instance provides a unique point-to-multipoint L2VPN service. 
In a VPMS, P2MP tree-shaped reachability is given FROM A SINGLE ROOT AC to several leaf ACs.  This will be named a "P2MP connection" in this VPMS framework. 
In a VPMS, an AC attached to a VPMS MUST be configured as "root" (sender) or "leaf" (receiver) not both.  Any AC is associated with the role of either sending side (Tx) or receiving side (Rx) from the view of the CE.  These will be named the root (sender) AC and leaf (receiver) AC respectively. Unless reverse traffic is optionally supported, a root AC does not transmit traffic back to a CE at upstream side, likewise a leaf AC does not receive traffic from a CE at downstream side" 

A VPMS is already defined to be optionnally bidirectionnal, a leaf CE can send traffic back to the root PE, but that does not mean that the leaf CE is becoming a root (MEF definition). The return path has also been defined in the P2MP PW requirements draft (Note that this will be especially required for VPMS, since in VPLS unicast messages will use P2P PW).

To sum up, I agree with Raymond to say that even thoug VPMS can address E-Tree requirements in a specific case, we can not say it covers the generic E-Tree definition (multi-root, unicast messages from root to leaf).
Indeed VPMS could address an E-Tree service with a single root (root <=> leafs ok for all kind of traffic).
In that scenario the main drawback is of course the unicast traffic sent from the root to leafs. So once again that will depend of the application (e.g. ok for content delivery).

Cheers,
Fred

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shane Amante
Envoyé : mercredi 21 juillet 2010 05:37
À : [email-masked]
Cc : [email-masked]
Objet : Re: Are E-Tree requirements addressed in the VPMS requirement draft?

Attention, votre correspondant continue de vous ecrire a votre ancienne adresse en @francetelecom.com.
Veuillez lui demander de mettre a jour son carnet d'adresses avec votre nouvelle adresse en @orange-ftgroup.com.
Dans quelques semaines, nous refuserons definitivement les messages vers ce domaine.
En savoir plus:
<A HREF="http://pratique.itn.ftgroup/FR/catalogue/messagerie/boitesdemessagerie/Pages/fermeturedomainesftorange.aspx">http://pratique.itn.ftgroup/FR/catalogue/messagerie/boitesdemessagerie/Pages/fermeturedomainesftorange.aspx</A>
-------------------------------------------------------------------------------------------------------------------------

Raymond,

---snip---

Correct.

Thanks,

-shane

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

---

From: Yong Lucy <[email-masked]>
Date: Wed, 21 Jul 2010 10:14:54 -0500

Hi Shane,

I agree with Raymond analysis. There is a BIG difference between VPMS and
E-Tree. VPMS PE forwards the packets from a sender site over pre-build P2MP
without checking MAC, i.e. it does not support selective forwarding. E-Tree
requires forwarding the packets based on MAC address. Example, a root AC can
forward one packet to leaf1 but not leaf2, and forward another packet to
leaf2 but not lead1. 

Regards,
Lucy 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shane Amante
> Sent: Tuesday, July 20, 2010 10:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Are E-Tree requirements addressed in the VPMS requirement
> draft?
> 
> 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).
> 
> 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:
> 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---
> 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.
> 
> 
> 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".
> 
> 
> 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.
> 
> 
> 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.
> 
> 
> 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
> 
> 
> > VPMS will be able to meet the requirement. An exmaple is single-root E-
> Tree service for content delivery application.
> >

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Jul 2010 09:23:04 -0600

Hi Fred,

On Jul 21, 2010, at 03:36 MDT, <[email-masked]> <[email-masked]> wrote:
[--snip--]
> In a VPMS, an AC attached to a VPMS MUST be configured as "root" (sender) or "leaf" (receiver) not both.  Any AC is associated with the role of either sending side (Tx) or receiving side (Rx) from…

First, I think you may not have understood my tersely word reply above.  (Sorry about that).  What I meant is the following.  In a given VPMS "VPN", let's say there are 10 hosts/CE's.  In my understanding, there is no requirement that a given "source host" in that VPMS must speak to all 9 downstream/receiver sites.  Instead, with VPMS Auto-Discovery, one could configure the network such that source host A is only allowed to discover, say, 5 receivers.  Likewise, source host B in the same VPMS "VPN" may discover 7 downstream/receiver sites.  However, this is ultimately a function of how an SP configures the RT's and administrative policies on their PE's and associated AC's.  

Second, IMHO, the above appears to be describing the properties of the underlying P2MP PW -- especially, the last paragraph you quote.  Again, the Auto Discovery aspects, (that L2VPN WG is responsible for developing), are largely a function of administrative policy *and* the underlying properties of the P2MP PW transport (which PWE3 is developing).  IOW, L2VPN can't mandate or change the properties of the P2MP PW.  With respect to the language you quote above from draft-ietf-l2vpn-vpms-frmwk-requirements-03, IMO it would likely be best to discuss amongst the co-authors and the L2VPN WG (since the above is a WG draft), which of the following is most palatable:
a)  Clarify that the cited text is one example (common?) application; or,
b)  Strike it entirely; or,
c)  At a minimum, put a reference to the P2MP PW reqmt's and/or solutions drafts in PWE3, since they are a more definitive reference.

-shane

---

From: <[email-masked]>
Date: Wed, 21 Jul 2010 21:06:27 +0200

Shane, 

Thanks for your clarification
The VPMS (VPN id) does not assume so far more than one root PE, except for the dual-homing case for redundancy (section 6.4.1).
I agree with you that a leaf AC could receive traffic from different roots (based on RT selection), but how to manage the return path if the leaf PE is not assumed to look at any L2 info.
That is why "Regarding end-to-end traffic topology between the ACs, a single VPMS instance (i.e., one VPN) corresponds to a single P2MP connection".

Regards,
Fred

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shane Amante
Envoyé : mercredi 21 juillet 2010 17:23
À : JOUNAY Frederic RD-RESA-LAN
Cc : [email-masked]
Objet : Re: Are E-Tree requirements addressed in the VPMS requirement draft?

En savoir plus: http://pratique.itn.ftgroup/FR/catalogue/messagerie/boitesdemessagerie/Pages/fermeturedomainesftorange.aspx

Hi Fred,

-shane

> De : [email-masked] [mailto:[email-masked]] De la part 
> de Shane Amante Envoyé : mercredi 21 juillet 2010 05:37 À : 
> [email-masked] Cc : [email-masked] Objet : Re: Are E-Tree 
> requirements addressed in the VPMS requirement draft?
> 
> <A 
> HREF="http://pratique.itn.ftgroup/FR/catalogue/messagerie/boitesdemess
> agerie/Pages/fermeturedomainesftorange.aspx">http://pratique.itn.ftgro
> up/FR/catalogue/messagerie/boitesdemessagerie/Pages/fermeturedomainesf
> torange.aspx</A>
> ----------------------------------------------------------------------
> ---------------------------------------------------
> 
> 
> 
> Raymond,
>

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Jul 2010 15:54:18 -0600

Hi Fred,

> The VPMS (VPN id) does not assume so far more than one root PE, except for the dual-homing case for redundancy (section 6.4.1).

I'm not sure to which draft(s) you are referring, so I'm unable to respond to the above.

> That is why "Regarding end-to-end traffic topology between the ACs, a single VPMS instance (i.e., one VPN) corresponds to a single P2MP connection".

According to:
http://tools.ietf.org/html/draft-raggarwa-pwe3-p2mp-pw-encaps-01#section-3
---snip---
   A particular leaf CE may receive traffic from multiple sender CEs.
   Traffic from different sender CEs is received by a leaf PE over
   unique P2MP PWs. The leaf PE must use unique ACs to send traffic
   received over unique P2MP PW, to the same leaf CE or different leaf
   CEs.
---snip---

The way I interpret the above is, for example, different VLAN ID's on the physical AC from a leaf PE to leaf CE are used so that the leaf CE can know the identity of a particular root CE (by looking at the recv'd VLAN ID).  Admittedly, the aforementioned draft (currently) does not discuss procedures for how a P2P PW from each AC can/is built from the leaf PE back to the root CE for return traffic, although as you noted in an earlier e-mail the authors of these drafts appear to want to (optionally) allow that.  I would encourage the co-authors of draft-raggarwa-pwe3-p2mp-pw-encaps to speak up to elaborate on how they intend to accomplish that.

-shane

---

From: <[email-masked]>
Date: Thu, 22 Jul 2010 09:15:31 +0200

Hi Shane,

The draft I'm referring is the VPMS requirements draft

If the leaf CE gets as many ACs as P2MP PW, i.e. 1 per root, you are free to gather them in a common VPN or seperate.

Regards,
Fred 

-----Message d'origine-----
De : Shane Amante [mailto:[email-masked]] 
Envoyé : mercredi 21 juillet 2010 23:54
À : JOUNAY Frederic RD-RESA-LAN
Cc : [email-masked]
Objet : Re: Are E-Tree requirements addressed in the VPMS requirement draft?

Hi Fred,

According to:
---snip---

-shane

> de Shane Amante Envoyé : mercredi 21 juillet 2010 17:23 À : JOUNAY 
> Frederic RD-RESA-LAN Cc : [email-masked] Objet : Re: Are E-Tree 
> http://pratique.itn.ftgroup/FR/catalogue/messagerie/boitesdemessagerie
> /Pages/fermeturedomainesftorange.aspx
>> De : [email-masked] [mailto:[email-masked]] De la 
>> part de Shane Amante Envoyé : mercredi 21 juillet 2010 05:37 À :
>>  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---
>> 
>> 
>>> - 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.
>>>

---

From: "Yuji KAMITE" <[email-masked]>
Date: Mon, 26 Jul 2010 15:53:56 +0900

Hi Shane, Fred, and all,

Regarding the suggestion about VPMS requirement below from Shane,
let me summarize the points please.   
 (I changed the thread title since this is about VPMS, not E-Tree)

> IMO it would likely be best to discuss amongst the co-authors and the
L2VPN WG (since the above is a WG draft), which of the following is most
palatable:
> c)  At a minimum, put a reference to the P2MP PW reqmt's and/or solutions
drafts in PWE3, since they are a more definitive reference.

We can come up with two multi-source scenarios in VPMS.

(1) Multi-source & Single-coverage of receivers
     - For example, there are two sources, host A and host B inside a given VPMS　where there are 10 hosts/CEs.  Host A and B are attached to different PEs.  Traffic from both hosts reach the same group of receivers.  This is useful for different stream channels in the common receivers.  Moreover, this can also be applied to redundancy of source.  In redundancy case host A and B can be physically at the same box as a single CE  (dual-homed source).   To realize this there might be two redundant p2mp connections inside this VPMS particularly if source CE is dual-homed.

(2) Multi-source & Multi-coverage of receivers
     - This means multiple p2mp-connections inside a given VPMS.  It allows different receiver coverage from separate roots in a given "VPN".   For example, there are two separate p2mp connections; from host A to 4 receivers, and from host B to its 6 receivers.  In addition, there might be overlapped receivers (CEs) that can get traffic from host A and host B.  

In the current VPMS requirement draft:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-03
It has a statement about (1).  Section 6.4.1 shows dual-homed redundancy scenario.  It also includes a brief statement in the last paragraph, which is about multi-source scenario as an extended interpretation of this.   However, at this moment the requirement for the case (2) has not been explicitly written in the document.

In the current VPMS solution draft:
http://tools.ietf.org/html/draft-raggarwa-l2vpn-p2mp-pw-03
It introduces discovery mechanism using RT in BGP in Section 5, hence it is possible　to support the scenario of (2).  (Inside a same VPN, you can configure different RTs with import/export policy to create multiple p2mp topology.)  This will also support the scenario of (1), mentioned in Section 5.1.    

Now we have a qusetion about the requirement side: Do we have a requirement / application scneario about (2)?  
-- IMHO, if we assume different streams/applications is running over the same VPN customer, apparently it makes sense as one of typical use cases.
WG folks, any ideas or feedback?

Best regards,
Yuji

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, July 22, 2010 4:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Are E-Tree requirements addressed in the VPMS 
> requirement draft?
> 
> Hi Shane,
> 
> If the leaf CE gets as many ACs as P2MP PW, i.e. 1 per root, 
> you are free to gather them in a common VPN or seperate.
> 
> Regards,
> Fred 
>  
> 
> De : Shane Amante [mailto:[email-masked]] Envoyé : 
> mercredi 21 juillet 2010 23:54 À : JOUNAY Frederic 
> RD-RESA-LAN Cc : [email-masked] Objet : Re: Are E-Tree 
> On Jul 21, 2010, at 13:06 MDT, 
> <[email-masked]> 
> <[email-masked]> wrote:
> > Shane,
> > 
> > The VPMS (VPN id) does not assume so far more than one root 
> PE, except for the dual-homing case for redundancy (section 6.4.1).
> 
> > I agree with you that a leaf AC could receive traffic from 
> different roots (based on RT selection), but how to manage 
> the return path if the leaf PE is not assumed to look at any L2 info.
> > That is why "Regarding end-to-end traffic topology between 
> the ACs, a single VPMS instance (i.e., one VPN) corresponds 
> to a single P2MP connection".
> 
> According to:
> The way I interpret the above is, for example, different VLAN 
> ID's on the physical AC from a leaf PE to leaf CE are used so 
> that the leaf CE can know the identity of a particular root 
> CE (by looking at the recv'd VLAN ID).  Admittedly, the 
> aforementioned draft (currently) does not discuss procedures 
> for how a P2P PW from each AC can/is built from the leaf PE 
> back to the root CE for return traffic, although as you noted 
> in an earlier e-mail the authors of these drafts appear to 
> want to (optionally) allow that.  I would encourage the 
> co-authors of draft-raggarwa-pwe3-p2mp-pw-encaps to speak up 
> to elaborate on how they intend to accomplish that.
> 
> -shane
> 
> 
> 
> > Regards,
> > Fred
> > 
> > 
> > Attention, votre correspondant continue de vous ecrire a 
> votre ancienne adresse en @francetelecom.com.
> > Veuillez lui demander de mettre a jour son carnet 
> d'adresses avec votre nouvelle adresse en @orange-ftgroup.com.
> > On Jul 21, 2010, at 03:36 MDT, 
> <[email-masked]> 
> <[email-masked]> wrote:
> > [--snip--]
> >> "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"."
> >> 
> >> The requirement drafts does not allow what you propose. 
> That would imply the root PE to forward the traffic based on 
> a L2 info, what is out of scope of VPMS (AC<=>P2MP PW, no MAC 
> learning, forwarding, etc). 
> >> In a VPMS, P2MP tree-shaped reachability is given FROM A 
> SINGLE ROOT AC to several leaf ACs.  This will be named a 
> "P2MP connection" in this VPMS framework. 
> >> In a VPMS, an AC attached to a VPMS MUST be configured as 
> "root" (sender) or "leaf" (receiver) not both.  Any AC is 
> associated with the role of either sending side (Tx) or 
> receiving side (Rx) from the view of the CE.  These will be 
> named the root (sender) AC and leaf (receiver) AC 
> respectively. Unless reverse traffic is optionally supported, 
> a root AC does not transmit traffic back to a CE at upstream 
> side, likewise a leaf AC does not receive traffic from a CE 
> at downstream side" 
> > 
> > First, I think you may not have understood my tersely word 
> reply above.  (Sorry about that).  What I meant is the 
> following.  In a given VPMS "VPN", let's say there are 10 
> hosts/CE's.  In my understanding, there is no requirement 
> that a given "source host" in that VPMS must speak to all 9 
> downstream/receiver sites.  Instead, with VPMS 
> Auto-Discovery, one could configure the network such that 
> source host A is only allowed to discover, say, 5 receivers.  
> Likewise, source host B in the same VPMS "VPN" may discover 7 
> downstream/receiver sites.  However, this is ultimately a 
> function of how an SP configures the RT's and administrative 
> policies on their PE's and associated AC's.  
> > 
> > Second, IMHO, the above appears to be describing the 
> properties of the underlying P2MP PW -- especially, the last 
> paragraph you quote.  Again, the Auto Discovery aspects, 
> (that L2VPN WG is responsible for developing), are largely a 
> function of administrative policy *and* the underlying 
> properties of the P2MP PW transport (which PWE3 is 
> developing).  IOW, L2VPN can't mandate or change the 
> properties of the P2MP PW.  With respect to the language you 
> quote above from draft-ietf-l2vpn-vpms-frmwk-requirements-03, 
> IMO it would likely be best to discuss amongst the co-authors 
> and the L2VPN WG (since the above is a WG draft), which of 
> the following is most palatable:
> > a)  Clarify that the cited text is one example (common?) 
> application; 
> > or,
> > c)  At a minimum, put a reference to the P2MP PW reqmt's 
> and/or solutions drafts in PWE3, since they are a more 
> definitive reference.
> > 
> > -shane
> > 
> > 
> >> A VPMS is already defined to be optionnally 
> bidirectionnal, a leaf CE can send traffic back to the root 
> PE, but that does not mean that the leaf CE is becoming a 
> root (MEF definition). The return path has also been defined 
> in the P2MP PW requirements draft (Note that this will be 
> especially required for VPMS, since in VPLS unicast messages 
> will use P2P PW).
> >> 
> >> To sum up, I agree with Raymond to say that even thoug 
> VPMS can address E-Tree requirements in a specific case, we 
> can not say it covers the generic E-Tree definition 
> (multi-root, unicast messages from root to leaf).
> >> Indeed VPMS could address an E-Tree service with a single 
> root (root <=> leafs ok for all kind of traffic).
> >> In that scenario the main drawback is of course the 
> unicast traffic sent from the root to leafs. So once again 
> that will depend of the application (e.g. ok for content delivery).
> >> 
> >> Cheers,
> >> Fred
> >> 
> >> 
> >> Attention, votre correspondant continue de vous ecrire a 
> votre ancienne adresse en @francetelecom.com.
> >> Veuillez lui demander de mettre a jour son carnet 
> d'adresses avec votre nouvelle adresse en @orange-ftgroup.com.
> >> 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).
> >> 
> >>> Shane: really would like to see review of the drafts and 
> to see if the ETREE requirements are addressed in the VPMS 
> requirements draft.
> >>> 
> >>> The focus of VPMS (Virtual Private Multicast Service) is 
> to provide point-to-multipoint connectivity.
> >>> 
> >> 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:
> >> 
> >> Technically, the P2MP PW /underlying the VPMS service/ 
> sends data traffic from a single Root AC to associated Leaf 
> AC's.  From 
> >> 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".
> >> 
> >> 
> >> 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.
> >> 
> >> 
> >>> 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 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
> >> 
> >> 
> >>> 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.
> >>>