|
»
« Return to Thread: RE: L2vpn Digest, Vol 95, Issue 58
RE: Discussion on E-Tree and H-VPLS
by Jiangyuanlong
::
Rate this Message:
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:Alexander.Vainshtein@...]
Sent: Monday, April 23, 2012 7:33 PM
To: Jiangyuanlong; Sam Cao
Cc: l2vpn@...
Subject: RE: Discussion on E-Tree and H-VPLS
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
> -----Original Message-----
> From: l2vpn-bounces@... [mailto:l2vpn-bounces@...] On Behalf
> Of Jiangyuanlong
> Sent: Monday, April 23, 2012 2: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@...
>
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.
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:Alexander.Vainshtein@...]
Sent: Monday, April 23, 2012 7:33 PM
To: Jiangyuanlong; Sam Cao
Cc: l2vpn@...
Subject: RE: Discussion on E-Tree and H-VPLS
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
> -----Original Message-----
> From: l2vpn-bounces@... [mailto:l2vpn-bounces@...] On Behalf
> Of Jiangyuanlong
> Sent: Monday, April 23, 2012 2: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@...
>
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.
« Return to Thread: RE: L2vpn Digest, Vol 95, Issue 58
| Free embeddable forum powered by Nabble | Forum Help |
