From stbryant@cisco.com Thu Sep 1 03:48:50 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 9577D21F8B95; Thu, 1 Sep 2011 03:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.54 X-Spam-Level: X-Spam-Status: No, score=-110.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW60eJXUhbc3; Thu, 1 Sep 2011 03:48:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD4A21F8B85; Thu, 1 Sep 2011 03:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=7083; q=dns/txt; s=iport; t=1314874222; x=1316083822; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=R7YgFcGcW/msXrA/eoFZFrD/Lb4phh89nebZf8qg9D4=; b=PYojQN7VQJm+Vxn4hX8qwmfoPGe5sZZrZ9rLL9iokiZ4QLjSC/yDotsq jnW3pBVKKlyz7LKLRpbGk4tUs0yKOHcUM6tGrzlxGigEvYT246wLl7se6 tlLDo6m7x09HzjKLHpZ9RNc8QZG0BVSXIhEBt4A4LBFSuQK/lylcKnL2L Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEViX06Q/khN/2dsb2JhbABCqFh3gUABAQEBAwEBAQ8BAgFYFwQcAwECChoLDwIWHwcCCAYBDAYCAQEeh1SYNAGDJQ8BnDCGWwSTJZEL X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208,217";a="113517118" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Sep 2011 10:50:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p81AoG87032189; Thu, 1 Sep 2011 10:50:16 GMT Received: from dhcp-gpk02-vlan300-64-103-65-27.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p81Ao4nc009137; Thu, 1 Sep 2011 11:50:15 +0100 (BST) Message-ID: <4E5F635B.80500@cisco.com> Date: Thu, 01 Sep 2011 11:50:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: pwe3 , "l2vpn@ietf.org" Subject: Fwd: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> In-Reply-To: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030106070303070409040104" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 10:48:50 -0000 This is a multi-part message in MIME format. --------------030106070303070409040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please can I draw the following document to the attention of the PWE3 and L2VPN WGs. Your comments would be welcome. It is an individual AD sponsored submission. - Stewart -------- Original Message -------- Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 10:50:05 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. The file can be obtained via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1149/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------030106070303070409040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please can I draw the following document to the
attention of the PWE3 and L2VPN WGs.

Your comments would be welcome.

It is an individual AD sponsored submission.

- Stewart



-------- Original Message --------
Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
Date: Tue, 30 Aug 2011 10:50:05 -0700
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org> 


The IESG has received a request from an individual submitter to consider
the following document:
- 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and
   Signaling'
  <draft-kompella-l2vpn-l2vpn-07.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
   circuits have been around a long time; more recently, Ethernet VPNs,
   including Virtual Private LAN Service, have become popular.
   Traditional L2VPNs often required a separate Service Provider
   infrastructure for each type, and yet another for the Internet and IP
   VPNs.  In addition, L2VPN provisioning was cumbersome.  This document
   presents a new approach to the problem of offering L2VPN services
   where the L2VPN customer's experience is virtually identical to that
   offered by traditional Layer 2 VPNs, but such that a Service Provider
   can maintain a single network for L2VPNs, IP VPNs and the Internet,
   as well as a common provisioning methodology for all services.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1149/



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--------------030106070303070409040104-- From agmalis@gmail.com Thu Sep 1 04:40:49 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 A806C21F8BB1; Thu, 1 Sep 2011 04:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3MY-Sf3P3B8; Thu, 1 Sep 2011 04:40:49 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4F21F8BAD; Thu, 1 Sep 2011 04:40:48 -0700 (PDT) Received: by qyk35 with SMTP id 35so1057520qyk.10 for ; Thu, 01 Sep 2011 04:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sW1vAqk22+/x5+PHbst0qL64kkrXzPsSl6wSz3bWR1c=; b=mQ+ZTIwwI1f0aLaQU25nEHMHBmbpsbzfI8K9zDe9s1yBOcStzeCiDKH/jQqZSj1Nv3 TOCxDrYVt80oqtkNfo6epp/s3pyjU0YJNinKqkVkRVgfQ2pGWHXgfzQvBY/ZNt4q+KHJ WGLvfryOzYRXrMC2WnWtxtaXj2UG6RLdTGfIY= Received: by 10.229.205.169 with SMTP id fq41mr87842qcb.119.1314877341125; Thu, 01 Sep 2011 04:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.29.1 with HTTP; Thu, 1 Sep 2011 04:42:00 -0700 (PDT) In-Reply-To: <4E5F635B.80500@cisco.com> References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> From: "Andrew G. Malis" Date: Thu, 1 Sep 2011 07:42:00 -0400 Message-ID: Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC To: IETF Discussion Content-Type: multipart/alternative; boundary=00504502eaaed74c5404abdfbcf2 Cc: "l2vpn@ietf.org" , pwe3 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, 01 Sep 2011 11:40:49 -0000 --00504502eaaed74c5404abdfbcf2 Content-Type: text/plain; charset=ISO-8859-1 Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC. Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well. Thanks, Andy Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for > Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 > 10:50:05 -0700 From: The IESG Reply-To: > ietf@ietf.org To: IETF-Announce > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and > Signaling' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM > circuits have been around a long time; more recently, Ethernet VPNs, > including Virtual Private LAN Service, have become popular. > Traditional L2VPNs often required a separate Service Provider > infrastructure for each type, and yet another for the Internet and IP > VPNs. In addition, L2VPN provisioning was cumbersome. This document > presents a new approach to the problem of offering L2VPN services > where the L2VPN customer's experience is virtually identical to that > offered by traditional Layer 2 VPNs, but such that a Service Provider > can maintain a single network for L2VPNs, IP VPNs and the Internet, > as well as a common provisioning methodology for all services. > > > > > The file can be obtained viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > IESG discussion can be tracked viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1149/ > > > > _______________________________________________ > IETF-Announce mailing listIETF-Announce@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-announce > > --00504502eaaed74c5404abdfbcf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Speaking as an individual, the solution in this draft has been has been ope= rationally deployed in a number of service provider networks, and it should= be documented in an informational RFC.

Speaking as PWE3 co-chair, I= would be happier if this draft required that routers that implement this s= olution also implement RFC 4447, that RFC 4447 be configured as the default= mechanism for pseudowire signaling, and that RFC 4447 was moved from an in= formational to a normative reference. In practice, I know that routers that= implement this also do implement RFC 4447, but I would like to see it in t= he RFC as well.

Thanks,
Andy

Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
Date: Tue, 30 Aug 2011 10:50:05 -0700
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.= org
To: IETF-Announce <ietf-announce@ietf.org> 


The IESG has received a request from an individual submitter to co=
nsider
the following document:
- 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and
   Signaling'
  <draft-kompella-l2vpn-l2vpn-07.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin=
g lists by 2011-09-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
   circuits have been around a long time; more recently, Ethernet VPNs,
   including Virtual Private LAN Service, have become popular.
   Traditional L2VPNs often required a separate Service Provider
   infrastructure for each type, and yet another for the Internet and IP
   VPNs.  In addition, L2VPN provisioning was cumbersome.  This document
   presents a new approach to the problem of offering L2VPN services
   where the L2VPN customer's experience is virtually identical to that
   offered by traditional Layer 2 VPNs, but such that a Service Provider
   can maintain a single network for L2VPNs, IP VPNs and the Internet,
   as well as a common provisioning methodology for all services.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/<=
/a>

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/<=
/a>


The following IPR Declarations may be related to this I-D:

   http=
://datatracker.ietf.org/ipr/1149/



_______________________________________________
IETF-Announce mailing list
IETF-Announce@i=
etf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


--00504502eaaed74c5404abdfbcf2-- From robert@raszuk.net Thu Sep 1 07:00:40 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 7946221F9AE0 for ; Thu, 1 Sep 2011 07:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TYwFHYhp7W5 for ; Thu, 1 Sep 2011 07:00:40 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 0DDCF21F9ADF for ; Thu, 1 Sep 2011 07:00:39 -0700 (PDT) Received: (qmail 30889 invoked by uid 399); 1 Sep 2011 13:55:33 -0000 Received: from unknown (HELO ?192.168.1.68?) (robert@raszuk.net@83.28.178.205) by mail37.opentransfer.com with SMTP; 1 Sep 2011 13:55:33 -0000 Message-ID: <4E5F8EDD.7000700@raszuk.net> Date: Thu, 01 Sep 2011 15:55:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Andrew G. Malis" Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , pwe3 , IETF Discussion X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 14:00:40 -0000 Hi, I support adoption and publishing draft-kompella-l2vpn-l2vpn-07.txt as informational RFC. Using BGP for auto-discovery and signalling of L2VPNs is by all means a right approach. The draft also makes it very clear that underlying transport is opaque and allows to use any form of encapsulation for PE-PE data exchange. In that light I would not recommend to make any references in it to RFC4447 and treat both specs as fully independent and unreleated documents. Best regards, R. > Speaking as an individual, the solution in this draft has been has been > operationally deployed in a number of service provider networks, and it > should be documented in an informational RFC. > > Speaking as PWE3 co-chair, I would be happier if this draft required that > routers that implement this solution also implement RFC 4447, that RFC 4447 > be configured as the default mechanism for pseudowire signaling, and that > RFC 4447 was moved from an informational to a normative reference. In > practice, I know that routers that implement this also do implement RFC > 4447, but I would like to see it in the RFC as well. > > Thanks, > Andy > > Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for >> Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 >> 10:50:05 -0700 From: The IESG Reply-To: >> ietf@ietf.org To: IETF-Announce >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and >> Signaling' >> as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM >> circuits have been around a long time; more recently, Ethernet VPNs, >> including Virtual Private LAN Service, have become popular. >> Traditional L2VPNs often required a separate Service Provider >> infrastructure for each type, and yet another for the Internet and IP >> VPNs. In addition, L2VPN provisioning was cumbersome. This document >> presents a new approach to the problem of offering L2VPN services >> where the L2VPN customer's experience is virtually identical to that >> offered by traditional Layer 2 VPNs, but such that a Service Provider >> can maintain a single network for L2VPNs, IP VPNs and the Internet, >> as well as a common provisioning methodology for all services. >> >> >> >> >> The file can be obtained viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >> >> IESG discussion can be tracked viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> http://datatracker.ietf.org/ipr/1149/ >> >> >> >> _______________________________________________ >> IETF-Announce mailing listIETF-Announce@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-announce >> >> > From xuxiaohu@huawei.com Tue Sep 6 01:23:06 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 C7EF821F84F3 for ; Tue, 6 Sep 2011 01:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.97 X-Spam-Level: X-Spam-Status: No, score=-3.97 tagged_above=-999 required=5 tests=[AWL=2.629, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NyG-z3HxzmA for ; Tue, 6 Sep 2011 01:23:06 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 284B321F84EC for ; Tue, 6 Sep 2011 01:23:06 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR300JJUE0XW3@szxga04-in.huawei.com> for l2vpn@ietf.org; Tue, 06 Sep 2011 16:24:33 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR3005HRE0AEN@szxga04-in.huawei.com> for l2vpn@ietf.org; Tue, 06 Sep 2011 16:24:33 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADU98948; Tue, 06 Sep 2011 16:24:32 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 16:24:29 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.122]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 06 Sep 2011 16:24:28 +0800 Date: Tue, 06 Sep 2011 08:24:27 +0000 From: Xuxiaohu Subject: fwd: New Version Notification for draft-xu-l2vpn-vpls-isis-01.txt X-Originating-IP: [10.110.98.53] To: "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C474@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-xu-l2vpn-vpls-isis-01.txt Thread-index: AQHMbGsFjE6nNbiPlUqa5mAsL2AVYZVAAOgw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected 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, 06 Sep 2011 08:23:06 -0000 SGkgYWxsLA0KDQpUaGUgbmV3IHZlcnNpb24gb2YgSVMtSVMgVlBMUyBpcyBub3cgYXZhaWxhYmxl IGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWwydnBuLXZwbHMtaXNpcy0w MS4gSVMtSVMgVlBMUyBpcyBhIGxpZ2h0LXdlaWdodCBWUExTIHdoaWNoIGlzIGludGVuZGVkIHRv IGJlIHVzZWQgYXMgYSBzY2FsYWJsZSBjbG91ZCBkYXRhIGNlbnRlciBuZXR3b3JrIHNvbHV0aW9u Lg0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumX tDogMjAxMeW5tDnmnIg25pelIDE1OjU4DQo+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4g5oqE6YCB OiBoc2hhaEBjaWVuYS5jb207IFh1eGlhb2h1DQo+IOS4u+mimDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC14dS1sMnZwbi12cGxzLWlzaXMtMDEudHh0DQo+IA0KPiBBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtbDJ2cG4tdnBscy1pc2lzLTAxLnR4dCBoYXMgYmVlbiBz dWNjZXNzZnVsbHkNCj4gc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LXh1LWwydnBuLXZwbHMtaXNp cw0KPiBSZXZpc2lvbjoJIDAxDQo+IFRpdGxlOgkJIFZpcnR1YWwgUHJpdmF0ZSBMQU4gU2Vydmlj ZSAoVlBMUykgVXNpbmcgSVMtSVMNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTEtMDktMDYNCj4gV0cg SUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogOQ0KPiANCj4g QWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbGlnaHQtd2VpZ2h0IFZp cnR1YWwgUHJpdmF0ZSBMQU4gU2VydmljZQ0KPiAgICAoVlBMUykgd2hpY2ggdXNlcyBJUy1JUyBm b3IgYXV0by1kaXNjb3ZlcnkgYW5kIHNpZ25hbGluZy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0K From xuxiaohu@huawei.com Tue Sep 6 02:57: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 E319221F85B5; Tue, 6 Sep 2011 02:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.134 X-Spam-Level: X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=2.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2d5P1RA9LfX; Tue, 6 Sep 2011 02:57:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAAA21F8593; Tue, 6 Sep 2011 02:57:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR300H3GIEEQN@szxga04-in.huawei.com>; Tue, 06 Sep 2011 17:59:03 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR3004DJIE5MS@szxga04-in.huawei.com>; Tue, 06 Sep 2011 17:59:02 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV08440; Tue, 06 Sep 2011 17:59:02 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 17:58:59 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.122]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 06 Sep 2011 17:58:57 +0800 Date: Tue, 06 Sep 2011 09:58:56 +0000 From: Xuxiaohu Subject: re: New Version Notification for draft-xu-l2vpn-vpls-isis-01.txt In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C474@szxeml525-mbx.china.huawei.com> X-Originating-IP: [10.110.98.53] To: "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C49F@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-xu-l2vpn-vpls-isis-01.txt Thread-index: AQHMbGsFjE6nNbiPlUqa5mAsL2AVYZVAAOgwgAATWMA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C474@szxeml525-mbx.china.huawei.com> Cc: "mpls@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: Tue, 06 Sep 2011 09:57:54 -0000 SGkgYWxsLA0KDQpJIGp1c3QgcmVhbGl6ZWQgdGhhdCB0aGUgbG9jYWxseSB1bmlxdWUgVlBMUyBs YWJlbCB3aGljaCBpcyBhZHZlcnRpc2VkIGluIHRoZSB0by1iZS1kZWZpbmVkIElTLUlTIFRMViBj b3VsZCBhY3R1YWxseSBiZSB1c2VkIGZvciBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdC4gSW4g b3RoZXIgd29yZHMsIHRoZSBzYW1lIFZQTFMgbGFiZWwgY291bGQgYmUgdHJlYXRlZCBhcyBhIGRv d25zdHJlYW0tYXNzaWduZWQgbGFiZWwgZm9yIHVuaWNhc3QgYW5kIGEgdXBzdHJlYW0tYXNzaWdu ZWQgbGFiZWwgZm9yIG11bHRpY2FzdC4gRm9yIGV4YW1wbGUsIGFzc3VtZSBQRS0xIGFkdmVydGlz ZXMgYSBsb2NhbGx5IHVuaXF1ZSBsYWJlbCBMIGZvciBWUExTIGluc3RhbmNlIFggd2l0aCB0aGF0 IHRvLWJlLWRlZmluZWQgSVMtSVMgVExWLCBvdGhlciBQRSByb3V0ZXJzIGNvdWxkIHNlbmQga25v d24gdW5pY2FzdCBwYWNrZXQgZGVzdGluZWQgZm9yIFBFLTEgd2l0aCBsYWJlbCBMIGNvbnRhaW5l ZCBhcyBhIGRvd25zdHJlYW0tYXNzaWduZWQgbGFiZWwuIE1lYW53aGlsZSwgUEUtMSBjb3VsZCBz ZW5kIGEgbXVsdGljYXN0IHBhY2tldCBmb3IgVlBMUyBYIGNvbnRhaW5pbmcgbGFiZWwgTCBhcyBh biB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbC4gVGhlIGVncmVzcyBQRSByb3V0ZXJzIGNvdWxkIGRp c3Rpbmd1aXNoIHdoZXRoZXIgdGhlIE1QTFMgbGFiZWwgY29udGFpbmVkIGluIHRoZSBlbmNhcHN1 bGF0ZWQgVlBMUyBwYWNrZXQgaXMgYW4gdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwgb3IgYSBkb3du c3RyZWFtLWFzc2lnbmVkIGxhYmVsIGFjY29yZGluZyB0byB0aGUgIk1QTFMgbGFiZWwgdHlwZSIg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSBlbmNhcHN1bGF0ZWQgVlBMUyBwYWNrZXRzLCB0 YWtlbiB0aGUgTVBMUy1pbi1HUkUgZW5jYXBzdWxhdGlvbiBhcyBhbiBleGFtcGxlLCB0aGUgcHJv dG9jb2wgdHlwZSBmaWVsZCBpbiB0aGUgR1JFIGhlYWRlciB3b3VsZCBiZSBzZXQgdG8gMHg4ODQ3 IGZvciBNUExTIHVuaWNhc3QgYW5kIDB4ODg0OCBmb3IgbXVsdGljYXN0LiANCg0KQW55IGNvbW1l bnRzPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0t DQo+IOWPkeS7tuS6ujogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiBYdXhpYW9odQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQ5 5pyINuaXpSAxNjoyNA0KPiDmlLbku7bkuro6IGwydnBuQGlldGYub3JnDQo+IOS4u+mimDogZndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LWwydnBuLXZwbHMtaXNpcy0w MS50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IFRoZSBuZXcgdmVyc2lvbiBvZiBJUy1JUyBWUExT IGlzIG5vdyBhdmFpbGFibGUgYXQNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eHUtbDJ2cG4tdnBscy1pc2lzLTAxLiBJUy1JUyBWUExTIGlzIGEgbGlnaHQtd2VpZ2h0DQo+IFZQ TFMgd2hpY2ggaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIHNjYWxhYmxlIGNsb3VkIGRhdGEg Y2VudGVyIG5ldHdvcmsNCj4gc29sdXRpb24uDQo+IA0KPiBBbnkgY29tbWVudHMgYXJlIHdlbGNv bWUuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLemCruS7tuWO n+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0Oeac iDbml6UgMTU6NTgNCj4gPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ID4g5oqE6YCBOiBoc2hhaEBj aWVuYS5jb207IFh1eGlhb2h1DQo+ID4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXh1LWwydnBuLXZwbHMtaXNpcy0wMS50eHQNCj4gPg0KPiA+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC14dS1sMnZwbi12cGxzLWlzaXMtMDEudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseQ0KPiA+IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6CSBkcmFmdC14dS1sMnZwbi12cGxzLWlz aXMNCj4gPiBSZXZpc2lvbjoJIDAxDQo+ID4gVGl0bGU6CQkgVmlydHVhbCBQcml2YXRlIExBTiBT ZXJ2aWNlIChWUExTKSBVc2luZyBJUy1JUw0KPiA+IENyZWF0aW9uIGRhdGU6CSAyMDExLTA5LTA2 DQo+ID4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gTnVtYmVyIG9mIHBhZ2Vz OiA5DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IGxpZ2h0LXdlaWdodCBWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZpY2UNCj4gPiAgICAoVlBMUykg d2hpY2ggdXNlcyBJUy1JUyBmb3IgYXV0by1kaXNjb3ZlcnkgYW5kIHNpZ25hbGluZy4NCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From jiangyuanlong@huawei.com Tue Sep 6 23:18:35 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 C27F521F8479; Tue, 6 Sep 2011 23:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja0lvtc6fv2u; Tue, 6 Sep 2011 23:18:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA8C21F845C; Tue, 6 Sep 2011 23:18:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR500AAI2WLCR@szxga04-in.huawei.com>; Wed, 07 Sep 2011 14:19:33 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR500B9E2WL7J@szxga04-in.huawei.com>; Wed, 07 Sep 2011 14:19:33 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV52539; Wed, 07 Sep 2011 14:19:07 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 07 Sep 2011 14:19:03 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.10]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Wed, 07 Sep 2011 14:19:02 +0800 Date: Wed, 07 Sep 2011 06:19:00 +0000 From: Jiangyuanlong Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC In-reply-to: X-Originating-IP: [10.70.40.106] To: Stewart Bryant Message-id: <3B0A1BED22CAD649A1B3E97BE5DDD68B04157849@SZXEML508-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-index: AQHMbSYJms83MirJNkCnRC3l8hO+3g== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "l2vpn@ietf.org" , pwe3 , IETF Discussion 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: Wed, 07 Sep 2011 06:18:35 -0000 Hi Stewart, This draft specifies two new registries for IANA to grant, and in which new entry values also need "standards action". Shouldn't this draft be classified as "Standards Track"? Regards Yuanlong -------- Original Message -------- Date: Thu, 01 Sep 2011 11:50:03 +0100 From: Stewart Bryant To: pwe3 , "l2vpn@ietf.org" Subject: Fwd: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Message-ID: <4E5F635B.80500@cisco.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Please can I draw the following document to the attention of the PWE3 and L2VPN WGs. Your comments would be welcome. It is an individual AD sponsored submission. - Stewart From lmartini@cisco.com Tue Sep 13 08:21:56 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 D74DE21F86F6; Tue, 13 Sep 2011 08:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8YY4hHIEVLQ; Tue, 13 Sep 2011 08:21:41 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id E94C521F84FD; Tue, 13 Sep 2011 08:21:40 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p8DFNjHn003254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 09:23:45 -0600 (MDT) Message-ID: <4E6F7581.20102@cisco.com> Date: Tue, 13 Sep 2011 09:23:45 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Andrew G. Malis" Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , pwe3 , IETF Discussion 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, 13 Sep 2011 15:21:56 -0000 I concurr with Andy. Given that the WG has made a decision on which control plane technology is the standard track technology we should have a statement in this document pointing to the standard track rfc4447 so it is clear to anyone reading the document. In the same way we published the draft-martini documents as historical ee should publish this document as historical rfc, to document existing implementations. Luca On 09/01/11 05:42, Andrew G. Malis wrote: > Speaking as an individual, the solution in this draft has been has > been operationally deployed in a number of service provider networks, > and it should be documented in an informational RFC. > > Speaking as PWE3 co-chair, I would be happier if this draft required > that routers that implement this solution also implement RFC 4447, > that RFC 4447 be configured as the default mechanism for pseudowire > signaling, and that RFC 4447 was moved from an informational to a > normative reference. In practice, I know that routers that implement > this also do implement RFC 4447, but I would like to see it in the RFC > as well. > > Thanks, > Andy > > Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP > for Auto-discovery and Signaling) to Informational RFC > Date: Tue, 30 Aug 2011 10:50:05 -0700 > From: The IESG > > Reply-To: ietf@ietf.org > To: IETF-Announce > > > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and > Signaling' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM > circuits have been around a long time; more recently, Ethernet VPNs, > including Virtual Private LAN Service, have become popular. > Traditional L2VPNs often required a separate Service Provider > infrastructure for each type, and yet another for the Internet and IP > VPNs. In addition, L2VPN provisioning was cumbersome. This document > presents a new approach to the problem of offering L2VPN services > where the L2VPN customer's experience is virtually identical to that > offered by traditional Layer 2 VPNs, but such that a Service Provider > can maintain a single network for L2VPNs, IP VPNs and the Internet, > as well as a common provisioning methodology for all services. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1149/ > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From Alexander.Vainshtein@ecitele.com Tue Sep 13 09:01:41 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 902BC21F8C28; Tue, 13 Sep 2011 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.292 X-Spam-Level: X-Spam-Status: No, score=-4.292 tagged_above=-999 required=5 tests=[AWL=0.911, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhUvum1FsiCu; Tue, 13 Sep 2011 09:01:40 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 4E20C21F8B3D; Tue, 13 Sep 2011 09:01:38 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1315929820!17616746!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 24361 invoked from network); 13 Sep 2011 16:03:41 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-5.tower-216.messagelabs.com with SMTP; 13 Sep 2011 16:03:41 -0000 X-AuditID: 93eaf2e7-b7cf3ae00000636f-50-4e6f7ed21f3b Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id F8.C1.25455.2DE7F6E4; Tue, 13 Sep 2011 19:03:30 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 13 Sep 2011 18:03:39 +0200 From: Alexander Vainshtein To: Luca Martini Date: Tue, 13 Sep 2011 18:03:38 +0200 Subject: RE: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Topic: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Index: AcxyKS9DkRwie8etQQCUTilca/wRpAABKNGw Message-ID: References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> In-Reply-To: <4E6F7581.20102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa2wMURTO3ZnuTqsjY3XttR5Zo9p4bO16JNPo0v5rE6qiIpFIjdnb3dHZ 2c3OtFGpqnqUlYhXhI201BJB9BGUENXlB+tV/aOqqCiteiQaKmxYM4aquL++e77zne/cm3MI zPhebyF4UUYBkRVofRK+f2Dwk62j0pdvb3ySxtzpi+qZ1011OPNyKGJg+rq/G5jdg+fx7ITc A7GmhNzLoaeG3HD4q64AW1UFslhR9MmsjKwuJHFOuiDAl7FcOW3lXU7aQVv9AsshLxJlJ836 /Uh00QuTrP+dLCWNF61I5HwuXnQ76bzlS20MMz/T5qAXpk11zF2QVOjhJSuyeVlesHqRJLFu ZFUia85jnms3d+L+nvT1R1pe4FWge3IQJBKQmgc739YbNDwOtj9r0AdBEmGkWgHc2979izBS BwF8FDepWE85YfOZp3oVp1DT4LkbMaBijNoGYG9oYhAQBK7EL7ba1DpjqXoAg1WbDeolhToO 4JH+a7gmngPv1zf8MiCpZfBOtBloZm0A3qvJUnEilQ6HYv2YioHS3ZfoWZ1mZoZdvXU6rWsK hq8+wDRsgm9e/kjQ8k2wu6bhd3Oz4NErg3oNz4Qnj73FNN8x8PbhXlzTjodtpzrxPcAcGmER GiEPjZCHRsiPAvw0MPGCX17rddsdGYjjZSSgDM7nbQba4PRdAt/qUiOAIgCdTLani/nGBLZM KvdGwHhCR5vItgpfvnH0Wp+r3MNKnqJAqYCkCIAERqeQsTUKR7rY8g0o4PtDMco378Usozif MqKiXDTXbv/nQpvJV9y7JUbKrUxdCUJ+FPgjnUgQNCQFZZKNYwLIjdYX84L8l9YRiapzsuJc r+aQkp/1Srxb46NgisVMblUJSiU8peKwVt2STfF4fACYlXeOJZtLlaxkZYeG1QNKYZ1SeFOt qBZWNmKYslSB6uvF5x7QrZmnxEq5OoO5eKy0ccnHMzXrtqfOFg6VldiL4w8v8HnT87bpWj73 WDw5lfG7Baji/sah9p59W7LnZ0cKcydtPDG768Me3ckduyZUrI6mLq/Nvxp7MqrjRm3dyvDz nNu7FuUs7gWZXE5yagUWvpw4p/9b9YrgoVsz0x5XFtK45GEdM7CAxP4EFNifBAAEAAA= Cc: "l2vpn@ietf.org" , "Andrew G. Malis" , pwe3 , IETF Discussion 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, 13 Sep 2011 16:01:42 -0000 Luca, and all, I concur with Andy's opinion that the reference to RFC 4447 must become Norm= ative (this will not delay the publication is too often the case:-). As for Informational vs. Historical, I think that Informational is more appr= opriate because, AFAIK, the technique defined in draft-kompella is not just= a documenting an existing solution - it describes is THE ONLY deployed solu= tion for the problem. (If this statement happens to be factually incorrect,= I would be happy to learn about the deployed alternatives.) Regards, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Luca > Martini > Sent: Tuesday, September 13, 2011 6:24 PM > To: Andrew G. Malis > Cc: l2vpn@ietf.org; pwe3; IETF Discussion > Subject: Re: Last Call: (Layer 2 Virtu= al > Private Networks Using BGP for Auto-discovery and Signaling) to Informatio= nal > RFC > > I concurr with Andy. > Given that the WG has made a decision on which control plane technology > is the standard track technology we should have a statement in this > document pointing to the standard track rfc4447 so it is clear to anyone > reading the document. > In the same way we published the draft-martini documents as historical > ee should publish this document as historical rfc, to document existing > implementations. > > Luca > > On 09/01/11 05:42, Andrew G. Malis wrote: > > Speaking as an individual, the solution in this draft has been has > > been operationally deployed in a number of service provider networks, > > and it should be documented in an informational RFC. > > > > Speaking as PWE3 co-chair, I would be happier if this draft required > > that routers that implement this solution also implement RFC 4447, > > that RFC 4447 be configured as the default mechanism for pseudowire > > signaling, and that RFC 4447 was moved from an informational to a > > normative reference. In practice, I know that routers that implement > > this also do implement RFC 4447, but I would like to see it in the RFC > > as well. > > > > Thanks, > > Andy > > > > Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP > > for Auto-discovery and Signaling) to Informational RFC > > Date: Tue, 30 Aug 2011 10:50:05 -0700 > > From: The IESG > > > > Reply-To: ietf@ietf.org > > To: IETF-Announce > > > > > > > > > > The IESG has received a request from an individual submitter to cons= ider > > the following document: > > - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and > > Signaling' > > as an Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicit= s > > final comments on this action. Please send substantive comments to t= he > > ietf@ietf.org mailing lists by 2011-09-27. > Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case= , > please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or= ATM > > circuits have been around a long time; more recently, Ethernet VP= Ns, > > including Virtual Private LAN Service, have become popular. > > Traditional L2VPNs often required a separate Service Provider > > infrastructure for each type, and yet another for the Internet an= d IP > > VPNs. In addition, L2VPN provisioning was cumbersome. This docu= ment > > presents a new approach to the problem of offering L2VPN services > > where the L2VPN customer's experience is virtually identical to t= hat > > offered by traditional Layer 2 VPNs, but such that a Service Prov= ider > > can maintain a single network for L2VPNs, IP VPNs and the Interne= t, > > as well as a common provisioning methodology for all services. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/1149/ > > > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > > > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From wwwrun@ietfa.amsl.com Tue Sep 13 09:41:59 2011 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 24CB721F8CCA; Tue, 13 Sep 2011 09:41:59 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Subject: WG Action: RECHARTER: Layer 2 Virtual Private Networks (l2vpn) Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110913164159.24CB721F8CCA@ietfa.amsl.com> Date: Tue, 13 Sep 2011 09:41:59 -0700 (PDT) Cc: l2vpn@ietf.org, giheron@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: Tue, 13 Sep 2011 16:41:59 -0000 The Layer 2 Virtual Private Networks (l2vpn) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Last updated: 2011-08-30 Current Status: Active Chairs: Nabil Bitar Giles Heron Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: 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 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) as defined by the PWE3 WG or over IP or 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 will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing 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 emulates a switched Ethernet (V)LAN across a 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 a PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across a PSN. 4. IP-only L2VPN, an IP-only service over a 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 also 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 VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree, a Layer-2 service defined by the MEF, which provides connectivity between one or more root nodes and one or more leaf nodes, with the restriction that leaf nodes may only communicate with root node(s) (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 of L2VPN within the scope of the L2VPN Working Group. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multi-pathing between PEs interconnecting a Layer-2 service using an L2VPN across the 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 control plane solutions for achieving fast convergence after failure of an active 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-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. 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 Informational RFC Done Submit L2 framework to IESG for publication as Informational 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 Oct 2011 Submit IP-only L2VPN solution documents to IESG Nov 2011 Submit OAM solutions for VPWS to IESG Nov 2011 Submit OAM solutions for VPLS to IESG Nov 2011 Submit signaling solution for multicast-optimized VPLS to IESG Nov 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2011 Submit MIB for VPLS to IESG Nov 2011 Submit MIB for VPWS to IESG Mar 2012 Submit scalability solutions for VPLS Data-Plane to IESG Mar 2012 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit E-Tree requirements/framework to IESG Jul 2012 Submit MIB for IP-only L2VPN to IESG Jul 2012 Submit OAM solutions for IP-only L2VPN to IESG Jul 2012 Submit Auto-Discovery solution for VPMS to IESG Jul 2012 Submit VPLS service convergence improvement solutions to IESG Jul 2012 Submit VPLS multi-homing solutions to IESG Jul 2012 Submit E-Tree solution to IESG Jul 2012 Submit E-VPN requirements/framework to IESG Nov 2012 Submit E-Tree OAM to IESG Dec 2012 Submit E-Tree MIB to IESG Nov 2012 Submit E-VPN solution to IESG Mar 2013 Submit E-VPN OAM to IESG Apr 2013 Submit E-VPN MIB to IESG From lmartini@cisco.com Tue Sep 13 12:15: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 2E56721F8BA8; Tue, 13 Sep 2011 12:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aTo-DRZPZcn; Tue, 13 Sep 2011 12:15:07 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB221F8BA6; Tue, 13 Sep 2011 12:15:06 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p8DJGwTB021386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 13:16:59 -0600 (MDT) Message-ID: <4E6FAC2A.5060401@cisco.com> Date: Tue, 13 Sep 2011 13:16:58 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Alexander Vainshtein Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , "Andrew G. Malis" , pwe3 , IETF Discussion 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, 13 Sep 2011 19:15:08 -0000 On 09/13/11 10:03, Alexander Vainshtein wrote: > Luca, and all, > > I concur with Andy's opinion that the reference to RFC 4447 must become Normative (this will not delay the publication is too often the case:-). > > As for Informational vs. Historical, I think that Informational is more appropriate because, AFAIK, the technique defined in draft-kompella is not just a documenting an existing solution - it describes is THE ONLY deployed solution for the problem. (If this statement happens to be factually incorrect, I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074. As 10 years ago we had several deployments of "draft-martini" which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca > Regards, > Sasha > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Luca >> Martini >> Sent: Tuesday, September 13, 2011 6:24 PM >> To: Andrew G. Malis >> Cc: l2vpn@ietf.org; pwe3; IETF Discussion >> Subject: Re: Last Call: (Layer 2 Virtual >> Private Networks Using BGP for Auto-discovery and Signaling) to Informational >> RFC >> >> I concurr with Andy. >> Given that the WG has made a decision on which control plane technology >> is the standard track technology we should have a statement in this >> document pointing to the standard track rfc4447 so it is clear to anyone >> reading the document. >> In the same way we published the draft-martini documents as historical >> ee should publish this document as historical rfc, to document existing >> implementations. >> >> Luca >> >> On 09/01/11 05:42, Andrew G. Malis wrote: >>> Speaking as an individual, the solution in this draft has been has >>> been operationally deployed in a number of service provider networks, >>> and it should be documented in an informational RFC. >>> >>> Speaking as PWE3 co-chair, I would be happier if this draft required >>> that routers that implement this solution also implement RFC 4447, >>> that RFC 4447 be configured as the default mechanism for pseudowire >>> signaling, and that RFC 4447 was moved from an informational to a >>> normative reference. In practice, I know that routers that implement >>> this also do implement RFC 4447, but I would like to see it in the RFC >>> as well. >>> >>> Thanks, >>> Andy >>> >>> Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP >>> for Auto-discovery and Signaling) to Informational RFC >>> Date: Tue, 30 Aug 2011 10:50:05 -0700 >>> From: The IESG >>> >>> Reply-To: ietf@ietf.org >>> To: IETF-Announce >>> >>> >>> >>> >>> The IESG has received a request from an individual submitter to consider >>> the following document: >>> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and >>> Signaling' >>> as an Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2011-09-27. >> Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, >> please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM >>> circuits have been around a long time; more recently, Ethernet VPNs, >>> including Virtual Private LAN Service, have become popular. >>> Traditional L2VPNs often required a separate Service Provider >>> infrastructure for each type, and yet another for the Internet and IP >>> VPNs. In addition, L2VPN provisioning was cumbersome. This document >>> presents a new approach to the problem of offering L2VPN services >>> where the L2VPN customer's experience is virtually identical to that >>> offered by traditional Layer 2 VPNs, but such that a Service Provider >>> can maintain a single network for L2VPNs, IP VPNs and the Internet, >>> as well as a common provisioning methodology for all services. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>> >>> >>> The following IPR Declarations may be related to this I-D: >>> >>> http://datatracker.ietf.org/ipr/1149/ >>> >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf > > > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > From Alexander.Vainshtein@ecitele.com Tue Sep 13 13:12:44 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 38D4321F8AF3; Tue, 13 Sep 2011 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.37 X-Spam-Level: X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDLKEr82RJWh; Tue, 13 Sep 2011 13:12:40 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id E973A21F8AE6; Tue, 13 Sep 2011 13:12:39 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1315944861!54819596!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 2630 invoked from network); 13 Sep 2011 20:14:21 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-27.messagelabs.com with SMTP; 13 Sep 2011 20:14:21 -0000 X-AuditID: 93eaf2e7-b7cf3ae00000636f-2f-4e6fb9a9fa1e Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D6.C6.25455.9A9BF6E4; Tue, 13 Sep 2011 23:14:34 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 13 Sep 2011 22:14:43 +0200 From: Alexander Vainshtein To: Luca Martini Date: Tue, 13 Sep 2011 22:14:43 +0200 Subject: RE: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Topic: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Index: AcxySbyvOc4/mVo1SdOdUURGHSKGrAABroTy Message-ID: References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> , <4E6FAC2A.5060401@cisco.com> In-Reply-To: <4E6FAC2A.5060401@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTW0gUURjuzGUdzYlx3W1PYjBMFyhbc9uKiVyp6MGgrEh6iMjG3dPu0OzM trNdrIesKMEH7X5ZKE1FKisvGKkVll2kjcqHoto0IS1JE0HK7tlMY2Z0nr7//7/vfP85/D+F m/NjkihRDqGgLEicKY440jv4wX6hUclKe3Uxln/QEzHxb2tLCL5rqCWG72n/EcMXDdYTi8jM o99qyczGcEdMZkXFF2wVvi4fpAuyrISEEGI9SHW7uFVBcZvgzuNY0ePiHBwbkAQ38iM55OKE QADJHi4jjv3vpGs0UWaR7FY8oux1ccvWrLTz/LwFdgeXMX2Kw7kwLtsnqiyy+wVRYv1IVQUv YrXMxnrct6/jMBn4OH9H395WkA8iKYUgloLMXHglXEAYeCJse1VtKgRxlJlpBrCium8kOA5g W+ERUmeZGBesq+ow6djCTIOXb38DOsaZ/QB2h5N1TGj55x0nfosTmTIA9/e8wPXAwpQDWBx5 SxrqOfDRs2INUxTNrIYvoyv0tJmpxGDVsQQdxzIz4ED/d0zHQGvvU+QiZpjZYLS7BDPaZmDF 9ce4ga3wXddP0uBbYXtB9Uhzs2DptUGTgVNg5dm+33yaSYD3T3WPPH8SvHXuOXEQ2MJjLMJj 5OEx8vAYeSkgLgCrKAVCuX5vmiMVucUQklCqW/HXAWNyehrA15KpLYChABdP1+xVssyksE3N 87eASRTGWek1DVpqQq7iyfMJqi8nuFVCaguAFM5Z6BM1Wo32CHk7UVD5U+K1bz6EJ413K9qM yqEcZ1raPwFno9+4368wM15t7DYjFEDBP9JkiuIg3as7JgSRF+3YJEqhv2WMitWd4zXnpY26 sxoQ/KroNeoR4KReNjxrBVRnVbQVmAlZkVGSjeZ0KqNTfVvl0dv0xdk9PDzcC2zayxPpo7pp vLZWo/f1alaYZrX7jKxbaUsyWkrKB03K9q5Lye1Z2ekWe/v0gcC9Ldii6M/JTdap109/rlx7 KIfdctd8+IvwY8j0vv+p7cWCziWdiZeWppZmz//4cPaT7ylPXjtv8uWi5ergFHpcxvIMqSba OqNsonPPas/5Dc1tdeW5xZJU5Mo9YF08jpwtrh84s6uJvHP2eD/Omk+W3eAI1Sc4ZuJBVfgF bfUR4RMEAAA= Cc: "l2vpn@ietf.org" , "Andrew G. Malis" , pwe3 , IETF Discussion 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, 13 Sep 2011 20:12:44 -0000 Luca, The draft in question exists for almost 8 years (the -00 version has been po= sted 2004-01-13), has been implemented and deployed. I have not heard that solutions compliant with RFC 6074 (which is the proper= analog of 4447 in this case IMO) have been deployed in this interval - and= that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficiently s= table for any potential implementer) for almost 6 years (from 2006-06-12). Hence I do not see this case as similar to what happened to the original dra= ft-martini vs. RFC 4447. Do I miss something substantial here? Regards, Sasha ________________________________________ From: Luca Martini [lmartini@cisco.com] Sent: Tuesday, September 13, 2011 9:16 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; pwe3; IETF Discussion; Andrew G. Malis Subject: Re: Last Call: (Layer 2 Virtual= Private Networks Using BGP for Auto-discovery and Signaling) to Information= al RFC On 09/13/11 10:03, Alexander Vainshtein wrote: > Luca, and all, > > I concur with Andy's opinion that the reference to RFC 4447 must become No= rmative (this will not delay the publication is too often the case:-). > > As for Informational vs. Historical, I think that Informational is more ap= propriate because, AFAIK, the technique defined in draft-kompella is not jus= t a documenting an existing solution - it describes is THE ONLY deployed sol= ution for the problem. (If this statement happens to be factually incorrect,= I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074. As 10 years ago we had several deployments of "draft-martini" which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca > Regards, > Sasha > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of= Luca >> Martini >> Sent: Tuesday, September 13, 2011 6:24 PM >> To: Andrew G. Malis >> Cc: l2vpn@ietf.org; pwe3; IETF Discussion >> Subject: Re: Last Call: (Layer 2 Virt= ual >> Private Networks Using BGP for Auto-discovery and Signaling) to Informati= onal >> RFC >> >> I concurr with Andy. >> Given that the WG has made a decision on which control plane technology >> is the standard track technology we should have a statement in this >> document pointing to the standard track rfc4447 so it is clear to anyone >> reading the document. >> In the same way we published the draft-martini documents as historical >> ee should publish this document as historical rfc, to document existing >> implementations. >> >> Luca >> >> On 09/01/11 05:42, Andrew G. Malis wrote: >>> Speaking as an individual, the solution in this draft has been has >>> been operationally deployed in a number of service provider networks, >>> and it should be documented in an informational RFC. >>> >>> Speaking as PWE3 co-chair, I would be happier if this draft required >>> that routers that implement this solution also implement RFC 4447, >>> that RFC 4447 be configured as the default mechanism for pseudowire >>> signaling, and that RFC 4447 was moved from an informational to a >>> normative reference. In practice, I know that routers that implement >>> this also do implement RFC 4447, but I would like to see it in the RFC >>> as well. >>> >>> Thanks, >>> Andy >>> >>> Subject: Last Call: (Layer 2 Virtual Private Networks Using B= GP >>> for Auto-discovery and Signaling) to Informational RFC >>> Date: Tue, 30 Aug 2011 10:50:05 -0700 >>> From: The IESG >>> >>> Reply-To: ietf@ietf.org >>> To: IETF-Announce >>> >>> >>> >>> >>> The IESG has received a request from an individual submitter to cons= ider >>> the following document: >>> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and >>> Signaling' >>> as an Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicit= s >>> final comments on this action. Please send substantive comments to t= he >>> ietf@ietf.org mailing lists by 2011-09-27. >> Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case= , >> please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or= ATM >>> circuits have been around a long time; more recently, Ethernet VP= Ns, >>> including Virtual Private LAN Service, have become popular. >>> Traditional L2VPNs often required a separate Service Provider >>> infrastructure for each type, and yet another for the Internet an= d IP >>> VPNs. In addition, L2VPN provisioning was cumbersome. This docu= ment >>> presents a new approach to the problem of offering L2VPN services >>> where the L2VPN customer's experience is virtually identical to t= hat >>> offered by traditional Layer 2 VPNs, but such that a Service Prov= ider >>> can maintain a single network for L2VPNs, IP VPNs and the Interne= t, >>> as well as a common provisioning methodology for all services. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>> >>> >>> The following IPR Declarations may be related to this I-D: >>> >>> http://datatracker.ietf.org/ipr/1149/ >>> >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf > > > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From tnadeau@lucidvision.com Wed Sep 14 05:42:29 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 D64E621F8C40; Wed, 14 Sep 2011 05:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3XsagbESGvW; Wed, 14 Sep 2011 05:42:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8021F8AF9; Wed, 14 Sep 2011 05:42:23 -0700 (PDT) Received: from [172.20.10.6] (mobile-166-137-137-094.mycingular.net [166.137.137.94]) by lucidvision.com (Postfix) with ESMTP id 080551E1A65D; Wed, 14 Sep 2011 08:44:31 -0400 (EDT) References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> <4E6FAC2A.5060401@cisco.com> In-Reply-To: <4E6FAC2A.5060401@cisco.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <71FDC3E8-2D9F-4C5D-B11D-8D297850D6BC@lucidvision.com> X-Mailer: iPad Mail (8L1) From: Thomas Nadeau Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Wed, 14 Sep 2011 08:45:12 -0400 To: Luca Martini Cc: "l2vpn@ietf.org" , pwe3 , IETF Discussion 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: Wed, 14 Sep 2011 12:42:30 -0000 I agree. Historic seems go be the way to go with this document. Sent from my iPad On Sep 13, 2011, at 3:16 PM, Luca Martini wrote: > On 09/13/11 10:03, Alexander Vainshtein wrote: >> Luca, and all, >>=20 >> I concur with Andy's opinion that the reference to RFC 4447 must become N= ormative (this will not delay the publication is too often the case:-). >>=20 >> As for Informational vs. Historical, I think that Informational is more a= ppropriate because, AFAIK, the technique defined in draft-kompella is not ju= st a documenting an existing solution - it describes is THE ONLY deployed so= lution for the problem. (If this statement happens to be factually incorrect= , I would be happy to learn about the deployed alternatives.) > no, there are several ( I think 3 ) implementations of the > l2vpn-singalling standards track document also known as rfc6074. > There are several deployments of rfc6074. >=20 > As 10 years ago we had several deployments of "draft-martini" which over > time are being updated to rfc4447 , there are some deployments of the > solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still > think that an historical RFC would fit this solution , unless we plan on > expanding it , and pursuing new enhancements to it. >=20 > Luca >=20 >=20 >> Regards, >> Sasha >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Luca >>> Martini >>> Sent: Tuesday, September 13, 2011 6:24 PM >>> To: Andrew G. Malis >>> Cc: l2vpn@ietf.org; pwe3; IETF Discussion >>> Subject: Re: Last Call: (Layer 2 Vir= tual >>> Private Networks Using BGP for Auto-discovery and Signaling) to Informat= ional >>> RFC >>>=20 >>> I concurr with Andy. >>> Given that the WG has made a decision on which control plane technology= >>> is the standard track technology we should have a statement in this >>> document pointing to the standard track rfc4447 so it is clear to anyone= >>> reading the document. >>> In the same way we published the draft-martini documents as historical >>> ee should publish this document as historical rfc, to document existing >>> implementations. >>>=20 >>> Luca >>>=20 >>> On 09/01/11 05:42, Andrew G. Malis wrote: >>>> Speaking as an individual, the solution in this draft has been has >>>> been operationally deployed in a number of service provider networks, >>>> and it should be documented in an informational RFC. >>>>=20 >>>> Speaking as PWE3 co-chair, I would be happier if this draft required >>>> that routers that implement this solution also implement RFC 4447, >>>> that RFC 4447 be configured as the default mechanism for pseudowire >>>> signaling, and that RFC 4447 was moved from an informational to a >>>> normative reference. In practice, I know that routers that implement >>>> this also do implement RFC 4447, but I would like to see it in the RFC >>>> as well. >>>>=20 >>>> Thanks, >>>> Andy >>>>=20 >>>> Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP >>>> for Auto-discovery and Signaling) to Informational RFC >>>> Date: Tue, 30 Aug 2011 10:50:05 -0700 >>>> From: The IESG >>>> >>>> Reply-To: ietf@ietf.org >>>> To: IETF-Announce >>>> >>>>=20 >>>>=20 >>>>=20 >>>> The IESG has received a request from an individual submitter to cons= ider >>>> the following document: >>>> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and= >>>> Signaling' >>>> as an Informational RFC >>>>=20 >>>> The IESG plans to make a decision in the next few weeks, and solicit= s >>>> final comments on this action. Please send substantive comments to t= he >>>> ietf@ietf.org mailing lists by 2011-09-27. >>> Exceptionally, comments may be >>>> sent to iesg@ietf.org instead. In either case= , >>> please retain the >>>> beginning of the Subject line to allow automated sorting. >>>>=20 >>>> Abstract >>>>=20 >>>>=20 >>>> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or= ATM >>>> circuits have been around a long time; more recently, Ethernet VP= Ns, >>>> including Virtual Private LAN Service, have become popular. >>>> Traditional L2VPNs often required a separate Service Provider >>>> infrastructure for each type, and yet another for the Internet an= d IP >>>> VPNs. In addition, L2VPN provisioning was cumbersome. This docu= ment >>>> presents a new approach to the problem of offering L2VPN services= >>>> where the L2VPN customer's experience is virtually identical to t= hat >>>> offered by traditional Layer 2 VPNs, but such that a Service Prov= ider >>>> can maintain a single network for L2VPNs, IP VPNs and the Interne= t, >>>> as well as a common provisioning methodology for all services. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>>>=20 >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>>>=20 >>>>=20 >>>> The following IPR Declarations may be related to this I-D: >>>>=20 >>>> http://datatracker.ietf.org/ipr/1149/ >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. >>=20 >>=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From florin.balus@alcatel-lucent.com Wed Sep 14 10:19: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 ED02A21F873A; Wed, 14 Sep 2011 10:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T73Q97J6eWP; Wed, 14 Sep 2011 10:19:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C9A0521F86A4; Wed, 14 Sep 2011 10:19:30 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p8EHLXo7027071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 12:21:33 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8EHLW70000806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Sep 2011 12:21:33 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 14 Sep 2011 12:21:32 -0500 From: "Balus, Florin Stelian (Florin)" To: Alexander Vainshtein , Luca Martini Date: Wed, 14 Sep 2011 12:21:31 -0500 Subject: RE: [PWE3] Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Topic: [PWE3] Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Index: AcxySbyvOc4/mVo1SdOdUURGHSKGrAABroTyACxyhdA= Message-ID: <2073A6C5467C99478898544C6EBA3F4602BBFE48F5@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> , <4E6FAC2A.5060401@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "l2vpn@ietf.org" , pwe3 , IETF Discussion 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: Wed, 14 Sep 2011 17:19:32 -0000 I do not have a strong opinion on historical vs. experimental but I want to= say that solutions based on RFC 6074 (so called "BGP-AD") have been deploy= ed in multiple networks some of them with mixed vendor environment.=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Tuesday, September 13, 2011 1:15 PM To: Luca Martini Cc: l2vpn@ietf.org; pwe3; IETF Discussion Subject: Re: [PWE3] Last Call: (Layer 2= Virtual Private Networks Using BGP for Auto-discovery and Signaling) to In= formational RFC Luca, The draft in question exists for almost 8 years (the -00 version has been p= osted 2004-01-13), has been implemented and deployed. I have not heard that solutions compliant with RFC 6074 (which is the prope= r analog of 4447 in this case IMO) have been deployed in this interval - a= nd that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficientl= y stable for any potential implementer) for almost 6 years (from 2006-06-12= ). Hence I do not see this case as similar to what happened to the original dr= aft-martini vs. RFC 4447. Do I miss something substantial here? Regards, Sasha ________________________________________ From: Luca Martini [lmartini@cisco.com] Sent: Tuesday, September 13, 2011 9:16 PM To: Alexander Vainshtein Cc: l2vpn@ietf.org; pwe3; IETF Discussion; Andrew G. Malis Subject: Re: Last Call: (Layer 2 Virtua= l Private Networks Using BGP for Auto-discovery and Signaling) to Informati= onal RFC On 09/13/11 10:03, Alexander Vainshtein wrote: > Luca, and all, > > I concur with Andy's opinion that the reference to RFC 4447 must become N= ormative (this will not delay the publication is too often the case:-). > > As for Informational vs. Historical, I think that Informational is more a= ppropriate because, AFAIK, the technique defined in draft-kompella is not j= ust a documenting an existing solution - it describes is THE ONLY deployed = solution for the problem. (If this statement happens to be factually incorr= ect, I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074. As 10 years ago we had several deployments of "draft-martini" which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca > Regards, > Sasha > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Luca >> Martini >> Sent: Tuesday, September 13, 2011 6:24 PM >> To: Andrew G. Malis >> Cc: l2vpn@ietf.org; pwe3; IETF Discussion >> Subject: Re: Last Call: (Layer 2 Vir= tual >> Private Networks Using BGP for Auto-discovery and Signaling) to Informat= ional >> RFC >> >> I concurr with Andy. >> Given that the WG has made a decision on which control plane technology >> is the standard track technology we should have a statement in this >> document pointing to the standard track rfc4447 so it is clear to anyone >> reading the document. >> In the same way we published the draft-martini documents as historical >> ee should publish this document as historical rfc, to document existing >> implementations. >> >> Luca >> >> On 09/01/11 05:42, Andrew G. Malis wrote: >>> Speaking as an individual, the solution in this draft has been has >>> been operationally deployed in a number of service provider networks, >>> and it should be documented in an informational RFC. >>> >>> Speaking as PWE3 co-chair, I would be happier if this draft required >>> that routers that implement this solution also implement RFC 4447, >>> that RFC 4447 be configured as the default mechanism for pseudowire >>> signaling, and that RFC 4447 was moved from an informational to a >>> normative reference. In practice, I know that routers that implement >>> this also do implement RFC 4447, but I would like to see it in the RFC >>> as well. >>> >>> Thanks, >>> Andy >>> >>> Subject: Last Call: (Layer 2 Virtual Private Networks Using = BGP >>> for Auto-discovery and Signaling) to Informational RFC >>> Date: Tue, 30 Aug 2011 10:50:05 -0700 >>> From: The IESG >>> >>> Reply-To: ietf@ietf.org >>> To: IETF-Announce >>> >>> >>> >>> >>> The IESG has received a request from an individual submitter to con= sider >>> the following document: >>> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery an= d >>> Signaling' >>> as an Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solici= ts >>> final comments on this action. Please send substantive comments to = the >>> ietf@ietf.org mailing lists by 2011-09-27. >> Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either cas= e, >> please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay o= r ATM >>> circuits have been around a long time; more recently, Ethernet V= PNs, >>> including Virtual Private LAN Service, have become popular. >>> Traditional L2VPNs often required a separate Service Provider >>> infrastructure for each type, and yet another for the Internet a= nd IP >>> VPNs. In addition, L2VPN provisioning was cumbersome. This doc= ument >>> presents a new approach to the problem of offering L2VPN service= s >>> where the L2VPN customer's experience is virtually identical to = that >>> offered by traditional Layer 2 VPNs, but such that a Service Pro= vider >>> can maintain a single network for L2VPNs, IP VPNs and the Intern= et, >>> as well as a common provisioning methodology for all services. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>> >>> >>> The following IPR Declarations may be related to this I-D: >>> >>> http://datatracker.ietf.org/ipr/1149/ >>> >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf > > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Wed Sep 14 11:11:29 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 B258D21F8876; Wed, 14 Sep 2011 11:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtoPGi9RYHFl; Wed, 14 Sep 2011 11:11:28 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85521F8468; Wed, 14 Sep 2011 11:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=8238; q=dns/txt; s=iport; t=1316024018; x=1317233618; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gM1dX8oqT+dlh/oI4ykDq5QjUmS2zFkuh7fT4n56mug=; b=jy6A9LoXywpl97Y56bPvRrB/z8ZXfjOczffmm0hFNyn45v89C9hXXnbC tNEeMpzAdjUKoeJd5IvsoIiAOaAv2rBOYZjO1FRLj/x8TPI15/nu6ny9g 6jXUt1l9mazXa0WKm1ZADjaGUxKva7edcwauwPBSukGyRCRO286L19IrZ 4=; X-IronPort-AV: E=Sophos;i="4.68,381,1312156800"; d="scan'208";a="54597133" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Sep 2011 18:13:35 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8EIDZwh017748; Wed, 14 Sep 2011 18:13:35 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p8EIDXPV002307; Wed, 14 Sep 2011 19:13:34 +0100 (BST) Message-ID: <4E70EECD.5010100@cisco.com> Date: Wed, 14 Sep 2011 19:13:33 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Alexander Vainshtein Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> , <4E6FAC2A.5060401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , pwe3 , Luca Martini , IETF Discussion X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:11:29 -0000 It is clear that: 1) RFC6074 is the IETF recommended approach. 2) That draft-kompella-l2vpn-l2vpn is in active deployment. The question is whether the number of independent deployments of draft-kompella-l2vpn-l2vpn is increasing or not. In other words is this a legacy approach that will over time decline, or is it a parallel alternative that will be actively chosen by some subset of operators going forward and which will be implemented by more than one vendor. - Stewart On 13/09/2011 21:14, Alexander Vainshtein wrote: > Luca, > The draft in question exists for almost 8 years (the -00 version has been posted 2004-01-13), has been implemented and deployed. > > I have not heard that solutions compliant with RFC 6074 (which is the proper analog of 4447 in this case IMO) have been deployed in this interval - and that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficiently stable for any potential implementer) for almost 6 years (from 2006-06-12). > > Hence I do not see this case as similar to what happened to the original draft-martini vs. RFC 4447. > > Do I miss something substantial here? > > Regards, > Sasha > ________________________________________ > From: Luca Martini [lmartini@cisco.com] > Sent: Tuesday, September 13, 2011 9:16 PM > To: Alexander Vainshtein > Cc: l2vpn@ietf.org; pwe3; IETF Discussion; Andrew G. Malis > Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC > > On 09/13/11 10:03, Alexander Vainshtein wrote: >> Luca, and all, >> >> I concur with Andy's opinion that the reference to RFC 4447 must become Normative (this will not delay the publication is too often the case:-). >> >> As for Informational vs. Historical, I think that Informational is more appropriate because, AFAIK, the technique defined in draft-kompella is not just a documenting an existing solution - it describes is THE ONLY deployed solution for the problem. (If this statement happens to be factually incorrect, I would be happy to learn about the deployed alternatives.) > no, there are several ( I think 3 ) implementations of the > l2vpn-singalling standards track document also known as rfc6074. > There are several deployments of rfc6074. > > As 10 years ago we had several deployments of "draft-martini" which over > time are being updated to rfc4447 , there are some deployments of the > solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still > think that an historical RFC would fit this solution , unless we plan on > expanding it , and pursuing new enhancements to it. > > Luca > > >> Regards, >> Sasha >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Luca >>> Martini >>> Sent: Tuesday, September 13, 2011 6:24 PM >>> To: Andrew G. Malis >>> Cc: l2vpn@ietf.org; pwe3; IETF Discussion >>> Subject: Re: Last Call: (Layer 2 Virtual >>> Private Networks Using BGP for Auto-discovery and Signaling) to Informational >>> RFC >>> >>> I concurr with Andy. >>> Given that the WG has made a decision on which control plane technology >>> is the standard track technology we should have a statement in this >>> document pointing to the standard track rfc4447 so it is clear to anyone >>> reading the document. >>> In the same way we published the draft-martini documents as historical >>> ee should publish this document as historical rfc, to document existing >>> implementations. >>> >>> Luca >>> >>> On 09/01/11 05:42, Andrew G. Malis wrote: >>>> Speaking as an individual, the solution in this draft has been has >>>> been operationally deployed in a number of service provider networks, >>>> and it should be documented in an informational RFC. >>>> >>>> Speaking as PWE3 co-chair, I would be happier if this draft required >>>> that routers that implement this solution also implement RFC 4447, >>>> that RFC 4447 be configured as the default mechanism for pseudowire >>>> signaling, and that RFC 4447 was moved from an informational to a >>>> normative reference. In practice, I know that routers that implement >>>> this also do implement RFC 4447, but I would like to see it in the RFC >>>> as well. >>>> >>>> Thanks, >>>> Andy >>>> >>>> Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP >>>> for Auto-discovery and Signaling) to Informational RFC >>>> Date: Tue, 30 Aug 2011 10:50:05 -0700 >>>> From: The IESG >>>> >>>> Reply-To: ietf@ietf.org >>>> To: IETF-Announce >>>> >>>> >>>> >>>> >>>> The IESG has received a request from an individual submitter to consider >>>> the following document: >>>> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and >>>> Signaling' >>>> as an Informational RFC >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2011-09-27. >>> Exceptionally, comments may be >>>> sent to iesg@ietf.org instead. In either case, >>> please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> >>>> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM >>>> circuits have been around a long time; more recently, Ethernet VPNs, >>>> including Virtual Private LAN Service, have become popular. >>>> Traditional L2VPNs often required a separate Service Provider >>>> infrastructure for each type, and yet another for the Internet and IP >>>> VPNs. In addition, L2VPN provisioning was cumbersome. This document >>>> presents a new approach to the problem of offering L2VPN services >>>> where the L2VPN customer's experience is virtually identical to that >>>> offered by traditional Layer 2 VPNs, but such that a Service Provider >>>> can maintain a single network for L2VPNs, IP VPNs and the Internet, >>>> as well as a common provisioning methodology for all services. >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>>> >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>>> >>>> >>>> The following IPR Declarations may be related to this I-D: >>>> >>>> http://datatracker.ietf.org/ipr/1149/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >> >> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. >> >> > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From kireeti@juniper.net Wed Sep 14 14:07:10 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 BEE5421F8CC3; Wed, 14 Sep 2011 14:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WY8t5PJikXS; Wed, 14 Sep 2011 14:07:09 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9146621F8CBE; Wed, 14 Sep 2011 14:07:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTnEX9fzscE5UA/GcPw/JKD6Wdd3IOmY9@postini.com; Wed, 14 Sep 2011 14:09:19 PDT Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 14 Sep 2011 14:08:31 -0700 Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB11-HQ.jnpr.net ([::1]) with mapi; Wed, 14 Sep 2011 14:08:30 -0700 From: Kireeti Kompella To: "stbryant@cisco.com" Date: Wed, 14 Sep 2011 14:08:29 -0700 Subject: Re: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Topic: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Thread-Index: AcxzInQwn2oVChbYQ8GZkRfbiycwHQ== Message-ID: <65F110B8-5E16-43D1-ADA8-B2CECBB1B0F4@juniper.net> References: <20110830175005.2032.89819.idtracker@ietfa.amsl.com> <4E5F635B.80500@cisco.com> <4E6F7581.20102@cisco.com> , <4E6FAC2A.5060401@cisco.com> <4E70EECD.5010100@cisco.com> In-Reply-To: <4E70EECD.5010100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: cf379b08-bd3c-4ba0-a9bb-2500e331bd80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , IETF Discussion , Kireeti Kompella , Luca Martini , pwe3 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: Wed, 14 Sep 2011 21:07:10 -0000 Hi Stewart, On Sep 14, 2011, at 11:13 , Stewart Bryant wrote: > It is clear that: >=20 > 1) RFC6074 is the IETF recommended approach. > 2) That draft-kompella-l2vpn-l2vpn is in active deployment. >=20 > The question is whether the number of independent > deployments of draft-kompella-l2vpn-l2vpn is > increasing or not. In other words is this a legacy > approach that will over time decline, or is it a > parallel alternative that will be actively chosen > by some subset of operators going forward and > which will be implemented by more than one vendor. a) The deployments are increasing. This is the chosen approach for some su= bset of operators. This is not a legacy approach. I can't say what will h= appen going forward, but to the extent that I can see, this is the chosen d= irection for some subset of operators. b) There are implementations by more than one vendor. c) The BBF will build solutions on top of this, in parallel with other appr= oaches. Kireeti. > - Stewart >=20 >=20 > On 13/09/2011 21:14, Alexander Vainshtein wrote: >> Luca, >> The draft in question exists for almost 8 years (the -00 version has bee= n posted 2004-01-13), has been implemented and deployed. >>=20 >> I have not heard that solutions compliant with RFC 6074 (which is the pr= oper analog of 4447 in this case IMO) have been deployed in this interval = - and that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficie= ntly stable for any potential implementer) for almost 6 years (from 2006-06= -12). >>=20 >> Hence I do not see this case as similar to what happened to the original= draft-martini vs. RFC 4447. >>=20 >> Do I miss something substantial here? >>=20 >> Regards, >> Sasha >> ________________________________________ >> From: Luca Martini [lmartini@cisco.com] >> Sent: Tuesday, September 13, 2011 9:16 PM >> To: Alexander Vainshtein >> Cc: l2vpn@ietf.org; pwe3; IETF Discussion; Andrew G. Malis >> Subject: Re: Last Call: (Layer 2 Vir= tual Private Networks Using BGP for Auto-discovery and Signaling) to Inform= ational RFC >>=20 >> On 09/13/11 10:03, Alexander Vainshtein wrote: >>> Luca, and all, >>>=20 >>> I concur with Andy's opinion that the reference to RFC 4447 must become= Normative (this will not delay the publication is too often the case:-). >>>=20 >>> As for Informational vs. Historical, I think that Informational is more= appropriate because, AFAIK, the technique defined in draft-kompella is not= just a documenting an existing solution - it describes is THE ONLY deploye= d solution for the problem. (If this statement happens to be factually inco= rrect, I would be happy to learn about the deployed alternatives.) >> no, there are several ( I think 3 ) implementations of the >> l2vpn-singalling standards track document also known as rfc6074. >> There are several deployments of rfc6074. >>=20 >> As 10 years ago we had several deployments of "draft-martini" which over >> time are being updated to rfc4447 , there are some deployments of the >> solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still >> think that an historical RFC would fit this solution , unless we plan on >> expanding it , and pursuing new enhancements to it. >>=20 >> Luca >>=20 >>=20 >>> Regards, >>> Sasha >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of Luca >>>> Martini >>>> Sent: Tuesday, September 13, 2011 6:24 PM >>>> To: Andrew G. Malis >>>> Cc: l2vpn@ietf.org; pwe3; IETF Discussion >>>> Subject: Re: Last Call: (Layer 2 V= irtual >>>> Private Networks Using BGP for Auto-discovery and Signaling) to Inform= ational >>>> RFC >>>>=20 >>>> I concurr with Andy. >>>> Given that the WG has made a decision on which control plane technolo= gy >>>> is the standard track technology we should have a statement in this >>>> document pointing to the standard track rfc4447 so it is clear to anyo= ne >>>> reading the document. >>>> In the same way we published the draft-martini documents as historical >>>> ee should publish this document as historical rfc, to document existin= g >>>> implementations. >>>>=20 >>>> Luca >>>>=20 >>>> On 09/01/11 05:42, Andrew G. Malis wrote: >>>>> Speaking as an individual, the solution in this draft has been has >>>>> been operationally deployed in a number of service provider networks, >>>>> and it should be documented in an informational RFC. >>>>>=20 >>>>> Speaking as PWE3 co-chair, I would be happier if this draft required >>>>> that routers that implement this solution also implement RFC 4447, >>>>> that RFC 4447 be configured as the default mechanism for pseudowire >>>>> signaling, and that RFC 4447 was moved from an informational to a >>>>> normative reference. In practice, I know that routers that implement >>>>> this also do implement RFC 4447, but I would like to see it in the RF= C >>>>> as well. >>>>>=20 >>>>> Thanks, >>>>> Andy >>>>>=20 >>>>> Subject: Last Call: (Layer 2 Virtual Private Networks Usin= g BGP >>>>> for Auto-discovery and Signaling) to Informational RFC >>>>> Date: Tue, 30 Aug 2011 10:50:05 -0700 >>>>> From: The IESG >>>>> >>>>> Reply-To: ietf@ietf.org >>>>> To: IETF-Announce >>>>> >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IESG has received a request from an individual submitter to c= onsider >>>>> the following document: >>>>> - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery = and >>>>> Signaling' >>>>> as an Informational RFC >>>>>=20 >>>>> The IESG plans to make a decision in the next few weeks, and soli= cits >>>>> final comments on this action. Please send substantive comments t= o the >>>>> ietf@ietf.org mailing lists by 2011-09-27. >>>> Exceptionally, comments may be >>>>> sent to iesg@ietf.org instead. In either c= ase, >>>> please retain the >>>>> beginning of the Subject line to allow automated sorting. >>>>>=20 >>>>> Abstract >>>>>=20 >>>>>=20 >>>>> Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay= or ATM >>>>> circuits have been around a long time; more recently, Ethernet= VPNs, >>>>> including Virtual Private LAN Service, have become popular. >>>>> Traditional L2VPNs often required a separate Service Provider >>>>> infrastructure for each type, and yet another for the Internet= and IP >>>>> VPNs. In addition, L2VPN provisioning was cumbersome. This d= ocument >>>>> presents a new approach to the problem of offering L2VPN servi= ces >>>>> where the L2VPN customer's experience is virtually identical t= o that >>>>> offered by traditional Layer 2 VPNs, but such that a Service P= rovider >>>>> can maintain a single network for L2VPNs, IP VPNs and the Inte= rnet, >>>>> as well as a common provisioning methodology for all services. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The file can be obtained via >>>>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>>>>=20 >>>>> IESG discussion can be tracked via >>>>> http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ >>>>>=20 >>>>>=20 >>>>> The following IPR Declarations may be related to this I-D: >>>>>=20 >>>>> http://datatracker.ietf.org/ipr/1149/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf >>>=20 >>> This e-mail message is intended for the recipient only and contains inf= ormation which is CONFIDENTIAL and which may be proprietary to ECI Telecom.= If you have received this transmission in error, please inform us by e-mai= l, phone or fax, and then delete the original and all copies thereof. >>>=20 >>>=20 >> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof. >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >>=20 >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From raymond.key@hotmail.com Mon Sep 26 15:51:40 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 1523811E810F for ; Mon, 26 Sep 2011 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSfNHWOL1iDa for ; Mon, 26 Sep 2011 15:51:38 -0700 (PDT) Received: from snt0-omc4-s24.snt0.hotmail.com (snt0-omc4-s24.snt0.hotmail.com [65.55.90.227]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB811E80D4 for ; Mon, 26 Sep 2011 15:51:38 -0700 (PDT) Received: from SNT123-W10 ([65.55.90.200]) by snt0-omc4-s24.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 15:54:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3f91669f-d541-47db-9933-c757f7853463_" X-Originating-IP: [113.92.40.143] From: Raymond Key Sender: To: Subject: RE: Further Requirements Proposed for E-Tree Date: Tue, 27 Sep 2011 09:24:22 +1030 Importance: Normal In-Reply-To: <9435EDACD941174099E143BCA2BCD615F7AD0C87B4@HE101452.emea1.cds.t-internal.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B041435F9@SZXEML508-MBX.china.huawei.com>, , <3B0A1BED22CAD649A1B3E97BE5DDD68B041439E2@SZXEML508-MBX.china.huawei.com>, <9435EDACD941174099E143BCA2BCD615F7AD0C87B4@HE101452.emea1.cds.t-internal.com> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 22:54:23.0050 (UTC) FILETIME=[3BB89AA0:01CC7C9F] 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, 26 Sep 2011 22:51:40 -0000 --_3f91669f-d541-47db-9933-c757f7853463_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi L2VPN working group=2C =20 I have a slightly different opinion. I don't think we need to add more tex= t about service frame description in this requirement document. =20 My understanding is that in MEF specifications the service frame descriptio= n is applicable to all MEF defined service types=2C not particular for E-Tr= ee. Many operators has been using VPLS to provide E-LAN services=2C and ab= le to support the service frame description in the MEF specificaitons. Now= what we need to add is only the Leaf-to-Leaf restriction. It would be goo= d to focus on this only difference between E-LAN and E-Tree=2C keep the req= uirement document simple (actully the draft has already included pointers t= o the MEF specifications). Besides=2C it seems to me this have no impact o= n various solution approaches currently proposed. Best regards=2C Raymond Key=20 =20 > From: Manuel.Paul@telekom.de > To: jiangyuanlong@huawei.com=3B josh.rogers@twcable.com=3B draft-key-l2vp= n-vpls-etree-reqt@tools.ietf.org > CC: l2vpn@ietf.org > Date: Wed=2C 3 Aug 2011 16:49:34 +0200 > Subject: RE: Further Requirements Proposed for E-Tree >=20 > Hi=2C >=20 > As this work is for the support of a service defined by the MEF=2C I woul= d prefer to keep alignment with MEF service specs as much as possible. >=20 > I believe the additions re service transparency proposed by Yuanlong=2C a= s written below=2C would sufficiently cover it and I support them as is. >=20 > Please see one more comment inline below. >=20 > Thanks=2C > Manuel >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of > > Jiangyuanlong > > Sent: Wednesday=2C August 03=2C 2011 4:06 AM > > To: Rogers=2C Josh=3B draft-key-l2vpn-vpls-etree-reqt@tools.ietf.org > > Cc: l2vpn@ietf.org > > Subject: RE: Further Requirements Proposed for E-Tree > > > > Hi Josh=2C > > > > I also prefer to preserve the service transparency=2C though the statem= ent > > seems more restrictive than MEF 10.2 (where the preservation of C-VLAN = ID > > and CoS are configurable parameters rather than mandating). > > Can more service providers clarify their requirements on the service > > transparency? > > > > Thanks > > Yuanlong > > > > -----Original Message----- > > From: Rogers=2C Josh [mailto:josh.rogers@twcable.com] > > Sent: Tuesday=2C August 02=2C 2011 10:30 PM > > To: Jiangyuanlong=3B draft-key-l2vpn-vpls-etree-reqt@tools.ietf.org > > Cc: l2vpn@ietf.org > > Subject: Re: Further Requirements Proposed for E-Tree > > > > Would it be to restrictive to change #2 to: > > > > 2) Solution must maintain E-Tree Service frame transparently=2C if > > containing a IEEE 802.1Q Customer VLAN Tag=2C the solution MUST be able= to > > preserve the VLAN ID in the Customer VLAN Tag=2C and if not containing = a > > IEEE 802.1Q Customer VLAN Tag=2C lack of Customer VLAN tag must be pres= erved > > as well. > > > > I imagine that could be worded slightly better=2C but the notion of > > preserving the frame's Customer tag (or lack of) is something I'd like = to > > see captured. I've seen so many implementations called 'ETREE' that > > disagree with this=2C however I'd like to hear from others whether this= is > > agreeable or not=2C and if not=2C why? > [MP:] While customer service VLAN preservation is a feature requiring imp= lementation support=2C isn't the other case rather a (pre-)configuration is= sue? > > > > > > From: Jiangyuanlong > > > > > Date: Tue=2C 2 Aug 2011 02:13:41 -0400 > > To: "draft-key-l2vpn-vpls-etree-reqt@tools.ietf.org > l2vpn-vpls-etree-reqt@tools.ietf.org>" > reqt@tools.ietf.org > reqt@tools.ietf.org>> > > Cc: "l2vpn@ietf.org" > > > > > Subject: Further Requirements Proposed for E-Tree > > > > > > Hello authors=2C > > > > > > > > During the 81th IETF meeting=2C it seemed there are ambiguities with re= gard > > to the supported types of E-Tree service frames > > > > in the E-Tree requirements. To align with the MEF standard (i.e.=2C the > > specifications in Section 6.5.3 and 6.6 of MEF 10.2)=2C > > > > I suggest the following E-Tree requirements should be added: > > 1) E-Tree Service Frame MAY be untagged=2C priority tagged=2C or contai= n an > > IEEE 802.1Q Customer VLAN Tag. > > 2) If the E-Tree Service Frame contains an IEEE 802.1Q Customer VLAN Ta= g=2C > > the solution MUST be able to preserve > > > > VLAN ID in this Customer VLAN Tag. > > 3) If the E-Tree Service Frame is priority tagged or contains an IEEE > > 802.1Q Customer VLAN Tag=2C the solution MUST > > > > be able to preserve the CoS (Class of Service). > > > > > > > > Best regards > > Yuanlong > > > > > > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable > > proprietary information=2C which is privileged=2C confidential=2C or su= bject to > > copyright belonging to Time Warner Cable. This E-mail is intended solel= y > > for the use of the individual or entity to which it is addressed. If yo= u > > are not the intended recipient of this E-mail=2C you are hereby notifie= d > > that any dissemination=2C distribution=2C copying=2C or action taken in= relation > > to the contents of and attachments to this E-mail is strictly prohibite= d > > and may be unlawful. If you have received this E-mail in error=2C pleas= e > > notify the sender immediately and permanently delete the original and a= ny > > copy of this E-mail and any printout. = --_3f91669f-d541-47db-9933-c757f7853463_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi L2VPN working group=2C
 =3B
I have a slightly different opinion. =3B I don't think we need to add m= ore text about =3Bservice frame description in this requirement documen= t.
 =3B
My understanding is that in MEF specifications the service frame descriptio= n is applicable to all MEF defined service types=2C not particular for E-Tr= ee. =3B Many operators has been using VPLS to provide E-LAN services=2C= and able to support the service frame description in the MEF specificaiton= s. =3B Now what we need to add is only the Leaf-to-Leaf restriction.&nb= sp=3B It would be good to focus on this only difference between E-LAN and E= -Tree=2C keep the requirement document simple (actully the draft has alread= y included pointers to the MEF specifications). =3B Besides=2C it seems= to me this have no impact on various solution approaches currently propose= d.

Best regards=2C
Raymond Key =3B

 =3B
>=3B From: Manuel.Paul@telekom.de
>=3B To: jiangyuanlong@huawei.com= =3B josh.rogers@twcable.com=3B draft-key-l2vpn-vpls-etree-reqt@tools.ietf.o= rg
>=3B CC: l2vpn@ietf.org
>=3B Date: Wed=2C 3 Aug 2011 16:49:34 = +0200
>=3B Subject: RE: Further Requirements Proposed for E-Tree
&g= t=3B
>=3B Hi=2C
>=3B
>=3B As this work is for the support = of a service defined by the MEF=2C I would prefer to keep alignment with ME= F service specs as much as possible.
>=3B
>=3B I believe the add= itions re service transparency proposed by Yuanlong=2C as written below=2C = would sufficiently cover it and I support them as is.
>=3B
>=3B = Please see one more comment inline below.
>=3B
>=3B Thanks=2C>=3B Manuel
>=3B
>=3B >=3B -----Original Message-----
&g= t=3B >=3B From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On= Behalf Of
>=3B >=3B Jiangyuanlong
>=3B >=3B Sent: Wednesday= =2C August 03=2C 2011 4:06 AM
>=3B >=3B To: Rogers=2C Josh=3B draft-= key-l2vpn-vpls-etree-reqt@tools.ietf.org
>=3B >=3B Cc: l2vpn@ietf.or= g
>=3B >=3B Subject: RE: Further Requirements Proposed for E-Tree>=3B >=3B
>=3B >=3B Hi Josh=2C
>=3B >=3B
>=3B >= =3B I also prefer to preserve the service transparency=2C though the statem= ent
>=3B >=3B seems more restrictive than MEF 10.2 (where the preser= vation of C-VLAN ID
>=3B >=3B and CoS are configurable parameters ra= ther than mandating).
>=3B >=3B Can more service providers clarify t= heir requirements on the service
>=3B >=3B transparency?
>=3B &= gt=3B
>=3B >=3B Thanks
>=3B >=3B Yuanlong
>=3B >=3B>=3B >=3B -----Original Message-----
>=3B >=3B From: Rogers=2C = Josh [mailto:josh.rogers@twcable.com]
>=3B >=3B Sent: Tuesday=2C Aug= ust 02=2C 2011 10:30 PM
>=3B >=3B To: Jiangyuanlong=3B draft-key-l2v= pn-vpls-etree-reqt@tools.ietf.org
>=3B >=3B Cc: l2vpn@ietf.org
&g= t=3B >=3B Subject: Re: Further Requirements Proposed for E-Tree
>=3B= >=3B
>=3B >=3B Would it be to restrictive to change #2 to:
>= =3B >=3B
>=3B >=3B 2) Solution must maintain E-Tree Service frame = transparently=2C if
>=3B >=3B containing a IEEE 802.1Q Customer VLAN= Tag=2C the solution MUST be able to
>=3B >=3B preserve the VLAN ID = in the Customer VLAN Tag=2C and if not containing a
>=3B >=3B IEEE 8= 02.1Q Customer VLAN Tag=2C lack of Customer VLAN tag must be preserved
&= gt=3B >=3B as well.
>=3B >=3B
>=3B >=3B I imagine that coul= d be worded slightly better=2C but the notion of
>=3B >=3B preservin= g the frame's Customer tag (or lack of) is something I'd like to
>=3B = >=3B see captured. I've seen so many implementations called 'ETREE' that<= BR>>=3B >=3B disagree with this=2C however I'd like to hear from others= whether this is
>=3B >=3B agreeable or not=2C and if not=2C why?>=3B [MP:] While customer service VLAN preservation is a feature requiri= ng implementation support=2C isn't the other case rather a (pre-)configurat= ion issue?
>=3B >=3B
>=3B >=3B
>=3B >=3B From: Jiangyu= anlong
>=3B >=3B <=3Bjiangyuanlong@huawei.com<=3Bmailto:jiangyua= nlong@huawei.com>=3B>=3B
>=3B >=3B Date: Tue=2C 2 Aug 2011 02:13= :41 -0400
>=3B >=3B To: "draft-key-l2vpn-vpls-etree-reqt@tools.ietf.= org<=3Bmailto:draft-key-
>=3B >=3B l2vpn-vpls-etree-reqt@tools.iet= f.org>=3B" <=3Bdraft-key-l2vpn-vpls-etree-
>=3B >=3B reqt@tools.= ietf.org<=3Bmailto:draft-key-l2vpn-vpls-etree-
>=3B >=3B reqt@tool= s.ietf.org>=3B>=3B
>=3B >=3B Cc: "l2vpn@ietf.org<=3Bmailto:l2v= pn@ietf.org>=3B"
>=3B >=3B <=3Bl2vpn@ietf.org<=3Bmailto:l2vpn@= ietf.org>=3B>=3B
>=3B >=3B Subject: Further Requirements Propose= d for E-Tree
>=3B >=3B
>=3B >=3B
>=3B >=3B Hello autho= rs=2C
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B D= uring the 81th IETF meeting=2C it seemed there are ambiguities with regard<= BR>>=3B >=3B to the supported types of E-Tree service frames
>=3B = >=3B
>=3B >=3B in the E-Tree requirements. To align with the MEF s= tandard (i.e.=2C the
>=3B >=3B specifications in Section 6.5.3 and 6= .6 of MEF 10.2)=2C
>=3B >=3B
>=3B >=3B I suggest the followin= g E-Tree requirements should be added:
>=3B >=3B 1) E-Tree Service F= rame MAY be untagged=2C priority tagged=2C or contain an
>=3B >=3B I= EEE 802.1Q Customer VLAN Tag.
>=3B >=3B 2) If the E-Tree Service Fra= me contains an IEEE 802.1Q Customer VLAN Tag=2C
>=3B >=3B the soluti= on MUST be able to preserve
>=3B >=3B
>=3B >=3B VLAN ID in th= is Customer VLAN Tag.
>=3B >=3B 3) If the E-Tree Service Frame is pr= iority tagged or contains an IEEE
>=3B >=3B 802.1Q Customer VLAN Tag= =2C the solution MUST
>=3B >=3B
>=3B >=3B be able to preserve= the CoS (Class of Service).
>=3B >=3B
>=3B >=3B
>=3B &g= t=3B
>=3B >=3B Best regards
>=3B >=3B Yuanlong
>=3B >= =3B
>=3B >=3B
>=3B >=3B
>=3B >=3B ____________________= ____________
>=3B >=3B This E-mail and any of its attachments may co= ntain Time Warner Cable
>=3B >=3B proprietary information=2C which i= s privileged=2C confidential=2C or subject to
>=3B >=3B copyright be= longing to Time Warner Cable. This E-mail is intended solely
>=3B >= =3B for the use of the individual or entity to which it is addressed. If yo= u
>=3B >=3B are not the intended recipient of this E-mail=2C you are= hereby notified
>=3B >=3B that any dissemination=2C distribution=2C= copying=2C or action taken in relation
>=3B >=3B to the contents of= and attachments to this E-mail is strictly prohibited
>=3B >=3B and= may be unlawful. If you have received this E-mail in error=2C please
&g= t=3B >=3B notify the sender immediately and permanently delete the origin= al and any
>=3B >=3B copy of this E-mail and any printout.
=
= --_3f91669f-d541-47db-9933-c757f7853463_-- From lizhong.jin@zte.com.cn Wed Sep 28 06:46: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 B6D8D21F8B00 for ; Wed, 28 Sep 2011 06:46:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzSc6sVJXKhM for ; Wed, 28 Sep 2011 06:46:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0021F85BB for ; Wed, 28 Sep 2011 06:46:23 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713577109098; Wed, 28 Sep 2011 21:47:22 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 75544.577109098; Wed, 28 Sep 2011 21:48:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p8SDmcr4021866 for ; Wed, 28 Sep 2011 21:48:38 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <20110928133823.30613.3191.idtracker@ietfa.amsl.com> To: l2vpn@ietf.org Subject: Request comments for draft-liu-l2vpn-vpls-inter-domain-redundancy-01 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Lizhong Jin Date: Wed, 28 Sep 2011 21:48:25 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-28 21:48:36, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-28 21:48:36, Serialize complete at 2011-09-28 21:48:36, S/MIME Sign failed at 2011-09-28 21:48:37: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-28 21:48:40, Serialize complete at 2011-09-28 21:48:40 Content-Type: multipart/alternative; boundary="=_alternative 004BDC4E48257919_=" X-MAIL: mse01.zte.com.cn p8SDmcr4021866 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: Wed, 28 Sep 2011 13:46:54 -0000 This is a multipart message in MIME format. --=_alternative 004BDC4E48257919_= Content-Type: text/plain; charset="US-ASCII" Dear all, We update the draft with the feedback from IETF 81. And we think the value of this draft is to introduce VPLS inter-domain redundancy mechanism, as complement for RFC4762 section 10.3. We also describe the MAC withdraw procedure in such inter-domain scenario. Would be appreciated if you could raise some comments. And also please let us know if you think such a draft is useful or valuable. Thanks Lizhong internet-drafts@ietf.org wrote on 2011-09-28 21:38:23: > A new version of I-D, draft-liu-l2vpn-vpls-inter-domain- > redundancy-01.txt has been successfully submitted by Lizhong Jin and > posted to the IETF repository. > > Filename: draft-liu-l2vpn-vpls-inter-domain-redundancy > Revision: 01 > Title: Node redundancy provisioning for VPLS Inter-domain > Creation date: 2011-09-28 > WG ID: Individual Submission > Number of pages: 8 > > Abstract: > In many VPLS deployment based on [RFC4762], inter-domain has been > deployed without node redundancy, or only with node redundancy in one > domain. This document describes how to deploy inter-domain VPLS > based on [RFC4762] with node redundancy in both domain. The draft > reuses the existing protocols without introducing any new protocols. > > > > > The IETF Secretariat > -------------------------------------------------------- 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 004BDC4E48257919_= Content-Type: text/html; charset="US-ASCII"
Dear all,
We update the draft with the feedback from IETF 81. And we think the value of this draft is to introduce VPLS inter-domain redundancy mechanism, as complement for RFC4762 section 10.3. We also describe the MAC withdraw procedure in such inter-domain scenario.
Would be appreciated if you could raise some comments. And also please let us know if you think such a draft is useful or valuable.

Thanks
Lizhong
 

internet-drafts@ietf.org wrote on 2011-09-28 21:38:23:

> A new version of I-D, draft-liu-l2vpn-vpls-inter-domain-
> redundancy-01.txt has been successfully submitted by Lizhong Jin and
> posted to the IETF repository.
>
> Filename:    draft-liu-l2vpn-vpls-inter-domain-redundancy
> Revision:    01
> Title:       Node redundancy provisioning for VPLS Inter-domain
> Creation date:    2011-09-28
> WG ID:       Individual Submission
> Number of pages: 8
>
> Abstract:
>    In many VPLS deployment based on [RFC4762], inter-domain has been
>    deployed without node redundancy, or only with node redundancy in one
>    domain.  This document describes how to deploy inter-domain VPLS
>    based on [RFC4762] with node redundancy in both domain.  The draft
>    reuses the existing protocols without introducing any new protocols.
>
>                                                                              
>
>
> The IETF Secretariat
> 

--------------------------------------------------------
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 004BDC4E48257919_=-- From giles.heron@gmail.com Thu Sep 29 12:29:48 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 E566A1F0C43 for ; Thu, 29 Sep 2011 12:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj8FcEAKsGZ6 for ; Thu, 29 Sep 2011 12:29:45 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 73C851F0C3D for ; Thu, 29 Sep 2011 12:29:45 -0700 (PDT) Received: by pzk37 with SMTP id 37so2417653pzk.9 for ; Thu, 29 Sep 2011 12:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=XtCtGYbCG6nhZILunytn7hUJQL89Wt59lyQG4biAcoc=; b=eddtmUQEf4UYrJ8gcEvR2GLFOpSHhTK67nVS5rao4H0pyAX6I1ULkBgEEwf2zgHc7j WUtqHo9LuM0GsOlia7eCj2aaoEzMr44ZAJtO67/6vbvJdGd3G0upPs50QH7EvUOVprUc dVpvC9PHExELkCY8eZJadV6M+6JzoV5G10qRc= Received: by 10.68.122.133 with SMTP id ls5mr35171427pbb.57.1317324757210; Thu, 29 Sep 2011 12:32:37 -0700 (PDT) Received: from [171.71.145.180] (dhcp-171-71-145-180.cisco.com. [171.71.145.180]) by mx.google.com with ESMTPS id ji3sm9619485pbc.2.2011.09.29.12.32.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Sep 2011 12:32:36 -0700 (PDT) User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Thu, 29 Sep 2011 20:32:34 +0100 Subject: WG adoption of draft-key-l2vpn-vpls-etree-reqt? From: Giles Heron To: Message-ID: Thread-Topic: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Index: Acx+3olnBdW6oUmrHUWspYzlTDElSg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 29 Sep 2011 19:29:49 -0000 This is a request to gauge consensus as to whether: http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 should be accepted as an L2VPN WG draft. Now that we've adopted the new charter E-Tree is in scope, and we have a milestone item to submit a requirements draft for E-Tree to IESG by March 2012. If you think this draft is a good starting point for those requirements then please reply indicating your support for the draft. If not then please reply giving some reasons why you think this draft shouldn't be adopted - which we can then debate. Please respond by Thursday 13th of October. Thanks! Nabil & Giles From simon.delord@gmail.com Thu Sep 29 14:10:40 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 B218E21F8EDF for ; Thu, 29 Sep 2011 14:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBHu+SY-poJA for ; Thu, 29 Sep 2011 14:10:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E243C21F8CD0 for ; Thu, 29 Sep 2011 14:10:39 -0700 (PDT) Received: by fxd18 with SMTP id 18so2435686fxd.31 for ; Thu, 29 Sep 2011 14:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5sOaf46vr708cVLhUsMhyi1iYxkx5x9Yy41D2HU72tk=; b=Ket2SmSElomf8qKcnvrAo3ghU1dwOBRBooTv/6M8ZfjByrwWhjHODU2B/R7kB1WbiD 4zQN+PTGbPsV6erfFzRBea8gXFJ7SEype16XcrAMHZuK4E1H/h/isQxHAk5JCYvMR6hj y3aNnxESSV5mH/NBeZtWU4DjEsJXoYA8Ud5Vw= MIME-Version: 1.0 Received: by 10.223.26.220 with SMTP id f28mr609335fac.87.1317330811410; Thu, 29 Sep 2011 14:13:31 -0700 (PDT) Received: by 10.223.154.134 with HTTP; Thu, 29 Sep 2011 14:13:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Sep 2011 05:13:31 +0800 Message-ID: Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? From: Simon Delord To: Giles Heron , l2vpn@ietf.org Content-Type: multipart/alternative; boundary=00151747b42a10db2f04ae1afb4c 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, 29 Sep 2011 21:10:40 -0000 --00151747b42a10db2f04ae1afb4c Content-Type: text/plain; charset=ISO-8859-1 support, Simon 2011/9/30 Giles Heron > This is a request to gauge consensus as to whether: > > http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 > > should be accepted as an L2VPN WG draft. > > Now that we've adopted the new charter E-Tree is in scope, and we have a > milestone item to submit a requirements draft for E-Tree to IESG by March > 2012. If you think this draft is a good starting point for those > requirements then please reply indicating your support for the draft. If > not then please reply giving some reasons why you think this draft > shouldn't > be adopted - which we can then debate. > > Please respond by Thursday 13th of October. > > Thanks! > > Nabil & Giles > > > --00151747b42a10db2f04ae1afb4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable support,
Simon

2011/9/30 Giles Heron = <giles.heron@= gmail.com>
This is a request to gauge consensus as to whether:

http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt= -04

should be accepted as an L2VPN WG draft.

Now that we've adopted the new charter E-Tree is in scope, and we have = a
milestone item to submit a requirements draft for E-Tree to IESG by March 2012. =A0If you think this draft is a good starting point for those
requirements then please reply indicating your support for the draft. =A0If=
not then please reply giving some reasons why you think this draft shouldn&= #39;t
be adopted - which we can then debate.

Please respond by Thursday 13th of October.

Thanks!

Nabil & Giles



--00151747b42a10db2f04ae1afb4c-- From josh.rogers@twcable.com Thu Sep 29 14:14:45 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 27DB021F8DDD for ; Thu, 29 Sep 2011 14:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErFyZzyYKOFh for ; Thu, 29 Sep 2011 14:14:44 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 673D721F8DB2 for ; Thu, 29 Sep 2011 14:14:44 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,609,1309752000"; d="scan'208";a="264954976" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Sep 2011 17:15:10 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 29 Sep 2011 17:17:36 -0400 From: "Rogers, Josh" To: "l2vpn@ietf.org" Date: Thu, 29 Sep 2011 17:17:34 -0400 Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Topic: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Index: Acx+7TTqoFItoq51QguCf6mTY+LMEA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 29 Sep 2011 21:14:45 -0000 I support it. Josh From: Simon Delord Date: Thu, 29 Sep 2011 17:13:31 -0400 To: Giles Heron , "l2vpn@ietf.org" Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? support,Simon 2011/9/30 Giles Heron This is a request to gauge consensus as to whether: http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 should be accepted as an L2VPN WG draft. Now that we've adopted the new charter E-Tree is in scope, and we have a milestone item to submit a requirements draft for E-Tree to IESG by March 2012. If you think this draft is a good starting point for those requirements then please reply indicating your support for the draft. If not then please reply giving some reasons why you think this draft shouldn't be adopted - which we can then debate. Please respond by Thursday 13th of October. Thanks! Nabil & Giles This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From william.zayas@fibercrossing.net Thu Sep 29 14:57: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 D592D21F8906 for ; Thu, 29 Sep 2011 14:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.288 X-Spam-Level: * X-Spam-Status: No, score=1.288 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRbQhTZwt+lD for ; Thu, 29 Sep 2011 14:57:05 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2321F8772 for ; Thu, 29 Sep 2011 14:57:05 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p8TLxsRR001980 for ; Thu, 29 Sep 2011 17:59:56 -0400 X-Authenticated-IP: 205.178.146.50 Received: from [205.178.146.50] ([205.178.146.50:33220] helo=webmail9) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id D1/B9-29812-A5AE48E4; Thu, 29 Sep 2011 17:59:54 -0400 Received: from 77.67.108.13 (william.zayas@fibercrossing.net [77.67.108.13]) by webmail9 (Netsol 11.2.30) with WEBMAIL id 23609; Thu, 29 Sep 2011 21:59:54 +0000 From: william.zayas@fibercrossing.net To: "Rogers, Josh" , l2vpn@ietf.org Importance: Normal Sensitivity: Normal Message-ID: X-Mailer: Network Solutions Webmail, Build 11.2.30 X-Originating-IP: [77.67.108.13] X-Forwarded-For: [(null)] Date: Thu, 29 Sep 2011 21:59:54 +0000 Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_vm_0011_W3355022565_23609_1317333594" 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, 29 Sep 2011 21:57:05 -0000 ----=_vm_0011_W3355022565_23609_1317333594 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Obrigado..:) -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com] Sent: Thursday, September 29, 2011 05:17 PM To: l2vpn@ietf.org Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? I support it. Josh From: Simon Delord Date: Thu, 29 Sep 2011 17:13:31 -04= 00 To: Giles Heron , "l2vpn@ietf.org" Subject: Re: WG adoption of draft-k= ey-l2vpn-vpls-etree-reqt? support,Simon 2011/9/30 Giles Heron This is a r= equest to gauge consensus as to whether: http://tools.ietf.org/html/draft= -key-l2vpn-vpls-etree-reqt-04 should be accepted as an L2VPN WG draft. No= w that we've adopted the new charter E-Tree is in scope, and we have a mi= lestone item to submit a requirements draft for E-Tree to IESG by March 2= 012. If you think this draft is a good starting point for those requireme= nts then please reply indicating your support for the draft. If not then = please reply giving some reasons why you think this draft shouldn't be ad= opted - which we can then debate. Please respond by Thursday 13th of Octo= ber. Thanks! Nabil & Giles This E-mail and any of its attachments may con= tain Time Warner Cable proprietary information, which is privileged, conf= idential, or subject to copyright belonging to Time Warner Cable. This E-= mail is intended solely for the use of the individual or entity to which = it is addressed. If you are not the intended recipient of this E-mail, yo= u are hereby notified that any dissemination, distribution, copying, or a= ction taken in relation to the contents of and attachments to this E-mail= is strictly prohibited and may be unlawful. If you have received this E-= mail in error, please notify the sender immediately and permanently delet= e the original and any copy of this E-mail and any printout. ----=_vm_0011_W3355022565_23609_1317333594 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Support.
 
 
 
Obrigado..:)
 
 
 
-----Ori= ginal Message-----
From: Rogers, Josh [mailto:josh.rogers@twcab= le.com]
Sent: Thursday, September 29, 2011 05:17 PM
To: l2vpn@ietf.org
Subject: Re: WG adoption of draft-key-l2vpn-v= pls-etree-reqt?

I support it. Josh From: Simon Delord Date: Thu, 29 Sep 2011 17:13:31 -0400 To: Giles Heron = , "l2vpn@ietf.org" Subject: Re: WG= adoption of draft-key-l2vpn-vpls-etree-reqt? support,Simon 2011/9/30 Gil= es Heron This is a request to gauge consensus as t= o whether: http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 = should be accepted as an L2VPN WG draft. Now that we've adopted the new c= harter E-Tree is in scope, and we have a milestone item to submit a requi= rements draft for E-Tree to IESG by March 2012. If you think this draft i= s a good starting point for those requirements then please reply indicati= ng your support for the draft. If not then please reply giving some reaso= ns why you think this draft shouldn't be adopted - which we can then deba= te. Please respond by Thursday 13th of October. Thanks! Nabil & Giles= This E-mail and any of its attachments may contain Time Warner Cable pro= prietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely fo= r the use of the individual or entity to which it is addressed. If you ar= e not the intended recipient of this E-mail, you are hereby notified that= any dissemination, distribution, copying, or action taken in relation to= the contents of and attachments to this E-mail is strictly prohibited an= d may be unlawful. If you have received this E-mail in error, please noti= fy the sender immediately and permanently delete the original and any cop= y of this E-mail and any printout.
----=_vm_0011_W3355022565_23609_1317333594-- From raymond.key@hotmail.com Thu Sep 29 17:18:31 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 903EF21F8C76 for ; Thu, 29 Sep 2011 17:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEpVIbxEgoJx for ; Thu, 29 Sep 2011 17:18:31 -0700 (PDT) Received: from snt0-omc3-s51.snt0.hotmail.com (snt0-omc3-s51.snt0.hotmail.com [65.54.51.88]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8021F8CCA for ; Thu, 29 Sep 2011 17:18:30 -0700 (PDT) Received: from SNT123-W30 ([65.55.90.137]) by snt0-omc3-s51.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Sep 2011 17:21:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d97d5faf-f195-4ae6-a54a-cc831d43149f_" X-Originating-IP: [113.92.42.136] From: Raymond Key Sender: To: , Subject: RE: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Date: Fri, 30 Sep 2011 10:51:22 +1030 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2011 00:21:22.0700 (UTC) FILETIME=[E21D3CC0:01CC7F06] 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: Fri, 30 Sep 2011 00:18:31 -0000 --_d97d5faf-f195-4ae6-a54a-cc831d43149f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support. Raymond =20 > Date: Thu=2C 29 Sep 2011 20:32:34 +0100 > Subject: WG adoption of draft-key-l2vpn-vpls-etree-reqt? > From: giles.heron@gmail.com > To: l2vpn@ietf.org >=20 > This is a request to gauge consensus as to whether: >=20 > http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 >=20 > should be accepted as an L2VPN WG draft. >=20 > Now that we've adopted the new charter E-Tree is in scope=2C and we have = a > milestone item to submit a requirements draft for E-Tree to IESG by March > 2012. If you think this draft is a good starting point for those > requirements then please reply indicating your support for the draft. If > not then please reply giving some reasons why you think this draft should= n't > be adopted - which we can then debate. >=20 > Please respond by Thursday 13th of October. >=20 > Thanks! >=20 > Nabil & Giles >=20 >=20 = --_d97d5faf-f195-4ae6-a54a-cc831d43149f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I support.
Raymond
 =3B
>=3B Date: Thu=2C 29 Sep 2011 20:32:34 +0100
>=3B Subject: WG adopti= on of draft-key-l2vpn-vpls-etree-reqt?
>=3B From: giles.heron@gmail.co= m
>=3B To: l2vpn@ietf.org
>=3B
>=3B This is a request to ga= uge consensus as to whether:
>=3B
>=3B http://tools.ietf.org/htm= l/draft-key-l2vpn-vpls-etree-reqt-04
>=3B
>=3B should be accepte= d as an L2VPN WG draft.
>=3B
>=3B Now that we've adopted the new= charter E-Tree is in scope=2C and we have a
>=3B milestone item to su= bmit a requirements draft for E-Tree to IESG by March
>=3B 2012. If yo= u think this draft is a good starting point for those
>=3B requirement= s then please reply indicating your support for the draft. If
>=3B not= then please reply giving some reasons why you think this draft shouldn't>=3B be adopted - which we can then debate.
>=3B
>=3B Please= respond by Thursday 13th of October.
>=3B
>=3B Thanks!
>= =3B
>=3B Nabil &=3B Giles
>=3B
>=3B
=
= --_d97d5faf-f195-4ae6-a54a-cc831d43149f_-- From prvs=7254c7f5cb=edwin.mallette@bhnis.com Thu Sep 29 17:33:36 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 16B9921F8AC9 for ; Thu, 29 Sep 2011 17:33:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqd6jRDRrYDN for ; Thu, 29 Sep 2011 17:33:35 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0521F8AB9 for ; Thu, 29 Sep 2011 17:33:35 -0700 (PDT) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p8U0Z8he025345; Thu, 29 Sep 2011 20:36:26 -0400 Received: from tbstpcas01.corp.local ([10.226.201.190]) by mx3.mybrighthouse.com with ESMTP id 10507hgr8f-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 20:36:26 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by tbstpcas01.corp.local ([10.226.201.190]) with mapi; Thu, 29 Sep 2011 20:36:24 -0400 From: "Mallette, Edwin" To: Giles Heron , "l2vpn@ietf.org" Date: Thu, 29 Sep 2011 20:36:35 -0400 Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Topic: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Index: Acx/CPu1f8hrxF/ORi+lYaKpd2Yfnw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1109290311 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: Fri, 30 Sep 2011 00:33:36 -0000 /Support Ed On 9/29/11 3:32 PM, "Giles Heron" wrote: >This is a request to gauge consensus as to whether: > >http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 > >should be accepted as an L2VPN WG draft. > >Now that we've adopted the new charter E-Tree is in scope, and we have a >milestone item to submit a requirements draft for E-Tree to IESG by March >2012. If you think this draft is a good starting point for those >requirements then please reply indicating your support for the draft. If >not then please reply giving some reasons why you think this draft >shouldn't >be adopted - which we can then debate. > >Please respond by Thursday 13th of October. > >Thanks! > >Nabil & Giles > > CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From mach.chen@huawei.com Thu Sep 29 17:51:33 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 80C1621F8C7D for ; Thu, 29 Sep 2011 17:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9sUsbth6l0s for ; Thu, 29 Sep 2011 17:51:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B259121F8C78 for ; Thu, 29 Sep 2011 17:51:32 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSB00LU596NIY@szxga03-in.huawei.com> for l2vpn@ietf.org; Fri, 30 Sep 2011 08:54:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSB00BZF96NFL@szxga03-in.huawei.com> for l2vpn@ietf.org; Fri, 30 Sep 2011 08:54:23 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADZ81890; Fri, 30 Sep 2011 08:54:22 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 30 Sep 2011 08:54:11 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.204]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 08:54:15 +0800 Date: Fri, 30 Sep 2011 00:54:15 +0000 From: Mach Chen Subject: RE: WG adoption of draft-key-l2vpn-vpls-etree-reqt? In-reply-to: X-Originating-IP: [10.108.4.67] To: Giles Heron , "l2vpn@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-index: Acx+3olnBdW6oUmrHUWspYzlTDElSgALM/tg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Thu, 29 Sep 2011 18:02:04 -0700 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: Fri, 30 Sep 2011 00:51:33 -0000 Support! Best regards, Mach > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Giles Heron > Sent: Friday, September 30, 2011 3:33 AM > To: l2vpn@ietf.org > Subject: WG adoption of draft-key-l2vpn-vpls-etree-reqt? > > This is a request to gauge consensus as to whether: > > http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 > > should be accepted as an L2VPN WG draft. > > Now that we've adopted the new charter E-Tree is in scope, and we have a > milestone item to submit a requirements draft for E-Tree to IESG by March > 2012. If you think this draft is a good starting point for those > requirements then please reply indicating your support for the draft. If > not then please reply giving some reasons why you think this draft shouldn't > be adopted - which we can then debate. > > Please respond by Thursday 13th of October. > > Thanks! > > Nabil & Giles > From lizhong.jin@zte.com.cn Thu Sep 29 18:07:21 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 8E14021F8AE6 for ; Thu, 29 Sep 2011 18:07:21 -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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiTQemb7RGxC for ; Thu, 29 Sep 2011 18:07:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6E21F8AA8 for ; Thu, 29 Sep 2011 18:07:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713577109098; Fri, 30 Sep 2011 09:08:35 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 75544.683968793; Fri, 30 Sep 2011 09:10:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p8U1A1kY055455; Fri, 30 Sep 2011 09:10:01 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: l2vpn@ietf.org Subject: Re: WG adoption of draft-key-l2vpn-vpls-etree-reqt? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Lizhong Jin Date: Fri, 30 Sep 2011 09:09:41 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-30 09:09:57, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-30 09:09:57, Serialize complete at 2011-09-30 09:09:57, S/MIME Sign failed at 2011-09-30 09:09:57: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-30 09:10:01, Serialize complete at 2011-09-30 09:10:01 Content-Type: multipart/alternative; boundary="=_alternative 000667944825791B_=" X-MAIL: mse01.zte.com.cn p8U1A1kY055455 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: Fri, 30 Sep 2011 01:07:21 -0000 This is a multipart message in MIME format. --=_alternative 000667944825791B_= Content-Type: text/plain; charset="US-ASCII" Yes, support. Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Sep 2011 20:32:34 +0100 > From: Giles Heron > To: > Subject: WG adoption of draft-key-l2vpn-vpls-etree-reqt? > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > This is a request to gauge consensus as to whether: > > http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 > > should be accepted as an L2VPN WG draft. > > Now that we've adopted the new charter E-Tree is in scope, and we have a > milestone item to submit a requirements draft for E-Tree to IESG by March > 2012. If you think this draft is a good starting point for those > requirements then please reply indicating your support for the draft. If > not then please reply giving some reasons why you think this draft shouldn't > be adopted - which we can then debate. > > Please respond by Thursday 13th of October. > > Thanks! > > 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. --=_alternative 000667944825791B_= Content-Type: text/html; charset="US-ASCII"
Yes, support.

Lizhong

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 Sep 2011 20:32:34 +0100
> From: Giles Heron <giles.heron@gmail.com>
> To: <l2vpn@ietf.org>
> Subject: WG adoption of draft-key-l2vpn-vpls-etree-reqt?
> Message-ID: <CAAA8662.EEB4%giles.heron@gmail.com>
> Content-Type: text/plain;   charset="US-ASCII"
>
> This is a request to gauge consensus as to whether:
>
> http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04
>
> should be accepted as an L2VPN WG draft.
>
> Now that we've adopted the new charter E-Tree is in scope, and we have a
> milestone item to submit a requirements draft for E-Tree to IESG by March
> 2012.  If you think this draft is a good starting point for those
> requirements then please reply indicating your support for the draft.  If
> not then please reply giving some reasons why you think this draft shouldn't
> be adopted - which we can then debate.
>
> Please respond by Thursday 13th of October.
>
> Thanks!
>
> 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.
--=_alternative 000667944825791B_=-- From wim.henderickx@alcatel-lucent.com Thu Sep 29 21:36:16 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 6357C11E8083 for ; Thu, 29 Sep 2011 21:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.482 X-Spam-Level: X-Spam-Status: No, score=-5.482 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEAIW7xGLR1y for ; Thu, 29 Sep 2011 21:36:15 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC211E8082 for ; Thu, 29 Sep 2011 21:36:15 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8U4d4P7022180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Sep 2011 06:39:04 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 30 Sep 2011 06:39:04 +0200 From: "Henderickx, Wim (Wim)" To: Giles Heron , "l2vpn@ietf.org" Date: Fri, 30 Sep 2011 06:39:02 +0200 Subject: RE: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Topic: WG adoption of draft-key-l2vpn-vpls-etree-reqt? Thread-Index: Acx+3olnBdW6oUmrHUWspYzlTDElSgATFSlA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671AC8BD5A@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 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: Fri, 30 Sep 2011 04:36:16 -0000 support -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: donderdag 29 september 2011 21:33 To: l2vpn@ietf.org Subject: WG adoption of draft-key-l2vpn-vpls-etree-reqt? This is a request to gauge consensus as to whether: http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-04 should be accepted as an L2VPN WG draft. Now that we've adopted the new charter E-Tree is in scope, and we have a milestone item to submit a requirements draft for E-Tree to IESG by March 2012. If you think this draft is a good starting point for those requirements then please reply indicating your support for the draft. If not then please reply giving some reasons why you think this draft shouldn'= t be adopted - which we can then debate. Please respond by Thursday 13th of October. Thanks! Nabil & Giles