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

From: Lizhong Jin <[email-masked]>
Date: Sat, 21 Apr 2012 00:37:41 +0800

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

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 20 Apr 2012 19:26:57 +0200

The VPWS which terminates at the H-VPLS node is indicated to be root or leaf and the procedures associated will do the VLAN manipulation

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: vrijdag 20 april 2012 18:38
To: [email-masked]; [email-masked]
Cc: [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

> From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
> 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]>>
>        <[email-masked]<mailto:[email-masked]>>
> 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]>]
> Cc: [email-masked]<mailto:[email-masked]>
> On 4/18/12 1:53 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>Send this again.
>>
>>From: Daniel Cohn [mailto:[email-masked]<mailto:[email-masked]>]
>>Cc: [email-masked]<mailto:[email-masked]>
>>Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>
>>Snipped..
>>
>>On 4/18/12 10:30 AM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>Please see inline.
>>>
>>>From: Sam Cao [mailto:[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]>;
>>>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>E-mail: [email-masked]<mailto:[email-masked]>
>>>
>>>
>>>From: Daniel Cohn [mailto:[email-masked]<mailto:[email-masked]>]
>>>[email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 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]>
>>>From: Lucy yong [mailto:[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]>;
>>>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>>[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>From: Rogers, Josh [mailto:[email-masked]<mailto:[email-masked]>]
>>>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]>'
>>>Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>>>Of Henderickx, Wim (Wim)
>>>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]>'
>>>From: Giles Heron [mailto:[email-masked]<mailto:[email-masked]>]
>>>To: Simon Delord <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein
>>><[email-masked]<mailto:[email-masked]>>
>>>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]>>
>>>On 10/04/2012 00:45, "Simon Delord" <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> 2012/4/8 Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
>>>>
>>>>>  Hi all,
>>>>>
> 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.
>
>
>
> [email-masked]<mailto:[email-masked]>

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 20 Apr 2012 18:29:06 +0000

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]] On Behalf Of Lizhong Jin
Sent: Friday, April 20, 2012 9:38 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi, all,

Thanks
Lizhong

---

From: "Rogers, Josh" <[email-masked]>
Date: Fri, 20 Apr 2012 14:40:09 -0400

This is a very good question.  A common (but not necessarily good) use case we run into is service multiplexing UNI's where multiple ELAN or ETREE services are handed off to the customer, and the S-VLAN is 'coordinated' with the customer.  Meaning we expect them to tag traffic for service X with S-tag X.

I suppose that we would ask the customer to use the 'root' S-Tag at the root site, and the 'leaf' at leaf sites, however this introduces a problem in my mind, because I believe the 2VLAN method has been working under the mindset of popping the s-tag off on UNI egress.  In this situation where we want to keep the s-tag in tact, we would require the s-tag to be kept on both ingress at one end and egress at the other.  (So things like PVST don't get upset about being sent with one vlan received w/out it)

This means that the customer would be expected to either, 1) send a frame with one VLAN id from one site type, and expect to receive it with another at the other site types, and the operator sort of 'maps' between root/leaf s-tags.  Or 2) transmit one vlan on a UNI, and expect return traffic to be tagged with the other vlan.

Neither of which is a good/reasonable option.  Is there some other way I haven't considered here?

-Josh

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,

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,

Thanks
Lizhong

---

From: Lizhong Jin <[email-masked]>
Date: Sat, 21 Apr 2012 11:59:14 +0800

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the
root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on
PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS
or MTU-s. Unless having some additional indication in NMS, you even don't
know which spoke PW needs to do VLAN manipulation. I am not sure such R/L
configuration could be accepted from operational view. Hope to see more
comments.

Regards
Lizhong

在 2012年4月21日星期六，Henderickx, Wim (Wim) <[email-masked]>
写道：
> The VPWS which terminates at the H-VPLS node is indicated to be root or
leaf and the procedures associated will do the VLAN manipulation
>>
>> 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.
>>>P2P PW fo

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Sat, 21 Apr 2012 08:52:08 +0200

Lizhong, You can also signal if the VPWS is root or leaf through a signaling protocol, but you need to configure something on the remote end or PE-rs, so from an operational point of view something needs to be configured irrespective where you do it.

From: Lizhong Jin [mailto:[email-masked]]
Sent: zaterdag 21 april 2012 5:59
To: Henderickx, Wim (Wim)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Win,
Thank you for the answers. In that case, PE-rs should configure the root/leaf properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s. Unless having some additional indication in NMS, you even don't know which spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration could be accepted from operational view. Hope to see more comments.

Regards
Lizhong

在 2012年4月21日星期六，Henderickx, Wim (Wim) <[email-masked]<mailto:[email-masked]>> 写道：
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lizhong Jin

---

From: "Sam Cao" <[email-masked]>
Date: Sat, 21 Apr 2012 19:45:42 +0800

Dual-VLAN does NOT coordinate outer S-VLAN ID with customer.  The 2 S-VLAN
ID is used to identify Root or Leaf, not for other. 

In fact, the 2 VLAN-IDs added by Dual-VLAN solution only have meaning
between 2 PEs in E-Tree domain. Ingress PE pushes S-VLAN ID, and egress PE
stripes them out. After egress PE stripes S-VLAN ID out (previous operation
is to pop PW label out), the left is customer's frame, and then bridge will
forward it in traditional way. 

Regards,

Yuqun (Sam) Cao

  _____  

From: Rogers, Josh [mailto:[email-masked]] 
Sent: Saturday, April 21, 2012 2:40 AM
To: Shahram Davari; Lizhong Jin; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

This is a very good question.  A common (but not necessarily good) use case
we run into is service multiplexing UNI's where multiple ELAN or ETREE
services are handed off to the customer, and the S-VLAN is 'coordinated'
with the customer.  Meaning we expect them to tag traffic for service X with
S-tag X. 

I suppose that we would ask the customer to use the 'root' S-Tag at the root
site, and the 'leaf' at leaf sites, however this introduces a problem in my
mind, because I believe the 2VLAN method has been working under the mindset
of popping the s-tag off on UNI egress.  In this situation where we want to
keep the s-tag in tact, we would require the s-tag to be kept on both
ingress at one end and egress at the other.  (So things like PVST don't get
upset about being sent with one vlan received w/out it)

This means that the customer would be expected to either, 1) send a frame
with one VLAN id from one site type, and expect to receive it with another
at the other site types, and the operator sort of 'maps' between root/leaf
s-tags.  Or 2) transmit one vlan on a UNI, and expect return traffic to be
tagged with the other vlan.

Neither of which is a good/reasonable option.  Is there some other way I
haven't considered here?

-Josh

From: Shahram Davari <[email-masked]>
To: Lizhong Jin <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[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]] On Behalf Of
Lizhong Jin
Sent: Friday, April 20, 2012 9:38 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi, all,

Thanks
Lizhong

> 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.
> From: [email-masked] [[email-masked]] on behalf of Rogers,
Josh [[email-masked]]
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: "Sam Cao" <[email-masked]>
Date: Sat, 21 Apr 2012 21:20:22 +0800

Lizhong and all,

We discussed HVPLS in another thread, but don’t start second thought. This
is one good question. 

If we consider VPWS, It is reasonable to configure Root/Leaf on PE-rs. As
you know, VPWS is point-to-point. So VPWS PW is thought as one VIRTUAL AC or
extension to remote attachment circuit. Please refer to Fig. 4 in RFC 4762,
say, we can configure PW1 between PE-r and PE-rs as Root on PE-rs, which
means CE-1 access is Root. PE-rs does VLAN manipulation. This seems
reasonable for me.

If you are talking about Fig. 3 in RFC 4762, it is not VPWS PW between MTU-s
and PE-rs. On both side, PW1 is taken as Spoke PW of VPLS instance. In this
case, MTU-s supports l2 switching, and we can configure Root/Leaf on MTU-s
(on the remote PE of VPWS in your mail, I think). If so, MTU-S will add
Root-VLAN ID or Leaf-VLAN ID, and PE-rs can NOT do VLAN manipulation. This
confuse me, on PE-rs, it should configure AC type in one case, but can NOT
in another case. In addition, it should operate in Tag mode, otherwise PE-rs
will remove S-VLAN ID (we also raised raw-mode before).

Lizhong, thank you again for your information.

Regards,

Yuqun (Sam) Cao

  _____  

Sent: Saturday, April 21, 2012 11:59 AM

Hi Win,

Regards
Lizhong

Lizhong Jin

---

From: "Sam Cao" <[email-masked]>
Date: Sat, 21 Apr 2012 22:51:28 +0800

Hi all,

We reach an impasse:-).  BTW, Meeting minutes is ready now. We can get
E-tree summary from IETF site.

Today I collected all items we discussed before. They are,

1)       Silicon issue or chip limit;

2)       Network efficiency;

3)       Encapsulation mode, tag or raw;

4)       H-VPLS;

5)       Backwards compatibility, especially legacy PE or Non-supporting PE
with IEEE E-tree support joins E-Tree domain;

6)       Configuration change in operation, for example, Leaf-only ->
Root-Leaf-Mixed;

7)       S-VLAN preservation support;

8)       Multi-segment PW;

9)       VLAN ID allocation (Only for Dual-VLAN);

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

If we review the mail-list, CW approach has the following limits:

1)       Chip limit. Please read reply from Giles and Wim;

2)       Network efficiency: There are garbage fames which will be dropped
on egress PE since only egress PE can decide forward or drop frames while it
receives frames. Ingress PE can not decide forward or not. Yes, current
solution can support Hub-Spoke configuration, but as we know, the
configuration is not easy if the network is big. Dual-VLAN or Multi-PW
approach can break communication between Leaf-Only PEs via signaling.

3)       Backwards compatibility: Not all PEs supports control word. If one
can not support control word, it will not join E-Tree domain;

Dual VLAN has following limits:

1)       Chip limit: As we know, we need to push one VLAN into frames before
MPLS encapsulation on ingress PE and stripe it out on egress PE. This is
non-standard operation. Wait for confirmation from chip vendor;

2)       HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS,
PE-rs works in different manner, PE-rs should figure out AC type in VPWS
case, but can NOT configure it at all in Spoke PW case;

3)       Multi-PW: Rafi figures this out, but we don’t think this over at
that time. I think that it also has same problem as H-VPLS has.

4)       Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs
should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN
ID;

5)       Backward Compatibility: Just as Daniel mentioned, there is
compatibility issue if legacy PE joins E-Tree domain. For me, I don’t get
clear response from co-authors of Dual-VLAN.

For all approaches, we don’t cover ECMP / Ethernet OAM till now. 

Is there anything missed? 

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin

---

From: "Rogers, Josh" <[email-masked]>
Date: Sat, 21 Apr 2012 11:02:51 -0400

Sam?  Where is the list for multi-PW method?

One item I don't think is covered in your 2VLAN list, is where service multiplexed UNI's are involved, or any time there is a layer 2 CPE between PE and CE, these devices usually expect a single, bidirectional s-tag, and according to your explanation this morning, coordinating the S-Tags used for ETREE with the customer SHOULD NOT to be done, therefor there must be an 'inner S-Tag' on the AC, and an 'outer S-Tag' in the PW.

While inside the PW, a 2VLAN method frame would look like:

+-----------+-----------+----------+-------+-----------------+
|MPLS Label | R/L S-Tag | AC S-Tag | C-tag | Layer 2 Payload |
+-----------+-----------+----------+-------+-----------------+

Correct?

Would you consider this an 'issue' or just a 'complication' ?

A lot of the 'pro 2VLAN' argument has been centered around existing IEEE standard, and at first it sounded like this was better/proposed for the ability to extend the R/L S-tag beyond the PW, but it sounds like that isn't really an option, so I'm not sure that is a valid benefit/driver.

Thanks much,
Josh

From: Sam Cao <[email-masked]<mailto:[email-masked]>>
To: 'Lizhong Jin' <[email-masked]<mailto:[email-masked]>>, "'Henderickx, Wim (Wim)'" <[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 all,

We reach an impasse☺.  BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site.

1)       Silicon issue or chip limit;
2)       Network efficiency;
3)       Encapsulation mode, tag or raw;
4)       H-VPLS;
5)       Backwards compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree support joins E-Tree domain;
6)       Configuration change in operation, for example, Leaf-only -> Root-Leaf-Mixed;
7)       S-VLAN preservation support;
8)       Multi-segment PW;
9)       VLAN ID allocation (Only for Dual-VLAN);
10)   Multi-AS deployment;
11)   ECMP;
12)   P2MP-PW;
13)   Ethernet OAM;

If we review the mail-list, CW approach has the following limits:
1)       Chip limit. Please read reply from Giles and Wim;
2)       Network efficiency: There are garbage fames which will be dropped on egress PE since only egress PE can decide forward or drop frames while it receives frames. Ingress PE can not decide forward or not. Yes, current solution can support Hub-Spoke configuration, but as we know, the configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach can break communication between Leaf-Only PEs via signaling.
3)       Backwards compatibility: Not all PEs supports control word. If one can not support control word, it will not join E-Tree domain;

Dual VLAN has following limits:
1)       Chip limit: As we know, we need to push one VLAN into frames before MPLS encapsulation on ingress PE and stripe it out on egress PE. This is non-standard operation. Wait for confirmation from chip vendor;
2)       HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in different manner, PE-rs should figure out AC type in VPWS case, but can NOT configure it at all in Spoke PW case;
3)       Multi-PW: Rafi figures this out, but we don’t think this over at that time. I think that it also has same problem as H-VPLS has.
4)       Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID;
5)       Backward Compatibility: Just as Daniel mentioned, there is compatibility issue if legacy PE joins E-Tree domain. For me, I don’t get clear response from co-authors of Dual-VLAN.

Regards,

Yuqun (Sam) Cao

________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Saturday, April 21, 2012 11:59 AM
To: Henderickx, Wim (Wim)
Cc: [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?

Hi Win,

Regards
Lizhong

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

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

---

From: Raymond Key <[email-masked]>
Date: Sun, 22 Apr 2012 02:01:44 +1030

Some clarifications [RK] inserted belowThanksRaymond KeyFrom: [email-masked]
To: [email-masked]; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: [email-masked]

Hi all,

We reach an impasseJ.  BTW,
Meeting minutes is ready now. We can get E-tree summary from IETF site.

Today I collected all items we discussed before. They
are,

1)       Silicon
issue or chip limit;

2)       Network
efficiency;

3)       Encapsulation
mode, tag or raw;

4)       H-VPLS;

5)       Backwards
compatibility, especially legacy PE or Non-supporting PE with IEEE E-tree
support joins E-Tree domain;

6)       Configuration
change in operation, for example, Leaf-only -> Root-Leaf-Mixed;

7)       S-VLAN
preservation support;

8)       Multi-segment
PW;

9)       VLAN
ID allocation (Only for Dual-VLAN);

10)   Multi-AS
deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet
OAM;

If we review the
mail-list, CW approach has the following limits:

1)      
Chip limit. Please read reply from Giles and Wim;

2)      
Network efficiency: There are garbage fames which will be dropped
on egress PE since only egress PE can decide forward or drop frames while it
receives frames. Ingress PE can not decide forward or not. Yes,
current solution can support Hub-Spoke configuration, but as we know, the
configuration is not easy if the network is big. Dual-VLAN or Multi-PW approach
can break communication between Leaf-Only PEs via signaling.

[RK] It seems to me this is not the case. Section 6 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE 3)      
Backwards compatibility: Not all PEs supports control word. If one
can not support control word, it will not join E-Tree domain;

 [RK] It seems to me this is not the case. Section 5 of the draft has some discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-5
5. Backward Compatibility
5.1. AC Type
5.2. Control Word
5.3. Additional Action in Data Forwarding
5.3.1. Ingress PE Supporting the Extension but Egress PE Not
5.3.2. Egress PE Supporting the Extension but Ingress PE Not 

Dual VLAN has following
limits:

1)      
Chip limit: As we know, we need to push one VLAN into frames before
MPLS encapsulation on ingress PE and stripe it out on egress PE. This is
non-standard operation. Wait for confirmation from chip vendor;

2)      
HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs works in
different manner, PE-rs should figure out AC type in VPWS case, but can NOT
configure it at all in Spoke PW case;

3)      
Multi-PW: Rafi figures this out, but we don’t think this over at
that time. I think that it also has same problem as H-VPLS has.

4)      
Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs
should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID;

5)      
Backward Compatibility: Just as Daniel mentioned, there is
compatibility issue if legacy PE joins E-Tree domain. For me, I don’t get clear
response from co-authors of Dual-VLAN.

For all approaches, we don’t
cover ECMP / Ethernet OAM till now. 

Regards,

Yuqun (Sam) Cao

 

From:

Lizhong Jin [mailto:[email-masked]] 

Sent: Saturday, April 21, 2012
11:59 AM

Cc: [email-masked];
[email-masked]; [email-masked]

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

Hi
Win,

Thank you for the answers. In that case, PE-rs should configure the root/leaf
properties of VPWS, not on the remote PE of VPWS. And usually on PE-rs, you
could not figure out the accessing spoke PW is from PE-r of VPWS or MTU-s.
Unless having some additional indication in NMS, you even don't know which
spoke PW needs to do VLAN manipulation. I am not sure such R/L configuration
could be accepted from operational view. Hope to see more comments.

Regards

Lizhong

在 2012年4月21日星期六，Henderickx, Wim
(Wim) <[email-masked]>

> From: [email-masked]
[mailto:[email-masked]] On
Behalf Of Lizhong Jin

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

>>        <[email-masked]>,
Daniel Cohn <[email-masked]>,
Sam Cao

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

>> From: [email-masked]
[[email-masked]] on behalf
of Rogers, Josh [[email-masked]]

---

From: "Daniel Cohn" <[email-masked]>
Date: Sun, 22 Apr 2012 15:33:57 +0300

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]>
To: Lizhong Jin <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The status of the approaches to the E-Tree solution?

Hi,

Thx

Shahram

Of Lizhong Jin

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

> 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.
>>>P2P PW for unicast traffic and P2MP PW for broadcast and unknown
unicast
>>proprietary information, which is privileged, confidential, or subject
to
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: Alexander Vainshtein <[email-masked]>
Date: Sun, 22 Apr 2012 12:42:20 +0000

Dan and all,
It seems that interaction with PBB (when S-VLAN is replaced by an I-Tag at E-NNI) makes your question even more relevant.

Regards,
     Sasha

From: Daniel Cohn [mailto:[email-masked]]
Sent: Sunday, April 22, 2012 3:34 PM
To: Rogers, Josh; Shahram Davari; Lizhong Jin; [email-masked]; Alexander Vainshtein
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

Hi,

Thx
Shahram

Hi, all,

Thanks
Lizhong

---

From: "Sam Cao" <[email-masked]>
Date: Sun, 22 Apr 2012 20:50:19 +0800

Josh,

Yesterday I re-read all mail and pick out all issues we have discussed
before. They are questions for all 3 approaches, and some are still
questions for me till now.

 I can not fully understand “where is the list for multi-PW method”? Do
you mean Multi-segment PW? Rafi raised this as objection to Dual-VLAN
approach, and Yuanlong explained that switching-PW does not aware AC type
and just do label-swapping. It seems reasonable, but now it may not cover
all cases. In some special cases we should configure AC types on switching
PE.

Yes, I think that it is correct.  Maybe Yuanlong or other co-authors can
correct it if it is wrong. 

“The VLAN mode looks more like the MEF and IEEE approaches – is that a
conclusive enough reason to prefer that approach?” (From meeting minutes).
For me, if it has no chip limit (wait for confirmation from chip vendors)
and compatible with current solutions, it will be better, but now… 

Regards,

Yuqun (Sam) Cao

  _____  

From: Rogers, Josh [mailto:[email-masked]] 
Sent: Saturday, April 21, 2012 11:03 PM
To: Sam Cao; 'Lizhong Jin'; 'Henderickx, Wim (Wim)'
Cc: [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

One item I don't think is covered in your 2VLAN list, is where service
multiplexed UNI's are involved, or any time there is a layer 2 CPE between
PE and CE, these devices usually expect a single, bidirectional s-tag, and
according to your explanation this morning, coordinating the S-Tags used for
ETREE with the customer SHOULD NOT to be done, therefor there must be an
'inner S-Tag' on the AC, and an 'outer S-Tag' in the PW.  

Correct?

A lot of the 'pro 2VLAN' argument has been centered around existing IEEE
standard, and at first it sounded like this was better/proposed for the
ability to extend the R/L S-tag beyond the PW, but it sounds like that isn't
really an option, so I'm not sure that is a valid benefit/driver.

Thanks much,

Josh

From: Sam Cao <[email-masked]>
To: 'Lizhong Jin' <[email-masked]>, "'Henderickx, Wim (Wim)'"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The status of the approaches to the E-Tree solution?

Hi all,

2)    Network efficiency;

4)    H-VPLS;

8)    Multi-segment PW;

10)Multi-AS deployment;

11)ECMP;

12)P2MP-PW;

13)Ethernet OAM;

2)    Network efficiency: There are garbage fames which will be dropped on
egress PE since only egress PE can decide forward or drop frames while it
receives frames. Ingress PE can not decide forward or not. Yes, current
solution can support Hub-Spoke configuration, but as we know, the
configuration is not easy if the network is big. Dual-VLAN or Multi-PW
approach can break communication between Leaf-Only PEs via signaling.

3)    Backwards compatibility: Not all PEs supports control word. If one can
not support control word, it will not join E-Tree domain;

2)    HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS, PE-rs
works in different manner, PE-rs should figure out AC type in VPWS case, but
can NOT configure it at all in Spoke PW case;

3)    Multi-PW: Rafi figures this out, but we don’t think this over at that
time. I think that it also has same problem as H-VPLS has.

4)    Encapsulation mode: If deploy GVPLS with Spoke PW mode, PE-rs should
work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN ID;

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin

  _____

---

From: "Sam Cao" <[email-masked]>
Date: Sun, 22 Apr 2012 21:40:34 +0800

Raymond,

Network efficiency:

[Sam] Leaf/Root configuration is local configuration, and PE can not know
remote AC type configuration. This is CW Fundamentals. So even if CW
approach defines optional enhancement for Leaf-Only PE, but can not signal
it between Leaf-Only PEs, so there is no good way to support this. The
possible solution is, manually configure hub-spoke topology, but if we do
like this, current solutions have support most E-Tree cases with Hub-Spoke
configuration. Lizhong mentioned this in one mail.

Backwards compatibility:

[Sam] Yes, new draft considers backward compatibility, but it makes
precondition: The PE which can not support Control word only works as
Root-only PE. This does not make sense for me. If it only supports VPLS, ok,
it can work as Root-only, but why it can not work as Root-Leaf-Mixed or
Leaf-only if it can not support CW?

Regards,

Yuqun (Sam) Cao

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Raymond Key
Sent: Saturday, April 21, 2012 11:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Some clarifications [RK] inserted below

Thanks

Raymond Key

  _____  

From: [email-masked]
To: [email-masked]; [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?
Date: Sat, 21 Apr 2012 22:51:28 +0800
CC: [email-masked]

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

[RK] It seems to me this is not the case. Section 6 of the draft has some
discussions on this.
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-07#section-6
6. Optional Enhancements for Leaf-only PE
6.1. No PW between Leaf-only PEs
6.2. Not Forward Frame from Leaf AC to Leaf-only PE

[RK] It seems to me this is not the case. Section 5 of the draft has some
discussions on this.

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 22 Apr 2012 13:56:00 +0000

Sam,
You’ve asked:
If it only supports VPLS, ok, it can work as Root-only, but why it cannot work as Root-Leaf-Mixed or Leaf-only if it cannot support CW?
IMHO and FWIW there is not too much you can expect from a true legacy PE (i.e. a PE that did not change its forwarding behavior):

1.       It can obviously support Root-only functionality

2.       It can support Leaf-only functionality if there are no Mixed by preventing setup PW (by not setting up PWs to other Leaf-only PEs).
Anything beyond that would be very much implementation-specific. E.g., I am aware of legacy implementations that could support functionality of a Mixed PE provided that it would be the only Mixed PE in the VPLS instance, and other legacy implementations that are, as legacy, fully interoperable with these ones but could not support such functionality.

My 2c,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Cao
Sent: Sunday, April 22, 2012 4:41 PM
To: 'Raymond Key'
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Raymond,

Network efficiency:
[Sam] Leaf/Root configuration is local configuration, and PE can not know remote AC type configuration. This is CW Fundamentals. So even if CW approach defines optional enhancement for Leaf-Only PE, but can not signal it between Leaf-Only PEs, so there is no good way to support this. The possible solution is, manually configure hub-spoke topology, but if we do like this, current solutions have support most E-Tree cases with Hub-Spoke configuration. Lizhong mentioned this in one mail.

Backwards compatibility:
[Sam] Yes, new draft considers backward compatibility, but it makes precondition: The PE which can not support Control word only works as Root-only PE. This does not make sense for me. If it only supports VPLS, ok, it can work as Root-only, but why it can not work as Root-Leaf-Mixed or Leaf-only if it can not support CW?

Regards,

Yuqun (Sam) Cao

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raymond Key
Sent: Saturday, April 21, 2012 11:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi all,

We reach an impasse:).  BTW, Meeting minutes is ready now. We can get E-tree summary from IETF site.

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

Hi Win,

Regards
Lizhong

---

From: "Sam Cao" <[email-masked]>
Date: Sun, 22 Apr 2012 22:05:49 +0800

I agree. 

Regards,

Yuqun (Sam) Cao

  _____  

From: Daniel Cohn [mailto:[email-masked]] 
Sent: Sunday, April 22, 2012 8:34 PM
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

Hi,

Thx

Shahram

Hi, all,

Thanks
Lizhong

---

From: "Sam Cao" <[email-masked]>
Date: Sun, 22 Apr 2012 22:22:26 +0800

Sasha,

I agree with your comments. But maybe I don’t make myself understood. I
make it clear.

If one chip can not support control word, then one switch which uses this
chip can not work as Root-Leaf-Mixed PE since we can not extend it. Is this
correct? Is this reasonable?

Anyway, chip limit is big problem for CW approach.

Regards,

Yuqun (Sam) Cao

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Sunday, April 22, 2012 9:56 PM
To: Sam Cao
Cc: [email-masked]; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

Sam,

You’ve asked:

If it only supports VPLS, ok, it can work as Root-only, but why it cannot
work as Root-Leaf-Mixed or Leaf-only if it cannot support CW?

IMHO and FWIW there is not too much you can expect from a true legacy PE (i.
e. a PE that did not change its forwarding behavior):

2.       It can support Leaf-only functionality if there are no Mixed by
preventing setup PW (by not setting up PWs to other Leaf-only PEs).

Anything beyond that would be very much implementation-specific. E.g., I am
aware of legacy implementations that could support functionality of a Mixed
PE provided that it would be the only Mixed PE in the VPLS instance, and
other legacy implementations that are, as legacy, fully interoperable with
these ones but could not support such functionality.

My 2c,

     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

  _____  

Thanks

Raymond Key

  _____  

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 22 Apr 2012 14:56:42 +0000

Sam,
I will try to explain myself.

I have misspoken before, and I owe you an apology.

A true legacy PE cannot operate as a Mixed PE for E-tree since this operation requires some changes in the forwarding behavior. This is IMHO correct regardless of the specific E-tree solution that is implemented by the rest of the PEs (CW-based, dual PW-based or VLAN-based). I.e. without some additional implementation-specific tricks it can be either a Root-only PE or a Leaf-only PE in the VPLS that does not contain Mixed PEs.

Regards,
     Sasha

From: Sam Cao [mailto:[email-masked]]
Sent: Sunday, April 22, 2012 5:22 PM
To: Alexander Vainshtein
Cc: [email-masked]; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

Sasha,

I agree with your comments. But maybe I don’t make myself understood. I make it clear.

If one chip can not support control word, then one switch which uses this chip can not work as Root-Leaf-Mixed PE since we can not extend it. Is this correct? Is this reasonable?

Regards,

Yuqun (Sam) Cao

Sam,
You’ve asked:

My 2c,
     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

Hi Win,

Regards
Lizhong

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Sun, 22 Apr 2012 23:27:05 +0000

For a given PE, If you use BGP and define separate VRFs one for the leafs and one for roots than the semantic provided by the RT assignment should be translated correctly in to the forwarding programmed.. This means that intra-PE between the leaf and root VRF should be treated as a Labeled PW. If treated as a regular ethernet interface than a leaf on VRF S1 can forward traffic on VRF H1 and then onto a different PEs leaf VRF… I believe we had a very similar conversation over a year ago about E-Tree…

So, here are the reqs I shared

*          E-Tree/Partial mesh topologies need to be realized in the control plane by constructing PWs. The data plane should not infer a topology. In other words data should not have to be inspected to determine if the packet is sourced from a leaf or a root
*          The same PE must be able to host Root and Leaf sites.
*          Disallowing of Leaf to Leaf traffic on the same PE must be done using PW semantics.
*          When Root and Leaf sites are deployed on the same PE the packets between them should obey the same semantics as if they had traversed a PW i.e ( Split Horizon, No Label Re-Imposition etc… )
*          If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or leaf site. If from PE:Leaf then the traffic should not be resolved in PE1:Leaf.

Jim Uttaro
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Sunday, April 22, 2012 10:57 AM
To: Sam Cao
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Sam,

Regards,
     Sasha

Sasha,

Regards,

Yuqun (Sam) Cao

Sam,
You’ve asked:

My 2c,
     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

Hi Win,

Regards
Lizhong

---

From: "Sam Cao" <[email-masked]>
Date: Mon, 23 Apr 2012 09:57:40 +0800

Sasha,

Yes, I agree.  

But IMHO Legacy PE can be Root-only PE, not be Leaf-Only PE, since there is
no communication limit between PEs in VPLS domain. Generally VPLS is
deployed in Full-Mesh, although we can deploy it in Hub-Spoke. Hub-Spoke is
NOT typical deployment. With Hub-Spoke, we can specify one PE as Leaf-only
PE manually (Use RT with BGP-AD, or manually configure PW wi/out BGP-AD),
but the configuration seems too complex. That is why I prefer to Multi-PW or
Dual-VLAN approach, not CW approach. 

For CW, no control-word, no E-tree, but CW is just optional.

Thanks,

Sam

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Sunday, April 22, 2012 10:57 PM
To: Sam Cao
Cc: [email-masked]; 'Raymond Key'
Subject: RE: The status of the approaches to the E-Tree solution?

Sam,

A true legacy PE cannot operate as a Mixed PE for E-tree since this
operation requires some changes in the forwarding behavior. This is IMHO
correct regardless of the specific E-tree solution that is implemented by
the rest of the PEs (CW-based, dual PW-based or VLAN-based). I.e. without
some additional implementation-specific tricks it can be either a Root-only
PE or a Leaf-only PE in the VPLS that does not contain Mixed PEs.

Regards,

     Sasha

Sasha,

Regards,

Yuqun (Sam) Cao

  _____  

Sam,

You’ve asked:

My 2c,

     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

  _____  

Thanks

Raymond Key

  _____  

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin

---

From: "Sam Cao" <[email-masked]>
Date: Mon, 23 Apr 2012 12:05:44 +0800

Hi Jim,

Thank you very much for your comments. But what we did is a little different
from yours.

Multi-PW carries AC type in “Layer2 Info Extended Community”, NOT
different RT, and control plane will translate it, but we don’t separate it
into 2 VRFs (VSI in the draft). They belong to one VSI. 

I guess your E-Tree deployment via BGP-AD is, assign one Root-RT (same in
all VPLA-PE in VPLS domain), and assign different Leaf RT for each Leaf-only
PE, then we will not setup PW between Leaf-only PEs, then we can break the
communication between Leaf-Only PEs. Is my understanding correct or not?
This is Hub-Spoke deployment, and current solution can support this. But it
can not cover all cases. 

I agree with some requirements on E-Tree in your mail.

-          Partial mesh topologies. 

[Sam] Agree. Now CW, Dual-VLAN or Dual-PW consider this in draft, but for
me, CW or Dual-VLAN will deploy partial mesh in your way or configure it
manually; Dual-PW can support this via signaling. 

-          Same PE mush be able to host Root and Leaf Sites. 

[Sam] Agree. This is Root-Leaf-Mixed case in all E-tree draft; All drafts
should support this.

-          Disallowing of Leaf to Leaf traffic on the same PE must be done
using PW semantics. 

[Sam] Jim, can not fully understand this case. If on same PE, this is local
behavior, is it correct? Do you mean we need to setup one dummy PW on any PE
if it hosts Root and Leaf sites? Shall we describe in draft?

-          When Root and Leaf sites are deployed on the same PE the packets
between them should obey the same semantics as if they had traversed a PW i.
e ( Split Horizon, No Label Re-Imposition etc… ). 

[Sam] Same question as above. Anyway, “Split Horizon” is basic rule for
all drafts.

-          If PE has a root and leaf site and sends traffic to PE1. PE1
should be able to decide if the traffic was sourced from the root or leaf
site. If from PE:Leaf then the traffic should not be resolved in PE1:Leaf. 

[Sam] Yes, what we are doing is to solve this.

Thanks,

Sam

  _____  

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 7:27 AM
To: 'Alexander Vainshtein'; Sam Cao
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

For a given PE, If you use BGP and define separate VRFs one for the leafs
and one for roots than the semantic provided by the RT assignment should be
translated correctly in to the forwarding programmed.. This means that
intra-PE between the leaf and root VRF should be treated as a Labeled PW. If
treated as a regular ethernet interface than a leaf on VRF S1 can forward
traffic on VRF H1 and then onto a different PEs leaf VRF… I believe we had
a very similar conversation over a year ago about E-Tree… 

*          E-Tree/Partial mesh topologies need to be realized in the control
plane by constructing PWs. The data plane should not infer a topology. In
other words data should not have to be inspected to determine if the packet
is sourced from a leaf or a root

*          Disallowing of Leaf to Leaf traffic on the same PE must be done
using PW semantics.

*          When Root and Leaf sites are deployed on the same PE the packets
between them should obey the same semantics as if they had traversed a PW i.
e ( Split Horizon, No Label Re-Imposition etc… )

*          If PE has a root and leaf site and sends traffic to PE1. PE1
should be able to decide if the traffic was sourced from the root or leaf
site. If from PE:Leaf then the traffic should not be resolved in PE1:Leaf.

Jim Uttaro

Alexander Vainshtein

Sam,

Regards,

     Sasha

Sasha,

Regards,

Yuqun (Sam) Cao

  _____  

Sam,

You’ve asked:

My 2c,

     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

  _____  

Thanks

Raymond Key

  _____  

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 23 Apr 2012 13:55:51 +0000

Sam,

                Comments In-Line..

Thanks,
                Jim Uttaro

From: Sam Cao [mailto:[email-masked]]
Sent: Monday, April 23, 2012 12:06 AM
To: UTTARO, JAMES; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Jim,

Thank you very much for your comments. But what we did is a little different from yours.

Multi-PW carries AC type in “Layer2 Info Extended Community”, NOT different RT, and control plane will translate it, but we don’t separate it into 2 VRFs (VSI in the draft). They belong to one VSI.

I guess your E-Tree deployment via BGP-AD is, assign one Root-RT (same in all VPLA-PE in VPLS domain), and assign different Leaf RT for each Leaf-only PE, then we will not setup PW between Leaf-only PEs, then we can break the communication between Leaf-Only PEs. Is my understanding correct or not? This is Hub-Spoke deployment, and current solution can support this. But it can not cover all cases. [Jim U>] That is the approach but as you note it does not cover all cases..

-       Partial mesh topologies.
[Sam] Agree. Now CW, Dual-VLAN or Dual-PW consider this in draft, but for me, CW or Dual-VLAN will deploy partial mesh in your way or configure it manually; Dual-PW can support this via signaling.
-       Same PE mush be able to host Root and Leaf Sites.
[Sam] Agree. This is Root-Leaf-Mixed case in all E-tree draft; All drafts should support this.
-       Disallowing of Leaf to Leaf traffic on the same PE must be done using PW semantics.
[Sam] Jim, can not fully understand this case. If on same PE, this is local behavior, is it correct? Do you mean we need to setup one dummy PW on any PE if it hosts Root and Leaf sites? Shall we describe in draft?
[Jim U>] If two VRFs one Leaf and one Root on a common PE traffic when sent from the Leaf to the Root context must not be treated as native ethernet traffic as it would then “appear” the same as traffic arriving from external ethernet interfaces.. In this regard you lose the notion that a leaf semantic is associated with that traffic..
-       When Root and Leaf sites are deployed on the same PE the packets between them should obey the same semantics as if they had traversed a PW i.e ( Split Horizon, No Label Re-Imposition etc… ).
[Sam] Same question as above. Anyway, “Split Horizon” is basic rule for all drafts.
[Jim U>] See above.. Sort of the same requirement as stated above.. I believe that the local behavior intra-PE between a Leaf and a Root should mimic the behavior as if the traffic arrived from a different PE>..
-       If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or leaf site. If from PE:Leaf then the traffic should not be resolved in PE1:Leaf.
[Sam] Yes, what we are doing is to solve this.
[Jim U>] I have not been following E-Tree too closely is this where the solution space is multiple PWs or inferring context from data traffic?

Thanks,

Sam

•          E-Tree/Partial mesh topologies need to be realized in the control plane by constructing PWs. The data plane should not infer a topology. In other words data should not have to be inspected to determine if the packet is sourced from a leaf or a root
•          The same PE must be able to host Root and Leaf sites.
•          Disallowing of Leaf to Leaf traffic on the same PE must be done using PW semantics.
•          When Root and Leaf sites are deployed on the same PE the packets between them should obey the same semantics as if they had traversed a PW i.e ( Split Horizon, No Label Re-Imposition etc… )
•          If PE has a root and leaf site and sends traffic to PE1. PE1 should be able to decide if the traffic was sourced from the root or leaf site. If from PE:Leaf then the traffic should not be resolved in PE1:Leaf.

Jim Uttaro

Sam,

Regards,
     Sasha

Sasha,

Regards,

Yuqun (Sam) Cao

Sam,
You’ve asked:

My 2c,
     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

Hi Win,

Regards
Lizhong

---

From: Lucy yong <[email-masked]>
Date: Mon, 23 Apr 2012 15:51:10 +0000

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,

Daniel

Hi,

Thx
Shahram

Hi, all,

Thanks
Lizhong

---

From: "Sam Cao" <[email-masked]>
Date: Tue, 24 Apr 2012 11:04:03 +0800

Jim,

I see. Let me summarize what we discussed.

You gave me one new solution to implement E-Tree: create 2 VSIs (VRF in your
mail) on a common PE, one for Root, and another for Leaf. If so, one
“DUMMY” or “NATIVE” PW should be established (then it “appears” same
as frames from external interface), VSI management is a little difficult,
and we also need to update our data plane to support this. In addition,
encapsulation and decapsulation are needed for native forwarding. But as I
know, most vendors do NOT support this, CW. Dual-VLAN or multi-PW approach
would implement E-Tree in one VSI, not separate it into 2 VSIs. For me, ONE
VSI is a little better. 

Solution space of Multi-PW approach is “Multi-PW”, or say, different
“PATH”, not inferring context from data traffic. CW or Dual-VLAN uses
inferring context from data traffic: CW uses one LEAF bit in control-word,
and Dual-VLAN uses 2 S-VLAN-ID in the frames.

Thanks,

Sam

  _____  

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:56 PM
To: 'Sam Cao'; 'Alexander Vainshtein'
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Sam,

                Comments In-Line..

Thanks,

                Jim Uttaro

Hi Jim,

I guess your E-Tree deployment via BGP-AD is, assign one Root-RT (same in
all VPLA-PE in VPLS domain), and assign different Leaf RT for each Leaf-only
PE, then we will not setup PW between Leaf-only PEs, then we can break the
communication between Leaf-Only PEs. Is my understanding correct or not?
This is Hub-Spoke deployment, and current solution can support this. But it
can not cover all cases. [Jim U>] That is the approach but as you note it
does not cover all cases..

[Jim U>] If two VRFs one Leaf and one Root on a common PE traffic when sent
from the Leaf to the Root context must not be treated as native ethernet
traffic as it would then “appear” the same as traffic arriving from
external ethernet interfaces.. In this regard you lose the notion that a
leaf semantic is associated with that traffic.. 

[Jim U>] See above.. Sort of the same requirement as stated above.. I
believe that the local behavior intra-PE between a Leaf and a Root should
mimic the behavior as if the traffic arrived from a different PE>..

[Jim U>] I have not been following E-Tree too closely is this where the
solution space is multiple PWs or inferring context from data traffic? 

Thanks,

Sam

  _____  

 

Jim Uttaro

Sam,

Regards,

     Sasha

Sasha,

Regards,

Yuqun (Sam) Cao

  _____  

Sam,

You’ve asked:

My 2c,

     Sasha

Raymond,

Network efficiency:

Backwards compatibility:

Regards,

Yuqun (Sam) Cao

  _____  

Thanks

Raymond Key

  _____  

Hi all,

2)       Network efficiency;

4)       H-VPLS;

8)       Multi-segment PW;

10)   Multi-AS deployment;

11)   ECMP;

12)   P2MP-PW;

13)   Ethernet OAM;

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin