Subject: S-VLAN access in E-Tree

From: Jiangyuanlong <[email-masked]>
Date: Wed, 30 Mar 2011 10:00:17 +0000

Rafi and all,

Yesterday we discussed the S-VLAN access of E-Tree during the WG meeting, in addition to S-VLAN mapping or B-VLAN method, a third option is also possible if it is a carrier over carrier network use case, that is, the E-Tree traffic from the 1st carrier can be transparently transported over the 2nd carrier's VPLS network, just as in the traditional VPLS. This seems more practical as the E-Tree topology is usually only known to the 1st carrier while unavailable to the 2nd carrier, furthermore, it requires no change on the 2nd carrier network.

Best regards,
Yuanlong

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 30 Mar 2011 17:56:23 +0200

Hi Yuanlong, thanks for your comments. Looking at the scenario you
describe - if the second carrier is just doing transparent transport for
the e-tree VPLS, from a scalability point of view it would make more
sense to subtend the PW-VSIs directly between the e-tree-aware PEs, with
the second carrier acting simply as PSN for these PWs.

Also, actually I'm not sure the scenario you describe is a valid one. If
the second carrier is not e-tree aware, the e-tree VPLS won't comply
with the e-tree requirements as stated in
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and
http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what
solution is adopted.

Please note that adding VLAN tag for E-Tree functionality might be
problematic to many implementations if the original frame already
contains S-TAG/C-TAG or B-TAG.

Daniel - not Rafi ;-)

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 PM
To: Rafi Ram
Cc: [email-masked]
Subject: S-VLAN access in E-Tree

Rafi and all,

Yesterday we discussed the S-VLAN access of E-Tree during the WG
meeting, in addition to S-VLAN mapping or B-VLAN method, a third option
is also possible if it is a carrier over carrier network use case, that
is, the E-Tree traffic from the 1st carrier can be transparently
transported over the 2nd carrier's VPLS network, just as in the
traditional VPLS. This seems more practical as the E-Tree topology is
usually only known to the 1st carrier while unavailable to the 2nd
carrier, furthermore, it requires no change on the 2nd carrier network.

Best regards,

Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 30 Mar 2011 18:12:31 +0000

Daniel,

Please see my comments inline.

________________________________
发件人: Daniel Cohn [[email-masked]]
发送时间: 2011年3月30日 23:56
到: Jiangyuanlong
Cc: [email-masked]; Rafi Ram
主题: RE: S-VLAN access in E-Tree

Hi Yuanlong, thanks for your comments. Looking at the scenario you describe - if the second carrier is just doing transparent transport for the e-tree VPLS, from a scalability point of view it would make more sense to subtend the PW-VSIs directly between the e-tree-aware PEs, with the second carrier acting simply as PSN for these PWs.

[JYL]  Actually we are talking about the use case where carrier 1 attached to carrier 2 with a S-VLAN tagged AC. Your  use case is valid, but the service interface to carrier 2 is MPLS.

Also, actually I’m not sure the scenario you describe is a valid one. If the second carrier is not e-tree aware, the e-tree VPLS won't comply with the e-tree requirements as stated in http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what solution is adopted.

[JYL] Since all leaf sites are connected to the 1st carrier, assume all its network PEs can support E-Tree, then the 2nd carrier does not need to be E-Tree aware. But as a whole, the E-Tree requirements are fulfilled.

Please note that adding VLAN tag for E-Tree functionality might be problematic to many implementations if the original frame already contains S-TAG/C-TAG or B-TAG.

[JYL] As I said before, global VLAN provisioning, VLAN mapping or transparently transport are all optional mechanisms for the above use cases. After all, the typical VPLS PE consists of a bridge module and one or more VSIs, no matter what is used to indicate root/leaf in a PW (PW, control word, or VLAN, etc.), we still need an Ethernet mechanism to support E-Tree access and filtering in the bridge module itself, IMHO, it should be based on IEEE standard rather than develop another wheel in our WG. Therefore, all other solutions need the same VLAN based mechanism in the bridge module, while introduce more complexities in the VSI forwarding plane at the same time.

Daniel - not Rafi ;-)

[JYL] Wow, it's my fault! Thanks for your comments and your kindness.

Regards

Yuanlong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 PM
To: Rafi Ram
Cc: [email-masked]
Subject: S-VLAN access in E-Tree

Rafi and all,

Best regards,
Yuanlong

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 31 Mar 2011 10:57:32 +0200

Hi Yuanlong, please see inline with [DC].

[DC] Interfacing between carriers using VLAN handoff (SP interconnection on tagged AC) has the following drawbacks:

1.      Service scalability – each E-Tree service uses up two VLANs out of 4K VLAN range

2.      VID coordination – VLAN-ID X of carrier 1 may be already in use in carrier 2 network for different service

3.      End-to-end OAM – Assuming the carriers have MPLS network, VLAN handoff precludes the usage of MPLS end-to-end OAM tools  

[DC]  This assumption (“all leaf sites are connected to the 1st carrier) appears to conflict with “Service Provider Independence”. From L2VPN requirements :

   Customers MAY require L2VPN service that spans multiple

   administrative domains or SP networks.  Therefore, an L2VPN service

   MUST be able to span multiple AS and SP networks but still to act and

   to appear as a single, homogeneous L2VPN from a customer point of

   view.

   A customer might also start with an L2VPN provided in a single AS

   with a certain SLS but then ask for an expansion of the service

   spanning multiple ASes and/or multiple-SPs.  In this case, as well as

   for all kinds of multi-AS and multiple-SP L2VPNs, L2VPN service

   SHOULD be able to deliver the same SLS to all sites in a VPN

   regardless of the AS/SP to which it homes.

Daniel - not Rafi ;-)

Regards

Yuanlong

Rafi and all,

Best regards,

Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 31 Mar 2011 09:51:22 +0000

Daniel, the scenario we are discussing from the beginning is a "carrier over carrier" network with S-VLAN interface, for example, the 1st carrier is a provider network in accordance with IEEE 802.1ad, and the 2nd carrier is a VPLS network. This kind of network scenario exists today. The use case you described is another scenario, where a carrier peers with another carrier.

Further comments are inline.

发送时间: 2011年3月31日 16:57

[JYL] If local VLAN mapping is supported, the above 2 problem seems trivial. Furthermore, VPLS can extend the scalability of the E-Tree with appropriate PE models.

[JYL] As indicated above, the assumption of uniform MPLS network does not apply here.

Daniel - not Rafi ;-)

Regards

Yuanlong

Rafi and all,

Best regards,
Yuanlong

---

From: "S. Davari" <[email-masked]>
Date: Thu, 31 Mar 2011 07:36:09 -0700 (PDT)

Hi Daniel,

________________________________
From: Daniel Cohn <[email-masked]>
To: Jiangyuanlong <[email-masked]>
Cc: [email-masked]; Rafi Ram <[email-masked]>
Sent: Thu, March 31, 2011 1:57:32 AM
Subject: RE: S-VLAN access in E-Tree

发件人:Daniel Cohn [[email-masked]]
发送时间:2011年3月30日23:56
到:Jiangyuanlong
Cc: [email-masked]; Rafi Ram
主题:RE: S-VLAN access in E-Tree
Hi Yuanlong, thanks for your comments. Looking at the scenario you describe - if 
the second carrier is just doing transparent transport for the e-tree VPLS, from 
a scalability point of view it would make more sense to subtend the PW-VSIs 
directly between the e-tree-aware PEs, with the second carrier acting simply as 
PSN for these PWs.
[JYL]  Actually we are talking about the use case where carrier 1 attached to 
carrier 2 with a S-VLAN tagged AC. Your  use case is valid, but the service 
interface to carrier 2 is MPLS.
 
[DC] Interfacing between carriers using VLAN handoff (SP interconnection on 
tagged AC) has the following drawbacks:
1.      Service scalability – each E-Tree serviceuses up two VLANsout of 4K VLAN 
range
2.      VID coordination – VLAN-ID X of carrier 1 may be already in use in 
carrier 2 network for different service
3.      End-to-end OAM – Assuming the carriers have MPLS network, VLAN handoff 
precludes the usage of MPLS end-to-end OAM tools 

 SD> Actually MEF is using SVLAN at the E-NNI. I agree with the scalability 
issue. However the idea is to translate SVLAN at the ENNI. The End-to End OAM 
for E-Tree service which is Ethernet OAM works fine. The MPLS OAM is just 
protecting the Transport and does not need to be End-to-End. Each network can 
have its own independent Transport OAM.

Also, actually I’m not sure the scenario you describe is a valid one. If the 
second carrier is not e-tree aware, the e-tree VPLS won't comply with the e-tree 
requirements as stated in 
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-02 and 
http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-03, no matter what 
solution is adopted.
[JYL] Since all leaf sites are connected to the 1st carrier, assume all its 
network PEs can support E-Tree, then the 2nd carrier does not need to be E-Tree 
aware. But as a whole, the E-Tree requirements are fulfilled.
 
[DC]  This assumption (“all leaf sites are connected to the 1st carrier) appears 
to conflict with “Service Provider Independence”.From L2VPN requirements :

SD> I agree. There are 2 ways to do this. 1) Both networks can support E-Tree, 
which then we wont have a problem. 2) One network (network 2) does not support 
E-Tree. In this case that network 2 should just provide E-Line (VPWS) service 
for customers and connect them to network 2. Network 2 PE box now should do VFI 
switching (requires Hairpin switching).

Please note that adding VLAN tag for E-Tree functionality might be problematic 
to many implementations if the original frame already contains S-TAG/C-TAG or 
B-TAG.
[JYL] As I said before, global VLAN provisioning, VLAN mapping or transparently 
transport are all optional mechanisms for the above use cases. After all, the 
typical VPLS PE consists of a bridge module and one or more VSIs, no matter what 
is used to indicate root/leaf in a PW (PW, control word, or VLAN, etc.), we 
still need an Ethernet mechanism to support E-Tree access and filtering in the 
bridge module itself, IMHO, it should be based on IEEE standard rather than 
develop another wheel in our WG. Therefore, all other solutions need the same 
VLAN based mechanism in the bridge module, while introduce more complexities in 
the VSI forwarding plane at the same time.
 
Daniel - not Rafi ;-)
 
Regards
Yuanlong

From:[email-masked] [mailto:[email-masked]] On Behalf Of 
Jiangyuanlong
Sent: Wednesday, March 30, 2011 12:00 PM
To: Rafi Ram
Cc: [email-masked]
Subject: S-VLAN access in E-Tree
 
Rafi and all,
 
Yesterday we discussed the S-VLAN access of E-Tree during the WG meeting, in 
addition to S-VLAN mapping or B-VLAN method, a third option is also possible if 
it is a carrier over carrier network use case, that is, the E-Tree traffic from 
the 1st carrier can be transparently transported over the 2nd carrier's VPLS 
network, just as in the traditional VPLS. This seems more practical as the 
E-Tree topology is usually only known to the 1st carrier while unavailable to 
the 2nd carrier, furthermore, it requires no change on the 2nd carrier network.
 
Best regards,
Yuanlong