From sboutros@cisco.com Tue May 3 13:42:08 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC27E0800; Tue, 3 May 2011 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whnxEw0etNr5; Tue, 3 May 2011 13:42:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8897FE069B; Tue, 3 May 2011 13:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=585; q=dns/txt; s=iport; t=1304455327; x=1305664927; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=Htx7oqunPLSjs+1z7Lo1CBHG5zRDZUEkvKvnegHL2vs=; b=DsYR8+tc4oSh7tnBJYYNpkclBM5E3ba0yviVAiciAlf9VZ1XflKPILQA jEmoGpFUiHxXJi9UlLqgLnyVekdhXj6VN+n6gFgIgAclD+OV7DS1hjOBi 2pQnTuD5+u5cI3cBWrb1eMEEcGTejNPn1QqRus4lXcpjRBxSQ3gAWkXhi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEFowE2rRDoG/2dsb2JhbACHZJ44d6dTnQCGAgSGJY0Wii8 X-IronPort-AV: E=Sophos;i="4.64,311,1301875200"; d="scan'208";a="441073057" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 03 May 2011 20:42:07 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p43Kg6nD024408; Tue, 3 May 2011 20:42:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 13:42:07 -0700 Received: from sboutros-wxp02.ciswco.com ([171.71.139.235]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 13:42:06 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 May 2011 13:42:04 -0700 To: , l2vpn@ietf.org From: Sami Boutros Subject: draft-boutros-pwe3-mpls-tp-mac-wd-01 In-Reply-To: <7.1.0.9.0.20101123022725.069dedf0@cisco.com> References: <7.1.0.9.0.20101123022725.069dedf0@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 May 2011 20:42:06.0402 (UTC) FILETIME=[90CCBA20:01CC09D2] Cc: "Malis, Andrew G. \(Andy\)" , "Siva Sivabalan \(msiva\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 20:42:08 -0000 We have presented " MAC Address Withdrawal over Static Pseudowire " at IETF79 and 80 http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-01 This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. The authors are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list. Thanks, Sami From lizhong.jin@zte.com.cn Thu May 5 04:39:08 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48622E0752; Thu, 5 May 2011 04:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHgp-2scBarw; Thu, 5 May 2011 04:39:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 95012E06F2; Thu, 5 May 2011 04:39:06 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 125201974505403; Thu, 5 May 2011 19:37:22 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 62444.4876266596; Thu, 5 May 2011 19:26:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p45BcqB5041199; Thu, 5 May 2011 19:38:52 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: sboutros@cisco.com Subject: Re: [PWE3] draft-boutros-pwe3-mpls-tp-mac-wd-01 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Thu, 5 May 2011 19:38:54 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-05-05 19:38:54, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-05-05 19:38:54, Serialize complete at 2011-05-05 19:38:54, S/MIME Sign failed at 2011-05-05 19:38:54: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-05 19:38:55, Serialize complete at 2011-05-05 19:38:55 Content-Type: multipart/alternative; boundary="=_alternative 003FFC7A48257887_=" X-MAIL: mse02.zte.com.cn p45BcqB5041199 Cc: l2vpn@ietf.org, andrew.g.malis@verizon.com, pwe3@ietf.org, msiva@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 11:39:08 -0000 This is a multipart message in MIME format. --=_alternative 003FFC7A48257887_= Content-Type: text/plain; charset="US-ASCII" Hi Sami, Does the MAC address withdraw OAM message shares the same Associated Channel Type with PW OAM Message? I don't see the IANA assignment for this message in the draft. Other comments, see below. 4.1.2. Operation of Receiver Each PW is associated with a counter to keep track of the sequence number of the MAC withdrawal message received last. Whenever a MAC withdrawal message is received, and if the sequence number on the message is greater than the receive counter, the MAC address(es) contained in the MAC TLV(s) is/are removed, and the receive counter is incremented. The receiver sends an ACK whose sequence number is the same as the received message. [Lizhong] "greater than the receive counter" may not be the case, when PE receives the first MAC withdrawal message, the receiver counter would be empty. When the sequence number overflow, the receiver counter maybe greater that the sequence number. If the sequence number in the received message is smaller than or equal to the receive counter, the MAC TLV(s) is/are not processed. However, an ACK whose sequence number is the same as the received message is sent. [Lizhong] It would be better to define the range of valid sequence number, e.g, is "0" valid for the sequence number? Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 03 May 2011 13:42:04 -0700 > From: Sami Boutros > To: , l2vpn@ietf.org > Cc: "Malis, Andrew G. \(Andy\)" , "Siva > Sivabalan \(msiva\)" > Subject: [PWE3] draft-boutros-pwe3-mpls-tp-mac-wd-01 > Message-ID: > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > We have presented " > MAC Address Withdrawal over Static Pseudowire > " at IETF79 and 80 > http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-01 > > > This document specifies a mechanism to signal MAC address withdrawal > notification using PW Associated Channel (ACH). Such notification is > useful when statically provisioned PWs are deployed in VPLS/H-VPLS > environment. > > > The authors are seeking more feedback from the mailing list, and > would be grateful if you could review the document and post comments > on the mailing list. > > Thanks, > Sami > > --=_alternative 003FFC7 -------------------------------------------------------- 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. --=_alternative 003FFC7A48257887_= Content-Type: text/html; charset="US-ASCII"
Hi Sami,
Does the MAC address withdraw OAM message shares the same Associated Channel Type with PW OAM Message? I don't see the IANA assignment for this message in the draft. Other comments, see below.

4.1.2. Operation of Receiver

   Each PW is associated with a counter to keep track of the sequence
   number of the MAC withdrawal message received last. Whenever a MAC
   withdrawal message is received, and if the sequence number on the
   message is greater than the receive counter, the MAC address(es)
   contained in the MAC TLV(s) is/are removed, and the receive counter
   is incremented. The receiver sends an ACK whose sequence number is
   the same as the received message.
[Lizhong] "greater than the receive counter" may not be the case, when PE receives the first MAC withdrawal message, the receiver counter would be empty. When the sequence number overflow, the receiver counter maybe greater that the sequence number.

   If the sequence number in the received message is smaller than or
   equal to the receive counter, the MAC TLV(s) is/are not processed.
   However, an ACK whose sequence number is the same as the received
   message is sent.
[Lizhong] It would be better to define the range of valid sequence number, e.g, is "0" valid for the sequence number?


Regards
Lizhong



> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 03 May 2011 13:42:04 -0700
> From: Sami Boutros <sboutros@cisco.com>
> To: <pwe3@ietf.org>, l2vpn@ietf.org
> Cc: "Malis, Andrew G. \(Andy\)" <andrew.g.malis@verizon.com>,   "Siva
>    Sivabalan \(msiva\)" <msiva@cisco.com>
> Subject: [PWE3] draft-boutros-pwe3-mpls-tp-mac-wd-01
> Message-ID: <XFE-SJC-2115U9T3TGJ000000bc@xfe-sjc-211.amer.cisco.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>
> We have presented "
> MAC Address Withdrawal over Static Pseudowire
> " at IETF79 and 80
> http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-01
>
>
>     This document specifies a mechanism to signal MAC address withdrawal
>     notification using PW Associated Channel (ACH). Such notification is
>     useful when statically provisioned PWs are deployed in VPLS/H-VPLS
>     environment.
>
>
> The authors are seeking more feedback from the mailing list, and
> would be grateful if you could review the document and post comments
> on the mailing list.
>
> Thanks,
> Sami
>
> 
--------------------------------------------------------
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.
--=_alternative 003FFC7A48257887_=-- From sboutros@cisco.com Thu May 5 10:33:32 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB1E08F6; Thu, 5 May 2011 10:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvf71zpajn9r; Thu, 5 May 2011 10:33:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 501AEE08F5; Thu, 5 May 2011 10:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=9227; q=dns/txt; s=iport; t=1304616811; x=1305826411; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=OQTeeAW0kxb30zUf/LZDpedjFfn7mNuAXX+jQ6p/Q88=; b=bNiYqJSbBXCjDmPz6Z4QHmnAALDCiaXXznII9l+20pJ0bgfIg66HwBTO Cftx5Nh2o2dn5qYOZ53vLpSD7SIBTfy5Bexe/AuP6SnEuPwx9e7B8ljIF je0ZAFBhwhJhpPU/qKSPlMxJK2Tkl4kvjUhvblt3Krg4xtmRvOikOT2n7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFALnewk2rRDoI/2dsb2JhbACHY5cYAYdBd4hyng2ePYYHBIY4jT6KQw X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208,217";a="442461980" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 05 May 2011 17:33:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p45HXUEC019801; Thu, 5 May 2011 17:33:30 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 10:33:30 -0700 Received: from sboutros-wxp02.ciswco.com ([171.71.139.235]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 10:33:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 May 2011 10:28:30 -0700 To: lizhong.jin@zte.com.cn From: Sami Boutros Subject: Re: [PWE3] draft-boutros-pwe3-mpls-tp-mac-wd-01 In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6522640==.ALT" Message-ID: X-OriginalArrivalTime: 05 May 2011 17:33:29.0980 (UTC) FILETIME=[8C8343C0:01CC0B4A] Cc: l2vpn@ietf.org, andrew.g.malis@verizon.com, pwe3@ietf.org, msiva@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:33:32 -0000 --=====================_6522640==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Lizhong, Thanks for your comments. Please see comments inline. At 04:38 AM 5/5/2011, lizhong.jin@zte.com.cn wrote: >Hi Sami, > >Does the MAC address withdraw OAM message shares the same Associated >Channel Type with PW OAM Message? I don't see the IANA assignment >for this message in the draft. Other comments, see below. Sami: Correct it does. >4.1.2. Operation of Receiver > > Each PW is associated with a counter to keep track of the sequence > number of the MAC withdrawal message received last. Whenever a MAC > withdrawal message is received, and if the sequence number on the > message is greater than the receive counter, the MAC address(es) > contained in the MAC TLV(s) is/are removed, and the receive counter > is incremented. The receiver sends an ACK whose sequence number is > the same as the received message. >[Lizhong] "greater than the receive counter" may not be the case, >when PE receives the first MAC withdrawal message, the receiver >counter would be empty. When the sequence number overflow, the >receiver counter maybe greater that the sequence number. Sami: We will update this section in next Rev to specify the handling and the meaning of 0 counters and to work around cases of wrapping counters. > If the sequence number in the received message is smaller than or > equal to the receive counter, the MAC TLV(s) is/are not processed. > However, an ACK whose sequence number is the same as the received > message is sent. >[Lizhong] It would be better to define the range of valid sequence >number, e.g, is "0" valid for the sequence number? Sami: Agreed as per above. Thanks, Sami >Regards >Lizhong > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 03 May 2011 13:42:04 -0700 > > From: Sami Boutros > > To: , l2vpn@ietf.org > > Cc: "Malis, Andrew G. \(Andy\)" , "Siva > > Sivabalan \(msiva\)" > > Subject: [PWE3] draft-boutros-pwe3-mpls-tp-mac-wd-01 > > Message-ID: > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > > > We have presented " > > MAC Address Withdrawal over Static Pseudowire > > " at IETF79 and 80 > > http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-01 > > > > > > This document specifies a mechanism to signal MAC address withdrawal > > notification using PW Associated Channel (ACH). Such notification is > > useful when statically provisioned PWs are deployed in VPLS/H-VPLS > > environment. > > > > > > The authors are seeking more feedback from the mailing list, and > > would be grateful if you could review the document and post comments > > on the mailing list. > > > > Thanks, > > Sami > > > > > > >-------------------------------------------------------- >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. --=====================_6522640==.ALT Content-Type: text/html; charset="us-ascii" Hi Lizhong,

Thanks for your comments. Please see comments inline.
At 04:38 AM 5/5/2011, lizhong.jin@zte.com.cn wrote:

Hi Sami,

Does the MAC address withdraw OAM message shares the same Associated Channel Type with PW OAM Message? I don't see the IANA assignment for this message in the draft. Other comments, see below.

Sami: Correct it does.

4.1.2. Operation of Receiver

   Each PW is associated with a counter to keep track of the sequence
   number of the MAC withdrawal message received last. Whenever a MAC
   withdrawal message is received, and if the sequence number on the
   message is greater than the receive counter, the MAC address(es)
   contained in the MAC TLV(s) is/are removed, and the receive counter
   is incremented. The receiver sends an ACK whose sequence number is
   the same as the received message.
[Lizhong] "greater than the receive counter" may not be the case, when PE receives the first MAC withdrawal message, the receiver counter would be empty. When the sequence number overflow, the receiver counter maybe greater that the sequence number.

Sami: We will update this section in next Rev to specify the handling and the meaning of 0 counters and to work around cases of wrapping counters.


   If the sequence number in the received message is smaller than or
   equal to the receive counter, the MAC TLV(s) is/are not processed.
   However, an ACK whose sequence number is the same as the received
   message is sent.
[Lizhong] It would be better to define the range of valid sequence number, e.g, is "0" valid for the sequence number?

Sami: Agreed as per above.

Thanks,

Sami


Regards
Lizhong



> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 03 May 2011 13:42:04 -0700
> From: Sami Boutros <sboutros@cisco.com>
> To: <pwe3@ietf.org>, l2vpn@ietf.org
> Cc: "Malis, Andrew G. \(Andy\)" <andrew.g.malis@verizon.com>,   "Siva
>    Sivabalan \(msiva\)" <msiva@cisco.com>
> Subject: [PWE3] draft-boutros-pwe3-mpls-tp-mac-wd-01
> Message-ID: <XFE-SJC-2115U9T3TGJ000000bc@xfe-sjc-211.amer.cisco.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>
> We have presented "
> MAC Address Withdrawal over Static Pseudowire
> " at IETF79 and 80
> http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-01
>
>
>     This document specifies a mechanism to signal MAC address withdrawal
>     notification using PW Associated Channel (ACH). Such notification is
>     useful when statically provisioned PWs are deployed in VPLS/H-VPLS
>     environment.
>
>
> The authors are seeking more feedback from the mailing list, and
> would be grateful if you could review the document and post comments
> on the mailing list.
>
> Thanks,
> Sami
>
> 

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

--=====================_6522640==.ALT-- From nabil.n.bitar@verizon.com Sun May 8 08:34:23 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5771E068C for ; Sun, 8 May 2011 08:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk3exghNU8dz for ; Sun, 8 May 2011 08:34:19 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfa.amsl.com (Postfix) with ESMTP id B394FE06DC for ; Sun, 8 May 2011 08:34:18 -0700 (PDT) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p48FYFhO016510 for ; Sun, 8 May 2011 11:34:15 -0400 (EDT) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.64,335,1301875200"; d="scan'208,217";a="45943985" Received: from fldp1lumxc7hb04.verizon.com (HELO FLDP1LUMXC7HB04.us.one.verizon.com) ([166.68.75.83]) by fldsmtpi01.verizon.com with ESMTP; 08 May 2011 15:34:14 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:4b53::a644:4b53]) with mapi; Sun, 8 May 2011 11:34:14 -0400 To: Benson Schliesser , "Shah, Himanshu" , Thomas Nadeau , Giles Heron Date: Sun, 8 May 2011 11:34:12 -0400 Subject: Re: Draft of new L2VPN WG Charter Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiwePAAI/U3QHTQhEmQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9EB205A1543Enabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 15:34:23 -0000 --_000_C9EB205A1543Enabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As we are working to firming up the charter, I think it will be good to add= ress the questions raised in this thread. I am hearing question about the i= ntention of that second sentence mentioned more than opposition to it. We are still addressing provider-provisioned L2VPN. However, nothing restri= cts the environment that this gets used in. For instance, if there is value= to expand l2vpn such as VPLS into the data center, would that be excluded?= I am not judging that there is value or not. If there are new requirements= that drive additional solutions, should they be excluded? In addition, Data center and data center interconnects in a cloud could b= ring requirements to interconnect technologies that we had not looked at be= fore in the l2vpn WG. Certainly, a data center layer2 network can be based= on Trill or 802.1aq as examples which we had not covered before in additio= n to 802.1ad or PBB . If there are requirements to interconnect data cen= ters using these technologies, l2vpn-solutions may be needed (and if needed= drafts will show up). These are examples and are not to restrict the type= s of requirements. There are already drafts driven from data center and clo= ud viewpoint that have been brought in by folks. Could we live without the = sentence in question? Probably yes. However, calling out explicitly that so= lutions that address data center and cloud requirements as they apply to l2= vpn are within the l2vpn WG charter adds more clarity to what we could be t= aking on upfront. We all know based on industry activities, that is an area= of interest, and there have been already drafts brought to the l2vpn WG dr= iven by that although some were not layer2-based. For that reason also, I t= hink calling it out as in the draft charter points out that only L2 will be= addressed by the l2vpn WG, which may seem like calling out the obvious. Thanks, Nabil On 3/31/11 12:18 PM, "Benson Schliesser" wrote: Speaking as ARMD co-chair: Solution development is not in our charter, but= analysis of existing solutions (and identification of gaps) is. If we ide= ntify gaps, then ARMD might be re-chartered to develop solutions - or we mi= ght send our requirements into other WGs for development. This is TBD pend= ing our work on the Problem Statement. Speaking personally: I don't have any objection to L2VPN working on data ce= nter solutions. If somebody deploys e.g. VPLS inside an enterprise network= , provider data center, provider metro network, etc, I think these are all = valid use-cases. This is why I asked my question about the 2nd sentence - = it seems redundant. Cheers, -Benson On 3/31/11 10:21 AM, "Shah, Himanshu" wrote: My understanding is that, as a first step, the problem scope needs to be understood. Solutions, if any required, could follow only after the problem is well understood. Solutions are part of ARMD charter but only after first step is completed. Although, it appears that L2VPN group has already acknowledged and understood the problem well enough to propose solutions?? /himanshu -----Original Message----- From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau Sent: Thu 3/31/2011 10:57 AM To: Giles Heron Cc: l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: > Hi Benson, > > This would be provider-provisioned L2VPN environments (whether data-centr= e > interconnect, or scaling of a large multi-tenant data-centre). > > Personally I'm not sure we need the sentence there, but others were keen = to > mention the data-centre requirements. I think that is meant to explicitly field requirements for solution= s that come from ARMD/etc... into the WG, since they cannot build their own solutions. While that isn't implicitly handled in the existing charter, I do not know either. --Tom > > Giles > > On 31/03/2011 15:37, "Benson Schliesser" wrote: > >> Hi, Giles. >> >> I have a clarifying question about the first paragraph: What is the pur= pose >> of the 2nd sentence, bringing cloud and DC requirements into the mix? >> Assuming this is meant to include non-provider L2VPN environments (like >> enterprise data centers), then why not just remove the phrase >> "provider-provisioned" from the first sentence? Otherwise, it seems >> redundant. >> >> This is a real question, not a suggestion at this time. >> >> Thanks, >> -Benson >> >> >> >> On 3/18/11 1:21 PM, "Giles Heron" wrote: >> >>> OK - looks like the attachment didn't come through as intended. My >>> apologies. >>> >>> Text inline: >>> >>> ---------------- >>> >>> The L2VPN working group is responsible for defining and specifying a >>> limited number of solutions for supporting provider-provisioned Layer-2 >>> Virtual Private Networks (L2VPNs). It will also address requirements dr= iven >>> by cloud computing services and data centers as they apply to Layer-2 >>> VPN services. >>> >>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>> "native" service over a PSN that is adequately faithful to, but may not >>> be entirely indistinguishable from the native service itself. Further, >>> following in the "edge-to-edge" nature of the service, the L2VPN WG wi= ll >>> not define any mechanisms which exert control over the underlying PSN. >>> When necessary it may, however, recommend or require the use of existin= g >>> PSN QoS and path control mechanisms between the PEs which provide the >>> L2VPN connectivity. >>> >>> Layer-2 VPNs comprise the following: >>> >>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulate= s >>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN)= . >>> >>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>> provides point-to-point connectivity for a variety of link layers, >>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>> >>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that >>> provides point-to-multipoint connectivity for a variety of link >>> layers across an MPLS PSN. >>> >>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG will >>> address two specific types of IP-only L2VPN: >>> >>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but al= so >>> supports heterogenous Attachment Circuits at either end of a single >>> point-to-point service. >>> >>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VP= LS, >>> but learns IP and MAC address bindings from ARPs and broadcast/multicas= t >>> IP packets. >>> >>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across >>> multiple connections from a Layer-2 site to an L2VPN service, and also >>> supports control plane distribution of MAC addresses and IP to MAC addr= ess >>> bindings in the VPN. E-VPN is primarily targeted to support large-scale >>> L2VPNs with resiliency requirements not satisfied by other L2VPN soluti= ons. >>> >>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides >>> connectivity between one or more "root" nodes and one or more >>> "leaf" nodes, with the restriction that leaves may only communicate >>> with roots (and not with each other). >>> >>> L2VPNs will make use of existing IETF specified mechanisms unless there >>> are technical reasons why the existing mechanisms are insufficient or >>> unnecessary. >>> >>> The L2VPN WG is responsible for specification of the discovery and >>> membership of PEs participating in a Layer-2 VPN as well as the >>> membership of CE devices for a specific instance of an L2VPN. >>> >>> The L2VPN WG will provide extensions of existing protocols that will be >>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>> may define extensions to pseudowire management mechanisms for VPLS. >>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>> aligned with the overall design/architecture of PWE3. >>> >>> The L2VPN WG will not define new encapsulations, control, or resiliency >>> mechanisms specifically related to pseudowires. Furthermore, when the >>> L2VPN solution is based on PWs, the L2VPN WG will not define protocol >>> inter-working between an L2VPN and native service Layer-2 OAM or >>> resiliency mechanisms. The L2VPN WG may define how to operate native >>> service-layer control, OAM or resiliency mechanisms on top of an L2VPN. >>> In addition, it may define native data plane and/or control plane >>> interworking between an L2VPN and an associated native Layer-2 service. >>> >>> The L2VPN WG scope includes the following: >>> >>> 1. Discovery of PEs participating in a Layer-2 VPN and the associated >>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>> service. >>> >>> 2. Signaling of information related to the discovery and membership of >>> PEs within a L2VPN. These procedures must use PWE3 control and >>> management procedures, or define requirements for extensions of PWE3 >>> protocols to suit the needs of an L2VPN, when the L2VPN operates over >>> PWs. Once those requirements have been reviewed by the L2VPN WG, they >>> should be provided to the PWE3 WG to derive solutions. >>> >>> 3. MIBs for Layer-2 VPN solutions. >>> >>> 4. Specification of requirements, framework and solutions that >>> facilitate Operations Administration and Management (OAM) of any type o= f >>> L2VPN. >>> >>> 5. Mechanisms to permit optimization of multicast data traffic within >>> an L2VPN. >>> >>> 6. If transport does not involve PWs, mechanisms that support >>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>> service using an L2VPN across the MPLS PSN. >>> >>> 7. requirements for the multi-homing of CEs to several VPLS or >>> E-VPN PEs, inclusive of active/backup and active/active (load-sharing) >>> configurations. Based on these requirements define VPLS or E-VPN contro= l >>> plane solutions for achieving fast convergence after failure of an acti= ve >>> path in the PSN or on the AC side. >>> >>> 8. Enhancements to increase the scalability of the Control Plane and >>> Data Plane of L2VPN PE nodes, and of core nodes that provide transport >>> services for L2VPN. >>> >>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>> Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimi= zed >>> L2VPNs. >>> >>> 10. Requirements and solutions for supporting "E-Tree" services using >>> VPLS. >>> >>> 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS >>> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinate= d >>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that = are >>> chartered to do MPLS TP work. >>> >>> Milestones: >>> >>> Done Submit an I-D describing MIB for VPLS >>> Done Submit an I-D describing MIB for VPWS >>> Done Submit an I-D on OAM requirements for VPLS >>> Done Submit an I-D on OAM requirements for VPWS >>> Done Submit L2 requirements to IESG for publication as Informati= onal >>> RFC >>> Done Submit L2 framework to IESG for publication as Informationa= l RFC >>> Done Identify VPLS and VPWS solutions for the WG >>> Done Submit VPLS solution documents to IESG >>> Done Submit VPWS solution documents to IESG >>> Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-= AS >>> VPLS and VPWS Layer-2 VPNs >>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>> Jul 2011 Submit OAM solutions for VPWS to IESG >>> Jul 2011 Submit OAM solutions for VPLS to IESG >>> Jul 2011 Submit signaling solution for multicast-optimized VPLS to I= ESG >>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>> requirements to IESG >>> Jul 2011 Submit MIB for VPLS to IESG >>> Jul 2011 Submit MIB for VPWS to IESG >>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG >>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>> Mar 2012 Submit VPLS service convergence improvement solutions to IE= SG >>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>> Mar 2012 Submit E-Tree documents to IESG >>> Mar 2012 Submit E-VPN requirements/framework to IESG >>> Jul 2012 Submit E-VPN solution to IESG >>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>> >>> ----------------- >>> >>> On 18/03/2011 17:41, "Giles Heron" wrote: >>> >>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tr= ee >>>> in-scope. >>>> >>>> Please find attached a draft charter for discussion both on this list = and at >>>> IETF 80 in Prague. >>>> >>>> Nabil and Giles >>>> >>>> >>> >>> >> > > > --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 60 Sylvan Road Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C9EB205A1543Enabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Draft of new L2VPN WG Charter Hi,
As we are working to firming up the charter, I think it will be good to add= ress the questions raised in this thread. I am hearing question about the i= ntention of that second sentence mentioned more than opposition to it.
We are still addressing provider-provisioned L2VPN. However, nothing restri= cts the environment that this gets used in. For instance, if there is value= to expand l2vpn such as VPLS into the data center, would that be excluded?= I am not judging that there is value or not. If there are new requirements= that drive additional solutions, should they be excluded?
In addition,  Data center and data center interconnects in a cloud &nb= sp;could bring requirements to interconnect technologies that we had not lo= oked at before in  the l2vpn WG. Certainly, a data center layer2 netwo= rk can be based on Trill or 802.1aq as examples which we had not covered be= fore in addition to 802.1ad or  PBB .   If there are require= ments to interconnect data centers using these technologies, l2vpn-solution= s may be needed (and if needed drafts will show up).  These are exampl= es and are not to restrict the types of requirements. There are already dra= fts driven from data center and cloud viewpoint that have been brought in b= y folks. Could we live without the sentence in question? Probably yes. Howe= ver, calling out explicitly that solutions that address data center and clo= ud requirements as they apply to l2vpn are within the l2vpn WG charter adds= more clarity to what we could be taking on upfront. We all know based on i= ndustry activities, that is an area of interest, and there have been alread= y drafts brought to the l2vpn WG driven by that although some were not laye= r2-based. For that reason also, I think calling it out as in the draft char= ter points out that only L2 will be addressed by the l2vpn WG, which may se= em like calling out the obvious.   

Thanks,
Nabil

On 3/31/11 12:18 PM, "Benson Schliesser" <bschlies@cisco.com> wrote:

Speaking as ARMD co-chair:  Solution d= evelopment is not in our charter, but analysis of existing solutions (and i= dentification of gaps) is.  If we identify gaps, then ARMD might be re= -chartered to develop solutions – or we might send our requirements i= nto other WGs for development.  This is TBD pending our work on the Pr= oblem Statement.

Speaking personally: I don’t have any objection to L2VPN working on d= ata center solutions.  If somebody deploys e.g. VPLS inside an enterpr= ise network, provider data center, provider metro network, etc, I think the= se are all valid use-cases.  This is why I asked my question about the= 2nd sentence – it seems redundant.

Cheers,
-Benson


On 3/31/11 10:21 AM, "Shah, Himanshu" <hshah@ciena.com> wrote:

My understanding is that, as a first step, = the problem
scope needs to be understood. Solutions, if any required,
could follow only after the problem is well understood.
Solutions are part of ARMD charter but only after first step
is completed.

Although, it appears that L2VPN group has already acknowledged
and understood the problem well enough to propose solutions??

/himanshu


-----Original Message-----
From: l2vpn-bounces@ietf.org on beha= lf of Thomas Nadeau
Sent: Thu 3/31/2011 10:57 AM
To: Giles Heron
Cc: l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter


On Mar 31, 2011, at 10:49 AM, Giles Heron wrote:

> Hi Benson,
>
> This would be provider-provisioned L2VPN environments (whether data-ce= ntre
> interconnect, or scaling of a large multi-tenant data-centre).
>
> Personally I'm not sure we need the sentence there, but others were ke= en to
> mention the data-centre requirements.

        I think that is meant to ex= plicitly field requirements for solutions
that come from ARMD/etc... into the WG, since they cannot build their own solutions.  While that isn't implicitly handled in the existing charte= r, I
do not know either.

        --Tom


>
> Giles
>
> On 31/03/2011 15:37, "Benson Schliesser" <bschlies@cisco.com> wrote:
>
>> Hi, Giles.
>>
>> I have a clarifying question about the first paragraph:  What= is the purpose
>> of the 2nd sentence, bringing cloud and DC requirements into the m= ix?
>> Assuming this is meant to include non-provider L2VPN environments = (like
>> enterprise data centers), then why not just remove the phrase
>> "provider-provisioned" from the first sentence?  Ot= herwise, it seems
>> redundant.
>>
>> This is a real question, not a suggestion at this time.
>>
>> Thanks,
>> -Benson
>>
>>
>>
>> On 3/18/11 1:21 PM, "Giles Heron" <giles.heron@gmail.com> wrote:
>>
>>> OK - looks like the attachment didn't come through as intended= .  My
>>> apologies.
>>>
>>> Text inline:
>>>
>>> ----------------
>>>
>>> The L2VPN working group is responsible for defining and specif= ying a
>>> limited number of solutions for supporting provider-provisione= d Layer-2
>>> Virtual Private Networks (L2VPNs). It will also address requir= ements driven
>>> by cloud computing services and data centers as they apply to = Layer-2
>>> VPN services.
>>>
>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) a= s
>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emula= tes a
>>> "native" service over a PSN that is adequately faith= ful to, but may not
>>> be entirely indistinguishable from the native service itself. = Further,
>>> following in the "edge-to-edge" nature of the  = service, the L2VPN WG will
>>> not define any mechanisms which exert control over the underly= ing PSN.
>>> When necessary it may, however, recommend or require the use o= f existing
>>> PSN QoS and path control mechanisms between the PEs which prov= ide the
>>> L2VPN connectivity.
>>>
>>> Layer-2 VPNs comprise the following:
>>>
>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service tha= t emulates
>>> a switched Ethernet (V)LAN across an MPLS Packet Switched Netw= ork (PSN).
>>>
>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service th= at
>>> provides point-to-point connectivity for a variety of link lay= ers,
>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPL= S PSN.
>>>
>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 servi= ce that
>>> provides point-to-multipoint connectivity for a variety of lin= k
>>> layers across an MPLS PSN.
>>>
>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN.  = The WG will
>>> address two specific types of IP-only L2VPN:
>>>
>>> a) Point-to-point Layer-2 VPN.  This service is similar t= o VPWS, but also
>>> supports heterogenous Attachment Circuits at either end of a s= ingle
>>> point-to-point service.
>>>
>>> b) Multipoint-to-multipoint Layer-2 VPN.  This service is= similar to VPLS,
>>> but learns IP and MAC address bindings from ARPs and broadcast= /multicast
>>> IP packets.
>>>
>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates a= n
>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharin= g across
>>> multiple connections from a Layer-2 site to an L2VPN service, = and also
>>> supports control plane distribution of MAC addresses and IP to= MAC address
>>> bindings in the VPN. E-VPN is primarily targeted to support la= rge-scale
>>> L2VPNs with resiliency requirements not satisfied by other L2V= PN solutions.
>>>
>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which pro= vides
>>> connectivity between one or more "root" nodes and on= e or more
>>> "leaf" nodes, with the restriction that leaves may o= nly communicate
>>> with roots (and not with each other).
>>>
>>> L2VPNs will make use of existing IETF specified mechanisms unl= ess there
>>> are technical reasons why the existing mechanisms are insuffic= ient or
>>> unnecessary.
>>>
>>> The L2VPN WG is responsible for specification of the discovery= and
>>> membership of PEs participating in a Layer-2 VPN as well as th= e
>>> membership of CE devices for a specific instance of an L2VPN.<= BR> >>>
>>> The L2VPN WG will provide extensions of existing protocols tha= t will be
>>> discussed in protocol-specific WGs. In particular, the L2VPN W= G
>>> may define extensions to pseudowire management mechanisms for = VPLS.
>>> Those extensions will be reviewed by the PWE3 WG to ensure the= y are
>>> aligned with the overall design/architecture of PWE3.
>>>
>>> The L2VPN WG will not define new encapsulations, control, or r= esiliency
>>> mechanisms specifically related to pseudowires. Furthermore, w= hen the
>>> L2VPN solution is based on PWs, the L2VPN WG will not define p= rotocol
>>> inter-working between an L2VPN and native service Layer-2 OAM = or
>>> resiliency mechanisms. The L2VPN WG may define how to operate = native
>>> service-layer control, OAM or resiliency mechanisms on top of = an L2VPN.
>>> In addition, it may define native data plane and/or control pl= ane
>>> interworking between an L2VPN and an associated native Layer-2= service.
>>>
>>> The L2VPN WG scope includes the following:
>>>
>>> 1. Discovery of PEs participating in a Layer-2 VPN and the ass= ociated
>>> topology required for connectivity of the VPLS, VPWS, VPMS or = E-VPN
>>> service.
>>>
>>> 2. Signaling of information related to the discovery and membe= rship of
>>> PEs within a L2VPN. These procedures must use PWE3 control and=
>>> management procedures, or define requirements for extensions o= f PWE3
>>> protocols to suit the needs of an L2VPN, when the L2VPN operat= es over
>>> PWs. Once those requirements have been reviewed by the L2VPN W= G, they
>>> should be provided to the PWE3 WG to derive solutions.
>>>
>>> 3. MIBs for Layer-2 VPN solutions.
>>>
>>> 4. Specification of requirements, framework and solutions that=
>>> facilitate Operations Administration and Management (OAM) of a= ny type of
>>> L2VPN.
>>>
>>> 5. Mechanisms to permit optimization of multicast data traffic= within
>>> an L2VPN.
>>>
>>> 6. If transport does not involve PWs, mechanisms that support<= BR> >>> load-balancing/multipathing between PEs interconnecting a Laye= r-2
>>> service using an L2VPN across the MPLS PSN.
>>>
>>> 7. requirements for the multi-homing of CEs to several VPLS or=
>>> E-VPN PEs, inclusive of active/backup and active/active (load-= sharing)
>>> configurations. Based on these requirements define VPLS or E-V= PN control
>>> plane solutions for achieving fast convergence after failure o= f an active
>>> path in the PSN or on the AC side.
>>>
>>> 8. Enhancements to increase the scalability of the Control Pla= ne and
>>> Data Plane of L2VPN PE nodes, and of core nodes that provide t= ransport
>>> services for L2VPN.
>>>
>>> 9. Requirements and solutions for Auto-Discovery and Signaling= of
>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for multica= st-optimized
>>> L2VPNs.
>>>
>>> 10. Requirements and solutions for supporting "E-Tree&quo= t; services using
>>> VPLS.
>>>
>>> 11. Extensions to L2VPN protocols and RFCs necessary to create= an MPLS
>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be c= oordinated
>>> between four primary working groups (MPLS, PWE3, L2VPN and CCA= MP) that are
>>> chartered to do MPLS TP work.
>>>
>>> Milestones:
>>>
>>> Done        Submit an I-D d= escribing MIB for VPLS
>>> Done        Submit an I-D d= escribing MIB for VPWS
>>> Done        Submit an I-D o= n OAM requirements for VPLS
>>> Done        Submit an I-D o= n OAM requirements for VPWS
>>> Done        Submit L2 requi= rements to IESG for publication as Informational
>>> RFC
>>> Done        Submit L2 frame= work to IESG for publication as Informational RFC
>>> Done        Identify VPLS a= nd VPWS solutions for the WG
>>> Done        Submit VPLS sol= ution documents to IESG
>>> Done        Submit VPWS sol= ution documents to IESG
>>> Done        Submit Auto-Dis= covery and Signaling for Intra-AS and Inter-AS
>>>           &n= bsp;VPLS and VPWS Layer-2 VPNs
>>> Jul 2011    Submit IP-only L2VPN solution docum= ents to IESG
>>> Jul 2011    Submit OAM solutions for VPWS to IE= SG
>>> Jul 2011    Submit OAM solutions for VPLS to IE= SG
>>> Jul 2011    Submit signaling solution for multi= cast-optimized VPLS to IESG
>>> Jul 2011    Submit I-D on Virtual Private Multi= cast Service (VPMS)
>>>           &n= bsp;requirements to IESG
>>> Jul 2011    Submit MIB for VPLS to IESG
>>> Jul 2011    Submit MIB for VPWS to IESG
>>> Nov 2011    Submit scalability solutions for VP= LS Data-Plane to IESG
>>> Nov 2011    Submit scalability solutions for VP= LS Control-Plane to IESG
>>> Mar 2012    Submit MIB for IP-only L2VPN to IES= G
>>> Mar 2012    Submit OAM solutions for IP-only L2= VPN to IESG
>>> Mar 2012    Submit Auto-Discovery solution for = VPMS to IESG
>>> Mar 2012    Submit VPLS service convergence imp= rovement solutions to IESG
>>> Mar 2012    Submit VPLS multi-homing solutions = to IESG
>>> Mar 2012    Submit E-Tree documents to IESG
>>> Mar 2012    Submit E-VPN requirements/framework= to IESG
>>> Jul 2012    Submit E-VPN solution to IESG
>>> Nov 2012    Submit E-VPN MIB/OAM to IESG
>>>
>>> -----------------
>>>
>>> On 18/03/2011 17:41, "Giles Heron" <giles.heron@gmail.com> wrote:
>>>
>>>> We plan to re-charter the L2VPN WG - primarily to bring E-= VPN and E-Tree
>>>> in-scope.
>>>>
>>>> Please find attached a draft charter for discussion both o= n this list and at
>>>> IETF 80 in Prague.
>>>>
>>>> Nabil and Giles
>>>>
>>>>
>>>
>>>
>>
>
>
>



X-IronPort-AV: E=Sophos;i="4.64,335,1301875200"; d="scan'208,217";a="45993360" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi02.verizon.com with ESMTP; 08 May 2011 15:34:20 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([fe80::303e:41f6:bcf4:d607]) by FLDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:4b55::a644:4b55]) with mapi; Sun, 8 May 2011 11:34:20 -0400 To: "Shah, Himanshu" , Thomas Nadeau , Giles Heron Date: Sun, 8 May 2011 11:34:19 -0400 Subject: Re: Draft of new L2VPN WG Charter Thread-Topic: Draft of new L2VPN WG Charter Thread-Index: AcvvtA2JzqTxhFkJSFamDqHmBDPKfwAAiwePB0+lBX0= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9EB22CD15440nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 15:34:41 -0000 --_000_C9EB22CD15440nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Himanshu, Please see inlime. Thanks, Nabil On 3/31/11 11:21 AM, "Shah, Himanshu" wrote: My understanding is that, as a first step, the problem scope needs to be understood. Solutions, if any required, could follow only after the problem is well understood. Solutions are part of ARMD charter but only after first step is completed. This applies to ARMD. Although, it appears that L2VPN group has already acknowledged and understood the problem well enough to propose solutions?? I am not sure that is being said or it could be construed from the pro= posed WG charter. Addressing data center requirements (which define the pro= blems and could be brought into the l2vpn WG or the Ops group) as they appl= y to l2vpn is what is proposed to be in the WG charter. One may ask how do= we know there are any. There are already drafts being brought in driven by= that as I mentioned in the other email. Given the activities areas we may = want to call it out explicitly and restrict it to l2vpn. /himanshu -----Original Message----- From: l2vpn-bounces@ietf.org on behalf of Thomas Nadeau Sent: Thu 3/31/2011 10:57 AM To: Giles Heron Cc: l2vpn@ietf.org Subject: Re: Draft of new L2VPN WG Charter On Mar 31, 2011, at 10:49 AM, Giles Heron wrote: > Hi Benson, > > This would be provider-provisioned L2VPN environments (whether data-centr= e > interconnect, or scaling of a large multi-tenant data-centre). > > Personally I'm not sure we need the sentence there, but others were keen = to > mention the data-centre requirements. I think that is meant to explicitly field requirements for solution= s that come from ARMD/etc... into the WG, since they cannot build their own solutions. While that isn't implicitly handled in the existing charter, I do not know either. --Tom > > Giles > > On 31/03/2011 15:37, "Benson Schliesser" wrote: > >> Hi, Giles. >> >> I have a clarifying question about the first paragraph: What is the pur= pose >> of the 2nd sentence, bringing cloud and DC requirements into the mix? >> Assuming this is meant to include non-provider L2VPN environments (like >> enterprise data centers), then why not just remove the phrase >> "provider-provisioned" from the first sentence? Otherwise, it seems >> redundant. >> >> This is a real question, not a suggestion at this time. >> >> Thanks, >> -Benson >> >> >> >> On 3/18/11 1:21 PM, "Giles Heron" wrote: >> >>> OK - looks like the attachment didn't come through as intended. My >>> apologies. >>> >>> Text inline: >>> >>> ---------------- >>> >>> The L2VPN working group is responsible for defining and specifying a >>> limited number of solutions for supporting provider-provisioned Layer-2 >>> Virtual Private Networks (L2VPNs). It will also address requirements dr= iven >>> by cloud computing services and data centers as they apply to Layer-2 >>> VPN services. >>> >>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as >>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a >>> "native" service over a PSN that is adequately faithful to, but may not >>> be entirely indistinguishable from the native service itself. Further, >>> following in the "edge-to-edge" nature of the service, the L2VPN WG wi= ll >>> not define any mechanisms which exert control over the underlying PSN. >>> When necessary it may, however, recommend or require the use of existin= g >>> PSN QoS and path control mechanisms between the PEs which provide the >>> L2VPN connectivity. >>> >>> Layer-2 VPNs comprise the following: >>> >>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulate= s >>> a switched Ethernet (V)LAN across an MPLS Packet Switched Network (PSN)= . >>> >>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that >>> provides point-to-point connectivity for a variety of link layers, >>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. >>> >>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that >>> provides point-to-multipoint connectivity for a variety of link >>> layers across an MPLS PSN. >>> >>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN. The WG will >>> address two specific types of IP-only L2VPN: >>> >>> a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but al= so >>> supports heterogenous Attachment Circuits at either end of a single >>> point-to-point service. >>> >>> b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VP= LS, >>> but learns IP and MAC address bindings from ARPs and broadcast/multicas= t >>> IP packets. >>> >>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates an >>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across >>> multiple connections from a Layer-2 site to an L2VPN service, and also >>> supports control plane distribution of MAC addresses and IP to MAC addr= ess >>> bindings in the VPN. E-VPN is primarily targeted to support large-scale >>> L2VPNs with resiliency requirements not satisfied by other L2VPN soluti= ons. >>> >>> 6. E-Tree - a Layer-2 technology defined by the MEF, which provides >>> connectivity between one or more "root" nodes and one or more >>> "leaf" nodes, with the restriction that leaves may only communicate >>> with roots (and not with each other). >>> >>> L2VPNs will make use of existing IETF specified mechanisms unless there >>> are technical reasons why the existing mechanisms are insufficient or >>> unnecessary. >>> >>> The L2VPN WG is responsible for specification of the discovery and >>> membership of PEs participating in a Layer-2 VPN as well as the >>> membership of CE devices for a specific instance of an L2VPN. >>> >>> The L2VPN WG will provide extensions of existing protocols that will be >>> discussed in protocol-specific WGs. In particular, the L2VPN WG >>> may define extensions to pseudowire management mechanisms for VPLS. >>> Those extensions will be reviewed by the PWE3 WG to ensure they are >>> aligned with the overall design/architecture of PWE3. >>> >>> The L2VPN WG will not define new encapsulations, control, or resiliency >>> mechanisms specifically related to pseudowires. Furthermore, when the >>> L2VPN solution is based on PWs, the L2VPN WG will not define protocol >>> inter-working between an L2VPN and native service Layer-2 OAM or >>> resiliency mechanisms. The L2VPN WG may define how to operate native >>> service-layer control, OAM or resiliency mechanisms on top of an L2VPN. >>> In addition, it may define native data plane and/or control plane >>> interworking between an L2VPN and an associated native Layer-2 service. >>> >>> The L2VPN WG scope includes the following: >>> >>> 1. Discovery of PEs participating in a Layer-2 VPN and the associated >>> topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN >>> service. >>> >>> 2. Signaling of information related to the discovery and membership of >>> PEs within a L2VPN. These procedures must use PWE3 control and >>> management procedures, or define requirements for extensions of PWE3 >>> protocols to suit the needs of an L2VPN, when the L2VPN operates over >>> PWs. Once those requirements have been reviewed by the L2VPN WG, they >>> should be provided to the PWE3 WG to derive solutions. >>> >>> 3. MIBs for Layer-2 VPN solutions. >>> >>> 4. Specification of requirements, framework and solutions that >>> facilitate Operations Administration and Management (OAM) of any type o= f >>> L2VPN. >>> >>> 5. Mechanisms to permit optimization of multicast data traffic within >>> an L2VPN. >>> >>> 6. If transport does not involve PWs, mechanisms that support >>> load-balancing/multipathing between PEs interconnecting a Layer-2 >>> service using an L2VPN across the MPLS PSN. >>> >>> 7. requirements for the multi-homing of CEs to several VPLS or >>> E-VPN PEs, inclusive of active/backup and active/active (load-sharing) >>> configurations. Based on these requirements define VPLS or E-VPN contro= l >>> plane solutions for achieving fast convergence after failure of an acti= ve >>> path in the PSN or on the AC side. >>> >>> 8. Enhancements to increase the scalability of the Control Plane and >>> Data Plane of L2VPN PE nodes, and of core nodes that provide transport >>> services for L2VPN. >>> >>> 9. Requirements and solutions for Auto-Discovery and Signaling of >>> Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimi= zed >>> L2VPNs. >>> >>> 10. Requirements and solutions for supporting "E-Tree" services using >>> VPLS. >>> >>> 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS >>> Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinate= d >>> between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that = are >>> chartered to do MPLS TP work. >>> >>> Milestones: >>> >>> Done Submit an I-D describing MIB for VPLS >>> Done Submit an I-D describing MIB for VPWS >>> Done Submit an I-D on OAM requirements for VPLS >>> Done Submit an I-D on OAM requirements for VPWS >>> Done Submit L2 requirements to IESG for publication as Informati= onal >>> RFC >>> Done Submit L2 framework to IESG for publication as Informationa= l RFC >>> Done Identify VPLS and VPWS solutions for the WG >>> Done Submit VPLS solution documents to IESG >>> Done Submit VPWS solution documents to IESG >>> Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-= AS >>> VPLS and VPWS Layer-2 VPNs >>> Jul 2011 Submit IP-only L2VPN solution documents to IESG >>> Jul 2011 Submit OAM solutions for VPWS to IESG >>> Jul 2011 Submit OAM solutions for VPLS to IESG >>> Jul 2011 Submit signaling solution for multicast-optimized VPLS to I= ESG >>> Jul 2011 Submit I-D on Virtual Private Multicast Service (VPMS) >>> requirements to IESG >>> Jul 2011 Submit MIB for VPLS to IESG >>> Jul 2011 Submit MIB for VPWS to IESG >>> Nov 2011 Submit scalability solutions for VPLS Data-Plane to IESG >>> Nov 2011 Submit scalability solutions for VPLS Control-Plane to IESG >>> Mar 2012 Submit MIB for IP-only L2VPN to IESG >>> Mar 2012 Submit OAM solutions for IP-only L2VPN to IESG >>> Mar 2012 Submit Auto-Discovery solution for VPMS to IESG >>> Mar 2012 Submit VPLS service convergence improvement solutions to IE= SG >>> Mar 2012 Submit VPLS multi-homing solutions to IESG >>> Mar 2012 Submit E-Tree documents to IESG >>> Mar 2012 Submit E-VPN requirements/framework to IESG >>> Jul 2012 Submit E-VPN solution to IESG >>> Nov 2012 Submit E-VPN MIB/OAM to IESG >>> >>> ----------------- >>> >>> On 18/03/2011 17:41, "Giles Heron" wrote: >>> >>>> We plan to re-charter the L2VPN WG - primarily to bring E-VPN and E-Tr= ee >>>> in-scope. >>>> >>>> Please find attached a draft charter for discussion both on this list = and at >>>> IETF 80 in Prague. >>>> >>>> Nabil and Giles >>>> >>>> >>> >>> >> > > > --------------------------------------------- Nabil Bitar, PhD Principal Member of Technical Staff Packet Network Technology Verizon Corporate Network and Technology 60 Sylvan Road Waltham, MA 02451 Office Phone: (781) 466-2161 --_000_C9EB22CD15440nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Draft of new L2VPN WG Charter Hi Himanshu,
Please see inlime.

Thanks,
Nabil


On 3/31/11 11:21 AM, "Shah, Himanshu" <hshah@ciena.com> wrote:

My understanding is that, as a first step, = the problem
scope needs to be understood. Solutions, if any required,
could follow only after the problem is well understood.
Solutions are part of ARMD charter but only after first step
is completed.
<NB> This applies to ARMD.

Although, it appears that L2VPN group has already acknowledged
and understood the problem well enough to propose solutions??

<NB> I am not sure that is being said or it could be construed from t= he proposed WG charter. Addressing data center requirements (which define t= he problems and could be brought into the l2vpn WG or the Ops group) as the= y apply to l2vpn is what is proposed to be in the WG charter.  One may= ask how do we know there are any. There are already drafts being brought i= n driven by that as I mentioned in the other email. Given the activities ar= eas we may want to call it out explicitly and restrict it to l2vpn.

/himanshu


-----Original Message-----
From: l2vpn-bounces@ietf.org on beha= lf of Thomas Nadeau
Sent: Thu 3/31/2011 10:57 AM
To: Giles Heron
Cc: l2vpn@ietf.org
Subject: Re: Draft of new L2VPN WG Charter


On Mar 31, 2011, at 10:49 AM, Giles Heron wrote:

> Hi Benson,
>
> This would be provider-provisioned L2VPN environments (whether data-ce= ntre
> interconnect, or scaling of a large multi-tenant data-centre).
>
> Personally I'm not sure we need the sentence there, but others were ke= en to
> mention the data-centre requirements.

        I think that is meant to ex= plicitly field requirements for solutions
that come from ARMD/etc... into the WG, since they cannot build their own solutions.  While that isn't implicitly handled in the existing charte= r, I
do not know either.

        --Tom


>
> Giles
>
> On 31/03/2011 15:37, "Benson Schliesser" <bschlies@cisco.com> wrote:
>
>> Hi, Giles.
>>
>> I have a clarifying question about the first paragraph:  What= is the purpose
>> of the 2nd sentence, bringing cloud and DC requirements into the m= ix?
>> Assuming this is meant to include non-provider L2VPN environments = (like
>> enterprise data centers), then why not just remove the phrase
>> "provider-provisioned" from the first sentence?  Ot= herwise, it seems
>> redundant.
>>
>> This is a real question, not a suggestion at this time.
>>
>> Thanks,
>> -Benson
>>
>>
>>
>> On 3/18/11 1:21 PM, "Giles Heron" <giles.heron@gmail.com> wrote:
>>
>>> OK - looks like the attachment didn't come through as intended= .  My
>>> apologies.
>>>
>>> Text inline:
>>>
>>> ----------------
>>>
>>> The L2VPN working group is responsible for defining and specif= ying a
>>> limited number of solutions for supporting provider-provisione= d Layer-2
>>> Virtual Private Networks (L2VPNs). It will also address requir= ements driven
>>> by cloud computing services and data centers as they apply to = Layer-2
>>> VPN services.
>>>
>>> Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) a= s
>>> defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emula= tes a
>>> "native" service over a PSN that is adequately faith= ful to, but may not
>>> be entirely indistinguishable from the native service itself. = Further,
>>> following in the "edge-to-edge" nature of the  = service, the L2VPN WG will
>>> not define any mechanisms which exert control over the underly= ing PSN.
>>> When necessary it may, however, recommend or require the use o= f existing
>>> PSN QoS and path control mechanisms between the PEs which prov= ide the
>>> L2VPN connectivity.
>>>
>>> Layer-2 VPNs comprise the following:
>>>
>>> 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service tha= t emulates
>>> a switched Ethernet (V)LAN across an MPLS Packet Switched Netw= ork (PSN).
>>>
>>> 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service th= at
>>> provides point-to-point connectivity for a variety of link lay= ers,
>>> including Frame Relay, ATM, Ethernet, PPP, etc., across an MPL= S PSN.
>>>
>>> 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 servi= ce that
>>> provides point-to-multipoint connectivity for a variety of lin= k
>>> layers across an MPLS PSN.
>>>
>>> 4. IP-only L2VPN - An IP-only service over an MPLS PSN.  = The WG will
>>> address two specific types of IP-only L2VPN:
>>>
>>> a) Point-to-point Layer-2 VPN.  This service is similar t= o VPWS, but also
>>> supports heterogenous Attachment Circuits at either end of a s= ingle
>>> point-to-point service.
>>>
>>> b) Multipoint-to-multipoint Layer-2 VPN.  This service is= similar to VPLS,
>>> but learns IP and MAC address bindings from ARPs and broadcast= /multicast
>>> IP packets.
>>>
>>> 5. Ethernet VPN (E-VPN) - A Layer-2 technology that emulates a= n
>>> Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharin= g across
>>> multiple connections from a Layer-2 site to an L2VPN service, = and also
>>> supports control plane distribution of MAC addresses and IP to= MAC address
>>> bindings in the VPN. E-VPN is primarily targeted to support la= rge-scale
>>> L2VPNs with resiliency requirements not satisfied by other L2V= PN solutions.
>>>
>>> 6. E-Tree - a Layer-2 technology defined by the MEF, which pro= vides
>>> connectivity between one or more "root" nodes and on= e or more
>>> "leaf" nodes, with the restriction that leaves may o= nly communicate
>>> with roots (and not with each other).
>>>
>>> L2VPNs will make use of existing IETF specified mechanisms unl= ess there
>>> are technical reasons why the existing mechanisms are insuffic= ient or
>>> unnecessary.
>>>
>>> The L2VPN WG is responsible for specification of the discovery= and
>>> membership of PEs participating in a Layer-2 VPN as well as th= e
>>> membership of CE devices for a specific instance of an L2VPN.<= BR> >>>
>>> The L2VPN WG will provide extensions of existing protocols tha= t will be
>>> discussed in protocol-specific WGs. In particular, the L2VPN W= G
>>> may define extensions to pseudowire management mechanisms for = VPLS.
>>> Those extensions will be reviewed by the PWE3 WG to ensure the= y are
>>> aligned with the overall design/architecture of PWE3.
>>>
>>> The L2VPN WG will not define new encapsulations, control, or r= esiliency
>>> mechanisms specifically related to pseudowires. Furthermore, w= hen the
>>> L2VPN solution is based on PWs, the L2VPN WG will not define p= rotocol
>>> inter-working between an L2VPN and native service Layer-2 OAM = or
>>> resiliency mechanisms. The L2VPN WG may define how to operate = native
>>> service-layer control, OAM or resiliency mechanisms on top of = an L2VPN.
>>> In addition, it may define native data plane and/or control pl= ane
>>> interworking between an L2VPN and an associated native Layer-2= service.
>>>
>>> The L2VPN WG scope includes the following:
>>>
>>> 1. Discovery of PEs participating in a Layer-2 VPN and the ass= ociated
>>> topology required for connectivity of the VPLS, VPWS, VPMS or = E-VPN
>>> service.
>>>
>>> 2. Signaling of information related to the discovery and membe= rship of
>>> PEs within a L2VPN. These procedures must use PWE3 control and=
>>> management procedures, or define requirements for extensions o= f PWE3
>>> protocols to suit the needs of an L2VPN, when the L2VPN operat= es over
>>> PWs. Once those requirements have been reviewed by the L2VPN W= G, they
>>> should be provided to the PWE3 WG to derive solutions.
>>>
>>> 3. MIBs for Layer-2 VPN solutions.
>>>
>>> 4. Specification of requirements, framework and solutions that=
>>> facilitate Operations Administration and Management (OAM) of a= ny type of
>>> L2VPN.
>>>
>>> 5. Mechanisms to permit optimization of multicast data traffic= within
>>> an L2VPN.
>>>
>>> 6. If transport does not involve PWs, mechanisms that support<= BR> >>> load-balancing/multipathing between PEs interconnecting a Laye= r-2
>>> service using an L2VPN across the MPLS PSN.
>>>
>>> 7. requirements for the multi-homing of CEs to several VPLS or=
>>> E-VPN PEs, inclusive of active/backup and active/active (load-= sharing)
>>> configurations. Based on these requirements define VPLS or E-V= PN control
>>> plane solutions for achieving fast convergence after failure o= f an active
>>> path in the PSN or on the AC side.
>>>
>>> 8. Enhancements to increase the scalability of the Control Pla= ne and
>>> Data Plane of L2VPN PE nodes, and of core nodes that provide t= ransport
>>> services for L2VPN.
>>>
>>> 9. Requirements and solutions for Auto-Discovery and Signaling= of
>>> Inter-AS L2VPNs, in addition to Inter-AS solutions for multica= st-optimized
>>> L2VPNs.
>>>
>>> 10. Requirements and solutions for supporting "E-Tree&quo= t; services using
>>> VPLS.
>>>
>>> 11. Extensions to L2VPN protocols and RFCs necessary to create= an MPLS
>>> Transport Profile (MPLS-TP). The work on the MPLS TP will be c= oordinated
>>> between four primary working groups (MPLS, PWE3, L2VPN and CCA= MP) that are
>>> chartered to do MPLS TP work.
>>>
>>> Milestones:
>>>
>>> Done        Submit an I-D d= escribing MIB for VPLS
>>> Done        Submit an I-D d= escribing MIB for VPWS
>>> Done        Submit an I-D o= n OAM requirements for VPLS
>>> Done        Submit an I-D o= n OAM requirements for VPWS
>>> Done        Submit L2 requi= rements to IESG for publication as Informational
>>> RFC
>>> Done        Submit L2 frame= work to IESG for publication as Informational RFC
>>> Done        Identify VPLS a= nd VPWS solutions for the WG
>>> Done        Submit VPLS sol= ution documents to IESG
>>> Done        Submit VPWS sol= ution documents to IESG
>>> Done        Submit Auto-Dis= covery and Signaling for Intra-AS and Inter-AS
>>>           &n= bsp;VPLS and VPWS Layer-2 VPNs
>>> Jul 2011    Submit IP-only L2VPN solution docum= ents to IESG
>>> Jul 2011    Submit OAM solutions for VPWS to IE= SG
>>> Jul 2011    Submit OAM solutions for VPLS to IE= SG
>>> Jul 2011    Submit signaling solution for multi= cast-optimized VPLS to IESG
>>> Jul 2011    Submit I-D on Virtual Private Multi= cast Service (VPMS)
>>>           &n= bsp;requirements to IESG
>>> Jul 2011    Submit MIB for VPLS to IESG
>>> Jul 2011    Submit MIB for VPWS to IESG
>>> Nov 2011    Submit scalability solutions for VP= LS Data-Plane to IESG
>>> Nov 2011    Submit scalability solutions for VP= LS Control-Plane to IESG
>>> Mar 2012    Submit MIB for IP-only L2VPN to IES= G
>>> Mar 2012    Submit OAM solutions for IP-only L2= VPN to IESG
>>> Mar 2012    Submit Auto-Discovery solution for = VPMS to IESG
>>> Mar 2012    Submit VPLS service convergence imp= rovement solutions to IESG
>>> Mar 2012    Submit VPLS multi-homing solutions = to IESG
>>> Mar 2012    Submit E-Tree documents to IESG
>>> Mar 2012    Submit E-VPN requirements/framework= to IESG
>>> Jul 2012    Submit E-VPN solution to IESG
>>> Nov 2012    Submit E-VPN MIB/OAM to IESG
>>>
>>> -----------------
>>>
>>> On 18/03/2011 17:41, "Giles Heron" <giles.heron@gmail.com> wrote:
>>>
>>>> We plan to re-charter the L2VPN WG - primarily to bring E-= VPN and E-Tree
>>>> in-scope.
>>>>
>>>> Please find attached a draft charter for discussion both o= n this list and at
>>>> IETF 80 in Prague.
>>>>
>>>> Nabil and Giles
>>>>
>>>>
>>>
>>>
>>
>
>
>



To: Subject: I-D:Extension to signaling in VPLS for E-Tree Date: Mon, 16 May 2011 09:28:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 01:28:44 -0000 SGkgTDJWUE4gR3JvdXAgbWVtYmVycywNCg0KSSB1cGRhdGVkICJFeHRlbnNpb24gdG8gc2lnbmFs aW5nIGluIFZQTFMgZm9yIEUtVHJlZSIgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtY2Fv LWwydnBuLXZwbHMtZXRyZWUtMDAudHh0KSBwZXIgc29tZSBmZWVkYmFjay4gVGhpcyBkcmFmdCBw cm9wb3NlcyBhbiBhcHByb2FjaCB0byBleHRlbmQgY29udHJvbCBwbGFuZSB1c2luZyBMRFAgW1JG QzQ3NjJdIG9yIEJHUCBbUkZDNDc2MV0gIHRvIHN1cHBvcnQgRS1UcmVlLiBUaGlzIHdvcmsgaXMg YmFzZWQgdXBvbiB0aGUgd29yayAiRXh0ZW5zaW9uIHRvIEJHUC1WUExTIGZvciBFLVRyZWUiICho dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWNhby1sMnZwbi1iZ3AtdnBscy1ldHJlZS0wMS50 eHQpLg0KDQpDb3VsZCB5b3UgcGxlYXNlIHJldmlldyBpdCBhbmQgY29sbGFib3JhdGUgb24gdGhl IG1haWxpbmcgbGlzdCwgb3IgZGlyZWN0IHRvIHRoZSBhdXRob3I/IExvb2tpbmcgZm9yd2FyZCB0 byB5b3VyIGZlZWRiYWNrLg0KDQogVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciB0aW1lLA0K DQpSZWdhcmRzLA0KDQpZdXF1bihTYW0pIENhbw0KDQo= From DanielC@orckit.com Mon May 23 10:28:54 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC5CE0670 for ; Mon, 23 May 2011 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef7-OnuDjDN2 for ; Mon, 23 May 2011 10:28:54 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A4E0658 for ; Mon, 23 May 2011 10:28:52 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision Date: Mon, 23 May 2011 20:28:49 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C0D78B@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision Thread-Index: AcwLP6XV1miX2H8qoEK7H055dP9t5wJU/z+AATZWW+A= X-Priority: 1 priority: Urgent Importance: high From: "Daniel Cohn" To: X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:28:54 -0000 Hi L2VPNers, We (the authors) uploaded a new revision of the "Extension to LDP-VPLS for E-Tree Using Two PW" at http://tools.ietf.org/id/draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt The main change from the previous revision is the use of new interface parameters TLVs (VSI E-Tree type and VSI E-Tree identifier) to identify root and leaf PWs, rather than defining new PW types. This is a result from feedback we received when we presented the draft at IETF 80. We are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list or directly to the authors. Regards, Daniel From yuqun.cao@gmail.com Sun May 29 02:22:53 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344EE06CE for ; Sun, 29 May 2011 02:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.035 X-Spam-Level: **** X-Spam-Status: No, score=4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20rYbWgDtqsP for ; Sun, 29 May 2011 02:22:48 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBC6E0651 for ; Sun, 29 May 2011 02:22:48 -0700 (PDT) Received: by pvh18 with SMTP id 18so1412718pvh.31 for ; Sun, 29 May 2011 02:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:in-reply-to:x-mimeole; bh=zEYahjLAcNidUr2Yoxg4K/OA/L7S0rkjJO4rpJaQL8k=; b=Sv0z0U4TnJXmWRfooDTmjJyx5BZUGY/oaA3UdF6otOwg6PL5CYpGBoGtg73Ks+l465 /4mEhfuLz5EfLtEsPX3EgnHYIiIug1e/ZfeFQ5puI5wKvZwx6LlJYfdxHPOWjH2Ny4Da awdUOXzWFPiB/N+fDQypK76AV8efsVChFlGOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; b=hPv1/o/9RDBIuVgcIQyd3RaLQ0x0mL1rVsafAQfDsf5m9TLGVgs9IJsRBnhpJT0cx1 gB2yN6nFlRz1CTIazL+x4oSQY3hTpHZkyPxjsJYAFOeD39da6NHwv7v2AXh4wAjcvgAS 7heu/vCYOQvm0x19a/U4FlDLQwMOtP3+WHm8Q= Received: by 10.68.9.196 with SMTP id c4mr1527211pbb.461.1306660966763; Sun, 29 May 2011 02:22:46 -0700 (PDT) Received: from v2comsam ([175.42.33.124]) by mx.google.com with ESMTPS id k9sm1946653pbc.54.2011.05.29.02.22.44 (version=SSLv3 cipher=OTHER); Sun, 29 May 2011 02:22:45 -0700 (PDT) From: "Sam Cao" To: References: Subject: =?gb2312?B?tPC4tDogTDJ2cG4gRGlnZXN0LCBWb2wgODQsIElzc3VlIDY=?= Date: Sun, 29 May 2011 17:22:58 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwZe7oN2ueN9XN6QA+dJtKK8FE30gEYLpMg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 09:22:53 -0000 Daniel, Today I read your draft and have some questions.=20 1) In Figure 2, "VSI Root PW" is used for frames originated from Root = ACs. Is it available for both AC1 on PE1 and AC3 (Root AC) on PE2? For = example, if one unknown unicast originated from AC1, it is carried via VSI root = PW and broadcasted to AC3 and AC4. Is it right? One unknown unicast = originated from AC3 is also carried via VSI Root PW. 2) AC E-Tree Type. In your draft, it is just locally configured. If so, = Root PW and Leaf PW are always established while VSI has been configured, = right? PE selected the correct PW to send frames upon local configuration, is = it right? 3) In 5.2.1, VSI E-Tree encoding. There are two VSI E-Tree types, one is E-Tree Root VSI, and one is E-Tree Leaf VSI. If so, in figure 2, if one = VSI is attached both Root ACs and Leaf ACs, what is its type?=20 4) Can you tell me the usage of VSI E-Tree identifier? Is it useful to establish PW? " pair", I guess = we have to separate one VSI into two VSIs, one is Root VSI and one is Leaf = VSI, but if so, it is not reasonable to establish just 2 PWs in Figure 2. = Root AC and Leaf AC can not attach to same VSI. There are two ways to support E-Tree, I believe, one on data plane and = one on control plane. I also uploaded one draft on this "http://datatracker.ietf.org/doc/draft-cao-l2vpn-vpls-etree/". Would you please share some comments?=20 Yuqun (Sam) Cao Mobile: +86-18959186587 E-mail: Yuqun.cao@gmail.com=20 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] =B4=FA=B1=ED l2vpn-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 3:00 =CA=D5=BC=FE=C8=CB: l2vpn@ietf.org =D6=F7=CC=E2: L2vpn Digest, Vol 84, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision (Daniel Cohn) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 May 2011 20:28:49 +0300 From: "Daniel Cohn" To: Subject: Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C0D78B@tlvmail1> Content-Type: text/plain; charset=3D"us-ascii" Hi L2VPNers, We (the authors) uploaded a new revision of the "Extension to LDP-VPLS for E-Tree Using Two PW" at http://tools.ietf.org/id/draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt The main change from the previous revision is the use of new interface parameters TLVs (VSI E-Tree type and VSI E-Tree identifier) to identify root and leaf PWs, rather than defining new PW types. This is a result from feedback we received when we presented the draft at IETF 80. We are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list or directly to the authors. Regards, Daniel ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 84, Issue 6 ************************************ From yuqun.cao@gmail.com Sun May 29 02:27:05 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E744CE0651 for ; Sun, 29 May 2011 02:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.035 X-Spam-Level: **** X-Spam-Status: No, score=4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd7FjQEuYkKn for ; Sun, 29 May 2011 02:27:05 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 716AEE0703 for ; Sun, 29 May 2011 02:27:05 -0700 (PDT) Received: by pxi20 with SMTP id 20so1942559pxi.27 for ; Sun, 29 May 2011 02:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:in-reply-to:x-mimeole; bh=5cur/3YcNCLOjQVtceibf0OGm6wf7aPzNYoWROoVbwY=; b=H6CqAXOOcIdhnirICHzfwj9gFpmqpBQliIl9989Tt4E5xWe7cmSOhcMZzMh9NiygSy b/wWQsoWQ39fwUDD5CuwqjmqLA87fOw6AkAjGAumHg0pF0FzN6Pq6xvfcrjzHxK92v2x YtCjQDcGF/wtgV3V/6SmDdlll92rXMAN7zRSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; b=nCWnR/87F1hBzJ5gV5fbHitI4QcQ5CMoSuDcDu3sD0mWytxYRTnjJBrKDILi6fYL+Q DHiyVBZjMXGZO9ZjlNJkwTn11V/ac/1bxlrL0t4xkdRYgeqSR01soxL4ZPHtMCv02UPH DJY7k4PdCZRou/nmxGpOaZBFj4fHXunjekuVM= Received: by 10.68.33.40 with SMTP id o8mr1511911pbi.520.1306661224057; Sun, 29 May 2011 02:27:04 -0700 (PDT) Received: from v2comsam ([175.42.33.124]) by mx.google.com with ESMTPS id n4sm1948715pbj.24.2011.05.29.02.27.01 (version=SSLv3 cipher=OTHER); Sun, 29 May 2011 02:27:03 -0700 (PDT) From: "Sam Cao" To: References: Subject: =?gb2312?B?tPC4tDogTDJ2cG4gRGlnZXN0LCBWb2wgODQsIElzc3VlIDY=?= Date: Sun, 29 May 2011 17:27:16 +0800 Message-ID: <3FB76F15CFBB4AAC8EB0ECF3CD494682@v2comsam> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwZe7oN2ueN9XN6QA+dJtKK8FE30gEZpSwg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 09:27:06 -0000 Daniel, The most important is, how to establish VSI Root PW and VSI Leaf PW, = Step by step for both Root-Leaf-Mixed VSIs. Yuqun (Sam) Cao Mobile: +86-18959186587 E-mail: Yuqun.cao@gmail.com=20 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] =B4=FA=B1=ED l2vpn-request@ietf.org =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 3:00 =CA=D5=BC=FE=C8=CB: l2vpn@ietf.org =D6=F7=CC=E2: L2vpn Digest, Vol 84, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision (Daniel Cohn) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 May 2011 20:28:49 +0300 From: "Daniel Cohn" To: Subject: Seeking feedback on I-D "Extension to LDP-VPLS for E-Tree Using Two PW" new revision Message-ID: <44F4E579A764584EA9BDFD07D0CA081306C0D78B@tlvmail1> Content-Type: text/plain; charset=3D"us-ascii" Hi L2VPNers, We (the authors) uploaded a new revision of the "Extension to LDP-VPLS for E-Tree Using Two PW" at http://tools.ietf.org/id/draft-ram-l2vpn-ldp-vpls-etree-2pw-02.txt The main change from the previous revision is the use of new interface parameters TLVs (VSI E-Tree type and VSI E-Tree identifier) to identify root and leaf PWs, rather than defining new PW types. This is a result from feedback we received when we presented the draft at IETF 80. We are seeking more feedback from the mailing list, and would be grateful if you could review the document and post comments on the mailing list or directly to the authors. Regards, Daniel ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 84, Issue 6 ************************************