From yaakov_s@rad.com Tue May 1 01:06:42 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620A921F8723 for ; Tue, 1 May 2012 01:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 ZXLYI9pBHh1N for ; Tue, 1 May 2012 01:06:40 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id DBD6E21F8710 for ; Tue, 1 May 2012 01:06:37 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 1 May 2012 10:49:40 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 1 May 2012 11:06:29 +0300 From: Yaakov Stein To: Gregory Mirsky , "pwe3@ietf.org" Thread-Topic: In response to discussion of LI/LB for PW at IETF-83 Thread-Index: Ac0nK6eE6CRf1OTeRZSe/a/N5zn7dgAQkzig Date: Tue, 1 May 2012 08:06:28 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C215F@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043C215FEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090203.4F9F9986.007F,ss=1,fgs=0 Subject: Re: [PWE3] In response to discussion of LI/LB for PW at IETF-83 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 08:06:42 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043C215FEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg First, thanks for reminding me to read over the minutes (which I haven't se= en until now). I note that there are several typos. First, in (X slide sets NOT received as of Mar 29 00:43 Paris time) does X stand for the Roman numeral for 10 ? On the issue of "simplifying" the number of VCCV options, I said Can't remove for architectural reasons not Can remove for architectu= ral reasons. ! (and while an "actons" sounds like newly discovered exotic fundamental part= icles, the previous sentence should have been about actions.) Regarding the LI/LB proposal, I don't recall mumbling either (but the minutes don't record who mumbled either - was it Greg, Himanshu, o= r Samy, or someone else?). I don't see how a timer addresses my security concerns, but on the other hand, this is one tiny piece of a large security issue tha= t is not being addressed. I didn't intend to complain about this particle draft in particular, it was just yet another place where our negligence is spectacularly evident= . The discussion as to where to place a function (MP, CP, OAM) that could ea= sily be used to create DoS was being discussed without asking the most important question, namely - "which can be more easily secured?". Y(J)S From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, May 01, 2012 02:48 To: Yaakov Stein; pwe3@ietf.org Subject: In response to discussion of LI/LB for PW at IETF-83 Dear Yaakov, et al., I've read the minutes and would like to note that: * I did not mumble "no" to your question at the end of time allotte= d for the presentation * Proposed extensions, IMO, have nothing to do with timer that migh= t be associated with Loopback state and would take Maintanence Point out of= Loopback if expired. If such a timer to be enabled its configuration can b= e part of OAM configuration through the LDP extensions or LSP Ping. Yaakov, would such timer address your concern with security impact of the p= roposed extension to control LI/LB via control plane? Chairs, I hope that WG minutes can be corrected. Regards, Greg --_000_07F7D7DED63154409F13298786A2ADC9043C215FEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg

 

First, thanks for reminding me to read over the minutes (whi= ch I haven't seen until now).

 

I note that there are several typos. 

First, in (X slide sets NOT received as of Mar 29 00:=
43 Paris time)

does X stand for the Roman numeral for 10 ?

 

On the issue of "simplifying" the number of VCCV o= ptions,

I said Can't remove for architectural reasons not Can remove for architectural reasons. !

(and while an "actons" sounds like newly discovere= d exotic fundamental particles,

 the previous sentence should have been about actions.)=

 

Regarding the LI/LB proposal,  I don't recall mumbling = either

(but the minutes don't record who mumbled either – was= it Greg, Himanshu, or Samy, or someone else?).

 

I don't see how a timer addresses my security concerns,=

but on the other hand, this is one tiny piece of a large sec= urity issue that is not being addressed.

 

I didn't intend to complain about this particle draft in par= ticular,

it was just yet another place where our negligence is specta= cularly evident.

The discussion as to where to place a function (MP, CP, OAM)=  that could easily be used to create DoS

was being discussed without asking the most important questi= on,

namely – "which can be more easily secured?"= .

 

Y(J)S

 

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, May 01, 2012 02:48
To: Yaakov Stein; pwe3@ietf.org
Subject: In response to discussion of LI/LB for PW at IETF-83

 

Dear Yaakov, et al.,

I've read the minutes and would like to n= ote that:

·         I did not mumb= le "no" to your question at the end of time allotted for the pres= entation

·         Proposed exten= sions, IMO, have nothing to do with timer that might be associated with Loo= pback state and would take Maintanence Point out of Loopback if expired. If such a timer to be enabled its configuration ca= n be part of OAM configuration through the LDP extensions or LSP Ping.=

Yaakov, would such timer address your con= cern with security impact of the proposed extension to control LI/LB via co= ntrol plane?

 

Chairs, I hope that WG minutes can be cor= rected.

 

       = ; Regards,

       = ;         Greg

 

--_000_07F7D7DED63154409F13298786A2ADC9043C215FEXRAD5adradcoil_-- From internet-drafts@ietf.org Tue May 1 09:10:12 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E60121E821F; Tue, 1 May 2012 09:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 52PRpLLC7R9U; Tue, 1 May 2012 09:10:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BA421E8206; Tue, 1 May 2012 09:10:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120501161011.27609.73606.idtracker@ietfa.amsl.com> Date: Tue, 01 May 2012 09:10:11 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-bit-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:10:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Preferential Forwarding Status Bit Author(s) : Praveen Muley Mustapha Aissaoui Filename : draft-ietf-pwe3-redundancy-bit-07.txt Pages : 36 Date : 2012-05-01 This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates the PW operational status textual convention defined in RFC 5542 [9]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-bit-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-bit-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ From mustapha.aissaoui@alcatel-lucent.com Tue May 1 09:17:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D79D21E8303 for ; Tue, 1 May 2012 09:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2DgaT9vkTBqx for ; Tue, 1 May 2012 09:17:24 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D70A321E82D6 for ; Tue, 1 May 2012 09:17:23 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q41GHJGV020996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 11:17:20 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q41GHJ7n007473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 May 2012 11:17:19 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 1 May 2012 11:17:19 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "pwe3@ietf.org" Date: Tue, 1 May 2012 11:17:18 -0500 Thread-Topic: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-bit-07.txt Thread-Index: Ac0ntQOrZAL65bVoQPyq5l8jLpDNQgAABYuA Message-ID: <5DF53972F7E9134782DCE51624466FE50BD6877AA5@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20120501161011.27609.73606.idtracker@ietfa.amsl.com> In-Reply-To: <20120501161011.27609.73606.idtracker@ietfa.amsl.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "Miguel A. Garcia" , Stewart Bryant Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-bit-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:17:24 -0000 Dear all, I uploaded the update to this draft which incorporates comments from Gen-Ar= t and other comments on this mailing list as per my previous communication. Regards, Mustapha.=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Tuesday, May 01, 2012 12:10 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-bit-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Preferential Forwarding Status Bit Author(s) : Praveen Muley Mustapha Aissaoui Filename : draft-ietf-pwe3-redundancy-bit-07.txt Pages : 36 Date : 2012-05-01 This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates the PW operational status textual convention defined in RFC 5542 [9]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-bit-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-bit-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Thu May 3 12:14:16 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3B21F869D; Thu, 3 May 2012 12:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 K9t92saVKh+z; Thu, 3 May 2012 12:14:16 -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 0865D21F85A8; Thu, 3 May 2012 12:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1148; q=dns/txt; s=iport; t=1336072456; x=1337282056; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=pc0/jItpBi696itjL+QZv4X2m3QukMhr3hPnQ/0phyc=; b=BUVAVzyztNdFskYRIyOvp4R0B9C/eBMpucXg+wLxs3lsys6BwQ5qOpb8 sb9MMZxOftluGA4H+ILD2AX9X6ElaYKjpiDsexM/27KOPPuSPxFsdiLsF v1Im3N98//v3XCklccYmfhQ45Phsp1KJwjhTljxEUVD+L4T5YeiPCdPYO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJTYok+Q/khM/2dsb2JhbABFryCDW4EHgiIBAiM8BAE8FhgDAgECAVgBBwEBHodrmlqDRRCBTpp+jWODJQSVfo5ZgQJngmmBWw X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="136979641" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 May 2012 19:14:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q43JEEWb003026; Thu, 3 May 2012 19:14:14 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q43JEClg017921; Thu, 3 May 2012 20:14:13 +0100 (BST) Message-ID: <4FA2D904.5040007@cisco.com> Date: Thu, 03 May 2012 20:14:12 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: draft-ietf-pwe3-redundancy@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3 , "pwe3-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 19:14:17 -0000 This document was on the IESG Telechat for 10 May 2012. However it has been drawn to my attention that because of the length of time taken to address comments the proto statement was written before we required the shepherd to asked each author to confirmed that they know of no IPR related to this draft. I have postponed the IESG review by two weeks so that, we can check whether there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Regards Stewart From tnadeau@lucidvision.com Thu May 3 13:08:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC6A21F860E; Thu, 3 May 2012 13:08:20 -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=[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 S-MTAMakQnvj; Thu, 3 May 2012 13:08:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6783721F8547; Thu, 3 May 2012 13:08:19 -0700 (PDT) Received: from sa-nc-finance-215.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 83F9C20F9672; Thu, 3 May 2012 16:08:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4FA2D904.5040007@cisco.com> Date: Thu, 3 May 2012 16:08:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4EF7E0CF-36C1-4DF6-919E-23AE38C064DC@lucidvision.com> References: <4FA2D904.5040007@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-pwe3-redundancy@tools.ietf.org, pwe3 , "pwe3-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 20:08:20 -0000 None from my end. On May 3, 2012:3:14 PM, at 3:14 PM, Stewart Bryant wrote: > > This document was on the IESG Telechat for 10 May 2012. > > However it has been drawn to my attention that because of > the length of time taken to address comments the proto > statement was written before we required the shepherd > to asked each author to confirmed that they know of no IPR > related to this draft. > > I have postponed the IESG review by two weeks so that, we > can check whether there is IPR on the document that needs to > be disclosed. > > Are you aware of any IPR that applies to the the draft? > If so, has this IPR been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please > reply to this email regardless of whether or not you are > aware of any relevant IPR. The document will not advance to > the next stage until a response has been received from each > author and contributor. > > If you are on the PWE3 WG email list but are not listed as > an author or contributor, then please explicitly respond only if > you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > > Regards > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From matthew.bocci@alcatel-lucent.com Fri May 4 02:02:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB7A21F8633; Fri, 4 May 2012 02:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.731 X-Spam-Level: X-Spam-Status: No, score=-107.731 tagged_above=-999 required=5 tests=[AWL=-1.482, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 Ukt8iDNNfzOk; Fri, 4 May 2012 02:02:46 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7AD21F8550; Fri, 4 May 2012 02:02:46 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4492Rd2030125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 11:02:42 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 4 May 2012 11:02:39 +0200 From: "Bocci, Matthew (Matthew)" To: "stbryant@cisco.com" , "draft-ietf-pwe3-redundancy@tools.ietf.org" Date: Fri, 4 May 2012 11:02:37 +0200 Thread-Topic: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? Thread-Index: Ac0p1Ke3raGJxZOiQqS0jH/fmFkrvQ== Message-ID: In-Reply-To: <4FA2D904.5040007@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: 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.83 Cc: pwe3 , "pwe3-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:02:47 -0000 I'm not aware of any. Matthew On 03/05/2012 20:14, "Stewart Bryant" wrote: > >This document was on the IESG Telechat for 10 May 2012. > >However it has been drawn to my attention that because of >the length of time taken to address comments the proto >statement was written before we required the shepherd >to asked each author to confirmed that they know of no IPR >related to this draft. > >I have postponed the IESG review by two weeks so that, we >can check whether there is IPR on the document that needs to >be disclosed. > >Are you aware of any IPR that applies to the the draft? >If so, has this IPR been disclosed in compliance with IETF IPR >rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please >reply to this email regardless of whether or not you are >aware of any relevant IPR. The document will not advance to >the next stage until a response has been received from each >author and contributor. > >If you are on the PWE3 WG email list but are not listed as >an author or contributor, then please explicitly respond only if >you are aware of any IPR that has not yet been disclosed in >conformance with IETF rules. > >Regards > >Stewart > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From internet-drafts@ietf.org Fri May 4 02:14:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A638B21F8748; Fri, 4 May 2012 02:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, 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 fYm-OrBLERV3; Fri, 4 May 2012 02:14:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3F21F862B; Fri, 4 May 2012 02:14:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504091440.6651.40422.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 02:14:40 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-08.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:14:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Redundancy Author(s) : Praveen Muley Mustapha Aissaoui Matthew Bocci Filename : draft-ietf-pwe3-redundancy-08.txt Pages : 16 Date : 2012-05-04 This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single -segment PW applications, or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy/ From matthew.bocci@alcatel-lucent.com Fri May 4 03:39:02 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5C621F8587 for ; Fri, 4 May 2012 03:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.65 X-Spam-Level: X-Spam-Status: No, score=-109.65 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 G374MGzWH4CJ for ; Fri, 4 May 2012 03:39:02 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 07B5321F8617 for ; Fri, 4 May 2012 03:38:48 -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 q44Aclqb031436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 May 2012 12:38:47 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 4 May 2012 12:38:47 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Fri, 4 May 2012 12:38:44 +0200 Thread-Topic: Updates to goals and milestones Thread-Index: Ac0p4hWVTO5WPsXMRTefgV9GBEa5/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBC9699C2A41Cmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 10:39:02 -0000 --_000_CBC9699C2A41Cmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012 - P2MP Requirements LC Done =96 PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012 - Enhanced PW OAM Sept 2011 =96 Signaling extensions for MPLS-TP OAM Dec 2012 - Multisegment PW MIB Dec 2012 - Security Considerations LC Dec 2012 =96 Congestion Considerations Dec 2012 - P2MP PW Signaling (root initiated) Dec 2012 =96 P2MP PW Signaling (leaf initiated) --_000_CBC9699C2A41Cmatthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All,

Please find below a proposed list of updat= es to the WG goals and milestones that was presented in Paris, with one mod= ification pushing the P2MP Requirements LC back to Dec 2012.

Please post any comments to the list befo= re Friday 11th May.

Matthew=

=

 Done     - PWE3 WG started, organize editing teams.

=   Done     - Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables

  Done     - Accept drafts of servi= ce-specific documents as WG items

  Done &nbs= p;   - PW Requirements Document Last Call

  Done     - = TDM Circuit Documents Last Call

  Done=      - ATM Documents Last Call

  Done     - Ethernet Documents Last Call<= /span>

  Done     - Fragm= entation LC

  Done   &n= bsp; - TDM Requirements LC

  Done = ;    - SONET Documents Last Call

  Done     - TDM Documents Last Call

  Done     - Frame Relay D= ocuments Last Call

=   Done  &= nbsp;  - FCS retention Last Call

 = ; Done     - Multi-Segment PW Requirements LC

  Done     - VCCV LC

 &n= bsp;Done     - PWE3 Services MIBs LC

  Done    = - PPP/HDLC PW LC

<= span style=3D"font-family: Arial; color: black; ">  Done  &n= bsp;  - Wildcard FEC LC

  Done     - TDM Signaling L= C

<= !--StartFragment-->

  Done- Multi-Segment Architecture LC

  Done     - Basic Pseudowire MIBs LC

  Done - PW OAM Mapping LC

  Done - Multi-Segment PW LC

  Done   Done - PW Protection and Restoration Architecture

  Done - Generic Associated Channel Header LC

&n= bsp; Done - PW Protection and Restoration LC

  Done - Fiber Channel En= cap LC

  Done- Multipath PW LC

  = Done  - Packe= t PW Requirements / solution

  Dec  2012 - P2MP Requirements LC

  Done  =96 PW Status signa= lling in static/MPLS-TP

  July 2012<= /span> - Dynamic MS PW LC

  Sept  - Enhanced PW OAM

  Sept 2011 =96 Signaling extensions for M= PLS-TP OAM

&n= bsp; Dec 2012 - Multisegment PW MIB

  Dec 2012 - Security Considerations LC

  <= span style=3D"font-family: Arial; ">Dec 2012 =96 Congestion Considerations 

 Dec  2012 - P2MP = PW Signaling (roo= t initiated)

 Dec 2012 =96 P2MP PW <= /span>Signaling (leaf initiated)

<= !--EndFragment-->
--_000_CBC9699C2A41Cmatthewboccialcatellucentcom_-- From cpignata@cisco.com Fri May 4 04:37:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBDE21F86F4 for ; Fri, 4 May 2012 04:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.531 X-Spam-Level: X-Spam-Status: No, score=-108.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, 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 U2qHBVyjIb8n for ; Fri, 4 May 2012 04:37:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 223F021F86E4 for ; Fri, 4 May 2012 04:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=27242; q=dns/txt; s=iport; t=1336131466; x=1337341066; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=yTD94Nz0XaIbUbFoUXHdJv3lVCIbCPfpKOVOOWEEhgQ=; b=hiytI7YhVE001TgYdF6KS+dEjPpt5OHi2sTw9AlfElmt2N0WRmAuQB1q hLp4w3ujQVn2r9/8NKKvfKbnarUg4Tp9JiqhD4qsHUdpCtMYtOzoTl1jK 7cx+KFjy58qod6MKqhBe9CkipZXnvNxFUnYsHj5EWzbDTxADuYYIsfNL/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4IAIO+o0+tJXG8/2dsb2JhbABFgkaDKKtfgRICgQeCCQEBAQMBAQEBDwEQCkELBQsCAQgSCAIcCgICAiUiDgEBBBMbB4dmBQuaWo0WkngEgS+ORjVjBJV+jlmBaYME X-IronPort-AV: E=Sophos;i="4.75,530,1330905600"; d="scan'208,217";a="80327297" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 04 May 2012 11:37:45 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q44BbjiS009495; Fri, 4 May 2012 11:37:45 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 06:37:45 -0500 Received: from 72.163.62.213 ([72.163.62.213]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 May 2012 11:37:44 +0000 References: Content-Transfer-Encoding: 7bit From: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary="Apple-Mail-67282BAB-1179-42E4-9D25-EAB05C090175"; charset="utf-8" In-Reply-To: Message-ID: thread-topic: [PWE3] Updates to goals and milestones thread-index: Ac0p6lKPXCqc6kZ2Stak6pCJF4vbwg== Date: Fri, 4 May 2012 07:37:37 -0400 To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 04 May 2012 11:37:45.0633 (UTC) FILETIME=[53112110:01CD29EA] Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:37:47 -0000 --Apple-Mail-67282BAB-1179-42E4-9D25-EAB05C090175 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 TWF0dGhldywNCg0KSW4gUGFyaXMgdGhlcmUgd2FzIGRpc2N1c3Npb24gKGFuZCBzdWJzZXF1ZW50 IGZvbGxvd3VwKSBhYm91dCBhIFZDQ1YtYmlzIGRvY3VtZW50LiBJIGFtIG5vdCBzdXJlIGlmIGEg Zm9ybWFsIGNvbnNlbnN1cyBjYWxsIHdhcyBpc3N1ZWQgb24gdGhhdCwgYnV0IEkgd29uZGVyIGlm IGl0IG5lZWRzIHRvIGJlIGNhcHR1cmVkIGFzIGEgbWlsZXN0b25lIChvciBob3cgaXQgcmVsYXRl cyB0byAiRW5oYW5jZWQgUFcgT0FNIikuIA0KDQpUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0 YXJvLg0KRXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dzDQoNCk9uIE1heSA0LCAyMDEyLCBhdCA2 OjM5IEFNLCAiQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpIiA8bWF0dGhldy5ib2NjaUBhbGNhdGVs LWx1Y2VudC5jb20+IHdyb3RlOg0KDQo+IEFsbCwNCj4gDQo+IFBsZWFzZSBmaW5kIGJlbG93IGEg cHJvcG9zZWQgbGlzdCBvZiB1cGRhdGVzIHRvIHRoZSBXRyBnb2FscyBhbmQgbWlsZXN0b25lcyB0 aGF0IHdhcyBwcmVzZW50ZWQgaW4gUGFyaXMsIHdpdGggb25lIG1vZGlmaWNhdGlvbiBwdXNoaW5n IHRoZSBQMk1QIFJlcXVpcmVtZW50cyBMQyBiYWNrIHRvIERlYyAyMDEyLg0KPiANCj4gUGxlYXNl IHBvc3QgYW55IGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJlZm9yZSBGcmlkYXkgMTF0aCBNYXkuDQo+ IA0KPiBNYXR0aGV3DQo+IA0KPiAgRG9uZSAgICAgLSBQV0UzIFdHIHN0YXJ0ZWQsIG9yZ2FuaXpl IGVkaXRpbmcgdGVhbXMuDQo+ICAgRG9uZSAgICAgLSBIb2xkIGludGVyaW0gbWVldGluZywgaW5j bHVkaW5nIGRpc2N1c3Npb24gb2YgcHJpb3JpdHkgb2Ygc2VydmljZS1zcGVjaWZpYyBkb2N1bWVu dHMgYW5kIGNvbnNpZGVyIHBydW5pbmcgc29tZSBkZWxpdmVyYWJsZXMNCj4gICBEb25lICAgICAt IEFjY2VwdCBkcmFmdHMgb2Ygc2VydmljZS1zcGVjaWZpYyBkb2N1bWVudHMgYXMgV0cgaXRlbXMN Cj4gICBEb25lICAgICAtIFBXIFJlcXVpcmVtZW50cyBEb2N1bWVudCBMYXN0IENhbGwNCj4gICBE b25lICAgICAtIFRETSBDaXJjdWl0IERvY3VtZW50cyBMYXN0IENhbGwNCj4gICBEb25lICAgICAt IEFUTSBEb2N1bWVudHMgTGFzdCBDYWxsDQo+ICAgRG9uZSAgICAgLSBFdGhlcm5ldCBEb2N1bWVu dHMgTGFzdCBDYWxsDQo+ICAgRG9uZSAgICAgLSBGcmFnbWVudGF0aW9uIExDDQo+ICAgRG9uZSAg ICAgLSBURE0gUmVxdWlyZW1lbnRzIExDDQo+ICAgRG9uZSAgICAgLSBTT05FVCBEb2N1bWVudHMg TGFzdCBDYWxsDQo+ICAgRG9uZSAgICAgLSBURE0gRG9jdW1lbnRzIExhc3QgQ2FsbA0KPiAgIERv bmUgICAgIC0gRnJhbWUgUmVsYXkgRG9jdW1lbnRzIExhc3QgQ2FsbA0KPiAgIERvbmUgICAgIC0g RkNTIHJldGVudGlvbiBMYXN0IENhbGwNCj4gICBEb25lICAgICAtIE11bHRpLVNlZ21lbnQgUFcg UmVxdWlyZW1lbnRzIExDDQo+ICAgRG9uZSAgICAgLSBWQ0NWIExDDQo+ICAgRG9uZSAgICAgLSBQ V0UzIFNlcnZpY2VzIE1JQnMgTEMNCj4gICBEb25lICAgICAtIFBQUC9IRExDIFBXIExDDQo+ICAg RG9uZSAgICAgLSBXaWxkY2FyZCBGRUMgTEMNCj4gICBEb25lICAgICAtIFRETSBTaWduYWxpbmcg TEMNCj4gICBEb25lLSBNdWx0aS1TZWdtZW50IEFyY2hpdGVjdHVyZSBMQw0KPiAgIERvbmUgICAg IC0gQmFzaWMgUHNldWRvd2lyZSBNSUJzIExDDQo+ICAgRG9uZSAtIFBXIE9BTSBNYXBwaW5nIExD DQo+ICAgRG9uZSAtIE11bHRpLVNlZ21lbnQgUFcgTEMNCj4gICBEb25lIC0gUFcgUHJvdGVjdGlv biBhbmQgUmVzdG9yYXRpb24gUmVxdWlyZW1lbnRzIExDDQo+ICAgRG9uZSAtIFBXIFByb3RlY3Rp b24gYW5kIFJlc3RvcmF0aW9uIEFyY2hpdGVjdHVyZQ0KPiAgIERvbmUgLSBHZW5lcmljIEFzc29j aWF0ZWQgQ2hhbm5lbCBIZWFkZXIgTEMNCj4gICBEb25lIC0gUFcgUHJvdGVjdGlvbiBhbmQgUmVz dG9yYXRpb24gTEMNCj4gICBEb25lIC0gRmliZXIgQ2hhbm5lbCBFbmNhcCBMQw0KPiAgIERvbmUt IE11bHRpcGF0aCBQVyBMQw0KPiAgIERvbmUgIC0gUGFja2V0IFBXIFJlcXVpcmVtZW50cyAvIHNv bHV0aW9uDQo+ICAgRGVjICAyMDEyIC0gUDJNUCBSZXF1aXJlbWVudHMgTEMNCj4gICBEb25lICDi gJMgUFcgU3RhdHVzIHNpZ25hbGxpbmcgaW4gc3RhdGljL01QTFMtVFANCj4gICBKdWx5IDIwMTIg LSBEeW5hbWljIE1TIFBXIExDDQo+ICAgU2VwdCAyMDEyIC0gRW5oYW5jZWQgUFcgT0FNDQo+ICAg U2VwdCAyMDExIOKAkyBTaWduYWxpbmcgZXh0ZW5zaW9ucyBmb3IgTVBMUy1UUCBPQU0NCj4gICBE ZWMgMjAxMiAtIE11bHRpc2VnbWVudCBQVyBNSUINCj4gICBEZWMgMjAxMiAtIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIExDDQo+ICAgRGVjIDIwMTIg4oCTIENvbmdlc3Rpb24gQ29uc2lkZXJhdGlv bnMgDQo+ICBEZWMgIDIwMTIgLSBQMk1QIFBXIFNpZ25hbGluZyAocm9vdCBpbml0aWF0ZWQpDQo+ ICBEZWMgMjAxMiDigJMgUDJNUCBQVyBTaWduYWxpbmcgKGxlYWYgaW5pdGlhdGVkKQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwd2UzIG1haWxp bmcgbGlzdA0KPiBwd2UzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcHdlMw0K --Apple-Mail-67282BAB-1179-42E4-9D25-EAB05C090175 Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+TWF0dGhldyw8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkluIFBhcmlzIHRoZXJlIHdhcyBkaXNjdXNzaW9uIChh bmQgc3Vic2VxdWVudCBmb2xsb3d1cCkgYWJvdXQgYSBWQ0NWLWJpcyBkb2N1bWVudC4gSSBhbSBu b3Qgc3VyZSBpZiBhIGZvcm1hbCBjb25zZW5zdXMgY2FsbCB3YXMgaXNzdWVkIG9uIHRoYXQsIGJ1 dCBJIHdvbmRlciBpZiBpdCBuZWVkcyB0byBiZSBjYXB0dXJlZCBhcyBhIG1pbGVzdG9uZSAob3Ig aG93IGl0IHJlbGF0ZXMgdG8gIjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsOyAtd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYs IDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEo MTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9y OiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPkVuaGFuY2VkIFBXIE9BTTwvc3Bhbj48 c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdo dC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRpb24t ZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9z aXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+IikuJm5i c3A7PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBz dHlsZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjk2 ODc1KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcs IDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4 LCAxODAsIDAuMjMwNDY5KTsgIj5UaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJvLjwvc3Bh bj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iLXdlYmtpdC10YXAt aGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtpdC1jb21w b3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtp dC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsg Ij5FeGN1emUgdHlwb2ZyYXBoaWNhayBlcnJvd3M8L3NwYW4+PC9kaXY+PC9kaXY+PGRpdj48YnI+ T24gTWF5IDQsIDIwMTIsIGF0IDY6MzkgQU0sICJCb2NjaSwgTWF0dGhldyAoTWF0dGhldykiICZs dDs8YSBocmVmPSJtYWlsdG86bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20iPm1hdHRo ZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48 ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQo8bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1XaW5kb3dzLTEyNTIi PjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVudD0iUG93ZXJQb2ludC5TbGlkZSI+PG1ldGEgbmFt ZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgUG93ZXJQb2ludCAxNCI+PGRpdiBzdHls ZT0iZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyAiPkFsbCw8L2Rpdj48ZGl2 IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7ICI+PGJyPjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgIj5QbGVh c2UgZmluZCBiZWxvdyBhIHByb3Bvc2VkIGxpc3Qgb2YgdXBkYXRlcyB0byB0aGUgV0cgZ29hbHMg YW5kIG1pbGVzdG9uZXMgdGhhdCB3YXMgcHJlc2VudGVkIGluIFBhcmlzLCB3aXRoIG9uZSBtb2Rp ZmljYXRpb24gcHVzaGluZyB0aGUgUDJNUCBSZXF1aXJlbWVudHMgTEMgYmFjayB0byBEZWMgMjAx Mi48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 ICI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAw LCAwKTsgIj5QbGVhc2UgcG9zdCBhbnkgY29tbWVudHMgdG8gdGhlIGxpc3QgYmVmb3JlIEZyaWRh eSAxMXRoIE1heS48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2Io MCwgMCwgMCk7ICI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgY29sb3I6 IHJnYigwLCAwLCAwKTsgIj5NYXR0aGV3PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyBjb2xvcjogcmdiKDAsIDAsIDApOyAiPjxicj48L2Rpdj48ZGl2PjwhLS1TdGFydEZyYWdtZW50 LS0+PHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IG1hcmdpbi10b3A6IDJwdDsgbWFyZ2lu LWJvdHRvbTogMHB0OyBtYXJnaW4tbGVmdDogMC4zOGluOyB0ZXh0LWluZGVudDogLTAuMzhpbjsg dGV4dC1hbGlnbjogbGVmdDsgZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZl cnRpY2FsLWFsaWduOiBiYXNlbGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsgIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOnllcyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsOyBjb2xvcjogYmxhY2s7ICI+RG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KLSBQV0Uz IFdHIHN0YXJ0ZWQsIG9yZ2FuaXplIGVkaXRpbmcgdGVhbXMuPC9zcGFuPjwvcD48cCBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7 IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAtMC4zOGluOyB0ZXh0LWFsaWduOiBs ZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246 IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFj azsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEhvbGQgaW50ZXJpbSBt ZWV0aW5nLCBpbmNsdWRpbmcNCmRpc2N1c3Npb24gb2YgcHJpb3JpdHkgb2Ygc2VydmljZS1zcGVj aWZpYyBkb2N1bWVudHMgYW5kIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs OyBjb2xvcjogYmxhY2s7ICI+Y29uc2lkZXIgcHJ1bmluZyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyAiPnNvbWUgZGVsaXZlcmFibGVzPC9zcGFu PjwvcD48cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2luLXRvcDogMnB0OyBtYXJn aW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAtMC4zOGlu OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt IEFjY2VwdCBkcmFmdHMgb2Ygc2VydmljZS1zcGVjaWZpYw0KZG9jdW1lbnRzIGFzIFdHIGl0ZW1z PC9zcGFuPjwvcD48cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2luLXRvcDogMnB0 OyBtYXJnaW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAt MC4zOGluOyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBl bWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWw7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtIFBXIFJlcXVpcmVtZW50cyBEb2N1bWVudCBMYXN0DQpDYWxsPC9zcGFuPjwvcD48cCBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9t OiAwcHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAtMC4zOGluOyB0ZXh0LWFs aWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwt YWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGNvbG9y OiBibGFjazsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRETSBDaXJj dWl0IERvY3VtZW50cyBMYXN0IENhbGw8L3NwYW4+PC9wPjxwIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBtYXJnaW4tdG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgbWFyZ2luLWxlZnQ6 IDAuMzhpbjsgdGV4dC1pbmRlbnQ6IC0wLjM4aW47IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlv bjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyBE b25lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gQVRNIERvY3VtZW50cyBMYXN0IENhbGw8L3Nw YW4+PC9wPjxwIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBtYXJnaW4tdG9wOiAycHQ7IG1h cmdpbi1ib3R0b206IDBwdDsgbWFyZ2luLWxlZnQ6IDAuMzhpbjsgdGV4dC1pbmRlbnQ6IC0wLjM4 aW47IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVk OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbDsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyBEb25lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0gRXRoZXJuZXQgRG9jdW1lbnRzIExhc3QgQ2FsbDwvc3Bhbj48L3A+PHAgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IG1hcmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyBtYXJn aW4tbGVmdDogMC4zOGluOyB0ZXh0LWluZGVudDogLTAuMzhpbjsgdGV4dC1hbGlnbjogbGVmdDsg ZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogYmxhY2s7ICI+ Jm5ic3A7IERvbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBGcmFnbWVudGF0aW9uIExDPC9z cGFuPjwvcD48cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2luLXRvcDogMnB0OyBt YXJnaW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAtMC4z OGluOyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJl ZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWw7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtIFRETSBSZXF1aXJlbWVudHMgTEM8L3NwYW4+PC9wPjxwIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBtYXJnaW4tdG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgbWFyZ2luLWxlZnQ6 IDAuMzhpbjsgdGV4dC1pbmRlbnQ6IC0wLjM4aW47IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlv bjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyBE b25lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gU09ORVQgRG9jdW1lbnRzIExhc3QgQ2FsbDwv c3Bhbj48L3A+PHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IG1hcmdpbi10b3A6IDJwdDsg bWFyZ2luLWJvdHRvbTogMHB0OyBtYXJnaW4tbGVmdDogMC4zOGluOyB0ZXh0LWluZGVudDogLTAu MzhpbjsgdGV4dC1hbGlnbjogbGVmdDsgZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1i ZWQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsOyBjb2xvcjogYmxhY2s7ICI+Jm5ic3A7IERvbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLSBURE0gRG9jdW1lbnRzIExhc3QgQ2FsbDwvc3Bhbj48L3A+PHAgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IG1hcmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyBtYXJnaW4t bGVmdDogMC4zOGluOyB0ZXh0LWluZGVudDogLTAuMzhpbjsgdGV4dC1hbGlnbjogbGVmdDsgZGly ZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGlu ZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogYmxhY2s7ICI+Jm5i c3A7IERvbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBGcmFtZSBSZWxheSBEb2N1bWVudHMg TGFzdCBDYWxsPC9zcGFuPjwvcD48cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2lu LXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQt aW5kZW50OiAtMC4zOGluOyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29k ZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtIEZDUyByZXRlbnRpb24gTGFzdCBDYWxsPC9zcGFuPjwvcD48cCBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAw cHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAtMC4zOGluOyB0ZXh0LWFsaWdu OiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxp Z246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBi bGFjazsgIj4mbmJzcDsgRG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIE11bHRpLVNlZ21l bnQgUFcgUmVxdWlyZW1lbnRzIExDPC9zcGFuPjwvcD48cCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgbWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiAw LjM4aW47IHRleHQtaW5kZW50OiAtMC4zOGluOyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246 IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsgRG9u ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFZDQ1YgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsgIj5MQzwvc3Bhbj48L3A+PHAgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IG1hcmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyBt YXJnaW4tbGVmdDogMC4zOGluOyB0ZXh0LWluZGVudDogLTAuMzhpbjsgdGV4dC1hbGlnbjogbGVm dDsgZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZlcnRpY2FsLWFsaWduOiBi YXNlbGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogYmxhY2s7 ICI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyAiPjxzcGFuIHN0eWxl PSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDs8L3NwYW4+RG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtIFBXRTMgU2VydmljZXMNCk1JQnMgTEM8L3NwYW4+PC9wPjxwIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBtYXJnaW4tdG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgbWFyZ2lu LWxlZnQ6IDAuMzhpbjsgdGV4dC1pbmRlbnQ6IC0wLjM4aW47IHRleHQtYWxpZ246IGxlZnQ7IGRp cmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxp bmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyAiPiZu YnNwOyBEb25lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gUFBQL0hETEMgUFcgTEM8L3NwYW4+ PC9wPjxwIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBtYXJnaW4tdG9wOiAycHQ7IG1hcmdp bi1ib3R0b206IDBwdDsgbWFyZ2luLWxlZnQ6IDAuMzhpbjsgdGV4dC1pbmRlbnQ6IC0wLjM4aW47 IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2 ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IGJsYWNrOyAiPiZuYnNwOyBEb25lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0g V2lsZGNhcmQgRkVDIExDPC9zcGFuPjwvcD48cCBzdHlsZT0ibWFyZ2luLXRvcDogMnB0OyBtYXJn aW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiAwLjM4aW47IHRleHQtaW5kZW50OiAtMC4zOGlu OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiBibGFjazsgIj4mbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWw7ICI+RG9uZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFRETSA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj5TaWduYWxpbmc8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4gTEM8L3NwYW4+PC9wPjxwIHN0eWxlPSJtYXJnaW4t dG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgbWFyZ2luLWxlZnQ6IDAuMzhpbjsgdGV4dC1p bmRlbnQ6IC0wLjM4aW47IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2Rl LWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBBcmlhbDsgIj48IS0tU3RhcnRGcmFnbWVudC0tPjwvc3Bhbj48L3A+PHAgc3R5 bGU9Im1hcmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0 OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJh c2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7IERvbmUt DQpNdWx0aS1TZWdtZW50IEFyY2hpdGVjdHVyZSBMQzwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdp bi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rp b246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7DQpEb25lJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gQmFzaWMgUHNldWRvd2lyZSBNSUJzIExDPC9zcGFuPjwvcD48cCBz dHlsZT0ibWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IHRleHQtYWxpZ246IGxl ZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjog YmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4mbmJzcDsNCkRv bmUgLSBQVyBPQU0gTWFwcGluZyBMQzwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdpbi10b3A6IDJw dDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsg dW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7DQpEb25lIC0gTXVsdGktU2VnbWVudCBQ VyBMQzwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTog MHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJl ZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWw7ICI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyA8L3NwYW4+RG9u ZSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4tIFBXIFByb3RlY3Rp b24gYW5kIFJlc3RvcmF0aW9uIFJlcXVpcmVtZW50cyBMQzwvc3Bhbj48L3A+PHAgc3R5bGU9Im1h cmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJl Y3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5l OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7DQpEb25lIC0gUFcg UHJvdGVjdGlvbiBhbmQgUmVzdG9yYXRpb24gQXJjaGl0ZWN0dXJlPC9zcGFuPjwvcD48cCBzdHls ZT0ibWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IHRleHQtYWxpZ246IGxlZnQ7 IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4mbmJzcDsNCkRvbmUg LSBHZW5lcmljIEFzc29jaWF0ZWQgQ2hhbm5lbCBIZWFkZXIgTEM8L3NwYW4+PC9wPjxwIHN0eWxl PSJtYXJnaW4tdG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgdGV4dC1hbGlnbjogbGVmdDsg ZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPiZuYnNwOyBEPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+b25lDQotIFBXIFByb3RlY3Rpb24g YW5kIFJlc3RvcmF0aW9uIExDPC9zcGFuPjwvcD48cCBzdHlsZT0ibWFyZ2luLXRvcDogMnB0OyBt YXJnaW4tYm90dG9tOiAwcHQ7IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmlj b2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4mbmJzcDsgRG9uZQ0KLSA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj5GaWJlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsOyAiPiBDaGFubmVsIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsOyAiPkVuY2FwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+IExD PC9zcGFuPjwvcD48cCBzdHlsZT0ibWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7 IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2 ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bDsgIj4mbmJzcDsgRG9uZS0gTXVsdGlwYXRoIFBXIExDPC9zcGFuPjwvcD48cCBzdHlsZT0ibWFy Z2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVj dGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7 ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4mbmJzcDsmbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj5Eb25lIDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsOyAiPi0gUGFja2V0IFBXIFJlcXVpcmVtZW50cyAvIHNvbHV0aW9uPC9zcGFu PjwvcD48cCBzdHlsZT0ibWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IHRleHQt YWxpZ246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNh bC1hbGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj48 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPkRlYyAmbmJzcDsyMDEyPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsOyAiPi0gUDJNUCBSZXF1aXJlbWVudHMgTEM8L3NwYW4+PC9wPjxwIHN0 eWxlPSJtYXJnaW4tdG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgdGV4dC1hbGlnbjogbGVm dDsgZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZlcnRpY2FsLWFsaWduOiBi YXNlbGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPjxzcGFuIHN0eWxl PSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWw7ICI+RG9uZSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbDsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bDsgIj7igJMgUFcgU3RhdHVzIHNpZ25hbGxpbmcgaW4NCnN0YXRpYy9NUExTLVRQPC9zcGFuPjwv cD48cCBzdHlsZT0ibWFyZ2luLXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IHRleHQtYWxp Z246IGxlZnQ7IGRpcmVjdGlvbjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1h bGlnbjogYmFzZWxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj48c3Bh biBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPkp1bHkgPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+MjAxMjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbDsgIj4tDQpEeW5hbWljIE1TIFBXIExDPC9zcGFuPjwvcD48cCBzdHlsZT0ibWFyZ2lu LXRvcDogMnB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IHRleHQtYWxpZ246IGxlZnQ7IGRpcmVjdGlv bjogbHRyOyB1bmljb2RlLWJpZGk6IGVtYmVkOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7ICI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOnllcyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPlNlcHQmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4yMDEyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWw7ICI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPi0N CkVuaGFuY2VkIFBXIE9BTTwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdpbi10b3A6IDJwdDsgbWFy Z2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29k ZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQXJpYWw7ICI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNw OyZuYnNwOzwvc3Bhbj5TZXB0IDIwMTEg4oCTIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsOyAiPlNpZ25hbGluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsOyAiPiBleHRlbnNpb25zIGZvciBNUExTLVRQIE9BTTwvc3Bhbj48L3A+PHAgc3R5bGU9Im1h cmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJl Y3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5l OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbDsgIj5EZWMmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbDsgIj4yMDEyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+ IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPi0gPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+TXVsdGlzZWdtZW50PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+IFBXIE1JQjwvc3Bhbj48L3A+PHAgc3R5bGU9Im1h cmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJl Y3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5l OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbDsgIj5EZWM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bDsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4yMDEy PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+IDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPi0gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgTEM8 L3NwYW4+PC9wPjxwIHN0eWxlPSJtYXJnaW4tdG9wOiAycHQ7IG1hcmdpbi1ib3R0b206IDBwdDsg dGV4dC1hbGlnbjogbGVmdDsgZGlyZWN0aW9uOiBsdHI7IHVuaWNvZGUtYmlkaTogZW1iZWQ7IHZl cnRpY2FsLWFsaWduOiBiYXNlbGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs OyAiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+RGVjPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWw7ICI+MjAxMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsOyAiPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj7igJMgQ29u Z2VzdGlvbiBDb25zaWRlcmF0aW9ucyZuYnNwOzwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdpbi10 b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBkaXJlY3Rpb246 IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyAiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7RGVjDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4mbmJzcDsyMDEyPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWw7ICI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsOyAiPi0gUDJNUCBQVyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bDsgIj5TaWduYWxpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4g KDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyAiPnJvb3QgaW5pdGlhdGVk PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+KTwvc3Bhbj48L3A+PHAg c3R5bGU9Im1hcmdpbi10b3A6IDJwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyB0ZXh0LWFsaWduOiBs ZWZ0OyBkaXJlY3Rpb246IGx0cjsgdW5pY29kZS1iaWRpOiBlbWJlZDsgdmVydGljYWwtYWxpZ246 IGJhc2VsaW5lOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+Jm5ic3A7RGVj DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgIj4yMDEyPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7ICI+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsOyAiPuKAkyBQMk1QIFBXIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsOyAiPlNpZ25hbGluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsOyAiPiAobGVhZiBpbml0aWF0ZWQpPC9zcGFuPjwvcD48IS0tRW5kRnJhZ21lbnQtLT48 cD48L3A+PCEtLUVuZEZyYWdtZW50LS0+PC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+cHdlMyBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpwd2UzQGlldGYub3JnIj5wd2UzQGlldGYub3Jn PC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wd2UzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3 ZTM8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-67282BAB-1179-42E4-9D25-EAB05C090175-- From amalis@gmail.com Fri May 4 06:30:05 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AB521F86E2 for ; Fri, 4 May 2012 06:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 i15nwavHSW7f for ; Fri, 4 May 2012 06:30:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE821F86CA for ; Fri, 4 May 2012 06:30:05 -0700 (PDT) Received: by yhq56 with SMTP id 56so3307187yhq.31 for ; Fri, 04 May 2012 06:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CWoCwMh86SMgj0cmanQ5PCx9KcqiNO798VrLwTZgkuU=; b=Xj9VVXkj2y9O4InnEcgZpUebbk/RJg1r7IfoeXFth1+WCHx4f1UCZF/2SBaDDtk/uT jPu1R/1yLUfTpTnmMOl50Jg9s7kPQqAHBu/ahe6tpp3ZCavc7m/QzbKcUhXeUgZGp3lo FpfsxvwUVvouqSnF9INkz7fhZL0yM+BmGMoLDO+bFxZzCHTg/7a+Lqta2RHb2oedbkIW hfjjW071xiLXN35RpLDk3ujxoQuVFoXakZ0Z9tDWve0LppQniBRZr/S9JanZqBCxd37F TtyC1nADF/lMF3DpsvMWtM6pJGl407hQ9BKKTu5tFsNWvAnUV0oPwXvswAvSJ1MfsBkB gqeQ== Received: by 10.236.154.35 with SMTP id g23mr1988493yhk.107.1336138204801; Fri, 04 May 2012 06:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.109.193 with HTTP; Fri, 4 May 2012 06:29:44 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 4 May 2012 09:29:44 -0400 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf303b427d1169dd04bf35ebeb Subject: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 13:30:06 -0000 --20cf303b427d1169dd04bf35ebeb Content-Type: text/plain; charset=ISO-8859-1 To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG: Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks much, Andy --20cf303b427d1169dd04bf35ebeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG:
Are you aware of any IPR that applies to the the draft?
If so, has thi= s IPR been disclosed in compliance with IETF IPR
rules (see RFCs 3979, 4= 879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please
reply t= o this email regardless of whether or not you are
aware of any relevant = IPR. The document will not advance to
the next stage until a response ha= s been received from each
author and contributor.

If you are on the PWE3 WG email list but are= not listed as
an author or contributor, then please explicitly respond = only if
you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.

Thanks much,
Andy

--20cf303b427d1169dd04bf35ebeb-- From tnadeau@lucidvision.com Fri May 4 06:42:30 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D0721F8680 for ; Fri, 4 May 2012 06:42:30 -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=[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 0OmpZQQn6Ekp for ; Fri, 4 May 2012 06:42:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A55CC21F85D3 for ; Fri, 4 May 2012 06:42:23 -0700 (PDT) Received: from sa-nc-finance-215.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 538B020FA9CB; Fri, 4 May 2012 09:42:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau In-Reply-To: Date: Fri, 4 May 2012 09:42:20 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: "Andrew G. Malis" X-Mailer: Apple Mail (2.1257) Cc: pwe3@ietf.org Subject: Re: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 13:42:30 -0000 None from my end. On May 4, 2012:9:29 AM, at 9:29 AM, Andrew G. Malis wrote: > To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG: > > Are you aware of any IPR that applies to the the draft? > If so, has this IPR been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If you are listed as a document author or contributor please > reply to this email regardless of whether or not you are > aware of any relevant IPR. The document will not advance to > the next stage until a response has been received from each > author and contributor. > > If you are on the PWE3 WG email list but are not listed as > an author or contributor, then please explicitly respond only if > you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > > Thanks much, > Andy > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From mustapha.aissaoui@alcatel-lucent.com Fri May 4 06:59:25 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B226F21F86FC; Fri, 4 May 2012 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 v3Ojxvx88XQd; Fri, 4 May 2012 06:59:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEE221F8702; Fri, 4 May 2012 06:59:21 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q44DxIbl019212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 08:59:19 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q44Dx0jv009758 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 08:59:17 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 4 May 2012 08:59:15 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "stbryant@cisco.com" , "draft-ietf-pwe3-redundancy@tools.ietf.org" Date: Fri, 4 May 2012 08:59:15 -0500 Thread-Topic: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? Thread-Index: Ac0pYPIgBMzM+v5kRLO6eMpcAlEarQAArRHA Message-ID: <5DF53972F7E9134782DCE51624466FE50BD712FB8A@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <4FA2D904.5040007@cisco.com> In-Reply-To: <4FA2D904.5040007@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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: pwe3 , "pwe3-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 13:59:25 -0000 Hi Stewart, I am not aware of any IPR that applies to this draft. Mustapha.=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Thursday, May 03, 2012 3:14 PM To: draft-ietf-pwe3-redundancy@tools.ietf.org Cc: pwe3; pwe3-chairs@tools.ietf.org; iesg@ietf.org Subject: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? This document was on the IESG Telechat for 10 May 2012. However it has been drawn to my attention that because of the length of tim= e taken to address comments the proto statement was written before we requi= red the shepherd to asked each author to confirmed that they know of no IPR= related to this draft. I have postponed the IESG review by two weeks so that, we can check whether= there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please reply to this = email regardless of whether or not you are aware of any relevant IPR. The d= ocument will not advance to the next stage until a response has been receiv= ed from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From mustapha.aissaoui@alcatel-lucent.com Fri May 4 06:59:49 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9FB21F8702 for ; Fri, 4 May 2012 06:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.265 X-Spam-Level: X-Spam-Status: No, score=-7.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ASAzD3U4ByIK for ; Fri, 4 May 2012 06:59:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1735D21F86FC for ; Fri, 4 May 2012 06:59:48 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q44Dxd0l020169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 08:59:39 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q44DxcjA024522 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 08:59:39 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 4 May 2012 08:59:34 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "Andrew G. Malis" , "pwe3@ietf.org" Date: Fri, 4 May 2012 08:59:34 -0500 Thread-Topic: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 Thread-Index: Ac0p+hWSVvUAzjWxQEa71/Cray04OwAA/dig Message-ID: <5DF53972F7E9134782DCE51624466FE50BD712FB8C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50BD712FB8CUSNAVSXCHMBSC_" 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.12 Subject: Re: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 13:59:49 -0000 --_000_5DF53972F7E9134782DCE51624466FE50BD712FB8CUSNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andy, I am not aware of any IPR that applies to this draft. Regards, Mustapha. ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Friday, May 04, 2012 9:30 AM To: pwe3@ietf.org Subject: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG: Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks much, Andy --_000_5DF53972F7E9134782DCE51624466FE50BD712FB8CUSNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Andy,

I am not aware of any IPR that applies to th= is=20 draft.

Regards,

Mustapha.

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G.=20 Malis
Sent: Friday, May 04, 2012 9:30 AM
To:=20 pwe3@ietf.org
Subject: [PWE3] IPR checking on=20 draft-ietf-pwe3-redundancy-bit-07

To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE= 3=20 WG:

Are you aware of any IPR that applies to the the draft?
If so= , has=20 this IPR been disclosed in compliance with IETF IPR
rules (see RFCs 3979= ,=20 4879, 3669 and 5378 for more details)?

If you are listed as a docume= nt=20 author or contributor please
reply to this email regardless of whether o= r not=20 you are
aware of any relevant IPR. The document will not advance to
t= he=20 next stage until a response has been received from each
author and=20 contributor.

If you are on the PWE3 WG email list but are not listed= =20 as
an author or contributor, then please explicitly respond only if
y= ou=20 are aware of any IPR that has not yet been disclosed in
conformance with= IETF=20 rules.

Thanks much,
Andy

--_000_5DF53972F7E9134782DCE51624466FE50BD712FB8CUSNAVSXCHMBSC_-- From matthew.bocci@alcatel-lucent.com Fri May 4 07:01:54 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762DB21F85BB for ; Fri, 4 May 2012 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.696 X-Spam-Level: X-Spam-Status: No, score=-109.696 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 5gI4N+atskZ4 for ; Fri, 4 May 2012 07:01:53 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9801821F85B1 for ; Fri, 4 May 2012 07:01:53 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q44E1HEi012830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 16:01:51 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 4 May 2012 16:01:42 +0200 From: "Bocci, Matthew (Matthew)" To: "Andrew G. Malis" , "pwe3@ietf.org" Date: Fri, 4 May 2012 16:01:41 +0200 Thread-Topic: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 Thread-Index: Ac0p/m6gmPmqnEdeR36yHA73ZbzKkQ== 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.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBC99FBC2A481matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:01:54 -0000 --_000_CBC99FBC2A481matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, I'm not aware of any IPR applying to this draft. Matthew On 04/05/2012 14:29, "Andrew G. Malis" > wrote: To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG: Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks much, Andy --_000_CBC99FBC2A481matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andy,

I'm not aware of any IPR applying to this draft.

Matthew

On 04/05/2012 14:29, "Andrew G. Malis" <amalis@gmail.com> wrote:

To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG:
Are you aware of any IPR that applies to the the draft?
If so, has this IPR been disclosed in compliance with IETF IPR
rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please
reply to this email regardless of whether or not you are
aware of any relevant IPR. The document will not advance to
the next stage until a response has been received from each
author and contributor.

If you are on the PWE3 WG email list but are not listed as
an author or contributor, then please explicitly respond only if
you are aware of any IPR that has not yet been disclosed in
conformance with IETF rules.

Thanks much,
Andy

--_000_CBC99FBC2A481matthewboccialcatellucentcom_-- From praveen.muley@alcatel-lucent.com Fri May 4 10:54:34 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1421F859A; Fri, 4 May 2012 10:54:34 -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=[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 Ob+ureDs5jiG; Fri, 4 May 2012 10:54:33 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBC821F8599; Fri, 4 May 2012 10:54:32 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q44HsQxm001733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 12:54:27 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q44HsQZc009530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 May 2012 12:54:26 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 4 May 2012 12:54:26 -0500 From: "Muley, Praveen V (Praveen)" To: "stbryant@cisco.com" , "draft-ietf-pwe3-redundancy@tools.ietf.org" Date: Fri, 4 May 2012 12:54:25 -0500 Thread-Topic: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? Thread-Index: Ac0pYPIgBMzM+v5kRLO6eMpcAlEarQAArRHAAC7N8bA= Message-ID: <2073A6C5467C99478898544C6EBA3F4602C1529678@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <4FA2D904.5040007@cisco.com> <5DF53972F7E9134782DCE51624466FE50BD712FB8A@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50BD712FB8A@USNAVSXCHMBSC2.ndc.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: pwe3 , "pwe3-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 17:54:34 -0000 =20 Hi Stewart, I am not aware of any IPR that applies to this draft. -Praveen =20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Thursday, May 03, 2012 3:14 PM To: draft-ietf-pwe3-redundancy@tools.ietf.org Cc: pwe3; pwe3-chairs@tools.ietf.org; iesg@ietf.org Subject: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? This document was on the IESG Telechat for 10 May 2012. However it has been drawn to my attention that because of the length of tim= e taken to address comments the proto statement was written before we requi= red the shepherd to asked each author to confirmed that they know of no IPR= related to this draft. I have postponed the IESG review by two weeks so that, we can check whether= there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please reply to this = email regardless of whether or not you are aware of any relevant IPR. The d= ocument will not advance to the next stage until a response has been receiv= ed from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From gregory.mirsky@ericsson.com Fri May 4 12:54:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD421E8039 for ; Fri, 4 May 2012 12:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AFrKhinQTzyY for ; Fri, 4 May 2012 12:54:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B723321F85F1 for ; Fri, 4 May 2012 12:54:18 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q44JruTd030429; Fri, 4 May 2012 14:54:16 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 4 May 2012 15:53:56 -0400 From: Gregory Mirsky To: "Carlos Pignataro (cpignata)" , "Bocci, Matthew (Matthew)" Date: Fri, 4 May 2012 15:53:55 -0400 Thread-Topic: [PWE3] Updates to goals and milestones Thread-Index: Ac0p6lKPXCqc6kZ2Stak6pCJF4vbwgAPLGWQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13552DBB1A8EUSAACMS0715e_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:54:20 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13552DBB1A8EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Matthew, Carlos, et al., I agree with Carlos that updates to VCCV Control Channels resulting from di= scussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capab= ility extension that, I think, referenced as "Enhanced PW OAM". Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Car= los Pignataro (cpignata) Sent: Friday, May 04, 2012 4:38 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, In Paris there was discussion (and subsequent followup) about a VCCV-bis do= cument. I am not sure if a formal consensus call was issued on that, but I = wonder if it needs to be captured as a milestone (or how it relates to "Enh= anced PW OAM"). Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" > wrote: All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012 - P2MP Requirements LC Done - PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012 - Enhanced PW OAM Sept 2011 - Signaling extensions for MPLS-TP OAM Dec 2012 - Multisegment PW MIB Dec 2012 - Security Considerations LC Dec 2012 - Congestion Considerations Dec 2012 - P2MP PW Signaling (root initiated) Dec 2012 - P2MP PW Signaling (leaf initiated) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF13552DBB1A8EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Matthew, Carlos, et al.,
I agree with Carlos that updates to VCCV Control C= hannels=20 resulting from discussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, = can=20 be captured in Milestones. But I think that this work not=20 necessarily tied with CV capability extension that, I think,=20 referenced as "Enhanced PW OAM".
 
    Regards,
      &= nbsp;=20 Greg
From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos Pignataro=20 (cpignata)
Sent: Friday, May 04, 2012 4:38 AM
To: Bocci= ,=20 Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3]= =20 Updates to goals and milestones

Matthew,

In Paris there was discussion (and subsequent followup) about a VCCV-b= is=20 document. I am not sure if a formal consensus call was issued on that, but = I=20 wonder if it needs to be captured as a milestone (or how it relates to "Enhanced=20 PW OAM"). 

Thumb=20 typed by Carlos Pignataro.
Excuze=20 typofraphicak errows

On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-luce= nt.com>=20 wrote:

All,

Please find below a pro= posed=20 list of updates to the WG goals and milestones that was presented in Pari= s,=20 with one modification pushing the P2MP Requirements LC back to Dec 2012.<= /DIV>

Please post any comment= s to=20 the list before Friday 11th May.

Matthew

 Done     -= PWE3=20 WG started, organize editing teams.

  Done   &= nbsp; -=20 Hold interim meeting, including discussion of priority of service-specifi= c=20 documents and con= sider=20 pruning some=20 deliverables

  Done   &= nbsp; -=20 Accept drafts of service-specific documents as WG items

  Done   &= nbsp; -=20 PW Requirements Document Last Call

  Done   &= nbsp; -=20 TDM Circuit Documents Last Call

  Done   &= nbsp; -=20 ATM Documents Last Call

  Done   &= nbsp; -=20 Ethernet Documents Last Call

  Done   &= nbsp; -=20 Fragmentation LC

  Done   &= nbsp; -=20 TDM Requirements LC

  Done   &= nbsp; -=20 SONET Documents Last Call

  Done   &= nbsp; -=20 TDM Documents Last Call

  Done   &= nbsp; -=20 Frame Relay Documents Last Call

  Done   &= nbsp; -=20 FCS retention Last Call

  Done   &= nbsp; -=20 Multi-Segment PW Requirements LC

  Done   &= nbsp; -=20 VCCV LC   Done     - P= WE3=20 Services MIBs LC

  Done   &= nbsp; -=20 PPP/HDLC PW LC

  Done   &= nbsp; -=20 Wildcard FEC LC

  Done     - TDM Signaling=20 LC

  Done- Multi-Segment Architecture=20 LC

  Done     - Basic= =20 Pseudowire MIBs LC

  Done - PW OAM Mapping LC

  Done - Multi-Segment PW LC

  Done=20 - PW Protection and Restoration= =20 Requirements LC

  Done - PW Protection and Restoration= =20 Architecture

  Done - Generic Associated Channel Hea= der=20 LC

  Done=20 - PW Protection and Restoration LC

  Done - Fiber=20 Channel Encap LC

  Done- Multipath PW LC

  Done  -=20 Packet PW Requirements / solution

  Dec  2012 -= P2MP=20 Requirements LC

  Done  – PW=20 Status signalling in static/MPLS-TP

  July 2012- Dynamic MS PW LC

  Sept 2012- Enhanced PW OAM

  Sept 2011 – <= SPAN=20 style=3D"FONT-FAMILY: Arial">Signaling=20 extensions for MPLS-TP OAM

  Dec 2012- Multisegment PW MIB

  Dec 2012- Security Considerations=20 LC

  Dec 2012– Congestion=20 Considerations 

 Dec  2012=20 - P2MP PW Signaling=20 (root initiated)

 Dec 2012– P2MP PW Signaling=20 (leaf initiated)

_______________________________________________
pwe3=20 mailing list
pwe3@ietf.org
https://www.ietf.org/= mailman/listinfo/pwe3
--_000_FE60A4E52763E84B935532D7D9294FF13552DBB1A8EUSAACMS0715e_-- From wwwrun@rfc-editor.org Mon May 7 12:03:56 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC221F8663; Mon, 7 May 2012 12:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 tR2z6mLjSCDU; Mon, 7 May 2012 12:03:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 146D821F865B; Mon, 7 May 2012 12:03:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 81917B1E008; Mon, 7 May 2012 12:01:41 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120507190144.81917B1E008@rfc-editor.org> Date: Mon, 7 May 2012 12:01:41 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 6478 on Pseudowire Status for Static Pseudowires X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 19:03:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6478 Title: Pseudowire Status for Static Pseudowires Author: L. Martini, G. Swallow, G. Heron, M. Bocci Status: Standards Track Stream: IETF Date: May 2012 Mailbox: lmartini@cisco.com, swallow@cisco.com, giheron@cisco.com, matthew.bocci@alcatel-lucent.com Pages: 13 Characters: 28285 Updates: RFC5885 I-D Tag: draft-ietf-pwe3-static-pw-status-10.txt URL: http://www.rfc-editor.org/rfc/rfc6478.txt This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK] This document is a product of the Pseudowire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From amalis@gmail.com Mon May 7 12:24:32 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEEE21F857F for ; Mon, 7 May 2012 12:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 A6rQqTM8k3w1 for ; Mon, 7 May 2012 12:24:31 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85721F8575 for ; Mon, 7 May 2012 12:24:31 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1295745ggm.31 for ; Mon, 07 May 2012 12:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=hpAT7nOQQD+Dajn6qxWbbSPjT9uoVF9oATNg/5hcM5U=; b=UF3Ogn9Ud9H43rHYmJn9i2gF6xhkrhvf/7eIJIG2SwuD+eaTgrPHqJ8r4fDg3m0QO+ 6mcQwaBDAu+rJj3TI1KiLsp8HsIFLflXXxvQYubIzV5rpkdYmJrnwKDcibl13T4zbNpW C9AWo/pzAMib/cyxCbWvIigG285mPlFYT74pXEARb0Vyr79ELVMT5vE3OPtWeYWCvWFX b/r5p7SCdrqZvrc53MEJVu2Hd+28E6PSnmSMQ+GPACJ1VXqURDcWcGAPKGRDG4e27M2R 6kxrVcL2bk27bspLfJnkGvjIr1OqifY8OoCLRdnBxvHwDLd/8r5Mg3cvLshgGC7v5Lqt fXgg== Received: by 10.236.185.10 with SMTP id t10mr20884889yhm.112.1336418670964; Mon, 07 May 2012 12:24:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.109.193 with HTTP; Mon, 7 May 2012 12:24:10 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 7 May 2012 15:24:10 -0400 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf3026714c276e0f04bf7738d1 Subject: Re: [PWE3] PWE3 WG last call on draft-ietf-pwe3-cbit-negotiation-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 19:24:33 -0000 --20cf3026714c276e0f04bf7738d1 Content-Type: text/plain; charset=ISO-8859-1 This ends WG last call, with no comments received. I will work on forwarding this to the IESG for publication. Cheers, Andy On Mon, Apr 23, 2012 at 3:05 PM, Andrew G. Malis wrote: > This email begins a two week working group last call for > draft-ietf-pwe3-cbit-negotiation-03, > https://tools.ietf.org/html/draft-ietf-pwe3-cbit-negotiation-03 . > > The authors have all indicated that they are not aware of any IPR on this > draft, and no IPR disclosures have been filed. If anyone else is aware of > IPR regarding this draft, this would be an excellent time to speak up. > > Please post any comments on this draft to the PWE3 mailing list. > > This working group last call will end on Monday 7 May 2012. > > Regards, > Andy & Matthew > > --20cf3026714c276e0f04bf7738d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This ends WG last call, with no comments received. I will work on forwardin= g this to the IESG for publication.

Cheers,
Andy

On Mon, Apr 23, 2012 at 3:05 PM, Andrew G. Malis <amalis@= gmail.com> wrote:
This email begins a two week working gr= oup last call for draft= -ietf-pwe3-cbit-negotiation-03, https://tools.ietf.org/h= tml/draft-ietf-pwe3-cbit-negotiation-03 .

The authors have all indicated that they are not aware of any IPR on th= is draft, and no IPR disclosures have been filed. If anyone else is aware o= f IPR regarding this draft, this would be an excellent time to speak up.

Please post any comments on this draft to the PWE= 3 mailing list.

This working group last call will end on Monday 7 May 2012.

Regards,
Andy & Matthew


--20cf3026714c276e0f04bf7738d1-- From Internet-Drafts@ietf.org Mon May 7 12:32:09 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A421F8724; Mon, 7 May 2012 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 zcUJ85EsdMKv; Mon, 7 May 2012 12:32:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AFA21F865F; Mon, 7 May 2012 12:32:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507193201.16311.22930.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 12:32:01 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-jain-pwe3-p2mp-pw-lsp-ping-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 19:32:09 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Definition of P2MP PW TLV for LSP-Ping Mechanisms Author(s) : P. Jain, et al Filename : draft-jain-pwe3-p2mp-pw-lsp-ping Pages : 8 Date : May 7, 2012 LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jain-pwe3-p2mp-pw-lsp-ping-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-jain-pwe3-p2mp-pw-lsp-ping"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-05-07123201.I-D@ietf.org> --NextPart-- From matthew.bocci@alcatel-lucent.com Tue May 8 03:19:32 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0657921F855B for ; Tue, 8 May 2012 03:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.736 X-Spam-Level: X-Spam-Status: No, score=-109.736 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 VHPrHHzAtYZu for ; Tue, 8 May 2012 03:19:31 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id A406D21F84AF for ; Tue, 8 May 2012 03:19:30 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q48AJPsS025148 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 May 2012 12:19:26 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 8 May 2012 12:19:25 +0200 From: "Bocci, Matthew (Matthew)" To: Gregory Mirsky , "Carlos Pignataro (cpignata)" Date: Tue, 8 May 2012 12:19:22 +0200 Thread-Topic: [PWE3] Updates to goals and milestones Thread-Index: Ac0tBAqdWVABeAG2RXaJ39WbbgnlKw== 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.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBCE99C02A66Dmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 10:19:32 -0000 --_000_CBCE99C02A66Dmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greg, Carlos, I think this milestone started life as referring to any PW OAM extensions r= equired for MPLS-TP. However, it has become very ambiguous. There are reall= y a number of objectives that we should capture, including at least the fol= lowing: * Additional VCCV Channel Type using the GAL * VCCV capability negotiation for MPLS-TP OAM tools. * Rationalisation of VCCV (RFC5085bis) I think we could replace this milestone with milestones for the above. Regards Matthew On 04/05/2012 20:53, "Gregory Mirsky" > wrote: Dear Matthew, Carlos, et al., I agree with Carlos that updates to VCCV Control Channels resulting from di= scussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capab= ility extension that, I think, referenced as "Enhanced PW OAM". Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Carlos Pignataro (cpignata) Sent: Friday, May 04, 2012 4:38 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, In Paris there was discussion (and subsequent followup) about a VCCV-bis do= cument. I am not sure if a formal consensus call was issued on that, but I = wonder if it needs to be captured as a milestone (or how it relates to "Enh= anced PW OAM"). Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" > wrote: All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012- P2MP Requirements LC Done =96 PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012- Enhanced PW OAM Sept 2011 =96 Signaling extensions for MPLS-TP OAM Dec 2012- Multisegment PW MIB Dec 2012- Security Considerations LC Dec 2012=96 Congestion Considerations Dec 2012- P2MP PW Signaling (root initiated) Dec 2012=96 P2MP PW Signaling (leaf initiated) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_CBCE99C02A66Dmatthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Greg, Carlos,

I think this milestone started life as referring to any PW OAM exte= nsions required for MPLS-TP. However, it has become very ambiguous. There a= re really a number of objectives that we should capture, including at least= the following:

  • Additional VCCV Channel Type us= ing the GAL
  • VCCV capability negotiation for MPLS-TP OAM tools.
    • =
  • Rationalisation of VCCV (RFC5085bis)

I thi= nk we could replace this milestone with milestones for the above.

Regards

Matthew

On 04/05/2012 20:53, "Gr= egory Mirsky" <grego= ry.mirsky@ericsson.com> wrote:

Dear Matthew, Carlos, et al.,
I agree with Carlos that updates to= VCCV Control Channels resulting from discussion of GAL as Type 4 VCCV CC, = perhaps as RFC5085bis, can be captured in Milestones. But I think that this work not necessarily tied with= CV capability extension that, I think, referenced as "Enhanced PW OAM= ".
 
    Regards,
  = ;      Greg
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, May= 04, 2012 4:38 AM
To: Bocci, Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3= ] Updates to goals and milestones

Matth= ew,

In Paris there was discussion (and subsequent = followup) about a VCCV-bis document. I am not sure if a formal consensus ca= ll was issued on that, but I wonder if it needs to be captured as a milesto= ne (or how it relates to "Enhanced PW OAM"). 

Thumb typed by Carlos Pig= nataro.
Excuze typofraphicak errows

On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.= com> wrote:

<= meta content=3D"PowerPoint.Slide" name=3D"ProgId">
All,

=
Please find below a= proposed list of updates to the WG goals and milestones that was presented= in Paris, with one modification pushing the P2MP Requirements LC back to D= ec 2012.

<= div style=3D"FONT-SIZE: 14px; COLOR: rgb(0,0,0)">Please post any comments t= o the list before Friday 11th May.

= Matthew

 Done     - PWE3 WG started, organize editing t= eams.

  Done     - Hold = interim meeting, including discussion of priority of service-specific docum= ents and consider pruning some deliverables

  Done     - Accept drafts = of service-specific documents as WG items

  = Done     - PW Requirements Document Last Call

  Done     - TDM Circuit Document= s Last Call

  Done     -= ATM Documents Last Call

  Done  &= nbsp;  - Ethernet Documents Last Call

 = Done     - Fragmentation LC

=   Done     - TDM Requirements LC

  Done     - SONET Documents Last Call

  Done     - TDM Documents= Last Call

  Done     -= Frame Relay Documents Last Call

  Done = ;    - FCS retention Last Call

&nb= sp; Done     - Multi-Segment PW Requirements LC<= /p>

  Done     - VCCV LC

  Don= e     - PWE3 Services MIBs LC

  Done     - PPP/HDLC PW LC

  Done     - Wildcard FEC LC

  Done     - TDM Signaling LC

  Done- M= ulti-Segment Architecture LC

  Done &nbs= p;   - Basic Pseudowire MIBs LC

  D= one - PW OAM Mapping LC

  Done - Multi-Segmen= t PW LC

  <= /span>Done - PW Protection and Re= storation Requirements LC

  Done - PW Protect= ion and Restoration Architecture

  Done - Gen= eric Associated Channel Header LC

  D<= span style=3D"FONT-FAMILY: Arial">one - PW Protection and Restoration LC

  Done - Fiber Channel Encap LC

  Done- Multipath PW LC

  Done  - Packet PW Requirements / solution

  Dec  2012- P2MP Requirements LC=

  Done  =96 PW Status signalling in static/MPLS-TP

  July 2012 - Dynamic MS PW LC

  Sept&n= bsp;2012- Enhanced PW OA= M

  Sept 2011 =96 Signaling extensions for MPLS-TP OAM

  Dec 2012- Multisegment PW MIB

  Dec 2012- Security Considerations LC

  Dec 2012=96 Cong= estion Considerations 

 Dec  2012- P2MP PW Signalingroot initiated)

 Dec 2012=96 P2MP PW Signaling= (leaf initiated)

_________________= ______________________________
pwe3 mailing list
= pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3
 --_000_CBCE99C02A66Dmatthewboccialcatellucentcom_-- From yaakov_s@rad.com Tue May 8 03:59:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7718221F84A1 for ; Tue, 8 May 2012 03:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 Z1N11I1Ji2qQ for ; Tue, 8 May 2012 03:59:39 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7A921F8491 for ; Tue, 8 May 2012 03:59:38 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 8 May 2012 13:40:49 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 8 May 2012 13:59:25 +0300 From: Yaakov Stein To: Stewart Bryant , "pwe3@ietf.org" Thread-Topic: once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmw== Date: Tue, 8 May 2012 10:59:25 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043C64FBEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020201.4FA8FC8E.006C,ss=1,fgs=0 Subject: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 10:59:40 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043C64FBEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart and all, RFC 4448 has an erratum marked "Held for Document Update by Stewart Bryant"= . This erratum (penned by Alfred Hoenes) deals with several issues, from a "subtle typo" to the misleading figure label. However, there is one issue with which I agree and which I think is importa= nt; but regarding which I don't recall discussion on the list. With the entire group of comments marked as "held for document update" rath= er than as "approved", I am not sure whether this issue has been agreed upon. The text in question is this : When the PE receives an Ethernet frame, and the frame has a VLAN tag, we can distinguish two cases: 1. The tag is service-delimiting. This means that the tag was placed on the frame by some piece of service provider-operated equipment, and the tag is used by the service provider to distinguish the traffic. For example, LANs from different customers might be attached to the same service provider switch, which applies VLAN tags to distinguish one customer's traffic from another's, and then forwards the frames to the PE. 2. The tag is not service-delimiting. This means that the tag was placed in the frame by a piece of customer equipment, and is not meaningful to the PE. Alfred states that The term, "service delimiting", apparently here is defined by the origin of the tag, not by its function. I understand where the original text comes from. In the provider provisioned model the SP doesn't trust the customer to prop= erly tag the frames, and so doesn't look at tags inserted by CE devices. However, other groups (e.g., MEF) assume careful prior negotiation (of the legal kind, not the protocol kind) between customer and SP, and so the C-tag may indeed be service delimiting. More specifically, one can make the distinction between three "bundling" ty= pes based on the C-tag. *All-to-one means that all C-tags are taken as one "flow" or "EVC" or whate= ver, and thus the mapping to PW is independent of this tag. So here the C-tag is NOT service delimiting. *One-to-one means that each C-tag is mapped to a single EVC. So the C-tag determines the PW, and is thus service delimiting. *Arbitrary bundling means we have a general mapping of C-tags to EVCs (and so includes the previous two). In general the C-tag here too is service delimiting. (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as the "bundling" case.) Do you agree with this analysis, and thus with the need to remove the cavea= t in 4448 that states that C-tags can not be service delimiting ? Y(J)S --_000_07F7D7DED63154409F13298786A2ADC9043C64FBEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart and all,

 

RFC 4448 has an erratum marked "Held for Docume= nt Update by Stewart Bryant".

This erratum (penned by Alfred Hoenes) deals with se= veral issues,

from a "subtle typo" to the misleading fig= ure label.

 

However, there is one issue with which I agree and w= hich I think is important;

but regarding which I don't recall discussion on the= list.

With the entire group of comments marked as "he= ld for document update" rather than as "approved",

I am not sure whether this issue has been agreed upo= n.

 

The text in question is this :

   When the PE receives an E= thernet frame, and the frame has a VLAN tag,

   we can distinguish two ca= ses:

 

      1. The = tag is service-delimiting.  This means that the tag was

      &n= bsp;  placed on the frame by some piece of service provider-operated

      &n= bsp;  equipment, and the tag is used by the service provider to

      &n= bsp;  distinguish the traffic.  For example, LANs from different<= o:p>

      &n= bsp;  customers might be attached to the same service provider

      &n= bsp;  switch, which applies VLAN tags to distinguish one customer's

      &n= bsp;  traffic from another's, and then forwards the frames to the PE.<= o:p>

 

      2. The = tag is not service-delimiting.  This means that the tag was=

      &n= bsp;  placed in the frame by a piece of customer equipment, and is

      &n= bsp;  not meaningful to the PE.

 

Alfred states that

The term, "service delimiting",=
 apparently here is defined
by the origin of the tag, not by its func=
tion.

I understand where the original text comes from.

In the provider provisioned model the SP doesn't tru= st the customer to properly tag the frames,

and so doesn't look at tags inserted by CE devices.<= o:p>

 

However, other groups (e.g., MEF) assume careful pri= or negotiation

(of the legal kind, not the protocol kind) between c= ustomer and SP,

and so the C-tag may indeed be service delimiting.

 

More specifically, one can make the distinction betw= een three "bundling" types

based on the C-tag.

 

*All-to-one means that all C-tags are taken as one &= quot;flow" or "EVC" or whatever,

and thus the mapping to PW is independent of this ta= g.

So here the C-tag is NOT service delimiting.

 

*One-to-one means that each C-tag is mapped to a sin= gle EVC.

So the C-tag determines the PW, and is thus service = delimiting.

 

*Arbitrary bundling means we have a general mapping<= o:p>

of C-tags to EVCs (and so includes the previous two)= .

In general the C-tag here too is service delimiting.=

 

(NOTE: the arbitrary and One-to-one cases are lumped= together in MEF as

the "bundling" case.)

 

Do you agree with this analysis, and thus with the n= eed to remove the caveat in 4448

that states that C-tags can not be service delimitin= g ?

 

Y(J)S

 

--_000_07F7D7DED63154409F13298786A2ADC9043C64FBEXRAD5adradcoil_-- From Alexander.Vainshtein@ecitele.com Tue May 8 04:20:21 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCC221F8495 for ; Tue, 8 May 2012 04:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 dE498nAlOdFK for ; Tue, 8 May 2012 04:20:19 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E321F849A for ; Tue, 8 May 2012 04:20:18 -0700 (PDT) Received: from [193.109.254.147:43161] by server-9.bemta-14.messagelabs.com id C2/F9-05787-17109AF4; Tue, 08 May 2012 11:20:17 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1336476013!8186508!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 23552 invoked from network); 8 May 2012 11:20:13 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-12.tower-27.messagelabs.com with SMTP; 8 May 2012 11:20:13 -0000 X-AuditID: a8571401-b7f8d6d0000035b0-25-4fa901eea7ba Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 7E.22.13744.EE109AF4; Tue, 8 May 2012 13:22:22 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Tue, 8 May 2012 13:20:12 +0200 From: Alexander Vainshtein To: Yaakov Stein , Stewart Bryant Thread-Topic: once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQ Date: Tue, 8 May 2012 11:20:10 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.216.82] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02055AF0FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURTlzbRlqIwZarHPRmMd8UOxpIhLibTRDxU1WhQNxg9xbF/b0XZm MlMVjIk1xg13Ax+CuESCBRcQNWoEF4gfIm6JojFIiCxxiRtGQVF0hgEkMb6v884579z7Zu4j cMOeaDPBciEkckyA1uk1ehBltn4EZS5bZcEE+/7OSxr7g/ajwP4pr1s7C0/P77mgTS8p+Y6l Hz7nzcBXhkEaw3F8iAkhiwdJbgedIbIbGHcubWE9DjqZtggBxo2CiAs5aEYQEOehnXrLPytN trGcBXFu3sNyPgc9P9NltdunpVqTaecyPytZkDXIsAFLEEkS40MWmVHa5jyrz+P+zrr7mLCH z6nenRoGT1bngRgCUlPhh523NCoeCR81V+jygJ4wUE8A3Hqjq39TAuCd4vdaxaWjHLDqzEud go1UOjz+7FAfj1Pj4ZWibX38CGoc/HDtQL+HhsVdD7UqngIbmlr6qmmoBFjefBQomKQWwUi4 KFrBBmoBDJ/8hik4hloIy2t29HmA3F1X/VlMrWWCL9qOY2rXFCypfoirOB6+ae2VaxEyHgt/ fONVOw+/dt7UqaXi4N0jbf0XHgVvR55rDoKRhUNSC4ccKRxyROUnwxPXO3UqToSlJ9/hA7jh Vis2lD8BosuBySuyHkGQ1thsyUnIzYZQACW5+WAVkKcokmUEV8GrfUm1gCIAHUuGP592GbTM Bik3WAtGERgdT+b/jrgMw9fwnlw/I/mzxfUBJNUCSOC0kdxcIGukh8ndhER+QJojf9pDuHmY m1d+fCg7xWb7/4Y2kRVLnS4D5ZNHcx1CAhIHckYTBA3J7VFlLkOciHwox8sGQn9ljIhR2oiV 29iieEhJYIIS61P1ejCBOJZ/+SkwaDieQ2YT+VgxUYrJv54bzHkLTPLFR5AFihorj+pgwls5 HJPDL3aUKuHy0xmUzGEg3BvD1ln3LnfunDE9beZNY9Zu1JJ6JHvF91UTq0afTcKmVQTn1lyq WVs3vfJGZmP7y4PN3pQrs+f+5J42LVjxpToKu96zKjpuf+PC5Rqmu802+X7ikkoQjMrUxxVf sI3vSKjNLNtxOCdha/euiLgxK/X1qUhib49zsbE3HG9O+TXPS2skP5M8CRcl5g9Ck4IYHgQA AA== Cc: "pwe3@ietf.org" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 11:20:21 -0000 --_000_F9336571731ADE42A5397FC831CEAA02055AF0FRIDWPPMB001ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yaakov, Stewart and all, I believe that 5061 effectively supports Yaakov's point of view. My 2c, Sasha From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaak= ov Stein Sent: Tuesday, May 08, 2012 1:59 PM To: Stewart Bryant; pwe3@ietf.org Subject: [PWE3] once upon an erratum Stewart and all, RFC 4448 has an erratum marked "Held for Document Update by Stewart Bryant". This erratum (penned by Alfred Hoenes) deals with several issues, from a "subtle typo" to the misleading figure label. However, there is one issue with which I agree and which I think is importan= t; but regarding which I don't recall discussion on the list. With the entire group of comments marked as "held for document update" rathe= r than as "approved", I am not sure whether this issue has been agreed upon. The text in question is this : When the PE receives an Ethernet frame, and the frame has a VLAN tag, we can distinguish two cases: 1. The tag is service-delimiting. This means that the tag was placed on the frame by some piece of service provider-operated equipment, and the tag is used by the service provider to distinguish the traffic. For example, LANs from different customers might be attached to the same service provider switch, which applies VLAN tags to distinguish one customer's traffic from another's, and then forwards the frames to the PE. 2. The tag is not service-delimiting. This means that the tag was placed in the frame by a piece of customer equipment, and is not meaningful to the PE. Alfred states that The term, "service delimiting", apparently here is defined by the origin of the tag, not by its function. I understand where the original text comes from. In the provider provisioned model the SP doesn't trust the customer to prope= rly tag the frames, and so doesn't look at tags inserted by CE devices. However, other groups (e.g., MEF) assume careful prior negotiation (of the legal kind, not the protocol kind) between customer and SP, and so the C-tag may indeed be service delimiting. More specifically, one can make the distinction between three "bundling" typ= es based on the C-tag. *All-to-one means that all C-tags are taken as one "flow" or "EVC" or whatev= er, and thus the mapping to PW is independent of this tag. So here the C-tag is NOT service delimiting. *One-to-one means that each C-tag is mapped to a single EVC. So the C-tag determines the PW, and is thus service delimiting. *Arbitrary bundling means we have a general mapping of C-tags to EVCs (and so includes the previous two). In general the C-tag here too is service delimiting. (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as the "bundling" case.) Do you agree with this analysis, and thus with the need to remove the caveat= in 4448 that states that C-tags can not be service delimiting ? Y(J)S 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. --_000_F9336571731ADE42A5397FC831CEAA02055AF0FRIDWPPMB001ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Yaakov, Stewart and all= ,

I believe that 5061 eff= ectively supports Yaakov’s point of view.

 

My 2c,

    = ; Sasha

 

From: pwe3-bounce= s@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, May 08, 2012 1:59 PM
To: Stewart Bryant; pwe3@ietf.org
Subject: [PWE3] once upon an erratum

 

Stewart and all,

 

RFC 4448 has an erratum marked "Held for Documen= t Update by Stewart Bryant".

This erratum (penned by Alfred Hoenes) deals with sev= eral issues,

from a "subtle typo" to the misleading figu= re label.

 

However, there is one issue with which I agree and wh= ich I think is important;

but regarding which I don't recall discussion on the= list.

With the entire group of comments marked as "hel= d for document update" rather than as "approved",

I am not sure whether this issue has been agreed upon= .

 

The text in question is this :

   When the PE receiv= es an Ethernet frame, and the frame has a VLAN tag,

   we can distinguish= two cases:

 

     = 1. The tag is service-delimiting.  This means that the tag was

     &= nbsp;   placed on the frame by some piece of service provider-oper= ated

     &= nbsp;   equipment, and the tag is used by the service provider to<= o:p>

     &= nbsp;   distinguish the traffic.  For example, LANs from diff= erent

     &= nbsp;   customers might be attached to the same service provider

     &= nbsp;   switch, which applies VLAN tags to distinguish one custome= r's

     &= nbsp;   traffic from another's, and then forwards the frames to th= e PE.

 

     = 2. The tag is not service-delimiting.  This means that the tag was

     &= nbsp;   placed in the frame by a piece of customer equipment, and= is

     &= nbsp;   not meaningful to the PE.

 

Alfred states that

The term, "service delimiting",=
 apparently here is defined
by the origin of the tag, not by its funct=
ion.

I understand where the original text comes from.

In the provider provisioned model the SP doesn't trus= t the customer to properly tag the frames,

and so doesn't look at tags inserted by CE devices.

 

However, other groups (e.g., MEF) assume careful prio= r negotiation

(of the legal kind, not the protocol kind) between cu= stomer and SP,

and so the C-tag may indeed be service delimiting.

 

More specifically, one can make the distinction betwe= en three "bundling" types

based on the C-tag.

 

*All-to-one means that all C-tags are taken as one &q= uot;flow" or "EVC" or whatever,

and thus the mapping to PW is independent of this tag= .

So here the C-tag is NOT service delimiting.

 

*One-to-one means that each C-tag is mapped to a sing= le EVC.

So the C-tag determines the PW, and is thus service d= elimiting.

 

*Arbitrary bundling means we have a general mapping

of C-tags to EVCs (and so includes the previous two).=

In general the C-tag here too is service delimiting.<= o:p>

 

(NOTE: the arbitrary and One-to-one cases are lumped= together in MEF as

the "bundling" case.)

 

Do you agree with this analysis, and thus with the ne= ed to remove the caveat in 4448

that states that C-tags can not be service delimiting= ?

 

Y(J)S

 

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.

--_000_F9336571731ADE42A5397FC831CEAA02055AF0FRIDWPPMB001ecite_-- From tnadeau@lucidvision.com Tue May 8 04:50:09 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1B21F84F3 for ; Tue, 8 May 2012 04:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kaxFJkezrDlr for ; Tue, 8 May 2012 04:50:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3C21F84F8 for ; Tue, 8 May 2012 04:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 5709E210285D; Tue, 8 May 2012 07:50:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NibDXI5ZJTiQ; Tue, 8 May 2012 07:50:06 -0400 (EDT) Received: from [192.168.1.58] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C0CD72102850; Tue, 8 May 2012 07:50:06 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-C75CDB7E-9A92-40AB-B444-390BD15151EC Message-Id: <0B1336EA-4B70-4F0D-AAA5-5C1EC63335F3@lucidvision.com> X-Mailer: iPad Mail (9B176) From: Thomas D Nadeau Date: Tue, 8 May 2012 07:50:06 -0400 To: "Bocci, Matthew (Matthew)" Cc: "Carlos Pignataro\(cpignata\)" , "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 11:50:09 -0000 --Apple-Mail-C75CDB7E-9A92-40AB-B444-390BD15151EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed. On May 8, 2012, at 6:19 AM, "Bocci, Matthew (Matthew)" wrote: > Greg, Carlos, >=20 > I think this milestone started life as referring to any PW OAM extensions r= equired for MPLS-TP. However, it has become very ambiguous. There are really= a number of objectives that we should capture, including at least the follo= wing: >=20 > Additional VCCV Channel Type using the GAL > VCCV capability negotiation for MPLS-TP OAM tools. > Rationalisation of VCCV (RFC5085bis) >=20 > I think we could replace this milestone with milestones for the above. >=20 > Regards >=20 > Matthew >=20 > On 04/05/2012 20:53, "Gregory Mirsky" wrote:= >=20 > Dear Matthew, Carlos, et al., > I agree with Carlos that updates to VCCV Control Channels resulting from d= iscussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capabi= lity extension that, I think, referenced as "Enhanced PW OAM". > =20 > Regards, > Greg > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ca= rlos Pignataro (cpignata) > Sent: Friday, May 04, 2012 4:38 AM > To: Bocci, Matthew (Matthew) > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Updates to goals and milestones >=20 > Matthew, >=20 > In Paris there was discussion (and subsequent followup) about a VCCV-bis d= ocument. I am not sure if a formal consensus call was issued on that, but I w= onder if it needs to be captured as a milestone (or how it relates to "Enhan= ced PW OAM").=20 >=20 > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows >=20 > On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" wrote: >=20 >> All, >>=20 >> Please find below a proposed list of updates to the WG goals and mileston= es that was presented in Paris, with one modification pushing the P2MP Requi= rements LC back to Dec 2012. >>=20 >> Please post any comments to the list before Friday 11th May. >>=20 >> Matthew >>=20 >> Done - PWE3 WG started, organize editing teams. >> Done - Hold interim meeting, including discussion of priority of se= rvice-specific documents and consider pruning some deliverables >> Done - Accept drafts of service-specific documents as WG items >> Done - PW Requirements Document Last Call >> Done - TDM Circuit Documents Last Call >> Done - ATM Documents Last Call >> Done - Ethernet Documents Last Call >> Done - Fragmentation LC >> Done - TDM Requirements LC >> Done - SONET Documents Last Call >> Done - TDM Documents Last Call >> Done - Frame Relay Documents Last Call >> Done - FCS retention Last Call >> Done - Multi-Segment PW Requirements LC >> Done - VCCV LC >> Done - PWE3 Services MIBs LC >> Done - PPP/HDLC PW LC >> Done - Wildcard FEC LC >> Done - TDM Signaling LC >> Done- Multi-Segment Architecture LC >> Done - Basic Pseudowire MIBs LC >> Done - PW OAM Mapping LC >> Done - Multi-Segment PW LC >> Done - PW Protection and Restoration Requirements LC >> Done - PW Protection and Restoration Architecture >> Done - Generic Associated Channel Header LC >> Done - PW Protection and Restoration LC >> Done - Fiber Channel Encap LC >> Done- Multipath PW LC >> Done - Packet PW Requirements / solution >> Dec 2012- P2MP Requirements LC >> Done =E2=80=93 PW Status signalling in static/MPLS-TP >> July 2012 - Dynamic MS PW LC >> Sept 2012- Enhanced PW OAM >> Sept 2011 =E2=80=93 Signaling extensions for MPLS-TP OAM >> Dec 2012- Multisegment PW MIB >> Dec 2012- Security Considerations LC >> Dec 2012=E2=80=93 Congestion Considerations=20 >> Dec 2012- P2MP PW Signaling (root initiated) >> Dec 2012=E2=80=93 P2MP PW Signaling (leaf initiated) >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-C75CDB7E-9A92-40AB-B444-390BD15151EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Agreed.


<= div>
On May 8, 2012, at 6:19 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> wrote:

Dear Matthew, Carlos, et al.,
I agree with Carlos that u= pdates to VCCV Control Channels resulting from discussion of GAL as Type 4 V= CCV CC, perhaps as RFC5085bis, can be captured in Milestones. But I think that this work not necessarily tied with C= V capability extension that, I think, referenced as "Enhanced PW OAM".
 <= /div>
    Regards,
     =    Greg
From: pw= e3-bounces@ietf.org [mailto:pwe= 3-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, May 0= 4, 2012 4:38 AM
To: Bocci, Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Up= dates to goals and milestones

Matthew,

In Paris there was discussion (and subsequent follow= up) about a VCCV-bis document. I am not sure if a formal consensus call was i= ssued on that, but I wonder if it needs to be captured as a milestone (or ho= w it relates to "Enhanced PW OAM"). 

Thumb typed by Carlos Pignataro.
matthew.bocci@alcatel-lucent.com> w= rote:

All,

Please find below a proposed list of up= dates to the WG goals and milestones that was presented in Paris, with one m= odification pushing the P2MP Requirements LC back to Dec 2012.

Please post any comments to the list before Friday= 11th May.

=
Matthew

 Done   &= nbsp; - PWE3 WG started, organize editing teams.

&nbs= p; Done     - Hold interim meeting, including discussion= of priority of service-specific documents and consider pruning some deliverables

  Done     - Accept drafts of ser= vice-specific documents as WG items

  Done =     - PW Requirements Document Last Call

  Done     - ATM Documents Last C= all

  Done     - Ethernet Doc= uments Last Call

  Done     - = Fragmentation LC

  Done     - T= DM Requirements LC

  Done    = ; - SONET Documents Last Call

  Done  =    - TDM Documents Last Call

  Done&nbs= p;    - Frame Relay Documents Last Call

  Done     - Multi-Segment PW Requiremen= ts LC

  Done     - VCCV LC

  = Done     - PWE3 Services MIBs LC

=   Done     - PPP/HDLC PW LC

=   Done     - Wildcard FEC LC

  Done     - TDM Signaling LC

  Done- Multi-Se= gment Architecture LC

  Done   &nb= sp; - Basic Pseudowire MIBs LC

  Done - PW OAM M= apping LC

  Done - Multi-Segment PW LC

  Done - PW Protection and Restoration Requirements= LC

  Done - PW Protection and Restoration Archi= tecture

  Done - Generic Associated Channel Head= er LC

  D  Done -= Fiber Channel Encap LC

  Done- Multipath PW LC

  Done  - Packet PW Requirements / solution

  Dec  2012= - P2MP Requirements LC

  Done  =E2=80=93 PW Status signalling in static/MPLS-TP

  July 2012 - Dynamic MS PW LC

<= p style=3D"MARGIN-TOP: 2pt; MARGIN-BOTTOM: 0pt; VERTICAL-ALIGN: baseline; DI= RECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left">  Sept <= /span>2012- Enhanced PW OAM

  Sept 2= 011 =E2=80=93 Signaling extensions for MPLS-TP OAM

  Dec 2012- <= /span>Multisegment PW MIB

  Dec 2012- Security Considerations LC

  Dec 2012=E2=80=93 Congestion Considerat= ions 

<= span style=3D"FONT-FAMILY: Arial"> Dec  2012- P2MP PW Signaling (root initiated)

 Dec =E2=80=93 P2MP PW Sig= naling (leaf initiated)

=

_______________________________________________=
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
____________________= ___________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman= /listinfo/pwe3
= --Apple-Mail-C75CDB7E-9A92-40AB-B444-390BD15151EC-- From cpignata@cisco.com Tue May 8 06:49:36 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4279921F84F8 for ; Tue, 8 May 2012 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 6HggUpAHdpR8 for ; Tue, 8 May 2012 06:49:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EF2CB21F8499 for ; Tue, 8 May 2012 06:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=26631; q=dns/txt; s=iport; t=1336484975; x=1337694575; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=a5w1k/EZvDT9wWZFVBq69yXtgOhoR3Xpn7WGsYL3yV8=; b=KXF2cEFFgJp0mmrGmlaiPdKnudeiuYKiZ8FPLpIBSlMpeaVF3lqHScxF t16EoYHlEyc9zcWmaRZy/MG8ZT1SGheMjWg0ipyqxyHpt1cSeht6t5W0C 7WJ/aOInmvsbF5tMXTXF+8ZRsQgjbnXwO0ZGKxR7igJRIT25R5CWrYiwk M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADwkqU+tJXG8/2dsb2JhbABEgkawXoEHggwBAQEDAQEBAQ8BGkELBQsLEQEDAQEBIAcHJx8DBggGExkCB4dnBQubB6A0BIsDhSZjBI53hweOWYFpgwU X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="asc'?scan'208,217";a="81275337" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 08 May 2012 13:49:34 +0000 Received: from rtp-cpignata-8912.cisco.com (rtp-cpignata-8912.cisco.com [10.117.115.51]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q48DnXtA032718; Tue, 8 May 2012 13:49:33 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_993655CE-DEE5-40C7-BCCB-16ACEABD624B"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: Date: Tue, 8 May 2012 09:49:33 -0400 Message-Id: <89CB9267-8CBD-479C-B74D-EC201434D893@cisco.com> References: To: "Bocci, Matthew (Matthew)" X-Mailer: Apple Mail (2.1257) Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 13:49:36 -0000 --Apple-Mail=_993655CE-DEE5-40C7-BCCB-16ACEABD624B Content-Type: multipart/alternative; boundary="Apple-Mail=_56A9B66A-7921-41D8-B145-858711CBABEC" --Apple-Mail=_56A9B66A-7921-41D8-B145-858711CBABEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Matthew, I agree, sounds like a good approach. Thanks, -- Carlos. On May 8, 2012, at 6:19 AM, Bocci, Matthew (Matthew) wrote: > Greg, Carlos, >=20 > I think this milestone started life as referring to any PW OAM = extensions required for MPLS-TP. However, it has become very ambiguous. = There are really a number of objectives that we should capture, = including at least the following: >=20 > Additional VCCV Channel Type using the GAL > VCCV capability negotiation for MPLS-TP OAM tools. > Rationalisation of VCCV (RFC5085bis) >=20 > I think we could replace this milestone with milestones for the above. >=20 > Regards >=20 > Matthew >=20 > On 04/05/2012 20:53, "Gregory Mirsky" = wrote: >=20 >> Dear Matthew, Carlos, et al., >> I agree with Carlos that updates to VCCV Control Channels resulting = from discussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be = captured in Milestones. But I think that this work not necessarily tied = with CV capability extension that, I think, referenced as "Enhanced PW = OAM". >> =20 >> Regards, >> Greg >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Carlos Pignataro (cpignata) >> Sent: Friday, May 04, 2012 4:38 AM >> To: Bocci, Matthew (Matthew) >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] Updates to goals and milestones >>=20 >> Matthew, >>=20 >> In Paris there was discussion (and subsequent followup) about a = VCCV-bis document. I am not sure if a formal consensus call was issued = on that, but I wonder if it needs to be captured as a milestone (or how = it relates to "Enhanced PW OAM").=20 >>=20 >> Thumb typed by Carlos Pignataro. >> Excuze typofraphicak errows >>=20 >> On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" = wrote: >>=20 >>> All, >>>=20 >>> Please find below a proposed list of updates to the WG goals and = milestones that was presented in Paris, with one modification pushing = the P2MP Requirements LC back to Dec 2012. >>>=20 >>> Please post any comments to the list before Friday 11th May. >>>=20 >>> Matthew >>>=20 >>> Done - PWE3 WG started, organize editing teams. >>> Done - Hold interim meeting, including discussion of priority = of service-specific documents and consider pruning some deliverables >>> Done - Accept drafts of service-specific documents as WG items >>> Done - PW Requirements Document Last Call >>> Done - TDM Circuit Documents Last Call >>> Done - ATM Documents Last Call >>> Done - Ethernet Documents Last Call >>> Done - Fragmentation LC >>> Done - TDM Requirements LC >>> Done - SONET Documents Last Call >>> Done - TDM Documents Last Call >>> Done - Frame Relay Documents Last Call >>> Done - FCS retention Last Call >>> Done - Multi-Segment PW Requirements LC >>> Done - VCCV LC >>> Done - PWE3 Services MIBs LC >>> Done - PPP/HDLC PW LC >>> Done - Wildcard FEC LC >>> Done - TDM Signaling LC >>> Done- Multi-Segment Architecture LC >>> Done - Basic Pseudowire MIBs LC >>> Done - PW OAM Mapping LC >>> Done - Multi-Segment PW LC >>> Done - PW Protection and Restoration Requirements LC >>> Done - PW Protection and Restoration Architecture >>> Done - Generic Associated Channel Header LC >>> Done - PW Protection and Restoration LC >>> Done - Fiber Channel Encap LC >>> Done- Multipath PW LC >>> Done - Packet PW Requirements / solution >>> Dec 2012- P2MP Requirements LC >>> Done =96 PW Status signalling in static/MPLS-TP >>> July 2012 - Dynamic MS PW LC >>> Sept 2012- Enhanced PW OAM >>> Sept 2011 =96 Signaling extensions for MPLS-TP OAM >>> Dec 2012- Multisegment PW MIB >>> Dec 2012- Security Considerations LC >>> Dec 2012=96 Congestion Considerations=20 >>> Dec 2012- P2MP PW Signaling (root initiated) >>> Dec 2012=96 P2MP PW Signaling (leaf initiated) >>>=20 >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_56A9B66A-7921-41D8-B145-858711CBABEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On = 04/05/2012 20:53, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wrote:

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, = May 04, 2012 4:38 AM
To: Bocci, Matthew = (Matthew)
Cc: pwe3@ietf.org
Subject: Re: = [PWE3] Updates to goals and = milestones

Matthew,

In Paris there was discussion (and subsequent followup) about a = VCCV-bis document. I am not sure if a formal consensus call was issued = on that, but I wonder if it needs to be captured as a milestone (or how = it relates to "Enhanced PW OAM"). 

Thumb = typed by Carlos Pignataro.
Excuze = typofraphicak errows

On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-luc= ent.com> wrote:

All,

Please find below a proposed list of updates to the WG goals = and milestones that was presented in Paris, with one modification = pushing the P2MP Requirements LC back to Dec 2012.

Please post any comments to = the list before Friday 11th May.

Matthew

 Done     - PWE3 WG started, organize editing = teams.

  = Done     - Hold interim meeting, including = discussion of priority of service-specific documents and consider pruning = some = deliverables

  = Done     - Accept drafts of service-specific = documents as WG items

  Done     - PW Requirements Document = Last Call

  = Done     - TDM Circuit Documents Last = Call

  = Done     - ATM Documents Last Call

  = Done     - Ethernet Documents Last Call

  = Done     - Fragmentation LC

  = Done     - TDM Requirements LC

  = Done     - SONET Documents Last Call

  = Done     - TDM Documents Last Call

  = Done     - Frame Relay Documents Last = Call

  = Done     - FCS retention Last Call

  = Done     - Multi-Segment PW Requirements = LC

  = Done     - VCCV LC

  Done     - PWE3 Services MIBs = LC

  = Done     - PPP/HDLC PW LC

  = Done     - Wildcard FEC LC

  Done     - TDM Signaling LC

  Done- Multi-Segment Architecture LC

  Done     - Basic = Pseudowire MIBs LC

  Done - PW = OAM Mapping LC

  Done - = Multi-Segment PW LC

  Done - PW Protection and Restoration = Requirements LC

  Done - PW = Protection and Restoration Architecture

  Done - Generic Associated Channel Header LC

  Done - PW Protection and Restoration LC

  Done - Fiber Channel Encap LC

  Done- Multipath PW LC

  Done =  - Packet PW Requirements / = solution

  Dec  2012- = P2MP Requirements LC

  Done  =96 PW Status signalling in = static/MPLS-TP

  July 2012 - Dynamic MS PW = LC

  Sept 2012- Enhanced PW = OAM

  Sept 2011 =96 Signaling extensions for MPLS-TP OAM

  Dec 2012- Multisegment PW = MIB

  Dec 2012- = Security Considerations LC

  Dec 2012=96= Congestion Considerations 

 Dec  2012- P2MP PW Signaling (root initiated)

 Dec 2012=96 P2MP PW Signaling (leaf initiated)


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3

= --Apple-Mail=_56A9B66A-7921-41D8-B145-858711CBABEC-- --Apple-Mail=_993655CE-DEE5-40C7-BCCB-16ACEABD624B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk+pJG0ACgkQtfDPGTp3USzj1QCfSFmLW49xaywxT7hZaFbSDtq6 gAcAoIja1jT3eXJ8p97FTRzFCfE3ntiK =ZY96 -----END PGP SIGNATURE----- --Apple-Mail=_993655CE-DEE5-40C7-BCCB-16ACEABD624B-- From yaakov_s@rad.com Tue May 8 07:04:08 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974EF21F8568 for ; Tue, 8 May 2012 07:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 rlslsm4ZJSXR for ; Tue, 8 May 2012 07:04:05 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83E21F8564 for ; Tue, 8 May 2012 07:04:02 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 8 May 2012 16:47:26 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 8 May 2012 17:03:54 +0300 From: Yaakov Stein To: "Bocci, Matthew (Matthew)" Thread-Topic: [PWE3] Updates to goals and milestones Thread-Index: Ac0p4hWVTO5WPsXMRTefgV9GBEa5/f//3iaAgACKqoCABajMAP//j/tg Date: Tue, 8 May 2012 14:03:53 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C67CD@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043C67CDEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020208.4FA927CC.0048,ss=1,fgs=0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:04:08 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043C67CDEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew What if a single document (5085-bis) solves all these problems ? Would you still want 3 milestones ? Does "rationalization of VCCV" include unifying the BFD portion in RFC 5885 with the rest of the modes (thus obsoleting 5085 and 5885) ? Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Tuesday, May 08, 2012 13:19 To: Gregory Mirsky; Carlos Pignataro (cpignata) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Greg, Carlos, I think this milestone started life as referring to any PW OAM extensions r= equired for MPLS-TP. However, it has become very ambiguous. There are reall= y a number of objectives that we should capture, including at least the fol= lowing: * Additional VCCV Channel Type using the GAL * VCCV capability negotiation for MPLS-TP OAM tools. * Rationalisation of VCCV (RFC5085bis) I think we could replace this milestone with milestones for the above. Regards Matthew On 04/05/2012 20:53, "Gregory Mirsky" > wrote: Dear Matthew, Carlos, et al., I agree with Carlos that updates to VCCV Control Channels resulting from di= scussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capab= ility extension that, I think, referenced as "Enhanced PW OAM". Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Carlos Pignataro (cpignata) Sent: Friday, May 04, 2012 4:38 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, In Paris there was discussion (and subsequent followup) about a VCCV-bis do= cument. I am not sure if a formal consensus call was issued on that, but I = wonder if it needs to be captured as a milestone (or how it relates to "Enh= anced PW OAM"). Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" > wrote: All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012- P2MP Requirements LC Done - PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012- Enhanced PW OAM Sept 2011 - Signaling extensions for MPLS-TP OAM Dec 2012- Multisegment PW MIB Dec 2012- Security Considerations LC Dec 2012- Congestion Considerations Dec 2012- P2MP PW Signaling (root initiated) Dec 2012- P2MP PW Signaling (leaf initiated) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_07F7D7DED63154409F13298786A2ADC9043C67CDEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew

 

What if a single document (5085-bis) solves all these proble= ms ?

Would you still want 3 milestones ?

 

Does "rationalization of VCCV" include unifying th= e BFD portion in RFC 5885

with the rest of the modes (thus obsoleting 5085 and 5885) ?

 

Y(J)S

 

 

From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Tuesday, May 08, 2012 13:19
To: Gregory Mirsky; Carlos Pignataro (cpignata)
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Updates to goals and milestones

 

Greg, Carlos,

 

I think this milestone started life as referring to any PW OAM= extensions required for MPLS-TP. However, it has become very ambiguous. Th= ere are really a number of objectives that we should capture, including at least the following:

 

  • Additional VCCV Channel Ty= pe using the GAL
  • VCCV capability negotiatio= n for MPLS-TP OAM tools.
  • Rationalisation of VCCV (R= FC5085bis)

 

I think we could replace this milestone with milestones for th= e above.

 

Regards

 

Matthew

 

On 04/05/2012 20:53, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wr= ote:

 

Dear Matthew, Carlos, et al.,

I agree with Carlos that updates to VCCV Control Channels resul= ting from discussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can b= e captured in Milestones. But I think that this work not necessarily tied with CV capabili= ty extension that, I think, referenced as "Enhanced PW OAM".<= /p>

 

    Regards,

        Greg

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, May 04, 2012 4:38 AM
To: Bocci, Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Updates to goals and milestones

Matthew,

 

In Paris there was discussion (and subsequent followup) about = a VCCV-bis document. I am not sure if a formal consensus call was issued on= that, but I wonder if it needs to be captured as a milestone (or how it relates to "Enhanced PW OAM= "). 


Thumb typed by Carlos Pignataro.

Excuze = typofraphicak errows


On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.= com> wrote:

All,

 

Please find below a proposed list of updates to the WG goals a= nd milestones that was presented in Paris, with one modification pushing th= e P2MP Requirements LC back to Dec 2012.

 

Please post any comments to the list before Friday 11th May.

 

Matthew

 

 Done     - PWE= 3 WG started, organize editing teams.

  Done     - Hold interim meeting, in= cluding discussion of priority of service-specific documents and consider p= runing some deliverables

  Done     - Accept drafts of service= -specific documents as WG items

  Done     - PW Requirements Document= Last Call

  Done     - TDM Circuit Documents La= st Call

  Done     - ATM Documents Last Call<= /span>

  Done     - Ethernet Documents Last = Call

  Done     - Fragmentation LC<= span style=3D"font-size:8.5pt;font-family:"Calibri","sans-se= rif";color:black">

  Done     - TDM Requirements LC

  Done     - SONET Documents Last Cal= l

  Done     - TDM Documents Last Call<= /span>

  Done     - Frame Relay Documents La= st Call

  Done     - FCS retention Last Call<= /span>

  Done     - Multi-Segment PW Require= ments LC

  Done     - VCCV LC

  Done     - PWE3 Services MIBs LC

  Done     - PPP/HDLC PW LC

  Done     - Wildcard FEC LC

  Done     - TDM Signaling LC<= span style=3D"font-size:8.5pt;font-family:"Calibri","sans-se= rif";color:black">

  Done- Multi-Segment Architecture LC

  Done     - Basic Pseudowir= e MIBs LC

  Done - PW OAM Mapping LC

  Done - Multi-Segment PW LC

  Done - PW Protection and Restoration Requireme= nts LC<= o:p>

  Done - PW Protection and Restoration Architect= ure<= o:p>

  Done - Generic Associated Channel Header LC

  Done - PW Protection and Restoration LC=

  Done - Fiber Channel Encap LC<= /p>

  Done- Multipath PW LC

  Done  - Packet PW Requirements / sol= ution

  Dec  2012- P2MP Requirements LC<= /p>

  Done  – PW Status signalling in sta= tic/MPLS-TP<= o:p>

  July 2012 - Dynamic MS PW LC

  Sept 2012- Enhanced PW OAM<= /p>

  Sept 2011 – Signaling extensions for MPL= S-TP OAM

  Dec 2012- Multisegment PW MIB

  Dec 2012- Security Considerations LC

  Dec 2012– Congestion Considerations=  <= o:p>

 Dec  2012- P2MP PW Signaling (root initiat= ed)<= o:p>

 Dec 2012– P2MP PW Signaling (leaf initiat= ed)

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org= /mailman/listinfo/pwe3

--_000_07F7D7DED63154409F13298786A2ADC9043C67CDEXRAD5adradcoil_-- From matthew.bocci@alcatel-lucent.com Tue May 8 07:38:33 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA90121F8542 for ; Tue, 8 May 2012 07:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.77 X-Spam-Level: X-Spam-Status: No, score=-107.77 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 AFf+0lrlHLYt for ; Tue, 8 May 2012 07:38:32 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2A21F84B5 for ; Tue, 8 May 2012 07:38:31 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q48EcTtp032571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 May 2012 16:38:30 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 8 May 2012 16:38:29 +0200 From: "Bocci, Matthew (Matthew)" To: Yaakov Stein Date: Tue, 8 May 2012 16:38:26 +0200 Thread-Topic: [PWE3] Updates to goals and milestones Thread-Index: Ac0tKDxAySVpxwGSTb+yOW64e9OSFg== Message-ID: In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043C67CD@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBCEEDB22A764matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:38:33 -0000 --_000_CBCEEDB22A764matthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yakov, We currently have two separate drafts covering the first two bullets, but I= am not sure that the milestones should be interpreted as a mapping to sepa= rate drafts. I believe the WG has only discussed VCCV 'rationalisation' in terms of redu= cing the number of channel types. Do you think we should fold RFC5885 into = the bis? Regards Matthew On 08/05/2012 15:03, "Yaakov Stein" > wrote: Matthew What if a single document (5085-bis) solves all these problems ? Would you still want 3 milestones ? Does "rationalization of VCCV" include unifying the BFD portion in RFC 5885 with the rest of the modes (thus obsoleting 5085 and 5885) ? Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Tuesday, May 08, 2012 13:19 To: Gregory Mirsky; Carlos Pignataro (cpignata) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Greg, Carlos, I think this milestone started life as referring to any PW OAM extensions r= equired for MPLS-TP. However, it has become very ambiguous. There are reall= y a number of objectives that we should capture, including at least the fol= lowing: * Additional VCCV Channel Type using the GAL * VCCV capability negotiation for MPLS-TP OAM tools. * Rationalisation of VCCV (RFC5085bis) I think we could replace this milestone with milestones for the above. Regards Matthew On 04/05/2012 20:53, "Gregory Mirsky" > wrote: Dear Matthew, Carlos, et al., I agree with Carlos that updates to VCCV Control Channels resulting from di= scussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capab= ility extension that, I think, referenced as "Enhanced PW OAM". Regards, Greg ________________________________ From:pwe3-bounces@ietf.org [mailto:pwe3-bounc= es@ietf.org] On Behalf Of Carlos Pignataro (cpignata) Sent: Friday, May 04, 2012 4:38 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, In Paris there was discussion (and subsequent followup) about a VCCV-bis do= cument. I am not sure if a formal consensus call was issued on that, but I = wonder if it needs to be captured as a milestone (or how it relates to "Enh= anced PW OAM"). Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" > wrote: All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012- P2MP Requirements LC Done =96 PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012- Enhanced PW OAM Sept 2011 =96 Signaling extensions for MPLS-TP OAM Dec 2012- Multisegment PW MIB Dec 2012- Security Considerations LC Dec 2012=96 Congestion Considerations Dec 2012- P2MP PW Signaling (root initiated) Dec 2012=96 P2MP PW Signaling (leaf initiated) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_CBCEEDB22A764matthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yakov,

We currently have two separate drafts covering the first two bullets, but = I am not sure that the milestones should be interpreted as a mapping to sep= arate drafts. 

I believe the WG has only disc= ussed VCCV 'rationalisation' in terms of reducing the number of channel typ= es. Do you think we should fold RFC5885 into the bis?

<= div>Regards

Matthew

On 08/05/2012 15:03, "Yaakov Stein= " <yaakov_s@rad.com> wro= te:

Matthew

 <= /p>

What if a single document (5085= -bis) solves all these problems ?

Would you still want 3 milestones ?<= /p>

 

Does "rationalization of VCCV&qu= ot; include unifying the BFD portion in RFC 5885

with the rest of the modes (thus obsole= ting 5085 and 5885) ?

 

Y(J)S

=  

&= nbsp;

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Tuesday, May 0= 8, 2012 13:19
To: Gregory Mirsky; Carlos Pignataro (cpignata)
= Cc: pwe3@ietf.org
Subject= : Re: [PWE3] Updates to goals and milestones

 

Greg, Carlos,

 

I think this milestone started life as referring to any PW OAM ext= ensions required for MPLS-TP. However, it has become very ambiguous. There = are really a number of objectives that we should capture, including at least the following:

 

  • Additional VCCV Channel Type using the GAL
  • VCCV capability negotiation for MPLS-TP OAM to= ols.
  • Rationalisation of VCCV (RFC5085bis)

 

I think we could replace t= his milestone with milestones for the above.

 

Regards

 

Matthew

 

On 04/05/2012 20:53, "Gregory Mirsky" <gregory.mirsky@ericsson.com>= wrote:

Dear Matthew, Carlos, et al.,

I agree with Carl= os that updates to VCCV Control Channels resulting from discussion of GAL a= s Type 4 VCCV CC, perhaps as RFC5085bis, can be captured in Milestones. But I think that this work not necessarily tied with CV capabili= ty extension that, I think, referenced as "Enhanced PW OAM".

 <= /o:p>

    Regards,=

=         Greg

From:pwe3-bounces@ietf.org= [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, May= 04, 2012 4:38 AM
To: Bocci, Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3= ] Updates to goals and milestones

=

Matthew,

 

In Paris there was discussion (and subsequent follow= up) about a VCCV-bis document. I am not sure if a formal consensus call was= issued on that, but I wonder if it needs to be captured as a milestone (or how it relates to "Enhanced PW OAM"). 


Thumb typed by Carlos Pignataro.<= /span>

Excuze typofraphicak errows

=


On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.= com> wrote:

All= ,

 = ;

Please find bel= ow a proposed list of updates to the WG goals and milestones that was prese= nted in Paris, with one modification pushing the P2MP Requirements LC back to Dec 2012.

 

Please post any comments to the list before Friday 11th May.

 

Matthew<= /p>

 

&n= bsp;Done     - PWE3 WG started, organize e= diting teams.

  Done     - Hold interim meeting,= including discussion of priority of service-specific documents and conside= r pruning some deliverables

  Done     - Accept drafts of serv= ice-specific documents as WG items

  Done     - PW Requirements Docum= ent Last Call

  Done     - TDM Circuit Documents= Last Call

  Done     - ATM Documents Last Ca= ll

  Done     - Ethernet Documents La= st Call

  Done     - Fragmentation LC

  Done     - TDM Requirements LC

  Done     - SONET Documents Last = Call

  Done     - TDM Documents Last Ca= ll

  Done     - Frame Relay Documents= Last Call

  Done     - FCS retention Last Ca= ll

  Done     - Multi-Segment PW Requ= irements LC

  Done     - VCCV LC

  Done     - PWE3 Services MIBs LC=

  Done     - PPP/HDLC PW LC=

  Done     - Wildcard FEC LC

  Done     - TDM Signaling LC

 = ; Done- Multi-Segment Architecture LC

<= p style=3D"mso-margin-top-alt:2.0pt;margin-right:0cm;margin-bottom:0cm; margin-left:0cm;margin-bottom:.0001pt;vertical-align:baseline"> = ; Done     - Basic Pseudowire MIBs LC

 = ; Done - PW OAM Mapping LC

 = ; Done - Multi-Segment PW LC

 = ; Done - PW Protection and Restoration Requirements LC<= /o:p>

 = ; Done - PW Protection and Restoration Architecture

 = ; Done - Generic Associated Channel Header LC

 = ; Done - PW Protection and Restoration LC<= /p>

 = ; Done - Fiber Channel Encap LC

 = ; Done- Multipath PW LC

 = ; Done  - Packet PW Requirements / solution

 = ; Dec  2012- P2MP Requirements LC

=

 = ; Done  =96 PW Status signalling in static/MPLS-TP

 = ; July 2012 - Dynamic MS PW LC

 = ; Sept 2012- Enhanced PW OAM

 = ; Sept 2011 =96 Signaling extensions for MPLS-TP OAM

 = ; Dec 2012- Multisegment PW MIB

 = ; Dec 2012- Security Considerations LC

 = ; Dec 2012=96 Congestion Considerations 

 = ;Dec  2012- P2MP PW Signaling (root initiated)

 = ;Dec 2012=96 P2MP PW Signaling (leaf initiated)

_____________________= __________________________
pwe3 mailing list
pwe3@ietf.org
= https://www.ietf.org= /mailman/listinfo/pwe3

--_000_CBCEEDB22A764matthewboccialcatellucentcom_-- From gregory.mirsky@ericsson.com Tue May 8 07:45:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1021F8617 for ; Tue, 8 May 2012 07:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uqrPm3ykWy2x for ; Tue, 8 May 2012 07:45:45 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3921F8603 for ; Tue, 8 May 2012 07:45:45 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q48Ejg0F031998; Tue, 8 May 2012 09:45:44 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 8 May 2012 10:45:40 -0400 From: Gregory Mirsky To: Carlos Pignataro , "Bocci, Matthew (Matthew)" Date: Tue, 8 May 2012 10:45:39 -0400 Thread-Topic: [PWE3] Updates to goals and milestones Thread-Index: Ac0tIW9kVeMg5QsiQYaiirrWvE1QAgAB6/Uw Message-ID: References: <89CB9267-8CBD-479C-B74D-EC201434D893@cisco.com> In-Reply-To: <89CB9267-8CBD-479C-B74D-EC201434D893@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13552DBBA14EUSAACMS0715e_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:45:48 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13552DBBA14EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matthew, concur with Carlos, it's the right way. Regards, Greg ________________________________ From: Carlos Pignataro [mailto:cpignata@cisco.com] Sent: Tuesday, May 08, 2012 6:50 AM To: Bocci, Matthew (Matthew) Cc: Gregory Mirsky; pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, I agree, sounds like a good approach. Thanks, -- Carlos. On May 8, 2012, at 6:19 AM, Bocci, Matthew (Matthew) wrote: Greg, Carlos, I think this milestone started life as referring to any PW OAM extensions r= equired for MPLS-TP. However, it has become very ambiguous. There are reall= y a number of objectives that we should capture, including at least the fol= lowing: * Additional VCCV Channel Type using the GAL * VCCV capability negotiation for MPLS-TP OAM tools. * Rationalisation of VCCV (RFC5085bis) I think we could replace this milestone with milestones for the above. Regards Matthew On 04/05/2012 20:53, "Gregory Mirsky" > wrote: Dear Matthew, Carlos, et al., I agree with Carlos that updates to VCCV Control Channels resulting from di= scussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capab= ility extension that, I think, referenced as "Enhanced PW OAM". Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Carlos Pignataro (cpignata) Sent: Friday, May 04, 2012 4:38 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, In Paris there was discussion (and subsequent followup) about a VCCV-bis do= cument. I am not sure if a formal consensus call was issued on that, but I = wonder if it needs to be captured as a milestone (or how it relates to "Enh= anced PW OAM"). Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" > wrote: All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012- P2MP Requirements LC Done - PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012- Enhanced PW OAM Sept 2011 - Signaling extensions for MPLS-TP OAM Dec 2012- Multisegment PW MIB Dec 2012- Security Considerations LC Dec 2012- Congestion Considerations Dec 2012- P2MP PW Signaling (root initiated) Dec 2012- P2MP PW Signaling (leaf initiated) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF13552DBBA14EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Matthew,
concur with Carlos, it's the right way.
 
    Regards,
      &= nbsp;=20 Greg
From: Carlos Pignataro=20 [mailto:cpignata@cisco.com]
Sent: Tuesday, May 08, 2012 6:50=20 AM
To: Bocci, Matthew (Matthew)
Cc: Gregory Mirsky;=20 pwe3@ietf.org
Subject: Re: [PWE3] Updates to goals and=20 milestones

Matthew,

I agree, sounds like a good approach.

Thanks,

-- Carlos.

On May 8, 2012, at 6:19 AM, Bocci, Matthew (Matthew) wrote:
Greg, Carlos,

I think this milestone started life as referring to any PW OAM exten= sions=20 required for MPLS-TP. However, it has become very ambiguous. There are re= ally=20 a number of objectives that we should capture, including at least the=20 following:

  • Additional VCCV Channel Type using the GAL
  • VCCV capability negotiation for MPLS-TP OAM tools.
  • Rationalisation of VCCV (RFC5085bis)

I think we could replace this milestone with milestones for the=20 above.

Regards

Matthew

On 04/05/2012 20:53, "Gregory Mirsky" <gregory.mirsky@ericsson.com>=20 wrote:

Dear Matthew, Carlos, et al.,
I agree with Carlos that updates to VCCV Contr= ol=20 Channels resulting from discussion of GAL as Type 4 VCCV CC, perhaps as= =20 RFC5085bis, can be captured in Milestones. But I think that this work n= ot=20 necessarily tied with CV capability extension that, I think,= =20 referenced as "Enhanced PW OAM".
 
    Regards,
       =20 Greg
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]= On=20 Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, May 0= 4,=20 2012 4:38 AM
To: Bocci, Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: = [PWE3]=20 Updates to goals and milestones

Matthew,

In Paris there was discussion (and subsequent followup) about a=20 VCCV-bis document. I am not sure if a formal consensus call was issued = on=20 that, but I wonder if it needs to be captured as a milestone (or how it= =20 relates to "Enhanced= =20 PW OAM"). 

Thumb=20 typed by Carlos Pignataro.
Excuze=20 typofraphicak errows

On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-= lucent.com>=20 wrote:

All,

Please find below a= =20 proposed list of updates to the WG goals and milestones that was pres= ented=20 in Paris, with one modification pushing the P2MP Requirements LC back= to=20 Dec 2012.

Please post any com= ments=20 to the list before Friday 11th May.

Matthew

 Done   &nbs= p; -=20 PWE3 WG started, organize editing teams.

 =20 Done     - Hold interim meeting, including discus= sion=20 of priority of service-specific documents and consider pruning some deliverables  =20 Done     - Accept drafts of service-specific docu= ments=20 as WG items

 =20 Done     - PW Requirements Document Last=20 Call

 =20 Done     - TDM Circuit Documents Last Call=

 =20 Done     - ATM Documents Last Call

 =20 Done     - Ethernet Documents Last Call  =20 Done     - Fragmentation LC

 =20 Done     - TDM Requirements LC

 =20 Done     - SONET Documents Last Call

 =20 Done     - TDM Documents Last Call

 =20 Done     - Frame Relay Documents Last Call=

 =20 Done     - FCS retention Last Call

 =20 Done     - Multi-Segment PW Requirements LC

 =20 Done     - VCCV LC

  Done    = - PWE3=20 Services MIBs LC

 =20 Done     - PPP/HDLC PW LC

 =20 Done     - Wildcard FEC LC

  Done     - TDM Signaling LC

  Done- Multi-Segment Architecture= =20 LC

  Done     - Ba= sic=20 Pseudowire MIBs LC

  Done - PW OAM Mapping LC   Done - Multi-Segment PW LC=

 = =20 Done - PW Protection= and=20 Restoration Requirements LC

  Done - PW Protection and Restorat= ion=20 Architecture

  Done - Generic Associated Channel= Header=20 LC

  Done - PW Protection and Restoration=20 LC

  Done - Fiber=20 Channel Encap LC

  Done- Multipath PW LC

  Done  -=20 Packet PW Requirements / solution

  Dec  2012  Done  –=20 PW Status signalling in static/MPLS-TP

  July 2012=20 - Dynamic MS PW LC   Sept 2012  Sept 2011 – Signaling extensions for MPLS-TP OAM

  Dec 2012Multisegment PW MIB

  Dec 2012  Dec 2012 Dec  2012Signaling (root=20 initiated)

 Dec 2012Signaling (leaf initiated)

=
_______________________________________________
= pwe3=20 mailing list
pwe3@ietf.org
https://www.ietf.= org/mailman/listinfo/pwe3

--_000_FE60A4E52763E84B935532D7D9294FF13552DBBA14EUSAACMS0715e_-- From tnadeau@lucidvision.com Tue May 8 08:14:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC95F21F84D6 for ; Tue, 8 May 2012 08:14:24 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dqqoRnZvbO5J for ; Tue, 8 May 2012 08:14:23 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02E11E8072 for ; Tue, 8 May 2012 08:14:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id D62C22103B67; Tue, 8 May 2012 11:14:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioSPp4oceCzQ; Tue, 8 May 2012 11:14:21 -0400 (EDT) Received: from sa-nc-spg-146.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 20CE12103B5B; Tue, 8 May 2012 11:14:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_941F9338-9DBA-4C15-9FCE-17D6507CEE7F" From: Thomas Nadeau In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043C67CD@EXRAD5.ad.rad.co.il> Date: Tue, 8 May 2012 11:14:17 -0400 Message-Id: <70C55EA3-14A9-49B3-8DBF-CFA6D1FF4E12@lucidvision.com> References: <07F7D7DED63154409F13298786A2ADC9043C67CD@EXRAD5.ad.rad.co.il> To: Yaakov Stein X-Mailer: Apple Mail (2.1257) Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:14:24 -0000 --Apple-Mail=_941F9338-9DBA-4C15-9FCE-17D6507CEE7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 8, 2012:10:03 AM, at 10:03 AM, Yaakov Stein wrote: > Matthew > =20 > What if a single document (5085-bis) solves all these problems ? > Would you still want 3 milestones ? I do not see any issue with having 3 milestones that can be = possibly addressed by 1 document. There is no hard/fast rule that I am = aware of, requiring specific documents to target one and only 1 = chartered element. --Tom >=20 > Does "rationalization of VCCV" include unifying the BFD portion in RFC = 5885 > with the rest of the modes (thus obsoleting 5085 and 5885) ? > =20 > Y(J)S > =20 > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Bocci, Matthew (Matthew) > Sent: Tuesday, May 08, 2012 13:19 > To: Gregory Mirsky; Carlos Pignataro (cpignata) > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Updates to goals and milestones > =20 > Greg, Carlos, > =20 > I think this milestone started life as referring to any PW OAM = extensions required for MPLS-TP. However, it has become very ambiguous. = There are really a number of objectives that we should capture, = including at least the following: > =20 > Additional VCCV Channel Type using the GAL > VCCV capability negotiation for MPLS-TP OAM tools. > Rationalisation of VCCV (RFC5085bis) > =20 > I think we could replace this milestone with milestones for the above. > =20 > Regards > =20 > Matthew > =20 > On 04/05/2012 20:53, "Gregory Mirsky" = wrote: > =20 > Dear Matthew, Carlos, et al., > I agree with Carlos that updates to VCCV Control Channels resulting = from discussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be = captured in Milestones. But I think that this work not necessarily tied = with CV capability extension that, I think, referenced as "Enhanced PW = OAM". > =20 > Regards, > Greg > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Carlos Pignataro (cpignata) > Sent: Friday, May 04, 2012 4:38 AM > To: Bocci, Matthew (Matthew) > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Updates to goals and milestones >=20 > Matthew, > =20 > In Paris there was discussion (and subsequent followup) about a = VCCV-bis document. I am not sure if a formal consensus call was issued = on that, but I wonder if it needs to be captured as a milestone (or how = it relates to "Enhanced PW OAM").=20 >=20 > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows >=20 > On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" = wrote: >=20 > All, > =20 > Please find below a proposed list of updates to the WG goals and = milestones that was presented in Paris, with one modification pushing = the P2MP Requirements LC back to Dec 2012. > =20 > Please post any comments to the list before Friday 11th May. > =20 > Matthew > =20 > Done - PWE3 WG started, organize editing teams. > Done - Hold interim meeting, including discussion of priority of = service-specific documents and consider pruning some deliverables > Done - Accept drafts of service-specific documents as WG items > Done - PW Requirements Document Last Call > Done - TDM Circuit Documents Last Call > Done - ATM Documents Last Call > Done - Ethernet Documents Last Call > Done - Fragmentation LC > Done - TDM Requirements LC > Done - SONET Documents Last Call > Done - TDM Documents Last Call > Done - Frame Relay Documents Last Call > Done - FCS retention Last Call > Done - Multi-Segment PW Requirements LC > Done - VCCV LC > Done - PWE3 Services MIBs LC > Done - PPP/HDLC PW LC > Done - Wildcard FEC LC > Done - TDM Signaling LC > Done- Multi-Segment Architecture LC > Done - Basic Pseudowire MIBs LC > Done - PW OAM Mapping LC > Done - Multi-Segment PW LC > Done - PW Protection and Restoration Requirements LC > Done - PW Protection and Restoration Architecture > Done - Generic Associated Channel Header LC > Done - PW Protection and Restoration LC > Done - Fiber Channel Encap LC > Done- Multipath PW LC > Done - Packet PW Requirements / solution > Dec 2012- P2MP Requirements LC > Done =96 PW Status signalling in static/MPLS-TP > July 2012 - Dynamic MS PW LC > Sept 2012- Enhanced PW OAM > Sept 2011 =96 Signaling extensions for MPLS-TP OAM > Dec 2012- Multisegment PW MIB > Dec 2012- Security Considerations LC > Dec 2012=96 Congestion Considerations=20 > Dec 2012- P2MP PW Signaling (root initiated) > Dec 2012=96 P2MP PW Signaling (leaf initiated) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_941F9338-9DBA-4C15-9FCE-17D6507CEE7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 8, 2012:10:03 AM, at 10:03 AM, = Yaakov Stein wrote:

 
What if a single document = (5085-bis) solves all these problems ?
Would you still want 3 milestones = ?

I do not = see any issue with having 3 milestones that can be possibly addressed by = 1 document. There is no hard/fast rule that I am aware of, requiring = specific documents to target one and only 1 chartered = element.

--Tom


Does "rationalization of VCCV" include unifying the = BFD portion in RFC 5885
with the rest of the modes (thus obsoleting = 5085 and 5885) = ?
Y(J)S
 
 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org= ] On Behalf Of Bocci, Matthew = (Matthew)
Sent: Tuesday, May 08, 2012 = 13:19
To: Gregory Mirsky; Carlos = Pignataro (cpignata)
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Updates to goals = and milestones
 
Greg, = Carlos,
 
I think this milestone started life as referring to any PW OAM = extensions required for MPLS-TP. However, it has become very ambiguous. = There are really a number of objectives that we should capture, = including at least the following:
 
  • VCCV capability negotiation = for MPLS-TP OAM tools.
  • Rationalisation of VCCV = (RFC5085bis)
 
I think we could replace this milestone with milestones for the = above.
 
Regards
 
Matthew
 
On 04/05/2012 20:53, "Gregory Mirsky" <gregory.mirsky@ericsson.com> = wrote:
 
Dear Matthew, Carlos, et al.,

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos Pignataro = (cpignata)
Sent: Friday, May 04, 2012 4:38 = AM
To: Bocci, = Matthew (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Updates to goals = and milestones

 
In Paris there was discussion (and = subsequent followup) about a VCCV-bis document. I am not sure if a = formal consensus call was issued on that, but I wonder if it needs to be = captured as a milestone (or how it relates to "Enhanced PW OAM"). 

Thumb typed by Carlos = Pignataro.
Excuze typofraphicak = errows
On May 4, 2012, at 6:39 AM, "Bocci, = Matthew (Matthew)" <
All,
Please find below a proposed list of updates to the WG goals = and milestones that was presented in Paris, with one modification = pushing the P2MP Requirements LC back to Dec = 2012.
 
Please post any comments to the list before = Friday 11th May.
Matthew
 

Done     - PWE3 WG = started, organize editing teams.  Done     - Hold = interim meeting, including discussion of priority of service-specific = documents and consider pruning some deliverables

  Done     - Accept = drafts of service-specific documents as WG items

  Done     - PW = Requirements Document Last Call  Done     - TDM = Circuit Documents Last Call  Done     - ATM = Documents Last Call

  Done     - TDM = Requirements LC

  Done     - PWE3 = Services MIBs LC

  Done     - = Wildcard FEC LC

  Done - PW OAM = Mapping LC

  Done - = Multi-Segment PW LC

  Done - PW = Protection and Restoration Requirements LC  Done - PW = Protection and Restoration Architecture  Done - Generic = Associated Channel Header LC  Done - PW = Protection and Restoration LC  Done - Fiber = Channel Encap LC

  Done- Multipath = PW LC

  Done  - = Packet PW Requirements / solution  Dec  2012- = P2MP Requirements LC

  Done  =96 PW = Status signalling in static/MPLS-TP  July 2012 - = Dynamic MS PW LC

  Sept 2012- = Enhanced PW OAM

  Sept 2011 =96 = Signaling extensions for MPLS-TP OAM  Dec 2012- = Multisegment PW MIB

  Dec 2012- = Security Considerations LC  Dec 2012=96 = Congestion Considerations  Dec  2012- = P2MP PW Signaling (root initiated) Dec 2012=96 P2MP = PW Signaling (leaf initiated)

pwe3@ietf.org
Date: Tue, 8 May 2012 12:56:51 -0400 Thread-Topic: [PWE3] Updates to goals and milestones Thread-Index: Ac0p4hWVTO5WPsXMRTefgV9GBEa5/f//3iaAgACKqoCABajMAP//j/tg//7vTyA= Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043C67CD@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043C67CD@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13552DBBB25EUSAACMS0715e_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Updates to goals and milestones X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:57:08 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13552DBBB25EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Yaakov, at fix terminology along the way - from Connectivity Verification to Contin= uity Check. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Tuesday, May 08, 2012 7:04 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew What if a single document (5085-bis) solves all these problems ? Would you still want 3 milestones ? Does "rationalization of VCCV" include unifying the BFD portion in RFC 5885 with the rest of the modes (thus obsoleting 5085 and 5885) ? Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Tuesday, May 08, 2012 13:19 To: Gregory Mirsky; Carlos Pignataro (cpignata) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Greg, Carlos, I think this milestone started life as referring to any PW OAM extensions r= equired for MPLS-TP. However, it has become very ambiguous. There are reall= y a number of objectives that we should capture, including at least the fol= lowing: * Additional VCCV Channel Type using the GAL * VCCV capability negotiation for MPLS-TP OAM tools. * Rationalisation of VCCV (RFC5085bis) I think we could replace this milestone with milestones for the above. Regards Matthew On 04/05/2012 20:53, "Gregory Mirsky" > wrote: Dear Matthew, Carlos, et al., I agree with Carlos that updates to VCCV Control Channels resulting from di= scussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captured i= n Milestones. But I think that this work not necessarily tied with CV capab= ility extension that, I think, referenced as "Enhanced PW OAM". Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Carlos Pignataro (cpignata) Sent: Friday, May 04, 2012 4:38 AM To: Bocci, Matthew (Matthew) Cc: pwe3@ietf.org Subject: Re: [PWE3] Updates to goals and milestones Matthew, In Paris there was discussion (and subsequent followup) about a VCCV-bis do= cument. I am not sure if a formal consensus call was issued on that, but I = wonder if it needs to be captured as a milestone (or how it relates to "Enh= anced PW OAM"). Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 4, 2012, at 6:39 AM, "Bocci, Matthew (Matthew)" > wrote: All, Please find below a proposed list of updates to the WG goals and milestones= that was presented in Paris, with one modification pushing the P2MP Requir= ements LC back to Dec 2012. Please post any comments to the list before Friday 11th May. Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done- Multipath PW LC Done - Packet PW Requirements / solution Dec 2012- P2MP Requirements LC Done - PW Status signalling in static/MPLS-TP July 2012 - Dynamic MS PW LC Sept 2012- Enhanced PW OAM Sept 2011 - Signaling extensions for MPLS-TP OAM Dec 2012- Multisegment PW MIB Dec 2012- Security Considerations LC Dec 2012- Congestion Considerations Dec 2012- P2MP PW Signaling (root initiated) Dec 2012- P2MP PW Signaling (leaf initiated) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF13552DBBB25EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Yaakov,
at fix terminology along the way - from Connecti= vity=20 Verification to Continuity Check.
 
    Regards,
       =20 Greg

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent:= =20 Tuesday, May 08, 2012 7:04 AM
To: Bocci, Matthew=20 (Matthew)
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Updates= to=20 goals and milestones

Matthew

 

What=20 if a single document (5085-bis) solves all these problems=20 ?

Would=20 you still want 3 milestones ?

 

Does=20 "rationalization of VCCV" include unifying the BFD portion in RFC=20 5885

with=20 the rest of the modes (thus obsoleting 5085 and 5885)=20 ?

 

Y(J)S

 

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bo= cci,=20 Matthew (Matthew)
Sent: Tuesday, May 08, 2012 13:19
To:= =20 Gregory Mirsky; Carlos Pignataro (cpignata)
Cc:=20 pwe3@ietf.org
Subject: Re: [PWE3] Updates to goals and=20 milestones

 

Additiona= l VCCV=20 Channel Type using the GAL=20

  • VCCV capa= bility=20 negotiation for MPLS-TP OAM tools.=20
  • Rationali= sation=20 of VCCV (RFC5085bis)

    • Dear=20 Matthew, Carlos, et al.,

    I=20 agree with Carlos that updates to VCCV Control Channels resulting from=20 discussion of GAL as Type 4 VCCV CC, perhaps as RFC5085bis, can be captur= ed in=20 Milestones. But I think that this work not necessarily tied wit= h CV=20 capability extension that, I think, referenced as "Enhanced PW=20 OAM".

     

       =20 Regards,

           =20 Greg

    Matthew,

     

    In=20 Paris there was discussion (and subsequent followup) about a VCCV-bis=20 document. I am not sure if a formal consensus call was issued on that, bu= t I=20 wonder if it needs to be captured as a milestone (or how it relates to=20 ""). 


    Thumb typed by Carlos=20 Pignataro.

    Excuze=20 typofraphicak errows

    All,

     

    Please=20 find below a proposed list of updates to the WG goals and milestones th= at=20 was presented in Paris, with one modification pushing the P2MP Requirem= ents=20 LC back to Dec 2012.

     

    Please=20 post any comments to the list before Friday 11th=20 May.

     

    Matthew

     

    =  = Done    =20 - PWE3 WG started, organize editing teams.

    =  =20 Done     - Hold interim meeting, including discussi= on of=20 priority of service-specific documents and consider pruning some=20 deliverables

    =  =20 Done     - Accept drafts of service-specific docume= nts=20 as WG items

    =  =20 Done     - PW Requirements Document Last=20 Call

    =  =20 Done     - TDM Circuit Documents Last Call

    =  =20 Done     - ATM Documents Last Call

    =  =20 Done     - Ethernet Documents Last Call

    =  =20 Done     - Fragmentation LC

    =  =20 Done     - TDM Requirements LC

    =  =20 Done     - SONET Documents Last Call

    =  =20 Done     - TDM Documents Last Call

    =  =20 Done     - Frame Relay Documents Last Call

    =  =20 Done     - FCS retention Last Call

    =  =20 Done     - Multi-Segment PW Requirements LC<= SPAN=20 style=3D"FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: 'Calibri','sans-s= erif'">

    =  =20 Done     - VCCV LC

    =  =20 Done     - PWE3 Services MIBs LC

    =  =20 Done     - PPP/HDLC PW LC

    =  =20 Done     - Wildcard FEC LC

    =  =20 Done     - TDM Signaling LC

     =20 Done- Multi-Segment Architecture LC

     =20 Done     - Basic Pseudowire MIBs LC

     =20 Done - PW OAM Mapping LC

     =20 Done - Multi-Segment PW LC

     =20 Done - PW Protection and Restoration Requirements LC

     =20 Done - PW Protection and Restoration Architecture

     =20 Done - Generic Associated Channel Header LC

     =20 Done - PW Protection and Restoration LC

     =20 Done - Fiber Channel Encap LC

     =20 Done- Multipath PW LC

      Done=20  - Packet PW Requirements / solution

     =20 Dec  2012- P2MP Requirements LC

     =20 Done  – PW Status signalling in static/MPLS-TP

     =20 July 2012 - Dynamic MS PW LC

     =20 Sept 2012- Enhanced PW OAM

     =20 Sept 2011 – Signaling extensions for MPLS-TP OAM

     =20 Dec 2012- Multisegment PW MIB

     =20 Dec 2012- Security Considerations LC

     =20 Dec 2012– Congestion Considerations 

     Dec=20  2012- P2MP PW Signaling (root initiated)

     Dec=20 2012– P2MP PW Signaling (leaf initiated)

    _______________________________________________
    pwe3=20 mailing list
    pwe3@ietf.org
    <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/pwe3">https://www.ietf.or= g/mailman/listinfo/pwe3

    <= /DIV>
    --_000_FE60A4E52763E84B935532D7D9294FF13552DBBB25EUSAACMS0715e_-- From internet-drafts@ietf.org Tue May 8 14:37:28 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F979E8006; Tue, 8 May 2012 14:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 c3p46GRJdBj4; Tue, 8 May 2012 14:37:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059ED21F84B5; Tue, 8 May 2012 14:37:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120508213728.27966.83898.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2012 14:37:28 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:37:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : A Unified Control Channel for Pseudowires Author(s) : Thomas D. Nadeau Luca Martini Filename : draft-ietf-pwe3-vccv-for-gal-01.txt Pages : 9 Date : 2012-05-08 This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW). VCCV applies to all supported access circuit and transport types currently defined for PWs, as well as those being transported by The MPLS Transport Profile. This new mode is intended to augment those described in RFC5085, but this document describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV. The older types will remain optional. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-for-gal-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-for-gal-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-for-gal/ From tnadeau@lucidvision.com Tue May 8 14:38:14 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1E11E8089 for ; Tue, 8 May 2012 14:38:14 -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 Txe7blzwguBV for ; Tue, 8 May 2012 14:38:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAA211E8074 for ; Tue, 8 May 2012 14:38:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 350D62105267; Tue, 8 May 2012 17:38:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmfAq9G1j9qs; Tue, 8 May 2012 17:38:11 -0400 (EDT) Received: from sa-nc-apg-237.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 790F22105263; Tue, 8 May 2012 17:38:10 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 May 2012 17:38:07 -0400 Message-Id: To: "pwe3 WG ((((((((((((((((E-mail))))))))))))))))" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Martini Luca Subject: [PWE3] Soliciting comments on draft-ietf-pwe3-vccv-for-gal-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:38:14 -0000 PWE3 WG, Luca and I would like to solicit comments on the draft in = anticipation of a WG LC. WG Chairs, the co-authors would like to request that you issue a = WG last call on the draft as we believe it is ready to go. --Tom From stbryant@cisco.com Wed May 9 03:17:41 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67F721F84D9 for ; Wed, 9 May 2012 03:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ZwdK-oa0BgHs for ; Wed, 9 May 2012 03:17:41 -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 A25C921F84D8 for ; Wed, 9 May 2012 03:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4069; q=dns/txt; s=iport; t=1336558660; x=1337768260; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=67wQ7CVu4YjqNmiReW2lomIbqPTAx8ffkNtS9ci9TFg=; b=K+FxOR+kBidJ/5zAuENriUTRmtzMbM4LoywIsiVUymix62wwzSXhL1Nw m0o/WAbfenBPAsAweCX+oFoQA24cQAFjkn1opKVKjhxnHixyTIv6Xo53Y 2cssSYHeOJCzDePUpQxxhR0jojU09lOdkT3rtUCynCRgDucoaKqYigUwf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALhDqk+Q/khL/2dsb2JhbABEs06BB4IMAQEBBAEBAQ8BAh0BBTYKEQsRBAEBAQkWCAcJAwIBAgEVHxETBgIBAR6HbAubGoNFEJxWiwwZhXkElX2OWIECZ4JqgV0 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="72771513" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 May 2012 10:17:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q49AHd5N012151 for ; Wed, 9 May 2012 10:17:39 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q49AHcoj004540; Wed, 9 May 2012 11:17:39 +0100 (BST) Message-ID: <4FAA4442.1050702@cisco.com> Date: Wed, 09 May 2012 11:17:38 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pwe3@ietf.org References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 10:17:41 -0000 Sasha Do you have the correct reference? If so perhaps you could point to the right section. Stewart Yaakov I think that the purpose of the text as to say that the tag may or may not be service delimiting, which I think is demonstrably true. Stewart On 08/05/2012 12:20, Alexander Vainshtein wrote: > > Yaakov, Stewart and all, > > I believe that 5061 effectively supports Yaakov’s point of view. > > My 2c, > > Sasha > > *From:*pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf > Of *Yaakov Stein > *Sent:* Tuesday, May 08, 2012 1:59 PM > *To:* Stewart Bryant; pwe3@ietf.org > *Subject:* [PWE3] once upon an erratum > > Stewart and all, > > RFC 4448 has an erratum marked "Held for Document Update by Stewart > Bryant". > > This erratum (penned by Alfred Hoenes) deals with several issues, > > from a "subtle typo" to the misleading figure label. > > However, there is one issue with which I agree and which I think is > important; > > but regarding which I don't recall discussion on the list. > > With the entire group of comments marked as "held for document update" > rather than as "approved", > > I am not sure whether this issue has been agreed upon. > > The text in question is this : > > When the PE receives an Ethernet frame, and the frame has a VLAN tag, > > we can distinguish two cases: > > 1. The tag is service-delimiting. This means that the tag was > > placed on the frame by some piece of service provider-operated > > equipment, and the tag is used by the service provider to > > distinguish the traffic. For example, LANs from different > > customers might be attached to the same service provider > > switch, which applies VLAN tags to distinguish one customer's > > traffic from another's, and then forwards the frames to the PE. > > 2. The tag is not service-delimiting. This means that the tag was > > placed in the frame by a piece of customer equipment, and is > > not meaningful to the PE. > > Alfred states that > > The term, "service delimiting", apparently here is defined > by the origin of the tag, not by its function. > > I understand where the original text comes from. > > In the provider provisioned model the SP doesn't trust the customer to > properly tag the frames, > > and so doesn't look at tags inserted by CE devices. > > However, other groups (e.g., MEF) assume careful prior negotiation > > (of the legal kind, not the protocol kind) between customer and SP, > > and so the C-tag may indeed be service delimiting. > > More specifically, one can make the distinction between three > "bundling" types > > based on the C-tag. > > *All-to-one means that all C-tags are taken as one "flow" or "EVC" or > whatever, > > and thus the mapping to PW is independent of this tag. > > So here the C-tag is NOT service delimiting. > > *One-to-one means that each C-tag is mapped to a single EVC. > > So the C-tag determines the PW, and is thus service delimiting. > > *Arbitrary bundling means we have a general mapping > > of C-tags to EVCs (and so includes the previous two). > > In general the C-tag here too is service delimiting. > > (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as > > the "bundling" case.) > > Do you agree with this analysis, and thus with the need to remove the > caveat in 4448 > > that states that C-tags can not be service delimiting ? > > Y(J)S > > 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. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Alexander.Vainshtein@ecitele.com Wed May 9 04:59:38 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ACC21F84BF for ; Wed, 9 May 2012 04:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.285 X-Spam-Level: X-Spam-Status: No, score=-4.285 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 fJY2ZQIYUXyu for ; Wed, 9 May 2012 04:59:37 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6887C21F8493 for ; Wed, 9 May 2012 04:59:37 -0700 (PDT) Received: from [85.158.138.51:40894] by server-9.bemta-3.messagelabs.com id D3/56-26691-82C5AAF4; Wed, 09 May 2012 11:59:36 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1336564776!26081453!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 23698 invoked from network); 9 May 2012 11:59:36 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-11.tower-174.messagelabs.com with SMTP; 9 May 2012 11:59:36 -0000 X-AuditID: a8571401-b7f8d6d0000035b0-e9-4faa5cad236e Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 48.E2.13744.DAC5AAF4; Wed, 9 May 2012 14:01:49 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Wed, 9 May 2012 13:59:35 +0200 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [PWE3] once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQACv45wAAB60hnQ== Date: Wed, 9 May 2012 11:59:35 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> , <4FAA4442.1050702@cisco.com> In-Reply-To: <4FAA4442.1050702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTaUwTQRTHne5SF2R1LWiHxmhdiRcpKRG0JBSPL8IHrQdGxXNpx3a13a67 1YAfFKKAmngGSSwIHo1gPRC8iKJRjMYjKXiQqAgqYqJootF4koizXUCM8+k/837v/d/svqEI XafWQPGCD0kC52a1UWQUGGQwnV4etJnvBCZYdn8+T1pCb8rBDE1GSXdtREYg8FMzT5OdD9I4 QfD6OB8yOpBst7LzJH4jZ89jjbzDyiaxRtHN2ZEHCT4ry4kiEhxsepTxv5WGMV4wIsHudfCC 08pmLrSZLJaUVFMSm57l4mUjMnk43m30IFnmnMiIT5RuBcfqM4Tr9o6thBiMz325/T7IB22j doJICjLJsOhWnUbVI2Fze412J4iidMxjAO+Wl5HqJgDg77fvCIXSMlZYd7JNq+hYxgTLzj4B iiaYcfBS2dbweQwzEV4s7sE8hZlJsLSKUvFZsL7gehgnmXj4sOB9uCTNzIHP2g+Fm9AxJwHs eDVb0ZE49dq3K+GSADf3/d4pjWqlh886K3ubZmCgoYlQ9Qj47vXvCFWPgQ8+vezlzfBjqJJQ dQI8fqTPdzi8e7CTVPk4eKP6CbkX6P0DLPwD0v0D0v0D0g8DMgj0ayTeIYpyjtmclIjsvA+5 UaLd66kDeEqqF8eCetCxK7ERMBRgo+mJtSdsughuo5znaQRxlIYdQXcsCdp0Q3O8jjwXJ7tW SRvcSG4EkCLYWNo/AeO0g8vbhCRvX8iCv+E+wjDE7lX+sG/VFLP5nw2rp2sWpNt0jBOP3TqE RCT1pY6iKBbSmcuw43AJOVHuGt7t+xvWUJGKczR2jlUYWhY5j8w71fg9kEBVlFxoAVRRa30L 0JGCV0AGPT1VQRkFdW0Q+qt1AT2+cQw9WolG42Hsr9OFLTTYovSmcjkZP47+kCEfrI8IZS2I z75KnW87XnrucvDr/tYVj1pOOEOVUuqF5A8N0xqKVz5tP/JTaoBLB7sXHajpHlt4rMQ6/1Nd fsXM7p6E1vtzj4V0VJPVsHl08vjm4h+/rtBZlm2WwvSmmD3DPCUph6teXDx1NOV25HO0Jad9 bXzRh1xyRdf0+ubCii83voosKbu4pMmEJHN/AKSkVSn3AwAA Cc: "pwe3@ietf.org" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:59:38 -0000 Stewart, It is Section 9 of RFC 5063 (not 5061!) that discusses service-delimiting m= odes and their mapping to the appropriate set of the PW attributes. I apologize for the typo. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Stewart Bry= ant [stbryant@cisco.com] Sent: Wednesday, May 09, 2012 12:17 PM To: pwe3@ietf.org Subject: Re: [PWE3] once upon an erratum Sasha Do you have the correct reference? If so perhaps you could point to the right section. Stewart Yaakov I think that the purpose of the text as to say that the tag may or may not be service delimiting, which I think is demonstrably true. Stewart On 08/05/2012 12:20, Alexander Vainshtein wrote: > > Yaakov, Stewart and all, > > I believe that 5061 effectively supports Yaakov=92s point of view. > > My 2c, > > Sasha > > *From:*pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf > Of *Yaakov Stein > *Sent:* Tuesday, May 08, 2012 1:59 PM > *To:* Stewart Bryant; pwe3@ietf.org > *Subject:* [PWE3] once upon an erratum > > Stewart and all, > > RFC 4448 has an erratum marked "Held for Document Update by Stewart > Bryant". > > This erratum (penned by Alfred Hoenes) deals with several issues, > > from a "subtle typo" to the misleading figure label. > > However, there is one issue with which I agree and which I think is > important; > > but regarding which I don't recall discussion on the list. > > With the entire group of comments marked as "held for document update" > rather than as "approved", > > I am not sure whether this issue has been agreed upon. > > The text in question is this : > > When the PE receives an Ethernet frame, and the frame has a VLAN tag, > > we can distinguish two cases: > > 1. The tag is service-delimiting. This means that the tag was > > placed on the frame by some piece of service provider-operated > > equipment, and the tag is used by the service provider to > > distinguish the traffic. For example, LANs from different > > customers might be attached to the same service provider > > switch, which applies VLAN tags to distinguish one customer's > > traffic from another's, and then forwards the frames to the PE. > > 2. The tag is not service-delimiting. This means that the tag was > > placed in the frame by a piece of customer equipment, and is > > not meaningful to the PE. > > Alfred states that > > The term, "service delimiting", apparently here is defined > by the origin of the tag, not by its function. > > I understand where the original text comes from. > > In the provider provisioned model the SP doesn't trust the customer to > properly tag the frames, > > and so doesn't look at tags inserted by CE devices. > > However, other groups (e.g., MEF) assume careful prior negotiation > > (of the legal kind, not the protocol kind) between customer and SP, > > and so the C-tag may indeed be service delimiting. > > More specifically, one can make the distinction between three > "bundling" types > > based on the C-tag. > > *All-to-one means that all C-tags are taken as one "flow" or "EVC" or > whatever, > > and thus the mapping to PW is independent of this tag. > > So here the C-tag is NOT service delimiting. > > *One-to-one means that each C-tag is mapped to a single EVC. > > So the C-tag determines the PW, and is thus service delimiting. > > *Arbitrary bundling means we have a general mapping > > of C-tags to EVCs (and so includes the previous two). > > In general the C-tag here too is service delimiting. > > (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as > > the "bundling" case.) > > Do you agree with this analysis, and thus with the need to remove the > caveat in 4448 > > that states that C-tags can not be service delimiting ? > > Y(J)S > > 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. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 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 yaakov_s@rad.com Wed May 9 06:11:38 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF2C21F85EE for ; Wed, 9 May 2012 06:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 n0ARM1dSwC64 for ; Wed, 9 May 2012 06:11:38 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 474DF21F85D2 for ; Wed, 9 May 2012 06:11:34 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 9 May 2012 15:54:58 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Wed, 9 May 2012 16:11:30 +0300 From: Yaakov Stein To: Alexander Vainshtein , "stbryant@cisco.com" Thread-Topic: [PWE3] once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQACngdgAAA4+BgAAIyKpg Date: Wed, 9 May 2012 13:11:29 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> , <4FAA4442.1050702@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090202.4FAA6D03.00B8,ss=1,fgs=0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:11:38 -0000 Well, actually it is 5603 ... Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, May 09, 2012 15:00 To: stbryant@cisco.com Cc: pwe3@ietf.org Subject: Re: [PWE3] once upon an erratum Stewart, It is Section 9 of RFC 5063 (not 5061!) that discusses service-delimiting = modes and their mapping to the appropriate set of the PW attributes. I apologize for the typo. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Stewart Br= yant [stbryant@cisco.com] Sent: Wednesday, May 09, 2012 12:17 PM To: pwe3@ietf.org Subject: Re: [PWE3] once upon an erratum Sasha Do you have the correct reference? If so perhaps you could point to the right section. Stewart Yaakov I think that the purpose of the text as to say that the tag may or may not be service delimiting, which I think is demonstrably true. Stewart On 08/05/2012 12:20, Alexander Vainshtein wrote: > > Yaakov, Stewart and all, > > I believe that 5061 effectively supports Yaakov's point of view. > > My 2c, > > Sasha > > *From:*pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf > Of *Yaakov Stein > *Sent:* Tuesday, May 08, 2012 1:59 PM > *To:* Stewart Bryant; pwe3@ietf.org > *Subject:* [PWE3] once upon an erratum > > Stewart and all, > > RFC 4448 has an erratum marked "Held for Document Update by Stewart > Bryant". > > This erratum (penned by Alfred Hoenes) deals with several issues, > > from a "subtle typo" to the misleading figure label. > > However, there is one issue with which I agree and which I think is > important; > > but regarding which I don't recall discussion on the list. > > With the entire group of comments marked as "held for document update" > rather than as "approved", > > I am not sure whether this issue has been agreed upon. > > The text in question is this : > > When the PE receives an Ethernet frame, and the frame has a VLAN tag, > > we can distinguish two cases: > > 1. The tag is service-delimiting. This means that the tag was > > placed on the frame by some piece of service provider-operated > > equipment, and the tag is used by the service provider to > > distinguish the traffic. For example, LANs from different > > customers might be attached to the same service provider > > switch, which applies VLAN tags to distinguish one customer's > > traffic from another's, and then forwards the frames to the PE. > > 2. The tag is not service-delimiting. This means that the tag was > > placed in the frame by a piece of customer equipment, and is > > not meaningful to the PE. > > Alfred states that > > The term, "service delimiting", apparently here is defined > by the origin of the tag, not by its function. > > I understand where the original text comes from. > > In the provider provisioned model the SP doesn't trust the customer to > properly tag the frames, > > and so doesn't look at tags inserted by CE devices. > > However, other groups (e.g., MEF) assume careful prior negotiation > > (of the legal kind, not the protocol kind) between customer and SP, > > and so the C-tag may indeed be service delimiting. > > More specifically, one can make the distinction between three > "bundling" types > > based on the C-tag. > > *All-to-one means that all C-tags are taken as one "flow" or "EVC" or > whatever, > > and thus the mapping to PW is independent of this tag. > > So here the C-tag is NOT service delimiting. > > *One-to-one means that each C-tag is mapped to a single EVC. > > So the C-tag determines the PW, and is thus service delimiting. > > *Arbitrary bundling means we have a general mapping > > of C-tags to EVCs (and so includes the previous two). > > In general the C-tag here too is service delimiting. > > (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as > > the "bundling" case.) > > Do you agree with this analysis, and thus with the need to remove the > caveat in 4448 > > that states that C-tags can not be service delimiting ? > > Y(J)S > > 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. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 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 Alexander.Vainshtein@ecitele.com Wed May 9 06:14:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32FC21F85F9 for ; Wed, 9 May 2012 06:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 Cpvo1Eq0T0OQ for ; Wed, 9 May 2012 06:14:21 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 45CBC21F85F2 for ; Wed, 9 May 2012 06:14:21 -0700 (PDT) Received: from [85.158.138.51:60205] by server-1.bemta-3.messagelabs.com id 43/43-11491-CAD6AAF4; Wed, 09 May 2012 13:14:20 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1336569260!18430423!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 25228 invoked from network); 9 May 2012 13:14:20 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-6.tower-174.messagelabs.com with SMTP; 9 May 2012 13:14:20 -0000 X-AuditID: a8571401-b7f8d6d0000035b0-1b-4faa6e31c154 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id E7.F2.13744.13E6AAF4; Wed, 9 May 2012 15:16:33 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Wed, 9 May 2012 15:14:19 +0200 From: Alexander Vainshtein To: Yaakov Stein , "stbryant@cisco.com" Thread-Topic: [PWE3] once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQACv45wAAB60hnf//8ymA///d0zA= Date: Wed, 9 May 2012 13:14:18 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> , <4FAA4442.1050702@cisco.com> <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0zTUBTHvWuZBSmp47HrFNNUDeDc3CLGmTjUD0aM0RHRmOgHLOtlK2zt XKcyExN8xMd8BA0hcRrEhMhT8YGowcQ4DQkSXwgRJRoUfABqFDVKjGBLFTH207nn/zv3f057 SmC691oDwQsB5BdYD6ONwWPABIPJKtQ4LOcjRtuRwQbcdu/VSWD7GPoetQTLLPlxISqzomJI k3nsbF4WtqEILGIFQQywAURzSHLamSw/v5V1Bhma5+yMlaF9HtaJvEgI2BnW50MCx2TE0P89 i2SMF2gkOEWOF1x2ZkW2w2SzzV9osjIZa928RCOTl+U9tBdJEutCtJxR2ha4Tecwd19Lm9Y3 NLewq3UnVgSaZ4VANAGpdNhZVo2pcRJ88LxeGwIxhI5qBzDUfPT3oQLAoo+PRiktZYcXa5/J AkEkUKvhybbtShqjZsArJ3ZrlTieSoWN+0YwFUmDpZWEklboms89owhOzYSV177hSkxSq2B3 X2iianVJA+++eTxqFU2thD93HhiFgNzctzt1GtVLD5/2ntKoTVOw4vr93wMkwr6e4Sg1ng53 VbdPVPk5sLxpUKvGRnjm9ACmGk+GLcd7cZWfAm9WdeLFQB8eZxEeVx4eVx4eV14O8Bqgz/Pz nM8n5VosVjNy8gHkQWan6L0I5HWpWp8AroKXh80RQBGAiSVTL1Q7dFHsVinojYAphIZJJJvy axy6uFyRC7pZyZ3j3+JBUgRAAmMSyHCKjJMcG9yO/OIfySa/xKOYYZJTVL5wIGeexfLPgdGT 9WsyHDrKJa9dAUI+5P9TOo0gGEi+8siOk/3IhQrzeE/gr6whohXnWNn5ncKQko/1SrxL1e8A I1FWcrkDEHu7rnYAHS6IAjLoyQ4FpRTUvUUYu60f6OWJ48kvihorL+PYPf2yhUa2KL2lDCfJ P8eYZCgC6xojQ3MqH3no6UnDI8ta3va+zd7ziexP7nniTArx3KFpX7gbwz/yj3XGdXu3bTSl 0cWpdfOSRkrTg/XGuNol8YnpyQMNg/cLCqvbljZ+NddFln7mD240H29FU1/Utq4+H/26XNzR biy0PhxIXn+6ZH/2y7KUxWJTZULxh7gFtzcvZ3DJzVpnY36J/QWR8kExAAQAAA== Cc: "pwe3@ietf.org" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:14:22 -0000 Yaakov, Stewart, Apologies again. But I hope the intention is clear... Regards, Sasha > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, May 09, 2012 4:11 PM > To: Alexander Vainshtein; stbryant@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] once upon an erratum > > Well, actually it is 5603 ... > > Y(J)S > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 15:00 > To: stbryant@cisco.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] once upon an erratum > > Stewart, > It is Section 9 of RFC 5063 (not 5061!) that discusses service-delimiting > modes and their mapping to the appropriate set of the PW attributes. > > I apologize for the typo. > > Regards, > Sasha > ________________________________________ > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of > Stewart Bryant [stbryant@cisco.com] > Sent: Wednesday, May 09, 2012 12:17 PM > To: pwe3@ietf.org > Subject: Re: [PWE3] once upon an erratum > > Sasha > > Do you have the correct reference? If so perhaps you could > point to the right section. > > Stewart > > > Yaakov > > I think that the purpose of the text as to say that the tag > may or may not be service delimiting, which I think is > demonstrably true. > > Stewart > > > > On 08/05/2012 12:20, Alexander Vainshtein wrote: > > > > Yaakov, Stewart and all, > > > > I believe that 5061 effectively supports Yaakov's point of view. > > > > My 2c, > > > > Sasha > > > > *From:*pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > Behalf > > Of *Yaakov Stein > > *Sent:* Tuesday, May 08, 2012 1:59 PM > > *To:* Stewart Bryant; pwe3@ietf.org > > *Subject:* [PWE3] once upon an erratum > > > > Stewart and all, > > > > RFC 4448 has an erratum marked "Held for Document Update by Stewart > > Bryant". > > > > This erratum (penned by Alfred Hoenes) deals with several issues, > > > > from a "subtle typo" to the misleading figure label. > > > > However, there is one issue with which I agree and which I think is > > important; > > > > but regarding which I don't recall discussion on the list. > > > > With the entire group of comments marked as "held for document > update" > > rather than as "approved", > > > > I am not sure whether this issue has been agreed upon. > > > > The text in question is this : > > > > When the PE receives an Ethernet frame, and the frame has a VLAN tag, > > > > we can distinguish two cases: > > > > 1. The tag is service-delimiting. This means that the tag was > > > > placed on the frame by some piece of service provider-operated > > > > equipment, and the tag is used by the service provider to > > > > distinguish the traffic. For example, LANs from different > > > > customers might be attached to the same service provider > > > > switch, which applies VLAN tags to distinguish one customer's > > > > traffic from another's, and then forwards the frames to the PE. > > > > 2. The tag is not service-delimiting. This means that the tag was > > > > placed in the frame by a piece of customer equipment, and is > > > > not meaningful to the PE. > > > > Alfred states that > > > > The term, "service delimiting", apparently here is defined > > by the origin of the tag, not by its function. > > > > I understand where the original text comes from. > > > > In the provider provisioned model the SP doesn't trust the customer to > > properly tag the frames, > > > > and so doesn't look at tags inserted by CE devices. > > > > However, other groups (e.g., MEF) assume careful prior negotiation > > > > (of the legal kind, not the protocol kind) between customer and SP, > > > > and so the C-tag may indeed be service delimiting. > > > > More specifically, one can make the distinction between three > > "bundling" types > > > > based on the C-tag. > > > > *All-to-one means that all C-tags are taken as one "flow" or "EVC" or > > whatever, > > > > and thus the mapping to PW is independent of this tag. > > > > So here the C-tag is NOT service delimiting. > > > > *One-to-one means that each C-tag is mapped to a single EVC. > > > > So the C-tag determines the PW, and is thus service delimiting. > > > > *Arbitrary bundling means we have a general mapping > > > > of C-tags to EVCs (and so includes the previous two). > > > > In general the C-tag here too is service delimiting. > > > > (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as > > > > the "bundling" case.) > > > > Do you agree with this analysis, and thus with the need to remove the > > caveat in 4448 > > > > that states that C-tags can not be service delimiting ? > > > > Y(J)S > > > > 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. > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > 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. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 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 yaakov_s@rad.com Wed May 9 06:15:08 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F3021F8600 for ; Wed, 9 May 2012 06:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 M3oBtdH2XT8S for ; Wed, 9 May 2012 06:15:07 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id E750D21F85FB for ; Wed, 9 May 2012 06:15:05 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 9 May 2012 15:56:11 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Wed, 9 May 2012 16:15:03 +0300 From: Yaakov Stein To: "stbryant@cisco.com" , "pwe3@ietf.org" Thread-Topic: [PWE3] once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQACngdgAADF7kcA== Date: Wed, 9 May 2012 13:15:02 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C71F4@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> <4FAA4442.1050702@cisco.com> In-Reply-To: <4FAA4442.1050702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090206.4FAA6DD8.0045,ss=1,fgs=0 Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:15:08 -0000 > Yaakov > I think that the purpose of the text as to say that the tag > may or may not be service delimiting, which I think is > demonstrably true. Stewart, Yes, it is perhaps even tautological to state that it is either one or the = other. However, the text further states that if the tag is inserted by the CE then the tag is not service delimiting. This is demonstrably a significant restriction. Y(J)S From yaakov_s@rad.com Wed May 9 06:34:00 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA66E21F85C6 for ; Wed, 9 May 2012 06:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 LJKbfmCaVc+G for ; Wed, 9 May 2012 06:34:00 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 86E4921F851E for ; Wed, 9 May 2012 06:33:58 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 9 May 2012 16:17:23 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Wed, 9 May 2012 16:33:56 +0300 From: Yaakov Stein To: Alexander Vainshtein , "stbryant@cisco.com" Thread-Topic: [PWE3] once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQACngdgAAA4+BgAAIyKpg///OmgD//81L8A== Date: Wed, 9 May 2012 13:33:54 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C7276@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> , <4FAA4442.1050702@cisco.com> <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.140.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020203.4FAA7245.0030,ss=1,fgs=0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:34:00 -0000 Sasha,=20 Unfortunately, IMO 5603 is not clear, and is possibly not comprehensive. 5603 defines 3 cases (and states that all others are out of scope), that I understand as follows : 1) port mode - i.e. All-to-one bundling 2) single VLAN - i.e., look at the first VLAN, and then perform one-to-one = bundling=20 2.a with tag preservation 2.b with VLAN swap=20 2.c VLAN removal and the PW label identifying the EVC 2.d with untagged frames passed without modification 2.e with untagged frames passed after inserting PVID 2.f with S-tag insertion 3) Q-in-Q=20 3.a one-to-one with outer VLAN tag used as in 2 above (in fact, I think = this is precisely case 2!) 3.b one-to-one with both VLAN tags used and the outer tag removed. My understanding that all the cases in 2 and 3 are one-to-one=20 and not "arbitrary bundling" may be incorrect. I base this understanding on the settings, but perhaps these are just examp= les. Y(J)S From Alexander.Vainshtein@ecitele.com Wed May 9 06:48:58 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94CE21F85B5 for ; Wed, 9 May 2012 06:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 riJI3-k-tg7T for ; Wed, 9 May 2012 06:48:58 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id D60E121F859F for ; Wed, 9 May 2012 06:48:57 -0700 (PDT) Received: from [85.158.138.51:5959] by server-4.bemta-3.messagelabs.com id 57/13-15341-8C57AAF4; Wed, 09 May 2012 13:48:56 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1336571336!26171274!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 31195 invoked from network); 9 May 2012 13:48:56 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-9.tower-174.messagelabs.com with SMTP; 9 May 2012 13:48:56 -0000 X-AuditID: a8571401-b7f8d6d0000035b0-32-4faa764e371c Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 60.03.13744.E467AAF4; Wed, 9 May 2012 15:51:10 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 9 May 2012 15:48:56 +0200 From: Alexander Vainshtein To: Yaakov Stein Thread-Topic: [PWE3] once upon an erratum Thread-Index: Ac0tCaGewFO+Y9uSQqeRIjYDpnZDmwAAqzPQACv45wAAB60hnf//8ymA///d0zCAAChxAP//3W4Q Date: Wed, 9 May 2012 13:48:55 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> , <4FAA4442.1050702@cisco.com> <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC9043C7276@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043C7276@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTWUwTURTldUodlsGhgH0tBpvBBFQgbURTDSX6oeJGwSUmfIhj+9pObKdj pxDQDwnGGAERhaAWEjUQWWQRokgENeKCEEVJjCyiGBeSuiQEPwRN1JmOIMb5Ou+dc+65d+YO jinHFBqcYT3IzdIOShEsDwYBmsT03EaTrmwk2lA6dU1uGPhQDQyTRdOB67C0ih9tgWm1tTOy tDPN1gwsqwCk0Czr8tAepLUg3mykMtxMLm3Op7SMxUjpKS3noM3IiViPkaI5DrEWKjVY+9+T IsgYVotYs8vCsDYjtXmnKdFgWLUmUU+l7rIzvBYlOmnGoXUinqdtSCvciG2zln0tmP3+iT7A 9YbnPR4dVxSAF0QRCMIhmQynfzbJJbwIPnvdqigCwbiSfA5gyfTXBdKhFsAvzYN+lYI0wvYr rxQijiRj4ecTPwNFjJHpsOfoaz+OIONhx/FfWBHABc0yWFmHS/IsePxOqUzEcnIpfNh8348J cjssHhwEUlYnBieqHvrrB5FbYXHXkF8EhO6+9TfJpCwVHH1/QSZ1TcLa7qeYhKOg753UDyRj YGHD8wWSPgFe7JpSSHgFvHzpEyYFh8O+8+//TK+Gd+uH5WVA5Z0X4Z1n986ze+fZLwJ5I1BZ 3YyF4/j9Op0+CZkZD3KgJLPL2Q6EfanfEwk6wduTST2AxAEVSsS3NZiUgXQun+/sAWpcRkUR Dw42mpRh+12WfDvN27PdOQ7E9wCIY1Qk4Y0T5ISFzj+E3K5ZyiC8xNOYJsTsEj+xJ3ulTvfP gVIRrTtSTUrSJuzdAYQ45J61LsZxChKxOUJiuBvZUJ6VcXj+0jI8SEwOFZKXihqC52gnz9gk vh+oNSpik0iQImHPYee8H4FKmC+CYEQ2VNi9OddHoaBMKFh5TxyFF/6FOUpTAKruRq68VxO1 qHpoZKHvrJ1bH1IYMvbSV1Gn5p+ab6HxmejMgfEt1Tfq078bBtbW7L6a3feuQxY2+qJkCtys XmKdfPRmb8bl8ji9tfmJY1t5he9wzPXouMyErviumoTxC+qA1S3dvRPJmQ26DZjPeWQjP3zs 3MLJU7cb+vfpOspjJik5b6f1yzE3T/8GiA/o9u8DAAA= Cc: "pwe3@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 13:48:59 -0000 Yaakov, Lots of thanks for a prompt response (somewhat delayed by my persistent erro= rs in the references:-). After looking up again 5603 I tend to agree with you that some of the MEF sc= enarios are not covered. E.g., the situation when multiple (but not all) 802= .1q tags are mapped to the same PW. IMHO it is also not covered by 4447 - th= ere is no way to assure via signaling that the same set of VLANs is mapped t= o a given single PW at two endpoints of a tagged Ethernet PW. Maybe we should start from explicitly listing various MEF scenarios, mapping= some of them to the Ethernet PW parameters (both local and signaled) and co= ming up first with a list of gaps and then with solutions that would bridge= these gaps. I am not sure if there is sufficient interest in this kind of work in the co= mmunity; were it otherwise, SPs would be crying out loud for these solutions= . Or do I miss something? Regards, Sasha > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Wednesday, May 09, 2012 4:34 PM > To: Alexander Vainshtein; stbryant@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] once upon an erratum > > Sasha, > > Unfortunately, IMO 5603 is not clear, and is possibly not comprehensive. > > 5603 defines 3 cases (and states that all others are out of scope), > that I understand as follows : > > 1) port mode - i.e. All-to-one bundling > > 2) single VLAN - i.e., look at the first VLAN, and then perform one-to-one > bundling > 2.a with tag preservation > 2.b with VLAN swap > 2.c VLAN removal and the PW label identifying the EVC > 2.d with untagged frames passed without modification > 2.e with untagged frames passed after inserting PVID > 2.f with S-tag insertion > > 3) Q-in-Q > 3.a one-to-one with outer VLAN tag used as in 2 above (in fact, I think= this > is precisely case 2!) > 3.b one-to-one with both VLAN tags used and the outer tag removed. > > My understanding that all the cases in 2 and 3 are one-to-one > and not "arbitrary bundling" may be incorrect. > I base this understanding on the settings, but perhaps these are just > examples. > > Y(J)S 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 stbryant@cisco.com Wed May 9 07:29:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E601B11E809B for ; Wed, 9 May 2012 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.501 X-Spam-Level: X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 51viEWg6Uc1F for ; Wed, 9 May 2012 07:29:11 -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 E262511E809A for ; Wed, 9 May 2012 07:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2827; q=dns/txt; s=iport; t=1336573751; x=1337783351; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1EAnVGSmMbZ4bFM5LoWUFMxoU31wrNkBxaSZ5GVVafQ=; b=Tx1dfhI4Xt1/5QwjsrAYj4n1Z9x8lsFepQWEiYCM9t9/Sa06LQ38RCgO 6MIw3tW0Pw4IJjTy4IACxOnyVnRwDHzX9Fa+2tDSK8FeLVxwTpZFvYru+ tJ77yA4gR5Y+uCm/Y4PPP/BqZEfyCcBHP3fImEAmwdLuwD7Y6O2VsD+B9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOB9qk+Q/khN/2dsb2JhbABEszuBB4IMAQEBBBIBAiNAAQwECxEEAQEBCRYIBwkDAgECATQJCAYNAQUCAQEQBweHbAubQYNFEJxKiwwZhXkElX2OWIECZ4JqgV0 X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="137453267" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 May 2012 14:29:09 +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 q49ET9l8017776; Wed, 9 May 2012 14:29:09 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q49ET7IO021771; Wed, 9 May 2012 15:29:08 +0100 (BST) Message-ID: <4FAA7F33.5080505@cisco.com> Date: Wed, 09 May 2012 15:29:07 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexander Vainshtein References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il> , <4FAA4442.1050702@cisco.com> <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC9043C7276@EXRAD5.ad.rad.co.il> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 14:29:12 -0000 This sounds like it needs a short RFC explaining the issue and if necessary updating RFC4447 Stewart On 09/05/2012 14:48, Alexander Vainshtein wrote: > Yaakov, > Lots of thanks for a prompt response (somewhat delayed by my persistent errors in the references:-). > > After looking up again 5603 I tend to agree with you that some of the MEF scenarios are not covered. E.g., the situation when multiple (but not all) 802.1q tags are mapped to the same PW. IMHO it is also not covered by 4447 - there is no way to assure via signaling that the same set of VLANs is mapped to a given single PW at two endpoints of a tagged Ethernet PW. > > Maybe we should start from explicitly listing various MEF scenarios, mapping some of them to the Ethernet PW parameters (both local and signaled) and coming up first with a list of gaps and then with solutions that would bridge these gaps. > > I am not sure if there is sufficient interest in this kind of work in the community; were it otherwise, SPs would be crying out loud for these solutions. Or do I miss something? > > Regards, > Sasha > > >> -----Original Message----- >> From: Yaakov Stein [mailto:yaakov_s@rad.com] >> Sent: Wednesday, May 09, 2012 4:34 PM >> To: Alexander Vainshtein; stbryant@cisco.com >> Cc: pwe3@ietf.org >> Subject: RE: [PWE3] once upon an erratum >> >> Sasha, >> >> Unfortunately, IMO 5603 is not clear, and is possibly not comprehensive. >> >> 5603 defines 3 cases (and states that all others are out of scope), >> that I understand as follows : >> >> 1) port mode - i.e. All-to-one bundling >> >> 2) single VLAN - i.e., look at the first VLAN, and then perform one-to-one >> bundling >> 2.a with tag preservation >> 2.b with VLAN swap >> 2.c VLAN removal and the PW label identifying the EVC >> 2.d with untagged frames passed without modification >> 2.e with untagged frames passed after inserting PVID >> 2.f with S-tag insertion >> >> 3) Q-in-Q >> 3.a one-to-one with outer VLAN tag used as in 2 above (in fact, I think this >> is precisely case 2!) >> 3.b one-to-one with both VLAN tags used and the outer tag removed. >> >> My understanding that all the cases in 2 and 3 are one-to-one >> and not "arbitrary bundling" may be incorrect. >> I base this understanding on the settings, but perhaps these are just >> examples. >> >> Y(J)S > > 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. > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From amalis@gmail.com Fri May 11 06:05:03 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B527C21F84FA; Fri, 11 May 2012 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 Idj+5D+yzLet; Fri, 11 May 2012 06:05:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3356621F8705; Fri, 11 May 2012 06:05:02 -0700 (PDT) Received: by yhq56 with SMTP id 56so3154744yhq.31 for ; Fri, 11 May 2012 06:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=NHCfZuvPzNPj1SPzut0oElPsfhXKz3jdC8i1oEuiNMU=; b=KtpeGiyDkdLt7F4BrejrBmSM05FLH8j+3qdQgyhBNAu9wLQHHN/6h57r+TiVyJoYQG zQPEsCE3FxnsqiBxYycsrN3f1niDDaPmanjsyZWNIiB3Qp6ZUnJFogOYNtbLj9WXeBk8 on/XsovvcJcRdKU/ZsFYqvGSTi6aHjYPA3u5qIQaVCftfP2sMni1RkcBzOvZycHSr/tD NxZnI1jaNRbQmWsrJHctufuGXKtc18wv6c9F53KsbJmg/kQ9bmEhQlakHzqr5wLPDwmY 8Zo9Y3JV//ioSeLW0kzc1RlaSA2CrKyJRonNyEJkb85Yxzth3nmFqYCO9ERa+tzTI8Q8 VuTA== Received: by 10.236.190.2 with SMTP id d2mr10110657yhn.48.1336741501560; Fri, 11 May 2012 06:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.75.106 with HTTP; Fri, 11 May 2012 06:04:41 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 11 May 2012 09:04:41 -0400 Message-ID: To: The IESG , pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf305b0cb25b68e704bfc262f4 Subject: [PWE3] Publication request for draft-ietf-pwe3-cbit-negotiation-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 13:05:03 -0000 --20cf305b0cb25b68e704bfc262f4 Content-Type: text/plain; charset=ISO-8859-1 The PWE3 WG requests that draft-ietf-pwe3-cbit-negotiation-03 be published as a standards-track RFC. The writeup is below. Thanks, Andy ------------ Document Writeup for draft-ietf-pwe3-cbit-negotiation-03 As required by RFC 4858 , this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This updates a Standards Track RFC. Yes, the title page header is correct. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document solves a particular problem with the control word negotiation mechanism specified in RFC 4447. Based on the problem analysis, a message exchanging mechanism is introduced to solve the control word negotiation issue. This document updates the RFC 4447 control word negotiation mechanism. This update is fully backwards compatible with existing implementations. Working Group Summary This draft had strong consensus in the WG, and received good comments at the various stages of its development. Document Quality There is at least one known vendor implementation of the draft (the reporter says "Our product manager asked me to thank IETF&PWE3 to help to solve this problem"), and other vendors have expressed implementation plans. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Andrew Malis and Stewart Bryant. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed the draft for quality. It's a relatively short draft and the algorithm is easy to follow. Because the lead editor is not a native English speaker, the RFC Editor will probably do a minor editorial cleanup of the text from an English language perspective. Note that the draft currently has seven authors. Two of the authors, Vishwas Manral and Reshad Rahman, have indicated that they are willing to be moved to the acknowledgements section. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. It's been presented several times in the WG meetings and there's been good discussion on the list. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No, there is no known IPR concerning this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus in the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. It passes nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This RFC updates RFC 4447. This is included in the title page header, the abstract, and the introduction. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A --20cf305b0cb25b68e704bfc262f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The PWE3 WG requests that draft-ietf-pwe3-cbit-negotiation-03 be published = as a standards-track RFC. The writeup is below.

    Thanks,
    Andy
    <= br>------------

    Document Writeup for draft-ietf-pwe3-cbit-negotiatio= n-03

    As required by RFC 4858 </rfc/rfc4858.txt>, this is the current t= emplate
    for the Document Shepherd Write-Up.

    Changes are expected = over time. This version is dated 24 February 2012.

    (1) What type of = RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?=A0 Why
    is = this the proper type of RFC?=A0 Is this type of RFC indicated in the
    tit= le page header?

    Proposed Standard. This updates a Standards Track RF= C. Yes, the title page header is correct.

    (2) The IESG approval announcement includes a Document Announcement
    = Write-Up. Please provide such a Document Announcement Write-Up. Recent
    e= xamples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
    Technical Summary

    This document solves a particular problem with t= he control word negotiation
    mechanism specified in RFC 4447. Based on t= he problem analysis, a
    message exchanging mechanism is introduced to solve the control word
    ne= gotiation issue. This document updates the RFC 4447 control word
    negoti= ation mechanism. This update is fully backwards compatible with
    existing= implementations.

    Working Group Summary

    This draft had strong consensus in the WG,= and received good comments at the various stages of its development.
    Document Quality

    There is at least one known vendor implementation= of the draft (the reporter says "Our product manager asked me to than= k IETF&PWE3 to help to solve this problem"), and other vendors hav= e expressed implementation plans.

    Personnel

    =A0 Who is the Document Shepherd? Who is the Responsib= le Area
    =A0 Director?
    =A0
    Andrew Malis and Stewart Bryant.
    (3) Briefly describe the review of this document that was performed by
    = the Document Shepherd.=A0 If this version of the document is not ready
    for publication, please explain why the document is being forwarded to
    t= he IESG.

    The document shepherd reviewed the draft for quality. It= 9;s a relatively short draft and the algorithm is easy to follow. Because t= he lead editor is not a native English speaker, the RFC Editor will probabl= y do a minor editorial cleanup of the text from an English language perspec= tive.

    Note that the draft currently has seven authors. Two of the authors, Vi= shwas Manral and Reshad Rahman, have indicated that they are willing to be = moved to the acknowledgements section.

    (4) Does the document Shepher= d have any concerns about the depth or
    breadth of the reviews that have been performed?=A0

    No concerns. It= 's been presented several times in the WG meetings and there's been= good discussion on the list.

    (5) Do portions of the document need r= eview from a particular or from
    broader perspective, e.g., security, operational complexity, AAA, DNS,
    D= HCP, XML, or internationalization? If so, describe the review that
    took = place.

    No.

    (6) Describe any specific concerns or issues that = the Document Shepherd
    has with this document that the Responsible Area Director and/or the
    IES= G should be aware of? For example, perhaps he or she is uncomfortable
    wi= th certain parts of the document, or has concerns whether there really
    is a need for it. In any event, if the WG has discussed those issues andhas indicated that it still wishes to advance the document, detail thoseconcerns here.

    None.

    (7) Has each author confirmed that any= and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP 78
    = and BCP 79 have already been filed. If not, explain why.

    Yes.
    (8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the IPR
    disc= losures.

    No, there is no known IPR concerning this draft.

    (9)= How solid is the WG consensus behind this document? Does it
    represent = the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?=A0=A0=

    There is strong consensus in the WG.

    (10) Has anyone threat= ened an appeal or otherwise indicated extreme
    discontent? If so, please= summarise the areas of conflict in separate
    email messages to the Responsible Area Director. (It should be in a
    sepa= rate email because this questionnaire is publicly available.)

    No.
    (11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.iet= f.org/tools/idnits/ and the Internet-Drafts
    Checklist). Boilerplate = checks are not enough; this check needs to be
    thorough.

    It passes= nits.

    (12) Describe how the document meets any required formal review
    crit= eria, such as the MIB Doctor, media type, and URI type reviews.

    N/A<= br>
    (13) Have all references within this document been identified as
    either normative or informative?

    Yes.

    (14) Are there normativ= e references to documents that are not ready for
    advancement or are othe= rwise in an unclear state? If such normative
    references exist, what is t= he plan for their completion?

    No.

    (15) Are there downward normative references references (see= RFC 3967)?
    If so, list these downward references to support the Area Di= rector in the
    Last Call procedure.

    No.

    (16) Will publicat= ion of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header, listed
    in= the abstract, and discussed in the introduction? If the RFCs are not
    li= sted in the Abstract and Introduction, explain why, and point to the
    part of the document where the relationship of this document to the
    othe= r RFCs is discussed. If this information is not in the document,
    explain= why the WG considers it unnecessary.

    This RFC updates RFC 4447. Thi= s is included in the title page header, the abstract, and the introduction.=

    (17) Describe the Document Shepherd's review of the IANA considerat= ions
    section, especially with regard to its consistency with the body of= the
    document. Confirm that all protocol extensions that the document ma= kes
    are associated with the appropriate reservations in IANA registries.
    Con= firm that any referenced IANA registries have been clearly
    identified. C= onfirm that newly created IANA registries include a
    detailed specificati= on of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and a
    reaso= nable name for the new registry has been suggested (see RFC 5226).

    T= here are no IANA actions.

    (18) List any new IANA registries that req= uire Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful= in selecting the IANA Experts for these new registries.

    None.
    (19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    langua= ge, such as XML code, BNF rules, MIB definitions, etc.

    N/A

    --20cf305b0cb25b68e704bfc262f4-- From raymond.key@hotmail.com Fri May 11 20:06:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA521F85E5 for ; Fri, 11 May 2012 20:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.442, 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 u4T9CQTeQzQo for ; Fri, 11 May 2012 20:06:49 -0700 (PDT) Received: from snt0-omc3-s17.snt0.hotmail.com (snt0-omc3-s17.snt0.hotmail.com [65.55.90.156]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8921F85E4 for ; Fri, 11 May 2012 20:06:48 -0700 (PDT) Received: from SNT123-W6 ([65.55.90.137]) by snt0-omc3-s17.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 20:06:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a040d1b8-e7da-42fa-bba9-b09591acd59e_" X-Originating-IP: [113.92.101.35] From: Raymond Key Sender: To: Date: Sat, 12 May 2012 13:36:48 +1030 Importance: Normal In-Reply-To: <4FAA7F33.5080505@cisco.com> References: <07F7D7DED63154409F13298786A2ADC9043C64FB@EXRAD5.ad.rad.co.il>, , , <4FAA4442.1050702@cisco.com>, , <07F7D7DED63154409F13298786A2ADC9043C71BF@EXRAD5.ad.rad.co.il>, , <07F7D7DED63154409F13298786A2ADC9043C7276@EXRAD5.ad.rad.co.il>, , <4FAA7F33.5080505@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 May 2012 03:06:48.0950 (UTC) FILETIME=[45908960:01CD2FEC] Cc: pwe3@ietf.org Subject: Re: [PWE3] once upon an erratum X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 03:06:50 -0000 --_a040d1b8-e7da-42fa-bba9-b09591acd59e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree with Stewart. It would be good to have a draft clearly documenting t= he gaps and current practices operators use to overcome the challenges. Th= is will provide a base for solid discussion on whether protocol extensions = are required. When I worked for operators before=2C I have been working on MEF services o= ver MPLS. I remember we could do service bundling without considering exte= nsion to PWE3 standards. =20 Raymond Key=20 > Date: Wed=2C 9 May 2012 15:29:07 +0100 > From: stbryant@cisco.com > To: Alexander.Vainshtein@ecitele.com > CC: yaakov_s@rad.com=3B pwe3@ietf.org > Subject: Re: [PWE3] once upon an erratum >=20 > This sounds like it needs a short RFC explaining the issue and > if necessary updating RFC4447 >=20 > Stewart >=20 > On 09/05/2012 14:48=2C Alexander Vainshtein wrote: > > Yaakov=2C > > Lots of thanks for a prompt response (somewhat delayed by my persistent= errors in the references:-). > > > > After looking up again 5603 I tend to agree with you that some of the M= EF scenarios are not covered. E.g.=2C the situation when multiple (but not = all) 802.1q tags are mapped to the same PW. IMHO it is also not covered by = 4447 - there is no way to assure via signaling that the same set of VLANs i= s mapped to a given single PW at two endpoints of a tagged Ethernet PW. > > > > Maybe we should start from explicitly listing various MEF scenarios=2C = mapping some of them to the Ethernet PW parameters (both local and signaled= ) and coming up first with a list of gaps and then with solutions that woul= d bridge these gaps. > > > > I am not sure if there is sufficient interest in this kind of work in t= he community=3B were it otherwise=2C SPs would be crying out loud for these= solutions. Or do I miss something? > > > > Regards=2C > > Sasha > > > > > >> -----Original Message----- > >> From: Yaakov Stein [mailto:yaakov_s@rad.com] > >> Sent: Wednesday=2C May 09=2C 2012 4:34 PM > >> To: Alexander Vainshtein=3B stbryant@cisco.com > >> Cc: pwe3@ietf.org > >> Subject: RE: [PWE3] once upon an erratum > >> > >> Sasha=2C > >> > >> Unfortunately=2C IMO 5603 is not clear=2C and is possibly not comprehe= nsive. > >> > >> 5603 defines 3 cases (and states that all others are out of scope)=2C > >> that I understand as follows : > >> > >> 1) port mode - i.e. All-to-one bundling > >> > >> 2) single VLAN - i.e.=2C look at the first VLAN=2C and then perform on= e-to-one > >> bundling > >> 2.a with tag preservation > >> 2.b with VLAN swap > >> 2.c VLAN removal and the PW label identifying the EVC > >> 2.d with untagged frames passed without modification > >> 2.e with untagged frames passed after inserting PVID > >> 2.f with S-tag insertion > >> > >> 3) Q-in-Q > >> 3.a one-to-one with outer VLAN tag used as in 2 above (in fact=2C = I think this > >> is precisely case 2!) > >> 3.b one-to-one with both VLAN tags used and the outer tag removed. > >> > >> My understanding that all the cases in 2 and 3 are one-to-one > >> and not "arbitrary bundling" may be incorrect. > >> I base this understanding on the settings=2C but perhaps these are jus= t > >> examples. > >> > >> Y(J)S > > > > 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=2C please inform us by e-m= ail=2C phone or fax=2C and then delete the original and all copies thereof. > > > > >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 = --_a040d1b8-e7da-42fa-bba9-b09591acd59e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Agree with Stewart. =3B It would be good to have a dra= ft clearly documenting the gaps =3Band =3Bcurrent practices operato= rs use to overcome the challenges. =3B This will provide a base for sol= id discussion on whether protocol extensions are required.

    When I worked for operators before=2C I have been working on MEF = services over MPLS. =3B I remember we could do =3Bservice bundling = without considering =3Bextension to =3BPWE3 standards.
     =3B<= br>Raymond Key =3B
    >=3B Date: Wed=2C 9 May 2012 15:29:07 +0100
    >=3B From: s= tbryant@cisco.com
    >=3B To: Alexander.Vainshtein@ecitele.com
    >=3B = CC: yaakov_s@rad.com=3B pwe3@ietf.org
    >=3B Subject: Re: [PWE3] once up= on an erratum
    >=3B
    >=3B This sounds like it needs a short RFC ex= plaining the issue and
    >=3B if necessary updating RFC4447
    >=3B >=3B Stewart
    >=3B
    >=3B On 09/05/2012 14:48=2C Alexander Vain= shtein wrote:
    >=3B >=3B Yaakov=2C
    >=3B >=3B Lots of thanks fo= r a prompt response (somewhat delayed by my persistent errors in the refere= nces:-).
    >=3B >=3B
    >=3B >=3B After looking up again 5603 I te= nd to agree with you that some of the MEF scenarios are not covered. E.g.= =2C the situation when multiple (but not all) 802.1q tags are mapped to the= same PW. IMHO it is also not covered by 4447 - there is no way to assure v= ia signaling that the same set of VLANs is mapped to a given single PW at t= wo endpoints of a tagged Ethernet PW.
    >=3B >=3B
    >=3B >=3B May= be we should start from explicitly listing various MEF scenarios=2C mapping= some of them to the Ethernet PW parameters (both local and signaled) and c= oming up first with a list of gaps and then with solutions that would bridg= e these gaps.
    >=3B >=3B
    >=3B >=3B I am not sure if there is s= ufficient interest in this kind of work in the community=3B were it otherwi= se=2C SPs would be crying out loud for these solutions. Or do I miss someth= ing?
    >=3B >=3B
    >=3B >=3B Regards=2C
    >=3B >=3B Sa= sha
    >=3B >=3B
    >=3B >=3B
    >=3B >=3B>=3B -----Original = Message-----
    >=3B >=3B>=3B From: Yaakov Stein [mailto:yaakov_s@rad= .com]
    >=3B >=3B>=3B Sent: Wednesday=2C May 09=2C 2012 4:34 PM
    &= gt=3B >=3B>=3B To: Alexander Vainshtein=3B stbryant@cisco.com
    >=3B= >=3B>=3B Cc: pwe3@ietf.org
    >=3B >=3B>=3B Subject: RE: [PWE3] = once upon an erratum
    >=3B >=3B>=3B
    >=3B >=3B>=3B Sasha=2C=
    >=3B >=3B>=3B
    >=3B >=3B>=3B Unfortunately=2C IMO 5603 is= not clear=2C and is possibly not comprehensive.
    >=3B >=3B>=3B
    = >=3B >=3B>=3B 5603 defines 3 cases (and states that all others are ou= t of scope)=2C
    >=3B >=3B>=3B that I understand as follows :
    >= =3B >=3B>=3B
    >=3B >=3B>=3B 1) port mode - i.e. All-to-one bund= ling
    >=3B >=3B>=3B
    >=3B >=3B>=3B 2) single VLAN - i.e.=2C= look at the first VLAN=2C and then perform one-to-one
    >=3B >=3B>= =3B bundling
    >=3B >=3B>=3B 2.a with tag preservation
    >=3B= >=3B>=3B 2.b with VLAN swap
    >=3B >=3B>=3B 2.c VLAN re= moval and the PW label identifying the EVC
    >=3B >=3B>=3B 2.d w= ith untagged frames passed without modification
    >=3B >=3B>=3B = 2.e with untagged frames passed after inserting PVID
    >=3B >=3B>=3B= 2.f with S-tag insertion
    >=3B >=3B>=3B
    >=3B >=3B>=3B= 3) Q-in-Q
    >=3B >=3B>=3B 3.a one-to-one with outer VLAN tag us= ed as in 2 above (in fact=2C I think this
    >=3B >=3B>=3B is precise= ly case 2!)
    >=3B >=3B>=3B 3.b one-to-one with both VLAN tags u= sed and the outer tag removed.
    >=3B >=3B>=3B
    >=3B >=3B>= =3B My understanding that all the cases in 2 and 3 are one-to-one
    >=3B= >=3B>=3B and not "arbitrary bundling" may be incorrect.
    >=3B >= =3B>=3B I base this understanding on the settings=2C but perhaps these ar= e just
    >=3B >=3B>=3B examples.
    >=3B >=3B>=3B
    >=3B &g= t=3B>=3B Y(J)S
    >=3B >=3B
    >=3B >=3B This e-mail message is i= ntended for the recipient only and contains information which is CONFIDENTI= AL and which may be proprietary to ECI Telecom. If you have received this t= ransmission in error=2C please inform us by e-mail=2C phone or fax=2C and t= hen delete the original and all copies thereof.
    >=3B >=3B
    >=3B = >=3B
    >=3B
    >=3B
    >=3B --
    >=3B For corporate legal in= formation go to:
    >=3B
    >=3B http://www.cisco.com/web/about/doing_= business/legal/cri/index.html
    >=3B
    >=3B
    >=3B _____________= __________________________________
    >=3B pwe3 mailing list
    >=3B pw= e3@ietf.org
    >=3B https://www.ietf.org/mailman/listinfo/pwe3
    = --_a040d1b8-e7da-42fa-bba9-b09591acd59e_-- From internet-drafts@ietf.org Sat May 12 13:54:58 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E221F8589; Sat, 12 May 2012 13:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, 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 1lIvWePR3ptm; Sat, 12 May 2012 13:54:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7BC21F856A; Sat, 12 May 2012 13:54:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120512205457.4415.27515.idtracker@ietfa.amsl.com> Date: Sat, 12 May 2012 13:54:57 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-packet-pw-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 20:54:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Packet Pseudowire Encapsulation over an MPLS PSN Author(s) : Stewart Bryant Luca Martini George Swallow Andy Malis Filename : draft-ietf-pwe3-packet-pw-04.txt Pages : 15 Date : 2012-05-12 This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-packet-pw-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-packet-pw-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-packet-pw/ From iesg-secretary@ietf.org Mon May 14 14:37:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C157121F88B4; Mon, 14 May 2012 14:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 hZlxn1Sg7qk2; Mon, 14 May 2012 14:37:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0821F88BF; Mon, 14 May 2012 14:37:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120514213753.22711.33558.idtracker@ietfa.amsl.com> Date: Mon, 14 May 2012 14:37:53 -0700 Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Protocol Action: 'Packet Pseudowire Encapsulation over an MPLS PSN' to Proposed Standard (draft-ietf-pwe3-packet-pw-04.txt) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:37:55 -0000 The IESG has approved the following document: - 'Packet Pseudowire Encapsulation over an MPLS PSN' (draft-ietf-pwe3-packet-pw-04.txt) as Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-packet-pw/ Technical Summary This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. Working Group Summary This draft presents a number of alternative encapsulations for a generic packet PW that were investigated by the authors and discussed in the WG over a period of time (these are documented in the appendix), and reaches a conclusion about which one to use. However, an alternative approach was also proposed to the PWE3 working group by a different set of authors in a separate draft, and progressed over a period of a number of IETFs. A consensus call was conducted by the chairs to try to reach agreement on how to proceed. This resulted in the Ethernet PW encapsulation approach, specified in this document, being adopted. WG consensus on the alternative approach could not be reached at that time. Since this draft documents a new way to use an existing encapsulation, the draft was originally progressed as a BCP rather than on the standards track. However, it was subsequently noted in AD review that the document contains protocol definitions and makes IANA requests, and therefore it is now proposed on the standards track. Document Quality The draft uses an existing Ethernet PW type that is widely deployed. As well as being used for interconnecting Ethernet attachment circuits, there are implementations that directly terminate the Ethernet PW on an IP interface (e.g., on a VRF) which represents a subset of the proposal in the draft. However, direct termination on an LSR, as shown in the draft, is not known to be widely implemented/deployed yet, although such as model has been requested by service providers. Personnel Matthew Bocci (Matthew.Bocci@alcatel-lucent.com) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From matthew.bocci@alcatel-lucent.com Tue May 15 09:16:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933321F8998 for ; Tue, 15 May 2012 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.675 X-Spam-Level: X-Spam-Status: No, score=-107.675 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 iNVASQzf6cAF for ; Tue, 15 May 2012 09:16:47 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97F21F898B for ; Tue, 15 May 2012 09:16:47 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4FGGi6v019740 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 15 May 2012 18:16:46 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 15 May 2012 18:16:45 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Tue, 15 May 2012 18:16:44 +0200 Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05 Thread-Index: Ac0yth9/lfAS1oCZRmy/XPnEWqQO1w== Message-ID: In-Reply-To: <20120515153255.22015.83123.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: 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.84 Subject: [PWE3] FW: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:16:48 -0000 WG, Please see the attached IPR declaration related to draft-ietf-mpls-eth-oam-iwk-05. Since the draft has already been through last call, we will be running another working group last call on the draft in light of this IPR declaration. Please watch for a new working group last call notice, which will be issued shortly. In the mean time, and if you have not already responded affirmatively to this question, please let the chairs know if you are aware of any other IPR related to the draft. Best regards, Matthew On 15/05/2012 16:32, "IETF Secretariat" wrote: > >Dear Dinesh Mohan, Dr. Nabil N. Bitar, Philippe Niger, Ray Qiu, Simon >DeLord: > > An IPR disclosure that pertains to your Internet-Draft entitled "MPLS and >Ethernet OAM Interworking " (draft-ietf-pwe3-mpls-eth-oam-iwk) was >submitted to >the IETF Secretariat on 2012-05-14 and has been posted on the "IETF Page >of >Intellectual Property Rights Disclosures" >(https://datatracker.ietf.org/ipr/1781/). The title of the IPR disclosure >is >"Cisco's Statement of IPR Related to >draft-ietf-pwe3-mpls-eth-oam-iwk-05.""); > >The IETF Secretariat > From matthew.bocci@alcatel-lucent.com Wed May 16 05:57:27 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9321F858A for ; Wed, 16 May 2012 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.591 X-Spam-Level: X-Spam-Status: No, score=-107.591 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 TY93WvPoYHBH for ; Wed, 16 May 2012 05:57:26 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9571021F859A for ; Wed, 16 May 2012 05:57:26 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4GCum3M009178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 May 2012 14:57:24 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 16 May 2012 14:57:16 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Wed, 16 May 2012 14:57:15 +0200 Thread-Topic: Second WG last call for draft-ietf-pwe3-mpls-eth-oam-iwk-05 Thread-Index: Ac0zY2tTzMdDZufiT2WTHiBk+ZoANg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBD962BA2B1B7matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [PWE3] Second WG last call for draft-ietf-pwe3-mpls-eth-oam-iwk-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 12:57:27 -0000 --_000_CBD962BA2B1B7matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a two week working group last call for draft-ietf-pwe3-mp= ls-eth-oam-iwk-05.txt. In particular, please note the IPR disclosure received after the last WG la= st call had ended: https://datatracker.ietf.org/ipr/1781/ Please send any comments to the PWE3 list. This last call will close on Wednesday 30th May 2012. Best regards Matthew and Andy --_000_CBD962BA2B1B7matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    This email begins a two = week working group last call for draft-ietf-pwe3-mpls-eth-oam-iwk-05.t= xt.

    In particular, please note the IPR disclosure = received after the last WG last call had ended:

    https://datatracker.ietf.o= rg/ipr/1781/

    Please send any comments to the P= WE3 list.

    This last call will close on Wednesday 3= 0th May 2012.

    Best regards

    Matthew and Andy

    --_000_CBD962BA2B1B7matthewboccialcatellucentcom_-- From ietf-ipr@ietf.org Tue May 15 08:32:58 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A67821F883B; Tue, 15 May 2012 08:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, 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 kApIP+EdVJqF; Tue, 15 May 2012 08:32:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA121F880B; Tue, 15 May 2012 08:32:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: dinmohan@hotmail.com, nabil.n.bitar@verizon.com, philippe.niger@francetelecom.com, rayq@huawei.com, simon.a.delord@team.telstra.com X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515153255.22015.83123.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 08:32:55 -0700 X-Mailman-Approved-At: Wed, 16 May 2012 08:02:04 -0700 Cc: pwe3@ietf.org, andrew.g.malis@verizon.com, ipr-announce@ietf.org, stbryant@cisco.com Subject: [PWE3] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:32:58 -0000 Dear Dinesh Mohan, Dr. Nabil N. Bitar, Philippe Niger, Ray Qiu, Simon DeLor= d: An IPR disclosure that pertains to your Internet-Draft entitled "MPLS and Ethernet OAM Interworking " (draft-ietf-pwe3-mpls-eth-oam-iwk) was submitt= ed to the IETF Secretariat on 2012-05-14 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1781/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05.""= ); The IETF Secretariat From praveen.muley@alcatel-lucent.com Wed May 16 14:55:15 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8402E21F862A for ; Wed, 16 May 2012 14:55:14 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GICyJuZVVpSF for ; Wed, 16 May 2012 14:55:13 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 60D0B21F87D8 for ; Wed, 16 May 2012 14:55:13 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4GLtBOl002728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 16:55:12 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4GLtBjs022501 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 May 2012 16:55:11 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 16 May 2012 16:55:12 -0500 From: "Muley, Praveen V (Praveen)" To: "Andrew G. Malis" , "pwe3@ietf.org" Date: Wed, 16 May 2012 16:55:10 -0500 Thread-Topic: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 Thread-Index: Ac0p/m6gmPmqnEdeR36yHA73ZbzKkQJr/ySw Message-ID: <2073A6C5467C99478898544C6EBA3F4602C1907872@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F4602C1907872USNAVSXCHMBSC_" 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.9 Subject: Re: [PWE3] IPR checking on draft-ietf-pwe3-redundancy-bit-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:55:15 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602C1907872USNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, I'm not aware of any IPR applying to this draft. -Praveen On 04/05/2012 14:29, "Andrew G. Malis" > wrote: To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3 WG: Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks much, Andy --_000_2073A6C5467C99478898544C6EBA3F4602C1907872USNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Andy,

    I'm not aware of any IPR applying to this draft.

    -Praveen

    On 04/05/2012 14:29, "Andrew G. Malis" <amalis@gmail.com> wrote:

    To the authors of draft-ietf-pwe3-redundancy-bit-07, and the PWE3=20 WG:

    Are you aware of any IPR that applies to the the draft?
    If = so,=20 has this IPR been disclosed in compliance with IETF IPR
    rules (see RFC= s=20 3979, 4879, 3669 and 5378 for more details)?

    If you are listed as = a=20 document author or contributor please
    reply to this email regardless o= f=20 whether or not you are
    aware of any relevant IPR. The document will no= t=20 advance to
    the next stage until a response has been received from=20 each
    author and contributor.

    If you are on the PWE3 WG email li= st=20 but are not listed as
    an author or contributor, then please explicitly= =20 respond only if
    you are aware of any IPR that has not yet been disclos= ed=20 in
    conformance with IETF rules.

    Thanks=20 much,
    Andy

    --_000_2073A6C5467C99478898544C6EBA3F4602C1907872USNAVSXCHMBSC_-- From ma.yuxia@zte.com.cn Wed May 16 19:07:10 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB24211E8091 for ; Wed, 16 May 2012 19:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 jg7hs3OHN1W4 for ; Wed, 16 May 2012 19:07:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BCD1E11E8073 for ; Wed, 16 May 2012 19:07:09 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201397396305; Thu, 17 May 2012 09:23:02 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 60658.1397396305; Thu, 17 May 2012 10:07:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q4H26t5e053054 for ; Thu, 17 May 2012 10:06:55 +0800 (GMT-8) (envelope-from ma.yuxia@zte.com.cn) To: "pwe3@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ma.yuxia@zte.com.cn Date: Thu, 17 May 2012 10:06:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-17 10:06:56, Serialize complete at 2012-05-17 10:06:56 Content-Type: multipart/alternative; boundary="=_alternative 000BA12A48257A01_=" X-MAIL: mse01.zte.com.cn q4H26t5e053054 Subject: [PWE3] R: New Version Notification for draft-hao-pwe3-iccp-extension-for-msp-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:07:11 -0000 This is a multipart message in MIME format. --=_alternative 000BA12A48257A01_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpOZXcgdmVyc2lvbiBvZiAiZHJhZnQtaGFvLXB3ZTMtaWNjcC1leHRlbnNpb24t Zm9yLW1zcCIgaGFzIGJlZW4gdXBsb2FkZWQuIA0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUh DQoNClRoYW5rIHlvdSENCg0KQi5SLg0KWXV4aWENCg0KDQotLS0tLSDXqreiyMsgwu3T8c+8MDI4 NzE0L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTItMDUtMTcgMDk6NTUgLS0tLS0NCg0KaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIA0KMjAxMi0wNS0xNiAxMDo0NQ0KDQrK1bz+yMsNCm1hLnl1eGlhQHp0 ZS5jb20uY24NCrOty80NCmNhby53YW5taW5nQHp0ZS5jb20uY24sIHl1LmppbmdoYWlAenRlLmNv bS5jbiwgY2hlbmd3ZWlxaWFuZ0BjbWNjLmNvbS5jbiwgDQpoYW8uaG9uZ2ppZUB6dGUuY29tLmNu DQrW98ziDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhby1wd2UzLWljY3At ZXh0ZW5zaW9uLWZvci1tc3AtMDIudHh0DQoNCg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaGFvLXB3ZTMtaWNjcC1leHRlbnNpb24tZm9yLW1zcC0wMi50eHQgaGFzIA0KYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1eGlhIE1hIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC1oYW8tcHdl My1pY2NwLWV4dGVuc2lvbi1mb3ItbXNwDQpSZXZpc2lvbjogICAgICAgICAgICAgICAgIDAyDQpU aXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgSUNDUCBleHRlbnNpb24gZm9yIHRoZSBN U1AgYXBwbGljYXRpb24NCkNyZWF0aW9uIGRhdGU6ICAgICAgICAgICAgMjAxMi0wNS0xNg0KV0cg SUQ6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVt YmVyIG9mIHBhZ2VzOiAxNw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IHNvbWUgZXh0ZW5zaW9ucyBvbiBJbnRlci1DaGFzc2lzDQogICBDb21tdW5pY2F0aW9uIFByb3Rv Y29sKElDQ1ApIHRvIHN1cHBvcnQgaW50ZXItY2hhc3NpcyBsaW5lYXINCiAgIG11bHRpcGxleCBz ZWN0aW9uIHByb3RlY3Rpb24oTVNQKSB0aGF0IGlzIGRlc2NyaWJlZCBpbiBHLjg0MS4gIExpbmVh cg0KICAgbXVsdGlwbGV4IHNlY3Rpb24gcHJvdGVjdGlvbihNU1ApIGlzIHVzZWQgdG8gcHJvdGVj dCBTeW5jaHJvbm91cw0KICAgRGlnaXRhbCBIaWVyYXJjaHkgKFNESCkgbGlua3Mgd2hpY2ggY291 bGQgYmUgdXNlZCBhcyBhdHRhY2htZW50DQogICBjaXJjdWl0cyB0byBkdWFsLWhvbWUgdG8gdHdv IG9yIG1vcmUgUEVzLiAgSW4gdGhpcyBjYXNlLCBJQ0NQIGlzDQogICBpbnRyb2R1Y2VkIHRvIHN1 cHBvcnQgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIHN0YXRlIHN5bmNocm9uaXphdGlvbg0KICAgYmV0 d2VlbiB0d28gY2hhc3Npc2VzLg0KDQogIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --=_alternative 000BA12A48257A01_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5ldyB2ZXJzaW9uIG9mICZxdW90 O2RyYWZ0LWhhby1wd2UzLWljY3AtZXh0ZW5zaW9uLWZvci1tc3AmcXVvdDsNCmhhcyBiZWVuIHVw bG9hZGVkLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkFueSBjb21tZW50cyBhcmUgd2VsY29tZSE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkIuUi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPll1eGlhPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBj b2xvcj0jODAwMDgwIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tINeqt6LIyyDC7dPxz7wwMjg3MTQv dXNlci96dGVfbHRkDQrKsbzkIDIwMTItMDUtMTcgMDk6NTUgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9iPg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDUtMTYgMTA6 NDU8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+bWEueXV4aWFAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2FvLndhbm1pbmdAenRl LmNvbS5jbiwgeXUuamluZ2hhaUB6dGUuY29tLmNuLA0KY2hlbmd3ZWlxaWFuZ0BjbWNjLmNvbS5j biwgaGFvLmhvbmdqaWVAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtaGFvLXB3 ZTMtaWNjcC1leHRlbnNpb24tZm9yLW1zcC0wMi50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0 YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1oYW8tcHdlMy1pY2NwLWV4dGVuc2lvbi1mb3ItbXNwLTAyLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZdXhpYSBNYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuPGJyPg0KPGJyPg0KRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO2RyYWZ0LWhhby1wd2UzLWljY3At ZXh0ZW5zaW9uLWZvci1tc3A8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7MDI8YnI+DQpUaXRsZTogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCklDQ1AgZXh0ZW5zaW9uIGZvciB0aGUgTVNQIGFwcGxpY2F0aW9uPGJyPg0KQ3JlYXRpb24g ZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7MjAxMi0wNS0xNjxicj4NCldHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KSW5kaXZpZHVhbCBTdWJt aXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAxNzxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiAmbmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgc29tZSBleHRlbnNpb25zIG9uIEludGVy LUNoYXNzaXM8YnI+DQogJm5ic3A7IENvbW11bmljYXRpb24gUHJvdG9jb2woSUNDUCkgdG8gc3Vw cG9ydCBpbnRlci1jaGFzc2lzIGxpbmVhcjxicj4NCiAmbmJzcDsgbXVsdGlwbGV4IHNlY3Rpb24g cHJvdGVjdGlvbihNU1ApIHRoYXQgaXMgZGVzY3JpYmVkIGluIEcuODQxLiAmbmJzcDtMaW5lYXI8 YnI+DQogJm5ic3A7IG11bHRpcGxleCBzZWN0aW9uIHByb3RlY3Rpb24oTVNQKSBpcyB1c2VkIHRv IHByb3RlY3QgU3luY2hyb25vdXM8YnI+DQogJm5ic3A7IERpZ2l0YWwgSGllcmFyY2h5IChTREgp IGxpbmtzIHdoaWNoIGNvdWxkIGJlIHVzZWQgYXMgYXR0YWNobWVudDxicj4NCiAmbmJzcDsgY2ly Y3VpdHMgdG8gZHVhbC1ob21lIHRvIHR3byBvciBtb3JlIFBFcy4gJm5ic3A7SW4gdGhpcyBjYXNl LCBJQ0NQDQppczxicj4NCiAmbmJzcDsgaW50cm9kdWNlZCB0byBzdXBwb3J0IHRoZSBjb25maWd1 cmF0aW9uIGFuZCBzdGF0ZSBzeW5jaHJvbml6YXRpb248YnI+DQogJm5ic3A7IGJldHdlZW4gdHdv IGNoYXNzaXNlcy48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIFNl Y3JldGFyaWF0PGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 000BA12A48257A01_=-- From yaakov_s@rad.com Tue May 22 01:57:29 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966EA21F84FC for ; Tue, 22 May 2012 01:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 qqeKpG9HTU1b for ; Tue, 22 May 2012 01:57:28 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id E87CA21F84CF for ; Tue, 22 May 2012 01:57:25 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 22 May 2012 11:35:18 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 22 May 2012 11:57:21 +0300 From: Yaakov Stein To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05 Thread-Index: Ac0yth9/lfAS1oCZRmy/XPnEWqQO1wFQmTtA Date: Tue, 22 May 2012 08:57:20 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043CECBA@EXRAD5.ad.rad.co.il> References: <20120515153255.22015.83123.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090202.4FBB54F2.0159,ss=1,fgs=0 Subject: Re: [PWE3] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-mpls-eth-oam-iwk-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:57:29 -0000 Please note that this is the same application which was originally disclose= d in the context of oam-message-mapping (and as I expressed then, that linking was incorrect). That disclosure was removed at the request of the submitter,=20 and this one submitted in its stead, so this should not surprise anyone. Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Tuesday, May 15, 2012 19:17 To: pwe3@ietf.org Subject: [PWE3] FW: IPR Disclosure: Cisco's Statement of IPR Related to dra= ft-ietf-pwe3-mpls-eth-oam-iwk-05 WG, Please see the attached IPR declaration related to draft-ietf-mpls-eth-oam-iwk-05. Since the draft has already been through last call, we will be running another working group last call on the draft in light of this IPR declaration. Please watch for a new working group last call notice, which will be issued shortly. In the mean time, and if you have not already responded affirmatively to this question, please let the chairs know if you are aware of any other IPR related to the draft. Best regards, Matthew On 15/05/2012 16:32, "IETF Secretariat" wrote: > >Dear Dinesh Mohan, Dr. Nabil N. Bitar, Philippe Niger, Ray Qiu, Simon >DeLord: > > An IPR disclosure that pertains to your Internet-Draft entitled "MPLS and >Ethernet OAM Interworking " (draft-ietf-pwe3-mpls-eth-oam-iwk) was >submitted to >the IETF Secretariat on 2012-05-14 and has been posted on the "IETF Page >of >Intellectual Property Rights Disclosures" >(https://datatracker.ietf.org/ipr/1781/). The title of the IPR disclosure >is >"Cisco's Statement of IPR Related to >draft-ietf-pwe3-mpls-eth-oam-iwk-05.""); > >The IETF Secretariat > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From matthew.bocci@alcatel-lucent.com Wed May 23 06:30:34 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BA821F861F for ; Wed, 23 May 2012 06:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 G7PCFT-OOAD0 for ; Wed, 23 May 2012 06:30:34 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CF48021F861A for ; Wed, 23 May 2012 06:30:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4NDUGTr029615 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 23 May 2012 15:30:30 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 23 May 2012 15:30:26 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Wed, 23 May 2012 15:30:25 +0200 Thread-Topic: WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac046DaNXWtnHZkqTW6Ri0XHstXayw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBE2A5002BAFFmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:30:35 -0000 --_000_CBE2A5002BAFFmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a two week working group last call for draft-ietf-pwe3-vc= cv-for-gal-01.txt Please review the draft and post any comments to the PWE3 list. This working group last call will end on 6th June 2012. Best regards Matthew --_000_CBE2A5002BAFFmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    This email begins a two = week working group last call for draft-ietf-pwe3-vccv-for-gal-01.txt

    Please review the draft and post any comments to th= e PWE3 list.

    This working group last call will end= on 6th June 2012.

    Best regards

    Matthew


    --_000_CBE2A5002BAFFmatthewboccialcatellucentcom_-- From matthew.bocci@alcatel-lucent.com Wed May 23 06:35:27 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1018421F8573 for ; Wed, 23 May 2012 06:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 PgXKWD9bt3Tk for ; Wed, 23 May 2012 06:35:26 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE321F86C1 for ; Wed, 23 May 2012 06:35:25 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4NDZE6e021048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 May 2012 15:35:23 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 23 May 2012 15:35:16 +0200 From: "Bocci, Matthew (Matthew)" To: "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" Date: Wed, 23 May 2012 15:35:14 +0200 Thread-Topic: IPR check on draft-ietf-pwe3-vccv-for-gal Thread-Index: Ac046OL1GA6GPS7/R+yVtqK8/TqsyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBE2A6222BB0Amatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "pwe3@ietf.org" Subject: [PWE3] IPR check on draft-ietf-pwe3-vccv-for-gal X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:35:27 -0000 --_000_CBE2A6222BB0Amatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the authors of draft-ietf-pwe3-vccv-for-gal-01.txt, and the PWE3 WG: Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Regards Matthew --_000_CBE2A6222BB0Amatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    To the authors= of draft-ietf-pwe3-vccv-for-gal-01.txt, and the PWE3 WG:<= br>
    Are you aware of any IPR that appl= ies to the the draft?
    If so, has this = IPR been disclosed in compliance with IETF IPR
    <= span class=3D"Apple-style-span" style=3D"font-family: Calibri; font-size: m= edium; ">rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

    If you are listed as a= document author or contributor please
    reply to this email regardless of whether or not you are<= br>aware of any relevant IPR. The document will not advanc= e to
    the next stage until a response h= as been received from each
    author and = contributor.

    If y= ou are on the PWE3 WG email list but are not listed as
    =     an author or contributor, then please explicitly respond o= nly if
    you are aware of any IPR that h= as not yet been disclosed in
    conform= ance with IETF rules.

    Regards

    M= atthew
    --_000_CBE2A6222BB0Amatthewboccialcatellucentcom_-- From tnadeau@lucidvision.com Wed May 23 06:49:59 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341FD21F84D9 for ; Wed, 23 May 2012 06:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5tDNc57-7EV2 for ; Wed, 23 May 2012 06:49:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6D921F8497 for ; Wed, 23 May 2012 06:49:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id A916A2131258; Wed, 23 May 2012 09:49:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkeonsCs2Fc5; Wed, 23 May 2012 09:49:57 -0400 (EDT) Received: from sa-nc-apg-244.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id 7959F213124F; Wed, 23 May 2012 09:49:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5D46B7B-F35F-485A-B9D5-555CC81B5ABF" From: Thomas Nadeau In-Reply-To: Date: Wed, 23 May 2012 09:49:54 -0400 Message-Id: <92DE5017-1166-4F11-B602-22F1C5DCA017@lucidvision.com> References: To: "Bocci, Matthew (Matthew)" X-Mailer: Apple Mail (2.1278) Cc: "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] IPR check on draft-ietf-pwe3-vccv-for-gal X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:49:59 -0000 --Apple-Mail=_C5D46B7B-F35F-485A-B9D5-555CC81B5ABF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I am not aware of any. --Tom On May 23, 2012:9:35 AM, at 9:35 AM, Bocci, Matthew (Matthew) wrote: > To the authors of draft-ietf-pwe3-vccv-for-gal-01.txt, and the PWE3 WG: > > Are you aware of any IPR that applies to the the draft? > If so, has this IPR been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If you are listed as a document author or contributor please > reply to this email regardless of whether or not you are > aware of any relevant IPR. The document will not advance to > the next stage until a response has been received from each > author and contributor. > > If you are on the PWE3 WG email list but are not listed as > an author or contributor, then please explicitly respond only if > you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > > Regards > > Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_C5D46B7B-F35F-485A-B9D5-555CC81B5ABF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am not aware of = any.

    = --Tom


    On May 23, 2012:9:35 AM, = at 9:35 AM, Bocci, Matthew (Matthew) wrote:

    To the authors of draft-ietf-pwe3-vccv-for-gal-01.txt, and the = PWE3 WG:

    Are you aware of any IPR that applies to the the = draft?
    If so, has this IPR = been disclosed in compliance with IETF IPR
    rules (see RFCs = 3979, 4879, 3669 and 5378 for more details)?

    If you are listed as a document author or contributor = please
    reply to this email = regardless of whether or not you are
    aware of any = relevant IPR. The document will not advance to
    the next stage until = a response has been received from each
    author and = contributor.

    If you are on the PWE3 WG email list but are not listed = as
    an author or = contributor, then please explicitly respond only if
    you are aware of any = IPR that has not yet been disclosed in
    conformance with = IETF rules.
    pwe3@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/pwe3

    = --Apple-Mail=_C5D46B7B-F35F-485A-B9D5-555CC81B5ABF-- From tnadeau@juniper.net Wed May 23 06:48:57 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4AF21F85D7 for ; Wed, 23 May 2012 06:48:57 -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=[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 8t3m6VfT83J7 for ; Wed, 23 May 2012 06:48:57 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 782C121F857F for ; Wed, 23 May 2012 06:48:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT7zqwmI75hu/iZDTJa3tUM/FHe/3TCRP@postini.com; Wed, 23 May 2012 06:48:57 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 23 May 2012 06:48:36 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 23 May 2012 09:48:35 -0400 From: Thomas Nadeau To: "Bocci, Matthew (Matthew)" , "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" Date: Wed, 23 May 2012 09:48:32 -0400 Thread-Topic: IPR check on draft-ietf-pwe3-vccv-for-gal Thread-Index: Ac046r9HDd/Wq0uySOC8bV1e9K0QKg== 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.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 23 May 2012 08:01:57 -0700 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] IPR check on draft-ietf-pwe3-vccv-for-gal X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:48:57 -0000 None that I know of. --Tom From: , "Matthew (Matthew)" > To: "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" > Cc: "pwe3@ietf.org" > Subject: IPR check on draft-ietf-pwe3-vccv-for-gal To the authors of draft-ietf-pwe3-vccv-for-gal-01.txt, and the PWE3 WG: Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please reply to this email regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Regards Matthew From ostokes@extremenetworks.com Thu May 24 15:05:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2518211E808A; Thu, 24 May 2012 15:05:22 -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=[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 KeOaYjMjndY7; Thu, 24 May 2012 15:05:21 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F511E8081; Thu, 24 May 2012 15:05:21 -0700 (PDT) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p1.corp.extremenetworks.com ([10.0.4.73]) with mapi; Thu, 24 May 2012 15:05:21 -0700 From: Olen Stokes To: "'stbryant@cisco.com'" , "draft-ietf-pwe3-redundancy@tools.ietf.org" Date: Thu, 24 May 2012 15:05:21 -0700 Thread-Topic: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? Thread-Index: Ac0pYPImieMNyxghQz2q4WnJnYe/WAQmDwqg Message-ID: <6738A78F51650A4FAEDCF6844B26C2140177F9C08FC5@USEXCHANGE.corp.extremenetworks.com> References: <4FA2D904.5040007@cisco.com> In-Reply-To: <4FA2D904.5040007@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 Cc: pwe3 , "pwe3-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:05:22 -0000 Sorry for the delay in responding. I am not aware of any IPR with regards = to this draft. Cheers, Olen -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Thursday, May 03, 2012 3:14 PM To: draft-ietf-pwe3-redundancy@tools.ietf.org Cc: pwe3; pwe3-chairs@tools.ietf.org; iesg@ietf.org Subject: [PWE3] Is there any IPR on draft-ietf-pwe3-redundancy? This document was on the IESG Telechat for 10 May 2012. However it has been drawn to my attention that because of the length of tim= e taken to address comments the proto statement was written before we requi= red the shepherd to asked each author to confirmed that they know of no IPR= related to this draft. I have postponed the IESG review by two weeks so that, we can check whether= there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies to the the draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please reply to this = email regardless of whether or not you are aware of any relevant IPR. The d= ocument will not advance to the next stage until a response has been receiv= ed from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Regards Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From yaakov_s@rad.com Fri May 25 05:10:10 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2678D21F854E for ; Fri, 25 May 2012 05:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 NJe0dYJgKEMa for ; Fri, 25 May 2012 05:10:07 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 470B321F854B for ; Fri, 25 May 2012 05:10:03 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 25 May 2012 14:47:09 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Fri, 25 May 2012 15:09:59 +0300 From: Yaakov Stein To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac046DaNXWtnHZkqTW6Ri0XHstXaywBgjL4w Date: Fri, 25 May 2012 12:09:58 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043D1F4AEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090208.4FBF7698.00AC,ss=1,fgs=0 Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:10:10 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043D1F4AEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My comments. Most are editorial (some of the document seems to have been wr= itten in haste) but one expresses strong disagreement. As-is I do NOT support this document becoming an RFC! Y(J)S Operators have indicated in [RFC4377]= , [RFC3916]. 1) please remove the period. 2) there are no remarks from operators on OAM in RFC 3916. Many of the motivations of this survey are detailed in [MAN-CW]. This document and the implementation survey concluded that operators have had difficulty deploying the protocol given the number of combinations and options for its use. 1) please remove the carriage return. 2) I think "This doument" refers to [MAN-CW] and not the present document. = Please say "That document" or otherwise clarify. 3) please give a reference to the implementation survey 4) IMO MAN-CW does not CONCLUDE that there are problems in implementing VCC= V. It perhaps states this, but it mainly proposes an alternative. Similarly the survey does not CONCLUDE anything. It merely reports on wh= at various operators said. Perhaps you want to say "it may be concluded based on the implementation = survey [SURVEY] ... " In addition to the implementation issues just described, the ITU-T and IETF have set out to enhance MPLS to make it suitable as an optical transport protocol. An OPTICAL transport protocol ????? The requirements for this protocol are defined as the MPLS Transport Profile (MPLS-TP). I believe that by definition MPLS-TP is a PROFILE not an independent protoc= ol. In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created; Had to be ? No, there were alternative solutions proposed, and I can think= of several more. It was "standardized". This document defines two modes of operation of VCCV: 1) with a control word or 2) without a control word, but with a ACH encapsulation making it possible to handle all of the other cases handled by the other modes of VCCV. In either case, it will be mandatory to implement and use that mode under that scenario. 1) Now "This document" means THIS document! 2) The rest of the wording here is very confusing. Use of VCCV with a CW is already defined. What is being defined here is a new method of using VCCV for PWs over MPLS-= TP with a GAL. 3) The so called "without a CW" encap, in fact has a CW for the VCCV packet= s. 4) not an ACH encap, but a GAL or a GACh encap. 5) WHAT is mandatory to implement and use ? The PW Label must set the TTL field to 1. How does a label set anything ? The GAL field MUST contain What is a GAL field ? If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised. Although I personally prefer using type 1 if there IS a CW, I do not recall hearing WG consensus on this. This statement goes further than 5085. I would like to see people explicitly express support for this. If the c-bit is not set, indicating that the control word is not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised. Sorry, but I strongly disagree here!!!!!!!!!!! By a show of hands at the last meeting people agreed that router alert coul= d be eliminated. However, it was NOT agreed that TTL expiry was to be eliminated - quite the= contrary! So, without CW there are 2 options - the presently available and deployed o= ne of using TTL and this new one. The requirement to support this mode ONLY has NOT received consensus from t= he WG. If the remote PE also supports Type 4, then Type 4 MUST be used superceding the Capability Advertisement Selection rules of section 7 from RFC5085. I am not sure I agree with the language. If a PE supports Type 4 but wishes not to use it, what is to keep it from h= iding the fact that it supports type 4 ? I think you mean that if a PE advertised that it supports Type 4. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Wednesday, May 23, 2012 16:30 To: pwe3@ietf.org Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt This email begins a two week working group last call for draft-ietf-pwe3-vc= cv-for-gal-01.txt Please review the draft and post any comments to the PWE3 list. This working group last call will end on 6th June 2012. Best regards Matthew --_000_07F7D7DED63154409F13298786A2ADC9043D1F4AEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    My comments. Most are editorial (some of the document seems = to have been written in haste)

    but one expresses strong disagreement.

     

    As-is I do NOT support this document becoming an RFC!

     

    Y(J)S

     

     

     

      Operators have indicated in [RFC4377], [<=
a href=3D"http://tools.ietf.org/html/rfc3916" title=3D""Requirements f=
or Pseudo-Wire Emulation Edge-to-Edge (PWE3)"">RFC3916].

    1) please remove the period.

    2) there are no remarks from operators on OAM in RFC 3916.

     

       Many of the
       motivations of this survey are detailed in [MAN-CW]. This document
     
       and the implementation survey concluded that operator=
s have had
       difficulty deploying the protocol given the number of=
 combinations
       and options for its use.

    1) please remove the carriage return.

    2) I think "This doument" refers to [MAN-CW] and n= ot the present document. Please say "That document" or otherwise = clarify.

    3) please give a reference to the implementation survey=

    4) IMO MAN-CW does not CONCLUDE that there are problems in i= mplementing VCCV. It perhaps states this,

       but it mainly proposes an alternative.

       Similarly the survey does not CONCLUDE anything= . It merely reports on what various operators said.

      Perhaps you want to say "it may be concluded bas= ed on the implementation survey [SURVEY] … "

     

      = In addition to the implementation issues just described, the ITU-T

      = and IETF have set out to enhance MPLS to make it suitable as an=

     &n= bsp;      optical transport protocol.

    An OPTICAL transport protocol ?????

     

      The r= equirements for this protocol are

     &n= bsp; defined as the MPLS Transport Profile (MPLS-TP).I believe that by definition MPLS-TP is a PROFILE not an ind= ependent protocol.

     

       In order to support
       VCCV when an MPLS-TP PSN is in use, the GAL-ACH had t=
o be created;

    Had to be ?  No, there were alternative solutions propo= sed, and I can think of several more.

    It was "standardized".

     

       This document defines two modes of operation of VCCV:=
 1) with
       a control word or 2) without a control word, but=

       with a ACH encapsulation making it possible to handle=
 all of the
       other cases handled by the other modes of VCCV. In ei=
ther case, it
       will be mandatory to implement and use that mode unde=
r that
       scenario.
    1) No=
w "This document" means THIS document!
    2) Th=
e rest of the wording here is very confusing.
    Use o=
f VCCV with a CW is already defined. 
    What =
is being defined here is a new method of using VCCV for PWs over MPLS-TP wi=
th a GAL.
    3) Th=
e so called "without a CW" encap, in fact has a CW for the VCCV p=
ackets.
    4) no=
t an ACH encap, but a GAL or a GACh encap.
    5) WH=
AT is mandatory to implement and use ?
    =
 
       The PW Label must set the TTL field to 1.<=
/span>
    How d=
oes a label set anything ?
    =
 
      The GAL field MUST contain
    What =
is a GAL field ?
    =
 
      If the c-bit is set,
      indicating the use of the control word, type 1 MUST be adve=
rtised
      and type 4 MUST NOT be advertised.
    Altho=
ugh I personally prefer using type 1 if there IS a CW,

    I do =
not recall hearing WG consensus on this.
    

    This =
statement goes further than 5085.
    

    I wou=
ld like to see people explicitly express support for this.
    

    =
 
    

      If the c-bit is not set,
    

      indicating that the control word is not in use, type 4 MUST=

    

      be advertised, and type 1 MUST NOT be advertised.
    

    Sorry=
, but I strongly disagree here!!!!!!!!!!!
    

    By a =
show of hands at the last meeting people agreed that router alert could be =
eliminated.
    

    Howev=
er, it was NOT agreed that TTL expiry was to be eliminated – quite th=
e contrary!
    

    So, w=
ithout CW there are 2 options – the presently available and deployed =
one of using TTL
    

    and t=
his new one.
    

    The r=
equirement to support this mode ONLY has NOT received consensus from the WG=
.
    

     
    

      If the remote PE also supports Type
    

      4, then Type 4 MUST be used superceding the Capability=

    

      Advertisement Selection rules of section 7 from <=
a href=3D"http://tools.ietf.org/html/rfc5085">RFC5085.
    

    I am =
not sure I agree with the language.
    

    If a =
PE supports Type 4 but wishes not to use it, what is to keep it from hiding=
 the fact that it supports type 4 ?
    

    I thi=
nk you mean that if a PE advertised that it supports Type 4.
    

     
    

     
    

    Y(J)S
    

     
    

    

    

    From: pwe3-bou=
nces@ietf.org [mailto:pwe3-bounces@ietf.org]
On Behalf Of Bocci, Matthew (Matthew)
    
Sent: Wednesday, May 23, 2012 16:30
    
To: pwe3@ietf.org
    
Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt=

    

    

    

     
    

    

    This email begins a two week working group last call for =
draft-ietf-pwe3-vccv-for-gal-01.txt
    

    

    

     
    

    

    

    Please review the draft and post any comments to the PWE3 list=
.
    

    

    

     
    

    

    

    This working group last call will end on 6th June 2012.
    

    

    

     
    

    

    

    Best regards
    

    

    

     
    

    

    

    Matthew
    

    

    

     
    

    

    

     
    --_000_07F7D7DED63154409F13298786A2ADC9043D1F4AEXRAD5adradcoil_-- From yaakov_s@rad.com Fri May 25 06:43:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7DC21F8647 for ; Fri, 25 May 2012 06:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 UVgoxGC45YBc for ; Fri, 25 May 2012 06:43:04 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 01C1621F8616 for ; Fri, 25 May 2012 06:43:00 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 25 May 2012 16:20:05 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Fri, 25 May 2012 16:42:56 +0300 From: Yaakov Stein To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac046DaNXWtnHZkqTW6Ri0XHstXaywBgjL4wAAP8s5A= Date: Fri, 25 May 2012 13:42:55 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043D1FD7@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043D1FD7EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0B020D.4FBF8C61.0175,ss=1,fgs=0 Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 13:43:07 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043D1FD7EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I received an off-list email in response to my previous email, which convinced me to issue a clarification of my disagreement. The proposal is to require any PE not using a CW to advertise and use the n= ew Type 4 VCCV. As I voiced my concerns at the meeting, if accepted, this would ex-post facto delegitimize thousands of deployed devices, that up-to-now were completely RFC compliant. There are on rare occasions when breaking with the past is a good idea. As a completely imaginary example, I could understand someone who is of the opinion that IPv4 should be turned= off on core Internet routers. However, for the WG to accept such a course of action there would need to b= e a very strong reason to do so, and a very strong consensus would be needed. No strong reason has been given (other than a vague mis-referenced statement about operators having had di= fficulties); and there was no consensus whatsoever to accept this course of action. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Friday, May 25, 2012 15:10 To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt My comments. Most are editorial (some of the document seems to have been wr= itten in haste) but one expresses strong disagreement. As-is I do NOT support this document becoming an RFC! Y(J)S Operators have indicated in [RFC4377]= , [RFC3916]. 1) please remove the period. 2) there are no remarks from operators on OAM in RFC 3916. Many of the motivations of this survey are detailed in [MAN-CW]. This document and the implementation survey concluded that operators have had difficulty deploying the protocol given the number of combinations and options for its use. 1) please remove the carriage return. 2) I think "This doument" refers to [MAN-CW] and not the present document. = Please say "That document" or otherwise clarify. 3) please give a reference to the implementation survey 4) IMO MAN-CW does not CONCLUDE that there are problems in implementing VCC= V. It perhaps states this, but it mainly proposes an alternative. Similarly the survey does not CONCLUDE anything. It merely reports on wh= at various operators said. Perhaps you want to say "it may be concluded based on the implementation = survey [SURVEY] ... " In addition to the implementation issues just described, the ITU-T and IETF have set out to enhance MPLS to make it suitable as an optical transport protocol. An OPTICAL transport protocol ????? The requirements for this protocol are defined as the MPLS Transport Profile (MPLS-TP). I believe that by definition MPLS-TP is a PROFILE not an independent protoc= ol. In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created; Had to be ? No, there were alternative solutions proposed, and I can think= of several more. It was "standardized". This document defines two modes of operation of VCCV: 1) with a control word or 2) without a control word, but with a ACH encapsulation making it possible to handle all of the other cases handled by the other modes of VCCV. In either case, it will be mandatory to implement and use that mode under that scenario. 1) Now "This document" means THIS document! 2) The rest of the wording here is very confusing. Use of VCCV with a CW is already defined. What is being defined here is a new method of using VCCV for PWs over MPLS-= TP with a GAL. 3) The so called "without a CW" encap, in fact has a CW for the VCCV packet= s. 4) not an ACH encap, but a GAL or a GACh encap. 5) WHAT is mandatory to implement and use ? The PW Label must set the TTL field to 1. How does a label set anything ? The GAL field MUST contain What is a GAL field ? If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised. Although I personally prefer using type 1 if there IS a CW, I do not recall hearing WG consensus on this. This statement goes further than 5085. I would like to see people explicitly express support for this. If the c-bit is not set, indicating that the control word is not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised. Sorry, but I strongly disagree here!!!!!!!!!!! By a show of hands at the last meeting people agreed that router alert coul= d be eliminated. However, it was NOT agreed that TTL expiry was to be eliminated - quite the= contrary! So, without CW there are 2 options - the presently available and deployed o= ne of using TTL and this new one. The requirement to support this mode ONLY has NOT received consensus from t= he WG. If the remote PE also supports Type 4, then Type 4 MUST be used superceding the Capability Advertisement Selection rules of section 7 from RFC5085. I am not sure I agree with the language. If a PE supports Type 4 but wishes not to use it, what is to keep it from h= iding the fact that it supports type 4 ? I think you mean that if a PE advertised that it supports Type 4. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Wednesday, May 23, 2012 16:30 To: pwe3@ietf.org Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt This email begins a two week working group last call for draft-ietf-pwe3-vc= cv-for-gal-01.txt Please review the draft and post any comments to the PWE3 list. This working group last call will end on 6th June 2012. Best regards Matthew --_000_07F7D7DED63154409F13298786A2ADC9043D1FD7EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I received an off-list email in response to my previous emai= l,

    which convinced me to issue a clarification of my disagreeme= nt.

     

    The proposal is to require any PE not using a CW to advertis= e and use the new Type 4 VCCV.

     

    As I voiced my concerns at the meeting, if accepted,

    this would ex-post facto delegitimize thousands of deployed = devices,

    that up-to-now were completely RFC compliant.

     

    There are on rare occasions when breaking with the past is a= good idea.

    As a completely imaginary example,

    I could understand someone who is of the opinion that IPv4 s= hould be turned off on core Internet routers.

     

    However, for the WG to accept such a course of action there = would need to be a very strong reason to do so,

    and a very strong consensus would be needed.

    No strong reason has been given

    (other than a vague mis-referenced statement about operators=  having had difficulties);

    and there was no consensus whatsoever to accept this course = of action.

     

    Y(J)S

     

    From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
    Sent: Friday, May 25, 2012 15:10
    To: Bocci, Matthew (Matthew); pwe3@ietf.org
    Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01= .txt

     

    My comments. Most are editorial (some of the document seems = to have been written in haste)

    but one expresses strong disagreement.

     

    As-is I do NOT support this document becoming an RFC!

     

    Y(J)S

     

     

     

      Operators have indicated in [RFC4377], [<=
a href=3D"http://tools.ietf.org/html/rfc3916" title=3D""Requirements f=
or Pseudo-Wire Emulation Edge-to-Edge (PWE3)"">RFC3916].

    1) please remove the period.

    2) there are no remarks from operators on OAM in RFC 3916.

     

       Many of the
       motivations of this survey are detailed in [MAN-CW]. This document
     
       and the implementation survey concluded that operator=
s have had
       difficulty deploying the protocol given the number of=
 combinations
       and options for its use.

    1) please remove the carriage return.

    2) I think "This doument" refers to [MAN-CW] and n= ot the present document. Please say "That document" or otherwise = clarify.

    3) please give a reference to the implementation survey=

    4) IMO MAN-CW does not CONCLUDE that there are problems in i= mplementing VCCV. It perhaps states this,

       but it mainly proposes an alternative.

       Similarly the survey does not CONCLUDE anything= . It merely reports on what various operators said.

      Perhaps you want to say "it may be concluded bas= ed on the implementation survey [SURVEY] … "

     

      = In addition to the implementation issues just described, the ITU-T

      = and IETF have set out to enhance MPLS to make it suitable as an=

     &n= bsp;      optical transport protocol.

    An OPTICAL transport protocol ?????

     

      The r= equirements for this protocol are

     &n= bsp; defined as the MPLS Transport Profile (MPLS-TP).I believe that by definition MPLS-TP is a PROFILE not an ind= ependent protocol.

     

       In order to support
       VCCV when an MPLS-TP PSN is in use, the GAL-ACH had t=
o be created;

    Had to be ?  No, there were alternative solutions propo= sed, and I can think of several more.

    It was "standardized".

     

       This document defines two modes of operation of VCCV:=
 1) with
       a control word or 2) without a control word, but=

       with a ACH encapsulation making it possible to handle=
 all of the
       other cases handled by the other modes of VCCV. In ei=
ther case, it
       will be mandatory to implement and use that mode unde=
r that
       scenario.
    1) No=
w "This document" means THIS document!
    2) Th=
e rest of the wording here is very confusing.
    Use o=
f VCCV with a CW is already defined. 
    What =
is being defined here is a new method of using VCCV for PWs over MPLS-TP wi=
th a GAL.
    3) Th=
e so called "without a CW" encap, in fact has a CW for the VCCV p=
ackets.
    4) no=
t an ACH encap, but a GAL or a GACh encap.
    5) WH=
AT is mandatory to implement and use ?
    =
 
       The PW Label must set the TTL field to 1.<=
/span>
    How d=
oes a label set anything ?
    =
 
      The GAL field MUST contain
    What =
is a GAL field ?
    =
 
      If the c-bit is set,
      indicating the use of the control word, type 1 MUST be adve=
rtised
      and type 4 MUST NOT be advertised.
    Altho=
ugh I personally prefer using type 1 if there IS a CW,

    I do =
not recall hearing WG consensus on this.
    

    This =
statement goes further than 5085.
    

    I wou=
ld like to see people explicitly express support for this.
    

    =
 
    

      If the c-bit is not set,
    

      indicating that the control word is not in use, type 4 MUST=

    

      be advertised, and type 1 MUST NOT be advertised.
    

    Sorry=
, but I strongly disagree here!!!!!!!!!!!
    

    By a =
show of hands at the last meeting people agreed that router alert could be =
eliminated.
    

    Howev=
er, it was NOT agreed that TTL expiry was to be eliminated – quite th=
e contrary!
    

    So, w=
ithout CW there are 2 options – the presently available and deployed =
one of using TTL
    

    and t=
his new one.
    

    The r=
equirement to support this mode ONLY has NOT received consensus from the WG=
.
    

     
    

      If the remote PE also supports Type
    

      4, then Type 4 MUST be used superceding the Capability=

    

      Advertisement Selection rules of section 7 from <=
a href=3D"http://tools.ietf.org/html/rfc5085">RFC5085.
    

    I am =
not sure I agree with the language.
    

    If a =
PE supports Type 4 but wishes not to use it, what is to keep it from hiding=
 the fact that it supports type 4 ?
    

    I thi=
nk you mean that if a PE advertised that it supports Type 4.
    

     
    

     
    

    Y(J)S
    

     
    

    

    

    From: pwe3-bou=
nces@ietf.org [mailto:pwe3-bounces@ietf.org]
On Behalf Of Bocci, Matthew (Matthew)
    
Sent: Wednesday, May 23, 2012 16:30
    
To: pwe3@ietf.org
    
Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt=

    

    

    

     
    

    

    This email begins a two week working group last call for =
draft-ietf-pwe3-vccv-for-gal-01.txt
    

    

    

     
    

    

    

    Please review the draft and post any comments to the PWE3 list=
.
    

    

    

     
    

    

    

    This working group last call will end on 6th June 2012.
    

    

    

     
    

    

    

    Best regards
    

    

    

     
    

    

    

    Matthew
    

    

    

     
    

    

    

     
    --_000_07F7D7DED63154409F13298786A2ADC9043D1FD7EXRAD5adradcoil_-- From cpignata@cisco.com Fri May 25 07:15:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED121F85C3 for ; Fri, 25 May 2012 07:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[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 RGgb2g10-PoE for ; Fri, 25 May 2012 07:15:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA7A21F854D for ; Fri, 25 May 2012 07:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=16174; q=dns/txt; s=iport; t=1337955310; x=1339164910; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Shu61JRDEB/58VrMXqAWgm7uWUCst8gnhwBm+isPoTo=; b=Ge2k6VbkJB6k85Vp5JA79TzW+e2pccA15OSukmFty0Cf0DLJyV+zFlZe gSVQUVzf+zwK2YtGOmtbWEhk1+U2hRKhYMazq1hQpnm0mbGEwYdaKArPQ gcoyNdBkjFsw/EZfdNvzABokJVOXZw4ubNVc9nUu85jBAVo1rUFqZj3Sn A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAO2Sv0+tJXG9/2dsb2JhbABFgkWpEAGJO4EHghUBAQEDARIBClwFCwtGVwYBNIdmBQubS59diwGEZmADjjWGY4EPjH2BZIJ8gUM X-IronPort-AV: E=Sophos;i="4.75,656,1330905600"; d="asc'?scan'208,217";a="86686771" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 25 May 2012 14:15:09 +0000 Received: from rtp-cpignata-8914.cisco.com (rtp-cpignata-8914.cisco.com [10.117.115.53]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PEF8u8019944; Fri, 25 May 2012 14:15:09 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A199900A-1388-474E-84F9-AF33BFB704D4"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> Date: Fri, 25 May 2012 10:15:07 -0400 Message-Id: <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> To: Yaakov Stein , pwe3@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:15:11 -0000 --Apple-Mail=_A199900A-1388-474E-84F9-AF33BFB704D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_A1F0B52D-050C-4557-A2E8-372B180D5030" --Apple-Mail=_A1F0B52D-050C-4557-A2E8-372B180D5030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 PWE3ers, I too have strong concerns about this document being WGLCed. A meta-concern centers around the scope of this document. My = understanding (and please correct this with a citation if I am = incorrect) is that there was consensus for this document to define a new = CC Type 4 using GAL, but there was not consensus to have this document = redefine all Control Channels and their requirement levels (i.e., = deprecating or creating rules of use).=20 =46rom the minutes at http://tools.ietf.org/wg/pwe3/minutes we can see = that: 20 min - General discussion on VCCV for GAL There appear to be two separate issues on the table: 1. VCCV support for a PW associated channel that uses the GAL = as an alert mechanisms (VCCV Type 4). This is really the subject of = the draft. 2. What to do about legacy modes, particularly router alert = and TTL expiry. This is a separate issue regarding the progress of = RFC5085 (or some future RFC) to Internet Standard status. And this I-D should only deal with issue #1 but not #2. This is also = clear from the filename "vccv-for-gal", which was changed from the = "vccv-2" of the individual submission to make very explicitly clear this = scope. However, the title of this I-D is still "Unified Control Channel". Additionally I would like to highlight in agreement two issues that = Yaakov brought up. On May 25, 2012, at 8:09 AM, Yaakov Stein wrote: > My comments. Most are editorial (some of the document seems to have = been written in haste) I believe that the number of editorial issues actually amount to = technical concerns. For example, the Title, Abstract, and Introduction = speak of things in the scope of a 5085bis. Moreover, the Introduction = repeats Figures 1 and 2 and the Acronyms even repeats unused ones (L2SS, = LCCE are meaningless and unused in this doc). =46rom my perspective, the collection of these editorials amount to a = blocking comment. > =20 > If the c-bit is set, > indicating the use of the control word, type 1 MUST be advertised > and type 4 MUST NOT be advertised. > Although I personally prefer using type 1 if there IS a CW, > I do not recall hearing WG consensus on this. > This statement goes further than 5085. > I would like to see people explicitly express support for this. > =20 > If the c-bit is not set, > indicating that the control word is not in use, type 4 MUST > be advertised, and type 1 MUST NOT be advertised. > Sorry, but I strongly disagree here!!!!!!!!!!! > By a show of hands at the last meeting people agreed that router alert = could be eliminated. > However, it was NOT agreed that TTL expiry was to be eliminated =96 = quite the contrary! > So, without CW there are 2 options =96 the presently available and = deployed one of using TTL > and this new one. > The requirement to support this mode ONLY has NOT received consensus = from the WG. >=20 Similarly, this seems to contradict the actual document scope. We = discussed the best approach for "unification" in Paris and subsequently = on email, and it is closer to doing a 5085bis than having a document = that does not update to redefine. I object to VCCV-for-GAL going beyond = VCCV for GAL. As it stands, I do not support this document move forward as is. Thanks, -- Carlos. --Apple-Mail=_A1F0B52D-050C-4557-A2E8-372B180D5030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://tools.ietf.org/wg/pw= e3/minutes we can see that:
              RFC5085
          (or some future RFC) to Internet Standard =
status.

    And this I-D should only deal = with issue #1 but not #2. This is also clear from the filename = "vccv-for-gal", which was changed from the "vccv-2" of the individual = submission to make very explicitly clear this = scope.

    However, the title of this I-D is still = "Unified Control Channel".

    Additionally I would = like to highlight in agreement two issues that Yaakov brought = up.

    On May 25, 2012, at 8:09 AM, Yaakov Stein = wrote:

    My comments. Most are = editorial (some of the document seems to have been written in = haste)

    I believe = that the number of editorial issues actually amount to technical = concerns. For example, the Title, Abstract, and Introduction speak of = things in the scope of a 5085bis. Moreover, the Introduction repeats = Figures 1 and 2 and the Acronyms even repeats unused ones (L2SS, LCCE = are meaningless and unused in this doc).

    =46rom = my perspective, the collection of these editorials amount to a blocking = comment.


     
      If the c-bit is =
set,
      indicating the use of the control =
word, type 1 MUST be advertised
    Although I =
personally prefer using type 1 if there IS a =
CW,
    I do not recall hearing WG consensus on =
this.
    This statement goes further than =
5085.
    I would like to see people explicitly express =
support for this.
     
      be advertised, and type 1 MUST NOT be =
advertised.
    Sorry, but I strongly disagree =
here!!!!!!!!!!!
    By a show of hands at the last meeting people =
agreed that router alert could be =
eliminated.
    However, it was NOT agreed that TTL expiry =
was to be eliminated =96 quite the contrary!
    So, without =
CW there are 2 options =96 the presently available and deployed one of =
using TTL
    and this new one.
    The =
requirement to support this mode ONLY has NOT received consensus from =
the WG.


    Similarly,= this seems to contradict the actual document scope. We discussed the = best approach for "unification" in Paris and subsequently on email, and = it is closer to doing a 5085bis than having a document that does not = update to redefine. I object to VCCV-for-GAL going beyond VCCV for = GAL.

    As it stands, I do not support this = document move forward as = is.

    Thanks,

    -- = Carlos.



    = --Apple-Mail=_A1F0B52D-050C-4557-A2E8-372B180D5030-- --Apple-Mail=_A199900A-1388-474E-84F9-AF33BFB704D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk+/k+wACgkQtfDPGTp3USwvlwCfXpehGkhc+DuR78UxyDnD3tVv K/IAoIqW1eiACwZFM3/neKhKAWft83ef =5EXG -----END PGP SIGNATURE----- --Apple-Mail=_A199900A-1388-474E-84F9-AF33BFB704D4-- From gregory.mirsky@ericsson.com Fri May 25 10:01:27 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C13C21F8750 for ; Fri, 25 May 2012 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Z2uMmXUjtaOZ for ; Fri, 25 May 2012 10:01:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B902521F873C for ; Fri, 25 May 2012 10:01:23 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4PH1FTu025612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 May 2012 12:01:21 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 25 May 2012 13:01:16 -0400 From: Gregory Mirsky To: Carlos Pignataro , Yaakov Stein , "pwe3@ietf.org" Date: Fri, 25 May 2012 13:01:15 -0400 Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac06gNDEKW3yYBHESl2FVbKhRfTofwAFsfYg Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> In-Reply-To: <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:01:27 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do not support as in the current form document goes beyond mere definition = of the new Control Channel type for VCCV. And concur with concerns expressed by Yaacov and Carlos. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Car= los Pignataro Sent: Friday, May 25, 2012 7:15 AM To: Yaakov Stein; pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt PWE3ers, I too have strong concerns about this document being WGLCed. A meta-concern centers around the scope of this document. My understanding = (and please correct this with a citation if I am incorrect) is that there w= as consensus for this document to define a new CC Type 4 using GAL, but the= re was not consensus to have this document redefine all Control Channels an= d their requirement levels (i.e., deprecating or creating rules of use). >From the minutes at http://tools.ietf.org/wg/pwe3/minutes we can see that: 20 min - Genera= l discussion on VCCV for GAL There appear to be two separate issues on the table: 1. VCCV support = for a PW associated channel that uses the GAL as an alert mechanisms (VCCV Type 4). This is really the subject of the= draft. 2. What to do ab= out legacy modes, particularly router alert and TTL expiry. This is a separate issue regarding the progress of RFC508= 5 (or some future RFC) to Internet Standard status. And this I-D should only deal with issue #1 but not #2. This is also clear = from the filename "vccv-for-gal", which was changed from the "vccv-2" of th= e individual submission to make very explicitly clear this scope. However, the title of this I-D is still "Unified Control Channel". Additionally I would like to highlight in agreement two issues that Yaakov = brought up. On May 25, 2012, at 8:09 AM, Yaakov Stein wrote: My comments. Most are editorial (some of the document seems to have been wr= itten in haste) I believe that the number of editorial issues actually amount to technical = concerns. For example, the Title, Abstract, and Introduction speak of thing= s in the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 a= nd 2 and the Acronyms even repeats unused ones (L2SS, LCCE are meaningless = and unused in this doc). >From my perspective, the collection of these editorials amount to a blockin= g comment. If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised. Although I personally prefer using type 1 if there IS a CW, I do not recall hearing WG consensus on this. This statement goes further than 5085. I would like to see people explicitly express support for this. If the c-bit is not set, indicating that the control word is not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised. Sorry, but I strongly disagree here!!!!!!!!!!! By a show of hands at the last meeting people agreed that router alert coul= d be eliminated. However, it was NOT agreed that TTL expiry was to be eliminated - quite the= contrary! So, without CW there are 2 options - the presently available and deployed o= ne of using TTL and this new one. The requirement to support this mode ONLY has NOT received consensus from t= he WG. Similarly, this seems to contradict the actual document scope. We discussed= the best approach for "unification" in Paris and subsequently on email, an= d it is closer to doing a 5085bis than having a document that does not upda= te to redefine. I object to VCCV-for-GAL going beyond VCCV for GAL. As it stands, I do not support this document move forward as is. Thanks, -- Carlos. --_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Do not support as in the current form document goe= s beyond=20 mere definition of the new Control Channel type for VCCV.
    And concur with concerns expressed by Yaacov and=20 Carlos.
     
      &n= bsp; Regards,
            Greg

    From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos=20 Pignataro
    Sent: Friday, May 25, 2012 7:15 AM
    To: Yaakov= =20 Stein; pwe3@ietf.org
    Subject: Re: [PWE3] WG Last Call for=20 draft-ietf-pwe3-vccv-for-gal-01.txt

    PWE3ers,

    I too have strong concerns about this document being WGLCed.

    A meta-concern centers around the scope of this document. My understan= ding=20 (and please correct this with a citation if I am incorrect) is that there w= as=20 consensus for this document to define a new CC Type 4 using GAL, but there = was=20 not consensus to have this document redefine all Control Channels and their= =20 requirement levels (i.e., deprecating or creating rules of use). 

    From the minutes at http://tools.ietf.org/wg/pwe= 3/minutes we=20 can see that:
              20 min - General discussion on=
 VCCV for GAL
          There appear to be two separate issues on the table:
          1. VCCV support for a PW associated channel that uses the=
 GAL as an
          alert mechanisms (VCCV Type 4). This is really the subject of the=
 draft.
          2. What to do about legacy modes, particularly router ale=
rt and TTL
          expiry. This is a separate issue regarding the progress of RFC5085
          (or some future RFC) to Internet Standard status.

    And this I-D should only deal with issue #1 but not #2. This is also c= lear=20 from the filename "vccv-for-gal", which was changed from the "vccv-2" of th= e=20 individual submission to make very explicitly clear this scope.

    However, the title of this I-D is still "Unified Control Channel".

    Additionally I would like to highlight in agreement two issues that Ya= akov=20 brought up.

    On May 25, 2012, at 8:09 AM, Yaakov Stein wrote:
    My=20 comments. Most are editorial (some of the document seems to have been wri= tten=20 in haste)

    I believe that the number of editorial issues actually amount to techn= ical=20 concerns. For example, the Title, Abstract, and Introduction speak of thing= s in=20 the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 and 2 = and=20 the Acronyms even repeats unused ones (L2SS, LCCE are meaningless and unuse= d in=20 this doc).

    From my perspective, the collection of these editorials amount to a=20 blocking comment.


     
      If the c-bit=
 is set,
      indicating the use of the control wor=
d, type 1 MUST be advertised
      and type 4 MUST NO=
T be advertised.
    Although I personally prefer using type 1 if there IS =
a CW,
    I do not recall hearing WG consensus on this.
    This statement =
goes further than 5085.
    I would like to see people explicitly express s=
upport for this.
     
      If the c-bit is not=
 set,
      indicating that the control word is not i=
n use, type 4 MUST
    <=
SPAN lang=3DEN style=3D"FONT-SIZE: 9pt">  be advertised, and type 1 MU=
ST NOT be advertised.
    Sorry, but I strongly disagree here!!!!!!!!!!!
    By a show of hands at the last meeting people agreed that router alert c=
ould be eliminated.
    =
However, it was NOT agreed that TTL expiry was to b=
e eliminated – quite the contrary!
    So, without CW there are 2 op=
tions – the presently available and deployed one of using TTL
    and=
 this new one.
    The requirement to support this mode ONLY has NOT receiv=
ed consensus from the WG.

    Similarly, this seems to contradict the actual document scope. We disc= ussed=20 the best approach for "unification" in Paris and subsequently on email, and= it=20 is closer to doing a 5085bis than having a document that does not update to= =20 redefine. I object to VCCV-for-GAL going beyond VCCV for GAL.

    As it stands, I do not support this document move forward as is.

    Thanks,

    -- Carlos.



    --_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_-- From tnadeau@lucidvision.com Tue May 29 05:54:17 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6121F8763 for ; Tue, 29 May 2012 05:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] 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 7rtTKEqlKmda for ; Tue, 29 May 2012 05:54:16 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1621F8762 for ; Tue, 29 May 2012 05:54:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 7FBFE213EB87; Tue, 29 May 2012 08:54:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAM3WP2C+Pf4; Tue, 29 May 2012 08:54:15 -0400 (EDT) Received: from [192.168.1.64] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 22E9F213EB77; Tue, 29 May 2012 08:54:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1ABADA6C-26E6-4D48-8CC4-7BF78E3C65C2" From: Thomas Nadeau In-Reply-To: Date: Tue, 29 May 2012 08:54:14 -0400 Message-Id: <5E889EDF-82C4-4B32-BBBA-D5C8AE3A5A2A@lucidvision.com> References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> To: Gregory Mirsky X-Mailer: Apple Mail (2.1278) Cc: Carlos Pignataro , Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 12:54:17 -0000 --Apple-Mail=_1ABADA6C-26E6-4D48-8CC4-7BF78E3C65C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Generic statements like this are not useful at this point in the = process; please be specific and what you object to and what changes you = propose to correct them. This will allow the WG to discuss any changes = on the list if they are major. What we want to avoid is making changes = on the same issue multiple times due to multiple conflicting change = requests, or attempting to fix generic comments.=20 --Tom > Do not support as in the current form document goes beyond mere = definition of the new Control Channel type for VCCV. > And concur with concerns expressed by Yaacov and Carlos. > =20 > Regards, > Greg >=20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Carlos Pignataro > Sent: Friday, May 25, 2012 7:15 AM > To: Yaakov Stein; pwe3@ietf.org > Subject: Re: [PWE3] WG Last Call for = draft-ietf-pwe3-vccv-for-gal-01.txt >=20 > PWE3ers, >=20 > I too have strong concerns about this document being WGLCed. >=20 > A meta-concern centers around the scope of this document. My = understanding (and please correct this with a citation if I am = incorrect) is that there was consensus for this document to define a new = CC Type 4 using GAL, but there was not consensus to have this document = redefine all Control Channels and their requirement levels (i.e., = deprecating or creating rules of use).=20 >=20 > =46rom the minutes at http://tools.ietf.org/wg/pwe3/minutes we can see = that: > 20 min - General discussion on VCCV for GAL > There appear to be two separate issues on the table: > 1. VCCV support for a PW associated channel that uses the = GAL as an > alert mechanisms (VCCV Type 4). This is really the subject = of the draft. > 2. What to do about legacy modes, particularly router alert = and TTL > expiry. This is a separate issue regarding the progress of = RFC5085 > (or some future RFC) to Internet Standard status. >=20 > And this I-D should only deal with issue #1 but not #2. This is also = clear from the filename "vccv-for-gal", which was changed from the = "vccv-2" of the individual submission to make very explicitly clear this = scope. >=20 > However, the title of this I-D is still "Unified Control Channel". >=20 > Additionally I would like to highlight in agreement two issues that = Yaakov brought up. >=20 > On May 25, 2012, at 8:09 AM, Yaakov Stein wrote: >=20 >> My comments. Most are editorial (some of the document seems to have = been written in haste) >=20 > I believe that the number of editorial issues actually amount to = technical concerns. For example, the Title, Abstract, and Introduction = speak of things in the scope of a 5085bis. Moreover, the Introduction = repeats Figures 1 and 2 and the Acronyms even repeats unused ones (L2SS, = LCCE are meaningless and unused in this doc). >=20 > =46rom my perspective, the collection of these editorials amount to a = blocking comment. >=20 >=20 >> =20 >> If the c-bit is set, >> indicating the use of the control word, type 1 MUST be advertised >> and type 4 MUST NOT be advertised. >> Although I personally prefer using type 1 if there IS a CW, >> I do not recall hearing WG consensus on this. >> This statement goes further than 5085. >> I would like to see people explicitly express support for this. >> =20 >> If the c-bit is not set, >> indicating that the control word is not in use, type 4 MUST >> be advertised, and type 1 MUST NOT be advertised. >> Sorry, but I strongly disagree here!!!!!!!!!!! >> By a show of hands at the last meeting people agreed that router = alert could be eliminated. >> However, it was NOT agreed that TTL expiry was to be eliminated =96 = quite the contrary! >> So, without CW there are 2 options =96 the presently available and = deployed one of using TTL >> and this new one. >> The requirement to support this mode ONLY has NOT received consensus = from the WG. >>=20 >=20 > Similarly, this seems to contradict the actual document scope. We = discussed the best approach for "unification" in Paris and subsequently = on email, and it is closer to doing a 5085bis than having a document = that does not update to redefine. I object to VCCV-for-GAL going beyond = VCCV for GAL. >=20 > As it stands, I do not support this document move forward as is. >=20 > Thanks, >=20 > -- Carlos. >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_1ABADA6C-26E6-4D48-8CC4-7BF78E3C65C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 = Generic statements like this are not useful at this point in the = process; please be specific and what you object to and what changes you = propose to correct them. This will allow the WG to discuss any changes = on the list if they are major. What we want to avoid is making changes = on the same issue multiple times due to multiple conflicting change = requests, or attempting to fix generic = comments. 

    = --Tom

    Do not support as in the = current form document goes beyond=20 mere definition of the new Control Channel type for = VCCV.
    And concur with concerns = expressed by Yaacov and=20 Carlos.
     
        Regards,
            = Greg

    From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos=20 Pignataro
    Sent: Friday, May 25, 2012 7:15 AM
    To: = Yaakov=20 Stein; pwe3@ietf.org
    Subject: Re: = [PWE3] WG Last Call for=20 draft-ietf-pwe3-vccv-for-gal-01.txt

    PWE3ers,

    I too have strong concerns about this document being WGLCed.

    A meta-concern centers around the scope of this document. My = understanding=20 (and please correct this with a citation if I am incorrect) is that = there was=20 consensus for this document to define a new CC Type 4 using GAL, but = there was=20 not consensus to have this document redefine all Control Channels and = their=20 requirement levels (i.e., deprecating or creating rules of = use). 

    =46rom the minutes at http://tools.ietf.org/wg/pw= e3/minutes we=20 can see that:
             =
 20 min - General discussion on VCCV for =
GAL
          There appear to be two separate issues on the table:
          1. VCCV support for a PW associated channel that =
uses the GAL as an
          alert mechanisms (VCCV Type 4). This is really the subject of =
the draft.
          2. What to do about legacy modes, particularly =
router alert and TTL
          expiry. This is a separate issue regarding the progress of RFC5085
          (or some future RFC) to Internet Standard status.

    And this I-D should only deal with issue #1 but not #2. This is = also clear=20 from the filename "vccv-for-gal", which was changed from the "vccv-2" of = the=20 individual submission to make very explicitly clear this scope.

    However, the title of this I-D is still "Unified Control = Channel".

    Additionally I would like to highlight in agreement two issues that = Yaakov=20 brought up.

    On May 25, 2012, at 8:09 AM, Yaakov Stein wrote:

    My=20 comments. Most are editorial (some of the document seems to have been = written=20 in haste)

    I believe that the number of editorial issues actually amount to = technical=20 concerns. For example, the Title, Abstract, and Introduction speak of = things in=20 the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 and = 2 and=20 the Acronyms even repeats unused ones (L2SS, LCCE are meaningless and = unused in=20 this doc).

    =46rom my perspective, the collection of these editorials amount to = a=20 blocking comment.


     
      If the c-bit is =
set,
      indicating the =
use of the control word, type 1 MUST be =
advertised
      and type 4 MUST =
NOT be advertised.
    Although I personally prefer using =
type 1 if there IS a CW,
    I do not recall =
hearing WG consensus on this.
    This =
statement goes further than 5085.
    I would =
like to see people explicitly express support for =
this.
     
      If the c-bit is not set,
      indicating that the control word is not in use, type 4 =
MUST
      be advertised, =
and type 1 MUST NOT be advertised.
    Sorry, =
but I strongly disagree here!!!!!!!!!!!
    By a show =
of hands at the last meeting people agreed that router alert could be =
eliminated.
    However, it was NOT agreed that TTL =
expiry was to be eliminated =96 quite the =
contrary!
    So, without CW there are 2 options =96 =
the presently available and deployed one of using =
TTL
    and this new =
one.
    The requirement to support this mode =
ONLY has NOT received consensus from the WG.


    Similarly, this seems to contradict the actual document scope. We = discussed=20 the best approach for "unification" in Paris and subsequently on email, = and it=20 is closer to doing a 5085bis than having a document that does not update = to=20 redefine. I object to VCCV-for-GAL going beyond VCCV for GAL.

    As it stands, I do not support this document move forward as = is.

    Thanks,

    -- Carlos.



    _______________________________________________
    pwe3 mailing = list
    pwe3@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/pwe3

    = --Apple-Mail=_1ABADA6C-26E6-4D48-8CC4-7BF78E3C65C2-- From gregory.mirsky@ericsson.com Tue May 29 11:54:31 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F7B11E812D for ; Tue, 29 May 2012 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 syp319-RWgRS for ; Tue, 29 May 2012 11:54:27 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B68B811E8131 for ; Tue, 29 May 2012 11:54:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4TIsFjk000840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 May 2012 13:54:18 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 29 May 2012 14:54:15 -0400 From: Gregory Mirsky To: Thomas Nadeau Date: Tue, 29 May 2012 14:54:12 -0400 Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac09mivRaMWuEPosQq+Yllgc5C0JbwAJEOaQ Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> <5E889EDF-82C4-4B32-BBBA-D5C8AE3A5A2A@lucidvision.com> In-Reply-To: <5E889EDF-82C4-4B32-BBBA-D5C8AE3A5A2A@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_" MIME-Version: 1.0 Cc: Carlos Pignataro , Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:54:31 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Tom, apologies and please find my comments below (some if not most might duplica= te what already was noted by Yaacov and Carlos): * Abstract "This document describes a unified mode of operation for Virtual C= ircuit Connectivity Verification (VCCV) ..." IMHO, agreement of WG discussi= on in Paris was to limit document scope to introduction of Control Channel = Type 4 for PW VCCV and address unified operation of CC VCCV in RFC 5085bis. * Abstract "The older types will remain optional." IMHO, the WG agreed to ob= solete Type 2 CC PW VCCV. * Introduction "This document and the implementation survey concluded ...": * "This document" as A Unified Control Channel for Pseudowires? * Besides, I believe that if the acceptance of Mandatory Use of Control Word = for PWE3 Encapsulations will make draft-ietf-pwe3-vccv-for-gal- unnecessary= . Reference to the implementation survey draft-ietf-pwe3-vccv-impl-survey-r= esults-00 is missing. * I don't see that the "The Pseudowire (PW) & Virtual Circuit Connectivity Ve= rification (VCCV) Implementation Survey Results" made suggested conclusion. * Introduction "... the ITU-T and IETF have set out to enhance MPLS to make i= t suitable as an optical transport protocol ..." Perhaps should be "packet = transport". * Introduction "In order to support VCCV when an MPLS-TP PSN is in use, the G= AL-ACH had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW= VCCV when PSN is MPLS-TP can use any of described in RFC 5085 control chan= nel types. * Introduction "This document defines two modes of operation of VCCV ..." Whe= re the document leaves CC Type 3? Isn't it valid mode of PW VCCV operation = that the PWE3 WG decided to keep? * Introduction "In either case, it will be mandatory to implement and use tha= t mode under that scenario." Again, this conclusion is not in sync with wha= t was agreed at PWE3 WG meeting in Paris. * Section 2 "... Associated Channel Types of 21, 07, or 57 are allowed" First= ly, it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A, 0x000B, = 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, and= 0x0058 would not be listed as valid ACH types? * Section 3 "In the case of multi-segment pseudo-wires, the PW Label TTL MUST= be set to the correct value to reach the intended destination PE as descri= bed in [RFC6073]" This seems to exclude= VCCV CC Type 3 from being used in conjunction with GAL even though Section= 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control Channel= s Type 1 and Type 3. * Section 3 "The GAL field ..." Generic Associated Channel Label (GAL) is not= a field but part of MPLS label stack entry. What are values of other field= s of the label stack entry with the GAL - TC, S, TTL? * Section 3 "The first nibble of the next field is set to 0001b ..." Does tha= t imply that GAL MUST be BOS label and thus S=3D1? * Section 4 "If the c-bit is not set, indicating that the control word is not= in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised." I t= hink that whether Type 4 MUST,SHALL or MAY be advertised (do not forget Typ= e 3), should be addressed in RFC 5085bis. Regards, Greg ________________________________ From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Tuesday, May 29, 2012 5:54 AM To: Gregory Mirsky Cc: Carlos Pignataro; Yaakov Stein; pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Generic statements like this are not useful at this point in the process; p= lease be specific and what you object to and what changes you propose to co= rrect them. This will allow the WG to discuss any changes on the list if th= ey are major. What we want to avoid is making changes on the same issue mul= tiple times due to multiple conflicting change requests, or attempting to f= ix generic comments. --Tom Do not support as in the current form document goes beyond mere definition = of the new Control Channel type for VCCV. And concur with concerns expressed by Yaacov and Carlos. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Carlos Pignataro Sent: Friday, May 25, 2012 7:15 AM To: Yaakov Stein; pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt PWE3ers, I too have strong concerns about this document being WGLCed. A meta-concern centers around the scope of this document. My understanding = (and please correct this with a citation if I am incorrect) is that there w= as consensus for this document to define a new CC Type 4 using GAL, but the= re was not consensus to have this document redefine all Control Channels an= d their requirement levels (i.e., deprecating or creating rules of use). >From the minutes at http://tools.ietf.org/wg/pwe3/minutes we can see that: 20 min - Genera= l discussion on VCCV for GAL There appear to be two separate issues on the table: 1. VCCV support = for a PW associated channel that uses the GAL as an alert mechanisms (VCCV Type 4). This is really the subject of the= draft. 2. What to do ab= out legacy modes, particularly router alert and TTL expiry. This is a separate issue regarding the progress of RFC508= 5 (or some future RFC) to Internet Standard status. And this I-D should only deal with issue #1 but not #2. This is also clear = from the filename "vccv-for-gal", which was changed from the "vccv-2" of th= e individual submission to make very explicitly clear this scope. However, the title of this I-D is still "Unified Control Channel". Additionally I would like to highlight in agreement two issues that Yaakov = brought up. On May 25, 2012, at 8:09 AM, Yaakov Stein wrote: My comments. Most are editorial (some of the document seems to have been wr= itten in haste) I believe that the number of editorial issues actually amount to technical = concerns. For example, the Title, Abstract, and Introduction speak of thing= s in the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 a= nd 2 and the Acronyms even repeats unused ones (L2SS, LCCE are meaningless = and unused in this doc). >From my perspective, the collection of these editorials amount to a blockin= g comment. If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised. Although I personally prefer using type 1 if there IS a CW, I do not recall hearing WG consensus on this. This statement goes further than 5085. I would like to see people explicitly express support for this. If the c-bit is not set, indicating that the control word is not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised. Sorry, but I strongly disagree here!!!!!!!!!!! By a show of hands at the last meeting people agreed that router alert coul= d be eliminated. However, it was NOT agreed that TTL expiry was to be eliminated - quite the= contrary! So, without CW there are 2 options - the presently available and deployed o= ne of using TTL and this new one. The requirement to support this mode ONLY has NOT received consensus from t= he WG. Similarly, this seems to contradict the actual document scope. We discussed= the best approach for "unification" in Paris and subsequently on email, an= d it is closer to doing a 5085bis than having a document that does not upda= te to redefine. I object to VCCV-for-GAL going beyond VCCV for GAL. As it stands, I do not support this document move forward as is. Thanks, -- Carlos. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Dear Tom,
    apologies and please find my comments below (som= e if=20 not most might duplicate what already was noted by Yaacov and=20 Carlos):
    • Abstract "This document describes a unified mo= de of=20 operation for Virtual Circuit Connectivity Verification (VCCV) ..." = IMHO,=20 agreement of WG discussion in Paris was to limit document scope to=20 introduction of Control Channel Type 4 for PW VCCV and address unified=20 operation of CC VCCV in RFC 5085bis.
    • &n= bsp;Abstract=20 "The older types will remain optional." IMHO, the WG agreed to obsolete T= ype 2=20 CC PW VCCV.
    • Introduction "This document and the implementation survey conclu= ded=20 ...":
      • "This document" as A Unified = Control=20 Channel for Pseudowires?
      • Besides, I believe that if th= e=20 acceptance of Mandatory Use of Control Word for PWE3=20 Encapsulations will make draft-ietf-pwe3-vccv-for-gal- unnecessary.=20 Reference to the implementation survey=20 draft-ietf-pwe3-vccv-impl-survey-results-00 is=20 missing.
      • I don't see = that the=20 "The Pseudowire (PW) & Virtual Circuit Connectivit= y=20 Verification (VCCV) Implementation Survey Resul= ts"=20 made suggested conclusion.
    • Introduction = "... the=20 ITU-T and IETF have set out to enhance MPLS to make it suitable as=20 an optical transport protocol ..." Perhaps should be "packet=20 transport".
    • Introduction "In order to support VCCV when an MPLS-TP PSN is in= use,=20 the GAL-ACH had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW VCCV when PSN= is=20 MPLS-TP can use any of described in RFC 5085 control channel=20 types.
    • Introduction "This document defines two modes of operation of VC= CV ..."=20 Where the document leaves CC Type 3? Isn't it valid mode of PW VCCV opera= tion=20 that the PWE3 WG decided to keep?
    • Introduction "In either case, it will be mandatory to implement = and use=20 that mode under that scenario." Again, this conclusion is not in syn= c=20 with what was agreed at PWE3 WG meeting in Paris.
    • Section 2 "... Associated Channel Types of 21, 07, or 57 are all= owed"=20 Firstly, it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A,=20 0x000B, 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026,=20 0x0027, and 0x0058 would not be listed as valid ACH=20 types?
    • Section 3 "In the case of multi-segment pseudo-wires, the PW Lab= el TTL=20 MUST be set to the correct value to reach the intended destination PE as= =20 described in [RFC6073]" This seems to e= xclude=20 VCCV CC Type 3 from being used in conjunction with GAL even though Sectio= n=20 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control Channe= ls=20 Type 1 and Type 3.
    • Section 3 "The GAL field ..." Generic Associated Channel Label (= GAL) is=20 not a field but part of MPLS label stack entry. What are values of other= =20 fields of the label stack entry with the GAL - TC, S,=20 TTL?
    • Section 3 "The first nibble of the next field is set to 0001b ..= ." Does=20 that imply that GAL MUST be BOS label and thus S=3D1?
      =
    • Section 4 "If the c-bit is not set, indicating that the control = word is=20 not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised.= " I=20 think that whether Type 4 MUST,SHALL or MAY be advertised (do not forget = Type=20 3), should be addressed in RFC 5085bis.
        Regards,
           =20 Greg
    From: Thoma= s Nadeau=20 [mailto:tnadeau@lucidvision.com]
    Sent: Tuesday, May 29, 2012 5:5= 4=20 AM
    To: Gregory Mirsky
    Cc: Carlos Pignataro; Yaakov Stei= n;=20 pwe3@ietf.org
    Subject: Re: [PWE3] WG Last Call for=20 draft-ietf-pwe3-vccv-for-gal-01.txt


    Generic= =20 statements like this are not useful at this point in the process; please be= =20 specific and what you object to and what changes you propose to correct the= m.=20 This will allow the WG to discuss any changes on the list if they are major= .=20 What we want to avoid is making changes on the same issue multiple times du= e to=20 multiple conflicting change requests, or attempting to fix generic=20 comments. 

    --Tom

    Do not support as in the current form document g= oes=20 beyond mere definition of the new Control Channel type for=20 VCCV.
    And concur with concerns expressed by Yaacov and= =20 Carlos.
     
      =  =20 Regards,
            Greg

    From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos=20 Pignataro
    Sent: Friday, May 25, 2012 7:15 AM
    To: Yaak= ov=20 Stein; pwe3@ietf.org
    Subject:<= /B> Re:=20 [PWE3] WG Last Call for=20 draft-ietf-pwe3-vccv-for-gal-01.txt

    PWE3ers,

    I too have strong concerns about this document being WGLCed.

    A meta-concern centers around the scope of this document. My=20 understanding (and please correct this with a citation if I am incorrect)= is=20 that there was consensus for this document to define a new CC Type 4 usin= g=20 GAL, but there was not consensus to have this document redefine all Contr= ol=20 Channels and their requirement levels (i.e., deprecating or creating rule= s of=20 use). 

    From the minutes at http://tools.ietf.org/wg/p= we3/minutes we=20 can see that:
              20 min - General discussion =
on VCCV for GAL
          There appear to be two separate issues on the table:
          1. VCCV support for a PW associated channel that uses the=
 GAL as an
          alert mechanisms (VCCV Type 4). This is really the subject of the=
 draft.
          2. What to do about legacy modes, particularly router ale=
rt and TTL
          expiry. This is a separate issue regarding the progress of RFC5085
          (or some future RFC) to Internet Standard status.

    And this I-D should only deal with issue #1 but not #2. This is also= =20 clear from the filename "vccv-for-gal", which was changed from the "vccv-= 2" of=20 the individual submission to make very explicitly clear this scope.

    However, the title of this I-D is still "Unified Control Channel".

    Additionally I would like to highlight in agreement two issues that= =20 Yaakov brought up.

    On May 25, 2012, at 8:09 AM, Yaakov Stein wrote:
    My=20 comments. Most are editorial (some of the document seems to have been=20 written in haste)

    I believe that the number of editorial issues actually amount to=20 technical concerns. For example, the Title, Abstract, and Introduction sp= eak=20 of things in the scope of a 5085bis. Moreover, the Introduction repeats=20 Figures 1 and 2 and the Acronyms even repeats unused ones (L2SS, LCCE are= =20 meaningless and unused in this doc).

    From my perspective, the collection of these editorials amount to a= =20 blocking comment.


     
      If the c-b=
it is set,
      indicating the use of the control wo=
rd, type 1 MUST be advertised
      and type 4 MUST N=
OT be advertised.
    Although I personally prefer using type 1 if there IS=
 a CW,
    I do not recall hearing WG consensus on this.<=
/PRE>
    This statement=
 goes further than 5085.
    I would like to see people explicitly express =
support for this.
     
      If the c-bit is no=
t set,
      indicating that the control word is not =
in use, type 4 MUST
    =
  be advertised, and type 1 M=
UST NOT be advertised.
    By a show of hands at the last meeting people agreed that router alert c=
ould be eliminated.
    =
However, it was NOT agreed that TTL expiry was to b=
e eliminated – quite the contrary!
    So, without CW there are 2 op=
tions – the presently available and deployed one of using TTL
    and=
 this new one.
    The requirement to support this mode ONLY has NOT receiv=
ed consensus from the WG.

    Similarly, this seems to contradict the actual document scope. We=20 discussed the best approach for "unification" in Paris and subsequently o= n=20 email, and it is closer to doing a 5085bis than having a document that do= es=20 not update to redefine. I object to VCCV-for-GAL going beyond VCCV for=20 GAL.

    As it stands, I do not support this document move forward as is.

    Thanks,

    -- Carlos.



    _______________________________________________
    p= we3=20 mailing list
    pwe3@ietf.org
    https://www.ietf.org/m= ailman/listinfo/pwe3

    --_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_-- From manap@intracom.gr Thu May 31 00:15:09 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289B621F863C for ; Thu, 31 May 2012 00:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[AWL=3.163, 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 Gov4AZUrGibf for ; Thu, 31 May 2012 00:15:07 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.gr [192.92.155.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0379821F8642 for ; Thu, 31 May 2012 00:15:04 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.14.4/8.13.8) with ESMTP id q4V7F1M7005777 for ; Thu, 31 May 2012 10:15:01 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id q4V7F1Ca018432 for ; Thu, 31 May 2012 10:15:01 +0300 (EEST) Received: from aurora.intranet.gr (aurora.intranet.GR [146.124.34.195]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id q4V7Ewb0018398 for ; Thu, 31 May 2012 10:14:58 +0300 (EEST) Received: from pcrh103.intranet.gr (pcrh103 [146.124.34.84]) by aurora.intranet.gr (8.8.8+Sun/8.8.8) with ESMTP id KAA05832 for ; Thu, 31 May 2012 10:02:40 +0300 (EET DST) Message-ID: <4FC71A3B.7020000@intracom.gr> Date: Thu, 31 May 2012 10:14:03 +0300 From: Apostolos Manolitzas Organization: INTRACOM TELECOM S.A. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: pwe3@ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Subject: [PWE3] Question about PW MIBs X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 07:15:09 -0000 Hello all, based on the RFC5604 there should exist MIBs in the service layer for the CESoPSN and TDMoIP module, but those where drafts that where deprecated. Is there any other standard option for them? What should be used for management? Some custom approach perhaps? Furthermore, there is nothing available for managing psn as Ethernet, even the IANAPwPsnTypeTC doesn't support the Ethernet as psn, why is that? Is there any standard/draft alternative MIB that should be used to fill the gap in the PSN layer? best regards, -Apostolos Manolitzas