RE: Discussion on E-Tree and H-VPLS

See my comments in line.

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

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

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:jiangyuanlong@...]
Sent: Monday, April 23, 2012 7:23 PM
To: Sam Cao
Cc: l2vpn@...
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:yuqun.cao@...]
Sent: Monday, April 23, 2012 11:28 AM
To: Jiangyuanlong
Cc: l2vpn@...
Subject: RE: L2vpn Digest, Vol 95, Issue 58

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.
[JY] why divide the remote access to VPWS access and VPLS access?

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.


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.
[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:jiangyuanlong@...]
Sent: Monday, April 23, 2012 9:59 AM
To: Sam Cao
Cc: l2vpn@...
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

Date: Sun, 22 Apr 2012 22:03:52 +0800
From: "Sam Cao" <yuqun.cao@...>
To: "'Jiangyuanlong'" <jiangyuanlong@...>
Cc: l2vpn@...
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: Yuqun.cao@...