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

From: Jiangyuanlong <[email-masked]>
Date: Sun, 22 Apr 2012 09:50:26 +0000

Hi Josh,

Wish the last email on "SVLAN in the 2VLAN E-Tree solution" covered this issue.
BTW, a 2VLAN encapsulated frame is not in the format as described. A single S-tag is usually enough.

Thanks
Yuanlong

----------------------------------------------------------------------

Message: 1
Date: Sat, 21 Apr 2012 11:02:51 -0400
From: "Rogers, Josh" <[email-masked]>
To: Sam Cao <[email-masked]>, '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?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

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.

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
E-mail: [email-masked]<mailto:[email-masked]>

________________________________
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,
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]>> ???
> 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]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lizhong Jin
> Sent: vrijdag 20 april 2012 18:38
> 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:[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]>>
>> Subject: RE: The status of the approaches to the E-Tree solution?
>> Message-ID:
>>        <[email-masked]<mailto:[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 fo

________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120421/97b432ca/attachment.htm>

------------------------------

_______________________________________________
L2vpn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 95, Issue 49
*************************************

---

From: "Rogers, Josh" <[email-masked]>
Date: Sun, 22 Apr 2012 20:54:45 -0400

Hello Yuanlong,

If the UNI is service multiplexed (multiple services), then the customer
must tag all traffic destined for this ETREE instance (as well as expect
it tagged with the same ID).  So, imagine the customer transmit frame with
VLAN-ID '3' into the service from a root site.  Frame traverses the AC,
and enters the AC port on the first PE.  Service Provider is using VLAN-ID
4001 for traffic sourced from 'root' AC's, and 4002 for traffic sourced
from 'leaf' AC's.  Since this frame came in from a root site, we prepend
the frame with VLAN-ID 4001 (now 4001:3), it traverses the PW(s) that the
CAM designates on first PE.  On egress PE, vlan 4001 is popped off and the
frame is returned with VLAN ID 3 back to customer.  In my example below,
4001 would be the R/L S-Tag, and 3 would be the 'AC S-Tag' (I think
someone mentioned that this is not technically an S-Tag because it is
coordinated with the customer), and the 'C-Tag' below may be an additional
tag if the customer were double tagging.  My point was that the SP is
dealing with double tagged frames for the ETREE service.

In the example above, the SP still has to deal with 4001:3, the 3
designates which service the frame belongs to, and 4001 designates the
frame came from a root site.  From the customer's perspective, the three
approaches change nothing, none require anything different from the
customer. The 2VLAN method, however, does require a little more
understanding with VLAN mapping from the service provider's perspective,
since they are dealing with a double tag.  I suppose this depends a bit on
the hardware vendor's implementation of the method, however.  It could be
possible to automate and/or hide the outer ETREE tag.  For example, if the
implementation standardizes on 4001 for root sourced, and 4002 for leaf
sourced, then w/in the VPLS instance, if a) the service is defined as
ETREE, and b) each AC is defined as 'root' or 'leaf', then the R/L vlan
tagging could be automated and not really noticed or cared much about by
the operator, which would hide this complexity.

I do think it is worth noting that the double tagging introduces
complexity, however.

Thank you,
-Josh

On 4/22/12 4:50 AM, "Jiangyuanlong" <[email-masked]> wrote:

>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.
>
>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
>
>To: 'Lizhong Jin' <[email-masked]<mailto:[email-masked]>>,
>"'Henderickx, Wim (Wim)'"
><[email-masked]<mailto:[email-masked]
>m>>
>5)       Backwards compatibility, especially legacy PE or Non-supporting
>PE with IEEE E-tree support joins E-Tree domain;
>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;
>
>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.
>
>Cc: [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
>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]
>m>> ???
>> 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]>
>>[mailto:[email-masked]<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
>>
>>> From: Alexander Vainshtein
>>><[email-masked]<mailto:[email-masked]
>>>m>>
>>> 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]>>
>>> 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]>]
>>> On 4/18/12 1:53 PM, "Lucy yong"
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>Send this again.
>>>>
>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.
>URL:
><http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120421/97b432ca/
>attachment.htm>
>