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

[Lucy yong <[e-mail]>]

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]
>>>
>>"
>><[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?
>>
>>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.