Subject: RE: L2VPN Minutes - IETF81 (Giles Heron)

From: [email-masked]
Date: Wed, 17 Aug 2011 09:57:38 +0800

Hi all,
Since VPLS has been widely deployed, backward compatible with existing 
VPLS-PE for E-Tree is very important, as also said in section 5.3 of 
draft-key-l2vpn-vpls-etree-reqt. Three VLAN (not 3 VLAN lookup) solution 
requires every PE in E-Tree network to be updated both software and 
hardwire (or microcode), and such new deployment will surely cost much.

Lizhong

> 
> 
> ------------------------------
> Date: Tue, 16 Aug 2011 12:37:45 -0500
> From: "Balus, Florin Stelian (Florin)"
>    <[email-masked]>
> To: Daniel Cohn <[email-masked]>, Jiangyuanlong
>    <[email-masked]>,   Giles Heron <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: RE: L2VPN Minutes - IETF81 (Giles Heron)
> Message-ID:
>    <[email-masked].
> alcatel-lucent.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> Daniel,
> 
> There are lots of service providers using different technologies 
> inside their network (QinQ, PBB and VPLS technologies). ENNI stands 
> for External Network Network Interface not usually used between 
> different technology domains. 
> 
> Also as I said in the IETF L2VPN session, one or two VLAN service 
> tag(s) are usually mapped at the border between domains to PW 
> service labels (for VPLS) or to ISIDs (for PBB) mainly because 
> service providers want to keep VLAN assignment independent between 
> different QinQ domains so that each can scale as close to 4K as 
possible.
> 
> This means that one or two tags are usually removed as you go in 
> other domains. So adding another one for ETREE does not impact the 
> number of VLANs being looked up in the PBB BEBs/VPLS PEs. 
> 
> Even if a transparent service does not touch the C/S VLANs in the 
> packet (e.g. the port is used to map to VSI) only the PW label/ISID 
> are used for VSI identification in VPLS PEs/PBB BEBs. There is no 3 
> VLAN look up required at any point in time.
> 
> Hence I think the procedure outlined below by Yuanlong will work 
> across all these different domains (QinQ-VPLS-PBB) saving us some 
> headaches of implementing and deploying two different procedures for
> the same service type. 
> 
> Florin
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Daniel Cohn
> Sent: Tuesday, August 16, 2011 6:43 AM
> To: Jiangyuanlong; Giles Heron
> Cc: [email-masked]
> Subject: RE: L2VPN Minutes - IETF81 (Giles Heron)
> 
> Hi,
> 
> That is precisely my point - there is no requirement to support E-Tree
> E-NNI, therefore the claim that "E-Tree services may cross both Ethernet
> and VPLS domains" is not supported by the requirements.
> 
> See inline with [DC] regarding your comments on PW pair solution.
> 
> Regards,
> 
> DC
> 
> -----Original Message-----
> From: Jiangyuanlong [mailto:[email-masked]] 
> Sent: Tuesday, August 16, 2011 4:59 AM
> To: Daniel Cohn; Giles Heron
> Cc: [email-masked]
> Subject: RE: L2VPN Minutes - IETF81 (Giles Heron)
> 
> Daniel,
> 
> MEF-26 does not include E-Tree E-NNI yet, maybe phase 2 will;)
> 
> In fact, we have multiple options to support E-Tree E-NNI if it is
> required:
> 1) Using two global S-VLANs for the E-Tree E-NNI and transparently
> connected them into the same VSI;
> 2) Using an extra E-Tree label (indicating root/leaf) under the PW
> label;
> 3) Using PBB encapsulation.
> Thus we don't need three VLANs or two PWs to make it work.
> 
> Using two PWs between a pair of PEs, may introduce loops as commented by
> Florin. 
> Further disadvantages of parallel PWs are also discussed in Sec. A.3 in
> draft-ietf-pwe3-packet-pw-01:
> 1) how to fate sharing of these PWs
> [DC] Fate sharing between data and OAM, as required by RFC 5921, is
> supported. I am not aware of a requirement for fate sharing across PWs.
> 2) how to provide OAM for these PWs
> [DC] As for any other PW (see e.g. draft-ietf-mpls-tp-oam-framework) -
> don't see the difference.
> 3) control plane and management plane complexity of multiple PWs working
> as a single PW.
> [DC] There's no requirement in the draft that the PWs should work as a
> single PW. 
> 
> Regards
> Yuanlong
> 
> 
> -----Original Message-----
> From: Daniel Cohn [mailto:[email-masked]] 
> Sent: Tuesday, August 16, 2011 6:42 AM
> To: Jiangyuanlong; Giles Heron
> Cc: [email-masked]
> Subject: RE: L2VPN Minutes - IETF81 (Giles Heron)
> 
> Hi Yuanlong and all,
> 
> S-VLAN preservation is specified by MEF-26 at E-NNI. Therefore if you
> want to support E-NNI between networks containing root and leaf UNIs
> (which again AFAIK is not part of MEF E-Tree requirements),
> draft-jiang/l2vpn-vpls-pe-etree requires three VLAN tags in the E-NNI
> (C-VLAN, S-VLAN and root/leaf VLAN). As we already discussed, there are
> several problems with triple-tagged Ethernet frames.
> 
> Regards,
> 
> Daniel
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jiangyuanlong
> Sent: Monday, August 15, 2011 5:26 AM
> To: Giles Heron
> Cc: [email-masked]
> Subject: RE: L2VPN Minutes - IETF81 (Giles Heron)
> 
> Hi Giles and all,
> 
> Sorry for this late comment, I had a holiday last week and had no access
> to the Internet.
> Though impossible to change the minutes, I think it needs to be
> re-clarified that S-VLAN encapsulation as UNI is not a requirement in
> MEF.
> 
> [Yuanlong] I think the 3 VLAN tags is out of scope of MEF itself.
> MEF defines C-VLAN and untagged access.  It's not a requirement of
> the MEF itself.
> 
> Correction:
> [Yuanlong] I think the S-VLAN tags is out of scope of MEF itself.
> MEF defines C-VLAN and untagged access.  It's not a requirement of
> the MEF itself.
> 
> 
> Thanks
> Yuanlong
> 
> ------------------------------------------------------------------------
> --
> From: Giles Heron <[email-masked]>
> To: <[email-masked]>
> Subject: L2VPN Minutes - IETF81
> Message-ID: <[email-masked]>
> Content-Type: text/plain;   charset="US-ASCII"
> 
> All,
> 
> The draft minutes from Quebec are available at:
>     http://www.ietf.org/proceedings/81/minutes/l2vpn.txt
> 
> Please review and comment to the list (or to the chairs) as soon as
> possible if you'd to see any corrections.  Changes can only be made
> until Friday so please get any comments in as soon as possible.
> 
> Many thanks to our minute takers: Alia Atlas and John Scudder
> 
> Nabil & Giles
> 
> 
> 
> 
> ------------------------------
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.