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

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 25 Apr 2012 23:38:56 +0300

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 <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 3:46 PM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
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 <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 11:39 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
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 <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Tuesday, April 24, 2012 2:12 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
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 <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Sunday, April 22, 2012 7:34 AM
To: Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
To: Lizhong Jin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 9:38 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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
> <[email-masked]<mailto:Alexander.Vainshtein@ecitele.
> com>>
> To: "Rogers, Josh" <[email-masked]<mailto:[email-masked]>>, Lucy yong
>        <[email-masked]<mailto:[email-masked]>>, Daniel Cohn <[email-masked]<mailto:[email-masked]>>, Sam Cao
>        <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> Subject: RE: The status of the approaches to the E-Tree solution?
> Message-ID:
>
> <[email-masked]<mailt
> o:[email-masked]>>
> 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: [email-masked]<mailto:[email-masked]>
> [[email-masked]<mailto:[email-masked]>] on behalf of
> Rogers, Josh [[email-masked]<mailto:[email-masked]>]
> Sent: Wednesday, April 18, 2012 9:57 PM
> To: Lucy yong; Daniel Cohn; Sam Cao
> Cc: [email-masked]<mailto:[email-masked]>
> 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" <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
>>Sent: Wednesday, April 18, 2012 1:42 PM
>>To: Lucy yong; Rogers, Josh; Sam Cao
>>Cc: [email-masked]<mailto:[email-masked]>
>>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 <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>Please see inline.
>>>
>>>-----Original Message-----
>>>From: Sam Cao
>>>[mailto:[email-masked]<mailto:[email-masked]>]
>>>Sent: Tuesday, April 17, 2012 7:14 AM
>>>To: 'Daniel Cohn'; Lucy yong; 'Rogers, Josh'; 'Henderickx, Wim
>>>(Wim)'; [email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:Alexander.Vainshtein@ecitele.
>>>com>
>>>Cc: [email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>
>>>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: [email-masked]<mailto:[email-masked]>
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn
>>>[mailto:[email-masked]<mailto:[email-masked]>]
>>>Sent: Tuesday, April 17, 2012 4:56 PM
>>>To: Lucy yong; Rogers, Josh; Henderickx, Wim (Wim);
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:Alexander.Vainshtein@ecitele.
>>>com>; Sam Cao
>>>Cc: [email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>
>>>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:[email-masked]<mailto:[email-masked]>]
>>>Sent: Tuesday, April 17, 2012 12:39 AM
>>>To: Daniel Cohn; Rogers, Josh; Henderickx, Wim (Wim);
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:Alexander.Vainshtein@ecitele.
>>>com>
>>>Cc: [email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>
>>>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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
>>>Sent: Monday, April 16, 2012 8:35 AM
>>>To: Lucy yong; Henderickx, Wim (Wim);
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
>>>Cc: [email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
>>>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 <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>Agree with Wim. VLAN approach is the best solution for E-Tree.
>>>
>>>Lucy
>>>
>>>-----Original Message-----
>>>From: [email-masked]<mailto:[email-masked]>
>>>[mailto:[email-masked]<mailto:[email-masked]>] On
>>>Behalf Of Henderickx, Wim (Wim)
>>>Sent: Thursday, April 12, 2012 2:03 AM
>>>To: [email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>'
>>>Cc: [email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>';
>>>[email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
>>>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:[email-masked]<mailto:[email-masked]>]
>>>Sent: Thursday, April 12, 2012 08:22 AM
>>>To: Simon Delord
>>><[email-masked]<mailto:[email-masked]>>; Alexander
>>>Vainshtein
>>><[email-masked]<mailto:Alexander.Vainshtein@ecitele
>>>.com>>
>>>Cc: [email-masked]<mailto:[email-masked]>
>>><[email-masked]<mailto:[email-masked]>>; Vladimir Kleiner
>>><[email-masked]<mailto:[email-masked]>>;
>>>Andrew Sergeev
>>><[email-masked]<mailto:[email-masked]>>; Idan
>>>Kaspit <[email-masked]<mailto:[email-masked]>>;
>>>Mishael Wexler
>>><[email-masked]<mailto:[email-masked]>>;
>>>Rotem Cohen <[email-masked]<mailto:[email-masked]>>
>>>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" <[email-masked]<mailto:[email-masked]>> 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
>>>> <[email-masked]<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
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/l2vpn
>
>
> End of L2vpn Digest, Vol 95, Issue 25
> ***********************************

---

From: David Allan I <[email-masked]>
Date: Wed, 25 Apr 2012 17:04:57 -0400

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:[email-masked]]
Sent: Wednesday, April 25, 2012 4:39 PM
To: David Allan I; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

HI Daniel:

In the example provided,

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 3:46 PM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Daniel

Daniel,

-end

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 11:39 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Lucy,

Daniel,

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Tuesday, April 24, 2012 2:12 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Lucy,

Daniel

Daniel,

Best Regards,
Lucy

Shahram and all,

Daniel

Hi,

Thx
Shahram

Hi, all,

Thanks
Lizhong

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Wed, 25 Apr 2012 16:22:38 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, April 25, 2012 5:05 PM
To: Daniel Cohn; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Make sense?
Dave

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 4:39 PM
To: David Allan I; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

HI Daniel:

In the example provided,

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 3:46 PM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Daniel

Daniel,

-end

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 11:39 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Lucy,

Daniel,

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Tuesday, April 24, 2012 2:12 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Lucy,

Daniel

Daniel,

Best Regards,
Lucy

Shahram and all,

Daniel

Hi,

Thx
Shahram

Hi, all,

Thanks
Lizhong

---

From: David Allan I <[email-masked]>
Date: Wed, 25 Apr 2012 17:34:03 -0400

HI Don:

As usual you're correct. It would be no different than including a single S-tag for an ELAN in the PW when subtending PBNs needed to be supported as far as overhead at any point is concerned.

IMO NIDs is a good example (esp. for business services) of where this would be highly desirable as an example of both the art of the possible and a practical deployment scenario...

Best
Dave

-----Original Message-----
From: Fedyk, Donald (Don) [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 5:23 PM
To: David Allan I; Daniel Cohn; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Dave

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, April 25, 2012 5:05 PM
To: Daniel Cohn; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Make sense?
Dave

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 4:39 PM
To: David Allan I; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

HI Daniel:

In the example provided,

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 3:46 PM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Daniel

Daniel,

-end

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Wednesday, April 25, 2012 11:39 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Lucy,

Daniel,

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Tuesday, April 24, 2012 2:12 AM
To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Lucy,

Daniel

Daniel,

Best Regards,
Lucy

Shahram and all,

Daniel

Hi,

Thx
Shahram

Hi, all,

Thanks
Lizhong

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 25 Apr 2012 17:41:43 -0400

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)

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

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)

Hope that clears more than it confuses,
Josh

On 4/25/12 4:22 PM, "Fedyk, Donald (Don)"
<[email-masked]> 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
>
>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
>
>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.
>
>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
>
>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
>
>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?
>
>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
>
>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
>
>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
>
>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
>
>To: Lizhong Jin <[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>
>"
><[email-masked]<mailto:[email-masked]>
>>
>Cc: "[email-masked]<mailto:[email-masked]>"
>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
>
>[mailto:[email-masked]] On Behalf Of Lizhong Jin
>To: [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>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
>
>> To: "Rogers, Josh"
>><[email-masked]<mailto:[email-masked]>>, Lucy yong
>>        <[email-masked]<mailto:[email-masked]>>, Daniel Cohn
>><[email-masked]<mailto:[email-masked]>>, Sam Cao
>> 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
>>
>>
>>
>> On 4/18/12 1:53 PM, "Lucy yong"
>><[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>Send this again.
>>>
>>>On 4/18/12 10:30 AM, "Lucy yong"
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>Please see inline.
>>>>
>>>>[email-masked]<mailto:[email-masked]>';
>>>>[email-masked]<mailto:[email-masked]>'
>>>>[email-masked]<mailto:[email-masked]>';
>>>>[email-masked]<mailto:[email-masked]>'
>>>>On 10/04/2012 00:45, "Simon Delord"
>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> Hi Alexander,
>>>>>
>>solely for the use of the individual or entity to which it is addressed.
>>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
>> 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.
>>
>>
>>

---

From: David Allan I <[email-masked]>
Date: Wed, 25 Apr 2012 18:19:07 -0400

Yes, if the discussion was options on preserving CUSTOMER tag information, we did march off on a tangent.

Now I hate to be pedantic but when you wrote:
"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)"

I presume you meant "the customer VID is coordinated with the provider", "Not the service VID that is coordinated with the customer". The customer tag infers the ETREE instance for a VID based UNI. And the customer does not need to know the provider ETREE VIDs....the provider needs to know what tags the customer wants mapped to specific provider services....

Cheers
Dave

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 5:42 PM
To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; [email-masked]
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)

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

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)

On 4/25/12 4:22 PM, "Fedyk, Donald (Don)"
<[email-masked]> wrote:

> 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
>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.
>
>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.
>
>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
>
>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.
>
>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;
>[email-masked]; [email-masked]
>Cc: [email-masked]
>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;
>[email-masked]; [email-masked]
>Cc: [email-masked]
>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?
>
>To: Lucy yong; Rogers, Josh; Shahram Davari; Lizhong Jin;
>[email-masked]; [email-masked]
>Cc: [email-masked]
>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
>
>MEF model? Or should we try to be as transparent as possible to user
>VLAN encapsulation at the E-NNI, to accommodate future frameworks?
>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
>
>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.
>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
>
>>        <[email-masked]<mailto:[email-masked]>>, Daniel
>>Cohn <[email-masked]<mailto:[email-masked]>>, Sam Cao
>> <[email-masked]<mail
>> t o:[email-masked]>>
>>orthogonal to usage (or non-usage) of P2MP PWs for effective delivery
>>of BUN traffic.
>>
>>and, in a more generic way, localization of effects of changes in the
>>PE configuration.
>>
>>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.
>>
>>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
>>
>>
>>
>> Rogers, Josh
>> [[email-masked]<mailto:[email-masked]>]
>> 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.
>>
>>>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
>>>>slide, 2 pws are only needed between pes with both root and leaf
>>>>acs, which will typically be a small minority.
>>>>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
>>>>
>>>>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.
>>>>
>>>>[email-masked]<mailto:Alexander.Vainshtein@ecitel
>>>>e.c
>>>>om>'
>>>>[email-masked]<mailto:Alexander.Vainshtein@ecitel
>>>>e.c
>>>>om>'
>>>>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
>>>>
>>>><[email-masked]<mailto:[email-masked]>>;
>>>>Idan Kaspit
>>>><[email-masked]<mailto:[email-masked]>>;
>>>>Mishael Wexler
>>>>Rotem Cohen
>>>><[email-masked]<mailto:[email-masked]>>
>>>>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.
>>>>
>>>
>>>
>>>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.
>>
>>
>>taken in relation to the contents of and attachments to this E-mail is
>>inform us by e-mail, phone or fax, and then delete the original and
>>all copies thereof.
>>
>>
>>

---

From: Lucy yong <[email-masked]>
Date: Wed, 25 Apr 2012 22:22:24 +0000

Hi Josh,

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rogers, Josh
Sent: Wednesday, April 25, 2012 4:42 PM
To: Fedyk, Donald (Don); David Allan I; Daniel Cohn; [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

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.

Where:

Site  Type  VLAN
CE1   Root  X
CE2   Leaf  2
CE3   Leaf  3
CE4   Leaf  3

-or-

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

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 25 Apr 2012 19:21:43 -0400

> Yes, if the discussion was options on preserving CUSTOMER tag
>information, we did march off on a tangent.

I have to apologize, because I think I led y'all down that path (I
referred to the outermost tag, the same tag that the MPLS psuedowire is
using for vlan mode encamp, as the S-Tag, even though the customer is the
one placing it on the frame.  Same as I described below, but I either used
term S-Tag incorrectly, or ambiguously.

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

>I presume you meant "the customer VID is coordinated with the provider",
>"Not the service VID that is coordinated with the customer". The customer
>tag infers the ETREE instance for a VID based UNI. And the customer does
>not need to know the provider ETREE VIDs....the provider needs to know
>what tags the customer wants mapped to specific provider services....

So, I think this could be cleared up some still.  What I was referring to
is the VID that the customer is using to put frames in, the VID which they
should use to ensure the frame goes into the correct ETREE instance.  You
drew a distinction between 'customer VID' vs 'provider VID', but since it
is negotiated, I haven't really seen a distinction, which I think is what
has caused all the confusion.  In the two discussion points/solutions I
mentioned, the first one, "A", describes both a coordinated VID which the
customer should use, and the service provider uses to distinguish between
services on the same UNI, as well as a second, outer, VID which is used by
the SP to determine the source AC type.   In my example, if you were to
sniff inside the psuedowire between PE1 and PE2 to see CE2 destined
traffic, wish solution A, you might see "4001:2:Payload", where 4001
designates it is from a root AC, 2 designates the ETREE instance, and
Payload is the customer's traffic (which may include a C-Tag), where with
solution B, you would see "4001:Payload", and VID 2 would have to be
swapped for 4001 as it enters the PE2-CE2 AC, giving the customer
"2:Payload" just as they sent it (alternatively SP may choose to simply
drop tag entirely and provide "Payload" to customer, this can cause
problems with PVST on some devices, but I still see it done occasionally)

** Note, for the example above, I'm assuming 4001 is used as a 'standard'
for root sourced frames, and 4002 is used for leaf sourced frames, for the
ETREE R/L tags.

Have I undone the confusion, or made it worse?

-Josh

On 4/25/12 5:19 PM, "David Allan I" <[email-masked]> wrote:

>Yes, if the discussion was options on preserving CUSTOMER tag
>information, we did march off on a tangent.
>
>"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)"
>
>I presume you meant "the customer VID is coordinated with the provider",
>"Not the service VID that is coordinated with the customer". The customer
>tag infers the ETREE instance for a VID based UNI. And the customer does
>not need to know the provider ETREE VIDs....the provider needs to know
>what tags the customer wants mapped to specific provider services....
>
>Cheers
>Dave
>
>
>
>
>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
>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)
>
>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)
>
>
>>>>>is addressed.
>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.

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 25 Apr 2012 19:23:26 -0400

[[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" <[email-masked]> wrote:

>[[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.
>
>[[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.
>
>
>[[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
>
>
>>"[email-masked]<mailto:[email-masked]
>>>
>>"
>><[email-masked]<mailto:[email-masked]
>>>
>>>
>>>>>[email-masked]<mailto:Alexander.Vainshtein@ecitele.
>>>>>c
>>>>>om>'
>>>>>[email-masked]<mailto:Alexander.Vainshtein@ecitele.
>>>>>c
>>>>>om>'

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Wed, 25 Apr 2012 18:52:50 -0500

Hi Josh

Is there a draft that describes solution A?
Solution B is what I've seen in the IEEE.

One argument is that A is adding an extra TAG that offers little value. The TAG you have labeled 2 may need to be swapped anyway.  Stacking S-TAGs is why PBB was developed.

Cheers,
Don

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 7:22 PM
To: David Allan I; Fedyk, Donald (Don); Daniel Cohn; [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

-Josh

---

From: David Allan I <[email-masked]>
Date: Thu, 26 Apr 2012 08:55:27 -0400

Both scenarios are possible according to my read of 802.1.ad.

For 'a', a C-tagged frame simply has the s-tag inserted....

For 'b' a C-component strips the C-tag before presenting the frame on a customer network port that is unique to the S-tag (e.g. internal to a PB.)...

Dave

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 7:23 PM
To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn; [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

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" <[email-masked]> wrote:

>already has c-tag and s-tag, which is not UNI case. In addition, it
>seems that Daniel say that only option A works.
>
>
>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
>
>off the ETREE S-Tag (some SP's wish to Pop the original customer tag
>VID 2 as well)
>
>-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
>
>
>
>>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.
>>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.
>>
>>L2 isolation everywhere then I need two VIDs extended to the end
>>system attachement point in the local LANs by whatever means....
>>
>>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
>>would require two VIDs in each domain if the ETREE semantics were to
>>be telescoped E2E.
>>
>>double tagged. In this case, the dual vlan solution cannot preserve
>>the vlans without adding a third one, can it?
>>
>>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
>>
>>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?
>>com
>>> 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.
>>> or dedicated pw's are used for the same purpose, it seems both
>>> become more complex.
>>>
>>>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.
>>>>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
>>>>[[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
>>>>
>>>>
>>>>>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?
>>>>>
>>>>>construction and packet forwarding more complex, I can see
>>>>>potential backward compatibility issues with 2 PW solution.
>>>>>
>>>>>Regards,
>>>>>Lucy
>>>>>
>>>>>Regards,
>>>>>
>>>>>Daniel
>>>>>
>>>>>unknown unicast traffic, and some P2MP PWs for multicast traffic.
>>>>>It may double all of them.
>>>>>
>>>>>[email-masked]<mailto:[email-masked]>'
>>>>>; [email-masked]<mailto:[email-masked]>';
>>>>>[email-masked]<mailto:[email-masked]>'
>>>>>; [email-masked]<mailto:[email-masked]>';
>>>>>le
>>>>>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
>>>>>> 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
>>>>>>
>>>>>>> The Minutes of the Paris L2VPN session are not yet available,
>>>>>>> but I wonder whether the WG has taken a decision to reject the
>>>>>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
>E-mail is strictly prohibited and may be unlawful. If you have received

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Apr 2012 15:30:10 +0000

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:[email-masked]] 
Sent: Wednesday, April 25, 2012 6:23 PM
To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn; [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

-Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Thu, 26 Apr 2012 11:48:20 -0400

Agreed.

On 4/26/12 10:30 AM, "Lucy yong" <[email-masked]> 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
>
>>we
>>2
>>will
>>customer,
>>>works
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>>David Allan I
>>>A&B
>>>I
>>>of
>>>It
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>>Daniel Cohn
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>>Daniel Cohn
>>>double
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>>Daniel Cohn
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>>Daniel Cohn
>>>VLAN
>>>which
>>>[email-masked]<mailto:[email-masked]
>>>>
>>>R/L
>>>>Cohn
>>>>of
>>>>PE
>>>>on
>>>>>>is
>>>>>>addressed.
>>>>>and permanently delete the original and any copy of this E-mail and
>>>>>any
>>>>>printout.
>>>>
>>>>
>>>>addressed.

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Apr 2012 15:53:54 +0000

Dave,

I think that option a and b you give are different from option A and B Josh states. Your option a and b are possible. Option A in Josh's mail adds two S-tags on the frame, IEEE does not support this implementation. So it is better for us to be away from it since we have option B.

Regards,
Lucy

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Thursday, April 26, 2012 7:55 AM
To: Rogers, Josh; Lucy yong; Fedyk, Donald (Don); Daniel Cohn; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Dave

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 7:23 PM
To: Lucy yong; Fedyk, Donald (Don); David Allan I; Daniel Cohn; [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

-Josh

On 4/25/12 5:22 PM, "Lucy yong" <[email-masked]> wrote:

>Of Rogers, Josh
>>Of David Allan I
>>Of Daniel Cohn
>>Of Daniel Cohn
>>Of Daniel Cohn
>>Of Daniel Cohn

---

From: "Rogers, Josh" <[email-masked]>
Date: Thu, 26 Apr 2012 12:00:58 -0400

Lucy,

I'm not sure that is true.  I think you're having the same trouble I had,
I was considering the tag the customer applies to their egress traffic as
a 'inside S-Tag', but others have stated they would consider this a
'C-Tag', even though it is used on the SP's network (to distinguish
service on the UNI)  You'll note in my most recently explanation of the
two scenarios, I intentionally avoided referring to this ambiguous tag as
either an S-Tag or C-Tag.

> For 'a', a C-tagged frame simply has the s-tag inserted....

Do you mean that the SP pushes the S-tag on in front of the coordinated
tag the customer uses to ensure traffic enters the correct service?  Or do
you mean something else entirely?

Wait… I thought we agreed to not discuss this 'A' method any longer, as it
leads to some horrible black hole of inconsequential tangents?

-Josh

On 4/26/12 10:53 AM, "Lucy yong" <[email-masked]> wrote:

>Dave,
>
>I think that option a and b you give are different from option A and B
>Josh states. Your option a and b are possible. Option A in Josh's mail
>adds two S-tags on the frame, IEEE does not support this implementation.
>So it is better for us to be away from it since we have option B.
>
>Regards,
>Lucy
>
>For 'b' a C-component strips the C-tag before presenting the frame on a
>customer network port that is unique to the S-tag (e.g. internal to a
>PB.)...
>
>Dave
>
>>>>>>any printout.

---

From: David Allan I <[email-masked]>
Date: Thu, 26 Apr 2012 12:18:02 -0400

HI Josh:

My reference to a C-tag is a customer administered  tag with  ethertype 0x8100.
My reference to an S-tag is a provider administered  tag with ethertype 0x88a8.

My supposition is the customer needs to advise the provider of what C-tag they want mapped to which service if they subscribe to multiple tagged services, otherwise no tag information needs to be shared, all customer traffic is mapped to a common  service .

The provider translates the work order to an S-tag value to infer from either the port or the C-tag and configures the customer facing PB accordingly.

Dave

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]]
Sent: Thursday, April 26, 2012 12:01 PM
To: Lucy yong; David Allan I; Fedyk, Donald (Don); Daniel Cohn; [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

Lucy,

I'm not sure that is true.  I think you're having the same trouble I had, I was considering the tag the customer applies to their egress traffic as a 'inside S-Tag', but others have stated they would consider this a 'C-Tag', even though it is used on the SP's network (to distinguish service on the UNI)  You'll note in my most recently explanation of the two scenarios, I intentionally avoided referring to this ambiguous tag as either an S-Tag or C-Tag.

> For 'a', a C-tagged frame simply has the s-tag inserted....

Do you mean that the SP pushes the S-tag on in front of the coordinated tag the customer uses to ensure traffic enters the correct service?  Or do you mean something else entirely?

Wait... I thought we agreed to not discuss this 'A' method any longer, as it leads to some horrible black hole of inconsequential tangents?

-Josh

 <snipped.to end>