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

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

Hi Sam,

Please see my comments in line with [JY].

Regards,
Yuanlong

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

Message: 1
Date: Sat, 21 Apr 2012 22:51:28 +0800
From: "Sam Cao" <[email-masked]>
To: "'Lizhong Jin'" <[email-masked]>,	"'Henderickx, Wim \(Wim\)'"
	<[email-masked]>
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?
Message-ID: <1B88357C808B432E871CA9D678305B7C@v2comsam>
Content-Type: text/plain; charset="gb2312"

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;
[JY] Do you really consider tagged PW as non-standard?

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;
[JY] In the first place, why PE-rs need to figure out the AC type for a spoke? The VLAN should be processed in the MTU, not in the PE-rs.

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.
[JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW label, so I can't see what is the problem. 

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;
[JY] Is anything not working with tagged PW mode?

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.
[JY] Could you elaborate a little more what is the compatibility issue? 

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

Is there anything missed? 

Regards,

Yuqun (Sam) Cao

E-mail: [email-masked] 

  _____  

From: Lizhong Jin [mailto:[email-masked]] 
Sent: Saturday, April 21, 2012 11:59 AM
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]> ???
> 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
>
>> ------------------------------
>>
>> 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 fo 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120421/34adce68/attachment.htm>

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

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

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

---

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

Yuanlong,

I just collect all issues we discussed before, and we still can not make
agreement. I gave my comments on 2 items below. I will think other items
over and give my comments tomorrow.

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;
[JY] In the first place, why PE-rs need to figure out the AC type for a
spoke? The VLAN should be processed in the MTU, not in the PE-rs.
[Sam] Yuanlong, I understand your idea. It does NOT make sense for me.
First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig. 3),
we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so it
will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs
into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure
Root/Leaf on PE-rs (Refer to your reply to Josh's comments).

4)  Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs
should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN
ID;
[JY] Is anything not working with tagged PW mode?
[Sam] Tagged mode works. 

Regards,
 
Yuqun (Sam) Cao

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Sunday, April 22, 2012 5:43 PM
To: Sam Cao
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Sam,

Regards,
Yuanlong

Message: 1

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)       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;
[JY] In the first place, why PE-rs need to figure out the AC type for a
spoke? The VLAN should be processed in the MTU, not in the PE-rs.

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.
[JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW
label, so I can't see what is the problem. 

4)       Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs
should work in tagged mode, otherwise PE-rs or egress PE will stripe S-VLAN
ID;
[JY] Is anything not working with tagged PW mode?

Regards,

Yuqun (Sam) Cao

  _____  

Hi Win,

Regards
Lizhong

Lizhong Jin
hate

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120421/34adce68/at
tachment.htm>

---

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

Hi Yuanlong,

Yesterday evening I think HVPLS again, and again I think that it is problem
if I don't misunderstand Dual-VLAN draft. First, this is VPWS access;
secondly, if it is VPWS access, all active drafts does not extend anything
for VPWS. I agree with your answer to Josh's question (Original is Multi-AS,
but it is really HVPLS). Would you please read that mail again? Thanks.
Please get more comments below.

[JY] The same as above, only T-PE will deal with VLAN, S-PE only switches PW
label, so I can't see what is the problem.
[Sam] This came up in the first round (By Rafi). You explained that
switching PE does NOT aware VLAN mapping. At first glance it seems
reasonable. But this depends on your VLAN allocation. Would you please
update your draft? Then I can give more comments.

[JY] Could you elaborate a little more what is the compatibility issue?
// 2012-3-29 from Daniel
But how would the non-legacy PE know which VLANs are available at the legacy
PE? The legacy PE cannot advertise it if it doesn't support extensions!

BTW, I just collect the items we have discussed, and list what we can not
make agreement before :).

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Sunday, April 22, 2012 5:43 PM
To: Sam Cao
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Sam,

Regards,
Yuanlong

Message: 1

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
hate

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 23 Apr 2012 03:48:44 +0000

Hi Sam,

Please see my comments in line.

Regards,
Yuanlong

-----Original Message-----
From: Sam Cao [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:25 AM
To: Jiangyuanlong
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Yuanlong,

[JY] Could you detail your concerns so that I can understand it?

[JY] Could you elaborate a little more what is the compatibility issue?
// 2012-3-29 from Daniel
But how would the non-legacy PE know which VLANs are available at the legacy
PE? The legacy PE cannot advertise it if it doesn't support extensions!
[JY] Thanks, I got your point. So the question is the control plane interworking with the legacy PE, it seems the same VPLS processing as traditional can well deal with this scenario. That is, in Compatible mode, the PE with new E-Tree extension can establish raw PW with the legacy PE, and the VLAN can be removed on the PW. However, if the VLANs are configured, the VLAN can also be available.

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Sunday, April 22, 2012 5:43 PM
To: Sam Cao
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?

Hi Sam,

Regards,
Yuanlong

Message: 1

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
hate