From david.black@emc.com Sun Apr 1 02:33:01 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 7016C21F869F for ; Sun, 1 Apr 2012 02:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.999 X-Spam-Level: X-Spam-Status: No, score=-107.999 tagged_above=-999 required=5 tests=[BAYES_50=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 Mb9c3lDB4K7u for ; Sun, 1 Apr 2012 02:33:01 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id C82A421F867F for ; Sun, 1 Apr 2012 02:33:00 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q319Wu4F016141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Apr 2012 05:32:56 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Sun, 1 Apr 2012 05:32:44 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q319Wg5G024244 for ; Sun, 1 Apr 2012 05:32:43 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Sun, 1 Apr 2012 05:32:42 -0400 From: To: Date: Sun, 1 Apr 2012 05:32:40 -0400 Thread-Topic: fc-encap draft: Forthcoming reference changes Thread-Index: Ac0P6mIwrF9jl7jIQTaGS6Cg+to+Pw== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E807F9@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [PWE3] fc-encap draft: Forthcoming reference changes 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: Sun, 01 Apr 2012 09:33:01 -0000 This is a heads-up that the editing changes needed to get draft-ietf-pwe3-f= c-encap published are going to be a little more involved than I've lead the WG to e= xpect in the past. A reminder of the situation: The Fibre Channel pseudowire (FC PW) is specif= ied by a pair of related specifications, the IETF fc-encap draft, and an FC-BB-* s= pec from INCITS T11 (the Fibre Channel standards body). When we got the fc-encap dr= aft finished, we found ourselves badly out of sync with T11 - the draft contain= s a normative reference to [FC-BB-6] which will not be published as a standard = for a while to come (2013, maybe). As a result, the fc-encap draft has been stuc= k in reference wait at the RFC Editor (all other editing is done) for most of a = year. In order to deal with this situation, T11 has prepared a new standard that = contains their portion of the FC PW spec, FC-BB-5 Amendment 1 [FC-BB-5/AM1]. That s= tandard has now cleared its final technical approval stage and can be normatively r= eferenced (will be actually published in the next few months, but all the stages from= here are entirely procedural). The original plan was to simply change the normative= [FC-BB-6] reference in the fc-encap draft to [FC-BB-5/AM1], but ... FC-BB-6 is a large specification that includes other FC encapsulations in a= ddition to the FC-PW. In contrast, FC-BB-5 Amendment 1 has been cut down to just t= he FC PW material. In looking at the fc-encap draft, I've discovered that FC-BB-6 i= s cited both normatively and informatively in the text - the normative citations ar= e for the T11 portion of the FC PW, whereas the informative citations are for oth= er FC encapsulations (e.g., FCIP). Therefore what I intend to do is: - Move the existing [FC-BB-6] normative reference to an informative "work in progress" reference. - Add a new normative reference to [FC-BB-5/AM1] - Examine every current citation of [FC-BB-6] to determine whether it is normative for the FC PW (and needs to be changed to [FC-BB-5/AM1] vs. informative for other encapsulations (and needs to remain as a citation of [FC-BB-6]. The resulting editing instructions will take a bit of time to prepare, but = should go to the RFC Editor sometime this week. Thanks, --David (as one of the editors of the fc-encap draft, and T11's liaison to = IETF). ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From yaakov_s@rad.com Sun Apr 1 05:45:06 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 791AC21F95B5 for ; Sun, 1 Apr 2012 05:45:06 -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=[AWL=-0.000, 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 UgOcxv70bWwg for ; Sun, 1 Apr 2012 05:45:06 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5321F95CD for ; Sun, 1 Apr 2012 05:45:04 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 1 Apr 2012 15:35:36 +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; Sun, 1 Apr 2012 15:44:56 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: CW usage in opposite directions for static PWs Thread-Index: Ac0QBT4bYwJu0XdESV2fvjvH6qGlIA== Date: Sun, 1 Apr 2012 12:44:56 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904332092@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_07F7D7DED63154409F13298786A2ADC904332092EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090204.4F784DCE.00C1,ss=1,fgs=0 Subject: [PWE3] CW usage in opposite directions for static PWs 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: Sun, 01 Apr 2012 12:45:06 -0000 --_000_07F7D7DED63154409F13298786A2ADC904332092EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the meeting I promised to check when this issue in the subject line was = last discussed. It was only a short while ago in Prague (see http://www.ietf.org/proceeding= s/80/slides/pwe3-3.pdf slides 9 - 11). I recall a lively discussion after the presentation, but the minutes do not show resolution of the issue of whether a CW MUST be= used or not used in both directions for PWs not set up using the PWE3 control protocol. Y(J)S --_000_07F7D7DED63154409F13298786A2ADC904332092EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the meeting I promised to check when this issue i= n the subject line was last discussed.

 

It was only a short while ago in Prague (see http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11).

 

I recall a lively discussion after the presentation,=

but the minutes do not show resolution of the issue = of whether a CW MUST be used or not used

in both directions for PWs not set up using the PWE3= control protocol.

 

Y(J)S

 

--_000_07F7D7DED63154409F13298786A2ADC904332092EXRAD5adradcoil_-- From amalis@gmail.com Sun Apr 1 15:20:37 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 9A2EF21F876F for ; Sun, 1 Apr 2012 15:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 6wJ4CRoqEmIM for ; Sun, 1 Apr 2012 15:20:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8054011E8085 for ; Sun, 1 Apr 2012 15:20:36 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1076175ghb.31 for ; Sun, 01 Apr 2012 15:20:36 -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 :cc:content-type; bh=pxjAvze4oIysDnJytnka9c2XrCBhU7gwH6c19WWji6U=; b=Mcl/p7VT1UbVFpd0feCvgwPVReqqqh5Lu4irbDlM+UeCsQ7N7ik/Jdyu20MIII1zWS R/rvxCZx99NHR4ssF/wZt2fug6RDCBt4micvJQsrX1S9xYcIWJ4se9xqEhzqtdTb4ct6 GLmNYdoh/PqRG3rhCnqrfuFWJobt8hwPoO7fNtpFuH/Hstu3k8FRDFjyUhRsJmAzwulf jpDFwn9gpFb4GkuEFKiSIJ+Oxe+irWpj74bO6Hk2ktk0nc58u2fSXT7DfMmjm2sPsCVl 72OB33HuI0k4/i5OlWctq66qVpP5NvEOM2TCzPJS+PcKhGT/srgOGFhtFrJLwlnJVlv0 +31A== Received: by 10.236.115.3 with SMTP id d3mr4992078yhh.49.1333318835938; Sun, 01 Apr 2012 15:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.22.196 with HTTP; Sun, 1 Apr 2012 15:20:15 -0700 (PDT) In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E807F9@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2E807F9@MX14A.corp.emc.com> From: "Andrew G. Malis" Date: Sun, 1 Apr 2012 23:20:15 +0100 Message-ID: To: david.black@emc.com Content-Type: multipart/alternative; boundary=20cf303bf54e96a3c504bca57b86 Cc: pwe3@ietf.org Subject: Re: [PWE3] fc-encap draft: Forthcoming reference changes 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: Sun, 01 Apr 2012 22:20:37 -0000 --20cf303bf54e96a3c504bca57b86 Content-Type: text/plain; charset=ISO-8859-1 David, Thanks much for the update and keeping on top of this. Cheers, Andy On Sun, Apr 1, 2012 at 10:32 AM, wrote: > This is a heads-up that the editing changes needed to get > draft-ietf-pwe3-fc-encap > published are going to be a little more involved than I've lead the WG to > expect > in the past. > > A reminder of the situation: The Fibre Channel pseudowire (FC PW) is > specified by > a pair of related specifications, the IETF fc-encap draft, and an FC-BB-* > spec from > INCITS T11 (the Fibre Channel standards body). When we got the fc-encap > draft > finished, we found ourselves badly out of sync with T11 - the draft > contains a > normative reference to [FC-BB-6] which will not be published as a standard > for a > while to come (2013, maybe). As a result, the fc-encap draft has been > stuck in > reference wait at the RFC Editor (all other editing is done) for most of a > year. > > In order to deal with this situation, T11 has prepared a new standard that > contains > their portion of the FC PW spec, FC-BB-5 Amendment 1 [FC-BB-5/AM1]. That > standard > has now cleared its final technical approval stage and can be normatively > referenced > (will be actually published in the next few months, but all the stages > from here are > entirely procedural). The original plan was to simply change the > normative [FC-BB-6] > reference in the fc-encap draft to [FC-BB-5/AM1], but ... > > FC-BB-6 is a large specification that includes other FC encapsulations in > addition > to the FC-PW. In contrast, FC-BB-5 Amendment 1 has been cut down to just > the FC PW > material. In looking at the fc-encap draft, I've discovered that FC-BB-6 > is cited > both normatively and informatively in the text - the normative citations > are for > the T11 portion of the FC PW, whereas the informative citations are for > other FC > encapsulations (e.g., FCIP). Therefore what I intend to do is: > - Move the existing [FC-BB-6] normative reference to an informative "work > in progress" reference. > - Add a new normative reference to [FC-BB-5/AM1] > - Examine every current citation of [FC-BB-6] to determine whether it is > normative for the FC PW (and needs to be changed to [FC-BB-5/AM1] > vs. informative for other encapsulations (and needs to remain as a > citation of [FC-BB-6]. > The resulting editing instructions will take a bit of time to prepare, but > should > go to the RFC Editor sometime this week. > > Thanks, > --David (as one of the editors of the fc-encap draft, and T11's liaison to > IETF). > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --20cf303bf54e96a3c504bca57b86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David,

Thanks much for the update and keeping on top of this.
Cheers,
Andy

On Sun, Apr 1, 2012 at 1= 0:32 AM, <davi= d.black@emc.com> wrote:
This is a heads-up that the editing changes = needed to get draft-ietf-pwe3-fc-encap
published are going to be a little more involved than I've lead the WG = to expect
in the past.

A reminder of the situation: The Fibre Channel pseudowire (FC PW) is specif= ied by
a pair of related specifications, the IETF fc-encap draft, and an FC-BB-* s= pec from
INCITS T11 (the Fibre Channel standards body). =A0When we got the fc-encap = draft
finished, we found ourselves badly out of sync with T11 - the draft contain= s a
normative reference to [FC-BB-6] which will not be published as a standard = for a
while to come (2013, maybe). =A0As a result, the fc-encap draft has been st= uck in
reference wait at the RFC Editor (all other editing is done) for most of a = year.

In order to deal with this situation, T11 has prepared a new standard that = contains
their portion of the FC PW spec, FC-BB-5 Amendment 1 [FC-BB-5/AM1]. =A0That= standard
has now cleared its final technical approval stage and can be normatively r= eferenced
(will be actually published in the next few months, but all the stages from= here are
entirely procedural). =A0The original plan was to simply change the normati= ve [FC-BB-6]
reference in the fc-encap draft to [FC-BB-5/AM1], but ...

FC-BB-6 is a large specification that includes other FC encapsulations in a= ddition
to the FC-PW. =A0In contrast, FC-BB-5 Amendment 1 has been cut down to just= the FC PW
material. =A0In looking at the fc-encap draft, I've discovered that FC-= BB-6 is cited
both normatively and informatively in the text - the normative citations ar= e for
the T11 portion of the FC PW, whereas the informative citations are for oth= er FC
encapsulations (e.g., FCIP). =A0Therefore what I intend to do is:
- Move the existing [FC-BB-6] normative reference to an informative "w= ork
=A0 =A0 =A0 =A0in progress" reference.
- Add a new normative reference to [FC-BB-5/AM1]
- Examine every current citation of [FC-BB-6] to determine whether it is =A0 =A0 =A0 =A0normative for the FC PW (and needs to be changed to [FC-BB-= 5/AM1]
=A0 =A0 =A0 =A0vs. informative for other encapsulations (and needs to rema= in as a
=A0 =A0 =A0 =A0citation of [FC-BB-6].
The resulting editing instructions will take a bit of time to prepare, but = should
go to the RFC Editor sometime this week.

Thanks,
--David (as one of the editors of the fc-encap draft, and T11's liaison= to IETF).
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508)= 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7786
david.black@emc.com=A0=A0=A0=A0= =A0=A0=A0 Mobile: +1 (978) 394-7754
----------------------------------------------------


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

--20cf303bf54e96a3c504bca57b86-- From david.sinicrope@gmail.com Mon Apr 2 13:03: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 2255F21F85C7 for ; Mon, 2 Apr 2012 13:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wftShDtnSxC for ; Mon, 2 Apr 2012 13:03:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE84921F85CE for ; Mon, 2 Apr 2012 13:03:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so1621417yen.31 for ; Mon, 02 Apr 2012 13:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=HiiR/CUJlHfooKsrpP5koKdH+xYz8kE3HnZ/ok1gtB8=; b=C9YOONdfj3paI6ki+dZ79vt2kKemeh9o0ydV7TlqHD+Oriw7br60zmUUGo2oXhTD2f WcQl0wWnTLSBQ+d0vOTfgFjJHR2jOtxterzL3VFUQ3VU96dl27dHUxnqxsENv+2Lv10Q z54x++y7OUefClq31K6qVM2Ol5dgtp8Y/Ywz8zEi0oh1lNobwoNC7skKlIAKHAebH4bl nWxNpN3jsRVdzHY0iWXHAP7NluZbX10ars3Hln3oAsvuvFZrRMxnLpWzZTNT7x3IqTIH aMCZJKg/x9ochLkO6tGhgDkxJXPY3+3eiFFkJ6MG2hCgBWz/8O3AyB8ut0pxeaX66hww kbiw== Received: by 10.236.193.36 with SMTP id j24mr8279854yhn.34.1333396984564; Mon, 02 Apr 2012 13:03:04 -0700 (PDT) Received: from [192.168.3.5] (cpe-069-134-223-155.nc.res.rr.com. [69.134.223.155]) by mx.google.com with ESMTPS id n24sm52462776yhj.13.2012.04.02.13.03.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:03:02 -0700 (PDT) References: <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-8C93C300-79C0-49EB-9113-25405107E71E Message-Id: <5FDF996A-820E-4B13-84E7-4CF07C0684E7@gmail.com> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (9B176) From: David Sinicrope Date: Mon, 2 Apr 2012 16:03:03 -0400 To: Yaakov Stein Cc: "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 02 Apr 2012 20:03:08 -0000 --Apple-Mail-8C93C300-79C0-49EB-9113-25405107E71E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yaakov, Im gurssing you are referring tothe "CW Usage" part of your presentation. T= he minutes reflect there was no conclusion from the discussion, I.e. "Take i= t to the list". I haven't seen the archive to see if there was a definitive= outcome. Dave Sent from my iPad. Please excuse abbreviations, terse replies, and auto-corr= ect errors. On Apr 1, 2012, at 8:44, Yaakov Stein wrote: > At the meeting I promised to check when this issue in the subject line was= last discussed. > =20 > It was only a short while ago in Prague (see http://www.ietf.org/proceedin= gs/80/slides/pwe3-3.pdf slides 9 - 11). > =20 > I recall a lively discussion after the presentation, > but the minutes do not show resolution of the issue of whether a CW MUST b= e used or not used > in both directions for PWs not set up using the PWE3 control protocol. > =20 > Y(J)S > =20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-8C93C300-79C0-49EB-9113-25405107E71E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hi Yaakov,
Im gurssing you are referring tothe "CW Usage" part of your presentation.  The minutes reflect there was no conclusion from the discussion, I.e. "Take it to the list".  I haven't seen the archive to see if there was a definitive outcome.
Dave

Sent from my iPad. Please excuse abbreviations, terse replies, and auto-correct errors.

On Apr 1, 2012, at 8:44, Yaakov Stein <yaakov_s@rad.com> wrote:

At the meeting I promised to check when this issue in the subject line was last discussed.

 

It was only a short while ago in Prague (see http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11).

 

I recall a lively discussion after the presentation,

but the minutes do not show resolution of the issue of whether a CW MUST be used or not used

in both directions for PWs not set up using the PWE3 control protocol.

 

Y(J)S

 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
--Apple-Mail-8C93C300-79C0-49EB-9113-25405107E71E-- From yshen@juniper.net Mon Apr 2 15:41: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 2461421F85ED for ; Mon, 2 Apr 2012 15:41:59 -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 u-M5PBOo0zRY for ; Mon, 2 Apr 2012 15:41:58 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id DC86621F85D6 for ; Mon, 2 Apr 2012 15:41:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT3orLETs8IrEHyVpsYVJGHyInNqKjmne@postini.com; Mon, 02 Apr 2012 15:41:56 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 15:41:48 -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; Mon, 2 Apr 2012 18:41:47 -0400 From: Yimin Shen To: "draft-shen-pwe3-endpoint-fast-protection@tools.ietf.org" Date: Mon, 2 Apr 2012 18:41:44 -0400 Thread-Topic: clarification on draft-shen-pwe3-endpoint-fast-protection Thread-Index: Ac0RIceimIGYuhmjS36uZMx4y1+LCQ== Message-ID: 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@ietf.org" Subject: [PWE3] clarification on draft-shen-pwe3-endpoint-fast-protection 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, 02 Apr 2012 22:41:59 -0000 Hi, I'd like thank all your valuable comments on this draft during IETF. This e= mail is a follow-up to the discussions. What this draft specifies is a local repair mechanism that can be used by a= router (i.e. PLR) immediately upstream of a PW egress endpoint failure to = protect PW traffic. Essentially, the PLR sets up a bypass tunnel (of any ty= pe, such as MPLS tunnel) to a protector, in anticipation of a failure. When= the failure happens, the PLR will simply redirect PW packets to the protec= tor via this bypass tunnel. The PW packets will have the original PW label = unchanged. Hence, the protector will forward the packets to the target CE b= ased the PW label (i.e. upstream assigned label) by using the context-speci= fic label switching technique.=20 The advantage of this local repair mechanism is the capability of fast rest= oration in the order of 10s of milliseconds. This is because both failure d= etection and packet redirection are performed at the PLR that is directly a= djacent to the failure. Of course, since there is a link/node failure in the network, global repair= (i.e. reroute of transport tunnel or switch to a backup tunnel by ingress = PE) or control-plane repair (i.e. reroute of transport tunnel by intermedia= te transit router) may also follow the failure event. However, these proced= ures are driven by routers that are not adjacent to the failure, and they m= ay dependent on control plane convergence. Therefore, they are relatively s= low, compared to the local repair mechanism.=20 Note that before a global repair or control-plane repair takes an effect, P= W traffic is protected by the local repair mechanism without any loss. IOW,= PW traffic continues to flow over the original transport tunnel to the PLR= where it then flows over the bypass tunnel to the protector and then towar= ds the CE.=20 When the global repair or control-plane repair kicks in, PW traffic will be= switched to use a new transport tunnel or a new path, and traffic over the= bypass tunnel will drain out eventually. In this case, packet re-ordering = may occur before the PW packets completely drain out over the bypass tunnel= . However, this is not an issue specific to this local repair mechanism, bu= t rather a common/generic issue when traffic is switched from one transport= tunnel to another transport tunnel. IOW, a short window is always needed f= or the traffic to drain out over the old tunnel. Therefore, it should not b= e considered as an issue of this draft. Hope I have clarified the difference and relationship between local repair = and global/control-plain repair.=20 Please continue to provide your comments and suggestions through email. Tha= nks in advance! Thanks, -Yimin Shen Juniper Networks From yshen@juniper.net Mon Apr 2 15:49: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 D0EE621F8715 for ; Mon, 2 Apr 2012 15:49:05 -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 IBSCLme-S+DV for ; Mon, 2 Apr 2012 15:49:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id E2BC621F8714 for ; Mon, 2 Apr 2012 15:49:04 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT3os4GApKzb2jnyb5oqZe88/le6MUqqU@postini.com; Mon, 02 Apr 2012 15:49:04 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 15:49:02 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Apr 2012 15:49:02 -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; Mon, 2 Apr 2012 18:49:01 -0400 From: Yimin Shen To: "pwe3@ietf.org" Date: Mon, 2 Apr 2012 18:49:00 -0400 Thread-Topic: clarification on draft-shen-pwe3-endpoint-fast-protection Thread-Index: Ac0RIstQLjk6VEwUR3qxpzBFzunwJA== Message-ID: 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_DF7F294AF4153D498141CBEFADB17704C70D88E73BEMBX01WFjnprn_" MIME-Version: 1.0 Subject: [PWE3] clarification on draft-shen-pwe3-endpoint-fast-protection 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, 02 Apr 2012 22:49:06 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C70D88E73BEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like thank all your valuable comments on this draft during IETF. This e= mail is a follow-up to the discussions. What this draft specifies is a local repair mechanism that can be used by a= router (i.e. PLR) immediately upstream of a PW egress endpoint failure to = protect PW traffic. Essentially, the PLR sets up a bypass tunnel (of any ty= pe, such as MPLS tunnel) to a protector, in anticipation of a failure. When= the failure happens, the PLR will simply redirect PW packets to the protec= tor via this bypass tunnel. The PW packets will have the original PW label = unchanged. Hence, the protector will forward the packets to the target CE b= ased the PW label (i.e. upstream assigned label) by using the context-speci= fic label switching technique. The advantage of this local repair mechanism is the capability of fast rest= oration in the order of 10s of milliseconds. This is because both failure d= etection and packet redirection are performed at the PLR that is directly a= djacent to the failure. Of course, since there is a link/node failure in the network, global repair= (i.e. reroute of transport tunnel or switch to a backup tunnel by ingress = PE) or control-plane repair (i.e. reroute of transport tunnel by intermedia= te transit router) may also follow the failure event. However, these proced= ures are driven by routers that are not adjacent to the failure, and they m= ay dependent on control plane convergence. Therefore, they are relatively s= low, compared to the local repair mechanism. Note that before a global repair or control-plane repair takes an effect, P= W traffic is protected by the local repair mechanism without any loss. IOW,= PW traffic continues to flow over the original transport tunnel to the PLR= where it then flows over the bypass tunnel to the protector and then towar= ds the CE. When the global repair or control-plane repair kicks in, PW traffic will be= switched to use a new transport tunnel or a new path, and traffic over the= bypass tunnel will drain out eventually. In this case, packet re-ordering = may occur before the PW packets completely drain out over the bypass tunnel= . However, this is not an issue specific to this local repair mechanism, bu= t rather a common/generic issue when traffic is switched from one transport= tunnel to another transport tunnel. IOW, a short window is always needed f= or the traffic to drain out over the old tunnel. Therefore, it should not b= e considered as an issue of this draft. Hope I have clarified the difference and relationship between local repair = and global/control-plain repair. Please continue to provide your comments and suggestions through email. Tha= nks in advance! Thanks, -Yimin Shen Juniper Networks --_000_DF7F294AF4153D498141CBEFADB17704C70D88E73BEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'd like thank all your valuable comments on this draft during IETF. T= his email is a follow-up to the discussions.
 
What this draft specifies is a local repair mechanism that can be used= by a router (i.e. PLR) immediately upstream of a PW egress endpoint failur= e to protect PW traffic. Essentially, the PLR sets up a bypass tunnel (of a= ny type, such as MPLS tunnel) to a protector, in anticipation of a failure. When the failure happens, the PL= R will simply redirect PW packets to the protector via this bypass tunnel. = The PW packets will have the original PW label unchanged. Hence, the protec= tor will forward the packets to the target CE based the PW label (i.e. upstream assigned label) by using th= e context-specific label switching technique.
 
The advantage of this local repair mechanism is the capability of fast= restoration in the order of 10s of milliseconds. This is because both fail= ure detection and packet redirection are performed at the PLR that is direc= tly adjacent to the failure.
 
Of course, since there is a link/node failure in the network, global r= epair (i.e. reroute of transport tunnel or switch to a backup tunnel by ing= ress PE) or control-plane repair (i.e. reroute of transport tunnel by inter= mediate transit router) may also follow the failure event. However, these procedures are driven by routers t= hat are not adjacent to the failure, and they may dependent on control plan= e convergence. Therefore, they are relatively slow, compared to the local r= epair mechanism.
 
Note that before a global repair or control-plane repair takes an effe= ct, PW traffic is protected by the local repair mechanism without any loss.= IOW, PW traffic continues to flow over the original transport tunnel to th= e PLR where it then flows over the bypass tunnel to the protector and then towards the CE.
 
When the global repair or control-plane repair kicks in, PW traffic wi= ll be switched to use a new transport tunnel or a new path, and traffic ove= r the bypass tunnel will drain out eventually. In this case, packet re-orde= ring may occur before the PW packets completely drain out over the bypass tunnel. However, this is not an issue = specific to this local repair mechanism, but rather a common/generic issue = when traffic is switched from one transport tunnel to another transport tun= nel. IOW, a short window is always needed for the traffic to drain out over the old tunnel. Therefore, it shou= ld not be considered as an issue of this draft.
 
Hope I have clarified the difference and relationship between local re= pair and global/control-plain repair.
 
Please continue to provide your comments and suggestions through email= . Thanks in advance!
 
 
 
Thanks,
 
-Yimin Shen
Juniper Networks
 
 --_000_DF7F294AF4153D498141CBEFADB17704C70D88E73BEMBX01WFjnprn_-- From stbryant@cisco.com Thu Apr 5 09:57: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 C4FD921F86D8 for ; Thu, 5 Apr 2012 09:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 mxFGqdnatSQ8 for ; Thu, 5 Apr 2012 09:57:25 -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 EEC7921F8680 for ; Thu, 5 Apr 2012 09:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=181; q=dns/txt; s=iport; t=1333645045; x=1334854645; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fguWu6ZkZmBLq9k1q1mgD0LBgmEpaFfp5KyRq7TCqtE=; b=Ak9NcVF5QEJAQJMjLF3vlZOp1nqTk1nfa5W21/FtlKANwTCivc6fcUW/ dcNaQNulyQ1fP5WPw9ZdrbIsa3shSUOW6ff4jKEOKfTFEmsLixFvgiZNL ykXGikilLxW6DkLCx1kYcO/UGSL1nPOYTp3mrQwwPoWcQll06dhDmMO7I 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADbOfU+Q/khR/2dsb2JhbABFuHCBB4IKAQEEEgECI0ABEAshFgQLCQMCAQIBRQYNAQcBAR6HbJsOgzwQnCOQWgSVa45LgQJngmg X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="134422886" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2012 16:57:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q35GvJCJ022933; Thu, 5 Apr 2012 16:57:19 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-107-147.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q35GvH9A028250; Thu, 5 Apr 2012 17:57:18 +0100 (BST) Message-ID: <4F7DCEED.9020209@cisco.com> Date: Thu, 05 Apr 2012 17:57:17 +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: "Aissaoui, Mustapha (Mustapha)" References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD59605CD@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD59605CD@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'draft-ietf-pwe3-redundancy-bit@tools.ietf.org'" , "'pwe3@ietf.org'" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard 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, 05 Apr 2012 16:57:25 -0000 This draft had a bunch of comments in IETF LC I have marked it as needing a revised draft. When you have picked up all the comments, I will move the draft forward. Stewart From stbryant@cisco.com Thu Apr 5 10:02: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 A5C6D21F86DF; Thu, 5 Apr 2012 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 iBffbiD5jm0U; Thu, 5 Apr 2012 10:02:28 -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 4D1AC21F8648; Thu, 5 Apr 2012 10:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3344; q=dns/txt; s=iport; t=1333645348; x=1334854948; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rAPEzZXb4tzeoXKa08Qn+Y+j+LGaIYaHJqzFXK4VNcI=; b=VxDD1E0eCo13r6jFbdxfJvXz4s8YdbUzbaWIfON583iIrQzYqeBp39pj kXxQ7i1yxgfyjhnug/X0dIPKXy7n4AIMv3DgMdRoE8Hav6J6KZZXKb2t/ 5K/RUq1Ndzb0fx7WZj2bchxZG2e1yDOHBTykV27Rt4/ejXr37/alnI8cr I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD7PfU+Q/khR/2dsb2JhbABFhW+zAIEHggkBAQEEEgECDhVAARALFAQCAgUWCwICCQMCAQIBRQYNAQcBAR6HbAubA4M8EIk8kmeBL44TgRgElWuBEY06gQJngmg X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="134423395" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2012 17:02:27 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q35H2RQg023880; Thu, 5 Apr 2012 17:02:27 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-107-147.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q35H2PVe028809; Thu, 5 Apr 2012 18:02:25 +0100 (BST) Message-ID: <4F7DD021.4070807@cisco.com> Date: Thu, 05 Apr 2012 18:02:25 +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: Martin Thomson References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pwe3-redundancy.all@tools.ietf.org, gen-art@ietf.org, pwe3 , IETF Discussion Subject: Re: [PWE3] GenART review of draft-ietf-pwe3-redundancy-06 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, 05 Apr 2012 17:02:29 -0000 Authors Please can you answer or address these comments Thanks Stewart On 16/03/2012 03:06, Martin Thomson wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-pwe3-redundancy-06 > Reviewer: Martin Thomson > Review Date: 2012-03-15 > IETF LC End Date: 2012-03-21 > IESG Telechat date: (if known) > > Summary: The draft has some minor issues. > > Major issues: none > > Minor issues: > > 3.2.2 states: "The mechanisms for achieving this selection are outside > the scope of this document." > > The example then describes the _conditions_ under which the selection > is made. So the statement doesn't quite make sense. It's reasonable > to presume that a standard doesn't prescribe the internal behaviour of > a PE where interoperability is no concern. Even though this is just > an example, it makes a very specific presumption about the behaviour > of the PE in reaction to an event. I can't imagine any other reaction > in this case, so I'm left wondering: what exactly is out of scope for > this? Communication of the event between PE1 and PE2? > > Section 4.1: "Non-revertive behavior MUST be supported, while > revertive behavior is OPTIONAL." > > The reason for this requirement is non-obvious (at least to me). Some > justification for it seems appropriate. > > Section 4.1: "Protection switchover can be triggered by the operator [...]" > > Again, justification would be nice. This actually smells more like a > product specification that requirement for interoperability. If the > requirement is, as I suspect, that switchovers triggered by manual > intervention can be marked as such in the protocol _so that they can > be treated with lower priority_, then that is definitely > understandable. > > Section 4.2: "[...] MUST support the configuration of revertive or > non-revertive protection switching modes." > > If revertive switching is optional, then this requirement makes not > sense for (T-)PEs that don't implement it. > > Nits: > The figures are somewhat difficult to read overall. It's unclear what > significance is attached to the dots in many of the diagrams, since > they aren't always consistent (see Figure 3). > Figure 5 is especially difficult to read. Another instance is the > choice of '.' or '|' in Figure 4, which could have some significance, > but probably doesn't because the usage is quite inconsistent. Having > labels for lines/tunnels impinge on boxes is difficult to interpret. > Reducing the noise in the diagrams would help. The text is adequate > to make up the shortfall. (Figure 7 is perfectly clear.) > > Labeling of PEs in 3.2.2 makes it hard to follow because PE2 is > attached to CE2. I'd suggest renames such that you have {CE1, PE1a, > PE1b} and likewise. > > The first requirement in 4.1 is missing a couple of spaces (after the > comma, in "besupported"). > > 4.2 has an empty bullet. > > Not expanded on first use: PSN, LDP > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From lizho.jin@gmail.com Fri Apr 6 19:58:13 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 BD91D11E8081 for ; Fri, 6 Apr 2012 19:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVWRi72oxUGH for ; Fri, 6 Apr 2012 19:58:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08A9421F8473 for ; Fri, 6 Apr 2012 19:58:12 -0700 (PDT) Received: by iazz13 with SMTP id z13so4525521iaz.31 for ; Fri, 06 Apr 2012 19:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=j3+udXEXjxscTn+x3mnaLQVPatyujd0CXwyj5MpARM8=; b=C3qGB4LmTNahyaGc6d0I3V7guXltS6TnhvYVeL6FpHofGhU9a5TzjKOdiQ3zHMnhLa IYvektN0eMIcuKoQIbgUQnuedm48tMm35KerYefbFkbK0oByasrpM+K7p2tlkxCVrdB9 GK6fr+gxYjJeClPj76sg2uPspWyhqnqwaz7o6H42J/1FBrej6Vt+t7ocnI3OO0D7GM9m kWtCPS1pOJPQ/OpvHisztdF5zvg+l+nkGKZKYX1gW0uXmq1l/ruRtRlcICm9ixk9uLJS 3pMoieX/2sEMOt3+GmyF3VCujfznPIUT6zFwvuWosQ00ICBcDspNjj8DAf88VOaaN7eo 3dUA== MIME-Version: 1.0 Received: by 10.50.194.232 with SMTP id hz8mr71149igc.38.1333767492573; Fri, 06 Apr 2012 19:58:12 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Fri, 6 Apr 2012 19:58:12 -0700 (PDT) Date: Sat, 7 Apr 2012 10:58:12 +0800 Message-ID: From: Lizhong Jin To: yaakov_s@rad.com Content-Type: multipart/alternative; boundary=14dae93405a19b999804bd0df1bc Cc: pwe3@ietf.org Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 07 Apr 2012 02:58:13 -0000 --14dae93405a19b999804bd0df1bc Content-Type: text/plain; charset=ISO-8859-1 Hi Yaakov, Thanks for the comments during the session of PWE3. For the static PW, the CW usage should be consisted, otherwise the packet processing would be wrong. The CW nibble is not enough to identify a ACH, and "PW label + CW nibble" is used to identify ACH. IMO, the static PW CW capability could be got by "OR" operation of both local and remote CW parameters. Thanks Lizhong > ------------------------------ > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > From: Yaakov Stein > To: "pwe3@ietf.org" > Subject: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset="us-ascii" > > At the meeting I promised to check when this issue in the subject line was > last discussed. > > It was only a short while ago in Prague (see > http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11< > http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011 > >). > > I recall a lively discussion after the presentation, > but the minutes do not show resolution of the issue of whether a CW MUST > be used or not used > in both directions for PWs not set up using the PWE3 control protocol. > > Y(J)S > --14dae93405a19b999804bd0df1bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yaakov,
Thanks for the comments during the session of PWE3.
For the static PW, the CW usage should be consisted, otherwise the pac= ket processing would be wrong. The CW nibble is not enough to identify a AC= H, and "PW label + CW nibble" is used to identify ACH.=A0IMO, the= static PW CW capability could be got by "OR" operation of both l= ocal and remote CW parameters.
=A0
Thanks
Lizhong
=A0
------------------------------
Date: Sun, 1 Apr 2012 12:44:56 +0000
From: Yaakov Stein <yaakov_s@rad.com>
To: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: [PWE3] CW us= age in opposite directions for static PWs
Message-ID:
=A0 =A0 =A0 =A0= <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il&g= t;
Content-Type: text/plain; charset=3D"us-ascii"

At the meet= ing I promised to check when this issue in the subject line was last discus= sed.

It was only a short while ago in Prague (see http://www= .ietf.org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf%20s= lides%209%20-%2011>).

I recall a lively discussion after the presentation,
but the minutes= do not show resolution of the issue of whether a CW MUST be used or not us= ed
in both directions for PWs not set up using the PWE3 control protocol= .

Y(J)S
--14dae93405a19b999804bd0df1bc-- From yaakov_s@rad.com Sun Apr 8 08:29:01 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 B207621F851D for ; Sun, 8 Apr 2012 08:29:01 -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=[AWL=-0.000, 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 jELoEfBAgUqe for ; Sun, 8 Apr 2012 08:29:00 -0700 (PDT) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC5221F8518 for ; Sun, 8 Apr 2012 08:28:57 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 8 Apr 2012 18:14: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; Sun, 8 Apr 2012 18:28:53 +0300 From: Yaakov Stein To: Lizhong Jin Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFGpJR8k+8boiWEyuusmNJqhMmZaRDt/A Date: Sun, 8 Apr 2012 15:28:52 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904363878@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_07F7D7DED63154409F13298786A2ADC904363878EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020205.4F81AEB6.0078,ss=1,fgs=0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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: Sun, 08 Apr 2012 15:29:01 -0000 --_000_07F7D7DED63154409F13298786A2ADC904363878EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong Of course each side needs to KNOW if the other side is using a CW or not; but, that does not mean they can not be asymmetric. What do you mean by OR - that if either CAN use a CW then both MUST use? This is the opposite of 4447. Y(J)S From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: Saturday, April 07, 2012 05:58 To: Yaakov Stein Cc: pwe3@ietf.org Subject: Re: [PWE3] CW usage in opposite directions for static PWs Hi Yaakov, Thanks for the comments during the session of PWE3. For the static PW, the CW usage should be consisted, otherwise the packet p= rocessing would be wrong. The CW nibble is not enough to identify a ACH, an= d "PW label + CW nibble" is used to identify ACH. IMO, the static PW CW cap= ability could be got by "OR" operation of both local and remote CW paramete= rs. Thanks Lizhong ------------------------------ Date: Sun, 1 Apr 2012 12:44:56 +0000 From: Yaakov Stein > To: "pwe3@ietf.org" > Subject: [PWE3] CW usage in opposite directions for static PWs Message-ID: <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=3D"us-ascii" At the meeting I promised to check when this issue in the subject line was = last discussed. It was only a short while ago in Prague (see http://www.ietf.org/proceeding= s/80/slides/pwe3-3.pdf slides 9 - 11). I recall a lively discussion after the presentation, but the minutes do not show resolution of the issue of whether a CW MUST be= used or not used in both directions for PWs not set up using the PWE3 control protocol. Y(J)S --_000_07F7D7DED63154409F13298786A2ADC904363878EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lizhong

 

Of course each side needs to KNOW if the other side is using= a CW or not;

but, that does not mean they can not be asymmetric.

 

What do you mean by OR – that if either CAN use a CW t= hen both MUST use?

This is the opposite of 4447.

 

 

Y(J)S

 

From: Lizhong = Jin [mailto:lizho.jin@gmail.com]
Sent: Saturday, April 07, 2012 05:58
To: Yaakov Stein
Cc: pwe3@ietf.org
Subject: Re: [PWE3] CW usage in opposite directions for static PWs

 

Hi Yaakov,

Thanks for the comments during the session of PWE3.<= o:p>

For the static PW, the CW usage should be consisted,= otherwise the packet processing would be wrong. The CW nibble is not enoug= h to identify a ACH, and "PW label + CW nibble" is used to id= entify ACH. IMO, the static PW CW capability could be got by "OR" operation of both local and remote CW parameters.=

 

Thanks

Lizhong

 

------------------------------

Date: Sun, 1 Apr 2012 12:44:56 +0000
From: Yaakov Stein <yaakov_s@rad.com= >
To: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: [PWE3] CW usage in opposite directions for static PWs
Message-ID:
       <07F7D7DED63154409F13298786A2ADC90433209= 2@EXRAD5.ad.rad.co.il>
Content-Type: text/plain; charset=3D"us-ascii"

At the meeting I promised to check when this issue in the subject line was = last discussed.

It was only a short while ago in Prague (see http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<<= a href=3D"http://www.ietf.org/proceedings/80/slides/pwe3-3.pdf%20slides%209= %20-%2011" target=3D"_blank">http://www.ietf.org/proceedings/80/slides/pwe3= -3.pdf%20slides%209%20-%2011>).

I recall a lively discussion after the presentation,
but the minutes do not show resolution of the issue of whether a CW MUST be= used or not used
in both directions for PWs not set up using the PWE3 control protocol.

Y(J)S

--_000_07F7D7DED63154409F13298786A2ADC904363878EXRAD5adradcoil_-- From lizhong.jin@zte.com.cn Mon Apr 9 00:18: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 1907211E8076 for ; Mon, 9 Apr 2012 00:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jALsjpC8lDVw for ; Mon, 9 Apr 2012 00:18:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6411E8074 for ; Mon, 9 Apr 2012 00:18:14 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291397396305; Mon, 9 Apr 2012 15:17:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 14085.2928413318; Mon, 9 Apr 2012 15:02:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q397I3b6053771; Mon, 9 Apr 2012 15:18:04 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: pwe3@ietf.org, yaakov_s@rad.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Mon, 9 Apr 2012 15:18:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-09 15:18:06, Serialize complete at 2012-04-09 15:18:06 Content-Type: multipart/alternative; boundary="=_alternative 00281BA7482579DB_=" X-MAIL: mse02.zte.com.cn q397I3b6053771 Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 09 Apr 2012 07:18:16 -0000 This is a multipart message in MIME format. --=_alternative 00281BA7482579DB_= Content-Type: text/plain; charset="US-ASCII" Hi Yaakov, Sorry, word mistake. It should not be OR, but AND operation. If one side support and the other side not, then CW will not be used. Then the result will be aligned with RFC4447. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 8 Apr 2012 15:28:52 +0000 > From: Yaakov Stein > To: Lizhong Jin > Cc: "pwe3@ietf.org" > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset="us-ascii" > > Lizhong > > Of course each side needs to KNOW if the other side is using a CW or not; > but, that does not mean they can not be asymmetric. > > What do you mean by OR - that if either CAN use a CW then both MUST use? > This is the opposite of 4447. > > > Y(J)S > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Saturday, April 07, 2012 05:58 > To: Yaakov Stein > Cc: pwe3@ietf.org > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > Hi Yaakov, > Thanks for the comments during the session of PWE3. > For the static PW, the CW usage should be consisted, otherwise the > packet processing would be wrong. The CW nibble is not enough to > identify a ACH, and "PW label + CW nibble" is used to identify ACH. > IMO, the static PW CW capability could be got by "OR" operation of > both local and remote CW parameters. > > Thanks > Lizhong > > ------------------------------ > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > From: Yaakov Stein > > To: "pwe3@ietf.org" >> > Subject: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il< > mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>> > Content-Type: text/plain; charset="us-ascii" > > At the meeting I promised to check when this issue in the subject > line was last discussed. > > It was only a short while ago in Prague (see http://www.ietf. > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11 org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>). > > I recall a lively discussion after the presentation, > but the minutes do not show resolution of the issue of whether a CW > MUST be used or not used > in both directions for PWs not set up using the PWE3 control protocol. > > Y(J)S > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20120408/488442e2/attachment.htm> > > ------------------------------ > > ________ --=_alternative 00281BA7482579DB_= Content-Type: text/html; charset="US-ASCII"
Hi Yaakov,
Sorry, word mistake. It should not be OR, but AND operation. If one side support and the other side not, then CW will not be used. Then the result will be aligned with RFC4447.

Regards
Lizhong

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 8 Apr 2012 15:28:52 +0000
> From: Yaakov Stein <yaakov_s@rad.com>
> To: Lizhong Jin <lizho.jin@gmail.com>
> Cc: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs
> Message-ID:
>    <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il>
> Content-Type: text/plain; charset="us-ascii"
>
> Lizhong
>
> Of course each side needs to KNOW if the other side is using a CW or not;
> but, that does not mean they can not be asymmetric.
>
> What do you mean by OR - that if either CAN use a CW then both MUST use?
> This is the opposite of 4447.
>
>
> Y(J)S
>
> From: Lizhong Jin [mailto:lizho.jin@gmail.com]
> Sent: Saturday, April 07, 2012 05:58
> To: Yaakov Stein
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs
>
> Hi Yaakov,
> Thanks for the comments during the session of PWE3.
> For the static PW, the CW usage should be consisted, otherwise the
> packet processing would be wrong. The CW nibble is not enough to
> identify a ACH, and "PW label + CW nibble" is used to identify ACH.
> IMO, the static PW CW capability could be got by "OR" operation of
> both local and remote CW parameters.
>
> Thanks
> Lizhong
>
> ------------------------------
>
> Date: Sun, 1 Apr 2012 12:44:56 +0000
> From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
> To: "pwe3@ietf.org<mailto:pwe3@ietf.org>" <pwe3@ietf.org<mailto:pwe3@ietf.org
> >>
> Subject: [PWE3] CW usage in opposite directions for static PWs
> Message-ID:
>        <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il<
> mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>>
> Content-Type: text/plain; charset="us-ascii"
>
> At the meeting I promised to check when this issue in the subject
> line was last discussed.
>
> It was only a short while ago in Prague (see http://www.ietf.
> org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.ietf.
> org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>).
>
> I recall a lively discussion after the presentation,
> but the minutes do not show resolution of the issue of whether a CW
> MUST be used or not used
> in both directions for PWs not set up using the PWE3 control protocol.
>
> Y(J)S
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20120408/488442e2/attachment.htm>
>
> ------------------------------
>
> ________ --=_alternative 00281BA7482579DB_=-- From yaakov_s@rad.com Tue Apr 10 00:39:18 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 F0AC421F871E for ; Tue, 10 Apr 2012 00:39:17 -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=[AWL=-0.000, 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 H34-ZhgQTqgq for ; Tue, 10 Apr 2012 00:39:17 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5A40921F8720 for ; Tue, 10 Apr 2012 00:39:14 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 10 Apr 2012 10:27:29 +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, 10 Apr 2012 10:38:59 +0300 From: Yaakov Stein To: Lizhong Jin , "pwe3@ietf.org" Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFiDmR8k+8boiWEyuusmNJqhMmZaTrS8Q Date: Tue, 10 Apr 2012 07:38:58 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC90436C40D@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_07F7D7DED63154409F13298786A2ADC90436C40DEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020204.4F83E39A.00F7,ss=1,fgs=0 Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 10 Apr 2012 07:39:18 -0000 --_000_07F7D7DED63154409F13298786A2ADC90436C40DEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lizhong OK, maybe I agree. But my point was that this requirement was not fully dis= cussed. Perhaps a statically configured PW should be able to use the CW in one dire= ction while not using it in the other. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Monday, April 09, 2012 10:18 To: pwe3@ietf.org; Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs Hi Yaakov, Sorry, word mistake. It should not be OR, but AND operation. If one side su= pport and the other side not, then CW will not be used. Then the result wil= l be aligned with RFC4447. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 8 Apr 2012 15:28:52 +0000 > From: Yaakov Stein > To: Lizhong Jin > Cc: "pwe3@ietf.org" > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset=3D"us-ascii" > > Lizhong > > Of course each side needs to KNOW if the other side is using a CW or not; > but, that does not mean they can not be asymmetric. > > What do you mean by OR - that if either CAN use a CW then both MUST use? > This is the opposite of 4447. > > > Y(J)S > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Saturday, April 07, 2012 05:58 > To: Yaakov Stein > Cc: pwe3@ietf.org > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > Hi Yaakov, > Thanks for the comments during the session of PWE3. > For the static PW, the CW usage should be consisted, otherwise the > packet processing would be wrong. The CW nibble is not enough to > identify a ACH, and "PW label + CW nibble" is used to identify ACH. > IMO, the static PW CW capability could be got by "OR" operation of > both local and remote CW parameters. > > Thanks > Lizhong > > ------------------------------ > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > From: Yaakov Stein > > To: "pwe3@ietf.org" >> > Subject: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il< > mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>> > Content-Type: text/plain; charset=3D"us-ascii" > > At the meeting I promised to check when this issue in the subject > line was last discussed. > > It was only a short while ago in Prague (see http://www.ietf. > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11 org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>). > > I recall a lively discussion after the presentation, > but the minutes do not show resolution of the issue of whether a CW > MUST be used or not used > in both directions for PWs not set up using the PWE3 control protocol. > > Y(J)S > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20120408/488442e2/attachment.htm> > > ------------------------------ > > ________ --_000_07F7D7DED63154409F13298786A2ADC90436C40DEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lizhong

 

OK, maybe I agree. But my point was that this requirement wa= s not fully discussed.

 

Perhaps a statically configured PW should be able to use the= CW in one direction while not using it in the other.

 

Y(J)S

 

From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Monday, April 09, 2012 10:18
To: pwe3@ietf.org; Yaakov Stein
Subject: Re: [PWE3] CW usage in opposite directions for static PWs

 


Hi Yaakov,
Sorry, word mistake. It should not be = OR, but AND operation. If one side support and the other side not, then CW = will not be used. Then the result will be aligned with RFC4447.

Regards
Lizhong

> ------------------------------------------------------------------= ----
>
> Message: 1
> Date: Sun, 8 Apr 2012 15:28:52 +0000
> From: Yaakov Stein <yaakov_s@rad.com>
> To: Lizhong Jin <lizho.jin@gmail.com>
> Cc: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs=
> Message-ID:
>    <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.a= d.rad.co.il>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Lizhong
>
> Of course each side needs to KNOW if the other side is using a CW = or not;
> but, that does not mean they can not be asymmetric.
>
> What do you mean by OR - that if either CAN use a CW then both MUS= T use?
> This is the opposite of 4447.
>
>
> Y(J)S
>
> From: Lizhong Jin [mailto:lizho.jin@gmail.com]
> Sent: Saturday, April 07, 2012 05:58
> To: Yaakov Stein
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs=
>
> Hi Yaakov,
> Thanks for the comments during the session of PWE3.
> For the static PW, the CW usage should be consisted, otherwise the=
> packet processing would be wrong. The CW nibble is not enough to <= /tt>
> identify a ACH, and "PW label + CW nibble" is used t= o identify ACH.
> IMO, the static PW CW capability could be got by "OR" op= eration of
> both local and remote CW parameters.
>
> Thanks
> Lizhong
>
> ------------------------------
>
> Date: Sun, 1 Apr 2012 12:44:56 +0000
> From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com= >>
> To: "pwe3@ietf.org<mailto:pwe3@ietf.org>" <pwe3= @ietf.org<mailto:pwe3@ietf.org
> >>
> Subject: [PWE3] CW usage in opposite directions for static PWs
> Message-ID:
>        <07F7D7DED63154409F13298786A2ADC9043= 32092@EXRAD5.ad.rad.co.il<
> mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.i= l>>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> At the meeting I promised to check when this issue in the subject =
> line was last discussed.
>
> It was only a short while ago in Prague (see http://www.ietf.=
> org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.i= etf.
> org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>).
>
> I recall a lively discussion after the presentation,
> but the minutes do not show resolution of the issue of whether a C= W
> MUST be used or not used
> in both directions for PWs not set up using the PWE3 control proto= col.
>
> Y(J)S
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20120408/488442e2/attachment.htm><= /tt>
>
> ------------------------------
>
> ________

--_000_07F7D7DED63154409F13298786A2ADC90436C40DEXRAD5adradcoil_-- From Alexander.Vainshtein@ecitele.com Tue Apr 10 01:05: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 3907E21F87D6 for ; Tue, 10 Apr 2012 01:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 Jc55f9pyh8GR for ; Tue, 10 Apr 2012 01:05:37 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id A3DC621F87CC for ; Tue, 10 Apr 2012 01:05:34 -0700 (PDT) Received: from [193.109.254.147:59844] by server-11.bemta-14.messagelabs.com id E2/76-05858-BC9E38F4; Tue, 10 Apr 2012 08:05:31 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1334045129!3860393!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 13972 invoked from network); 10 Apr 2012 08:05:29 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-4.tower-27.messagelabs.com with SMTP; 10 Apr 2012 08:05:29 -0000 X-AuditID: a8571406-b7fe86d0000037a2-bc-4f83e9c21470 Received: from FRGRWPVCH001.ecitele.com (frgrwpvch001.ecitele.com [10.1.18.35]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 67.35.14242.2C9E38F4; Tue, 10 Apr 2012 10:05:22 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 10:05:29 +0200 From: Alexander Vainshtein To: Yaakov Stein Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFiDmqCfMYw5MQ0qbOiTyhnYHbZaTjDEAgAAlojA= Date: Tue, 10 Apr 2012 08:05:27 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC90436C40D@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC90436C40D@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: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02032216FRIDWPPMB002ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRzuvbttp3l1mrnXJbWuDPuYTExYH5OwAiXMsLAPKLt277aj7W7s prQgGklUS8oiqhmVgZV9aURRUFSOyr4oA5EsMsoitegTm30gvbdDE6L763mf5/d7fs979zua TKkymGhRCiC/xHs4fSKVCEaYLNGeqhJrZOsc2+3wALDt+nqRsn0O9+vmkYX19T+Iwr3nnIVn r/dTS8hVITCXlyQ5wAeQWUCKw84t8YuVvCPImUXBzuVwZp+HdyAvkgJ2jvf5kCRw+Ynmf565 uEyUzEhyyIIouexc0dISi82WN8uSw+Uvc4uKGVm8vOgxe5Gi8C5kxowaWxLWNpLu7uctOt/V MNhw+MADMgReB8MggYbsTNjwJazXcBps7WzCOJFOYdsA/HFjO6kdjgPY9Oq8Tq3Ss3Z44cyL eEcqOwl+2DEQ50m2CB788gnzND2GLYB3WxZrJfPhrZdvCQ3Phvu2xICKKTYTNrbXUipm2GL4 81GdTpvVDGD1nuq4kMAugvWX2+MY4HSx+2cJbZYRPntzlNBSs7D+2mNSw2NhT5eWB7Lj4ZZT bQatXobNb68ZtGHJ8F7kDaXVpMPmhqdUDUirHWZbO6yldliLxs+AdVe/6jU8HZ449p4cxA9v dhHD+TpgOA2g0y8KHl+lss5qzctGDjGAPCjbIXsvALxJDctT9VdAqCY7ClgacEmMNamqJEXH VypBbxSk0wQ3lkl7h6lR62Qh6OYVd7m/woOUKIA0yaUyzg6sMQIf3Ij88qC0EL/dPaRppENW P36gPNdq/f+BMzJNpfklKawLr+d6hHzIP+iTQdMcZAa68YhkP3KhDU7RE/grE3SCGiMJx5jc o8ZQfLxXEV2afh+km4yMXhVYVXBXSEO9vcCILzuGianWSXhFh7p6sSGBDa0v44b4lxmSTCEw 8QjqPbkscCiYt/jnlPymG5uIVPbiaENN5Ltn3IhiY+fG2JO+Fb8m14R+X3J0y+GKbGV1X6ul a01E+SxE9+/NsmWU7o8FizIK5pwqbSz79itrOVd2J7d1ddfuXQWbV1KRnVM/ZjoZupXKkNvO LzizTbFOyA2Bjpaydwf1J9vvVnOU4uZzppF+hf8Dnzq2qBYEAAA= Cc: Lizhong Jin , "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 10 Apr 2012 08:05:38 -0000 --_000_F9336571731ADE42A5397FC831CEAA02032216FRIDWPPMB002ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yaakov, and all, My reading of RFC 4447 is that in the case of a signaled PW the CW is either= used or not used bi-directionally by a PW endpoint. Further, as per RFC 6073, S-PEs in multi-segment PWs cannot strip, insert or= manipulate the CW in any way. Hence I think that the asymmetric usage of the CW must be prohibited in stat= ic PWs in order to assure interoperability of MS-PWs comprised of static and= dynamic segments. (On top of that, I do not see any advantage in allowing asymmetric usage of= the CW, but this is a different story.) Regards, Sasha From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaak= ov Stein Sent: Tuesday, April 10, 2012 10:39 AM To: Lizhong Jin; pwe3@ietf.org Subject: Re: [PWE3] CW usage in opposite directions for static PWs Lizhong OK, maybe I agree. But my point was that this requirement was not fully disc= ussed. Perhaps a statically configured PW should be able to use the CW in one direc= tion while not using it in the other. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Lizh= ong Jin Sent: Monday, April 09, 2012 10:18 To: pwe3@ietf.org; Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs Hi Yaakov, Sorry, word mistake. It should not be OR, but AND operation. If one side sup= port and the other side not, then CW will not be used. Then the result will= be aligned with RFC4447. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 8 Apr 2012 15:28:52 +0000 > From: Yaakov Stein > > To: Lizhong Jin > > Cc: "pwe3@ietf.org" > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset=3D"us-ascii" > > Lizhong > > Of course each side needs to KNOW if the other side is using a CW or not; > but, that does not mean they can not be asymmetric. > > What do you mean by OR - that if either CAN use a CW then both MUST use? > This is the opposite of 4447. > > > Y(J)S > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Saturday, April 07, 2012 05:58 > To: Yaakov Stein > Cc: pwe3@ietf.org > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > Hi Yaakov, > Thanks for the comments during the session of PWE3. > For the static PW, the CW usage should be consisted, otherwise the > packet processing would be wrong. The CW nibble is not enough to > identify a ACH, and "PW label + CW nibble" is used to identify ACH. > IMO, the static PW CW capability could be got by "OR" operation of > both local and remote CW parameters. > > Thanks > Lizhong > > ------------------------------ > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > From: Yaakov Stein >> > To: "pwe3@ietf.org" > >> > Subject: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il< >= mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>> > Content-Type: text/plain; charset=3D"us-ascii" > > At the meeting I promised to check when this issue in the subject > line was last discussed. > > It was only a short while ago in Prague (see http://www.ietf. > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11> org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-= %2011>). > > I recall a lively discussion after the presentation, > but the minutes do not show resolution of the issue of whether a CW > MUST be used or not used > in both directions for PWs not set up using the PWE3 control protocol. > > Y(J)S > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > archive/web/pwe3/attachments/20120408/488442= e2/attachment.htm> > > ------------------------------ > > ________ 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_F9336571731ADE42A5397FC831CEAA02032216FRIDWPPMB002ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Yaakov, and all,=

My reading of RFC 4447 is t= hat in the case of a signaled PW the CW is either used or not used bi-direct= ionally by a PW endpoint.

Further, as per RFC 6073, S= -PEs in multi-segment PWs cannot strip, insert or manipulate the CW in any w= ay.

Hence I think that the asym= metric usage of the CW must be prohibited in static PWs in order to assure i= nteroperability of MS-PWs comprised of static and dynamic segments.

 

(On top of that, I do not s= ee any advantage in allowing asymmetric usage of the CW, but this is a diffe= rent story.)

 

Regards,<= /p>

     Sa= sha

 

From: pwe3-bounce= s@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, April 10, 2012 10:39 AM
To: Lizhong Jin; pwe3@ietf.org
Subject: Re: [PWE3] CW usage in opposite directions for static PWs

 

Lizhong

 

OK, maybe I agree. But my p= oint was that this requirement was not fully discussed.

 

Perhaps a statically config= ured PW should be able to use the CW in one direction while not using it in= the other.

 

Y(J)S

 

From: pwe3-bounce= s@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Monday, April 09, 2012 10:18
To: pwe3@ietf.org; Yaakov Stein
Subject: Re: [PWE3] CW usage in opposite directions for static PWs

 


Hi Yaakov,
Sorry, word mistake. It should not be O= R, but AND operation. If one side support and the other side not, then CW wi= ll not be used. Then the result will be aligned with RFC4447.

Regards
Lizhong

> -------------------------------------------------------------------= ---
>
> Message: 1
> Date: Sun, 8 Apr 2012 15:28:52 +0000
> From: Yaakov Stein <yaakov_s= @rad.com>
> To: Lizhong Jin <lizho.ji= n@gmail.com>
> Cc: "pwe3@ietf.org"= <pwe3@ietf.org>
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs<= /tt>
> Message-ID:
>    <07F7D7DED63154409F13298786A2ADC904363878@EXRAD= 5.ad.rad.co.il>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Lizhong
>
> Of course each side needs to KNOW if the other side is using a CW o= r not;
> but, that does not mean they can not be asymmetric.
>
> What do you mean by OR - that if either CAN use a CW then both MUST= use?
> This is the opposite of 4447.
>
>
> Y(J)S
>
> From: Lizhong Jin [= mailto:lizho.jin@gmail.com]
> Sent: Saturday, April 07, 2012 05:58
> To: Yaakov Stein
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs<= /tt>
>
> Hi Yaakov,
> Thanks for the comments during the session of PWE3.
> For the static PW, the CW usage should be consisted, otherwise the=
> packet processing would be wrong. The CW nibble is not enough to
> identify a ACH, and "PW label + CW nibble" is used to= identify ACH.
> IMO, the static PW CW capability could be got by "OR" ope= ration of
> both local and remote CW parameters.
>
> Thanks
> Lizhong
>
> ------------------------------
>
> Date: Sun, 1 Apr 2012 12:44:56 +0000
> From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
> To: "pwe3@ietf.org<mailto:pwe3@ietf.org>" <pwe3@ietf.org<mailto:pwe3@ietf.o= rg
> >>
> Subject: [PWE3] CW usage in opposite directions for static PWs=
> Message-ID:
>        <07F7D7DED63154409F13298786= A2ADC904332092@EXRAD5.ad.rad.co.il<
> mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>&= gt;
> Content-Type: text/plain; charset=3D"us-ascii"
>
> At the meeting I promised to check when this issue in the subject <= /tt>
> line was last discussed.
>
> It was only a short while ago in Prague (see http://www.ietf.
> org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.ietf.
> org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>).
>
> I recall a lively discussion after the presentation,
> but the minutes do not show resolution of the issue of whether a CW=
> MUST be used or not used
> in both directions for PWs not set up using the PWE3 control protoc= ol.
>
> Y(J)S
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.o= rg/mail-
> archive/web/pwe3/attachments/20120408/488442e2/attachment.htm>
>
> ------------------------------
>
> ________

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_F9336571731ADE42A5397FC831CEAA02032216FRIDWPPMB002ecite_-- From yaakov_s@rad.com Tue Apr 10 01:14: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 2477921F87D2 for ; Tue, 10 Apr 2012 01:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, 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 E3YUd7t0Jpup for ; Tue, 10 Apr 2012 01:14:13 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 719A521F87FF for ; Tue, 10 Apr 2012 01:14:07 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 10 Apr 2012 10:59:15 +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, 10 Apr 2012 11:14:03 +0300 From: Yaakov Stein To: Alexander Vainshtein Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFiDmR8k+8boiWEyuusmNJqhMmZaTrS8Q///VpYCAADKjoA== Date: Tue, 10 Apr 2012 08:14:03 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC90436C40D@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: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC90436C45AEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090206.4F83EBCD.001E,ss=1,fgs=0 Cc: Lizhong Jin , "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 10 Apr 2012 08:14:15 -0000 --_000_07F7D7DED63154409F13298786A2ADC90436C45AEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha The only scenario I can think of where it is really useful, is the asymmetr= ic bandwidth and usage case. Consider a bandwidth constrained upstream sending very small packets (ack's and control signaling) where the CW may be significant overhead, and a wide bandwidth downstream sending very large packets (e.g., video), where the CW would be useful. The mixed static-signaled MS-PW case is not really a constraint. If the end-end MS-PW uses (or doesn't) the CW, then the configuration of the static segment(s) would need to enforce that = behavior, along with all other parameters. This has little to do with the general question of enforcing duplexing beha= vior. Y(J)S From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Tuesday, April 10, 2012 11:05 To: Yaakov Stein Cc: Lizhong Jin; pwe3@ietf.org Subject: RE: [PWE3] CW usage in opposite directions for static PWs Yaakov, and all, My reading of RFC 4447 is that in the case of a signaled PW the CW is eithe= r used or not used bi-directionally by a PW endpoint. Further, as per RFC 6073, S-PEs in multi-segment PWs cannot strip, insert o= r manipulate the CW in any way. Hence I think that the asymmetric usage of the CW must be prohibited in sta= tic PWs in order to assure interoperability of MS-PWs comprised of static a= nd dynamic segments. (On top of that, I do not see any advantage in allowing asymmetric usage of= the CW, but this is a different story.) Regards, Sasha From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Tuesday, April 10, 2012 10:39 AM To: Lizhong Jin; pwe3@ietf.org Subject: Re: [PWE3] CW usage in opposite directions for static PWs Lizhong OK, maybe I agree. But my point was that this requirement was not fully dis= cussed. Perhaps a statically configured PW should be able to use the CW in one dire= ction while not using it in the other. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Monday, April 09, 2012 10:18 To: pwe3@ietf.org; Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs Hi Yaakov, Sorry, word mistake. It should not be OR, but AND operation. If one side su= pport and the other side not, then CW will not be used. Then the result wil= l be aligned with RFC4447. Regards Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 8 Apr 2012 15:28:52 +0000 > From: Yaakov Stein > > To: Lizhong Jin > > Cc: "pwe3@ietf.org" > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset=3D"us-ascii" > > Lizhong > > Of course each side needs to KNOW if the other side is using a CW or not; > but, that does not mean they can not be asymmetric. > > What do you mean by OR - that if either CAN use a CW then both MUST use? > This is the opposite of 4447. > > > Y(J)S > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Saturday, April 07, 2012 05:58 > To: Yaakov Stein > Cc: pwe3@ietf.org > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > Hi Yaakov, > Thanks for the comments during the session of PWE3. > For the static PW, the CW usage should be consisted, otherwise the > packet processing would be wrong. The CW nibble is not enough to > identify a ACH, and "PW label + CW nibble" is used to identify ACH. > IMO, the static PW CW capability could be got by "OR" operation of > both local and remote CW parameters. > > Thanks > Lizhong > > ------------------------------ > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > From: Yaakov Stein >> > To: "pwe3@ietf.org" > >> > Subject: [PWE3] CW usage in opposite directions for static PWs > Message-ID: > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il< = > mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>> > Content-Type: text/plain; charset=3D"us-ascii" > > At the meeting I promised to check when this issue in the subject > line was last discussed. > > It was only a short while ago in Prague (see http://www.ietf. > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11> org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20= -%2011>). > > I recall a lively discussion after the presentation, > but the minutes do not show resolution of the issue of whether a CW > MUST be used or not used > in both directions for PWs not set up using the PWE3 control protocol. > > Y(J)S > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > archive/web/pwe3/attachments/20120408/48844= 2e2/attachment.htm> > > ------------------------------ > > ________ 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. --_000_07F7D7DED63154409F13298786A2ADC90436C45AEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha

 

The only scenario I can think of where it is really useful, = is the asymmetric bandwidth and usage case.

 

Consider a bandwidth constrained upstream sending very small= packets

(ack's and control signaling) where the CW may be significan= t overhead,

and a wide bandwidth downstream sending very large packets (= e.g., video),

where the CW would be useful.

 

The mixed static-signaled MS-PW case is not really a constra= int.

If the end-end MS-PW uses (or doesn't) the CW,

then the configuration of the static segment(s) would need t= o enforce that behavior,

along with all other parameters.

This has little to do with the general question of enforcing= duplexing behavior.

 

Y(J)S

 

 

From: Alexande= r Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, April 10, 2012 11:05
To: Yaakov Stein
Cc: Lizhong Jin; pwe3@ietf.org
Subject: RE: [PWE3] CW usage in opposite directions for static PWs

 

Yaakov, and all,

My reading of RFC 4447 is that in the case of a signaled PW = the CW is either used or not used bi-directionally by a PW endpoint.

Further, as per RFC 6073, S-PEs in multi-segment PWs cannot = strip, insert or manipulate the CW in any way.

Hence I think that the asymmetric usage of the CW must be pr= ohibited in static PWs in order to assure interoperability of MS-PWs compri= sed of static and dynamic segments.

 

(On top of that, I do not see any advantage in allowing asym= metric usage of the CW, but this is a different story.)

 

Regards,

     Sasha

 

From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, April 10, 2012 10:39 AM
To: Lizhong Jin; pwe3@ietf.org
Subject: Re: [PWE3] CW usage in opposite directions for static PWs

 

Lizhong

 

OK, maybe I agree. But my point was that this requirement wa= s not fully discussed.

 

Perhaps a statically configured PW should be able to use the= CW in one direction while not using it in the other.

 

Y(J)S

 

From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Monday, April 09, 2012 10:18
To: pwe3@ietf.org; Yaakov Stein
Subject: Re: [PWE3] CW usage in opposite directions for static PWs

 


Hi Yaakov,
Sorry, word mistake. It should not be = OR, but AND operation. If one side support and the other side not, then CW = will not be used. Then the result will be aligned with RFC4447.

Regards
Lizhong

> ------------------------------------------------------------------= ----
>
> Message: 1
> Date: Sun, 8 Apr 2012 15:28:52 +0000
> From: Yaakov Stein <yaakov_= s@rad.com>
> To: Lizhong Jin <lizho.j= in@gmail.com>
> Cc: "pwe3@ietf.org"= <pwe3@ietf.org>
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs=
> Message-ID:
>    <07F7D7DED63154409F13298786A2ADC904363878@EXR= AD5.ad.rad.co.il>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Lizhong
>
> Of course each side needs to KNOW if the other side is using a CW = or not;
> but, that does not mean they can not be asymmetric.
>
> What do you mean by OR - that if either CAN use a CW then both MUS= T use?
> This is the opposite of 4447.
>
>
> Y(J)S
>
> From: Lizhong Jin = [mailto:lizho.jin@gmail.com]
> Sent: Saturday, April 07, 2012 05:58
> To: Yaakov Stein
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs=
>
> Hi Yaakov,
> Thanks for the comments during the session of PWE3.
> For the static PW, the CW usage should be consisted, otherwise the=
> packet processing would be wrong. The CW nibble is not enough to <= /tt>
> identify a ACH, and "PW label + CW nibble" is used t= o identify ACH.
> IMO, the static PW CW capability could be got by "OR" op= eration of
> both local and remote CW parameters.
>
> Thanks
> Lizhong
>
> ------------------------------
>
> Date: Sun, 1 Apr 2012 12:44:56 +0000
> From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>><= /tt>
> To: "pwe3@ietf.org<mailto:pwe3@ietf.org>" <pwe3@ietf.org<mailto:pwe3@iet= f.org
> >>
> Subject: [PWE3] CW usage in opposite directions for static PWs
> Message-ID:
>        <07F7D7DED63154409F132987= 86A2ADC904332092@EXRAD5.ad.rad.co.il<
> mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>= >
> Content-Type: text/plain; charset=3D"us-ascii"
>
> At the meeting I promised to check when this issue in the subject =
> line was last discussed.
>
> It was only a short while ago in Prague (see http://www.ietf.
> org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.ietf.
> org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>).
>
> I recall a lively discussion after the presentation,
> but the minutes do not show resolution of the issue of whether a C= W
> MUST be used or not used
> in both directions for PWs not set up using the PWE3 control proto= col.
>
> Y(J)S
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.= org/mail-
> archive/web/pwe3/attachments/20120408/488442e2/attachment.htm><= /tt>
>
> ------------------------------
>
> ________

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.

--_000_07F7D7DED63154409F13298786A2ADC90436C45AEXRAD5adradcoil_-- From lizhong.jin@zte.com.cn Tue Apr 10 08:34: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 1DE0511E8104 for ; Tue, 10 Apr 2012 08:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.661 X-Spam-Level: X-Spam-Status: No, score=-100.661 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3At36DT8eHr for ; Tue, 10 Apr 2012 08:34:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id EACB011E80D9 for ; Tue, 10 Apr 2012 08:34:26 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201397396305; Tue, 10 Apr 2012 22:56:47 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.2965776721; Tue, 10 Apr 2012 23:34:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3AFYIS1034801; Tue, 10 Apr 2012 23:34:18 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> To: Yaakov Stein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 10 Apr 2012 23:34:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-10 23:34:20, Serialize complete at 2012-04-10 23:34:20 Content-Type: multipart/alternative; boundary="=_alternative 005587A4482579DC_=" X-MAIL: mse01.zte.com.cn q3AFYIS1034801 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 10 Apr 2012 15:34:29 -0000 This is a multipart message in MIME format. --=_alternative 005587A4482579DC_= Content-Type: text/plain; charset="US-ASCII" Hi Yaakov, The use case below may work, but does not mean asymmetric CW for PW would work in all cases. One example is, when CW is used for packet fragmentation, if asymmetric CW is used, packet fragmentation may not be achieved in one direction, and lead to pack loss. Other examples would be OAM tools for PW. IMO, we could consider asymmetric CW as a special implemenation case. Lizhong ------------------------ Yaakov Stein wrote 2012/04/10 16:14:03: > Sasha > > The only scenario I can think of where it is really useful, is the > asymmetric bandwidth and usage case. > > Consider a bandwidth constrained upstream sending very small packets > (ack's and control signaling) where the CW may be significant overhead, > and a wide bandwidth downstream sending very large packets (e.g., video), > where the CW would be useful. > > The mixed static-signaled MS-PW case is not really a constraint. > If the end-end MS-PW uses (or doesn't) the CW, > then the configuration of the static segment(s) would need to > enforce that behavior, > along with all other parameters. > This has little to do with the general question of enforcing > duplexing behavior. > > Y(J)S > > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, April 10, 2012 11:05 > To: Yaakov Stein > Cc: Lizhong Jin; pwe3@ietf.org > Subject: RE: [PWE3] CW usage in opposite directions for static PWs > > Yaakov, and all, > My reading of RFC 4447 is that in the case of a signaled PW the CW > is either used or not used bi-directionally by a PW endpoint. > Further, as per RFC 6073, S-PEs in multi-segment PWs cannot strip, > insert or manipulate the CW in any way. > Hence I think that the asymmetric usage of the CW must be prohibited > in static PWs in order to assure interoperability of MS-PWs > comprised of static and dynamic segments. > > (On top of that, I do not see any advantage in allowing asymmetric > usage of the CW, but this is a different story.) > > Regards, > Sasha > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Yaakov Stein > Sent: Tuesday, April 10, 2012 10:39 AM > To: Lizhong Jin; pwe3@ietf.org > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > Lizhong > > OK, maybe I agree. But my point was that this requirement was not > fully discussed. > > Perhaps a statically configured PW should be able to use the CW in > one direction while not using it in the other. > > Y(J)S > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Lizhong Jin > Sent: Monday, April 09, 2012 10:18 > To: pwe3@ietf.org; Yaakov Stein > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > > Hi Yaakov, > Sorry, word mistake. It should not be OR, but AND operation. If one > side support and the other side not, then CW will not be used. Then > the result will be aligned with RFC4447. > > Regards > Lizhong > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sun, 8 Apr 2012 15:28:52 +0000 > > From: Yaakov Stein > > To: Lizhong Jin > > Cc: "pwe3@ietf.org" > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > Message-ID: > > <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il> > > Content-Type: text/plain; charset="us-ascii" > > > > Lizhong > > > > Of course each side needs to KNOW if the other side is using a CW or not; > > but, that does not mean they can not be asymmetric. > > > > What do you mean by OR - that if either CAN use a CW then both MUST use? > > This is the opposite of 4447. > > > > > > Y(J)S > > > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > > Sent: Saturday, April 07, 2012 05:58 > > To: Yaakov Stein > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > > > Hi Yaakov, > > Thanks for the comments during the session of PWE3. > > For the static PW, the CW usage should be consisted, otherwise the > > packet processing would be wrong. The CW nibble is not enough to > > identify a ACH, and "PW label + CW nibble" is used to identify ACH. > > IMO, the static PW CW capability could be got by "OR" operation of > > both local and remote CW parameters. > > > > Thanks > > Lizhong > > > > ------------------------------ > > > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > > From: Yaakov Stein > > > To: "pwe3@ietf.org" pwe3@ietf.org > > >> > > Subject: [PWE3] CW usage in opposite directions for static PWs > > Message-ID: > > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il< > > mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>> > > Content-Type: text/plain; charset="us-ascii" > > > > At the meeting I promised to check when this issue in the subject > > line was last discussed. > > > > It was only a short while ago in Prague (see http://www.ietf. > > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11 > org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>). > > > > I recall a lively discussion after the presentation, > > but the minutes do not show resolution of the issue of whether a CW > > MUST be used or not used > > in both directions for PWs not set up using the PWE3 control protocol. > > > > Y(J)S > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > archive/web/pwe3/attachments/20120408/488442e2/attachment.htm> > > > > ------------------------------ > > > > ________ > 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. --=_alternative 005587A4482579DC_= Content-Type: text/html; charset="US-ASCII"
Hi Yaakov,
The use case below may work, but does not mean asymmetric CW for PW would work in all cases. One example is, when CW is used for packet fragmentation, if asymmetric CW is used, packet fragmentation may not be achieved in one direction, and lead to pack loss. Other examples would be OAM tools for PW. IMO, we could consider asymmetric CW as a special implemenation case.

Lizhong
 
------------------------
Yaakov Stein <yaakov_s@rad.com> wrote 2012/04/10 16:14:03:

> Sasha
>  
> The only scenario I can think of where it is really useful, is the
> asymmetric bandwidth and usage case.
>  
> Consider a bandwidth constrained upstream sending very small packets
> (ack's and control signaling) where the CW may be significant overhead,
> and a wide bandwidth downstream sending very large packets (e.g., video),
> where the CW would be useful.
>  
> The mixed static-signaled MS-PW case is not really a constraint.
> If the end-end MS-PW uses (or doesn't) the CW,
> then the configuration of the static segment(s) would need to
> enforce that behavior,
> along with all other parameters.
> This has little to do with the general question of enforcing
> duplexing behavior.
>  
> Y(J)S
>  
>  
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
> Sent: Tuesday, April 10, 2012 11:05
> To: Yaakov Stein
> Cc: Lizhong Jin; pwe3@ietf.org
> Subject: RE: [PWE3] CW usage in opposite directions for static PWs
>  
> Yaakov, and all,
> My reading of RFC 4447 is that in the case of a signaled PW the CW
> is either used or not used bi-directionally by a PW endpoint.
> Further, as per RFC 6073, S-PEs in multi-segment PWs cannot strip,
> insert or manipulate the CW in any way.
> Hence I think that the asymmetric usage of the CW must be prohibited
> in static PWs in order to assure interoperability of MS-PWs
> comprised of static and dynamic segments.
>  
> (On top of that, I do not see any advantage in allowing asymmetric
> usage of the CW, but this is a different story.)
>  
> Regards,
>      Sasha
>  
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Yaakov Stein
> Sent: Tuesday, April 10, 2012 10:39 AM
> To: Lizhong Jin; pwe3@ietf.org
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs
>  
> Lizhong
>  
> OK, maybe I agree. But my point was that this requirement was not
> fully discussed.
>  
> Perhaps a statically configured PW should be able to use the CW in
> one direction while not using it in the other.
>  
> Y(J)S
>  
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Lizhong Jin
> Sent: Monday, April 09, 2012 10:18
> To: pwe3@ietf.org; Yaakov Stein
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs
>  
>
> Hi Yaakov,
> Sorry, word mistake. It should not be OR, but AND operation. If one
> side support and the other side not, then CW will not be used. Then
> the result will be aligned with RFC4447.
>
> Regards
> Lizhong
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sun, 8 Apr 2012 15:28:52 +0000
> > From: Yaakov Stein <yaakov_s@rad.com>
> > To: Lizhong Jin <lizho.jin@gmail.com>
> > Cc: "pwe3@ietf.org" <pwe3@ietf.org>
> > Subject: Re: [PWE3] CW usage in opposite directions for static PWs
> > Message-ID:
> >    <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Lizhong
> >
> > Of course each side needs to KNOW if the other side is using a CW or not;
> > but, that does not mean they can not be asymmetric.
> >
> > What do you mean by OR - that if either CAN use a CW then both MUST use?
> > This is the opposite of 4447.
> >
> >
> > Y(J)S
> >
> > From: Lizhong Jin [mailto:lizho.jin@gmail.com]
> > Sent: Saturday, April 07, 2012 05:58
> > To: Yaakov Stein
> > Cc: pwe3@ietf.org
> > Subject: Re: [PWE3] CW usage in opposite directions for static PWs
> >
> > Hi Yaakov,
> > Thanks for the comments during the session of PWE3.
> > For the static PW, the CW usage should be consisted, otherwise the
> > packet processing would be wrong. The CW nibble is not enough to
> > identify a ACH, and "PW label + CW nibble" is used to identify ACH.
> > IMO, the static PW CW capability could be got by "OR" operation of
> > both local and remote CW parameters.
> >
> > Thanks
> > Lizhong
> >
> > ------------------------------
> >
> > Date: Sun, 1 Apr 2012 12:44:56 +0000
> > From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
> > To: "pwe3@ietf.org<mailto:pwe3@ietf.org>" <pwe3@ietf.org<mailto:
> pwe3@ietf.org
> > >>
> > Subject: [PWE3] CW usage in opposite directions for static PWs
> > Message-ID:
> >        <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il<
> > mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > At the meeting I promised to check when this issue in the subject
> > line was last discussed.
> >
> > It was only a short while ago in Prague (see http://www.ietf.
> > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.ietf.
> > org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>).
> >
> > I recall a lively discussion after the presentation,
> > but the minutes do not show resolution of the issue of whether a CW
> > MUST be used or not used
> > in both directions for PWs not set up using the PWE3 control protocol.
> >
> > Y(J)S
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://www.ietf.org/mail-
> > archive/web/pwe3/attachments/20120408/488442e2/attachment.htm>
> >
> > ------------------------------
> >
> > ________
> 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. --=_alternative 005587A4482579DC_=-- From amalis@gmail.com Tue Apr 10 09:09: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 5EDBE11E80BE for ; Tue, 10 Apr 2012 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 MlBa8s3qZpAR for ; Tue, 10 Apr 2012 09:08:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1213A21F860B for ; Tue, 10 Apr 2012 09:08:59 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2726193ggm.31 for ; Tue, 10 Apr 2012 09:08:58 -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 :cc:content-type; bh=SA2+b+5hMd3Z0QM+Dr9yfJZsEqOHCPvoqpklMsCf4Jg=; b=NtCNWA+ca+gjQ4cpxJGTDiwvMvLoishQUATnxWHiIghbsU4putdP4f3svlaZGIM9iL UlP7tCP6cKpF/NbwXPamEooC3NzcUDEvRfgsYN6CwDXDoezNalRmLMnRvfZ04f9DPGH9 OBNTLIbGHfbH9lVq91Uo9mYZLRKkgcmXZXZFA9Y9FsgHcb2iYHNLP/Mz9WnI43+qtfBA bT/qH/628xjy0m+X/3zjFlzstuBxK3/iKLHFvavsR3xCkg+sAUppZSrw5ZbdDbn4h088 0NOtHUkA3svQUYWSMKJZk6Qp/m4KnbWtE3YgXstfWWMLxWr6Rny/XXCg4RbRu7OJPN1D MEOg== Received: by 10.236.73.169 with SMTP id v29mr10203721yhd.12.1334074138684; Tue, 10 Apr 2012 09:08:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.22.196 with HTTP; Tue, 10 Apr 2012 09:08:38 -0700 (PDT) In-Reply-To: References: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> From: "Andrew G. Malis" Date: Tue, 10 Apr 2012 12:08:38 -0400 Message-ID: To: Lizhong Jin Content-Type: multipart/alternative; boundary=20cf3005121223eb9e04bd555797 Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 10 Apr 2012 16:09:00 -0000 --20cf3005121223eb9e04bd555797 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit All, This has been an extremely useful discussion. Personally, I don't really see much utility in asymmetric CWs in a PW. Once the WG comes to consensus on the issue one way or the other (and I would like to hear some more opinions), we should consider document revisions as necessary to make sure that the consensus is clearly reflected in the RFCs. Cheers, Andy On Tue, Apr 10, 2012 at 11:34 AM, Lizhong Jin wrote: > > Hi Yaakov, > The use case below may work, but does not mean asymmetric CW for PW would > work in all cases. One example is, when CW is used for packet > fragmentation, if asymmetric CW is used, packet fragmentation may not be > achieved in one direction, and lead to pack loss. Other examples would be > OAM tools for PW. IMO, we could consider asymmetric CW as a special > implemenation case. > > Lizhong > > ------------------------ > Yaakov Stein wrote 2012/04/10 16:14:03: > > > Sasha > > > > The only scenario I can think of where it is really useful, is the > > asymmetric bandwidth and usage case. > > > > Consider a bandwidth constrained upstream sending very small packets > > (ack's and control signaling) where the CW may be significant overhead, > > and a wide bandwidth downstream sending very large packets (e.g., video), > > where the CW would be useful. > > > > The mixed static-signaled MS-PW case is not really a constraint. > > If the end-end MS-PW uses (or doesn't) the CW, > > then the configuration of the static segment(s) would need to > > enforce that behavior, > > along with all other parameters. > > This has little to do with the general question of enforcing > > duplexing behavior. > > > > Y(J)S > > > > > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Tuesday, April 10, 2012 11:05 > > To: Yaakov Stein > > Cc: Lizhong Jin; pwe3@ietf.org > > Subject: RE: [PWE3] CW usage in opposite directions for static PWs > > > > Yaakov, and all, > > My reading of RFC 4447 is that in the case of a signaled PW the CW > > is either used or not used bi-directionally by a PW endpoint. > > Further, as per RFC 6073, S-PEs in multi-segment PWs cannot strip, > > insert or manipulate the CW in any way. > > Hence I think that the asymmetric usage of the CW must be prohibited > > in static PWs in order to assure interoperability of MS-PWs > > comprised of static and dynamic segments. > > > > (On top of that, I do not see any advantage in allowing asymmetric > > usage of the CW, but this is a different story.) > > > > Regards, > > Sasha > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Yaakov Stein > > Sent: Tuesday, April 10, 2012 10:39 AM > > To: Lizhong Jin; pwe3@ietf.org > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > > > Lizhong > > > > OK, maybe I agree. But my point was that this requirement was not > > fully discussed. > > > > Perhaps a statically configured PW should be able to use the CW in > > one direction while not using it in the other. > > > > Y(J)S > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Lizhong Jin > > Sent: Monday, April 09, 2012 10:18 > > To: pwe3@ietf.org; Yaakov Stein > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > > > > > Hi Yaakov, > > Sorry, word mistake. It should not be OR, but AND operation. If one > > side support and the other side not, then CW will not be used. Then > > the result will be aligned with RFC4447. > > > > Regards > > Lizhong > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Sun, 8 Apr 2012 15:28:52 +0000 > > > From: Yaakov Stein > > > To: Lizhong Jin > > > Cc: "pwe3@ietf.org" > > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > > Message-ID: > > > <07F7D7DED63154409F13298786A2ADC904363878@EXRAD5.ad.rad.co.il> > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Lizhong > > > > > > Of course each side needs to KNOW if the other side is using a CW or > not; > > > but, that does not mean they can not be asymmetric. > > > > > > What do you mean by OR - that if either CAN use a CW then both MUST > use? > > > This is the opposite of 4447. > > > > > > > > > Y(J)S > > > > > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > > > Sent: Saturday, April 07, 2012 05:58 > > > To: Yaakov Stein > > > Cc: pwe3@ietf.org > > > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > > > > > Hi Yaakov, > > > Thanks for the comments during the session of PWE3. > > > For the static PW, the CW usage should be consisted, otherwise the > > > packet processing would be wrong. The CW nibble is not enough to > > > identify a ACH, and "PW label + CW nibble" is used to identify ACH. > > > IMO, the static PW CW capability could be got by "OR" operation of > > > both local and remote CW parameters. > > > > > > Thanks > > > Lizhong > > > > > > ------------------------------ > > > > > > Date: Sun, 1 Apr 2012 12:44:56 +0000 > > > From: Yaakov Stein > > > > To: "pwe3@ietf.org" > pwe3@ietf.org > > > >> > > > Subject: [PWE3] CW usage in opposite directions for static PWs > > > Message-ID: > > > <07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il< > > > mailto:07F7D7DED63154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il>> > > > Content-Type: text/plain; charset="us-ascii" > > > > > > At the meeting I promised to check when this issue in the subject > > > line was last discussed. > > > > > > It was only a short while ago in Prague (see http://www.ietf. > > > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11 > > org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>). > > > > > > I recall a lively discussion after the presentation, > > > but the minutes do not show resolution of the issue of whether a CW > > > MUST be used or not used > > > in both directions for PWs not set up using the PWE3 control protocol. > > > > > > Y(J)S > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > archive/web/pwe3/attachments/20120408/488442e2/attachment.htm> > > > > > > ------------------------------ > > > > > > ________ > > 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 > > --20cf3005121223eb9e04bd555797 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable All,

This has been an extremely useful discussion.

<wg cha= ir hat off>

Personally, I don't really see much utility in as= ymmetric CWs in a PW.

<wg chair hat on>

Once the WG com= es to consensus on the issue one way or the other (and I would like to hear= some more opinions), we should consider document revisions as necessary to= make sure that the consensus is clearly reflected in the RFCs.

Cheers,
Andy

On Tue, Apr 10, 2012 = at 11:34 AM, Lizhong Jin <lizhong.jin@zte.com.cn> wrote:

Hi Yaakov,
The use case below may work, but does not mean asymmetric CW for PW would work in all cases. One example is, when CW is used for packet fragmentation, if asymmetric CW is used, packet fragmentation may not be achieved in one direction, and lead to pack loss. Other examples would be OAM tools for PW. IMO, we could consider asymmetric CW as a special implemenation case.

Lizhong
 
------------------------
Yaakov Stein <yaakov_s@rad.com> wrote 2012/04/10 16:14:03:

> Sasha
>  
> The only scenario I can think of where it is really useful, is the
> asymmetric bandwidth and usage case.
>  
> Consider a bandwidth constrained upstream sending very small packets
> (ack's and control signaling) where the CW may be significant overhead,
> and a wide bandwidth downstream sending very large packets (e.g., video),
> where the CW would be useful.
>  
> The mixed static-signaled MS-PW case is not really a constraint.
> If the end-end MS-PW uses (or doesn't) the CW,<= /font>
> then the configuration of the static segment(s) would need to
> enforce that behavior,
> along with all other parameters.
> This has little to do with the general question of enforcing
> duplexing behavior.
>  
> Y(J)S
>  
>  
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecite= le.com]
> Sent: Tuesday, April 10, 2012 11:05
> To: Yaakov Stein
> Cc: Lizhong Jin; pw= e3@ietf.org
> Subject: RE: [PWE3] CW usage in opposite directions for static PWs
>  
> Yaakov, and all,
> My reading of RFC 4447 is that in the case of a signaled PW the CW
> is either used or not used bi-directionally by a PW endpoint.
> Further, as per RFC 6073, S-PEs in multi-segment PWs cannot strip,
> insert or manipulate the CW in any way.
> Hence I think that the asymmetric usage of the CW must be prohibited
> in static PWs in order to assure interoperability of MS-PWs
> comprised of static and dynamic segments.
>  
> (On top of that, I do not see any advantage in allowing asymmetric
> usage of the CW, but this is a different story.)
>  
> Regards,
>      Sasha
>  
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Yaakov Stein
> Sent: Tuesday, April 10, 2012 10:39 AM
> To: Lizhong Jin; pw= e3@ietf.org
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs
>  
> Lizhong
>  
> OK, maybe I agree. But my point was that this requirement was not
> fully discussed.
>  
> Perhaps a statically configured PW should be able to use the CW in
> one direction while not using it in the other.
>  
> Y(J)S
>  
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Lizhong Jin
> Sent: Monday, April 09, 2012 10:18
> To: pwe3@ietf.org; Yaakov Stein
> Subject: Re: [PWE3] CW usage in opposite directions for static PWs
>  
>
> Hi Yaakov,
> Sorry, word mistake. It should not be OR, but AND operation. If one
> side support and the other side not, then CW will not be used. Then
> the result will be aligned with RFC4447.
>
> Regards
> Lizhong
>
> > -----------------------------------------------------------------= -----
> >
> > Message: 1
> > Date: Sun, 8 Apr 2012 15:28:52 +0000
> > From: Yaakov Stein <yaakov_s@rad.com>
> > To: Lizhong Jin <lizho.jin@gmail.com>
> > Cc: "pwe3= @ietf.org" <= pwe3@ietf.org>
> > Subject: Re: [PWE3] CW usage in opposite directions for static PWs
> > Message-ID:
> >    <07F7D7DED63154409F1329878= 6A2ADC904363878@EXRAD5.ad.rad.co.il>
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > Lizhong
> >
> > Of course each side needs to KNOW if the other side is using a CW or not;
> > but, that does not mean they can not be asymmetric.
> >
> > What do you mean by OR - that if either CAN use a CW then both MUST use?
> > This is the opposite of 4447.
> >
> >
> > Y(J)S
> >
> > From: Lizhong Jin [mailto:lizho.jin@gmail.com]
> > Sent: Saturday, April 07, 2012 05:58
> > To: Yaakov Stein
> > Cc: pwe3@ietf.= org
> > Subject: Re: [PWE3] CW usage in opposite directions for static PWs
> >
> > Hi Yaakov,
> > Thanks for the comments during the session of PWE3.
> > For the static PW, the CW usage should be consisted, otherwise the
> > packet processing would be wrong. The CW nibble is not enough to
> > identify a ACH, and "PW label + CW nibble" is used to identify ACH.
> > IMO, the static PW CW capability could be got by "OR" operation of
> > both local and remote CW parameters.
> >
> > Thanks
> > Lizhong
> >
> > ------------------------------
> >
> > Date: Sun, 1 Apr 2012 12:44:56 +0000
> > From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
> > To: "pwe3= @ietf.org<mailto:= pwe3@ietf.org>" <pwe3@ietf.org<mailto:
> pwe3@ietf.org > > >>
> > Subject: [PWE3] CW usage in opposite directions for static PWs > > Message-ID:
> >        <07F7D7DED63= 154409F13298786A2ADC904332092@EXRAD5.ad.rad.co.il<
> > mailto:07F7D7DED63154409F13298786A2ADC9043= 32092@EXRAD5.ad.rad.co.il>>
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > At the meeting I promised to check when this issue in the subject
> > line was last discussed.
> >
> > It was only a short while ago in Prague (see http://www.ietf.
> > org/proceedings/80/slides/pwe3-3.pdf slides 9 - 11<http://www.ietf.
> > org/proceedings/80/slides/pwe3-3.pdf%20slides%209%20-%2011>).<= br> > >
> > I recall a lively discussion after the presentation,
> > but the minutes do not show resolution of the issue of whether a CW
> > MUST be used or not used
> > in both directions for PWs not set up using the PWE3 control protocol.
> >
> > Y(J)S
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <= http://www.ietf.org/mail-
> > archive/web/pwe3/attachments/20120408/488442e2/attachment.htm>=
> >
> > ------------------------------
> >
> > ________
> 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
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--20cf3005121223eb9e04bd555797-- From stbryant@cisco.com Tue Apr 10 09:14:06 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 AD89C11E80CB for ; Tue, 10 Apr 2012 09:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 F9FIGitIfEqm for ; Tue, 10 Apr 2012 09:14:06 -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 EA0D911E80BE for ; Tue, 10 Apr 2012 09:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=641; q=dns/txt; s=iport; t=1334074446; x=1335284046; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IslHzSASE+/zT1G4HiQwOr17I5/xFUjuu2lPvDpHS9M=; b=YlqnDcYSAKLOhw3VeAeP+VRal8VO0OuiUIIPlAswNrLIM8aO63TlUFS8 3JAAQwb2iOXwMfw6bsbTTro1IpqqwShJHKwoK0UdLSfCd8lvoyjaAsuTu JwkjfIb0lO64fKTfslGriowKEXNqY7qNGTt57O/xhrAvLvdjs+Tv33dZy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIFbhE+Q/khM/2dsb2JhbABEtimDA4EHggkBAQEEEgECI0ABEAsYCRYPCQMCAQIBRQYNAQcBAR6HbJpjgz4QnHeQYQSVbI5NgQJngmg X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="134737820" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 16:14:04 +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 q3AGE4eJ011663; Tue, 10 Apr 2012 16:14:04 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3AGE12v001897; Tue, 10 Apr 2012 17:14:02 +0100 (BST) Message-ID: <4F845C49.1070900@cisco.com> Date: Tue, 10 Apr 2012 17:14:01 +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: "Andrew G. Malis" References: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lizhong Jin , "pwe3@ietf.org" , Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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: Tue, 10 Apr 2012 16:14:06 -0000 On 10/04/2012 17:08, Andrew G. Malis wrote: > All, > > This has been an extremely useful discussion. > > > > Personally, I don't really see much utility in asymmetric CWs in a PW. > > > > Once the WG comes to consensus on the issue one way or the other (and > I would like to hear some more opinions), we should consider document > revisions as necessary to make sure that the consensus is clearly > reflected in the RFCs. > > Cheers, > Andy For LDP signaled PWs, I don't think there is any ambiguity, the CW handling is symmetric. Does anyone read it any other way? Stewart From Alexander.Vainshtein@ecitele.com Tue Apr 10 12:58:51 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 977BE21F8539 for ; Tue, 10 Apr 2012 12:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=-1.499, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 Qn6MqGjDJ96R for ; Tue, 10 Apr 2012 12:58:51 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 99FCD21F84B8 for ; Tue, 10 Apr 2012 12:58:50 -0700 (PDT) Received: from [85.158.143.99:57301] by server-1.bemta-4.messagelabs.com id A6/32-20925-9F0948F4; Tue, 10 Apr 2012 19:58:49 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1334087928!19696171!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.7; banners=-,-,- Received: (qmail 20049 invoked from network); 10 Apr 2012 19:58:49 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-7.tower-216.messagelabs.com with SMTP; 10 Apr 2012 19:58:49 -0000 X-AuditID: a8571402-b7f796d00000340a-d7-4f848f30f017 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id DA.17.13322.03F848F4; Tue, 10 Apr 2012 21:51:13 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.167]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 21:58:47 +0200 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFiDmqCfMYw5MQ0qbOiTyhnYHbZaTjDEAgAAlojD//+QrgIAAevgAgAAJoQCAAAGBgIAAXvm1 Date: Tue, 10 Apr 2012 19:58:46 +0000 Message-ID: References: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> , <4F845C49.1070900@cisco.com> In-Reply-To: <4F845C49.1070900@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJsWRmVeSWpSXmKPExsXCxcggpWvY3+JvsP4dm8W9q8vYLY52/WO0 6Pu0hcXi3NM5jBYfun6wOrB6TPm9kdVj56y77B5Llvxk8pi0Ns1jzb4fLAGsUQ2MNol5efkl iSWpCimpxcm2SgFFmWWJyZVKCpkptkqGSgoFOYnJqbmpeSW2SokFBal5KUp2XAoYwAaoLDNP ITUvOT8lMy/dVskz2F/XwsLUUtdQyS4kI7NYIVU3NzEzRyE3tbg4MT1VASgC8kpeSsI65oxf q9YzFZzkqfh9cS9zA2MXVxcjJ4eEgInEmYabLBC2mMSFe+vZuhi5OIQErjBKPNu6hxEkISSw lFHi7kw9EJtNwFZi0+q7bCC2iICuxOwNNxhBGpgFJjFKbLtxAyjBwSEs4CRx4rgfRI2zxJH7 T5kg7CiJt79/gy1jEVCVWDG5hxXE5hXwlZj5exkTxK7vjBJzTuaB2JwCmhJHV84G28UIdNz3 U2vAapgFxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2PISm7c+ZoWo15FYsPsTG4StLbFs4Wtm iL2CEidnPoF6XlLi4IobLBMYxWchWTELSfssJO2zkLQvYGRZxSjhFuTp4hMQEOxkYGCk5+rs GeLq46rn7O+7iRGYhlaEizDtYGy+aXiIUYCDUYmH18O3xV+INbGsuDL3EKMkB5OSKK/ABKAQ X1J+SmVGYnFGfFFpTmrxIUYJDmYlEd5TeUA53pTEyqrUonyYlAUwECcyS3En54OiuCTe2MAA haMkzhsXZOcvJJAOTHfZqakFqUUwrTIcHEoSvGEgGwWLUtNTK9Iyc0oQ0kwcnCCbeYA2J4LU 8BYXJOYWZ6ZD5E8xSkqJ83qDJARAEhmleXC9rxjFgf4T5i0CyfIA0x5c1yuggUxAAw3uN4MM BOYFuJRUAyPr7Av1olVb3vwpC0l/vbj5gSjD43dZpgt2ayyMvvg73qrk2Jc7/6/dnvPBOKJ6 sQT3A/sbSlcvJPDtyPy85/imXj59sXN1brd2CzqH1rN+OPb+yffalRLsJZ+mXd8WeOWRnvb1 exmsF1K/FYlLFYet9K/bmPJBaELy1bYLZ7USldfbnVmVGOauxFKckWioxVxUnAgAI0Mc8wME AAA= Cc: Lizhong Jin , "pwe3@ietf.org" , Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 10 Apr 2012 19:58:51 -0000 Stewart, You've written: For LDP signaled PWs, I don't think there is any ambiguity, the CW handling is symmetric. Does anyone read it any other way? This matches my reading exactly, and this is why I would oppose allowing asy= mmetric CW usage for static PWs: I do not think that it is healthy to allow= operational static PWs that cannot be ever signaled. (I do not object to having *non-operational* static PWs that, if signaled, w= ould never be set up:-). My 2c, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Stewart Bry= ant [stbryant@cisco.com] Sent: Tuesday, April 10, 2012 6:14 PM To: Andrew G. Malis Cc: Lizhong Jin; pwe3@ietf.org; Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs On 10/04/2012 17:08, Andrew G. Malis wrote: > All, > > This has been an extremely useful discussion. > > > > Personally, I don't really see much utility in asymmetric CWs in a PW. > > > > Once the WG comes to consensus on the issue one way or the other (and > I would like to hear some more opinions), we should consider document > revisions as necessary to make sure that the consensus is clearly > reflected in the RFCs. > > Cheers, > Andy For LDP signaled PWs, I don't think there is any ambiguity, the CW handling is symmetric. Does anyone read it any other way? Stewart _______________________________________________ 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 adrian@olddog.co.uk Tue Apr 10 13:12: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 546EB21F850C; Tue, 10 Apr 2012 13:12:55 -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 KrqdyRV-iknh; Tue, 10 Apr 2012 13:12:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 2629921F8501; Tue, 10 Apr 2012 13:12:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3AKCp3m011940; Tue, 10 Apr 2012 21:12:51 +0100 Received: from 950129200 (AGrenoble-551-1-43-107.w92-157.abo.wanadoo.fr [92.157.202.107]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3AKCnJE011920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 21:12:50 +0100 From: "Adrian Farrel" To: References: <20120410200214.21728.80545.idtracker@ietfa.amsl.com> In-Reply-To: <20120410200214.21728.80545.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 21:12:50 +0100 Message-ID: <110101cd1756$4f01b270$ed051750$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIF569mwn8deiFiORYDjqgwh+Kp2ZYi3HdQ Content-Language: en-gb Cc: mpls@ietf.org, pwe3@ietf.org Subject: [PWE3] FW: New Version Notification - draft-betts-itu-oam-ach-code-point-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:12:55 -0000 Hi, Malcolm has been busy working on a new version of this I-D to address = the issues and comments raised during IETF last call. I have had a look at the changes (and supplied some suggestions) as = sponsoring AD. I think that this version is a pretty fine attempt at = addressing the concerns. Please hang in there while we put together some emails to explain the = changes and respond to the specific concerns that were raised. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 10 April 2012 21:02 > To: malcolm.betts@zte.com.cn; draft-betts-itu-oam-ach-code- > point@tools.ietf.org; Huub.van.Helvoort@huawei.com; = adrian@olddog.co.uk > Subject: New Version Notification - = draft-betts-itu-oam-ach-code-point-04.txt >=20 > New version (-04) has been submitted for = draft-betts-itu-oam-ach-code-point- > 04.txt: > = http://www.ietf.org/internet-drafts/draft-betts-itu-oam-ach-code-point-04= .txt >=20 > Diff from previous version: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-betts-itu-oam-ach-code-point-0= 4 >=20 > IETF Secretariat. From yaakov_s@rad.com Wed Apr 11 00:51: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 6E08621F86D3 for ; Wed, 11 Apr 2012 00:51:09 -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=[AWL=0.000, 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 Ee3yFjoglte1 for ; Wed, 11 Apr 2012 00:51:08 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4A821F86D5 for ; Wed, 11 Apr 2012 00:51:05 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 11 Apr 2012 10:39: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; Wed, 11 Apr 2012 10:51:00 +0300 From: Yaakov Stein To: "stbryant@cisco.com" , "Andrew G. Malis" Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFiDmR8k+8boiWEyuusmNJqhMmZaTrS8Q///VpYCAADKjoIAASrsAgAAJogCAAAGBgIABNpqg Date: Wed, 11 Apr 2012 07:50:59 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC90436DBCA@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> <4F845C49.1070900@cisco.com> In-Reply-To: <4F845C49.1070900@cisco.com> 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.0A02020B.4F8537E5.002A,ss=1,fgs=0 Cc: Lizhong Jin , "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 11 Apr 2012 07:51:10 -0000 Stewart Of course the PWE3 control protocol is clear in enforcing the use of non-us= e in both directions. Even there, I do not recall debate on the subject. It was "yeah, I guess th= at's OK". In my slide deck a few years back I discussed the state of affairs for othe= r methods of setting up PWs=20 I am OK with a decision to enforce the symmetry, but we need to discuss this and agree on it. And perhaps there are other parameters that need similar discussion. For example, can I set up a TDM PW with an E1 in one direction and a T1 in = the other ? What about a raw Ethernet PW in one direction and a tagged one in the oppos= ite direction ? If this is a general principle (as I suspect many people believe, but I don= 't recall was ever explicitly stated) then this should be written up (and the implications considered). Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Tuesday, April 10, 2012 19:14 To: Andrew G. Malis Cc: Lizhong Jin; pwe3@ietf.org; Yaakov Stein Subject: Re: [PWE3] CW usage in opposite directions for static PWs On 10/04/2012 17:08, Andrew G. Malis wrote: > All, > > This has been an extremely useful discussion. > > > > Personally, I don't really see much utility in asymmetric CWs in a PW. > > > > Once the WG comes to consensus on the issue one way or the other (and=20 > I would like to hear some more opinions), we should consider document=20 > revisions as necessary to make sure that the consensus is clearly=20 > reflected in the RFCs. > > Cheers, > Andy For LDP signaled PWs, I don't think there is any ambiguity, the CW=20 handling is symmetric. Does anyone read it any other way? Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Wed Apr 11 02:55: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 65E3A11E80B7 for ; Wed, 11 Apr 2012 02:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 7f3LBJTbbFek for ; Wed, 11 Apr 2012 02:55:04 -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 6F16111E809F for ; Wed, 11 Apr 2012 02:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2268; q=dns/txt; s=iport; t=1334138104; x=1335347704; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=L4aFAWvsPg3xJgcQzfFq3AojDj8Tz4V9a60HEMFYcxI=; b=LhhQvIS3VxjZT3e2Nnl+kd72jUMSxqbjPWdUCc5Blx3IKCEOe7GM/cct Fy7N0EClPotkDQnafA7/aoMegjSkF9rhz5shDA7vYKszoeuMYaifP42/Q TA5+XTIX/tjKMAta7HRISv5yvvhvTOv7aUMl5+o5jtCE1CdkazUwGyRNz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGxUhU+Q/khL/2dsb2JhbABFuUaBB4IJAQEBBAEBAQ8BAiM2CgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAR6HbAuaQoM/EJxhkT8ElWyOTYECZ4Jo X-IronPort-AV: E=Sophos;i="4.75,404,1330905600"; d="scan'208";a="70559223" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2012 09:55:03 +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 q3B9t318031845; Wed, 11 Apr 2012 09:55:03 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3B9t1nL027092; Wed, 11 Apr 2012 10:55:01 +0100 (BST) Message-ID: <4F8554F5.5080504@cisco.com> Date: Wed, 11 Apr 2012 10:55:01 +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: Yaakov Stein References: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> <4F845C49.1070900@cisco.com> <07F7D7DED63154409F13298786A2ADC90436DBCA@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC90436DBCA@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lizhong Jin , "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 11 Apr 2012 09:55:05 -0000 Yaakov Why not come at this from a different direction. Is there an application which requires asymmetry? Stewart On 11/04/2012 08:50, Yaakov Stein wrote: > Stewart > > Of course the PWE3 control protocol is clear in enforcing the use of non-use in both directions. > Even there, I do not recall debate on the subject. It was "yeah, I guess that's OK". > > In my slide deck a few years back I discussed the state of affairs for other methods of setting up PWs > > I am OK with a decision to enforce the symmetry, > but we need to discuss this and agree on it. > And perhaps there are other parameters that need similar discussion. > For example, can I set up a TDM PW with an E1 in one direction and a T1 in the other ? > What about a raw Ethernet PW in one direction and a tagged one in the opposite direction ? > > If this is a general principle (as I suspect many people believe, but I don't recall was ever explicitly stated) > then this should be written up (and the implications considered). > > Y(J)S > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, April 10, 2012 19:14 > To: Andrew G. Malis > Cc: Lizhong Jin; pwe3@ietf.org; Yaakov Stein > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > On 10/04/2012 17:08, Andrew G. Malis wrote: >> All, >> >> This has been an extremely useful discussion. >> >> >> >> Personally, I don't really see much utility in asymmetric CWs in a PW. >> >> >> >> Once the WG comes to consensus on the issue one way or the other (and >> I would like to hear some more opinions), we should consider document >> revisions as necessary to make sure that the consensus is clearly >> reflected in the RFCs. >> >> Cheers, >> Andy > For LDP signaled PWs, I don't think there is any ambiguity, the CW > handling is symmetric. Does anyone read it any other way? > > Stewart > > _______________________________________________ > 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 yaakov_s@rad.com Wed Apr 11 09:24: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 7C52A21F8581 for ; Wed, 11 Apr 2012 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NPtecVgD5pQS for ; Wed, 11 Apr 2012 09:24:57 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3815A21F8584 for ; Wed, 11 Apr 2012 09:24:54 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 11 Apr 2012 19:12:54 +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, 11 Apr 2012 19:24:50 +0300 From: Yaakov Stein To: "stbryant@cisco.com" Thread-Topic: [PWE3] CW usage in opposite directions for static PWs Thread-Index: AQHNFiDmR8k+8boiWEyuusmNJqhMmZaTrS8Q///VpYCAADKjoIAASrsAgAAJogCAAAGBgIABNpqg///x1oCAAJ2egA== Date: Wed, 11 Apr 2012 16:24:50 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC90436EED3@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC90436C45A@EXRAD5.ad.rad.co.il> <4F845C49.1070900@cisco.com> <07F7D7DED63154409F13298786A2ADC90436DBCA@EXRAD5.ad.rad.co.il> <4F8554F5.5080504@cisco.com> In-Reply-To: <4F8554F5.5080504@cisco.com> 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.0A020208.4F85B053.012A,ss=1,fgs=0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] CW usage in opposite directions for static PWs 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, 11 Apr 2012 16:24:58 -0000 Stewart My way of looking at it is different. Are we sure that we want to rule out asymmetry ? If we had BW reservation for PWs I would be sure that my answer would be no= . However, while I can't think of many concrete examples (perhaps others on the list have some good ones) I don't like ruling things out for no reason. A wildly successful protocol (RFC 5+something) is one that can be used=20 for cases that we didn't think about when we defined it. Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Wednesday, April 11, 2012 12:55 To: Yaakov Stein Cc: Lizhong Jin; pwe3@ietf.org Subject: Re: [PWE3] CW usage in opposite directions for static PWs Yaakov Why not come at this from a different direction. Is there an application which requires asymmetry? Stewart On 11/04/2012 08:50, Yaakov Stein wrote: > Stewart > > Of course the PWE3 control protocol is clear in enforcing the use of non-= use in both directions. > Even there, I do not recall debate on the subject. It was "yeah, I guess = that's OK". > > In my slide deck a few years back I discussed the state of affairs for ot= her methods of setting up PWs > > I am OK with a decision to enforce the symmetry, > but we need to discuss this and agree on it. > And perhaps there are other parameters that need similar discussion. > For example, can I set up a TDM PW with an E1 in one direction and a T1 i= n the other ? > What about a raw Ethernet PW in one direction and a tagged one in the opp= osite direction ? > > If this is a general principle (as I suspect many people believe, but I d= on't recall was ever explicitly stated) > then this should be written up (and the implications considered). > > Y(J)S > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of S= tewart Bryant > Sent: Tuesday, April 10, 2012 19:14 > To: Andrew G. Malis > Cc: Lizhong Jin; pwe3@ietf.org; Yaakov Stein > Subject: Re: [PWE3] CW usage in opposite directions for static PWs > > On 10/04/2012 17:08, Andrew G. Malis wrote: >> All, >> >> This has been an extremely useful discussion. >> >> >> >> Personally, I don't really see much utility in asymmetric CWs in a PW. >> >> >> >> Once the WG comes to consensus on the issue one way or the other (and >> I would like to hear some more opinions), we should consider document >> revisions as necessary to make sure that the consensus is clearly >> reflected in the RFCs. >> >> Cheers, >> Andy > For LDP signaled PWs, I don't think there is any ambiguity, the CW > handling is symmetric. Does anyone read it any other way? > > Stewart > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --=20 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 From internet-drafts@ietf.org Fri Apr 13 06:15: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 C13F321F865F; Fri, 13 Apr 2012 06:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 Cy5E59Uo6rkn; Fri, 13 Apr 2012 06:15:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454B921F8603; Fri, 13 Apr 2012 06:15: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.00 Message-ID: <20120413131528.30797.16095.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 06:15:28 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-cbit-negotiation-03.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, 13 Apr 2012 13:15: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 : Pseudowire Control Word Negotiation Mechanism Update Author(s) : Lizhong Jin Raymond Key Simon Delord Thomas Nadeau Vishwas Manral Sami Boutros Reshad Rahman Filename : draft-ietf-pwe3-cbit-negotiation-03.txt Pages : 8 Date : 2012-04-13 This document describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This document is to update [RFC4447] control word negotiation mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-03.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-cbit-negotiation-03.txt From iesg-secretary@ietf.org Mon Apr 16 09:33:51 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 3476811E80AD; Mon, 16 Apr 2012 09:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 og6QbyA7ieSi; Mon, 16 Apr 2012 09:33:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC90311E80A4; Mon, 16 Apr 2012 09:33:50 -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.00 Message-ID: <20120416163350.4446.64763.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2012 09:33:50 -0700 Cc: pwe3@ietf.org Subject: [PWE3] Additional Last Call: RFC-to-be 6478, previously draft-ietf-pwe3-static-pw-status-10.txt (Pseudowire Status for Static Pseudowires) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:33:51 -0000 Due to technical changes made during AUTH48, the IESG is issuing an additional Last Call on the following document: - 'Pseudowire Status for Static Pseudowires' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a mechanism to signal Pseudowire (PW) status messages using an 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 OAM message mapping and PW redundancy to operate on static PWs. This document also updates rfc5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status signaling information. The file can be obtained via http://www.rfc-editor.org/authors/rfc6478.txt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/ballot/ No IPR declarations have been submitted directly on this I-D. From Internet-Drafts@ietf.org Mon Apr 16 13:38: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 E320E21F8559; Mon, 16 Apr 2012 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 WUa-L7MeTL-r; Mon, 16 Apr 2012 13:38:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55E21F854C; Mon, 16 Apr 2012 13:38:30 -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.00 Message-ID: <20120416203830.31258.54490.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2012 13:38:30 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-mpls-eth-oam-iwk-05.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, 16 Apr 2012 20:38:31 -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 : MPLS and Ethernet OAM Interworking Author(s) : D. Mohan, et al Filename : draft-ietf-pwe3-mpls-eth-oam-iwk Pages : 20 Date : April 16, 2012 This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-eth-oam-iwk-05.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-ietf-pwe3-mpls-eth-oam-iwk"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-04-16133830.I-D@ietf.org> --NextPart-- From stbryant@cisco.com Tue Apr 17 04:31: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 0539B21F8670; Tue, 17 Apr 2012 04:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.56 X-Spam-Level: X-Spam-Status: No, score=-110.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 57a7l++ilyzi; Tue, 17 Apr 2012 04:30:58 -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 BF5B921F866D; Tue, 17 Apr 2012 04:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1967; q=dns/txt; s=iport; t=1334662238; x=1335871838; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JY/b5ebLVlTQK83IPc0NnZLmozyQsBsnJM8cYuR1FeU=; b=II/z32zfwRDlqxAwj46LH27UCAwfhvn6+WzhzVw5resgSIfN79ciRLRq v6RftAm0CcMFJW07uTo3P3bKoTlzlSulhQzQ8cjGj9Yea8ewI4z6jLdNL ZgfFmSybdXbrCF43SVhkhxiY0+BMScvEqPEiT8E4EBcY4ICbS+riLQCj8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADxTjU+Q/khM/2dsb2JhbABEsS2BB4IJAQEBBBIBAiM2CgEQCxgJFgQLCQMCAQIBNBETAQUCAQEeh2wLmWyDPxCcSo1TgyQElW+BEY08gQJngmiBWw X-IronPort-AV: E=Sophos;i="4.75,433,1330905600"; d="scan'208";a="71063443" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 17 Apr 2012 11:30:36 +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 q3HBUaGW029249; Tue, 17 Apr 2012 11:30:36 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3HBUWaZ027712; Tue, 17 Apr 2012 12:30:34 +0100 (BST) Message-ID: <4F8D5458.2000700@cisco.com> Date: Tue, 17 Apr 2012 12:30:32 +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: ietf@ietf.org References: <20120416163350.4446.64763.idtracker@ietfa.amsl.com> In-Reply-To: <20120416163350.4446.64763.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, The IESG , IETF-Announce Subject: Re: [PWE3] Additional Last Call: RFC-to-be 6478, previously draft-ietf-pwe3-static-pw-status-10.txt (Pseudowire Status for Static Pseudowires) to Proposed Standard 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: Tue, 17 Apr 2012 11:31:03 -0000 To clarify The text that needs to be reviewed is the text in the RFC editor's queue http://www.rfc-editor.org/authors/rfc6478.txt Note that the URL for the text in the RFC Editor's queue, provided in the original email, contains a spurious trailing space. Stewart On 16/04/2012 17:33, The IESG wrote: > Due to technical changes made during AUTH48, the IESG is issuing an > additional Last Call on the following document: > > - 'Pseudowire Status for Static Pseudowires' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-04-30. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies a mechanism to signal Pseudowire (PW) status > messages using an 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 OAM message mapping and PW redundancy to operate on static PWs. > This document also updates rfc5885 in the case when Bi-directional > Forwarding Detection (BFD) is used to convey PW status signaling > information. > > > > > The file can be obtained via > http://www.rfc-editor.org/authors/rfc6478.txt/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From internet-drafts@ietf.org Tue Apr 17 11:55: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 6905D11E80A0; Tue, 17 Apr 2012 11:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 W+oYvELkG4eC; Tue, 17 Apr 2012 11:55:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0883911E80B0; Tue, 17 Apr 2012 11:55: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.00 Message-ID: <20120417185528.18649.61480.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 11:55:28 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-vccv-impl-survey-results-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: Tue, 17 Apr 2012 18:55:32 -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 : The Pseudowire (PW) & Virtual Circuit Connectivity Verif= ication (VCCV) Implementation Survey Results Author(s) : Verizon Communications Inc Filename : draft-ietf-pwe3-vccv-impl-survey-results-00.txt Pages : 37 Date : 2012-04-17 Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-impl-survey-result= s-00.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-impl-survey-results= -00.txt From matthew.bocci@alcatel-lucent.com Wed Apr 18 02:09:01 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 E26F821F85D6; Wed, 18 Apr 2012 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.19 X-Spam-Level: X-Spam-Status: No, score=-109.19 tagged_above=-999 required=5 tests=[AWL=1.058, 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 XOcjCF-0I58G; Wed, 18 Apr 2012 02:08:57 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7370621F85CD; Wed, 18 Apr 2012 02:08:57 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3I98To8005723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2012 11:08:54 +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; Wed, 18 Apr 2012 11:08:44 +0200 From: "Bocci, Matthew (Matthew)" To: The IESG Date: Wed, 18 Apr 2012 11:08:43 +0200 Thread-Topic: Publication request for draft-ietf-pwe3-eth-oam-iwk-05.txt Thread-Index: Ac0dQtqiaaCSNYOuTJenIc1PqnCrlg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBB3159C292FCmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "pwe3@ietf.org" , Stewart Bryant Subject: [PWE3] Publication request for draft-ietf-pwe3-eth-oam-iwk-05.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, 18 Apr 2012 09:09:02 -0000 --_000_CBB3159C292FCmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PWE3 working group requests the publication of draft-ietf-pwe3-eth-oam-= iwk-05.txt. The document write-up is attached below. Best regards, Matthew --------- draft-ietf-pwe3-mpls-eth-oam-iwk-05.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has received significant review by the WG and received a number of comments during WG last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) 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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. (1.f) 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 entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are a couple of minor I-D nits related to a possibly out = of date reference to draft-ietf-pwe3-oam-message-map and some formatting iss= ues. One of the author's email addresses also appears to be incorrect. These should be fixed before publication. There are no formal review criteria. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists. There are no requests of IANA= , which seems reasonable given that the document uses existing OAM mechanisms and LDP status messaging code points. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) 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 specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. This document is a product of the PWE3 working group. This document is Standards Track. Working Group Summary Solutions for mapping OAM messages related to defect notifications from attachement circuits to PWs for ATM, FR, and TDM services were specified in RFC6310. This RFC did not cover Ethernet attachment circuits because of a perception at the time that Ethernet OAM mechanisms were less widel= y deployed and their standardization was on-going. The WG decided to handl= e the Ethernet case in a separate draft, which is the subject of this proto write-up. This was considered to be an important work item by the PWE3 working group, and there were a number of requests to roll this wor= king into the draft that became RFC6310. However, ultimately the consensus wa= s to progress the Ethernet case separately to not further delay RFC6310. Document Quality Previous PW deployment surveys (see draft-ietf-pwe3-pw-vccv-impl-survey-results-00) have indicated that the majority of PWs are Ethernet, and therefore standardizing the interworki= ng of defect notifications for emulated Ethernet services is expected to be of significant interest to the IETF and the operator community in genera= l. There are believed to be numerous implementations and deployments of Eth= ernet OAM mechanisms referred to in this draft, including cases where the Ethe= rnet service is supported over Pws. The document does not specify any MIB changes or additions which would n= eed review. Personnel The document shepherd is Matthew Bocci. The responsible Area Director is Stewart Bryant. --_000_CBB3159C292FCmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The PWE3 working group r= equests the publication of draft-ietf-pwe3-eth-oam-iwk-05.txt.
The document write-up is attached below.

<= div>Best regards,

Matthew

---------

draft-ietf-pwe3-mpls-eth-oam-iwk-0= 5.txt

Document Shepard Write-Up


    (1.a) Who is the Document Shepherd for = this document? Has the 
          D= ocument Shepherd personally reviewed this version of the 
&n= bsp;         document and, in particular, does he or sh= e believe this 
          version i= s ready for forwarding to the IESG for publication? 

&= nbsp;  Matthew Bocci (matthew.bocci@alcatel-lucent.com)
      &n= bsp; Yes, I have reviewed the document and I believe it is ready for <= /div>
        forwarding to the IESG.

    (1.b) Has the document had adequat= e review both from key WG members 
      &nbs= p;   and from key non-WG members? Does the Document Shepherd have = ;
          any concerns about the depth= or breadth of the reviews that 
       =   have been performed? 

    &= nbsp;   Yes, the document has received adequate review. The document h= as
        received significant review by the= WG and received a number 
        of co= mments during WG last call.


  =   (1.c) Does the Document Shepherd have concerns that the document&nbs= p;
          needs more review from a pa= rticular or broader perspective, 
       = ;   e.g., security, operational complexity, someone familiar with = ;
          AAA, internationalization or= XML? 

       No.


    (1.d) Does the Document Shep= herd have any specific concerns or 
      &nb= sp;   issues with this document that the Responsible Area Director&nbs= p;
          and/or the IESG should be a= ware of? For example, perhaps he 
       = ;   or she is uncomfortable with certain parts of the document, or&nbs= p;
          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 advan= ce the document, detail those 
        &= nbsp; concerns here. Has an IPR disclosure related to this document 
          been filed? If so, please inclu= de a reference to the 
          di= sclosure and summarize the WG discussion and conclusion on 
=           this issue. 

       No specific concerns. 


    (1.e) How solid is the WG consensus be= hind this document? Does it 
        &nb= sp; represent the strong concurrence of a few individuals, with 
=
          others being silent, or does the WG= as a whole understand and 
        &nbs= p; agree with it? 

      I am = comfortable that the document represents WG consensus and has
&nb= sp;     been reviewed by a reasonable number of active WG partici= pants. 
      

=     (1.f) Has anyone threatened an appeal or otherwise indicated = extreme 
          discontent? If s= o, please summarise the areas of conflict in 
    =       separate email messages to the Responsible Area Direct= or. (It 
          should be in a s= eparate email because this questionnaire is 
    &= nbsp;     entered into the ID Tracker.) 

       None indicated.

<= br>
    (1.g) Has the Document Shepherd personally veri= fied that the 
          document s= atisfies all ID nits? (See 
        &nbs= p; http://www.ietf.org/ID= -Checklist.html and 
          = http://tools.ietf.org/tools= /idnits/). Boilerplate checks are 
      =     not enough; this check needs to be thorough. Has the document=  
          met all formal review c= riteria it needs to, such as the MIB 
      &= nbsp;   Doctor, media type and URI type reviews? 

<= /div>

       Yes. There are a couple= of minor I-D nits related to a possibly out of date 
 =      reference to draft-ietf-pwe3-oam-message-map and some = formatting issues.
       One of the author's= email addresses also appears to be incorrect. 
   = ;    These should be fixed before publication.
There ar= e no formal review criteria.

    (1.h) H= as the document split its references into normative and 
&nb= sp;         informative? Are there normative references= to documents that 
          are n= ot ready for advancement or are otherwise in an unclear 
&nb= sp;         state? If such normative references exist, = what is the 
          strategy for= their completion? Are there normative references 
  &n= bsp;       that are downward references, as described in [RF= C3967]? If 
          so, list thes= e downward references to support the Area 
    &nb= sp;     Director in the Last Call procedure for them [RFC3967].&n= bsp;

      Yes, the references are = split appropriately. 



    (1.i) Has the Document Shepherd verified that the docu= ment IANA 
          consideration = section exists and is consistent with the body 
   = ;       of the document? If the document specifies protocol&= nbsp;
          extensions, are reservat= ions requested in appropriate IANA 
      &nb= sp;   registries? Are the IANA registries clearly identified? If =
          the document creates a new re= gistry, does it define the 
        &nbs= p; proposed initial contents of the registry and an allocation 
<= div>          procedure for future registrations? = Does it suggest a 
          reason= able name for the new registry? See [RFC5226]. If the 
 = ;         document describes an Expert Review process h= as Shepherd 
          conferred wi= th the Responsible Area Director so that the IESG 
  &n= bsp;       can appoint the needed Expert during the IESG Eva= luation? 

      The IANA consi= derations section exists. There are no requests of IANA,
  &= nbsp;   which seems reasonable given that the document uses existing&n= bsp;
      OAM mechanisms and LDP status messaging= code points.


    (1.j) H= as the Document Shepherd verified that sections of the 
&nbs= p;         document that are written in a formal langua= ge, such as XML 
          code, BN= F rules, MIB definitions, etc., validate correctly in 
 = ;         an automated checker? 

      There are no sections that use a formal langua= ge.


    (1.k) The IESG ap= proval 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 sec= tions: 

Technical Summary

   This document specifies the mapping of defect states bet= ween
        Ethernet Attachment Circuits (AC= s) and associated Ethernet
        Pseudowire= s (PWs) connected in accordance to the PWE3
      =   architecture to realize an end-to-end emulated Ethernet service.
        It standardizes the behavior of Provider= Edges (PEs) with
        respect to Ethernet= PW and AC defects.

   This document is = a product of the PWE3 working group.

   = This document is Standards Track.

Working Group Su= mmary
   Solutions for mapping OAM messages related to = defect notifications from 
   attachement circuits= to PWs for ATM, FR, and TDM services were specified
   = ;in RFC6310. This RFC did not cover Ethernet attachment circuits because
   of a perception at the time that Ethernet OAM mechanis= ms were less widely 
   deployed and their standar= dization was on-going. The WG decided to handle 
  &nbs= p;the Ethernet case in a separate draft, which is the subject of this =
   proto write-up. This was considered to be an import= ant work item by the
   PWE3 working group, and there w= ere a number of requests to roll this working 
   = into the draft that became RFC6310. However, ultimately the consensus was&n= bsp;
   to progress the Ethernet case separately to not= further delay RFC6310.
  

Doc= ument Quality

   Previous PW deployment = surveys (see 
   draft-ietf-pwe3-pw-vccv-impl-surv= ey-results-00) have indicated that the 
   majorit= y of PWs are Ethernet, and therefore standardizing the interworking 
   of defect notifications for emulated Ethernet service= s is expected to be
   of significant interest to the I= ETF and the operator community in general. 
   The= re are believed to be numerous implementations and deployments of Ethernet&= nbsp;
   OAM mechanisms referred to in this draft, incl= uding cases where the Ethernet
   service is supported = over Pws.
  
   The document does n= ot specify any MIB changes or additions which would need review.
=

 Personnel
   The do= cument shepherd is Matthew Bocci.
   The responsible Ar= ea Director is Stewart Bryant.


--_000_CBB3159C292FCmatthewboccialcatellucentcom_-- From matthew.bocci@alcatel-lucent.com Wed Apr 18 03:40: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 94B3421F85E6; Wed, 18 Apr 2012 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.454 X-Spam-Level: X-Spam-Status: No, score=-109.454 tagged_above=-999 required=5 tests=[AWL=0.794, 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 oyGrmfFEFrkd; Wed, 18 Apr 2012 03:40:37 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id F23A921F8596; Wed, 18 Apr 2012 03:40:29 -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 q3IAePRA012775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Apr 2012 12:40:25 +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, 18 Apr 2012 12:40:25 +0200 From: "Bocci, Matthew (Matthew)" To: IETF-IESG via RT Date: Wed, 18 Apr 2012 12:40:23 +0200 Thread-Topic: Publication request for draft-ietf-pwe3-vccv-impl-survey-results-00.txt Thread-Index: Ac0dT6liRcEp01ISRAKhTIQbfxRybw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBB458A7293E4matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "pwe3@ietf.org" , Stewart Bryant Subject: [PWE3] Publication request for draft-ietf-pwe3-vccv-impl-survey-results-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: Wed, 18 Apr 2012 10:40:41 -0000 --_000_CBB458A7293E4matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PWE3 working group requests the publication of draft-ietf-pwe3-vccv-imp= l-survey-results-00.txt. The document write-up is attached below. Best regards, Matthew --------- draft-ietf-pwe3-vccv-impl-survey-results-00.txt Document Shepherd Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review and was discussed ov= er a period of a number of IETFs. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) 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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. (1.f) 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 entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are no formal review criteria that should be met. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. Only one Informational reference is used by the document. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists. There are no requests of IANA= , which seems reasonable given that the draft simply documents the resu= lts of an implementation/deployment survey. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) 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 Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. This document is a product of the PWE3 working group. This document is Informational. Working Group Summary RFC5085 defines 3 VCCV channel types. These are essentially the mechanis= ms for transport of the PW associated channel that is used to carry e.g. PW= OAM messages. In addition, RFC6423 adds a 4th mechanism which uses the GAL. = There is currently no clear definition of which modes are mandatory and which = modes are optional to implement. This has caused concerns by some participants= in the operator community that the proliferation of modes causes interopera= bility issues between vendors. As a first step to rationalising the number of m= odes, the WG conducted a survey to try to quantify which modes are in use toda= y and so determine which ones could be either deprecated, or made optional in a p= ossible future update to RFC5085. This draft contains the results of that survey= . Since the survey contains useful information pertaining to the current state of PW= deployments, there was consensus to record the results of the survey in an Informatio= nal RFC. Note that the name of the document that was originally last called by th= e WG was draft-ietf-pwe3-pw-vccv-impl-survey-results-00, but this was updated to draft-ietf-pwe3-vccv-impl-survey-results-00 as a result of a comment fro= m the WG. Document Quality The document describes a service provider implementation survey, samplin= g the deployments of PWs and their respective VCCV types. There is likely to be a skew in = the results towards operators that are willing to divulge details of their network deploymen= ts, and towards those that participate in the IETF. However, the results were anonymised, and a broad cross-section of both large and= smaller operators participated, which may help to mitigate any skew. I have no c= oncerns about the quality of the document. The document does not specify any MIB changes or additions which would n= eed review. Personnel The document shepherd is Matthew Bocci. The responsible Area Director is Stewart Bryant. --_000_CBB458A7293E4matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The PWE3 working group requests the publi= cation of draft-ietf-pwe3-vccv-impl-survey-results-00.txt.

The document write-up is attached = below.

<= /div>
Best regards= ,

=
Matthew

---------

draft-ietf-pwe3-vccv-impl-survey-results-00.txt<= /div>

Document Shepherd W= rite-Up

=

<= div style=3D"font-family: Consolas; font-size: medium; ">    (1.a= ) Who is the Document Shepherd for this document? Has the 
      &n= bsp;   Document Shepherd personally reviewed this version of the =
  &nbs= p;       document and, in particular, does he or she believe= this 
=           version is ready for forwarding to the I= ESG for publication? 

&= nbsp;  Matthew Bocci (matthew.bocci@alcatel-lucent.com)
       = ; Yes, I have reviewed the document and I believe it is ready for 
    &= nbsp;   forwarding to the IESG.


    (1.b) Has the document had adequate review both fr= om key WG members 
          and from key non-WG members?= Does the Document Shepherd have 
          any concerns = about the depth or breadth of the reviews that 
         = have been performed? 

        Yes, the document has received adequat= e review and was discussed over a
        period of a number of IET= Fs.
  &= nbsp;     


=     (1.c) Does the Document Shepherd have concerns that the docum= ent 
&n= bsp;         needs more review from a particular or bro= ader perspective, 
          e.g., security, operational = complexity, someone familiar with 
          AAA, interna= tionalization or XML? 

       No.


    (1.d) Does the Document Shepherd have any speci= fic concerns or 
          issues with this document that= the Responsible Area Director 
          and/or the IESG= should be aware of? For example, perhaps he 
          o= r she is uncomfortable with certain parts of the document, or 
     = ;     has concerns whether there really is a need for it. In any&= nbsp;
 =         event, if the WG has discussed those issues an= d has indicated 
          that it still wishes to advanc= e the document, detail those 
          concerns here. Ha= s an IPR disclosure related to this document 
          b= een filed? If so, please include a reference to the 
       =   disclosure and summarize the WG discussion and conclusion on <= /div>
   = ;       this issue. 

       No specific concerns. = ;

=

    (1.e) How = solid is the WG consensus behind this document? Does it 
      &nbs= p;   represent the strong concurrence of a few individuals, with =
  &nbs= p;       others being silent, or does the WG as a whole unde= rstand and 
          agree with it? 

      I am comfort= able that the document represents WG consensus and has
      been review= ed by a reasonable number of active WG participants. 
      <= /div>

    (1.f)= Has anyone threatened an appeal or otherwise indicated extreme 
=
    &nb= sp;     discontent? If so, please summarise the areas of conflict= in 
&n= bsp;         separate email messages to the Responsible= Area Director. (It 
          should be in a separate em= ail because this questionnaire is 
          entered into= the ID Tracker.) 

       None indicated.


    (1.g) Has the Document Shepherd persona= lly verified that the 
          document satisfies all I= D nits? (See 
          http://www.ietf.org/ID-Checklist.= html and 
          not enough; this check= needs to be thorough. Has the document 
          met al= l formal review criteria it needs to, such as the MIB 
       =   Doctor, media type and URI type reviews? 


       Yes. 
     =  
&nbs= p;      There are no formal review criteria that should be m= et.

    (= 1.h) Has the document split its references into normative and 
     = ;     informative? Are there normative references to documents th= at 
&nb= sp;         are not ready for advancement or are otherw= ise in an unclear 
          state? If such normative ref= erences exist, what is the 
          strategy for their = completion? Are there normative references 
          tha= t are downward references, as described in [RFC3967]? If 
      &nb= sp;   so, list these downward references to support the Area 
    &= nbsp;     Director in the Last Call procedure for them [RFC3967].=  

<= /div>
   = ;   Yes, the references are split appropriately. Only one Informationa= l 
&nbs= p;     reference is used by the document.



    (1.i) Has the Document Shepherd verified t= hat the document IANA 
          consideration section ex= ists and is consistent with the body 
          of the do= cument? If the document specifies protocol 
          ext= ensions, are reservations requested in appropriate IANA 
      &nbs= p;   registries? Are the IANA registries clearly identified? If <= /div>
   = ;       the document creates a new registry, does it define = the 
&n= bsp;         proposed initial contents of the registry = and an allocation 
          procedure for future registr= ations? Does it suggest a 
          reasonable name for = the new registry? See [RFC5226]. If the 
          docume= nt describes an Expert Review process has Shepherd 
        &n= bsp; conferred with the Responsible Area Director so that the IESG 
    =       can appoint the needed Expert during the IESG Evaluati= on? 
  &n= bsp;   The IANA considerations section exists. There are no requests o= f IANA,
&nbs= p;     which seems reasonable given that the draft simply documen= ts the results


    (1.j) Has the Document = Shepherd verified that sections of the 
          documen= t that are written in a formal language, such as XML 
       =   code, BNF rules, MIB definitions, etc., validate correctly in =
  &nbs= p;       an automated checker? 

      There are no sections= that use a formal language.


  =         Announcement Write-Up. Please provide such a Do= cument 
          Announcement Write-Up? Recent examples = can be found in the
          "Action" announcements for appro= ved documents. The approval 
          announcement conta= ins the following sections: 

Technical Summary

   Most Pseudowire Emulation Edge-to-Edge (PWE3) en= capsulations mandate
   the use of the Control Word (CW) in order to better e= mulate the
&= nbsp;  services for which the encapsulations have been defined.  = However,
&nb= sp;  some encapulations treat the Control Word as optional.  As a= result,
&nb= sp;  implementations of the CW, for encapsulations for which it is
   op= tional, vary by equipment manufacturer, equipment model and service
   provid= er network.  Similarly, Virtual Circuit Connectivity
   Verification (= VCCV) supports three Control Channel (CC) types and
   multiple Connectivity = Verification (CV) Types.  This flexibility has
   led to reports of inte= roperability issues within deployed networks
   and associated drafts to atte= mpt to remedy the situation.  This
   survey of the PW/VCCV user communi= ty was conducted to determine
   implementation trends.  The survey and = results is presented herein.

   This document is a product of the PWE3 working group= .

=
   This= document is Informational.

Working Group Summary
   
   RFC5085 defines 3 VCCV channel types. The= se are essentially the mechanisms 
   for transport of the PW associated= channel that is used to carry e.g. PW OAM
   messages. In addition, RFC6423 = adds a 4th mechanism which uses the GAL. There
   is currently no clear defin= ition of which modes are mandatory and which modes 
   are optional to i= mplement. This has caused concerns by some participants in 
   the opera= tor community that the proliferation of modes causes interoperability
=
   issu= es between vendors. As a first step to rationalising the number of modes,&n= bsp;
  =  the WG conducted a survey to try to quantify which modes are in use t= oday and so 
   determine which ones could be either deprecated, or made= optional in a possible 
   future update to RFC5085. This draft contain= s the results of that survey. Since the
   survey contains useful information= pertaining to the current state of PW deployments,
   there was consensus to= record the results of the survey in an Informational RFC. 
   
   Note th= at the name of the document that was originally last called by the WG was
   = draft-ietf-pwe3-pw-vccv-impl-survey-results-00, but this was updated to
   d= raft-ietf-pwe3-vccv-impl-survey-results-00 as a result of a comment from
   t= he WG.
 = ; 

=
Document Qu= ality

   = The document describes a service provider implementation survey, sampling t= he deployments
   operators that are willing to divul= ge details of their network deployments, and towards
   those that participat= e in the IETF. However,
   the results were anonymised, and a broad cross-sec= tion of both large and smaller
   operators participated, which may help to m= itigate any skew. I have no concerns 
   about the quality of the docume= nt.
  &= nbsp;
 =  The document does not specify any MIB changes or additions which wou= ld need review.

&nb= sp;  
<= br>
 Pe= rsonnel
&nbs= p;  The document shepherd is Matthew Bocci.
   The responsible Area Dire= ctor is Stewart Bryant.

--_000_CBB458A7293E4matthewboccialcatellucentcom_-- From stbryant@cisco.com Fri Apr 20 07:37: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 6649321F872A; Fri, 20 Apr 2012 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 rY668gvHRjkc; Fri, 20 Apr 2012 07:37:53 -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 DDE5221F8726; Fri, 20 Apr 2012 07:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=20655; q=dns/txt; s=iport; t=1334932671; x=1336142271; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=9hNTZLptSWKvspEXM77p5FlJPKmqpLIdYx5VyYg9zvo=; b=eC8j1icYT7RmCJcxuryuAXxv9grtJH5SBF3dm1iKeL0u01COWSmBE431 CklHjfNmIkU+ZVJcoVluEeb3nQRGcOamB3L4sOlC1eRQwPLt7S2bvO3Q5 /Oke7gZeB39BdXDAYIB8m2d+6nv/vddq2h7/hl6MMz+rdKKAicINE6+k2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADZ0kU+Q/khM/2dsb2JhbABEsTiBB4IJAQEBAwESAQJjBgcEHAMBAgoWDwkDAgECAQ8sAggGAQwGAgEBHodfAwYFC5psgz8QkwUNEIk/BIQWhV+GcgSVeYs8gxiBAmeCaA X-IronPort-AV: E=Sophos;i="4.75,453,1330905600"; d="scan'208,217";a="135783399" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2012 14:37:28 +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 q3KEbSek009306; Fri, 20 Apr 2012 14:37:28 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3KEbNul000108; Fri, 20 Apr 2012 15:37:23 +0100 (BST) Message-ID: <4F9174A3.6000102@cisco.com> Date: Fri, 20 Apr 2012 15:37:23 +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: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" References: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> In-Reply-To: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> X-Forwarded-Message-Id: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> Content-Type: multipart/alternative; boundary="------------000202030501020805090605" Subject: [PWE3] Fwd: IPR Statements concerning etree 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: Fri, 20 Apr 2012 14:37:54 -0000 This is a multi-part message in MIME format. --------------000202030501020805090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WGs, You may wish to look at the following IPR statements that were received yesterday. They all relate to etree. The stated terms appear to require payment of a royalty. Stewart -------- Original Message -------- Subject: IPR Statements Date: Thu, 19 Apr 2012 13:04:27 -0400 From: Russ Housley To: Stewart Bryant Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:14:30 PM EDT > To: simon.delord@gmail.com, raymond.key@ieee.org, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frederic.jounay@orange.ch > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07 > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, Frederic JOUNAY: > > An IPR disclosure that pertains to your Internet-Draft entitled "Control Word > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was submitted > to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:08 PM EDT > To: yuqun.cao@gmail.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-cao-l2vpn-vpls-etree-02 > > > Dear Yuqun Cao: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extension to > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to > draft-cao-l2vpn-vpls-etree-02."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:34 PM EDT > To: chen.ran@zte.com.cn > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01 > > > Dear Ran Chen: > > An IPR disclosure that pertains to your Internet-Draft entitled "Automatic VLAN > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:16:29 PM EDT > To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi: > > An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree Support > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted to the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:02 PM EDT > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-vpls-pe-etree-05 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx: > > An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE Model > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:48 PM EDT > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, raymond.key@team.telstra.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extension to > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was > submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls- > etree-2pw-02.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:18:32 PM EDT > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal@broadcom.com, josh.rogers@twcable.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree-multiple-pw-01 > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extension to > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was > submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree- > multiple-pw-01.""); > > The IETF Secretariat > --------------000202030501020805090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
WGs,

You may wish to look at the following IPR statements that were
received yesterday.

They all relate to etree.

The stated terms appear to require payment of a royalty.

Stewart


-------- Original Message --------
Subject: IPR Statements
Date: Thu, 19 Apr 2012 13:04:27 -0400
From: Russ Housley <housley@vigilsec.com>
To: Stewart Bryant <stbryant@cisco.com> 


Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:14:30 PM EDT
> To: simon.delord@gmail.com, raymond.key@ieee.org, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frederic.jounay@orange.ch
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07
> 
> 
> Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, Frederic JOUNAY:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Control Word
> Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was submitted
> to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-bit-etree-07."");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:15:08 PM EDT
> To: yuqun.cao@gmail.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-cao-l2vpn-vpls-etree-02
> 
> 
> Dear Yuqun Cao:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Extension to
> VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF
> Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual
> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The title
> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to
> draft-cao-l2vpn-vpls-etree-02.");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:15:34 PM EDT
> To: chen.ran@zte.com.cn
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01
> 
> 
> Dear Ran Chen:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Automatic VLAN
> allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01.");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:16:29 PM EDT
> To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00
> 
> 
> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree Support
> in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-etree-bgp-00.");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:17:02 PM EDT
> To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-vpls-pe-etree-05
> 
> 
> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE Model
> for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to the IETF
> Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual
> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The title
> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related to
> draft-jiang-l2vpn-vpls-pe-etree-05."");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:17:48 PM EDT
> To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, raymond.key@team.telstra.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02
> 
> 
> Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Extension to
> LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was
> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure is
> "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ldp-vpls-
> etree-2pw-02."");
> 
> The IETF Secretariat
> 
Begin forwarded message:

> From: IETF Secretariat <ietf-ipr@ietf.org>
> Date: April 19, 2012 12:18:32 PM EDT
> To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal@broadcom.com, josh.rogers@twcable.com
> Cc: housley@vigilsec.com, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree-multiple-pw-01
> 
> 
> Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled "Extension to
> VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was
> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF
> Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure is
> "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-etree-
> multiple-pw-01."");
> 
> The IETF Secretariat
>
--------------000202030501020805090605-- From wwwrun@rfc-editor.org Fri Apr 20 16:18: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 1B0D821F84AE; Fri, 20 Apr 2012 16:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.034, 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 feW9B8EkJlbI; Fri, 20 Apr 2012 16:18:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AACC321F84AA; Fri, 20 Apr 2012 16:18:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1E4C3B1E003; Fri, 20 Apr 2012 16:17:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120420231731.1E4C3B1E003@rfc-editor.org> Date: Fri, 20 Apr 2012 16:17:31 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 6307 on Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks 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, 20 Apr 2012 23:18:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6307 Title: Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks Author: D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon Status: Standards Track Stream: IETF Date: April 2012 Mailbox: david.black@emc.com, ldunbar@huawei.com, MRoth@infinera.com, ronens@corrigent.com Pages: 21 Characters: 49421 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-fc-encap-16.txt URL: http://www.rfc-editor.org/rfc/rfc6307.txt A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. [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 jiangyuanlong@huawei.com Mon Apr 23 01:36: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 20F5D21F863F; Mon, 23 Apr 2012 01:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 tErSbihPz2U2; Mon, 23 Apr 2012 01:36:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2B21F863C; Mon, 23 Apr 2012 01:36:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD32109; Mon, 23 Apr 2012 04:36:52 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 01:34:14 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Apr 2012 01:34:15 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.137]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Mon, 23 Apr 2012 16:34:09 +0800 From: Jiangyuanlong To: Stewart Bryant Thread-Topic: Fwd: IPR Statements concerning etree Thread-Index: AQHNISvaxOG9O90SYkm8bQARl+8XDA== Date: Mon, 23 Apr 2012 08:34:08 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EA4B@SZXEML508-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] Fwd: IPR Statements concerning etree 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, 23 Apr 2012 08:36:54 -0000 As far as I know, tagging E-Tree traffic with different VLANs had already b= een published in 2005 (it is called asymmetric VLANs in IEEE 802.1Q-2005), = well ahead of it. ------------------------------ Date: Fri, 20 Apr 2012 15:37:23 +0100 From: Stewart Bryant To: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Subject: Fwd: IPR Statements concerning etree Message-ID: <4F9174A3.6000102@cisco.com> Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" WGs, You may wish to look at the following IPR statements that were received yesterday. They all relate to etree. The stated terms appear to require payment of a royalty. Stewart -------- Original Message -------- Subject: IPR Statements Date: Thu, 19 Apr 2012 13:04:27 -0400 From: Russ Housley To: Stewart Bryant Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:14:30 PM EDT > To: simon.delord@gmail.com, raymond.key@ieee.org, wim.henderickx@alcatel= -lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frederic.jounay@= orange.ch > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-delord-pwe3-cw-bit-etree-07 > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, = Frederic JOUNAY: > > An IPR disclosure that pertains to your Internet-Draft entitled "Control= Word > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was sub= mitted > to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF P= age of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/= ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stat= ement about IPR related to draft-delord-pwe3-cw-bit-etree-07.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:08 PM EDT > To: yuqun.cao@gmail.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-cao-l2vpn-vpls-etree-02 > > > Dear Yuqun Cao: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensi= on to > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intel= lectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). T= he title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rel= ated to > draft-cao-l2vpn-vpls-etree-02."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:34 PM EDT > To: chen.ran@zte.com.cn > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-chen-l2vpn-vpls-etree-vlan-01 > > > Dear Ran Chen: > > An IPR disclosure that pertains to your Internet-Draft entitled "Automat= ic VLAN > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted t= o the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/= ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stat= ement about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:16:29 PM EDT > To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.d= e, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderic= kx@alcatel-lucent.com, sajassi@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-jiang-l2vpn-etree-bgp-00 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Bal= us, Wim Henderickx, Ali Sajassi: > > An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree = Support > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted = to the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/= ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stat= ement about IPR related to draft-jiang-l2vpn-etree-bgp-00."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:02 PM EDT > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, fre= deric.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.hende= rickx@alcatel-lucent.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-jiang-l2vpn-vpls-pe-etree-05 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Bal= us, Wim Henderickx: > > An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE= Model > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to t= he IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intel= lectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). T= he title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rel= ated to > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:48 PM EDT > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, raymond= .key@team.telstra.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensi= on to > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) w= as > submitted to the IETF Secretariat on 2012-04-19 and has been posted on t= he "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosur= e is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-l= dp-vpls- > etree-2pw-02.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:18:32 PM EDT > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal= @broadcom.com, josh.rogers@twcable.com > Cc: housley@vigilsec.com, ipr-announce@ietf.org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR rela= ted to draft-ram-l2vpn-etree-multiple-pw-01 > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensi= on to > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) = was > submitted to the IETF Secretariat on 2012-04-19 and has been posted on t= he "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosur= e is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-e= tree- > multiple-pw-01.""); > > The IETF Secretariat > From internet-drafts@ietf.org Mon Apr 23 03:08: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 CEA4721F86A4; Mon, 23 Apr 2012 03:08:21 -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 EITv+K5ICC1T; Mon, 23 Apr 2012 03:08:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702B521F8682; Mon, 23 Apr 2012 03:08:21 -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.00 Message-ID: <20120423100821.16265.10428.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 03:08:21 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-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: Mon, 23 Apr 2012 10:08:22 -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-07.txt Pages : 16 Date : 2012-04-23 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 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-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-07.txt From giles.heron@gmail.com Mon Apr 23 05:18: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 11BF221F84DA; Mon, 23 Apr 2012 05:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDHd8UQfyv1A; Mon, 23 Apr 2012 05:18:52 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4943621F84C4; Mon, 23 Apr 2012 05:18:52 -0700 (PDT) Received: by werb10 with SMTP id b10so9130422wer.31 for ; Mon, 23 Apr 2012 05:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=C/mDP8O3C/Jny0uYBPeuqLYdhHe2aXZEOoKXotl6ffs=; b=Eigxla3Br0eZpNnAP+a7bv5AHWP1WjpsEvfHjnhz4AEVJcofi4UyWMFUF8P1WhpII5 xvoFsIGgEcXFmqePJ7xV/AHnyIu/l3L18nJJWyQtOTFpqEqBXYJF+upR39e5RrUuOmfK eHKwRIcCijTHSsTAumbgqR+kaoJalAPmCXCXyifXVv4etlpRHqDg6EZZ7r20atP/gh2L HLKTfBwOGBIoMteTcp/pjvjHgGiL+Y44H/Vjg03sPuZXIkrNQxsaDVLtgaJGG1Ij74Fv 6jjVILntEqYxNxsThyx46Ywy74ifixysmCo8pKF2btjdj17LWcyLDwKZa+7mdrnizKJE QCGQ== Received: by 10.216.205.35 with SMTP id i35mr1092063weo.17.1335183531138; Mon, 23 Apr 2012 05:18:51 -0700 (PDT) Received: from [10.147.56.203] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm22316938wib.2.2012.04.23.05.18.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 05:18:50 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 23 Apr 2012 13:19:02 +0100 From: Giles Heron To: , "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , pwe3 , "pwe3-chairs@tools.ietf.org" Message-ID: Thread-Topic: IPR Statements concerning etree Thread-Index: Ac0hS0SNJywDFTgpykaGT5z1KiKZOA== In-Reply-To: <4F9174A3.6000102@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [PWE3] IPR Statements concerning etree 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, 23 Apr 2012 12:18:54 -0000 Since we're having this discussion now, please could anyone with any other IPR related to E-Tree notify the IETF Secretariat, so that we can have this discussion once and once only? Giles On 20/04/2012 15:37, "Stewart Bryant" wrote: > > WGs, > > You may wish to look at the following IPR statements that were > received yesterday. > > They all relate to etree. > > The stated terms appear to require payment of a royalty. > > Stewart > > > -------- Original Message -------- > Subject: IPR Statements > Date: Thu, 19 Apr 2012 13:04:27 -0400 > From: Russ Housley > To: Stewart Bryant > > > > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:14:30 PM EDT >> To: simon.delord@gmail.com, raymond.key@ieee.org, >> wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, >> lizhong.jin@zte.com.cn, frederic.jounay@orange.ch >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-delord-pwe3-cw-bit-etree-07 >> >> >> Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, >> Frederic JOUNAY: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Control >> Word >> Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was >> submitted >> to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page >> of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-delord-pwe3-cw-bit-etree-07.""); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:15:08 PM EDT >> To: yuqun.cao@gmail.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-cao-l2vpn-vpls-etree-02 >> >> >> Dear Yuqun Cao: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Extension >> to >> VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF >> Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual >> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The >> title >> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related >> to >> draft-cao-l2vpn-vpls-etree-02."); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:15:34 PM EDT >> To: chen.ran@zte.com.cn >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-chen-l2vpn-vpls-etree-vlan-01 >> >> >> Dear Ran Chen: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Automatic >> VLAN >> allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to >> the >> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-chen-l2vpn-vpls-etree-vlan-01."); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:16:29 PM EDT >> To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, >> frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, >> wim.henderickx@alcatel-lucent.com, sajassi@cisco.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-jiang-l2vpn-etree-bgp-00 >> >> >> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, >> Wim Henderickx, Ali Sajassi: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree >> Support >> in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted to >> the >> IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-jiang-l2vpn-etree-bgp-00."); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:17:02 PM EDT >> To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, >> frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, >> wim.henderickx@alcatel-lucent.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-jiang-l2vpn-vpls-pe-etree-05 >> >> >> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, >> Wim Henderickx: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE >> Model >> for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to the >> IETF >> Secretariat on 2012-04-19 and has been posted on the "IETF Page of >> Intellectual >> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The >> title >> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR related >> to >> draft-jiang-l2vpn-vpls-pe-etree-05.""); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:17:48 PM EDT >> To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, >> raymond.key@team.telstra.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 >> >> >> Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Extension >> to >> LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was >> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the >> "IETF Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-ram-l2vpn-ldp-vpls- >> etree-2pw-02.""); >> >> The IETF Secretariat >> > Begin forwarded message: > >> From: IETF Secretariat >> Date: April 19, 2012 12:18:32 PM EDT >> To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, >> pagarwal@broadcom.com, josh.rogers@twcable.com >> Cc: housley@vigilsec.com, ipr-announce@ietf.org >> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR related >> to draft-ram-l2vpn-etree-multiple-pw-01 >> >> >> Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Extension >> to >> VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was >> submitted to the IETF Secretariat on 2012-04-19 and has been posted on the >> "IETF >> Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure is >> "Orckit-Corrigent Ltd's Statement about IPR related to >> draft-ram-l2vpn-etree- >> multiple-pw-01.""); >> >> The IETF Secretariat >> > > > From amalis@gmail.com Mon Apr 23 12:06: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 4F4FA21F854A for ; Mon, 23 Apr 2012 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 5jCTM-CTBzKy for ; Mon, 23 Apr 2012 12:06:04 -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 4BC8D21F8551 for ; Mon, 23 Apr 2012 12:05:58 -0700 (PDT) Received: by yhkk25 with SMTP id k25so7383143yhk.31 for ; Mon, 23 Apr 2012 12:05:56 -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=10KUXw4G30hwQTG/Kj+cpC1R70jE+uZPzUNXiYY43Pc=; b=O2Kb9Gy42H3JBBJlo8A3GFnA/ZN4dRG2mXEEu0LaUaFh2ca75xeCcy+GUZP3dgVNrf 3V6URgLBt3zq04svL324jDLyK0ohI7nOutaFjMrGLPpH1snU13wU8GnVqgiuuIS1fhta /iYP/FWK+GAgvk2ah9bNwDSOM0sFXxoHPxvXfJLko/Z5A12DK0B1/FUfTGYwoUgIn0yH OmZ2GrTWTwzr/KcuC1U1wG7i82MRDj1L3738OL2oHh2a6/fCGp8SJX0poDie5Dgdw7nA b71qNfcCYEyJ5wvU81TQz6lV2kUDbMY7FR6lZmhtcWtWz+i8KI8Zrh6jXSYRnfilWW/O HOoQ== Received: by 10.236.76.226 with SMTP id b62mr15975151yhe.13.1335207956274; Mon, 23 Apr 2012 12:05:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.155.105 with HTTP; Mon, 23 Apr 2012 12:05:36 -0700 (PDT) From: "Andrew G. Malis" Date: Mon, 23 Apr 2012 12:05:36 -0700 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf3005132eef5ccc04be5d53d6 Subject: [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, 23 Apr 2012 19:06:05 -0000 --20cf3005132eef5ccc04be5d53d6 Content-Type: text/plain; charset=ISO-8859-1 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 --20cf3005132eef5ccc04be5d53d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This email begins a two week working group la= st call for draft-ietf= -pwe3-cbit-negotiation-03, https://tools.ietf.org/html/draft-ietf-pwe3-cbi= t-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 PWE3 mailing list.

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

Regards,
Andy & Matthew

--20cf3005132eef5ccc04be5d53d6-- From lizhong.jin@zte.com.cn Mon Apr 23 18:06: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 D4E5321F86E2; Mon, 23 Apr 2012 18:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.168 X-Spam-Level: X-Spam-Status: No, score=-100.168 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_OBFU_AMP2B=2.555, 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 DnofGQv0McXS; Mon, 23 Apr 2012 18:06:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3721F86E4; Mon, 23 Apr 2012 18:06:27 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201974505403; Tue, 24 Apr 2012 08:26:24 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 66762.5191388195; Tue, 24 Apr 2012 09:06:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3O16CBJ044682; Tue, 24 Apr 2012 09:06:12 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: jiangyuanlong@huawei.com, stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 24 Apr 2012 09:05:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-24 09:06:12, Serialize complete at 2012-04-24 09:06:12 Content-Type: multipart/alternative; boundary="=_alternative 00060F9E482579EA_=" X-MAIL: mse02.zte.com.cn q3O16CBJ044682 Cc: l2vpn@ietf.org, l2vpn-chairs@tools.ietf.org, pwe3@ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [PWE3] Fwd: IPR Statements concerning etree 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, 24 Apr 2012 01:06:30 -0000 This is a multipart message in MIME format. --=_alternative 00060F9E482579EA_= Content-Type: text/plain; charset="US-ASCII" I have similar concern, the E-Tree technology has already been deployed before 2006. Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Apr 2012 08:34:08 +0000 > From: Jiangyuanlong > To: Stewart Bryant > Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" > , pwe3 , > "pwe3-chairs@tools.ietf.org" > Subject: Re: [PWE3] Fwd: IPR Statements concerning etree > Message-ID: > <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EA4B@SZXEML508-MBS.china.huawei.com> > > Content-Type: text/plain; charset="us-ascii" > > As far as I know, tagging E-Tree traffic with different VLANs had > already been published in 2005 (it is called asymmetric VLANs in > IEEE 802.1Q-2005), well ahead of it. > > ------------------------------ > Date: Fri, 20 Apr 2012 15:37:23 +0100 > From: Stewart Bryant > To: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" > , pwe3 , > "pwe3-chairs@tools.ietf.org" > Subject: Fwd: IPR Statements concerning etree > Message-ID: <4F9174A3.6000102@cisco.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > WGs, > > You may wish to look at the following IPR statements that were > received yesterday. > > They all relate to etree. > > The stated terms appear to require payment of a royalty. > > Stewart > > > -------- Original Message -------- > Subject: IPR Statements > Date: Thu, 19 Apr 2012 13:04:27 -0400 > From: Russ Housley > To: Stewart Bryant > > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:14:30 PM EDT > > To: simon.delord@gmail.com, raymond.key@ieee.org, wim. > henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong. > jin@zte.com.cn, frederic.jounay@orange.ch > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-delord-pwe3-cw-bit-etree-07 > > > > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, > Lizhong Jin, Frederic JOUNAY: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Control Word > > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) > was submitted > > to the IETF Secretariat on 2012-04-19 and has been posted on the > "IETF Page of > > Intellectual Property Rights Disclosures" (https://datatracker. > ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit- > Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw- > bit-etree-07.""); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:15:08 PM EDT > > To: yuqun.cao@gmail.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-cao-l2vpn-vpls-etree-02 > > > > > > Dear Yuqun Cao: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extension to > > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > > Secretariat on 2012-04-19 and has been posted on the "IETF Page > of Intellectual > > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/ > ). The title > > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about > IPR related to > > draft-cao-l2vpn-vpls-etree-02."); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:15:34 PM EDT > > To: chen.ran@zte.com.cn > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-chen-l2vpn-vpls-etree-vlan-01 > > > > > > Dear Ran Chen: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Automatic VLAN > > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was > submitted to the > > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > > Intellectual Property Rights Disclosures" (https://datatracker. > ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit- > Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn- > vpls-etree-vlan-01."); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:16:29 PM EDT > > To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel. > Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel- > lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-jiang-l2vpn-etree-bgp-00 > > > > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, > Florin Balus, Wim Henderickx, Ali Sajassi: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "E-Tree Support > > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was > submitted to the > > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > > Intellectual Property Rights Disclosures" (https://datatracker. > ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit- > Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn- > etree-bgp-00."); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:17:02 PM EDT > > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom. > de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent. > com, wim.henderickx@alcatel-lucent.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-jiang-l2vpn-vpls-pe-etree-05 > > > > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, > Florin Balus, Wim Henderickx: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "VPLS PE Model > > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was > submitted to the IETF > > Secretariat on 2012-04-19 and has been posted on the "IETF Page > of Intellectual > > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/ > ). The title > > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about > IPR related to > > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:17:48 PM EDT > > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, > raymond.key@team.telstra.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extension to > > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was > > submitted to the IETF Secretariat on 2012-04-19 and has been > posted on the "IETF Page of Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR > disclosure is > > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram- > l2vpn-ldp-vpls- > > etree-2pw-02.""); > > > > The IETF Secretariat > > > Begin forwarded message: > > > From: IETF Secretariat > > Date: April 19, 2012 12:18:32 PM EDT > > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, > pagarwal@broadcom.com, josh.rogers@twcable.com > > Cc: housley@vigilsec.com, ipr-announce@ietf.org > > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about > IPR related to draft-ram-l2vpn-etree-multiple-pw-01 > > > > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Extension to > > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was > > submitted to the IETF Secretariat on 2012-04-19 and has been > posted on the "IETF > > Page of Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR > disclosure is > > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram- > l2vpn-etree- > > multiple-pw-01.""); > > > > The IETF Secretariat > > > > > > --=_alternative 00060F9E482579EA_= Content-Type: text/html; charset="US-ASCII"
I have similar concern, the E-Tree technology has already been deployed before 2006.

Lizhong

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Apr 2012 08:34:08 +0000
> From: Jiangyuanlong <jiangyuanlong@huawei.com>
> To: Stewart Bryant <stbryant@cisco.com>
> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>,   "l2vpn-chairs@tools.ietf.org"
>    <l2vpn-chairs@tools.ietf.org>,   pwe3 <pwe3@ietf.org>,
>    "pwe3-chairs@tools.ietf.org" <pwe3-chairs@tools.ietf.org>
> Subject: Re: [PWE3] Fwd: IPR Statements concerning etree
> Message-ID:
>    <3B0A1BED22CAD649A1B3E97BE5DDD68B1CA3EA4B@SZXEML508-MBS.china.huawei.com>
>    
> Content-Type: text/plain; charset="us-ascii"
>
> As far as I know, tagging E-Tree traffic with different VLANs had
> already been published in 2005 (it is called asymmetric VLANs in
> IEEE 802.1Q-2005), well ahead of it.
>
> ------------------------------
> Date: Fri, 20 Apr 2012 15:37:23 +0100
> From: Stewart Bryant <stbryant@cisco.com>
> To: "l2vpn@ietf.org" <l2vpn@ietf.org>,   "l2vpn-chairs@tools.ietf.org"
>    <l2vpn-chairs@tools.ietf.org>,   pwe3 <pwe3@ietf.org>,
>    "pwe3-chairs@tools.ietf.org" <pwe3-chairs@tools.ietf.org>
> Subject: Fwd: IPR Statements concerning etree
> Message-ID: <4F9174A3.6000102@cisco.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
>
> WGs,
>
> You may wish to look at the following IPR statements that were
> received yesterday.
>
> They all relate to etree.
>
> The stated terms appear to require payment of a royalty.
>
> Stewart
>
>
> -------- Original Message --------
> Subject:    IPR Statements
> Date:    Thu, 19 Apr 2012 13:04:27 -0400
> From:    Russ Housley <housley@vigilsec.com>
> To:    Stewart Bryant <stbryant@cisco.com>
>
>
>
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:14:30 PM EDT
> >  To: simon.delord@gmail.com, raymond.key@ieee.org, wim.
> henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.
> jin@zte.com.cn, frederic.jounay@orange.ch
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-delord-pwe3-cw-bit-etree-07
> >
> >
> >  Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong,
> Lizhong Jin, Frederic JOUNAY:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Control Word
> >  Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree)
> was submitted
> >  to the IETF Secretariat on 2012-04-19 and has been posted on the
> "IETF Page of
> >  Intellectual Property Rights Disclosures" (https://datatracker.
> ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-
> Corrigent Ltd's Statement about IPR related to draft-delord-pwe3-cw-
> bit-etree-07."");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:15:08 PM EDT
> >  To: yuqun.cao@gmail.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-cao-l2vpn-vpls-etree-02
> >
> >
> >  Dear Yuqun Cao:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Extension to
> >  VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF
> >  Secretariat on 2012-04-19 and has been posted on the "IETF Page
> of Intellectual
> >  Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/
> ). The title
> >  of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about
> IPR related to
> >  draft-cao-l2vpn-vpls-etree-02.");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:15:34 PM EDT
> >  To: chen.ran@zte.com.cn
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-chen-l2vpn-vpls-etree-vlan-01
> >
> >
> >  Dear Ran Chen:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Automatic VLAN
> >  allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was
> submitted to the
> >  IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> >  Intellectual Property Rights Disclosures" (https://datatracker.
> ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-
> Corrigent Ltd's Statement about IPR related to draft-chen-l2vpn-
> vpls-etree-vlan-01.");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:16:29 PM EDT
> >  To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.
> Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-
> lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-jiang-l2vpn-etree-bgp-00
> >
> >
> >  Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY,
> Florin Balus, Wim Henderickx, Ali Sajassi:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "E-Tree Support
> >  in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was
> submitted to the
> >  IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of
> >  Intellectual Property Rights Disclosures" (https://datatracker.
> ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-
> Corrigent Ltd's Statement about IPR related to draft-jiang-l2vpn-
> etree-bgp-00.");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:17:02 PM EDT
> >  To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.
> de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.
> com, wim.henderickx@alcatel-lucent.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-jiang-l2vpn-vpls-pe-etree-05
> >
> >
> >  Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY,
> Florin Balus, Wim Henderickx:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "VPLS PE Model
> >  for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was
> submitted to the IETF
> >  Secretariat on 2012-04-19 and has been posted on the "IETF Page
> of Intellectual
> >  Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/
> ). The title
> >  of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about
> IPR related to
> >  draft-jiang-l2vpn-vpls-pe-etree-05."");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:17:48 PM EDT
> >  To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com,
> raymond.key@team.telstra.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02
> >
> >
> >  Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Extension to
> >  LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) was
> >  submitted to the IETF Secretariat on 2012-04-19 and has been
> posted on the "IETF Page of Intellectual Property Rights Disclosures"
> >  (https://datatracker.ietf.org/ipr/1755/). The title of the IPR
> disclosure is
> >  "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-
> l2vpn-ldp-vpls-
> >  etree-2pw-02."");
> >
> >  The IETF Secretariat
> >
> Begin forwarded message:
>
> >  From: IETF Secretariat<ietf-ipr@ietf.org>
> >  Date: April 19, 2012 12:18:32 PM EDT
> >  To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org,
> pagarwal@broadcom.com, josh.rogers@twcable.com
> >  Cc: housley@vigilsec.com, ipr-announce@ietf.org
> >  Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about
> IPR related to draft-ram-l2vpn-etree-multiple-pw-01
> >
> >
> >  Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers:
> >
> >  An IPR disclosure that pertains to your Internet-Draft entitled
> "Extension to
> >  VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) was
> >  submitted to the IETF Secretariat on 2012-04-19 and has been
> posted on the "IETF
> >  Page of Intellectual Property Rights Disclosures"
> >  (https://datatracker.ietf.org/ipr/1754/). The title of the IPR
> disclosure is
> >  "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-
> l2vpn-etree-
> >  multiple-pw-01."");
> >
> >  The IETF Secretariat
> >
>
>
>
> --=_alternative 00060F9E482579EA_=-- From mustapha.aissaoui@alcatel-lucent.com Tue Apr 24 15:23: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 9650D21F864D; Tue, 24 Apr 2012 15:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6pDRFvDYMVDq; Tue, 24 Apr 2012 15:23:34 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C069221F863E; Tue, 24 Apr 2012 15:23:33 -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 q3OMNUBI022540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 17:23:31 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3OMNUEb014228 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Apr 2012 17:23:30 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 24 Apr 2012 17:23:30 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "'pwe3@ietf.org'" , "'Daniel Cohn'" Date: Tue, 24 Apr 2012 17:23:29 -0500 Thread-Topic: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Thread-Index: Acz8izeZXI9/dkIbSZqtuo9E9fuJLwAADwawAsQxoaAGccOXQA== Message-ID: <5DF53972F7E9134782DCE51624466FE50BD6070745@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20120307170032.20594.20281.idtracker@ietfa.amsl.com> <4F579F33.7050508@cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5811DAC@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50BD6070745USNAVSXCHMBSC_" 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: "'draft-ietf-pwe3-redundancy-bit@tools.ietf.org'" , "'ietf@ietf.org'" , "'stbryant@cisco.com'" Subject: Re: [PWE3] Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard 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, 24 Apr 2012 22:23:36 -0000 --_000_5DF53972F7E9134782DCE51624466FE50BD6070745USNAVSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I have made a couple more clarifications to the text below based on additio= nal feedback from Daniel on the use of the active PW selection algorithm in= use cases presented in Section 15. I am copying the new updated Section 5.1. All the changes from the current = version of the draft are underlined. Let me know if you have any comments. Regards, Mustapha. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.1. Independent Mode: PW endpoint nodes independently select which PWs are eligible to become act= ive and which are not. They advertise the corresponding Active or Standby p= referential forwarding status for each PW. Each PW endpoint compares local = and remote status bits and uses the PW that is UP at both endpoints and tha= t advertised Active preferential forwarding status at both the local and re= mote endpoints. In this mode of operation, the preferential forwarding status indicates the= preferred forwarding state of each endpoint but the actual forwarding stat= e of the PW is the result of the comparison of the local and remote forward= ing status bits. If more than one PW qualifies for the Active state, each PW endpoint MUST i= mplement a common mechanism to choose the PW for forwarding. The default me= chanism MUST be supported by all implementations and operates as follows: 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified at = each PE using the following triplet: AGI::SAII::TAII. The unsigned integer = form of the concatenated word can be used in the comparison. However, the S= AII and TAII values as seen on a PE node are the mirror values of what the = peer PE node sees. To have both PE nodes compare the same value we propose = that the PE with the lowest system IP address use the unsigned integer form= of AGI::SAII::TAII while the PE with the highest system IP address use the= unsigned integer form of AGI::TAII::SAII. This way, both PEs will compare = the same values. The PW which corresponds to the minimum of the compared va= lues across all PWs in the redundant is selected. Note 1: in the case where the system IP address is not known, it is recomme= nded to implement the optional active PW selection mechanism described next= . Note 2: in the case of segmented PW, the operator needs to make sure that t= he pw-id or AGI::SAII::TAII of the redundant PWs within the first and last = segment are ordered consistently such that the same end-to-end MS-PW gets s= elected. Otherwise, it is recommended to implement the optional active PW s= election mechanism described next. The PW endpoints MAY also implement the following optional active PW select= ion mechanism. 1. If the PW endpoint is configured with the precedence parameter on ea= ch PW in the redundant set, it must select the PW with the lowest configure= d precedence value. 2. If the PW endpoint is configured with one PW as primary and one or m= ore PWs as secondary, it must select the primary PW in preference to all se= condary PWs. If a primary PW is not available, it must use the secondary PW= with the lowest precedence value. If the primary PW becomes available, a P= W endpoint must revert to it immediately or after the expiration of a confi= gurable delay. 3. This active PW selection mechanism assumes the precedence parameter = values are configured consistently at both PW endpoints and that unique val= ues are assigned to the PWs in the same redundancy set to achieve tie-break= ing using this mechanism. There are scenarios with dual-homing of a CE to PE nodes where each PE node= needs to advertise Active preferential forwarding status on more than one = PW in the redundancy set. However, a PE MUST always select a single PW for = forwarding using the above active PW selection algorithm. An example of suc= h a case is described in 15.2. . There are scenarios where each PE needs to advertize Active preferential fo= rwarding status on a single PW in the redundancy set. In order to ensure th= at both PE nodes make the same selection, they MUST use the above active PW= selection algorithm to determine the PW eligible for active state. An exam= ple of such a case is described in 15.5. . In steady state with consistent configuration, a PE will always find an act= ive PW. However, it is possible that such a PW is not found due to a mis-co= nfiguration. In the event that an active PW is not found, a management indi= cation SHOULD be generated. If a management indication for failure to find = an active PW was generated and an active PW is subsequently found, a manage= ment indication should be generated, so clearing the previous failure indic= ation. Additionally, a PE may use the optional request switchover procedure= s described in Section 6.3. to have both PE nodes switch to a common PW. There may also be transient conditions where endpoints do not share a commo= n view of the Active/Standby state of the PWs. This could be caused by prop= agation delay of the T-LDP status messages between endpoints. In this case,= the behavior of the receiving endpoint is outside the scope of this docume= nt. Thus, in this mode of operation, the following definition of Active and Sta= ndby PW states apply: o Active State A PW is considered to be in Active state when the PW labels are exchanged b= etween its two endpoints and the status bits exchanged between the endpoint= s indicate the PW is UP and its preferential forwarding status is Active at= both endpoints. In this state user traffic can flow over the PW in both di= rections. As described in Section 5.1. , the PE nodes must implement a comm= on mechanism to select one PW for forwarding in case multiple PWs qualify f= or the Active state. o Standby State A PW is considered to be in Standby state when the PW labels are exchanged = between its two endpoints, but the Preferential Forwarding status bits exch= anged indicate the PW preferential forwarding status is Standby at one or b= oth endpoints. In this state the endpoints MUST NOT forward data traffic ov= er the PW but MAY allow PW OAM packets, e.g., Virtual Connection Connectivi= ty Verification (VCCV) packets [10], to be sent and received in order to te= st the liveliness of standby PWs. The endpoints of the PW may also allow th= e forwarding of specific control plane packets of applications using the PW= . The specification of applications and the allowed control plane packets i= s outside the scope of this document. If the PW is a spoke in H-VPLS, any M= AC addresses learned via the PW SHOULD be flushed when it transitions to St= andby state according to the procedures in RFC4762 [3] and [9]. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Thursday, March 22, 2012 11:59 AM To: 'pwe3@ietf.org'; Daniel Cohn Cc: 'stbryant@cisco.com'; 'draft-ietf-pwe3-redundancy-bit@tools.ietf.org'; = 'ietf@ietf.org'; 'Andrew G. Malis' Subject: RE: [PWE3] Last Call: (Pse= udowire Preferential Forwarding Status Bit) to Proposed Standard Dear all, I received comments from Daniel regarding the intended use of the optional = active PW selection mechanism in section 5.1. I pasted below the correspond= ing paragraph of Section 5.1 with the changes we agreed to underlined. He also asked if the default active PW selection mechanism should be refere= nced in Section 5.2 with the Master/Slave mode of operation. Although, it i= s not stricly required for interoperability, implementations would benefit = from a consistent behaviour. I used SHOULD in that case. The text is also p= asted below with the changes underlined. Let me know if you have any comments on this. Regards, Mustapha. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I. Changes to Section 5.1 - 3rd paragraph: " If more than one PW qualifies for the Active state, each PW endpoint MUST i= mplement a common mechanism to choose the PW for forwarding. The default me= chanism MUST be supported by all implementations and operates as follows: 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified at = each PE using the following triplet: AGI::SAII::TAII. The unsigned integer = form of the concatenated word can be used in the comparison. However, the S= AII and TAII values as seen on a PE node are the mirror values of what the = peer PE node sees. To have both PE nodes compare the same value we propose = that the PE with the lowest system IP address use the unsigned integer form= of AGI::SAII::TAII while the PE with the highest system IP address use the= unsigned integer form of AGI::TAII::SAII. This way, both PEs will compare = the same values. The PW which corresponds to the minimum of the compared va= lues across all PWs in the redundant is selected. Note 1: in the case where the system IP address is not known, it is recomme= nded to implement the optional active PW selection mechanism described next= . Note 2: in the case of segmented PW, the operator needs to make sure that t= he pw-id or AGI::SAII::TAII of the redundant PWs within the first and last = segment are ordered consistently such that the same end-to-end MS-PW gets s= elected. Otherwise, it is recommended to implement the optional active PW s= election mechanism described next. The PW endpoints MAY also implement the following optional active PW select= ion mechanism. 1. If the PW endpoint is configured with the precedence parameter on ea= ch PW in the redundant set, it must select the PW with the lowest configure= d precedence value. 2. If the PW endpoint is configured with one PW as primary and one or m= ore PWs as secondary, it must select the primary PW in preference to all se= condary PWs. If a primary PW is not available, it must use the secondary PW= with the lowest precedence value. If the primary PW becomes available, a P= W endpoint must revert to it immediately or after the expiration of a confi= gurable delay. 3. This active PW selection mechanism assumes the precedence parameter = values are configured consistently at both PW endpoints and that unique val= ues are assigned to the PWs in the same redundancy set to achieve tie-break= ing using this mechanism. " II. Changes to Section 5.2 - 5th paragraph: " If more than one PW qualify for the Active state, the Master PW endpoint no= de selects one. There is no requirement to specify a default active PW sele= ction mechanism in this case but for consistency across implementations, th= e Master PW endpoint SHOULD implement the default active PW selection mecha= nism described in Section 5.1. If the Master PW endpoint implements the optional active PW selection mecha= nism based on primay/secondary and precedence parameters, it MUST follow th= e following behaviour: 1. If the PW endpoint is configured with the precedence parameter on ea= ch PW in the redundant set, it must select the PW with the lowest configure= d precedence value. 2. If the PW endpoint is configured with one PW as primary and one or m= ore PWs as secondary, it must select the primary PW in preference to all se= condary PWs. If a primary PW is not available, it must use the secondary PW= with the lowest precedence value. If the primary PW becomes available, a P= W endpoint must revert to it immediately or after the expiration of a confi= gurable delay. " =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Wednesday, March 07, 2012 12:56 PM To: Andrew G. Malis Cc: stbryant@cisco.com; draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3= @ietf.org; ietf@ietf.org Subject: RE: [PWE3] Last Call: (Pse= udowire Preferential Forwarding Status Bit) to Proposed Standard makes sense Andy. Thanks, Mustapha. ________________________________ From: Andrew G. Malis [mailto:amalis@gmail.com] Sent: Wednesday, March 07, 2012 12:53 PM To: Aissaoui, Mustapha (Mustapha) Cc: stbryant@cisco.com; draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3= @ietf.org; ietf@ietf.org Subject: Re: [PWE3] Last Call: (Pse= udowire Preferential Forwarding Status Bit) to Proposed Standard Mustapha, You might want to wait for any other LC comments before updating. Thanks, Andy On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) > wrot= e: Ooops. Thank you for pointing this out Stewart. I will make the update and = publish a new revision. Mustapha. -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-bit@tools.ietf.org Cc: ietf@ietf.org; pwe3@ietf.org Subject: Re: Last Call: (Pseudowire= Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD revie= w and so I am picking it up as a LC comment: In section 10 you say: "This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: " This update should be recorded in the metadata (top left front page) and it= is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: > The IESG has received a request from the Pseudowire Emulation Edge to > Edge WG (pwe3) to consider the following document: > - 'Pseudowire Preferential Forwarding Status Bit' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-03-21. Exceptio= nally, comments may > be sent to iesg@ietf.org instead. In either case, p= lease retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > 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. > > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- 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 --_000_5DF53972F7E9134782DCE51624466FE50BD6070745USNAVSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
I=20 have made a couple more clarifications to the text below based on=20 additional feedback from Daniel on the use of the active PW selection algor= ithm=20 in use cases presented in Section 15.
 
I=20 am copying the new updated Section 5.1. All the changes from the current ve= rsion=20 of the draft are underlined.
 
Let me  know if you have any=20 comments.
 
Regards,
Mustapha.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

5.1. Independent=20 Mode:

PW endpoint nodes=20 independently select which PWs are eligible to become active and which a= re=20 not. They advertise the corresponding Active or Standby preferential=20 forwarding status for each PW. Each PW endpoint compares local and remote s= tatus=20 bits and uses the PW that is UP at both endpoints and that advertised Activ= e=20 preferential forwarding status at both the local and remote endpoints.=20

In this mode of opera= tion,=20 the preferential forwarding status indicates the preferred forwarding state= of=20 each endpoint but the actual forwarding state of the PW is the result of th= e=20 comparison of the local and remote forwarding status=20 bits.

If more than one PW=20 qualifies for the Active state, each PW endpoint MUST implement a common=20 mechanism to choose the PW for forwarding. The default mechanism MUST be=20 supported by all implementations and operates as follows:=

1.   =  =20 F= or=20 FEC128 PW, the PW with the lowest pw-id value is=20 selected.

2.   =  =20 F= or=20 FEC129 PW, each PW in a redundant set is uniquely identified at each PE usi= ng=20 the following triplet: AGI::SAII::TAII. The unsigned integer form of the=20 concatenated word can be used in the comparison. However, the SAII and TAII= =20 values as seen on a PE node are the mirror values of what the peer PE node = sees.=20 To have both PE nodes compare the same value we propose that the PE with th= e=20 lowest system IP address use the unsigned integer form of AGI::SAII::TAII w= hile=20 the PE with the highest system IP address use the unsigned integer form of= =20 AGI::TAII::SAII. This way, both PEs will compare the same values. The PW wh= ich=20 corresponds to the minimum of the compared values across all PWs in the=20 redundant is selected.

Note 1: in the case w= here=20 the system IP address is not known, it is recommended to implement the opti= onal=20 active PW selection mechanism described next.

Note 2: in the case o= f=20 segmented PW, the operator needs to make sure that the pw-id or AGI::SAII::= TAII=20 of the redundant PWs within the first and last segment are ordered consiste= ntly=20 such that the same end-to-end MS-PW gets selected. Otherwise, it is recomme= nded=20 to implement the optional active PW selection mechanism described=20 next.

The PW endpoints MAY = also=20 implement the following optional active PW selection mechanism.=20

1.   =  =20 I= f the=20 PW endpoint is configured with the precedence parameter on each PW in the=20 redundant set, it must select the PW with the lowest configured precedence= =20 value.

2.   =  =20 I= f the=20 PW endpoint is configured with one PW as primary and one or more PWs as=20 secondary, it must select the primary PW in preference to all secondary PWs= . If=20 a primary PW is not available, it must use the secondary PW with the lowest= =20 precedence value. If the primary PW becomes available, a PW endpoint must r= evert=20 to it immediately or after the expiration of a configurable=20 delay.

3.   =  =20 There are scenarios w= ith=20 dual-homing of a CE to PE nodes where each PE node needs to advertise Activ= e=20 preferential forwarding status on more than one PW in the redundancy set.=20 However, a PE MUST always select a single PW for forwarding using the above= =20 active PW selection algorithm. An example of such a case is described in 15= .2.=20 .

There are scenarios w= here=20 each PE needs to advertize Active preferential forwarding status on a singl= e PW=20 in the redundancy set. In order to ensure that both PE nodes make the same= =20 selection, they MUST use the above active PW selection algorithm to determi= ne=20 the PW eligible for active state. An example of such a case = is=20 described in 15.5. .

In steady state with= =20 consistent configuration, a PE will always find an active PW. However, it i= s=20 possible that such a PW is not found due to a mis-configuration. In the eve= nt=20 that an active PW is not found, a management indication SHOULD be generated= . If=20 a management indication for failure to find an active PW was generated and = an=20 active PW is subsequently found, a management indication should be generate= d, so=20 clearing the previous failure indication. Additionally, a PE may use the=20 optional request switchover procedures described in Section 6.3. to have bo= th PE=20 nodes switch to a common PW.

There may also be tra= nsient=20 conditions where endpoints do not share a common view of the Active/Standby= =20 state of the PWs. This could be caused by propagation delay of the T-LDP st= atus=20 messages between endpoints. In this case, the behavior of the receiving end= point=20 is outside the scope of this document.

Thus, in this mode of= =20 operation, the following definition of Active and Standby PW states=20 apply:

o        &n= bsp;=20 Active State   &nb= sp;            =             &nb= sp;            =        =20

A PW is considered to= be in=20 Active state when the PW labels are exchanged between its two endpoints and= the=20 status bits exchanged between the endpoints indicate the PW is UP and its=20 preferential forwarding status is Active at both endpoints. In this state u= ser=20 traffic can flow over the PW in both directions. As described in Section 5.= 1. ,=20 the PE nodes must implement a common mechanism to select one PW for forward= ing=20 in case multiple PWs qualify for the Active state.

o        &n= bsp;=20 Standby State

A PW is considered to= be in=20 Standby state when the PW labels are exchanged between its two endpoints, b= ut=20 the Preferential Forwarding status bits exchanged indicate the PW preferent= ial=20 forwarding status is Standby at one or both endpoints. In this state the=20 endpoints MUST NOT forward data traffic over the PW but MAY allow PW OAM=20 packets, e.g., Virtual Connection Connectivity Verification (VCCV) packets = [10],=20 to be sent and received in order to test the liveliness of standby PWs. The= =20 endpoints of the PW may also allow the forwarding of specific control plane= =20 packets of applications using the PW. The specification of applications and= the=20 allowed control plane packets is outside the scope of this document. If the= PW=20 is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be flushe= d=20 when it transitions to Standby state according to the procedures in RFC4762= [3]=20 and [9].

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
From: Aissaoui, Mustapha (Mustapha)=20
Sent: Thursday, March 22, 2012 11:59 AM
To:=20 'pwe3@ietf.org'; Daniel Cohn
Cc: 'stbryant@cisco.com';=20 'draft-ietf-pwe3-redundancy-bit@tools.ietf.org'; 'ietf@ietf.org'; 'Andrew G= .=20 Malis'
Subject: RE: [PWE3] Last Call:=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard

Dear all,
I=20 received comments from Daniel regarding the intended use of the optional ac= tive=20 PW selection mechanism in section 5.1. I pasted below the correspondin= g=20 paragraph of Section 5.1 with the changes we agreed to underlined. =20
 
He also asked if the default active PW selection= =20 mechanism should be referenced in Section 5.2 with the Master/Slave mode of= =20 operation. Although, it is not stricly required for interoperability,=20 implementations would benefit from a consistent behaviour. I used SHOULD in= that=20 case. The text is also pasted below with the changes=20 underlined.
 
Let me know if you have any comments on=20 this.
 
Regards,
Mustapha.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I. Changes to Section 5.1 - 3rd=20 paragraph:
"

If more than one PW qualifies for the A= ctive=20 state, each PW endpoint MUST implement a common mechanism to choose the PW = for=20 forwarding. The default mechanism MUST be supported by all implementations = and=20 operates as follows:

1.    =20 For FEC128 PW, the PW with = the=20 lowest pw-id value is selected.

2.    =20 For FEC129 PW, each PW in a= =20 redundant set is uniquely identified at each PE using the following triplet= :=20 AGI::SAII::TAII. The unsigned integer form of the concatenated word can be = used=20 in the comparison. However, the SAII and TAII values as seen on a PE node a= re=20 the mirror values of what the peer PE node sees. To have both PE nodes comp= are=20 the same value we propose that the PE with the lowest system IP address use= the=20 unsigned integer form of AGI::SAII::TAII while the PE with the highest syst= em IP=20 address use the unsigned integer form of AGI::TAII::SAII. This way, both PE= s=20 will compare the same values. The PW which corresponds to the minimum of th= e=20 compared values across all PWs in the redundant is=20 selected.

Note 1: in the case where the system IP= address=20 is not known, it is recommended to implement the optional active PW=20 selection mechanism described next.

Note 2: in the case of segmented PW, th= e=20 operator needs to make sure that the pw-id or AGI::SAII::TAII of the redund= ant=20 PWs within the first and last segment are ordered consistently such that th= e=20 same end-to-end MS-PW gets selected. Otherwise, it is recommended to implem= ent=20 the optional active PW selection mechanism described=20 next.

The PW endpoints MAY also implement the= =20 following optional active PW selection mechanism.=20

1.    =20 If the PW endpoint is confi= gured=20 with the precedence parameter on each PW in the redundant set, it must sele= ct=20 the PW with the lowest configured precedence value.=20

2.    =20 If the PW endpoint is confi= gured=20 with one PW as primary and one or more PWs as secondary, it must select the= =20 primary PW in preference to all secondary PWs. If a primary PW is not avail= able,=20 it must use the secondary PW with the lowest precedence value. If the prima= ry PW=20 becomes available, a PW endpoint must revert to it immediately or after the= =20 expiration of a configurable delay.

3.    =20 This active PW selection= =20 mechanism assumes the precedence parameter values are configured consistent= ly at=20 both PW endpoints and that unique values are assigned to the PWs in the sam= e=20 redundancy set to achieve tie-breaking using this=20 mechanism.

"
 
II. Changes to Section 5.2 - 5th=20 paragraph:
"

If more than one PW qualify for the Act= ive=20 state, the Master PW endpoint node selects one. There is no requirement = to=20 specify a default active PW selection mechanism in this case but for consis= tency=20 across implementations, the Master PW endpoint SHOULD implement the default= =20 active PW selection mechanism described in Section 5.1.=20

If the Master PW endpoint implements th= e=20 optional active PW selection mechanism based on primay/secondary and preced= ence=20 parameters, it MUST follow the following behaviour:=20

1.    =20 If the PW endpoint is=20 configured with the precedence parameter on each PW in the redundant s= et,=20 it must select the PW with the lowest configured precedence=20 value.

2.    =20 If the PW endpoint is=20 configured with one PW as primary and one or more PWs as secondary, it= must=20 select the primary PW in preference to all secondary PWs. If a primary= PW=20 is not available, it must use the secondary PW with the lowest precede= nce=20 value. If the primary PW becomes available, a PW endpoint must revert = to it=20 immediately or after the expiration of a configurable=20 delay.

"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: Aissaoui, Mustapha (Mustapha)=20
Sent: Wednesday, March 07, 2012 12:56 PM
To: Andrew G.= =20 Malis
Cc: stbryant@cisco.com;=20 draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3@ietf.org;=20 ietf@ietf.org
Subject: RE: [PWE3] Last Call:=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard

makes sense Andy.
 
Thanks,
Mustapha.

From: Andrew G. Malis [mailto:amalis@gm= ail.com]=20
Sent: Wednesday, March 07, 2012 12:53 PM
To: Aissaoui,= =20 Mustapha (Mustapha)
Cc: stbryant@cisco.com;=20 draft-ietf-pwe3-redundancy-bit@tools.ietf.org; pwe3@ietf.org;=20 ietf@ietf.org
Subject: Re: [PWE3] Last Call:=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard

Mustapha,

You might want to wait for any other LC comment= s=20 before updating.

Thanks,
Andy

On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha= =20 (Mustapha) <mustapha.aissaoui@alca= tel-lucent.com>=20 wrote:
Ooops. Thank you for pointing this out Stewart. I will = make=20 the update and publish a new revision.

Mustapha.

-----Original Message-----
From: Stewart Bryant=20 [mailto:stbryant@cisco.com]
= Sent:=20 Wednesday, March 07, 2012 12:48 PM
To: draft-ietf-= pwe3-redundancy-bit@tools.ietf.org
Cc:=20 ietf@ietf.org; pwe3@ietf.org
Subject: Re: Last Call= :=20 <draft-ietf-pwe3-redundancy-bit-06.txt> (Pseudowire Preferential=20 Forwarding Status Bit) to Proposed Standard


Authors

The= re=20 was on point that I notice that you did not address from the AD review an= d so=20 I am picking it up as a LC comment:

In section 10 you=20 say:

   "This document makes the following update to the= =20 PwOperStatusTC
   textual convention in RFC5542 [8]:=20 "

This update should be recorded in the metadata (top left front p= age)=20 and it is usual to put a one line note in the=20 abstract.

Stewart



On 07/03/2012 17:00, The IESG=20 wrote:
> The IESG has received a request from the Pseudowire Emulat= ion=20 Edge to
> Edge WG (pwe3) to consider the following document:
>= ; -=20 'Pseudowire Preferential Forwarding Status Bit'
>  =20  <draft-ietf-pwe3-redundancy-bit-06.txt>  as a Proposed=20 Standard
>
> The IESG plans to make a decision in the next fe= w=20 weeks, and solicits
> final comments on this action. Please send=20 substantive comments to the
> ietf@ietf.org mailing lists by 2012-03-= 21.=20 Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, = please=20 retain the
> beginning of the Subject line to allow automated=20 sorting.
>
> Abstract
>
>
>     T= his=20 document describes a mechanism for standby status signaling of
> &n= bsp;=20   redundant pseudowires (PWs) between their termination points. A=20 set
>     of redundant PWs is configured between provider= edge=20 (PE) nodes in
>     single-segment pseudowire (SS-PW)=20 applications, or between
>     terminating provider edge= =20 (T-PE) nodes in multi-segment pseudowire
>     (MS-PW)=20 applications.
>
>     In order for the PE/T-PE node= s to=20 indicate the preferred PW to use
>     for forwarding PW= =20 packets to one another, a new status bit is needed
>     = to=20 indicate a preferential forwarding status of Active or Standby for
>= ;=20     each PW in a redundant set.
>
>     I= n=20 addition, a second status bit is defined to allow peer PE nodes to
>= ;=20     coordinate a switchover operation of the=20 PW.
>
>
>
>
>
>
> The file can = be=20 obtained via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundanc= y-bit/
>
>=20 IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundanc= y-bit/ballot/
>
>
>=20 No IPR declarations have been submitted directly on this=20 I-D.
>
>
>=20 _______________________________________________
> IETF-Announce mai= ling=20 list
> IETF-Announce@ietf.org
>= https://www.ietf.org/mailman/listinfo/ietf-announce>


--
For=20 corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html


_______________________________________________pwe3=20 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
<= /DIV>

--_000_5DF53972F7E9134782DCE51624466FE50BD6070745USNAVSXCHMBSC_-- From yaakov_s@rad.com Mon Apr 30 10:55: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 EDB0321F88C1 for ; Mon, 30 Apr 2012 10:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.057, 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 XjI9E5XY6+eZ for ; Mon, 30 Apr 2012 10:55:20 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6F30721F88BC for ; Mon, 30 Apr 2012 10:55:16 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 30 Apr 2012 20:38:30 +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; Mon, 30 Apr 2012 20:55:11 +0300 From: Yaakov Stein To: "stbryant@cisco.com" , "l2vpn@ietf.org" , pwe3 Thread-Topic: IPR Statements concerning etree Thread-Index: AQHNHwM0TCn7gW/V0UuYebtPmzR2Kpazsu9w Date: Mon, 30 Apr 2012 17:55:10 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9043C1CCE@EXRAD5.ad.rad.co.il> References: <51AC216A-75C8-4075-AA23-D80081CB61CA@vigilsec.com> <4F9174A3.6000102@cisco.com> In-Reply-To: <4F9174A3.6000102@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: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090209.4F9ED200.0069,ss=1,fgs=0 Subject: Re: [PWE3] IPR Statements concerning etree 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, 30 Apr 2012 17:55:24 -0000 --_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You needn't all seven disclosures - they all refer to the same US application (11/508,599) and its family. If you are experiencing difficulties in finding this application, it is simply because the distinguished IPR disclosure submitter seems to ha= ve forgotten that this application was granted in early 2010, and is now US 7,660,303 "POINT-TO-MULTIPOINT FUNCTIONALITY IN A BRIDGED NET= WORK". The priority date seems to be 22 Aug 2006. Y(J)S From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= tewart Bryant Sent: Friday, April 20, 2012 17:37 To: l2vpn@ietf.org; l2vpn-chairs@tools.ietf.org; pwe3; pwe3-chairs@tools.ie= tf.org Subject: Fwd: IPR Statements concerning etree WGs, You may wish to look at the following IPR statements that were received yesterday. They all relate to etree. The stated terms appear to require payment of a royalty. Stewart -------- Original Message -------- Subject: IPR Statements Date: Thu, 19 Apr 2012 13:04:27 -0400 From: Russ Housley To: Stewart Bryant Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:14:30 PM EDT > To: simon.delord@gmail.com, raymond.key@ie= ee.org, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, lizhong.jin@zte.com.cn, frede= ric.jounay@orange.ch > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-delord-pwe3-cw-bit-etree-07 > > > Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhong Jin, F= rederic JOUNAY: > > An IPR disclosure that pertains to your Internet-Draft entitled "Control = Word > Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-etree) was subm= itted > to the IETF Secretariat on 2012-04-19 and has been posted on the "IETF Pa= ge of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/i= pr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's State= ment about IPR related to draft-delord-pwe3-cw-bit-etree-07.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:08 PM EDT > To: yuqun.cao@gmail.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-cao-l2vpn-vpls-etree-02 > > > Dear Yuqun Cao: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensio= n to > VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted to the IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intell= ectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). Th= e title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rela= ted to > draft-cao-l2vpn-vpls-etree-02."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:15:34 PM EDT > To: chen.ran@zte.com.cn > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-chen-l2vpn-vpls-etree-vlan-01 > > > Dear Ran Chen: > > An IPR disclosure that pertains to your Internet-Draft entitled "Automati= c VLAN > allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was submitted to= the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/i= pr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's State= ment about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:16:29 PM EDT > To: jiangyuanlong@huawei.com, lucyyong@h= uawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-jiang-l2vpn-etree-bgp-00 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balu= s, Wim Henderickx, Ali Sajassi: > > An IPR disclosure that pertains to your Internet-Draft entitled "E-Tree S= upport > in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) was submitted t= o the > IETF Secretariat on 2012-04-19 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/i= pr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's State= ment about IPR related to draft-jiang-l2vpn-etree-bgp-00."); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:02 PM EDT > To: yljiang@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-jiang-l2vpn-vpls-pe-etree-05 > > > Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balu= s, Wim Henderickx: > > An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE = Model > for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was submitted to th= e IETF > Secretariat on 2012-04-19 and has been posted on the "IETF Page of Intell= ectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). Th= e title > of the IPR disclosure is "Orckit-Corrigent Ltd's Statement about IPR rela= ted to > draft-jiang-l2vpn-vpls-pe-etree-05.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:17:48 PM EDT > To: danielc@orckit.com, rafir@orckit.com, pagarwal@broadcom.com, r= aymond.key@team.telstra.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-ram-l2vpn-ldp-vpls-etree-2pw-02 > > > Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensio= n to > LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-etree-2pw) wa= s > submitted to the IETF Secretariat on 2012-04-19 and has been posted on th= e "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1755/). The title of the IPR disclosure= is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-ld= p-vpls- > etree-2pw-02.""); > > The IETF Secretariat > Begin forwarded message: > From: IETF Secretariat > Date: April 19, 2012 12:18:32 PM EDT > To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pag= arwal@broadcom.com, josh.rogers@twcable.com > Cc: housley@vigilsec.com, ipr-announce@ietf.= org > Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about IPR relat= ed to draft-ram-l2vpn-etree-multiple-pw-01 > > > Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers: > > An IPR disclosure that pertains to your Internet-Draft entitled "Extensio= n to > VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-multiple-pw) w= as > submitted to the IETF Secretariat on 2012-04-19 and has been posted on th= e "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1754/). The title of the IPR disclosure= is > "Orckit-Corrigent Ltd's Statement about IPR related to draft-ram-l2vpn-et= ree- > multiple-pw-01.""); > > The IETF Secretariat > --_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

You needn't all seven disclosures -

they all refer to the same US application (11/508,599) and i= ts family.

 

If you are experiencing difficulties in finding this applica= tion,

it is simply because the distinguished IPR disclosure submit= ter seems to have forgotten

that this application was granted in early 2010,<= /span>

and is now US 7,660,303 "POINT-TO-MULTIPOINT FUNCTIONAL= ITY IN A BRIDGED NETWORK".

The priority date seems to be 22 Aug 2006.=

 

Y(J)S

 

 

From: l2vpn-bounces@= ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, April 20, 2012 17:37
To: l2vpn@ietf.org; l2vpn-chairs@tools.ietf.org; pwe3; pwe3-chairs@t= ools.ietf.org
Subject: Fwd: IPR Statements concerning etree

 


WGs,

You may wish to look at the following IPR statements that were
received yesterday.

They all relate to etree.

The stated terms appear to require payment of a royalty.

Stewart


-------- Original Message --------

Subjec= t:

IPR Statements

Date: =

Thu, 19 Apr 2012 13:04:27 -0400

From: =

Russ Housley <housley@vigilsec.com>

To:

Stewart Bryant <stbryant@cisco.com>

 

 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:14:30 PM EDT
> To: simon.delord@gmail.=
com, raymond.key@ieee.org, =
wim.henderickx@alcatel=
-lucent.com, lucy.yong@huawei.c=
om, lizhong.jin@zte.com.cn, frederic.jounay@orange.ch
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-delord-pwe3-cw-bit-etree-07
> 
> 
> Dear Simon DeLord, Raymond Key, Wim Henderickx, Lucy Yong, Lizhon=
g Jin, Frederic JOUNAY:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Control Word
> Reserved bit for use in E-Tree" (draft-delord-pwe3-cw-bit-et=
ree) was submitted
> to the IETF Secretariat on 2012-04-19 and has been posted on the =
"IETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1760/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stateme=
nt about IPR related to draft-delord-pwe3-cw-bit-etree-07."");
> 
> The IETF Secretariat
> 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:15:08 PM EDT
> To: yuqun.cao@gmail.com
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-cao-l2vpn-vpls-etree-02
> 
> 
> Dear Yuqun Cao:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Extension to
> VPLS for E-Tree" (draft-cao-l2vpn-vpls-etree) was submitted =
to the IETF
> Secretariat on 2012-04-19 and has been posted on the "IETF P=
age of Intellectual
> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1759/). The title=

> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement a=
bout IPR related to
> draft-cao-l2vpn-vpls-etree-02.");
> 
> The IETF Secretariat
> 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:15:34 PM EDT
> To: chen.ran@zte.com.cn
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-chen-l2vpn-vpls-etree-vlan-01
> 
> 
> Dear Ran Chen:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Automatic VLAN
> allocation in E-tree" (draft-chen-l2vpn-vpls-etree-vlan) was=
 submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "I=
ETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1758/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stateme=
nt about IPR related to draft-chen-l2vpn-vpls-etree-vlan-01.");
> 
> The IETF Secretariat
> 
Begin forwarded message:
 
> From: IETF Secretariat <i=
etf-ipr@ietf.org>
> Date: April 19, 2012 12:16:29 PM EDT
> To: jiangyuanlong@hua=
wei.com, lucyyong@huawei.com=
, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucen=
t.com, wim.henderi=
ckx@alcatel-lucent.com, sajassi@ci=
sco.com
> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org
> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-jiang-l2vpn-etree-bgp-00
> 
> 
> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Flo=
rin Balus, Wim Henderickx, Ali Sajassi:
> 
> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;E-Tree Support
> in VPLS with BGP Signaling" (draft-jiang-l2vpn-etree-bgp) wa=
s submitted to the
> IETF Secretariat on 2012-04-19 and has been posted on the "I=
ETF Page of
> Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1757/). The title of the IPR disclosure is "Orckit-Corrigent Ltd's Stateme=
nt about IPR related to draft-jiang-l2vpn-etree-bgp-00.");<=
/pre>

> 


> The IETF Secretariat


> 


Begin forwarded message:


 


> From: IETF Secretariat <i=
etf-ipr@ietf.org>


> Date: April 19, 2012 12:17:02 PM EDT


> To: yljiang@huawei.com,=
 lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange-ftgroup.com, florin.balus@alcatel=
-lucent.com, wim.h=
enderickx@alcatel-lucent.com


> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org


> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-jiang-l2vpn-vpls-pe-etree-05


> 


> 


> Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Flo=
rin Balus, Wim Henderickx:


> 


> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;VPLS PE Model


> for E-Tree Support" (draft-jiang-l2vpn-vpls-pe-etree) was su=
bmitted to the IETF


> Secretariat on 2012-04-19 and has been posted on the "IETF P=
age of Intellectual


> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1756/). The title=



> of the IPR disclosure is "Orckit-Corrigent Ltd's Statement a=
bout IPR related to


> draft-jiang-l2vpn-vpls-pe-etree-05."");

> 


> The IETF Secretariat


> 


Begin forwarded message:


 


> From: IETF Secretariat <i=
etf-ipr@ietf.org>


> Date: April 19, 2012 12:17:48 PM EDT


> To: danielc@orckit.com,=
 rafir@orckit.com, pagarwal@broadcom.com, raymond.key@team.telstra.com


> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org


> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-ram-l2vpn-ldp-vpls-etree-2pw-02


> 


> 


> Dear Daniel Cohn, Rafi Ram, Puneet Agarwal, Raymond Key:


> 


> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Extension to


> LDP-VPLS for E-Tree Using Two PW" (draft-ram-l2vpn-ldp-vpls-=
etree-2pw) was


> submitted to the IETF Secretariat on 2012-04-19 and has been post=
ed on the "IETF Page of Intellectual Property Rights Disclosures"=



> (https://datat=
racker.ietf.org/ipr/1755/). The title of the IPR disclosure is


> "Orckit-Corrigent Ltd's Statement about IPR related to draft=
-ram-l2vpn-ldp-vpls-


> etree-2pw-02."");


> 


> The IETF Secretariat


> 


Begin forwarded message:


 


> From: IETF Secretariat <i=
etf-ipr@ietf.org>


> Date: April 19, 2012 12:18:32 PM EDT


> To: rafir@orckit.com, danielc@orckit.com, raymond.key@ieee.org, pagarwal@broadcom.com, josh.rogers@twcable.com


> Cc: housley@vigilsec.com<=
/a>, ipr-announce@ietf.org


> Subject: IPR Disclosure: Orckit-Corrigent Ltd's Statement about I=
PR related to draft-ram-l2vpn-etree-multiple-pw-01


> 


> 


> Dear Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua R=
ogers:


> 


> An IPR disclosure that pertains to your Internet-Draft entitled &=
quot;Extension to


> VPLS for E-Tree Using Multiple PWs" (draft-ram-l2vpn-etree-m=
ultiple-pw) was


> submitted to the IETF Secretariat on 2012-04-19 and has been post=
ed on the "IETF


> Page of Intellectual Property Rights Disclosures"=



> (https://datat=
racker.ietf.org/ipr/1754/). The title of the IPR disclosure is


> "Orckit-Corrigent Ltd's Statement about IPR related to draft=
-ram-l2vpn-etree-


> multiple-pw-01."");


> 


> The IETF Secretariat


> 


 


 
--_000_07F7D7DED63154409F13298786A2ADC9043C1CCEEXRAD5adradcoil_-- From stbryant@cisco.com Mon Apr 30 12:43:23 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 714A921E8063 for ; Mon, 30 Apr 2012 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 RFlw-0RPeD8r for ; Mon, 30 Apr 2012 12:43:18 -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 68EDE21E804E for ; Mon, 30 Apr 2012 12:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=15567; q=dns/txt; s=iport; t=1335814995; x=1337024595; h=message-id:date:from:reply-to:mime-version:to:subject; bh=WG9/neWsiDJGXhSciLvggSzmvawbyxZlrs/DL3vInmg=; b=esP2z6ZCc9YcKT/hvz++Uf8MjWII462HHK7CIRY89Dpo7i92CC7XFhy5 hVH0ZEKkp4Hm1V8WoT1H26qnkFGuJ1MuaCzp3Hn0fw/oLMNwGswJ3RETy em8i5HQH1v9jhnEy022l/tSTRahce+qXrX8cagH22W8a9uwbp+J0i1QNU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGzqnk+Q/khN/2dsb2JhbABEr1ODAIEHggkBAQEDEwECA2Y3NAJMAQwIAQEXB4dmBQuaMoNCEIFOmmORIgSVfo5ZgQJngmmBVQYR X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208,217";a="136646694" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 30 Apr 2012 19:43:14 +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 q3UJhE4m013141; Mon, 30 Apr 2012 19:43:14 GMT Received: from dhcp-128-107-166-59.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3UJhBHd015520; Mon, 30 Apr 2012 20:43:12 +0100 (BST) Message-ID: <4F9EEB4F.70209@cisco.com> Date: Mon, 30 Apr 2012 20:43:11 +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-vccv-impl-survey-results@tools.ietf.org, "pwe3-chairs@tools.ietf.org" , "pwe3-ads@tools.ietf.org" , pwe3 Content-Type: multipart/alternative; boundary="------------090202040007040703070804" Subject: [PWE3] draft-ietf-pwe3-vccv-impl-survey-results - AD review 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: Mon, 30 Apr 2012 19:43:24 -0000 This is a multi-part message in MIME format. --------------090202040007040703070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit PWE3 Chairs: Here are my AD review comments on this draft Please look for ">" in the first column. - Stewart ===== > You present a lot of data, but there there is no conclusion. > I think that you really need to present the WG consensus conclusion > of the data section my section and the WG consensus conclusion of > the results and a whole and any recommended action. ==== The Pseudowire (PW)& Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results draft-ietf-pwe3-vccv-impl-survey-results-00 Abstract Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. > Actually it's more fundamental than "better emulate" they carry > info fundamental to the emmulation. ====== 1. Introduction The IETF has defined many encapsulations of various layer 1 and layer 2 service-specific PDUs and circuit data. > Surely this is the IETF PWE3 WG? > Aren't they also PW encaps? > There are many non PWE3 L2 encaps that have been defined. Within these encapsulations, there are often several modes of encapsulation which have differing requirements in order to fully emulate the service. As such, the use of the PWE3 Control Word is mandated in many of the encapsulations, but not all. > The second sentence does not follow from the first This can present interoperability issues related to A) Control Word use and B) VCCV Control Channel negotiation in mixed implementation environments. > and then this does not logically follow. > VCCV needs to be expanded and a ref provided The encapsulations and modes for which the Control Word is currently optional are: o Ethernet Tagged Mode o Ethernet Raw Mode o PPP o HDLC o Frame Relay Port Mode o ATM (N:1 Cell Mode) > You need a ref for each of the above [RFC5085] defines three Control Channel types for MPLS PW's: Type 1, > You will get a ref vs name IESG comment with the above. > You mean "VCCV [RFC5085]....." using the Pseudowire Control Word, Type 2, using the Router Alert Label, and Type 3, using TTL Expiration (e.g. MPLS PW Label with TTL == 1). While Type 2 (RA Label) is indicated as being "the preferred > Is RA a well known abbreviation? ==== 1.1. PW/VCCV Survey Overview Per the direction of the PWE3 Working Group chairs, a survey was created to sample the nature of implementations of Pseudowires, with specific emphasis on Control Word usage, and VCCV, with emphasis on Control Channel and Control Type usage. The survey consisted of a series of questions based on direction of the WG chairs and the survey opened to the public on November 4, 2010. The URL for the survey (now closed) was http://www.surveymonkey.com/pwe3/. The survey ran from November 4, 2010 until February 25, 2011. > A statement of fact that is currently unverifiable since the URL > is no longer valid. 1.2. PW/VCCV Survey Form The PW/VCCV Implementation Survey requested the following information about user implementations: - Responding Organziation. No provisions were made for anonymity. All responses required a valid email address in order to validate the survey response. - Of the various encapsulations (and options therein) known at the time, including the WG draft for Fiber Channel), which were implemented b the respondent. These included: > You need to provide refs for each of the PWs that you talk about > I know it's too late for the responders, but the for the future reader > it needs to be provided as a note somewhere. > Also with LSP ping and ICMP Ping - need a ref. o Ethernet Tagged Mode - RFC 4448 o Ethernet Raw Mode - RFC 4448 o SAToP - RFC 4553 o PPP - RFC 4618 o HDLC - RFC 4618 o Frame Relay (Port Mode) - RFC 4619 o Frame Relay (1:1 Mode) - RFC 4619 o ATM (N:1 Mode) - RFC 4717 o ATM (1:1 Mode) - RFC 4717 o ATM (AAL5 SDU Mode) - RFC 4717 o ATM (AAL5 PDU Mode) - RFC 4717 o CEP - RFC 4842 o CESoPSN - RFC 5086 o TDMoIP - RFC 5087 o Fiber Channel (Port Mode) - draft-ietf-pwe3-fc-encap - Approximately how many Pseudowires of each type were deployed. Respondents could list a number, or for the sake of privacy, could just respond "In-Use" instead. - For each encapsulation listed above, the respondent could indicated which Control Channel was in use. The options listed were: o Control Word (Type 1) o Router Alert Label (Type 2) o TTL Expiry (Type 3) - For each encapsulation listed above, the respondent could indicate which Connectivity Verification types were in use. The options were: o ICMP Ping o LSP Ping - For each encapsulation type for which the use of the Control Word is optional, the respondents could indicated the encaps for which Control Word was supported by the equipment used and whether it was in use in the network. The encaps listed were: o Ethernet (Tagged Mode) o Ethernet (Raw Mode) o PPP o HDLC o Frame Relay (Port Mode) o ATM (N:1 Cell Mode) - Finally, a freeform entry was provided for the respondent to provide feedback regarding PW and VCCV deployments, VCCV interoperability challenges, the survey or any network/vendor details they wished to share. ======== 2. Survey Results 2.1. Respondents The following companies participated in the PW/VCCV Implementation Survey. The data provided has been aggregated. No specific company's reponse will be detailed herein. > To preserve anonymity you need to make sure there is on order correlation > (and state that), and it would be nice to have the following in alphabetical > order o Time Warner Cable o Bright House Networks o Tinet o AboveNet o Telecom New Zealand o Cox Communications o MTN South Africa o Wipro Technologies o Verizon o AMS-IX o Superonline o Deutsche Telekom AG o Internet Solution o Easynet Global Services o Telstra Corporation o OJSC MegaFon o France Telecom Orange > How did these operators know about this survey > Did any vendors reply, if so what action did you take? ===== 4. PW VCCV is very useful tool for finding faults in each PW channel. Without this we can not find fault on a PW channel. PW VCCV using BFD is another better option. Introperbility challences are with Ethernet OAM mechanism. > Given the sensitivity please clarify if you mean Eth OAM, or > OAM for Eth PWs. ==== 3. Security Considerations As this document is a report of the PW/VCCV User Implementation Survey results, no security considerations are introduced. > SCs should include the precautions you took to ensure the validity > of the sample and the data. --------------090202040007040703070804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
PWE3 Chairs:

Here are my AD review comments on this draft

Please look for ">" in the first column.

- Stewart

=====

> You present a lot of data, but there there is no conclusion.
> I think that you really need to present the WG consensus conclusion
> of the data section my section and the WG consensus conclusion of
> the results and a whole and any recommended action.

====


 The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV)
                     Implementation Survey Results
              draft-ietf-pwe3-vccv-impl-survey-results-00

Abstract

   Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate
   the use of the Control Word (CW) in order to better emulate the
   services for which the encapsulations have been defined.  

> Actually it's more fundamental than "better emulate" they carry
> info fundamental to the emmulation.

======



1.  Introduction

   The IETF has defined many encapsulations of various layer 1 and layer
   2 service-specific PDUs and circuit data.  

> Surely this is the IETF PWE3 WG?
> Aren't they also PW encaps?
> There are many non PWE3 L2 encaps that have been defined.

Within these
   encapsulations, there are often several modes of encapsulation which
   have differing requirements in order to fully emulate the service.

 As such, the use of the PWE3 Control Word is mandated in many of the
   encapsulations, but not all.  

> The second sentence does not follow from the first

This can present interoperability
   issues related to A) Control Word use and B) VCCV Control Channel
   negotiation in mixed implementation environments.

> and then this does not logically follow.
> VCCV needs to be expanded and a ref provided

 The encapsulations and modes for which the Control Word is currently
 optional are:

   o  Ethernet Tagged Mode

   o  Ethernet Raw Mode

   o  PPP

   o  HDLC

   o  Frame Relay Port Mode

   o  ATM (N:1 Cell Mode)

> You need a ref for each of the above


 [RFC5085] defines three Control Channel types for MPLS PW's: Type 1,

> You will get a ref vs name IESG comment with the above.
> You mean "VCCV [RFC5085]....."

   using the Pseudowire Control Word, Type 2, using the Router Alert
   Label, and Type 3, using TTL Expiration (e.g.  MPLS PW Label with TTL
   == 1).  While Type 2 (RA Label) is indicated as being "the preferred

> Is RA a well known abbreviation?

====


 1.1.  PW/VCCV Survey Overview

   Per the direction of the PWE3 Working Group chairs, a survey was
   created to sample the nature of implementations of Pseudowires, with
   specific emphasis on Control Word usage, and VCCV, with emphasis on
   Control Channel and Control Type usage.  The survey consisted of a
   series of questions based on direction of the WG chairs and the
   survey opened to the public on November 4, 2010.  The URL for the
   survey (now closed) was http://www.surveymonkey.com/pwe3/.  The
   survey ran from November 4, 2010 until February 25, 2011.


> A statement of fact that is currently unverifiable since the URL
> is no longer valid.

 1.2.  PW/VCCV Survey Form

   The PW/VCCV Implementation Survey requested the following information
   about user implementations:

   - Responding Organziation.  No provisions were made for anonymity.
   All responses required a valid email address in order to validate the
   survey response.

   - Of the various encapsulations (and options therein) known at the
   time, including the WG draft for Fiber Channel), which were
   implemented b the respondent.  These included:

> You need to provide refs for each of the PWs that you talk about
> I know it's too late for the responders, but the for the future reader
> it needs to be provided as a note somewhere.
> Also with LSP ping and ICMP Ping - need a ref.

   o  Ethernet Tagged Mode - RFC 4448

   o  Ethernet Raw Mode - RFC 4448

   o  SAToP - RFC 4553

   o  PPP - RFC 4618

   o  HDLC - RFC 4618

   o  Frame Relay (Port Mode) - RFC 4619

   o  Frame Relay (1:1 Mode) - RFC 4619

   o  ATM (N:1 Mode) - RFC 4717

   o  ATM (1:1 Mode) - RFC 4717

   o  ATM (AAL5 SDU Mode) - RFC 4717

   o  ATM (AAL5 PDU Mode) - RFC 4717

   o  CEP - RFC 4842

   o  CESoPSN - RFC 5086

   o  TDMoIP - RFC 5087

   o  Fiber Channel (Port Mode) - draft-ietf-pwe3-fc-encap

   - Approximately how many Pseudowires of each type were deployed.
   Respondents could list a number, or for the sake of privacy, could
   just respond "In-Use" instead.

   - For each encapsulation listed above, the respondent could indicated
   which Control Channel was in use.  The options listed were:

   o  Control Word (Type 1)

   o  Router Alert Label (Type 2)

   o  TTL Expiry (Type 3)

   - For each encapsulation listed above, the respondent could indicate
   which Connectivity Verification types were in use.  The options were:

   o  ICMP Ping

   o  LSP Ping

   - For each encapsulation type for which the use of the Control Word
   is optional, the respondents could indicated the encaps for which
   Control Word was supported by the equipment used and whether it was
   in use in the network.  The encaps listed were:

   o  Ethernet (Tagged Mode)

   o  Ethernet (Raw Mode)

   o  PPP

   o  HDLC

   o  Frame Relay (Port Mode)

   o  ATM (N:1 Cell Mode)

   - Finally, a freeform entry was provided for the respondent to
   provide feedback regarding PW and VCCV deployments, VCCV
   interoperability challenges, the survey or any network/vendor details
   they wished to share.

========


2.  Survey Results

2.1.  Respondents

   The following companies participated in the PW/VCCV Implementation
   Survey.  The data provided has been aggregated.  No specific
   company's reponse will be detailed herein.


> To preserve anonymity you need to make sure there is on order correlation
> (and state that), and it would be nice to have the following in alphabetical 
> order


   o  Time Warner Cable

   o  Bright House Networks

   o  Tinet

   o  AboveNet

   o  Telecom New Zealand

   o  Cox Communications

   o  MTN South Africa

   o  Wipro Technologies

   o  Verizon

   o  AMS-IX

   o  Superonline

   o  Deutsche Telekom AG

   o  Internet Solution

   o  Easynet Global Services

   o  Telstra Corporation

   o  OJSC MegaFon

   o  France Telecom Orange



> How did these operators know about this survey
> Did any vendors reply, if so what action did you take?



=====


   4.  PW VCCV is very useful tool for finding faults in each PW
       channel.  Without this we can not find fault on a PW channel.  PW
       VCCV using BFD is another better option.  Introperbility
       challences are with Ethernet OAM mechanism.

> Given the sensitivity please clarify if you mean Eth OAM, or 
> OAM for Eth PWs.

====


3.  Security Considerations

   As this document is a report of the PW/VCCV User Implementation
   Survey results, no security considerations are introduced.

> SCs should include the precautions you took to ensure the validity
> of the sample and the data.
--------------090202040007040703070804-- From iesg-secretary@ietf.org Mon Apr 30 15:38: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 3DDD021F8781; Mon, 30 Apr 2012 15:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 31cSyOPuTgeC; Mon, 30 Apr 2012 15:38:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753C21F8786; Mon, 30 Apr 2012 15:38:41 -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: <20120430223841.19678.87925.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 15:38:41 -0700 Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Protocol Action: 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' to Proposed Standard (draft-ietf-pwe3-pw-typed-wc-fec-03.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, 30 Apr 2012 22:38:42 -0000 The IESG has approved the following document: - 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' (draft-ietf-pwe3-pw-typed-wc-fec-03.txt) as a Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ Technical Summary The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. Working Group Summary There was solid consensus in the working group regarding this draft, no controversy or anything rough. Document Quality At least one implementation is in progress, but has not yet been deployed. There may be additional vendors with plans to implement. The draft received a good WG last call, which resulted in comments and a new revision. No particular expert review was necessary. Personnel Andrew Malis is the Document Shepherd Stewart Bryant is the Responsible Area Director RFC Editor Note In the Security Section OLD No new security considerations beyond that apply to the base LDP specification [RFC5036], [RFC4447], [RFC4762], and [RFC5920] apply to the use of the PW Typed Wildcard FEC Element types described in this document. NEW No new security considerations beyond that apply to LDP specifications [RFC5036], [RFC4447], [RFC4762], [RFC5918] and [RFC5920] apply to the use of the PW Typed Wildcard FEC Element types described in this document. END Please add an informative reference to RFC5918 S2: R bit: r/Must/MUST From gregory.mirsky@ericsson.com Mon Apr 30 16:48: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 7D74921E8118 for ; Mon, 30 Apr 2012 16:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 uj5oJvFZxrJR for ; Mon, 30 Apr 2012 16:48:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E350D21E8041 for ; Mon, 30 Apr 2012 16:47:59 -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 q3UNlvFo014377; Mon, 30 Apr 2012 18:47:59 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 30 Apr 2012 19:47:52 -0400 From: Gregory Mirsky To: Yaakov Stein , "pwe3@ietf.org" Date: Mon, 30 Apr 2012 19:47:51 -0400 Thread-Topic: In response to discussion of LI/LB for PW at IETF-83 Thread-Index: Ac0nK6eE6CRf1OTeRZSe/a/N5zn7dg== Message-ID: 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_FE60A4E52763E84B935532D7D9294FF13552C67A83EUSAACMS0715e_" MIME-Version: 1.0 Subject: [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: Mon, 30 Apr 2012 23:48:00 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13552C67A83EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 allotted = for the presentation * Proposed extensions, IMO, have nothing to do with timer that might = be associated with Loopback state and would take Maintanence Point out of L= oopback if expired. If such a timer to be enabled its configuration can be = 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_FE60A4E52763E84B935532D7D9294FF13552C67A83EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 all= otted for the presentation
  • Proposed extensions, IMO, have nothing t= o do with timer that might be associated with Loopback state and would take= Maintanence Point out of Loopback if expired. If such a timer to be enable= d its configuration can be part of OAM configuration through the LDP extensions or LSP Ping.
Yaakov, would such timer address your concern with security impact of = the proposed extension to control LI/LB via control plane?
 
Chairs, I hope that WG minutes can be corrected.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF13552C67A83EUSAACMS0715e_-- From gregory.mirsky@ericsson.com Mon Apr 30 17: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 3C02021F860E for ; Mon, 30 Apr 2012 17:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.180, 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 0Oxl76nhLFKK for ; Mon, 30 Apr 2012 17:01:53 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09521F86F4 for ; Mon, 30 Apr 2012 17:01:53 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4101pSj004974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 19:01:51 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.10]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 30 Apr 2012 20:01:51 -0400 From: Gregory Mirsky To: "sboutros@cisco.com" , "hshah@force10networks.com" , "pwe3@ietf.org" Date: Mon, 30 Apr 2012 20:01:50 -0400 Thread-Topic: Control of LB state through management plane Thread-Index: Ac0nLZuKAacNrY27T9qOMuVisrt5MA== Message-ID: 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_FE60A4E52763E84B935532D7D9294FF13552C67A85EUSAACMS0715e_" MIME-Version: 1.0 Subject: [PWE3] Control of LB state through management plane 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 00:01:54 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13552C67A85EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sami, Himanshu, et al., At presentation fo LDP Extensions to control LI/LB you've suggested that co= ntrol of LB state should be done through data plane only. Is that correct u= nderstanding of your comments? But the RFC 6435 in Section 4 states that LB= function can be configured by management plane. Hence I ask if signaling p= rotocol can be viewed as part of management plane and thus the proposed ext= ension is compliant with the RFC 6435. Your comments and questions greatly appreciated. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF13552C67A85EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sami, Himanshu, et al.,
At presentation fo LDP Extensions to control LI/LB you've suggested th= at control of LB state should be done through data plane only. Is that corr= ect understanding of your comments? But the RFC 6435 in Section 4 states th= at LB function can be configured by management plane. Hence I ask if signaling protocol can be viewed as par= t of management plane and thus the proposed extension is compliant with the= RFC 6435.
 
Your comments and questions greatly appreciated.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF13552C67A85EUSAACMS0715e_-- From jerdenebold@isocore.com Mon Apr 30 17:11: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 7F9B821F8733 for ; Mon, 30 Apr 2012 17:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcFeaan71Akn for ; Mon, 30 Apr 2012 17:11:10 -0700 (PDT) Received: from ns1.cpanel.btnaccess.com (unknown [205.177.121.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5935221F8731 for ; Mon, 30 Apr 2012 17:11:10 -0700 (PDT) Received: from [65.213.193.93] (port=57544 helo=VinceHP) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.77) (envelope-from ) id 1SP0gM-0006EO-Vp for pwe3@ietf.org; Mon, 30 Apr 2012 20:11:07 -0400 From: "Julia Erdenebold" To: References: <340C50A7-B675-42EE-ABCA-14F9E92F73CB@lucidvision.com> <015201cd2171$82fef360$88fcda20$@isocore.com> In-Reply-To: <015201cd2171$82fef360$88fcda20$@isocore.com> Date: Mon, 30 Apr 2012 20:11:10 -0400 Message-ID: <00cb01cd272e$e9863cc0$bc92b640$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01CD270D.62770DC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKEbRmDfsXHWO/PpT8NQlPOTyAUkgJngZ41lTJHSOA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Subject: [PWE3] FW: The MPLS 2012 International Conference Call For Papers 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 00:11:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CC_01CD270D.62770DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Due to numerous requests, we are extending the deadline for the submission of Call for Presentation abstract to Friday May 11. Please make sure to submit your abstracts to mpls2012-cfp@isocore.com. For further information, please refer to http://www.isocore.com/mpls2012/call_for_papers/cfp.htm. Regards, Julia The MPLS 2012 International Conference, the 15th Annual International Conference on MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2012/call_for_papers/cfp.htm Many of these topics have been of interest to members of in the past, and many people active on this list have been presenters at past events. On behalf of the Technical Planning Committee ------=_NextPart_000_00CC_01CD270D.62770DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Due to = numerous requests, we are extending the deadline for the submission of = Call for Presentation abstract to Friday May 11. Please make sure to = submit your abstracts to mpls2012-cfp@isocore.com.

 

For = further information, please refer to http://www.isocore.com/mpls2012/call_for_paper= s/cfp.htm.

 

Regards,

Julia

 

The MPLS 2012 International Conference, = the 15th Annual = International

Conference = on MPLS and Related Technologies, will be held October 28 = -

31, 2012, in = Washington, DC. The Technical Program Committee = is

soliciting = abstracts summarizing a proposed presentation = representing

original/unpu= blished work covering cutting-edge = topics.

 

Presentations= covering new technologies and operational experience = are

solicited = from network equipment vendors, service/transport = providers,

government = agencies, the research community, and enterprise = users.

The deadline = for submission of presentation proposals is April 30, = 2012.

If you want = further information on MPLS 2012 or want to submit = a

presentation = abstract, please see the following = URL:

 

 

Many of = these topics have been of interest to members of <this = community>

in the past, = and many people active on this list have = been

presenters = at past events.

 

 

On behalf of the Technical Planning Committee

------=_NextPart_000_00CC_01CD270D.62770DC0--