Subject: RE: L2vpn Digest, Vol 95, Issue 58

From: Jiangyuanlong <[email-masked]>
Date: Mon, 23 Apr 2012 01:59:02 +0000

Hi Sam,

If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762, then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC should be terminated and the E-Tree service should be encapsulated by the MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as one AC", but even in that case, the attribute of the AC may be configured at the PE-rs. So what is the problem for H-VPLS?

Thanks
Yuanlong

Date: Sun, 22 Apr 2012 22:03:52 +0800
From: "Sam Cao" <[email-masked]>
To: "'Jiangyuanlong'" <[email-masked]>
Cc: [email-masked]
Subject: RE: The status of the approaches to the E-Tree solution?
Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam>
Content-Type: text/plain;	charset="us-ascii"

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

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

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

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: "Sam Cao" <[email-masked]>
Date: Mon, 23 Apr 2012 11:27:53 +0800

Yuanlong,

I do apologize for my unclear description. I try to make it clear.

VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really
does NOT care remote access is VPWS access (point-to-point, Fig. 3) or VPLS
spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH, and
does NOT care customer payload. is this correct?  At least it is correct in
RFC 4762. 

But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for
remote VPWS access although it is still spoke PW in E-Tree. Please refer to
your answer to Josh's question. It seems reasonable. Ok, we think another
case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this
case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-s.

Ok, problem came up for me. For spoke PW on PE-rs, in one case it should
configure AC type and work as agent; in another case, it can NOT configure
AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it
is enough; why spoke-PW has different configuration in same VPLS instance on
same PE? I am confused although I know why we should configure in that way.

I prefer not to configure AC type on PE-rs since we can take it as
"Switching PE" (NOT pefact here and it is not real "Switching Point") which
does NOT aware customer payload. Extension to VPWS? Seems not reasonable.

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:59 AM
To: Sam Cao
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Hi Sam,

If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC 4762,
then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC
should be terminated and the E-Tree service should be encapsulated by the
MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as one
AC", but even in that case, the attribute of the AC may be configured at the
PE-rs. So what is the problem for H-VPLS?

Thanks
Yuanlong

Yuanlong,

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;

Regards,

Yuqun (Sam) Cao

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 23 Apr 2012 11:23:15 +0000

Sam,

Please see my comments in line. I also change the title to reflect the topic.

Regards
Yuanlong

-----Original Message-----
From: Sam Cao [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 11:28 AM
To: Jiangyuanlong
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Yuanlong,

[JY] why divide the remote access to VPWS access and VPLS access?

[JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the E-Tree attribute on the PE-rs since the PE-r does not support any bridging functions. I think this case is provided in RFC4762 just to be compatible with some legacy routers.

I prefer not to configure AC type on PE-rs since we can take it as
"Switching PE" (NOT pefact here and it is not real "Switching Point") which
does NOT aware customer payload. Extension to VPWS? Seems not reasonable.
[JY] Not sure I got your points. PE-rs will terminate the PW and switch the Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or a MTU-s is dependent on the topology of the service and how they are attached. H-VPLS can be seen as a transparent transport network, or as a service itself.

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:59 AM
To: Sam Cao
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Hi Sam,

Thanks
Yuanlong

Yuanlong,

Regards,
 
Yuqun (Sam) Cao

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 23 Apr 2012 11:33:27 +0000

Sam, Yuanlong and all,
>From my point of view the CW-based solution is by far the simplest way to deal with H-VPLS: all that is required is preservation of the CW (or, in the unlikely case PW sequencing is used, of its flags) when a packet is forwarded from the "core" PW to a "spoke" one (or vice versa).

With Dual PWE the situation becomes more complicated IMO. Not sure about dual VLAN - but may be also tricky.

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jiangyuanlong
> Sent: Monday, April 23, 2012 2:23 PM
> To: Sam Cao
> Cc: [email-masked]
> Subject: Discussion on E-Tree and H-VPLS
> 
> Sam,
> 
> [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the E-
> Tree attribute on the PE-rs since the PE-r does not support any bridging
> functions. I think this case is provided in RFC4762 just to be compatible with
> some legacy routers.
> 
> 
> [JY] Not sure I got your points. PE-rs will terminate the PW and switch the
> Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or a
> MTU-s is dependent on the topology of the service and how they are
> attached. H-VPLS can be seen as a transparent transport network, or as a
> service itself.
> 
> Thanks,
> 
> Sam
> 

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 23 Apr 2012 11:49:45 +0000

Hi Sash,

What Sam discussed is the use case where some legacy devices play the role of PE-r or MTU-s, these devices may not support CW either (some spoke are QinQ actually).
If all devices support the E-Tree extension, dual VLAN seems quite simple too - the PE-rs just needs to preserve the VLAN tagged by the MTU-s. Section A.2 of our I-D already discusses this H-VPLS scenario, could you have a review of it?

Regards and thanks,
Yuanlong

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 7:33 PM
To: Jiangyuanlong; Sam Cao
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS 

Sam, Yuanlong and all,

Regards,
     Sasha

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 23 Apr 2012 12:23:38 +0000

Sasha,

Sorry, but I don't think the CW-based solution can preserve the CW in such a way. In PE-rs, the PW should be terminated and the Ethernet frame needs to be forwarded with dst MAC lookup. Therefore, we need some tricky bits in the switch fabric in order to carry the CW information intact across the Ethernet forwarding plane. 

Thanks
Yuanlong

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 7:33 PM
To: Jiangyuanlong; Sam Cao
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS 

Sam, Yuanlong and all,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 23 Apr 2012 13:44:33 +0000

Yuanlong,
Lots of thanks for a prompt response.

I think that actual complexity of preserving the flags in the CW when forwarding from a core PW to a spoke one (or vice versa) strongly depends on your implementation. E.g., in Chassis-based PEs it is quite customary for the ingress blade to prepend some internal header to the packet(s) it sends across the Fabric to the egress blade. In this case you need at most to find one unused bit in this header (usually not a big deal), and you can also possibly do without.

Of course this implementing this behavior in some tailored HW could be highly problematic - but IMHO so would be any approach that has not been taken into account by the vendor of the specific chip.

Regards,
     Sasha

> Sent: Monday, April 23, 2012 3:24 PM
> To: Alexander Vainshtein; Sam Cao
> Cc: [email-masked]
> Sorry, but I don't think the CW-based solution can preserve the CW in such a
> way. In PE-rs, the PW should be terminated and the Ethernet frame needs
> to be forwarded with dst MAC lookup. Therefore, we need some tricky bits
> in the switch fabric in order to carry the CW information intact across the
> Ethernet forwarding plane.
> 
> Thanks
> Yuanlong
> 
> 
> From my point of view the CW-based solution is by far the simplest way to
> deal with H-VPLS: all that is required is preservation of the CW (or, in the
> unlikely case PW sequencing is used, of its flags) when a packet is
> forwarded from the "core" PW to a "spoke" one (or vice versa).
> 
> With Dual PWE the situation becomes more complicated IMO. Not sure
> about dual VLAN - but may be also tricky.
> 
> Regards,
>      Sasha
> 
> > is enough; why spoke-PW has different configuration in same VPLS
> instance
> > on
> > MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW
> as
> > one
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us by
> e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 24 Apr 2012 01:21:24 +0000

Sasha,

Dual VLAN will have no impact on the switch fabric as long as Ethernet forwarding is supported.
So the question is, do we really need to develop a solution which is strongly dependent on specific implementations when we have other choices?

Thanks,
Yuanlong

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:45 PM
To: Jiangyuanlong; Sam Cao
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS

Yuanlong,

Regards,
     Sasha

---

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

Yuanlong,

Ok. Go on H-VPLS discussion although there are so many pending issues on
Dual-VLAN.We can go one by one, :) I thought this for many times, it may be
disadvantage of Dual-VLAN.

In general, if MTU can NOT support Layer 2 switching, we will use P2P access
(I called this as VPWS access); if MTU can support Layer 2 switching, we can
use P2P or MP2MP access (I called the later as VPLS spoke access). Both are
active deployment. Josh has given us one real deployment in real network. We
can hold the opposite opinions, but this is really requirements from
carriers. In Josh's example, even if MTU-s can support L2 switching, it also
should work in VPWS mode.

As I know, most vendors support 2 deployments. Then focus on VPWS deployment
and PE-rs (Fig.4), we should appoint one VPWS access (On PE-r, it is VPWS;
on PE1-rs, it is really Spoke PW. In this case, there is 1 or more PWs
between PE-r AND PE1-rs) Root or Leaf. As you know, we can not appoint on
PE-r since we have no extension to VPWS. You explained it in your reply to
Josh's mail. I agree. Then go to Fig. 3. MTU-s can support L2 switching, so
only 1 PW (1 PW is requirement from RFC 4762, but 2 or more PWs has no
problem) between MTU-s and PE1-rs. This is also spoke PW. Can we appoint
Root/Leaf for the Spoke PW? No. The root cause is, we can not appoint access
type, Root or Leaf, anymore since MTU-s has added S-VLAN-ID into frame. This
is my question: For VPWS access, we should configure Root/Leaf for Spoke PW;
for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW.

Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in the 2
cases since it uses different PATH, not inferring context in frame.

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 7:23 PM
To: Sam Cao
Cc: [email-masked]
Subject: Discussion on E-Tree and H-VPLS

Sam,

Please see my comments in line. I also change the title to reflect the
topic.

Regards
Yuanlong

-----Original Message-----
From: Sam Cao [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 11:28 AM
To: Jiangyuanlong
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Yuanlong,

But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for
remote VPWS access although it is still spoke PW in E-Tree. Please refer to
your answer to Josh's question. It seems reasonable. Ok, we think another
case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this
case. In fact, on MTU-s it is VPLS and we should configure AC type on MTU-s.
[JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the
E-Tree attribute on the PE-rs since the PE-r does not support any bridging
functions. I think this case is provided in RFC4762 just to be compatible
with some legacy routers.

I prefer not to configure AC type on PE-rs since we can take it as
"Switching PE" (NOT pefact here and it is not real "Switching Point") which
does NOT aware customer payload. Extension to VPWS? Seems not reasonable.
[JY] Not sure I got your points. PE-rs will terminate the PW and switch the
Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or a
MTU-s is dependent on the topology of the service and how they are attached.
H-VPLS can be seen as a transparent transport network, or as a service
itself.

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:59 AM
To: Sam Cao
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Hi Sam,

Thanks
Yuanlong

Yuanlong,

Regards,
 
Yuqun (Sam) Cao

---

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

Sasha,

Just as we discussed for many times, 3 approaches use different identifiers.
For me, Multi-PW uses different PATH (Multi-PW), but CW or Dual-VLAN uses
inferring context in frames. 

So CW also has same HVPLS deployment problem.

Thanks,

Sam

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 7:33 PM
To: Jiangyuanlong; Sam Cao
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS 

Sam, Yuanlong and all,

With Dual PWE the situation becomes more complicated IMO. Not sure about
dual VLAN - but may be also tricky.

Regards,
     Sasha

topic.

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 24 Apr 2012 06:00:26 +0000

See my comments in line.

-----Original Message-----
From: Sam Cao [mailto:[email-masked]] 
Sent: Tuesday, April 24, 2012 11:51 AM
To: Jiangyuanlong
Cc: [email-masked]
Subject: RE: Discussion on E-Tree and H-VPLS

Yuanlong,

[JY] Not sure I understand the whole section, are you concerned with H-VPLS use cases with QinQ spoke access? If that is the case, the S-VLAN is just like the PW label in the case of PW spoke, it should be removed at the PE-rs.

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 7:23 PM
To: Sam Cao
Cc: [email-masked]
Subject: Discussion on E-Tree and H-VPLS

Sam,

Regards
Yuanlong

-----Original Message-----
From: Sam Cao [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 11:28 AM
To: Jiangyuanlong
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Yuanlong,

Thanks,

Sam

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 9:59 AM
To: Sam Cao
Cc: [email-masked]
Subject: RE: L2vpn Digest, Vol 95, Issue 58

Hi Sam,

Thanks
Yuanlong

Yuanlong,

Regards,
 
Yuqun (Sam) Cao