Re: The status of the approaches to the E-Tree solution?

["Rogers, Josh" <[e-mail]>]

Agreed.



On 4/26/12 10:30 AM, "Lucy yong" <[e-mail]> wrote:

>Josh,
>
>Dual VLAN draft describes option B only, which aligns with IEEE spec..
>Not sure which doc. talks about option A and suggest not discussing
>option A on email anymore.
>
>Regards,
>Lucy
>
>-----Original Message-----
>From: Rogers, Josh [mailto:[e-mail]]
>Sent: Wednesday, April 25, 2012 6:23 PM
>To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn;
>[e-mail]
>Subject: Re: The status of the approaches to the E-Tree solution?
>
>[[LY]]  This is not my understanding. Here we talk about incoming frame
>already has c-tag and s-tag, which is not UNI case. In addition, it seems
>that Daniel say that only option A works.
>
>That¹s funny, I thought someone said that only option B would work.  I
>think technically either is possible, but I am unclear which the 2VLAN
>draft would advise (or if it even does)
>
>
>-Josh
>
>
>
>On 4/25/12 5:22 PM, "Lucy yong" <[e-mail]> wrote:
>
>>Hi Josh,
>>
>>Please see inline.
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>Rogers, Josh
>>Sent: Wednesday, April 25, 2012 4:42 PM
>>To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; [e-mail]
>>Subject: Re: The status of the approaches to the E-Tree solution?
>>
>>Dave/Daniel/Lucy/Others Debating how many tags necessary when S-Tag
>>preservation is desired,
>>
>>
>>I think you all may have gone off on a tangent here.  The original
>>discussion was about how to deal with the situation where the S-Tag is
>>preserved at a handoff (either an ENNI, or Service Multiplexed UNI)
>>[[LY]] in MEF, S-Tag applies to ENNI only, not UNI. An UNI can support
>>multiplexed services, i.e. terminate many EVCs. In this case, each EVC
>>associates with one or multiple c-tags. EVC has a service attribute for
>>listing associated c-tags.
>>
>>I believe there were two suggestions, one was that you push on a 'ETREE'
>>tag (one of two values, for either a frame sourced from a root AC or
>>another for a frame from a leaf AC), and the second solution was to
>>'map'.
>>[[LY]]  This is not my understanding. Here we talk about incoming frame
>>already has c-tag and s-tag, which is not UNI case. In addition, it seems
>>that Daniel say that only option A works.
>>
>>
>>Imagine the following topology:
>>
>>+-----+  +-----+  +-----+  +-----+
>>| CE1 |--| PE1 |--| PE2 |--| CE2 |
>>+-----+  +-----+  +-----+  +-----+
>>            |        |
>>+-----+  +-----+  +-----+  +-----+
>>| CE3 |--| PE3 |--| PE4 |--| CE4 |
>>+-----+  +-----+  +-----+  +-----+
>>
>>Where:
>>
>>Site  Type  VLAN
>>CE1   Root  X
>>CE2   Leaf  2
>>CE3   Leaf  3
>>CE4   Leaf  3
>>
>>
>>So, there are a lot of SP's who are keen on the way many services can be
>>handed to a customer on a single UNI, but coordinating a single VLAN per
>>service, with the customer (MEF used to call this EVPL when it was many
>>point to point services terminating on a single UNI).  So, imagine that
>>we
>>have two ETREE instances, and an internet service all terminating on a
>>single UNI connecting to CE1.  We have negotiated VLAN ID's with the
>>customer, and they are expecting to reach CE2 using VLAN 2, CE3 and CE4
>>using VLAN 3, and Internet service on VLAN 10.  As a frame from CE1 comes
>>into PE1 destined for CE2 (so the customer has tagged it with VID 2),
>>using the 2VLAN method, since this is coming from a root site, do we
>>
>>a) place the Root S-Tag in front of VID 2, then ship it across, and pop
>>off the ETREE S-Tag (some SP's wish to Pop the original customer tag VID
>>2
>>as well)
>>
>>-or-
>>
>>b) swap VID2 for the ETREE Root S-Tag, send the frame to PE2 where it
>>will
>>remove the S-Tag (and either push VID2 back on, or leave it off depending
>>on SP preference)
>>
>>The reference to 'double tagging' was talking about solution A above,
>>since there is both the service VID that is coordinated with the
>>customer,
>>as well as the Etree VID which designates the source (root or leaf)
>>[[LY]] Since dual VLAN solution tries to inline with IEEE solution, if
>>this is the use case, we suggests to go with option B, not A. So please
>>don't discuss option A more.
>>
>>Regards,
>>Lucy
>>
>>
>>Hope that clears more than it confuses,
>>Josh
>>
>>
>>
>>On 4/25/12 4:22 PM, "Fedyk, Donald (Don)"
>><[e-mail]> wrote:
>>
>>>Hi Dave
>>>
>>>Yes the only point I would add is Dual VLAN means One VID for Root and
>>>one VID for Leaf. Not two TAGs at a time on the frame but two allocated
>>>for the service.
>>>
>>>The confusing part is no doubt that Dual PWE/Dual VLAN comparison talks
>>>about Encapsulation Overhead as a VLAN Tag. While that is true in a PWE
>>>sense it is still a single VLAN Tag at a time in a Ethernet E-tree
>>>sense.
>>> The compelling driver for Dual VLAN is having a Etree service that
>>>works
>>>in many environments and the DUAL VLAN (really dual VLAN interface on a
>>>VSI) uses the same mechanism (one VID for root and one VID for Leaf at a
>>>time) as specified in the IEEE. In a pure Ethernet bridging world the
>>>VLAN TAGs for Etree are not typically an overhead since translation is
>>>used.
>>>
>>>Don
>>>
>>>-----Original Message-----
>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of
>>>David Allan I
>>>Sent: Wednesday, April 25, 2012 5:05 PM
>>>To: Daniel Cohn; [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>OK I feel like I am digressing a fair distance from the actual
>>>problem.... But here goes:
>>>
>>>So the scenarios center around "how ETREE do you want to be?"....
>>>
>>>If the ACs are root/leaf, then if they are P2P (single ethernet end
>>>station attached to each AC) this is moot. ETREE semantics are enforced
>>>by the 2VID domain in the center of the example. If you assumed nodes
>>>A&B
>>>in the example were L2VPN PEs, the tagging and the PW tag imposition all
>>>happened at the same point in the network.
>>>
>>>If they are not simple P2P all the way to end systems and the objective
>>>is to avoid bridging between leaf "sites" but allowing intra-leaf-site
>>>connectivity then the leaves can be LANs but the root is not, such that
>>>I
>>>cannot bridge through the root. But all hosts at a given leaf site can
>>>see each other. So root Ethernet end systems are directly attached or
>>>two
>>>VIDs are used in the root site.
>>>
>>>If the objective is that there are multiple ethernet attached end
>>>stations at both the leaf and root sites, and the objective is to
>>>enforce
>>>L2 isolation everywhere then I need two VIDs extended to the end system
>>>attachement point in the local LANs by whatever means....
>>>
>>>And I do not see adding VLANs in any particular spot, simply selection
>>>of
>>>the VID and associated semantics where VIDs are translated. The actual
>>>point of S-tag imposition could be a PE, or cloud be a NID/CLE on the
>>>customer prem (more likely scenario here to extend OAM demarc to the
>>>prem), or some switch in a RAN downstream of the MPLS PE... blah blah
>>>blah. And if ETREE is extended into a customer site LAN and outside of
>>>the provider domain, then two C-tags would have to be used that mapped
>>>to
>>>S-tags at the PBN boundary...
>>>
>>>Make sense?
>>>Dave
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:[e-mail]]
>>>Sent: Wednesday, April 25, 2012 4:39 PM
>>>To: David Allan I; [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Dave, but the ACs are root/leaf (that's what the whole vpls etree is
>>>about - see the reqt draft), so per the 2vlan draft the root/leaf vlan
>>>must be added.
>>>
>>>Thumb typed - please be tolerant
>>>
>>>David Allan I <[e-mail]> wrote:
>>>
>>>HI Daniel:
>>>
>>>In the example provided,
>>>
>>>"ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID"
>>>                  A                       B
>>>
>>>the service is not ETREE in the domains of the ingress and egress VID.
>>>It
>>>is ELAN. SO there is no root/leaf attribute to shovel around. It would
>>>require two VIDs in each domain if the ETREE semantics were to be
>>>telescoped E2E.
>>>
>>>Otherwise it is a provisioning of the VID translation tables at the
>>>intermediate nodes (A&B that I've added to the picture) that would
>>>determine the VID values used in each domain. Or in the example above,
>>>what the ingress, Etree and egress VID values were.
>>>
>>>Cheers
>>>Dave
>>>
>>>-----Original Message-----
>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of
>>>Daniel Cohn
>>>Sent: Wednesday, April 25, 2012 3:46 PM
>>>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;
>>>[e-mail];
>>>[e-mail]
>>>Cc: [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>And to this I asked how this mapping works - how does the egress pe
>>>recover the ingress vid when it gets the frame tagged with only the
>>>root/leaf vid? How can you convey the ingress vid plus the root/leaf
>>>attribute in the same number of bits?
>>>What am I missing?
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <[e-mail]> wrote:
>>>
>>>Daniel,
>>>
>>>David Allen already explained the solution.
>>>
>>>From David:
>>>ingress VLAN ID <-> Etree Root/Leaf VID <-> Egress VID.
>>>
>>>Ingress VID does not have to equal Egress VID but regardless there is
>>>only ever one VID on a frame at a time.
>>>
>>>-end
>>>
>>>This works when customer makes ingress VLAN ID not equal to or equal to
>>>egress VLAN ID.
>>>
>>>Regards,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of
>>>Daniel Cohn
>>>Sent: Wednesday, April 25, 2012 11:39 AM
>>>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;
>>>[e-mail];
>>>[e-mail]
>>>Cc: [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Lucy,
>>>
>>>The scenario we are discussing is not the E-Tree E-NNI, but a general
>>>scenario where frames arriving at the root or leaf AC  are already
>>>double
>>>tagged. In this case, the dual vlan solution cannot preserve the vlans
>>>without adding a third one, can it?
>>>
>>>Maybe Shahram can add details on the scenario he had in mind
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <[e-mail]> wrote:
>>>
>>>Daniel,
>>>
>>>MEF has S-VLAN preservation attribute for ENNI only because there is no
>>>s-vlan at UNI. When an MEN connects to multiple ENNI interfaces, S-VALN
>>>preservation attribute is used. It applies to E-Tree as well.
>>>
>>>Regards,
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of
>>>Daniel Cohn
>>>Sent: Tuesday, April 24, 2012 2:12 AM
>>>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;
>>>[e-mail];
>>>[e-mail]
>>>Cc: [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Lucy,
>>>
>>>even if the current MEF framework doesn't require s-vlan preservation, I
>>>believe it's to the industry's benefit to adopt a solution that is not
>>>constrained to a specific enni model that, like all things networking,
>>>is
>>>likely to evolve. Especially when such a solution is available.
>>>
>>>Daniel
>>>
>>>Thumb typed - please be tolerant
>>>
>>>Lucy yong <[e-mail]> wrote:
>>>
>>>Daniel,
>>>
>>>MEF has worked in ENNI interface for a long time with many service
>>>providers' inputs. It had a fair reason to assume S-VLAN over ENNI by
>>>then. It may open B-VLAN for the future. It is better for us not to
>>>discuss  a future framework here, because it will lead us to nowhere.
>>>Here, we want to extend VPLS in supporting E-Tree.
>>>
>>>Best Regards,
>>>Lucy
>>>
>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of
>>>Daniel Cohn
>>>Sent: Sunday, April 22, 2012 7:34 AM
>>>To: Rogers, Josh; Shahram Davari; Lizhong Jin; [e-mail];
>>>[e-mail]
>>>Cc: [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Shahram and all,
>>>
>>>This question already came up in our discussions - is it safe to assume
>>>that the VLAN tags at the E-NNI will always be according to the current
>>>MEF model? Or should we try to be as transparent as possible to user
>>>VLAN
>>>encapsulation at the E-NNI, to accommodate future frameworks?
>>>I believe that any approach that looks at user payload (in this case
>>>VLAN
>>>tag) to signal VPLS information (in this case root/leaf origin) is
>>>necessarily tied to specific assumptions on user payload encapsulation
>>>(in this case, that S-VLAN tag is "available" to encode root/leaf). I
>>>don't think this is a future-proof assumption, it's very likely that
>>>other network models will come up that require S-VLAN preservation,
>>>which
>>>in the 2-VLAN approach would necessitate adding a third VLAN-ID.
>>>
>>>Daniel
>>>
>>>From: Shahram Davari <[e-mail]<mailto:[e-mail]>>
>>>To: Lizhong Jin <[e-mail]<mailto:[e-mail]>>,
>>>"[e-mail]<mailto:[e-mail]>"
>>><[e-mail]<mailto:[e-mail]>>,
>>>"[e-mail]<mailto:[e-mail]
>>>m
>>>>
>>>"
>>><[e-mail]<mailto:[e-mail]
>>>m
>>>>
>>>>
>>>Cc: "[e-mail]<mailto:[e-mail]>"
>>><[e-mail]<mailto:[e-mail]>>
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi,
>>>
>>>I also have a question regarding 2-VLAN. What if the customer traffic
>>>already has an S-VLAN? Do we need a 3rd VLAN to identify the L/R?
>>>
>>>Thx
>>>Shahram
>>>
>>>From: [e-mail]<mailto:[e-mail]>
>>>[mailto:[e-mail]] On Behalf Of Lizhong Jin
>>>Sent: Friday, April 20, 2012 9:38 AM
>>>To: [e-mail]<mailto:[e-mail]>;
>>>[e-mail]<mailto:[e-mail]
>>>>
>>>Cc: [e-mail]<mailto:[e-mail]>
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi, all,
>>>The difference between 2-VLAN and CW approach is who will provide the
>>>R/L
>>>information, customer payload or PW? The customer payload will be always
>>>modified to carry R/L information in 2-VLAN approach, while PW with CW
>>>will carry R/L information for CW approach.
>>>I have a question with the 2-VLAN approach in H-VPLS where H-VPLS is
>>>accessed by VPWS as described in RFC4672 section 10.1.3. If VPWS is used
>>>to access H-VPLS, how could the PE on VPWS side adds VLAN to indicate
>>>R/L
>>>information?
>>>
>>>Thanks
>>>Lizhong
>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Thu, 19 Apr 2012 04:38:36 +0000
>>>> From: Alexander Vainshtein
>>>> <[e-mail]<mailto:Alexander.Vainshtein@ecitele.
>>>> com>>
>>>> To: "Rogers, Josh"
>>>><[e-mail]<mailto:[e-mail]>>, Lucy yong
>>>>        <[e-mail]<mailto:[e-mail]>>, Daniel
>>>>Cohn
>>>><[e-mail]<mailto:[e-mail]>>, Sam Cao
>>>>        <[e-mail]<mailto:[e-mail]>>
>>>> Cc: "[e-mail]<mailto:[e-mail]>"
>>>> <[e-mail]<mailto:[e-mail]>>
>>>> Subject: RE: The status of the approaches to the E-Tree solution?
>>>> Message-ID:
>>>>
>>>> <[e-mail]<mailt
>>>> o:[e-mail]>>
>>>> Content-Type: text/plain; charset="us-ascii"
>>>>
>>>> Hi all,
>>>> I fully understand that that what I am going to say is not very
>>>>popular, but:
>>>>
>>>> IMO one of the advantages of the CW-based solution is that it is
>>>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery
>>>>of
>>>>BUN traffic.
>>>>
>>>> Another advantage is preservation of full mesh of P2P PWs in a VPLS,
>>>>and, in a more generic way, localization of effects of changes in the
>>>>PE
>>>>configuration.
>>>>
>>>> In particular, adding a Leaf AC to a PE that previously has been only
>>>>supporting Root ACs (or vice versa), removal of the last Leaf or last
>>>>Root AC from a PE that previously has been supporting a mix etc. affect
>>>>only the PE where this operation happens and not the rest of the PEs.
>>>>
>>>> As for the need for HW changes that have been mentioned as a main
>>>>disadvantage of the CW-based approach - I believe it strongly depends
>>>>on
>>>>specific implementations. And some changes in the forwarding process
>>>>are
>>>>required in any solution.
>>>>
>>>> My 2c,
>>>>     Sasha
>>>>
>>>>
>>>>
>>>> ________________________________________
>>>> From: [e-mail]<mailto:[e-mail]>
>>>> [[e-mail]<mailto:[e-mail]>] on behalf of
>>>> Rogers, Josh [[e-mail]<mailto:[e-mail]>]
>>>> Sent: Wednesday, April 18, 2012 9:57 PM
>>>> To: Lucy yong; Daniel Cohn; Sam Cao
>>>> Cc: [e-mail]<mailto:[e-mail]>
>>>> Subject: Re: The status of the approaches to the E-Tree solution?
>>>>
>>>> Again, the P2MP situation throws me.  Is this something that is used
>>>> commonly?
>>>>
>>>> I'm under the impression that adding P2MP to any model results in a
>>>> more complex model.  Wether outside s-tag is used to differentiate, or
>>>> dedicated pw's are used for the same purpose, it seems both become
>>>> more complex.
>>>>
>>>> Gile's comparison slide still concisely captures the differences
>>>> between these methods, in my opinion.  I haven't seen any new ideas or
>>>> thoughts brought to the group in the past week or two on the subject.
>>>> I would hate for both proposed methods to die on the vine because we
>>>> couldn't decide between two methods that have nothing inherently wrong
>>>>with either.
>>>>
>>>> -Josh
>>>>
>>>>
>>>> On 4/18/12 1:53 PM, "Lucy yong"
>>>><[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>>>Send this again.
>>>>>
>>>>>Two PW approach can be complex too if the VPLS instance for E-Tree
>>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown
>>>>>unicast traffic, and some P2MP PWs for multicast traffic. It may
>>>>>double all of them.
>>>>>
>>>>>Lucy
>>>>>
>>>>>-----Original Message-----
>>>>>From: Daniel Cohn
>>>>>[mailto:[e-mail]<mailto:[e-mail]>]
>>>>>Sent: Wednesday, April 18, 2012 1:42 PM
>>>>>To: Lucy yong; Rogers, Josh; Sam Cao
>>>>>Cc: [e-mail]<mailto:[e-mail]>
>>>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>>>
>>>>>I think the first option its the natural way to go. How is the
>>>>>processing in this case more complex?
>>>>>
>>>>>Thumb typed - please be tolerant
>>>>>
>>>>>Lucy yong <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>Snipped..
>>>>>
>>>>>Multi-PW - On ingress PE, frame is placed onto either a Leaf-only P2MP
>>>>>PW (for traffic coming from a leaf AC), or onto a Root/Leaf P2MP PW
>>>>>(for traffic coming from a root AC) [[LY]] Not that simple. You
>>>>>construct either two P2MP PWs to all other PEs and let egress PE
>>>>>performing filtering, or construct one P2MP PW to leaf-only PEs and
>>>>>two P2MP PWs to root and leaf PEs and let ingress PE perform
>>>>>forwarding and filtering. Both make node process complex.
>>>>>
>>>>>[[LY]] VPLS is built with the mechanism utilizing P2P and P2MP PW for
>>>>>delivering the frames to remote PEs. We should utilize them with the
>>>>>minimized changes. Dual VLAN solution is simpler than Dual PW.
>>>>>
>>>>>Regards,
>>>>>Lucy
>>>>>
>>>>>
>>>>>I see how 2VLAN is simpler when P2MP PW's are involved, I think.  I
>>>>>haven't had any first hand experience with P2MP PW's, however, so
>>>>>don't feel terribly strong about this objection.  Is this a real
>>>>>problem for others (now or in the future), or is this objection in the
>>>>>weeds?
>>>>>
>>>>>I'm not sure the 'additional complexity' is notable, or even relevant.
>>>>>I encourage others to speak up if they disagree, as P2MP PW is only
>>>>>conceptual to me, and I am unfamiliar with real-life use cases for it.
>>>>>
>>>>>Thanks,
>>>>>Josh
>>>>>
>>>>>
>>>>>
>>>>>On 4/18/12 10:30 AM, "Lucy yong"
>>>>><[e-mail]<mailto:[e-mail]>> wrote:
>>>>>
>>>>>>Please see inline.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Sam Cao
>>>>>>[mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim
>>>>>>(Wim)'; [e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:Alexander.Vainshtein@ecitele.
>>>>>>com>
>>>>>>Cc: [e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>
>>>>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>>>>
>>>>>>Yes, 2 pws are only needed between pes with both root and leaf acs
>>>>>>after improving Dual-PW approach. If consider P2MP, Dual-PW approach
>>>>>>setup 2 P2MP PWs if need. There is no difference between P2MP or
>>>>>>normal PW setup. But, can Leaf-ACs be bound to Root PE of P2MP PW?
>>>>>>
>>>>>>[[LY]] No, it makes complex in setting up P2MP PW. Should a PE with
>>>>>>both root and leaf ACs set up two or one P2MP PW to other PEs (some
>>>>>>PE have both root and leaf AC and some only have leaf ACs)?
>>>>>>Regards,
>>>>>>Lucy
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Yuqun (Sam) Cao
>>>>>>E-mail: [e-mail]<mailto:[e-mail]>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Daniel Cohn
>>>>>>[mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:Alexander.Vainshtein@ecitele.
>>>>>>com>; Sam Cao
>>>>>>Cc: [e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>
>>>>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>>>>
>>>>>>Adding Sam (as l2vpn@ is holding messages)
>>>>>>
>>>>>>DC
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Lucy yong
>>>>>>[mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:Alexander.Vainshtein@ecitele.
>>>>>>com>
>>>>>>Cc: [e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>;
>>>>>>[e-mail]<mailto:[e-mail]>
>>>>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>>>>
>>>>>>
>>>>>>Snipped,
>>>>>>
>>>>>>As we discussed extensively in the list, and as reflected in giles
>>>>>>slide, 2 pws are only needed between pes with both root and leaf acs,
>>>>>>which will typically be a small minority.
>>>>>>[[LY]] Don't know if the assumption is true. Even it is the case,
>>>>>>both approaches can benefit from it. I was off for a while and
>>>>>>captures some discussions now.
>>>>>>
>>>>>>Also as per giles slide, dual vlan can have scalability issues due to
>>>>>>additional lookup and double use of vlans in internal emulated lan
>>>>>>interface. Also there are potential backward compatibility issues
>>>>>>with silicon that doesn't support vlan mapping.
>>>>>>[[LY]] I was not in IETF83 meeting and wait on the meeting minutes. I
>>>>>>am not clear on all the issues. Could you be more specific? As I
>>>>>>mentioned in below, two PW approach makes VPLS transport construction
>>>>>>and packet forwarding more complex, I can see potential backward
>>>>>>compatibility issues with 2 PW solution.
>>>>>>
>>>>>>Regards,
>>>>>>Lucy
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Daniel
>>>>>>
>>>>>>Thumb typed - please be tolerant
>>>>>>
>>>>>>Lucy yong <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>In my mind, the VLAN approach means dual vlan method.
>>>>>>
>>>>>>The main concern for CW approach is hardware support.
>>>>>>
>>>>>>Two PW approach can be complex too if the VPLS instance for E-Tree
>>>>>>uses P2P PW for unicast traffic and P2MP PW for broadcast and unknown
>>>>>>unicast traffic, and some P2MP PWs for multicast traffic. It may
>>>>>>double all of them.
>>>>>>
>>>>>>E-tree is an Ethernet service and there is already VLAN based
>>>>>>solution in IEEE, can we just utilize it without complicating VPLS
>>>>>>transport construction? This also makes interworking with Eth only
>>>>>>network easier.
>>>>>>
>>>>>>Cheers,
>>>>>>Lucy
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Rogers, Josh
>>>>>>[mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>Sent: Monday, April 16, 2012 8:35 AM
>>>>>>To: Lucy yong; Henderickx, Wim (Wim);
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:Alexander.Vainshtein@ecitele
>>>>>>.
>>>>>>c
>>>>>>om>'
>>>>>>Cc: '[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>'
>>>>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>>>>
>>>>>>I believe the initial question was in regard to the CW method.  Are
>>>>>>you saying that you no longer are interested in that method in
>>>>>>preference of the dual vlan method?
>>>>>>
>>>>>>
>>>>>>
>>>>>>Lucy yong <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>
>>>>>>Agree with Wim. VLAN approach is the best solution for E-Tree.
>>>>>>
>>>>>>Lucy
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]<mailto:[e-mail]>
>>>>>>[mailto:[e-mail]<mailto:[e-mail]>] On
>>>>>>Behalf Of Henderickx, Wim (Wim)
>>>>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>>>>To: '[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:Alexander.Vainshtein@ecitele
>>>>>>.
>>>>>>c
>>>>>>om>'
>>>>>>Cc: '[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>';
>>>>>>'[e-mail]<mailto:[e-mail]>'
>>>>>>Subject: Re: The status of the approaches to the E-Tree solution?
>>>>>>
>>>>>>The vlan approach is superior as it also works for eth only networks,
>>>>>>etc. On top some vendors indicate hw issues with the cw approach. As
>>>>>>such we have dropped more or less the cw approach.
>>>>>>
>>>>>>Cheers,
>>>>>>Wim
>>>>>>_________________
>>>>>>sent from blackberry
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: Giles Heron
>>>>>>[mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>>>>To: Simon Delord
>>>>>><[e-mail]<mailto:[e-mail]>>; Alexander
>>>>>>Vainshtein
>>>>>><[e-mail]<mailto:Alexander.Vainshtein@ecitele
>>>>>>.com>>
>>>>>>Cc: [e-mail]<mailto:[e-mail]>
>>>>>><[e-mail]<mailto:[e-mail]>>; Vladimir Kleiner
>>>>>><[e-mail]<mailto:[e-mail]>>;
>>>>>>Andrew Sergeev
>>>>>><[e-mail]<mailto:[e-mail]>>; Idan
>>>>>>Kaspit <[e-mail]<mailto:[e-mail]>>;
>>>>>>Mishael Wexler
>>>>>><[e-mail]<mailto:[e-mail]>>;
>>>>>>Rotem Cohen <[e-mail]<mailto:[e-mail]>>
>>>>>>Subject: Re: The status of the approaches to the E-Tree solution?
>>>>>>
>>>>>>Sorry - the "anonymous presentation" was mine.  I should possibly
>>>>>>have put in a third column on the CW approach.  And hopefully the
>>>>>>minutes will be posted soon.
>>>>>>
>>>>>>We had various discussions, as Simon stated, and consensus seemed to
>>>>>>be forming around the two alternatives of two PWEs or two VLANs.  I
>>>>>>believe three of the authors of the CW approach are also authors of
>>>>>>the two VLAN approach and one is also an author of the two PWE
>>>>>>approach. So perhaps it's best to let those four individuals say
>>>>>>which approach they prefer and why?
>>>>>>
>>>>>>Giles
>>>>>>
>>>>>>On 10/04/2012 00:45, "Simon Delord"
>>>>>><[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> You are right, no discussion on the WG mailing list recently, but
>>>>>>> there have been substantial discussions among the authors of
>>>>>>> various solution drafts off the mailing list. As far as I know, no
>>>>>>> consensus yet before ietf83, not sure the progress in the Paris WG
>>>>>>> meeting. I think the CW approach has not been rejected by the WG
>>>>>>> yet, or the WG has not yet decided on which one to adopt.
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>> 2012/4/8 Alexander Vainshtein
>>>>>>> <[e-mail]<mailto:Alexander.Vainshtein@ecite
>>>>>>> le.com>>
>>>>>>>
>>>>>>>>  Hi all,
>>>>>>>>
>>>>>>>> Unfortunately I have not been able to attend the Paris IETF.
>>>>>>>>
>>>>>>>> However, looking up the L2VPN proceedings, I've found a short
>>>>>>>> anonymous presentation called "E-Tree Update"  (
>>>>>>>> http://www.ietf.org/proceedings/83/slides/slides-83-l2vpn-1.pptx).
>>>>>>>> This presentation discusses the differences of the E-Tree
>>>>>>>> approaches based on dedicated VLANs (as in
>>>>>>>> http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/?includ
>>>>>>>> e_t
>>>>>>>> ext=1) and multiple PWs between the PEs (as in
>>>>>>>> http://datatracker.ietf.org/doc/draft-ram-l2vpn-etree-multiple-pw/
>>>>>>>> ?in
>>>>>>>> clude_te
>>>>>>>> xt=1)
>>>>>>>> and completely ignores the solution based on usage of the CW in
>>>>>>>> the PWs connecting the PEs (as in
>>>>>>>> http://datatracker.ietf.org/doc/draft-key-l2vpn-vpls-etree/?includ
>>>>>>>> e_t
>>>>>>>> ext=1
>>>>>>>> ).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The Minutes of the Paris L2VPN session are not yet available, but
>>>>>>>> I wonder whether the WG has taken a decision to reject the
>>>>>>>> approach based on the CW usage? I do not remember any recent
>>>>>>>> discussion of this topic on the WG mailing list.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards, and lots of thanks in advance,
>>>>>>>>
>>>>>>>> Sasha
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This e-mail message is intended for the recipient only and
>>>>>>>> contains information which is CONFIDENTIAL and which may be
>>>>>>>> proprietary to ECI
>>>>>>
>>>>>>>> Telecom. If you have received this transmission in error, please
>>>>>>>> inform us by e-mail, phone or fax, and then delete the original
>>>>>>>> and all copies thereof.
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>This E-mail and any of its attachments may contain Time Warner Cable
>>>>>>proprietary information, which is privileged, confidential, or
>>>>>>subject to copyright belonging to Time Warner Cable. This E-mail is
>>>>>>intended solely for the use of the individual or entity to which it
>>>>>>is
>>>>>>addressed.
>>>>>>If you are not the intended recipient of this E-mail, you are hereby
>>>>>>notified that any dissemination, distribution, copying, or action
>>>>>>taken in relation to the contents of and attachments to this E-mail
>>>>>>is strictly prohibited and may be unlawful. If you have received this
>>>>>>E-mail in error, please notify the sender immediately and permanently
>>>>>>delete the original and any copy of this E-mail and any printout.
>>>>>>
>>>>>
>>>>>
>>>>>This E-mail and any of its attachments may contain Time Warner Cable
>>>>>proprietary information, which is privileged, confidential, or subject
>>>>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>>>>solely for the use of the individual or entity to which it is
>>>>>addressed. If you are not the intended recipient of this E-mail, you
>>>>>are hereby notified that any dissemination, distribution, copying, or
>>>>>action taken in relation to the contents of and attachments to this
>>>>>E-mail is strictly prohibited and may be unlawful. If you have
>>>>>received this E-mail in error, please notify the sender immediately
>>>>>and permanently delete the original and any copy of this E-mail and
>>>>>any
>>>>>printout.
>>>>
>>>>
>>>> This E-mail and any of its attachments may contain Time Warner Cable
>>>>proprietary information, which is privileged, confidential, or subject
>>>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>>>solely for the use of the individual or entity to which it is
>>>>addressed.
>>>>If you are not the intended recipient of this E-mail, you are hereby
>>>>notified that any dissemination, distribution, copying, or action taken
>>>>in relation to the contents of and attachments to this E-mail is
>>>>strictly prohibited and may be unlawful. If you have received this
>>>>E-mail in error, please notify the sender immediately and permanently
>>>>delete the original and any copy of this E-mail and any printout.
>>>> This e-mail message is intended for the recipient only and contains
>>>>information which is CONFIDENTIAL and which may be proprietary to ECI
>>>>Telecom. If you have received this transmission in error, please inform
>>>>us by e-mail, phone or fax, and then delete the original and all copies
>>>>thereof.
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> L2vpn mailing list
>>>> [e-mail]<mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/l2vpn
>>>>
>>>>
>>>> End of L2vpn Digest, Vol 95, Issue 25
>>>> ***********************************
>>
>>
>>This E-mail and any of its attachments may contain Time Warner Cable
>>proprietary information, which is privileged, confidential, or subject to
>>copyright belonging to Time Warner Cable. This E-mail is intended solely
>>for the use of the individual or entity to which it is addressed. If you
>>are not the intended recipient of this E-mail, you are hereby notified
>>that any dissemination, distribution, copying, or action taken in
>>relation to the contents of and attachments to this E-mail is strictly
>>prohibited and may be unlawful. If you have received this E-mail in
>>error, please notify the sender immediately and permanently delete the
>>original and any copy of this E-mail and any printout.
>
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.