From internet-drafts@ietf.org Thu Oct 3 13:54:46 2013 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 5B23621F864D; Thu, 3 Oct 2013 13:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 K+VhPKuXtuog; Thu, 3 Oct 2013 13:54:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5739521F8578; Thu, 3 Oct 2013 13:39:01 -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.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131003203901.30291.48869.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2013 13:39:01 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-vccv-impl-survey-results-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:54:46 -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 Working= Group of the IETF. Title : The Pseudowire (PW) & Virtual Circuit Connectivity Verif= ication (VCCV) Implementation Survey Results Author(s) : Andrew G. Malis Filename : draft-ietf-pwe3-vccv-impl-survey-results-03.txt Pages : 37 Date : 2013-10-03 Abstract: The IETF PWE3 Working Group has defined many encapsulations of various layer 1 and layer 2 service-specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the PW/VCCV user community was conducted to determine implementation trends and the possibility of always mandating the Control Word. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-vccv-impl-survey-results-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-vccv-impl-survey-results= -03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From amalis@gmail.com Fri Oct 4 09:54:24 2013 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 21EF221F9CC5 for ; Fri, 4 Oct 2013 09:54:24 -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, HTML_MESSAGE=0.001, 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 Un7gd-DPdYTP for ; Fri, 4 Oct 2013 09:54:23 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 26A7E21F8D20 for ; Fri, 4 Oct 2013 09:54:19 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i4so4189251oah.22 for ; Fri, 04 Oct 2013 09:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=rWJbAYkjEaWwdCkZcD7LErHwgpI6rn9Zde16DWPkNFw=; b=FqgpRU2BqoGQdiYY10Pl9VRqmVG62BR/2qLFQRV+zb1tZnmCyLo/EATUNdqn0Jvyiu QRvnP2QgBx1tyewTpHPV6jzPmCbbEOxjSAbwvU2IEHwHItdQIwG1BKvutTe9FCQ650fL CMDh9rEbqRbWZDd4Vqi0cVTvA2HJbVmHGlexO2SMRmKVjmUgxp9saeEPovdZHRcq/oJD EuVB0D/R5RVruCHPloQjN6kJeMn7W6Q4Z9bh/NYjovjkdMcKxY2KbXJtp1lpB6UaB8bS ayY1ZBESmleAIHNWtddxTfYy9tEPJLVMkGA1MZEBaONWdPF4pjbZfUQx5svB82WKEwJZ zq4A== X-Received: by 10.60.131.41 with SMTP id oj9mr23226720oeb.40.1380905657460; Fri, 04 Oct 2013 09:54:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.182.9 with HTTP; Fri, 4 Oct 2013 09:53:57 -0700 (PDT) In-Reply-To: <07F7D7DED63154409F13298786A2ADC904ECBCBB@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC904ECBCBB@EXRAD5.ad.rad.co.il> From: "Andrew G. Malis" Date: Fri, 4 Oct 2013 12:53:57 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=089e013c701a2e6f2504e7ed27ba Subject: [PWE3] Fwd: WG LC on draft-ietf-trill-o-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:54:24 -0000 --089e013c701a2e6f2504e7ed27ba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is for the information of the PWE3 WG, Yaakov had some comments on the trill list on this draft that you may find of interest. The discussion continues on the trill list. Cheers, Andy ---------- Forwarded message ---------- From: Yaakov Stein Date: Tue, Oct 1, 2013 at 10:57 AM Subject: WG LC on draft-ietf-trill-o-pw To: "trill@ietf.org" , Donald Eastlake Cc: "Stewart Bryant (stbryant)" , "Andrew G. Malis" < amalis@gmail.com> A request was made on the PWE3 list to look at this draft, and I volunteered to do so.**** ** ** Here are my comments:**** ** ** 1) The term trill over pseudowires is problematic. **** A PW is a tunneling mechanism, although over time it has become a full layer network.**** I would prefer =93trill pseudowire=94, but that would imply a new PW t= ype, which this draft does not propose (more on that below).**** So perhaps =93transport of TRILL using pseudowires=94 would be the mos= t appropriate.**** 2) In this context =85 and, assuming the pseudowires are over MPLS or IP [RFC4023 ], as label switched routers.**** Well, if over IP using 4023 the function is that of an IP router, not an LSR.**** 3) I find the parenthetical paragraph in section 2 somewhat strange =96 is this to be removed once the draft is agreed upon ?**** In any case, I disagree with the statement that an Ethernet PW would require an additional 12 or 16 bytes.**** If the TRILL packet is NOT an Ethernet packet, then an Ethernet PW is not appropriate at all.**** I think that you are actually referring to the generic =93packet pseudowire=94 encap which can carry anything,**** but does indeed require a pseudo-Ethernet header. If this is the intention, please restate as**** =93Although use of the packet pseudowire encapsulation of RFC 6658 would be possible, =85 =93**** 4) =93It would also be possible to specify a custom pseudowire type=85=94 *= *** It is not the custom in PWE3 to use the wording =93custom type=94. ***= * I believe that you simply mean a =93new=94 PW type (see next comment).= **** 5) =93the 3-bit Class of Service field=94. Sorry, but the name has been changed to the =93Traffic Class=94 field.**** 6) My main comment is regarding the use of the PPP encap.**** Yes, it is OK, but I really would prefer a new PW type. **** Yes that would require IANA updating the PW type registry, but we have only used up 32 out of 32K types**** so it is not that we need to conserve them. **** And 1024 are =93expert review=94, which don=92t even require this RFC to get an allocation!**** Why would such a definition be better ? There are at least 4 reasons:*= *** **A) **PW packets are not self describing, so packet dissectors (e.g., WireShark) need help in understanding them.**** This is normally done by looking at the PWE control protocol session.**** Obfuscating the intent here behind PW type 0x007 would thwart the possibility of properly parsing the packets,**** impacting debugging and other operational tasks.**** **B) **The TRILL PW requires special NSP functions to be performed, e.g., copying the priority into the TC field**** These functions are not required of standard PPP PWs, and should be linked to the TRILL case.**** **C) **I seem to recall that TRILL was working on its own OAM mechanism.*= *** Perhaps OAM interworking between this and the PW OAM is not yet of interest= ,**** but I can imagine it being desired. This would require knowing that we have a TRILL PW rather than just a PPP one.**** **D) **It would allow us to rename this encap as a =93TRILL pseudowire = =93.**** ** ** Thanks for making this draft concise!**** ** ** Y(J)S**** ** ** --089e013c701a2e6f2504e7ed27ba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
This is for the information of the PWE3 WG, Yaakov ha= d some comments on the trill list on this draft that you may find of intere= st. The discussion continues on the trill list.

Cheers,
And= y

---------- Forwarded message -----= -----
From: Yaakov Stein <yaakov_s@rad.com>
Date: Tue, Oct 1, 2013 at 10:57 AM
Subject: WG LC on draft-ietf-trill-o-= pw
To: "trill@ietf.org" = <trill@ietf.org>, Donald Eastla= ke <d3e3e3@gmail.com>
Cc: "Stewart Bryant (stbryant)" <stbryant@cisco.com>, "Andrew G. Malis" <amalis@gmail.com>


A request was made on the P= WE3 list to look at this draft, and I volunteered to do so.

=A0

Here are my comments:

=A0

1) The term trill over pseu= dowires is problematic.

=A0=A0=A0=A0=A0A PW is a tu= nneling mechanism, although over time it has become a full layer network.

=A0=A0=A0=A0 I would prefer= =93trill pseudowire=94, but that would imply a new PW type, which this dra= ft does not propose (more on that below).

=A0=A0=A0=A0 So perhaps =93= transport of TRILL using pseudowires=94 would be the most appropriate.

2) In this context =85 and, assuming the pseu=
dowires are over MPLS or IP [RFC4023], as label switched routers.<=
/pre>



=A0=A0 =A0Well, if over IP using 4023 the fun=
ction is that of an IP router, not an LSR.


3) I find the parenthetical paragraph in sect=
ion 2 somewhat strange =96 is this to be removed once the draft is agreed u=
pon ?




=A0=A0=A0 In any case, I disagree with the st=
atement that an Ethernet PW would require an additional 12 or 16 bytes.<=
/u>




=A0=A0=A0 If the TRILL packet is NOT an Ether=
net packet, then an Ethernet PW is not appropriate at all.




=A0=A0=A0 I think that you are actually refer=
ring to the generic =93packet pseudowire=94 encap which can carry anything,=





=A0=A0=A0 but does indeed require a pseudo-Et=
hernet header. If this is the intention, please restate as




=A0=A0=A0 =93Although use of the packet pseud=
owire encapsulation of RFC 6658 would be possible, =85 =93




4) =93It would also be possible to specify a =
custom pseudowire type=85=94 


=A0=A0=A0=A0=A0It is not the custom in PWE3 t=
o use the wording =93custom type=94. 


=A0=A0=A0=A0=A0I believe that you simply mean=
 a =93new=94 PW type (see next comment).


5) =93the 3-bit Class of Service field=94. So=
rry, but the name has been changed to the =93Traffic Class=94 field.=





6) My main comment is regarding the use of th=
e PPP encap.


=A0=A0=A0=A0 Yes, it is OK, but I really woul=
d prefer a new PW type. 


=A0=A0=A0=A0=A0Yes that would require IANA up=
dating the PW type registry, but we have only used up 32 out of 32K types




=A0=A0=A0=A0 so it is not that we need to con=
serve them. 


=A0=A0=A0=A0=A0And 1024 are =93expert review=
=94, which don=92t even require this RFC to get an allocation!




=A0=A0=A0=A0 Why would such a definition be b=
etter ? There are at least 4 reasons:


A)<=
span style=3D"font:7.0pt "Times New Roman"">=A0=A0 =
PW packets =
are not self describing, so packet dissectors (e.g., WireShark) need help i=
n understanding them.




This is normally=
 done by looking at the PWE control protocol session.<=
/pre>



Obfuscating the =
intent here behind PW type 0x007 would thwart the possibility of properly p=
arsing the packets,




impacting debugg=
ing and other operational tasks.


B)<=
span style=3D"font:7.0pt "Times New Roman"">=A0=A0 =
The TRILL P=
W requires special NSP functions to be performed, e.g., copying the priorit=
y into the TC field




These functions =
are not required of standard PPP PWs, and should be linked to the TRILL cas=
e.




C)<=
span style=3D"font:7.0pt "Times New Roman"">=A0=A0 =
I seem to r=
ecall that TRILL was working on its own OAM mechanism.=





Perhaps OAM inte=
rworking between this and the PW OAM is not yet of interest,<=
/span>




but I can imagin=
e it being desired. This would require knowing that we have a TRILL PW rath=
er than just a PPP one.




D)<=
span style=3D"font:7.0pt "Times New Roman"">=A0=A0 =
It would al=
low us to rename this encap as a =93TRILL pseudowire =93.




=A0


Thanks for making this draft concise!<=
u>


=A0


Y(J)S<=
/p>

=A0

--089e013c701a2e6f2504e7ed27ba-- From agmalis@gmail.com Sat Oct 5 05:15:08 2013 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 BE3E321F9AA8 for ; Sat, 5 Oct 2013 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 35CmBmdT5OrJ for ; Sat, 5 Oct 2013 05:15:07 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2B421F9B0D for ; Sat, 5 Oct 2013 05:15:02 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so5321003wgh.27 for ; Sat, 05 Oct 2013 05:15:02 -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=qBmfk5vtWYKilrkclxkrj2awcTm2b6rJbUQVmceo9Fg=; b=oj0APKWZoLcfBp+lSiOriU9/V92JMt1eqeaAlW6lQ/jQZ3F/9YBgF79UQWpl4FLFA+ ZEr09wnb+45d54D24J3qSRqvj6lpBQ6H/d7NHg9EpjxWYXCa0f34Z2Ig0n1lTP+wymTn YkyHLkpVyMf71iYv5XBJR6+YcGWn+EkaJp8ZPfM8XiI4dx4tPCX7irNPRDauJam4dAf4 WMTPTNBaYGAXJGgCuHtjjWAzgmCRyqIZ779sYb2ai+De2YhtSXacK7dARlx5BqtaWN04 NVULpqKM3j9iG9aZEiKqan+VZ6lM++EMIy9t/gNf7STGnFjCebOG5/ZxQmNt/bSFpAeB fqww== X-Received: by 10.180.84.70 with SMTP id w6mr11535133wiy.2.1380975302270; Sat, 05 Oct 2013 05:15:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.54.6 with HTTP; Sat, 5 Oct 2013 05:14:42 -0700 (PDT) In-Reply-To: <20131004225346.32223.38527.idtracker@ietfa.amsl.com> References: <20131004225346.32223.38527.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Sat, 5 Oct 2013 08:14:42 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [PWE3] Fwd: IETF 88 Preliminary Agenda 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, 05 Oct 2013 12:15:08 -0000 PWEers, Here's the current IETF agenda. Note that we have a one hour slot this time. Be sure to get your presentation requests to Dave ASAP. Cheers, Andy ---------- Forwarded message ---------- From: IETF Agenda Date: Fri, Oct 4, 2013 at 6:53 PM Subject: IETF 88 Preliminary Agenda To: IETF Announcement List Cc: ietf@ietf.org The IETF 88 Preliminary Agenda has been posted. The final agenda will be published on Friday, October 11th. https://datatracker.ietf.org/meeting/88/agenda.html https://datatracker.ietf.org/meeting/88/agenda.txt We are still having some difficulty integrating the new agenda tool into the datatracker and as a result some portions of the meeting agenda -- beverage and snack breaks, plenaries -- are not yet showing up on the html version. This will hopefully be resolved very soon. More information regarding IETF 88 in Vancouver, BC, Canada is located here: https://www.ietf.org/meeting/88/index.html IETF Secretariat From internet-drafts@ietf.org Mon Oct 7 06:40:37 2013 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 CB0BC21F9E33; Mon, 7 Oct 2013 06:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, 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 wIoNJRm+6Nha; Mon, 7 Oct 2013 06:40:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4C321F9FAE; Mon, 7 Oct 2013 06:40:37 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007134036.16131.18424.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 06:40:36 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-dynamic-ms-pw-18.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:40:37 -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 Working= Group of the IETF. Title : Dynamic Placement of Multi-Segment Pseudowires Author(s) : Luca Martini Matthew Bocci Florin Balus Filename : draft-ietf-pwe3-dynamic-ms-pw-18.txt Pages : 22 Date : 2013-10-07 Abstract: There is a requirement for service providers to be able to extend the reach of pseudowires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates the length value of the PW Switching Point PE Sub-TLV Type 0x06 to 14. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-dynamic-ms-pw-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Oct 9 03:18:48 2013 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 D477911E8163; Wed, 9 Oct 2013 03:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 RtfnvgA7lO6s; Wed, 9 Oct 2013 03:18:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 442B511E8118; Wed, 9 Oct 2013 03:18:43 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009101843.11449.31327.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 03:18:43 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-dynamic-ms-pw-19.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 10:18:49 -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 Working= Group of the IETF. Title : Dynamic Placement of Multi-Segment Pseudowires Author(s) : Luca Martini Matthew Bocci Florin Balus Filename : draft-ietf-pwe3-dynamic-ms-pw-19.txt Pages : 22 Date : 2013-10-09 Abstract: There is a requirement for service providers to be able to extend the reach of pseudowires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC6073 as follows: it updates the length value of the PW Switching Point PE Sub-TLV Type 0x06 to 14. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-dynamic-ms-pw-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Wed Oct 9 09:19:40 2013 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 BBFDF11E8192; Wed, 9 Oct 2013 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 QGfeHAdrgLcU; Wed, 9 Oct 2013 09:19:40 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1623211E816E; Wed, 9 Oct 2013 09:19:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 96B4EB1E014; Wed, 9 Oct 2013 09:11:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131009161155.96B4EB1E014@rfc-editor.org> Date: Wed, 9 Oct 2013 09:11:55 -0700 (PDT) Cc: drafts-update-ref@iana.org, pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 7023 on MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:19:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7023 Title: MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking Author: D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu Status: Standards Track Stream: IETF Date: October 2013 Mailbox: dinmohan@hotmail.com, nabil.n.bitar@verizon.com, sajassi@cisco.com, simon.delord@gmail.com, philippe.niger@orange.com, rqiu@juniper.net Pages: 23 Characters: 47621 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-mpls-eth-oam-iwk-08.txt URL: http://www.rfc-editor.org/rfc/rfc7023.txt This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (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 Pseudowire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard. 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/search/rfc_search.php 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 iesg-secretary@ietf.org Mon Oct 14 13:12:07 2013 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 6481321E8105; Mon, 14 Oct 2013 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, 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 ksCAlOB935TZ; Mon, 14 Oct 2013 13:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 595D721E8119; Mon, 14 Oct 2013 13:12:03 -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.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014201203.11479.96146.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 13:12:03 -0700 Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Document Action: 'The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results' to Informational RFC (draft-ietf-pwe3-vccv-impl-survey-results-03.txt) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 20:12:07 -0000 The IESG has approved the following document: - 'The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results' (draft-ietf-pwe3-vccv-impl-survey-results-03.txt) as Informational RFC 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-vccv-impl-survey-results/ Technical Summary The IETF PWE3 Working Group has defined many encapsulations of various layer 1 and layer 2 service-specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the PW/VCCV user community was conducted to determine implementation trends and the possibility of always mandating the Control Word. Working Group Summary RFC5085 defines 3 VCCV channel types. These 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 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 interoperability issues between vendors. As a first step to rationalising the number of modes, the WG conducted a survey to try to quantify which modes are in use today and so determine which ones could be either deprecated, or made optional in a possible 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 Informational RFC. Note that the draft spent an extended amount of time in AD review while additional editorial help was sought to address the comments from the AD. During this period the draft went dormant. Additional editorial help was eventually found, and the draft progressed as it was felt that the survey results contained therein were still relevant. The WG has also been using these results as a basis for on-going work, and it was felt that a permanent record of the results is desirable. Note that the name of the document that was originally last called by the WG was draft-ietf-pwe3-pw-vccv-impl-survey-results, but this was updated to draft-ietf-pwe3-vccv-impl-survey-results as a result of a comment from the WG. Document Quality The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci. The responsible Area Director is Stewart Bryant. From internet-drafts@ietf.org Tue Oct 15 10:32:51 2013 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 4B01611E815A; Tue, 15 Oct 2013 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 x+Bt1Jxsu8pS; Tue, 15 Oct 2013 10:32:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B54C311E81E4; Tue, 15 Oct 2013 10:32:49 -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.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015173249.2154.1459.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 10:32:49 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-rfc4447bis-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:32:51 -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 Working= Group of the IETF. Title : Pseudowire Setup and Maintenance using the Label Distrib= ution Protocol Author(s) : Luca Martini Giles Heron Filename : draft-ietf-pwe3-rfc4447bis-02.txt Pages : 34 Date : 2013-10-15 Abstract: Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and then transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-rfc4447bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-rfc4447bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-rfc4447bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=7001c78048=hshah@ciena.com Tue Oct 15 17:19:44 2013 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 AB80311E80FB for ; Tue, 15 Oct 2013 17:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 DRK7lVOFzvz7 for ; Tue, 15 Oct 2013 17:19:40 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id B7E0B11E81B0 for ; Tue, 15 Oct 2013 17:19:36 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by m0002317.ppops.net (8.14.5/8.14.5) with SMTP id r9G0DmoW031575; Tue, 15 Oct 2013 17:19:33 -0700 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 1fhbjcs54e-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Oct 2013 17:19:33 -0700 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 15 Oct 2013 20:20:32 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Tue, 15 Oct 2013 20:19:31 -0400 From: "Shah, Himanshu" To: David Sinicrope , "IETF.PWE3" Date: Tue, 15 Oct 2013 20:19:29 -0400 Thread-Topic: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver Thread-Index: Ac62E+PGsqUK0Mm2SNGh7a2c6b/RugT8Istw Message-ID: <40746B2300A8FC4AB04EE722A593182B67865E6C@ONWVEXCHMB04.ciena.com> References: <871EB8879748FA458598F046190628930F2A2A@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20222.003 X-TM-AS-Result: No--21.066100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182B67865E6CONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-15_08:2013-10-15, 2013-10-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310150129 Subject: Re: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:19:44 -0000 --_000_40746B2300A8FC4AB04EE722A593182B67865E6CONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2ZSwNCg0KSSBoYWQgbGlrZSB0byByZXNlcnZlIGEgMTBtaW4gc2xvdCB0byBkaXNjdXNz IE1BQyBXRCBzaWduYWxpbmcgb3ZlciBzdGF0aWMgUFcgZHJhZnQuIChodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1ib3V0cm9zLWwydnBuLW1wbHMtdHAtbWFjLXdkLTAyKQ0KV2UgYXJl IGluY3JlYXNpbmdseSBmaW5kaW5nIGRlcGxveW1lbnRzIG9mIHN0YXRpYyBNUExTIFRQIFBXcywg ZXNwZWNpYWxseSBpbiBNVFUtcyB0aGF0IGlzIGR1YWwtaG9tZWQgaW4gSFZQTFMgY29uZmlndXJh dGlvbnMuDQpTZW5kaW5nIE1BQyB3aXRoZHJhdyBvdmVyIHN0YXRpYyBQVyBoYXMgYmVjb21lIGEg a2V5IHJlcXVpcmVtZW50Lg0KDQpQcmVzZW50ZXIg4oCTIEhpbWFuc2h1IFNoYWgNCg0KVGhhbmtz LA0KaGltYW5zaHUNCg0KDQoNCg0KRnJvbTogcHdlMy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgU2luaWNyb3BlDQpTZW50 OiBGcmlkYXksIFNlcHRlbWJlciAyMCwgMjAxMyA4OjEzIEFNDQpUbzogSUVURi5QV0UzDQpTdWJq ZWN0OiBbUFdFM10gUFdFMyBJRVRGIDg4IFNsb3QgUmVxdWVzdHMgLSBWYW5jb3V2ZXINCg0KSGkg QWxsLA0KSXQncyB0aGF0IHRpbWUgYWdhaW4uDQoNCklmIHlvdSBuZWVkIGEgcHJlc2VudGF0aW9u IHNsb3QgZm9yIHRoZSBJRVRGIDg4IFBXRTMgc2Vzc2lvbiwgcGxlYXNlIHJlcGx5IHRvIHRoaXMg ZW1haWwgKHN1YmplY3QgaW50YWN0KSBjb21wbGV0aW5nIHRoZSBmb3JtIGJlbG93Og0KDQotIHRv cGljIChlLmcuLCBNUExTIGFuZCBFdGhlcm5ldCBPQU0gSW50ZXJ3b3JraW5nKToNCi0gZHJhZnQg VVJMIChlLmcuLCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcHdl My1tcGxzLWV0aC1vYW0taXdrLyk6DQotIGJyaWVmIHN0YXRlbWVudCBvZiBvYmplY3RpdmVzIGFu ZCBpc3N1ZXMgdGhhdCBuZWVkIHRvIGJlIGRpc2N1c3NlZCBhbmQgcmVzb2x2ZWQgdmlhIHRoZSBw cmVzZW50YXRpb24gKGUuZy4sIG5lZWQgdG8gYWRkcmVzcyBzZWN1cml0eSBpc3N1ZXMgYW5kIGdl dCBkaXJlY3Rpb24gZnJvbSB0aGUgV0cpOg0KLSByZXF1ZXN0ZWQgZHVyYXRpb24gKG5vcm0gaXMg MTAgbWluKToNCi0gc3BlYWtlciBuYW1lIChlLmcuLCBHaXZlbi1uYW1lIEZBTUlMWS1OQU1FKToN Cg0KVGhhbmtzIQ0KRGF2ZQ0K --_000_40746B2300A8FC4AB04EE722A593182B67865E6CONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u YXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiMwMDAwQ0M7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjojMDAwMENDJz5IaSBEYXZlLDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAw Q0MnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxp PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2Vy aWYiO2NvbG9yOiMwMDAwQ0MnPkkgaGFkIGxpa2UgdG8gcmVzZXJ2ZSBhIDEwbWluIHNsb3QgdG8g ZGlzY3VzcyBNQUMgV0Qgc2lnbmFsaW5nIG92ZXIgc3RhdGljIFBXIGRyYWZ0LiAoaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91dHJvcy1sMnZwbi1tcGxzLXRwLW1hYy13ZC0wMik8 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjoj MDAwMENDJz5XZSBhcmUgaW5jcmVhc2luZ2x5IGZpbmRpbmcgZGVwbG95bWVudHMgb2Ygc3RhdGlj IE1QTFMgVFAgUFdzLCBlc3BlY2lhbGx5IGluIE1UVS1zIHRoYXQgaXMgZHVhbC1ob21lZCBpbiBI VlBMUyBjb25maWd1cmF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Ft YnJpYSIsInNlcmlmIjtjb2xvcjojMDAwMENDJz5TZW5kaW5nIE1BQyB3aXRoZHJhdyBvdmVyIHN0 YXRpYyBQVyBoYXMgYmVjb21lIGEga2V5IHJlcXVpcmVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAwQ0MnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAw Q0MnPlByZXNlbnRlciDigJMgSGltYW5zaHUgU2hhaDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAwQ0MnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAwQ0MnPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtj b2xvcjojMDAwMENDJz5oaW1hbnNodTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAwQ0MnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAwQ0MnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDAw Q0MnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxp PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2Vy aWYiO2NvbG9yOiMwMDAwQ0MnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+PGRpdj48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnB3ZTMt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5EYXZpZCBTaW5pY3JvcGU8YnI+ PGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDIwLCAyMDEzIDg6MTMgQU08YnI+PGI+VG86 PC9iPiBJRVRGLlBXRTM8YnI+PGI+U3ViamVjdDo8L2I+IFtQV0UzXSBQV0UzIElFVEYgODggU2xv dCBSZXF1ZXN0cyAtIFZhbmNvdXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48YmxvY2txdW90ZSBz dHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5IaSBBbGwsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+SXQncyB0aGF0IHRpbWUgYWdhaW4uICZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+SWYgeW91IG5lZWQgYSBwcmVzZW50YXRpb24gc2xvdCBmb3IgdGhlIElF VEYgODggUFdFMyBzZXNzaW9uLCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCAoc3ViamVjdCBp bnRhY3QpIGNvbXBsZXRpbmcgdGhlIGZvcm0gYmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjEx LjI1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz4tIHRvcGljIChlLmcuLCZuYnNwOzxzcGFuIGNsYXNzPWFwcGxlLXN0eWxl LXNwYW4+TVBMUyBhbmQgRXRoZXJuZXQgT0FNIEludGVyd29ya2luZyk6PG86cD48L286cD48L3Nw YW4+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+LSBkcmFm dCBVUkwgKGUuZy4sJm5ic3A7PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXB3ZTMtbXBscy1ldGgtb2FtLWl3ay8iPmh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wd2UzLW1wbHMtZXRoLW9hbS1pd2svPC9hPik6ICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+LSBicmllZiBzdGF0ZW1lbnQgb2Ygb2JqZWN0aXZlcyBhbmQgaXNzdWVzIHRoYXQgbmVlZCB0 byBiZSBkaXNjdXNzZWQgYW5kIHJlc29sdmVkIHZpYSB0aGUgcHJlc2VudGF0aW9uIChlLmcuLCBu ZWVkIHRvIGFkZHJlc3Mgc2VjdXJpdHkgaXNzdWVzIGFuZCBnZXQgZGlyZWN0aW9uIGZyb20gdGhl IFdHKTogJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz4tIHJlcXVlc3RlZCBkdXJhdGlvbiAobm9ybSBpcyAxMCBtaW4pOiAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPi0gc3BlYWtlciBuYW1lIChlLmcuLCBHaXZlbi1uYW1lIEZBTUlMWS1OQU1FKTogJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_40746B2300A8FC4AB04EE722A593182B67865E6CONWVEXCHMB04cie_-- From david.sinicrope@ericsson.com Sun Oct 20 18:42:46 2013 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 E108111E8315 for ; Sun, 20 Oct 2013 18:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70-XBvUkxM3H for ; Sun, 20 Oct 2013 18:42:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 53B2D11E8101 for ; Sun, 20 Oct 2013 18:42:41 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-58-52648690d320 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 68.CB.03458.09684625; Mon, 21 Oct 2013 03:42:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 21:42:40 -0400 From: David Sinicrope To: IETF.PWE3 Thread-Topic: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver Thread-Index: AQHOzf7TuALn6SiP20+9OkbOSNfPHg== Date: Mon, 21 Oct 2013 01:42:38 +0000 Message-ID: <871EB8879748FA458598F046190628931C2B5DA1@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F046190628931C2B5DA1eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXRPlO6EtpQggw27zC36Pm1hcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp+v21gLdqpW3Hm4i7mB8ahCFyMnh4SAicSpzs3sELaYxIV7 69m6GLk4hASOMkr8WryLCSQhJLCcUeLlPX8Qmw2oYd3GPSwgtoiArMTr6/fYQGxhASuJVatn s0HErSVOr3rBDmHrSbTvOA4WZxFQlWhYvQ6sl1fAV2LP3HZWEJtTwFbi5MS/YLsYgY74fmoN mM0sIC5x68l8JojjBCSW7DnPDGGLSrx8/A+sVxRo/vr23VA1yhLf5zxigejNl1j+YzIbxC5B iZMzn7BMYBSZhWTsLCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMVSvtcSEf81MyGoWMHKs YuQoLU4ty003MtzECIygYxJsjjsYF3yyPMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbG3ssxohrs3v+4HkjfyWy4de1tzkVxJt2unCajs00PVVY91QrurPhgJhGtHfc0 5Jh4nNFEUblzy9wMNx2xiZopvCTRnDMngaeoaNnJezL/zJzjXAJ2h37NleN52pv3o9YmuW57 tY771G0llZXFy1i+iS7nEDXw7qzq0buVVD4ry/X8spi800osxRmJhlrMRcWJANoYJGluAgAA Subject: Re: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver 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, 21 Oct 2013 01:42:47 -0000 --_000_871EB8879748FA458598F046190628931C2B5DA1eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This is a reminder. I've received only one request to date. If you would like a slot, please follow the instructions below. As Andy noted earlier, please keep in mind we only have 1 hr. Thanks, Dave From: David A Sinicrope > Date: Friday, September 20, 2013 11:12 AM To: "IETF.PWE3" > Subject: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver Hi All, It's that time again. If you need a presentation slot for the IETF 88 PWE3 session, please reply = to this email (subject intact) completing the form below: - topic (e.g., MPLS and Ethernet OAM Interworking): - draft URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth= -oam-iwk/): - brief statement of objectives and issues that need to be discussed and re= solved via the presentation (e.g., need to address security issues and get = direction from the WG): - requested duration (norm is 10 min): - speaker name (e.g., Given-name FAMILY-NAME): Thanks! Dave --_000_871EB8879748FA458598F046190628931C2B5DA1eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi All,
This is a reminder. I've received only one request to date.
If you would like a slot, please follow the instructions below.
As Andy noted earlier, please keep in mind we only have 1 hr.
Thanks,
Dave

From: David A Sinicrope <david.sinicrope@gmail.com>
Date: Friday, September 20, 2013 11= :12 AM
To: "IETF.PWE3" <pwe3@ietf.org>
Subject: [PWE3] PWE3 IETF 88 Slot R= equests - Vancouver

Hi All,
It's that time again.  

If you need a presentation slot for the IE= TF 88 PWE3 session, please reply to this email (subject intact) completing = the form below:

- topic (e.g., MPLS and Ethernet OAM Interworking):
- brief statement of objectives and issues that need to be discussed a= nd resolved via the presentation (e.g., need to address security issues and= get direction from the WG):  
- requested duration (norm is 10 min):  
- speaker name (e.g., Given-name FAMILY-NAME):  

Thanks!
Dave
 --_000_871EB8879748FA458598F046190628931C2B5DA1eusaamb103erics_-- From internet-drafts@ietf.org Sun Oct 20 21:33:36 2013 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 ACA9011E8424; Sun, 20 Oct 2013 21:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 WXPVwDCWOiIv; Sun, 20 Oct 2013 21:33:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F511E8147; Sun, 20 Oct 2013 21:33:36 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021043336.22818.13700.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:33:36 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-status-reduction-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 04:33:36 -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 Working= Group of the IETF. Title : MPLS LSP PW status refresh reduction for Static Pseudowi= res Author(s) : Luca Martini George Swallow Elisa Bellagamba Filename : draft-ietf-pwe3-status-reduction-02.txt Pages : 17 Date : 2013-10-20 Abstract: This document describes a method for generating an aggregated pseudowire status message on Multi-Protocol Label Switching (MPLS) network Label Switched Path (LSP). The method for transmitting the pseudowire (PW) status information is not new, however this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network of multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-status-reduction There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-status-reduction-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-status-reduction-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Oct 20 21:54:07 2013 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 1ED7C11E8140; Sun, 20 Oct 2013 21:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 rVKt3GpWHOsf; Sun, 20 Oct 2013 21:54:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1111E8155; Sun, 20 Oct 2013 21:54:05 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021045404.8729.91870.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:54:04 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-iccp-12.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 04:54:07 -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 Working= Group of the IETF. Title : Inter-Chassis Communication Protocol for L2VPN PE Redund= ancy Author(s) : Luca Martini Samer Salam Ali Sajassi Satoru Matsushima Filename : draft-ietf-pwe3-iccp-12.txt Pages : 79 Date : 2013-10-20 Abstract: This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-iccp-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-iccp-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 07:19:00 2013 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 D77A311E857F; Mon, 21 Oct 2013 07:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 LJjIMhJUIqh4; Mon, 21 Oct 2013 07:18:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E593511E8579; Mon, 21 Oct 2013 07:18:49 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021141849.29534.43512.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 07:18:49 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-p2mp-pw-requirements-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:19:00 -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 Working= Group of the IETF. Title : Requirements and Framework for Point-to-Multipoint Pseud= owires over MPLS PSNs Author(s) : Frederic Jounay Yuji Kamite Giles Heron Matthew Bocci Filename : draft-ietf-pwe3-p2mp-pw-requirements-06.txt Pages : 16 Date : 2013-10-21 Abstract: This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to- Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service) as defined in the Layer 2 Virtual Private Network Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-p2mp-pw-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-p2mp-pw-requirements-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.sinicrope@ericsson.com Tue Oct 22 12:17:25 2013 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 B2FA111E823C for ; Tue, 22 Oct 2013 12:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3i4t3Nn03ny for ; Tue, 22 Oct 2013 12:17:02 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 28C0F21F9D23 for ; Tue, 22 Oct 2013 12:16:22 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-76-5266cf05cdff Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8C.8B.03458.50FC6625; Tue, 22 Oct 2013 21:16:21 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 15:16:18 -0400 From: David Sinicrope To: IETF.PWE3 Thread-Topic: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver Thread-Index: AQHOzf7TuALn6SiP20+9OkbOSNfPHpoBGl4A Date: Tue, 22 Oct 2013 19:16:17 +0000 Message-ID: <871EB8879748FA458598F046190628931C2BF043@eusaamb103.ericsson.se> In-Reply-To: <871EB8879748FA458598F046190628931C2B5DA1@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F046190628931C2BF043eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPuC7r+bQgg639qhZ9n7awODB6LFny kymAMYrLJiU1J7MstUjfLoErY8GthewF0xwr7tzQbmA8b9HFyMkhIWAisavjCCuELSZx4d56 ti5GLg4hgaOMEmeOL2OHcJYzSuxcsZYJpIoNqGPdxj0sILaIgKzE6+v32EBsZgEjiWOP5zOC 2MICVhKrVs9mg6ixlji96gU7hG0kMaH9MZjNIqAqsW3VbmYQm1fAV+LeiZ9gNqeAn8TDr//B 5jMCXfT91BomiPniEreezGeCuFRAYsme88wQtqjEy8f/wD4QFdCTWN++G6pGWeL7nEcsEL35 El9u72KB2CUocXLmE5YJjKKzkIydhaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48huq1llja 3sGIrGYBI8cqRo7S4tSy3HQjw02MwMg6JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamCs+Pi24mKvyAFbHU3DAm3Fa/0tP3jS19/UOq74q7CtkH/6tKte P5UVi3ZoWriFndMUEFnm/PvFFWfHqbuWPytLn2nRdEGoq7ysebrU1veLSpkvivAv/L4rt7Zi QuIMVSblq1wRUxcvOt9/dauXZNT241v1Lt89EtjnUaGy5IiKl6iFu9SBKUuUWIozEg21mIuK EwGs0l/segIAAA== Subject: Re: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 19:17:25 -0000 --_000_871EB8879748FA458598F046190628931C2BF043eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, http://www.ietf.org/proceedings/88/agenda/agenda-88-pwe3 Contains the agenda for Vancouver as it stands today. If you need a slot, = please provide the information below. - topic (e.g., MPLS and Ethernet OAM Interworking): - draft URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth= -oam-iwk/): - brief statement of objectives and issues that need to be discussed and re= solved via the presentation (e.g., need to address security issues and get = direction from the WG): - requested duration (norm is 10 min): - speaker name (e.g., Given-name FAMILY-NAME): Those who have slots, please send your slides to me no later than 5pm Vanco= uver time Monday 11/4/2013. As always, sooner is better. Thanks, Dave From: David A Sinicrope > Date: Sunday, October 20, 2013 9:42 PM To: "IETF.PWE3" > Subject: Re: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver Hi All, This is a reminder. I've received only one request to date. If you would like a slot, please follow the instructions below. As Andy noted earlier, please keep in mind we only have 1 hr. Thanks, Dave From: David A Sinicrope > Date: Friday, September 20, 2013 11:12 AM To: "IETF.PWE3" > Subject: [PWE3] PWE3 IETF 88 Slot Requests - Vancouver Hi All, It's that time again. If you need a presentation slot for the IETF 88 PWE3 session, please reply = to this email (subject intact) completing the form below: - topic (e.g., MPLS and Ethernet OAM Interworking): - draft URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth= -oam-iwk/): - brief statement of objectives and issues that need to be discussed and re= solved via the presentation (e.g., need to address security issues and get = direction from the WG): - requested duration (norm is 10 min): - speaker name (e.g., Given-name FAMILY-NAME): Thanks! Dave --_000_871EB8879748FA458598F046190628931C2BF043eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <9E5E748B235E4343992212BB63666F58@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi All,

Contains the agenda for Vancouver as it stands today.  If you nee= d a slot, please provide the information below.
- topic (e.g., MPLS and Ethernet OAM Interworking):
- brief statement of objectives and issues that need to be discussed a= nd resolved via the presentation (e.g., need to address security issues and= get direction from the WG):  
- requested duration (norm is 10 min):  
- speaker name (e.g., Given-name FAMILY-NAME):  
Those who have slots, please send your slides to me no later than 5pm = Vancouver time Monday 11/4/2013.  As always, sooner is better.

Thanks,
Dave



From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Sunday, October 20, 2013 9:42= PM
To: "IETF.PWE3" <pwe3@ietf.org>
Subject: Re: [PWE3] PWE3 IETF 88 Sl= ot Requests - Vancouver

Hi All,
This is a reminder. I've received only one request to date.
If you would like a slot, please follow the instructions below.
As Andy noted earlier, please keep in mind we only have 1 hr.
Thanks,
Dave

From: David A Sinicrope <david.sinicrope@gmail.com>
Date: Friday, September 20, 2013 11= :12 AM
To: "IETF.PWE3" <pwe3@ietf.org>
Subject: [PWE3] PWE3 IETF 88 Slot R= equests - Vancouver

Hi All,
It's that time again.  

If you need a presentation slot for the IE= TF 88 PWE3 session, please reply to this email (subject intact) completing = the form below:

- topic (e.g., MPLS and Ethernet OAM Interworking):
- brief statement of objectives and issues that need to be discussed a= nd resolved via the presentation (e.g., need to address security issues and= get direction from the WG):  
- requested duration (norm is 10 min):  
- speaker name (e.g., Given-name FAMILY-NAME):  

Thanks!
Dave
--_000_871EB8879748FA458598F046190628931C2BF043eusaamb103erics_-- From amalis@gmail.com Tue Oct 22 13:32:12 2013 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 C029F11E81F8 for ; Tue, 22 Oct 2013 13:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 VRox2iyGD2Ce for ; Tue, 22 Oct 2013 13:32:10 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2494811E822E for ; Tue, 22 Oct 2013 13:32:08 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j10so7137504oah.36 for ; Tue, 22 Oct 2013 13:32:07 -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:cc:content-type; bh=zZt1rpYbPnkfpfIIJ8nfekCI32Z/qavhQ4OPTzFR2r0=; b=qOOSzAUxIZ/SIV9xGeNoiC9w1o2MMVO2KEtbvPDArDhEGfEKeJJCMUlBZ4CWvWBy28 w3aL6Lao/wANZXmiwAd8+NXUc5MsOSkrSkceR+KE25yuu5QRKFmn77pt6g5s+McF6fm9 BUJEcikiP+Jfb7LIGhhCM8vvHGs76dUJyQC7OhRSz0IRrXnho8/KHShAd4M8KNO5Sr/T zr6hEFVN65Fx5tYLC33j/jRcziNF1/+B7mODLHEMaWuVvd8oS/OiBXoZ6Cnu8VkPvQUL gGdtzkOQ4jf4sMoV/UEdaxo6/fkt38yyhA6ozDWQJq1Nxb52TiZ61PsThflI7K5uLUbe KvuA== X-Received: by 10.182.106.4 with SMTP id gq4mr27260488obb.4.1382473927587; Tue, 22 Oct 2013 13:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.182.9 with HTTP; Tue, 22 Oct 2013 13:31:47 -0700 (PDT) From: "Andrew G. Malis" Date: Tue, 22 Oct 2013 16:31:47 -0400 Message-ID: To: Gregory Mirsky Content-Type: multipart/alternative; boundary=e89a8fb1fa625d7c3804e95a4b76 Cc: "pwe3@ietf.org" Subject: [PWE3] Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:32:13 -0000 --e89a8fb1fa625d7c3804e95a4b76 Content-Type: text/plain; charset=ISO-8859-1 Greg, As document shepherd for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last call review and have some comments. The good news is that the draft is mostly in good shape for publication, it just needs a quick revision to address the comments below. Also, there were no other WG last call comments which need to be addressed. First of all, there are some idnits issues that need to be addressed: Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 20, 2013) is 32 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5882' is defined on line 270, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) I also have some comments of my own, which are mostly editorial in nature. They are embedded in the text below. Just do an update to address the nits and these comments, and I'll be able to forward the draft for publication. Thanks, Andy ------------ 1. Introduction Proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) for the MPLS Transport Profile [RFC6428] are applicable to all constructs of the MPLS-TP, including pseudowires (PWs). If Control Plane is used to operate and manage PW s/Control Plane/a control plane/ s/PW/PWs/ then procedure defined in [RFC5085] and [RFC5885] should be used to s/procedure/the procedures/ select proper type of Control Channel and corresponding type of Connectivity Verification. This document specifies how signaling and selection process modified to ensure backward compatibility and allow s/process modified/processes are modified/ use of proactive CV-CC-RDI over MPLS-TP PWs. 1.1. Conventions used in this document 1.1.1. Terminology BFD: Bidirectional Forwarding Detection CC: Continuity Check CV: Connectivity Verification PE: Provider Edge VCCV: Virtual Circuit Connectivity Verification VCCV CC: VCCV Control Channel 1.1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. MPLS-TP CC-CV on Pseudowires PW VCCV can support several CV Types. Ability to support arbitrary s/Types. Ability to support/Types, and can support/ combination of CV modes advertised in CV Types field of VCCV s/in CV/in the CV/ Interface Parameter sub-TLV [RFC4446], [RFC4447]. Currently six types of CV been defined for PW VCCV out of eight bit long field. s/VCCV out of eight bit long field/VCCV/ This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined. Mirsky Expires March 24, 2014 [Page 3] Internet-Draft VCCV MPLS-TP CV September 2013 2.1. VCCV Extended CV Advertisement sub-TLV The format of VCCV Extended CV Advertisement is a TLV where: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x19 | Length | CV Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: VCCV Extended CV parameter format Length - the length of the sub-TLV, including type and the Length s/Length -/The Length field is/ field itself. Minimum length is 4. It it isrecommended that s/Minimum/The minimum/ extensions to the sub-TLV be done in 4 bytes increments with Reserved field being set to zero on transmit and ignored on receipt. Reserved field must be set to zeroes on transmit and ignored on receive. s/Reserved/The Reserved/ CV Type field is a bitmask that lists types of CV monitoring that a s/CV Type/The CV Type/ PE is capable to support. VCCV Extended CV parameter sub-TLV must s/VCCV/The VCCV/ appear in combination with VCCV parameter sub-TLV. If VCCV parameter s/VCCV/the VCCV/ (twice in this line) sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be s/VCCV/the VCCV/ ignored. 2.2. MPLS-TP CC-CV Types The [RFC6428] defines coordinated and independent modes of monitoring S/The // point-to-point bi-directional connection that can be applied to monitoring PWs. At the same time [RFC6310] defines how BFD-based OAM can map and be mapped to status of an Attachment Circuit. Thus there could be four MPLS-TP CV types as combination of modes and functionality: +---------------+-------------------+-------------------------------+ | Modes | Fault Detection | Fault Detection and Status | | | Only | Signalling | +---------------+-------------------+-------------------------------+ | Independent | 0x01 | 0x02 | | Mode | | | | Coordinated | 0x04 | 0x08 | | Mode | | | +---------------+-------------------+-------------------------------+ Table 1: Bitmask Values for MPLS-TP CV Types Mirsky Expires March 24, 2014 [Page 4] Internet-Draft VCCV MPLS-TP CV September 2013 2.3. MPLS-TP CC-CV Type Operation Connectivity verification according to [RFC6428] is part of MPLS-TP CC/CV operation that can be used with VCCV Control Channel Type 1 [RFC5085] . If VCCV CC Type 1 selected, then PEs might select one of MPLS-TP CC-CV types as VCCV CV mechanism to be used for this PW. 2.4. CV Type Selection CV selection rules that have been defined in Section 7 of [RFC5085] and updated Section 4 of [RFC5885] are augmented in this document. If VCCV Control Channel Type 1 is chosen according to Section 7 [RFC5085] and common set of proactive CV types advertized by both PEs includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP CC-CV takes precedence over any type of BFD CV. If multiple MPLS-TP CV types advertised by both PEs, then following list sorted in descending priority order is used: 1. 0x08 - coordinated mode for PW Fault Detection and AC/PW Fault Status Signaling 2. 0x04 - coordinated mode for PW Fault Detection only 3. 0x02 - independent mode for PW Fault Detection and AC/PW Fault Status Signaling 4. 0x01 - independent mode for PW Fault Detection only 3. IANA Considerations The PW Interface Parameters Sub-TLV registry defined in [RFC4446]. s/registry defined/registry is defined/ IANA is requested to reserve a new PW Interface Parameters Sub-TLV type as follows: +-------------+--------+----------------------------+---------------+ | Parameter | Length | Description | Reference | | ID | | | | +-------------+--------+----------------------------+---------------+ | 0x19 | 4 | VCCV Extended CV Parameter | This document | +-------------+--------+----------------------------+---------------+ Table 2: New PW Interface Parameters Sub-TLV Mirsky Expires March 24, 2014 [Page 5] Internet-Draft VCCV MPLS-TP CV September 2013 3.1. VCCV Extended CV Types IANA is requested to set up a registry of ?VCCV Extended CV Types?. s/?// (twice) These are 8 bitfield values. Extended CV Type values 0x01, 0x02, s/bitfield/bit/ 0x04 and 0x08 are specified in Section 2.2 of this document. The remaining bitfield values (0x10 through 0x80) are to be assigned by s/bitfield// IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV Extended Control Verification Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry. +--------------+----------------------------------------------------+ | Bit(Value) | Description | +--------------+----------------------------------------------------+ | Bit 0 (0x01) | Independent mode for PW Fault Detection only | | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW | | | Fault Status Signaling | | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only | | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW | | | Fault Status Signaling | | Bit 4 (0x10) | Reserved | | Bit 5 (0x20) | Reserved | | Bit 6 (0x40) | Reserved | | Bit 7 (0x80) | Reserved | +--------------+----------------------------------------------------+ Table 3: MPLS Connectivity Verification (CV) Types --e89a8fb1fa625d7c3804e95a4b76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Greg,

As document shepherd for= draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last call review and have some = comments. The good news is that the draft is mostly in good shape for publi= cation, it just needs a quick revision to address the comments below. Also,= there were no other WG last call comments which need to be addressed.

First of all, there are some idnits issues that need to be addres= sed:

  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

  =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to h=
ave RFC
     2119 boilerplate text.

  -- The document date (September 20, 2013) is 32 days in the past.  Is thi=
s
     intentional?


  Checking references for intended status: Proposed Standard
  -------------------------------------------------------------------------=
---

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  =3D=3D Unused Reference: 'RFC5882' is defined on line 270, but no=
 explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2434
     (Obsoleted by RFC 5226)
I also have some comments of my own, which are mostly ed= itorial in nature. They are embedded in the text below. Just do an update t= o address the nits and these comments, and I'll be able to forward the = draft for publication.

Thanks,
Andy

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

1.=A0 Introduction

=A0=A0 Proactive Connec= tivity Verification (CV), Continuity Check (CC), and
=A0=A0 Remote Defec= t Indication (RDI) for the MPLS Transport Profile
=A0=A0 [RFC6428] are applicable to all constructs of the MPLS-TP, including=
=A0=A0 pseudowires (PWs).=A0 If Control Plane is used to operate and ma= nage PW
s/Control Plane/a control plane/
s/PW/PWs/
=A0=A0 then pro= cedure defined in [RFC5085] and [RFC5885] should be used to
s/procedure/the procedures/
=A0=A0 select proper type of Control Channel= and corresponding type of
=A0=A0 Connectivity Verification.=A0 This doc= ument specifies how signaling and
=A0=A0 selection process modified to e= nsure backward compatibility and allow
s/process modified/processes are modified/
=A0=A0 use of proactive CV-CC= -RDI over MPLS-TP PWs.

1.1.=A0 Conventions used in this document
=
1.1.1.=A0 Terminology

=A0=A0 BFD: Bidirectional Forwarding Detec= tion

=A0=A0 CC: Continuity Check

=A0=A0 CV: Connectivity Verification=

=A0=A0 PE: Provider Edge

=A0=A0 VCCV: Virtual Circuit Connec= tivity Verification

=A0=A0 VCCV CC: VCCV Control Channel

1.1.= 2.=A0 Requirements Language

=A0=A0 The key words "MUST", "MUST NOT", "REQU= IRED", "SHALL", "SHALL NOT",
=A0=A0 "SHOUL= D", "SHOULD NOT", "RECOMMENDED", "NOT RECOMME= NDED", "MAY", and
=A0=A0 "OPTIONAL" in this document are to be interpreted as descr= ibed in
=A0=A0 [RFC2119].


2.=A0 MPLS-TP CC-CV on Pseudowires<= br>
=A0=A0 PW VCCV can support several CV Types.=A0 Ability to support a= rbitrary
s/Types.=A0 Ability to support/Types, and can support/
=A0=A0 combinatio= n of CV modes advertised in CV Types field of VCCV
s/in CV/in the CV/=A0=A0 Interface Parameter sub-TLV [RFC4446], [RFC4447].=A0 Currently six<= br>=A0=A0 types of CV been defined for PW VCCV out of eight bit long field.=
s/VCCV out of eight bit long field/VCCV/
=A0=A0 This document introduces= four new CV types and, to accommodate them,
=A0=A0 a new VCCV Extended = CV parameter for PW Interface Parameters Sub-TLV
=A0=A0 is defined.
<= br>




Mirsky=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ex= pires March 24, 2014=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page = 3]
=0C
Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VCCV = MPLS-TP CV=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 September 2013

2.1.=A0 VCCV Extended CV Advertisement sub-TLV

=A0=A0 The format of VCCV Extended CV Advertisement is a TLV where:
=
=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3
=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0=A0 | Type =3D 0x19 |=A0=A0=A0 Length=A0=A0=A0=A0 |=A0=A0 CV Type=A0= =A0=A0 |=A0=A0 Reserved=A0=A0=A0=A0 |
=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Figure 1: VCCV Extended CV parameter format

=A0= =A0 Length - the length of the sub-TLV, including type and the Length
s/Length -/The Length field is/
=A0=A0 field itself.=A0 Minimum length i= s 4.=A0 It it isrecommended that
s/Minimum/The minimum/
=A0=A0 extens= ions to the sub-TLV be done in 4 bytes increments with Reserved
=A0=A0 f= ield being set to zero on transmit and ignored on receipt.

=A0=A0 Reserved field must be set to zeroes on transmit and ignored on<= br>=A0=A0 receive.
s/Reserved/The Reserved/

=A0=A0 CV Type field = is a bitmask that lists types of CV monitoring that a
s/CV Type/The CV T= ype/
=A0=A0 PE is capable to support.=A0 VCCV Extended CV parameter sub-TLV must=
s/VCCV/The VCCV/
=A0=A0 appear in combination with VCCV parameter su= b-TLV.=A0 If VCCV parameter
s/VCCV/the VCCV/ (twice in this line)
=A0= =A0 sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be s/VCCV/the VCCV/
=A0=A0 ignored.

2.2.=A0 MPLS-TP CC-CV Types
<= br>=A0=A0 The [RFC6428] defines coordinated and independent modes of monito= ring
S/The //
=A0=A0 point-to-point bi-directional connection that ca= n be applied to
=A0=A0 monitoring PWs.=A0 At the same time [RFC6310] defines how BFD-based = OAM
=A0=A0 can map and be mapped to status of an Attachment Circuit.=A0 = Thus there
=A0=A0 could be four MPLS-TP CV types as combination of modes= and
=A0=A0 functionality:

=A0=A0 +---------------+-------------------+---------------------------= ----+
=A0=A0 |=A0=A0=A0=A0 Modes=A0=A0=A0=A0 |=A0 Fault Detection=A0 |= =A0=A0 Fault Detection and Status=A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 Only=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Signalling=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 +---------------+-------------------+-------------------------------= +
=A0=A0 |=A0 Independent=A0 |=A0=A0=A0=A0=A0=A0=A0 0x01=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x02=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |
=A0=A0 |=A0=A0=A0=A0=A0 Mode=A0=A0=A0=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 |=A0 Coordinated=A0 |=A0=A0=A0=A0=A0=A0=A0 0x04=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x08=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 |=A0=A0=A0=A0=A0 Mode=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 +----------= -----+-------------------+-------------------------------+

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 1: Bitmask Values for = MPLS-TP CV Types





Mirsky=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires March 24, 2014=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 [Page 4]
=0C
Internet-Draft=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 VCCV MPLS-TP CV=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 September 2013


2.3.=A0 MPLS-TP CC-CV Type Operation

=A0=A0 Connectivity ver= ification according to [RFC6428] is part of MPLS-TP
=A0=A0 CC/CV operati= on that can be used with VCCV Control Channel Type 1
=A0=A0 [RFC5085] .= =A0 If VCCV CC Type 1 selected, then PEs might select one of
=A0=A0 MPLS-TP CC-CV types as VCCV CV mechanism to be used for this PW.
=
2.4.=A0 CV Type Selection

=A0=A0 CV selection rules that have be= en defined in Section 7 of [RFC5085]
=A0=A0 and updated Section 4 of [RF= C5885] are augmented in this document.

=A0=A0 If VCCV Control Channel Type 1 is chosen according to Section 7<= br>=A0=A0 [RFC5085] and common set of proactive CV types advertized by both= PEs
=A0=A0 includes MPLS-TP CC-CV types and some BFD CV types, then MPL= S-TP
=A0=A0 CC-CV takes precedence over any type of BFD CV.=A0 If multiple MPLS-= TP
=A0=A0 CV types advertised by both PEs, then following list sorted in=
=A0=A0 descending priority order is used:

=A0=A0 1.=A0 0x08 - co= ordinated mode for PW Fault Detection and AC/PW Fault
=A0=A0=A0=A0=A0=A0 Status Signaling

=A0=A0 2.=A0 0x04 - coordinated = mode for PW Fault Detection only

=A0=A0 3.=A0 0x02 - independent mod= e for PW Fault Detection and AC/PW Fault
=A0=A0=A0=A0=A0=A0 Status Signa= ling

=A0=A0 4.=A0 0x01 - independent mode for PW Fault Detection onl= y


3.=A0 IANA Considerations

=A0=A0 The PW Interface Parameters= Sub-TLV registry defined in [RFC4446].
s/registry defined/registry is d= efined/

=A0=A0 IANA is requested to reserve a new PW Interface Param= eters Sub-TLV
=A0=A0 type as follows:

=A0=A0 +-------------+--------+-------------= ---------------+---------------+
=A0=A0 |=A0 Parameter=A0 | Length |=A0= =A0=A0=A0=A0=A0=A0=A0 Description=A0=A0=A0=A0=A0=A0=A0 | Reference=A0=A0=A0= =A0 |
=A0=A0 |=A0=A0=A0=A0=A0 ID=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 |=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 +-------------+--------+----------------------------+---------------= +
=A0=A0 |=A0=A0=A0=A0 0x19=A0=A0=A0 | 4=A0=A0=A0=A0=A0 | VCCV Extended = CV Parameter | This document |
=A0=A0 +-------------+--------+----------= ------------------+---------------+

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 2: New PW Interface Pa= rameters Sub-TLV






Mirsky=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires March 24, 2014=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page 5]
=0C
Internet-Draft=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VCCV MPLS-TP CV=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 September 2013


3.1.=A0 VCCV Extended CV Types

=A0=A0 IANA is requested to s= et up a registry of ?VCCV Extended CV Types?.
s/?// (twice)
=A0=A0 Th= ese are 8 bitfield values.=A0 Extended CV Type values 0x01, 0x02,
s/bitf= ield/bit/
=A0=A0 0x04 and 0x08 are specified in Section 2.2 of this document.=A0 The<= br>=A0=A0 remaining bitfield values (0x10 through 0x80) are to be assigned = by
s/bitfield//
=A0=A0 IANA using the "IETF Consensus" poli= cy defined in [RFC2434].=A0 A VCCV
=A0=A0 Extended Control Verification Type description and a reference to an=
=A0=A0 RFC approved by the IESG are required for any assignment from th= is
=A0=A0 registry.

=A0=A0 +--------------+----------------------= ------------------------------+
=A0=A0 |=A0 Bit(Value)=A0 | Description=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 +--------------+----------------------------------------= ------------+
=A0=A0 | Bit 0 (0x01) | Independent mode for PW Fault Dete= ction only=A0=A0=A0=A0=A0=A0 |
=A0=A0 | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW= =A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Fault Status Sig= naling=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |
=A0=A0 | Bit 2 (0x04) | Coordinated mode for PW Fault = Detection only=A0=A0=A0=A0=A0=A0 |
=A0=A0 | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW= =A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Fault Status Sig= naling=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |
=A0=A0 | Bit 4 (0x10) | Reserved=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 | Bit 5 (0x20) | Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
=A0=A0 | Bit 6 (0x40) | Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 | Bit 7 (0x80) | Reserved=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 +--------------+----------------------------------------------------= +

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3: MPLS Connectivity Verif= ication (CV) Types



--e89a8fb1fa625d7c3804e95a4b76-- From amalis@gmail.com Tue Oct 22 13:34:34 2013 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 67BDD11E81F8 for ; Tue, 22 Oct 2013 13:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 QN9YPmWBBo5I for ; Tue, 22 Oct 2013 13:34:33 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AE4DA11E8250 for ; Tue, 22 Oct 2013 13:34:28 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id k14so7194882oag.29 for ; Tue, 22 Oct 2013 13:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=wDWXGoGx28qvT0jhz/B3/qRSv2lJaH1qyPdWpRSaYVc=; b=hS4uf1tzjSS0Mx+SyRAYSHE5bmtualB8T64jXUdC5H8Qs9uCjQ8u+UK1TQZ6PTeMhG Q6cnWcypqLm++86wVF2RYYl/M0ab1SyxQDrLJ47obm7asNLrwMGMmm2Pw9vq6n7M9TcO H525QkzrpgMkTvssY+1jgIyEwQFChaGxPtNaHC6ocUz0Vkn99BFLWeBJMq9oHfDraU9z SGG5z+Q8h3f2lNNY+FYNJFKurQaIA9RZvmXqsuWlRph7vIHs3vR03+xwW1eie9FQqYCG fwDuEpQrIV0fWXiLHeROo2DNC3OB4iw+SfYKXcx3MsqczDf53KEG4JGQuazJooTuDaW5 aWIA== X-Received: by 10.60.70.134 with SMTP id m6mr3525357oeu.14.1382474068220; Tue, 22 Oct 2013 13:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.182.9 with HTTP; Tue, 22 Oct 2013 13:34:08 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 22 Oct 2013 16:34:08 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a1133458ebf630604e95a537a Subject: Re: [PWE3] PWE3 Working Group last call for draft-ietf-pwe3-mpls-tp-cv-adv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:34:34 -0000 --001a1133458ebf630604e95a537a Content-Type: text/plain; charset=ISO-8859-1 This (belatedly) ends the WG last call for http://tools.ietf.org/html/draft- ietf-pwe3-mpls-tp-cv-adv-01, with one comment received (from me). Once the draft has been updated, it will be forwarded to the IESG for publication. Cheers, Andy On Wed, Sep 25, 2013 at 9:54 AM, Andrew G. Malis wrote: > PWE3ers, > > This begins a two-week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-cv-adv-01 . > > Please send comments on this draft by replying to this message and > including the pwe3 list. The chairs would appreciate indications that the > draft has been read and agreement that it is ready for publication, > even if you don't have other comments. > > Coincidentally, we are also polling for knowledge of IPR that > applies to this draft to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 > for more details). To date, there have been no IPR declarations on this > draft. > > If you are listed as a document author or contributor please respond > to this email whether or not you are aware of any additional IPR. The > draft will not be forwarded to the IESG until a response has been > received from each author and contributor. > > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > This WG last call will conclude on 9 October 2013. > > Thanks, > Andy > > --001a1133458ebf630604e95a537a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This (belatedly) ends the WG last call for http://tools.ietf.org/html/d= raft-ietf-pwe3-mpls-tp-cv-adv-01, with one comment received (from me).= Once the draft has been updated, it will be forwarded to the IESG for publ= ication.

Cheers,
Andy



<= div class=3D"gmail_quote">On Wed, Sep 25, 2013 at 9:54 AM, Andrew G. Malis = <amalis@gmail.com> wrote:
PWE3ers,

This begins a two-week working group last call for
http://tools.ietf.org/html/= draft-ietf-pwe3-mpls-tp-cv-adv-01 .

Please send comments on this draft by replying to this message and
= including the pwe3 list. The chairs would appreciate indicatio= ns that the
draft has been read and agreement that it is ready for publ= ication,
even if you don't have other comments.

Coincidentally, we are also polling for knowledge of IPR that
applies to this draft to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378
for = more details). To date, there have been no IPR declarations on this
draft.

If you are listed as a document author or contributor please respond
to this email whether or not you are aware of any additional IPR. The
draft will not be forwarded to the IESG until a response has been
received from each author and contributor.

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

This WG last call will conclude on 9 October 2013= .

Thanks,
Andy


--001a1133458ebf630604e95a537a-- From zhangmingui@huawei.com Fri Oct 25 02:05:53 2013 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 94A6911E8353; Fri, 25 Oct 2013 02:05:51 -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 UiECyg3QL+yL; Fri, 25 Oct 2013 02:05:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DAFC821E80AD; Fri, 25 Oct 2013 02:05:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZL47505; Fri, 25 Oct 2013 09:05:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 10:05:33 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 10:05:39 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.234]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Fri, 25 Oct 2013 17:05:32 +0800 From: Mingui Zhang To: "l3vpn@ietf.org" Thread-Topic: I-D Action: draft-zhang-l3vpn-label-sharing-01.txt Thread-Index: AQHOzjs12GcUazYvVk2zdJUUGhGnEZoE/3hA Date: Fri, 25 Oct 2013 09:05:31 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E733643454@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pwe3@ietf.org" Subject: [PWE3] FW: I-D Action: draft-zhang-l3vpn-label-sharing-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:05:53 -0000 Hi, We received lots of comments on the initial version. The draft was updated = and we included a new author. This draft tries to bring up a simple solution for egress PE protection. It= is easily to be deployed and brings no big change. Welcome your comments o= n the mailing list and at the Vancouver meeting. Thanks, Mingui PS: I copied this email to the pwe3 mailing list since there is a companion= draft: ICCP Application TLVs for VPN Route Label Sharing, http://tools.iet= f.org/html/draft-zhang-pwe3-iccp-label-sharing-00 >-----Original Message----- >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >On Behalf Of internet-drafts@ietf.org >Sent: Monday, October 21, 2013 4:42 PM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-zhang-l3vpn-label-sharing-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > > Title : Label Sharing for Fast PE Protection > Author(s) : Mingui Zhang > Peng Zhou > Russ White > Filename : draft-zhang-l3vpn-label-sharing-01.txt > Pages : 13 > Date : 2013-10-21 > >Abstract: > This document describes a method to be used by Service Providers to > provide fast protection of VPN connections for a CE. Egress PEs in a > redundant group always assign the same label for VPN routes from a > VRF. These egress PEs create a BGP virtual Next Hop (vNH) in the > domain of the IP/MPLS backbone network as an agent of the CE router. > Primary and backup tunnels terminated at the vNH are set up by the > BGP/MPLS IP VPN based on IGP FRR. If the primary egress PE fails, the > backup egress PEs can recognize the "shared" VPN route label, so that > the failure affected traffic can be smoothly switched to the backup > PE for delivery without changing its VPN route label. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-zhang-l3vpn-label-sharing > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-l3vpn-label-sharing-01 > > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From zhangmingui@huawei.com Fri Oct 25 02:06:40 2013 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 4C8B821E80BB for ; Fri, 25 Oct 2013 02:06:40 -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 rirMFT103FEK for ; Fri, 25 Oct 2013 02:06:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 448A221E80B8 for ; Fri, 25 Oct 2013 02:06:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZL47569; Fri, 25 Oct 2013 09:06:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 10:06:04 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 10:06:10 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.234]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0146.000; Fri, 25 Oct 2013 17:06:07 +0800 From: Mingui Zhang To: "pwe3@ietf.org" Thread-Topic: Ask for comments on two drafts from the WG Thread-Index: Ac7RYXB0LN4bKjFMQbib2stJkHkKFw== Date: Fri, 25 Oct 2013 09:06:07 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E733643462@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [PWE3] Ask for comments on two drafts from the WG X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:06:40 -0000 Hi there, As we know, ICCP provides us an extendable protocol for PE redundancy. We h= ave submitted two drafts to introduce two new applications into ICCP. Welco= me your comments. STP Application of ICCP, http://tools.ietf.org/html/draft-zhang-pwe3-iccp-s= tp-00 In this document, the PEs in a Redundant Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks. The ICCP TLVs for the STP application are defined, therefore PEs from the RG can make use of these TLVs to synchronize the state and configuration data. ICCP Application TLVs for VPN Route Label Sharing, http://tools.ietf.org/ht= ml/draft-zhang-pwe3-iccp-label-sharing-00 This document defines TLVs under Inter-Chassis Communication Protocol (ICCP) to include a new application: Label Sharing for Fast PE Protection. Egress PEs in the same Redundant Group utilize the ICCP connection to negotiate the "VPN route label" and the "BGP next hop" for each VPN. Thanks, Mingui From gregory.mirsky@ericsson.com Fri Oct 25 14:05:51 2013 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 52F8A11E81DC for ; Fri, 25 Oct 2013 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfC9ly6oHf-Z for ; Fri, 25 Oct 2013 14:05:44 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 56CAF11E81BD for ; Fri, 25 Oct 2013 14:05:44 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-12-526add27ae73 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E0.13.03458.72DDA625; Fri, 25 Oct 2013 23:05:43 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 17:05:42 -0400 From: Gregory Mirsky To: "Andrew G. Malis" Thread-Topic: Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01 Thread-Index: AQHOz2XLYUaC0PamkE6Z/HzHOxwGypoF7INw Date: Fri, 25 Oct 2013 21:05:40 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B70A5A7@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B70A5A7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPoK763awgg67/ahb3ri5jt+j7tIXF gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mro/n6PseDDBKaKk/fbmRoYTz1h7GLk5JAQ MJGY1NEAZYtJXLi3nq2LkYtDSOAoo0TvutPsEM5yRon2m2/BqtgEjCRebOxhB7FFBDQkFnw8 zwRiMwsoS2yf3cwGYgsLOEu8m/CABaLGRWLb8Z/MELaRRPuR12BzWARUJTbdPMTaxcjBwSvg K3G/wwgkLCQQING1ZSHYGE6BQIkFs9aDjWcEOu77qTVQq8Qlbj2ZzwRxtIDEkj3nmSFsUYmX j/+xQtjKEt/nPGKBqM+XWLZ0KVg9r4CgxMmZT1gmMIrOQjJqFpKyWUjKIOI6Egt2f2KDsLUl li18zQxjnznwmAlZfAEj+ypGjtLi1LLcdCPDTYzAyDomwea4g3HBJ8tDjNIcLErivF/eOgcJ CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFwZfueG6CtOrlkiDRsXiAYdfD8zsLF+TsHsjd87 +HfnxOjPKpCv/Mvs7f+/OedxpYvVJ2+zN04LP+9/Jid0d5myygkNxzk9zE8yt9ptj6278HvR NtNNAS8ehfY7Hnxy4pn11ikJFxfb3ogwOXgn7M68aSZPWxtWeP742+ab7iZxqefoDLNHh/mU WIozEg21mIuKEwEkPOXlegIAAA== Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:05:51 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B70A5A7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Andy, thank you for your comments and suggestions. All are accepted and I'll make= appropriate changes to publish the next version as soon as gate gets open. Regards, Greg From: Andrew G. Malis [mailto:amalis@gmail.com] Sent: Tuesday, October 22, 2013 1:32 PM To: Gregory Mirsky Cc: pwe3@ietf.org Subject: Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01 Greg, As document shepherd for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last ca= ll review and have some comments. The good news is that the draft is mostly= in good shape for publication, it just needs a quick revision to address t= he comments below. Also, there were no other WG last call comments which ne= ed to be addressed. First of all, there are some idnits issues that need to be addressed: Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to have = RFC 2119 boilerplate text. -- The document date (September 20, 2013) is 32 days in the past. Is thi= s intentional? Checking references for intended status: Proposed Standard -------------------------------------------------------------------------= --- (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) =3D=3D Unused Reference: 'RFC5882' is defined on line 270, but no explici= t reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) I also have some comments of my own, which are mostly editorial in nature. = They are embedded in the text below. Just do an update to address the nits = and these comments, and I'll be able to forward the draft for publication. Thanks, Andy ------------ 1. Introduction Proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) for the MPLS Transport Profile [RFC6428] are applicable to all constructs of the MPLS-TP, including pseudowires (PWs). If Control Plane is used to operate and manage PW s/Control Plane/a control plane/ s/PW/PWs/ then procedure defined in [RFC5085] and [RFC5885] should be used to s/procedure/the procedures/ select proper type of Control Channel and corresponding type of Connectivity Verification. This document specifies how signaling and selection process modified to ensure backward compatibility and allow s/process modified/processes are modified/ use of proactive CV-CC-RDI over MPLS-TP PWs. 1.1. Conventions used in this document 1.1.1. Terminology BFD: Bidirectional Forwarding Detection CC: Continuity Check CV: Connectivity Verification PE: Provider Edge VCCV: Virtual Circuit Connectivity Verification VCCV CC: VCCV Control Channel 1.1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. MPLS-TP CC-CV on Pseudowires PW VCCV can support several CV Types. Ability to support arbitrary s/Types. Ability to support/Types, and can support/ combination of CV modes advertised in CV Types field of VCCV s/in CV/in the CV/ Interface Parameter sub-TLV [RFC4446], [RFC4447]. Currently six types of CV been defined for PW VCCV out of eight bit long field. s/VCCV out of eight bit long field/VCCV/ This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined. Mirsky Expires March 24, 2014 [Page 3] Internet-Draft VCCV MPLS-TP CV September 2013 2.1. VCCV Extended CV Advertisement sub-TLV The format of VCCV Extended CV Advertisement is a TLV where: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 0x19 | Length | CV Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: VCCV Extended CV parameter format Length - the length of the sub-TLV, including type and the Length s/Length -/The Length field is/ field itself. Minimum length is 4. It it isrecommended that s/Minimum/The minimum/ extensions to the sub-TLV be done in 4 bytes increments with Reserved field being set to zero on transmit and ignored on receipt. Reserved field must be set to zeroes on transmit and ignored on receive. s/Reserved/The Reserved/ CV Type field is a bitmask that lists types of CV monitoring that a s/CV Type/The CV Type/ PE is capable to support. VCCV Extended CV parameter sub-TLV must s/VCCV/The VCCV/ appear in combination with VCCV parameter sub-TLV. If VCCV parameter s/VCCV/the VCCV/ (twice in this line) sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be s/VCCV/the VCCV/ ignored. 2.2. MPLS-TP CC-CV Types The [RFC6428] defines coordinated and independent modes of monitoring S/The // point-to-point bi-directional connection that can be applied to monitoring PWs. At the same time [RFC6310] defines how BFD-based OAM can map and be mapped to status of an Attachment Circuit. Thus there could be four MPLS-TP CV types as combination of modes and functionality: +---------------+-------------------+-------------------------------+ | Modes | Fault Detection | Fault Detection and Status | | | Only | Signalling | +---------------+-------------------+-------------------------------+ | Independent | 0x01 | 0x02 | | Mode | | | | Coordinated | 0x04 | 0x08 | | Mode | | | +---------------+-------------------+-------------------------------+ Table 1: Bitmask Values for MPLS-TP CV Types Mirsky Expires March 24, 2014 [Page 4] Internet-Draft VCCV MPLS-TP CV September 2013 2.3. MPLS-TP CC-CV Type Operation Connectivity verification according to [RFC6428] is part of MPLS-TP CC/CV operation that can be used with VCCV Control Channel Type 1 [RFC5085] . If VCCV CC Type 1 selected, then PEs might select one of MPLS-TP CC-CV types as VCCV CV mechanism to be used for this PW. 2.4. CV Type Selection CV selection rules that have been defined in Section 7 of [RFC5085] and updated Section 4 of [RFC5885] are augmented in this document. If VCCV Control Channel Type 1 is chosen according to Section 7 [RFC5085] and common set of proactive CV types advertized by both PEs includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP CC-CV takes precedence over any type of BFD CV. If multiple MPLS-TP CV types advertised by both PEs, then following list sorted in descending priority order is used: 1. 0x08 - coordinated mode for PW Fault Detection and AC/PW Fault Status Signaling 2. 0x04 - coordinated mode for PW Fault Detection only 3. 0x02 - independent mode for PW Fault Detection and AC/PW Fault Status Signaling 4. 0x01 - independent mode for PW Fault Detection only 3. IANA Considerations The PW Interface Parameters Sub-TLV registry defined in [RFC4446]. s/registry defined/registry is defined/ IANA is requested to reserve a new PW Interface Parameters Sub-TLV type as follows: +-------------+--------+----------------------------+---------------+ | Parameter | Length | Description | Reference | | ID | | | | +-------------+--------+----------------------------+---------------+ | 0x19 | 4 | VCCV Extended CV Parameter | This document | +-------------+--------+----------------------------+---------------+ Table 2: New PW Interface Parameters Sub-TLV Mirsky Expires March 24, 2014 [Page 5] Internet-Draft VCCV MPLS-TP CV September 2013 3.1. VCCV Extended CV Types IANA is requested to set up a registry of ?VCCV Extended CV Types?. s/?// (twice) These are 8 bitfield values. Extended CV Type values 0x01, 0x02, s/bitfield/bit/ 0x04 and 0x08 are specified in Section 2.2 of this document. The remaining bitfield values (0x10 through 0x80) are to be assigned by s/bitfield// IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV Extended Control Verification Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry. +--------------+----------------------------------------------------+ | Bit(Value) | Description | +--------------+----------------------------------------------------+ | Bit 0 (0x01) | Independent mode for PW Fault Detection only | | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW | | | Fault Status Signaling | | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only | | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW | | | Fault Status Signaling | | Bit 4 (0x10) | Reserved | | Bit 5 (0x20) | Reserved | | Bit 6 (0x40) | Reserved | | Bit 7 (0x80) | Reserved | +--------------+----------------------------------------------------+ Table 3: MPLS Connectivity Verification (CV) Types --_000_7347100B5761DC41A166AC17F22DF1121B70A5A7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Andy,

thank you for your commen= ts and suggestions. All are accepted and I’ll make appropriate change= s to publish the next version as soon as gate gets open.<= /p>

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Andrew G= . Malis [mailto:amalis@gmail.com]
Sent: Tuesday, October 22, 2013 1:32 PM
To: Gregory Mirsky
Cc: pwe3@ietf.org
Subject: Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01=

 

Greg,

As document shepherd = for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last call review and have so= me comments. The good news is that the draft is mostly in good shape for pu= blication, it just needs a quick revision to address the comments below. Also, there were no other WG last call comm= ents which need to be addressed.

First of all, there a= re some idnits issues that need to be addressed:

  Miscellaneous warnings:
  -------------------------------=
---------------------------------------------
 
  =3D=3D The document doesn't use=
 any RFC 2119 keywords, yet seems to have RFC
     2119 boilerpl=
ate text.
 
  -- The document date (September=
 20, 2013) is 32 days in the past.  Is this
     intentional?<=
o:p>
 
 
  Checking references for intende=
d status: Proposed Standard
  -------------------------------=
---------------------------------------------
 
     (See RFCs 396=
7 and 4897 for information about using normative references
     to lower-matu=
rity documents in RFCs)
 
  =3D=3D Unused Reference: 'RFC58=
82' is defined on line 270, but no explicit
     reference was=
 found in the text
 
  -- Obsolete informational refer=
ence (is this intentional?): RFC 2434
     (Obsoleted by=
 RFC 5226)

I also have some comm= ents of my own, which are mostly editorial in nature. They are embedded in = the text below. Just do an update to address the nits and these comments, a= nd I'll be able to forward the draft for publication.

Thanks,
Andy

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

1. = ; Introduction

   Proactive Connectivity Verification (CV), Continuity Check (CC= ), and
   Remote Defect Indication (RDI) for the MPLS Transport Profile<= br>    [RFC6428] are applicable to all constructs of the MPLS-TP, inc= luding
   pseudowires (PWs).  If Control Plane is used to operate a= nd manage PW
s/Control Plane/a control plane/
s/PW/PWs/
   then procedure defined in [RFC5085] and [RFC5885] should be us= ed to
s/procedure/the procedures/
   select proper type of Control Channel and corresponding type o= f
   Connectivity Verification.  This document specifies how s= ignaling and
   selection process modified to ensure backward compatibility an= d allow
s/process modified/processes are modified/
   use of proactive CV-CC-RDI over MPLS-TP PWs.

1.1.  Conventions used in this document

1.1.1.  Terminology

   BFD: Bidirectional Forwarding Detection

   CC: Continuity Check

   CV: Connectivity Verification

   PE: Provider Edge

   VCCV: Virtual Circuit Connectivity Verification

   VCCV CC: VCCV Control Channel

1.1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as= described in
   [RFC2119].


2.  MPLS-TP CC-CV on Pseudowires

   PW VCCV can support several CV Types.  Ability to support= arbitrary
s/Types.  Ability to support/Types, and can support/
   combination of CV modes advertised in CV Types field of VCCV s/in CV/in the CV/
   Interface Parameter sub-TLV [RFC4446], [RFC4447].  Curren= tly six
   types of CV been defined for PW VCCV out of eight bit long fie= ld.
s/VCCV out of eight bit long field/VCCV/
   This document introduces four new CV types and, to accommodate= them,
   a new VCCV Extended CV parameter for PW Interface Parameters S= ub-TLV
   is defined.






Mirsky           &nb= sp;       Expires March 24, 2014  &= nbsp;           &nbs= p;  [Page 3]

Internet-Draft          &= nbsp;    VCCV MPLS-TP CV      =         September 2013


2.1.  VCCV Extended CV Advertisement sub-TLV

   The format of VCCV Extended CV Advertisement is a TLV where:
    0         &= nbsp;         1   &n= bsp;            = ;   2          =          3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1
    +-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
    | Type =3D 0x19 |    Length  &n= bsp;  |   CV Type    |   Reserved&n= bsp;    |
    +-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

            &nb= sp;   Figure 1: VCCV Extended CV parameter format

   Length - the length of the sub-TLV, including type and the Len= gth
s/Length -/The Length field is/
   field itself.  Minimum length is 4.  It it isrecomme= nded that
s/Minimum/The minimum/
   extensions to the sub-TLV be done in 4 bytes increments with R= eserved
   field being set to zero on transmit and ignored on receipt.
   Reserved field must be set to zeroes on transmit and ignored o= n
   receive.
s/Reserved/The Reserved/

   CV Type field is a bitmask that lists types of CV monitoring t= hat a
s/CV Type/The CV Type/
   PE is capable to support.  VCCV Extended CV parameter sub= -TLV must
s/VCCV/The VCCV/
   appear in combination with VCCV parameter sub-TLV.  If VC= CV parameter
s/VCCV/the VCCV/ (twice in this line)
   sub-TLV is missing then VCCV Extended CV parameter sub-TLV sho= uld be
s/VCCV/the VCCV/
   ignored.

2.2.  MPLS-TP CC-CV Types

   The [RFC6428] defines coordinated and independent modes of mon= itoring
S/The //
   point-to-point bi-directional connection that can be applied t= o
   monitoring PWs.  At the same time [RFC6310] defines how B= FD-based OAM
   can map and be mapped to status of an Attachment Circuit. = ; Thus there
   could be four MPLS-TP CV types as combination of modes and
   functionality:

   +---------------+-------------------+-------------= ------------------+
   |     Modes     | = ; Fault Detection  |   Fault Detection and Status  |    |          &= nbsp;    |        Only&nb= sp;      |      &nbs= p;    Signalling       &n= bsp;  |
   +---------------+-------------------+-------------= ------------------+
   |  Independent  |      = ;  0x01       |    &= nbsp;         0x02   = ;          |
   |      Mode     |=             &nb= sp;      |      &nbs= p;            &= nbsp;           |
   |  Coordinated  |      = ;  0x04       |    &= nbsp;         0x08   = ;          |
   |      Mode     |=             &nb= sp;      |      &nbs= p;            &= nbsp;           |
   +---------------+-------------------+-------------= ------------------+

            &nb= sp;  Table 1: Bitmask Values for MPLS-TP CV Types





Mirsky           &nb= sp;       Expires March 24, 2014  &= nbsp;           &nbs= p;  [Page 4]

Internet-Draft          &= nbsp;    VCCV MPLS-TP CV      =         September 2013


2.3.  MPLS-TP CC-CV Type Operation

   Connectivity verification according to [RFC6428] is part of MP= LS-TP
   CC/CV operation that can be used with VCCV Control Channel Typ= e 1
   [RFC5085] .  If VCCV CC Type 1 selected, then PEs might s= elect one of
   MPLS-TP CC-CV types as VCCV CV mechanism to be used for this P= W.

2.4.  CV Type Selection

   CV selection rules that have been defined in Section 7 of [RFC= 5085]
   and updated Section 4 of [RFC5885] are augmented in this docum= ent.

   If VCCV Control Channel Type 1 is chosen according to Section = 7
   [RFC5085] and common set of proactive CV types advertized by b= oth PEs
   includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-= TP
   CC-CV takes precedence over any type of BFD CV.  If multi= ple MPLS-TP
   CV types advertised by both PEs, then following list sorted in=
   descending priority order is used:

   1.  0x08 - coordinated mode for PW Fault Detection and AC= /PW Fault
       Status Signaling

   2.  0x04 - coordinated mode for PW Fault Detection only
   3.  0x02 - independent mode for PW Fault Detection and AC= /PW Fault
       Status Signaling

   4.  0x01 - independent mode for PW Fault Detection only

3.  IANA Considerations

   The PW Interface Parameters Sub-TLV registry defined in [RFC44= 46].
s/registry defined/registry is defined/

   IANA is requested to reserve a new PW Interface Parameters Sub= -TLV
   type as follows:

   +-------------+--------+--------------------------= --+---------------+
   |  Parameter  | Length |    &nbs= p;    Description        = | Reference     |
   |      ID     |&n= bsp;       |     &nb= sp;            =           |   &= nbsp;           |
   +-------------+--------+--------------------------= --+---------------+
   |     0x19    | 4 &nbs= p;    | VCCV Extended CV Parameter | This document |
   +-------------+--------+--------------------------= --+---------------+

            &nb= sp;  Table 2: New PW Interface Parameters Sub-TLV






Mirsky           &nb= sp;       Expires March 24, 2014  &= nbsp;           &nbs= p;  [Page 5]

Internet-Draft          &= nbsp;    VCCV MPLS-TP CV      =         September 2013


3.1.  VCCV Extended CV Types

   IANA is requested to set up a registry of ?VCCV Extended CV Ty= pes?.
s/?// (twice)
   These are 8 bitfield values.  Extended CV Type values 0x0= 1, 0x02,
s/bitfield/bit/
   0x04 and 0x08 are specified in Section 2.2 of this document.&n= bsp; The
   remaining bitfield values (0x10 through 0x80) are to be assign= ed by
s/bitfield//
   IANA using the "IETF Consensus" policy defined in [R= FC2434].  A VCCV
   Extended Control Verification Type description and a reference= to an
   RFC approved by the IESG are required for any assignment from = this
   registry.

   +--------------+--------------------------------------= --------------+
   |  Bit(Value)  | Description    =             &nb= sp;            =            |
   +--------------+--------------------------------------= --------------+
   | Bit 0 (0x01) | Independent mode for PW Fault Detection only&= nbsp;      |
   | Bit 1 (0x02) | Independent mode for PW Fault Detection and A= C/PW  |
   |          &= nbsp;   | Fault Status Signaling     &nb= sp;            =            |
   | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only&= nbsp;      |
   | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and A= C/PW  |
   |          &= nbsp;   | Fault Status Signaling     &nb= sp;            =            |
   | Bit 4 (0x10) | Reserved      &= nbsp;           &nbs= p;            &= nbsp;           |
   | Bit 5 (0x20) | Reserved      &= nbsp;           &nbs= p;            &= nbsp;           |
   | Bit 6 (0x40) | Reserved      &= nbsp;           &nbs= p;            &= nbsp;           |
   | Bit 7 (0x80) | Reserved      &= nbsp;           &nbs= p;            &= nbsp;           |
   +--------------+--------------------------------------= --------------+

            Table 3:= MPLS Connectivity Verification (CV) Types


--_000_7347100B5761DC41A166AC17F22DF1121B70A5A7eusaamb103erics_-- From amalis@gmail.com Fri Oct 25 14:18:38 2013 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 C2B7211E8213 for ; Fri, 25 Oct 2013 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rqliS89KgZVX for ; Fri, 25 Oct 2013 14:18:35 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9E07C11E8196 for ; Fri, 25 Oct 2013 14:18:35 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n10so1489052oag.39 for ; Fri, 25 Oct 2013 14:18:35 -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=r/p+OtgZ+mEit8WUlIzIPavhITHv+7hSg/QpjI4HzI0=; b=O+gE4VvOLbf75o02HmQK/ZuMFNyoBvYpdBpiRot4p8SRfCTsbJ53hECQoH1J+cIRQw Bt0E42UV7wPCro2/lsiBLOWbZHBOnSMj9+bSTqSseJ4kk7HRGNMt/qpddW7Xk2FygN+P XrkEf1zZbcx/pGno45GXYZWgRLoMdKfSVEfqLODcZv9HbPYk2F5N2lvVVNp81XWiSxQT 2Bh6laMNOKmKfavqojle1d8NbLZXjPqlJUfgAGvx09tD0bXcL2NMBIdeVPE61nf5nizK IMR5YA+opfr8fp16b3WW4sCiA+oHxpQLW1jRSPMjcjhjeGxySgroQFJKM8B3N20j6+ab 32DQ== X-Received: by 10.182.133.2 with SMTP id oy2mr45488obb.80.1382735914921; Fri, 25 Oct 2013 14:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.182.9 with HTTP; Fri, 25 Oct 2013 14:18:14 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B70A5A7@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B70A5A7@eusaamb103.ericsson.se> From: "Andrew G. Malis" Date: Fri, 25 Oct 2013 17:18:14 -0400 Message-ID: To: Gregory Mirsky Content-Type: multipart/alternative; boundary=e89a8ff1cdd606f40304e9974bfc Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:18:38 -0000 --e89a8ff1cdd606f40304e9974bfc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greg, Thanks, much appreciated. Cheers, Andy On Fri, Oct 25, 2013 at 5:05 PM, Gregory Mirsky wrote: > Dear Andy,**** > > thank you for your comments and suggestions. All are accepted and I=92ll > make appropriate changes to publish the next version as soon as gate gets > open.**** > > ** ** > > Regards,**** > > Greg**** > > ** ** > > *From:* Andrew G. Malis [mailto:amalis@gmail.com] > *Sent:* Tuesday, October 22, 2013 1:32 PM > *To:* Gregory Mirsky > *Cc:* pwe3@ietf.org > *Subject:* Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01**** > > ** ** > > Greg,**** > > As document shepherd for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last > call review and have some comments. The good news is that the draft is > mostly in good shape for publication, it just needs a quick revision to > address the comments below. Also, there were no other WG last call commen= ts > which need to be addressed.**** > > First of all, there are some idnits issues that need to be addressed:**** > > Miscellaneous warnings:**** > > -----------------------------------------------------------------------= -----**** > > ** ** > > =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to hav= e RFC**** > > 2119 boilerplate text.**** > > ** ** > > -- The document date (September 20, 2013) is 32 days in the past. Is t= his**** > > intentional?**** > > ** ** > > ** ** > > Checking references for intended status: Proposed Standard**** > > -----------------------------------------------------------------------= -----**** > > ** ** > > (See RFCs 3967 and 4897 for information about using normative refere= nces**** > > to lower-maturity documents in RFCs)**** > > ** ** > > =3D=3D Unused Reference: 'RFC5882' is defined on line 270, but no expli= cit**** > > reference was found in the text**** > > ** ** > > -- Obsolete informational reference (is this intentional?): RFC 2434***= * > > (Obsoleted by RFC 5226)**** > > I also have some comments of my own, which are mostly editorial in > nature. They are embedded in the text below. Just do an update to address > the nits and these comments, and I'll be able to forward the draft for > publication. > > Thanks, > Andy > > ------------ > > 1. Introduction > > Proactive Connectivity Verification (CV), Continuity Check (CC), and > Remote Defect Indication (RDI) for the MPLS Transport Profile > [RFC6428] are applicable to all constructs of the MPLS-TP, including > pseudowires (PWs). If Control Plane is used to operate and manage PW > s/Control Plane/a control plane/ > s/PW/PWs/ > then procedure defined in [RFC5085] and [RFC5885] should be used to > s/procedure/the procedures/ > select proper type of Control Channel and corresponding type of > Connectivity Verification. This document specifies how signaling and > selection process modified to ensure backward compatibility and allow > s/process modified/processes are modified/ > use of proactive CV-CC-RDI over MPLS-TP PWs. > > 1.1. Conventions used in this document > > 1.1.1. Terminology > > BFD: Bidirectional Forwarding Detection > > CC: Continuity Check > > CV: Connectivity Verification > > PE: Provider Edge > > VCCV: Virtual Circuit Connectivity Verification > > VCCV CC: VCCV Control Channel > > 1.1.2. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. > > > 2. MPLS-TP CC-CV on Pseudowires > > PW VCCV can support several CV Types. Ability to support arbitrary > s/Types. Ability to support/Types, and can support/ > combination of CV modes advertised in CV Types field of VCCV > s/in CV/in the CV/ > Interface Parameter sub-TLV [RFC4446], [RFC4447]. Currently six > types of CV been defined for PW VCCV out of eight bit long field. > s/VCCV out of eight bit long field/VCCV/ > This document introduces four new CV types and, to accommodate them, > a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV > is defined. > > > > > > > Mirsky Expires March 24, 2014 [Page 3] > > Internet-Draft VCCV MPLS-TP CV September 2013 > > > 2.1. VCCV Extended CV Advertisement sub-TLV > > The format of VCCV Extended CV Advertisement is a TLV where: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D 0x19 | Length | CV Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: VCCV Extended CV parameter format > > Length - the length of the sub-TLV, including type and the Length > s/Length -/The Length field is/ > field itself. Minimum length is 4. It it isrecommended that > s/Minimum/The minimum/ > extensions to the sub-TLV be done in 4 bytes increments with Reserved > field being set to zero on transmit and ignored on receipt. > > Reserved field must be set to zeroes on transmit and ignored on > receive. > s/Reserved/The Reserved/ > > CV Type field is a bitmask that lists types of CV monitoring that a > s/CV Type/The CV Type/ > PE is capable to support. VCCV Extended CV parameter sub-TLV must > s/VCCV/The VCCV/ > appear in combination with VCCV parameter sub-TLV. If VCCV parameter > s/VCCV/the VCCV/ (twice in this line) > sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be > s/VCCV/the VCCV/ > ignored. > > 2.2. MPLS-TP CC-CV Types > > The [RFC6428] defines coordinated and independent modes of monitoring > S/The // > point-to-point bi-directional connection that can be applied to > monitoring PWs. At the same time [RFC6310] defines how BFD-based OAM > can map and be mapped to status of an Attachment Circuit. Thus there > could be four MPLS-TP CV types as combination of modes and > functionality: > > +---------------+-------------------+-------------------------------+ > | Modes | Fault Detection | Fault Detection and Status | > | | Only | Signalling | > +---------------+-------------------+-------------------------------+ > | Independent | 0x01 | 0x02 | > | Mode | | | > | Coordinated | 0x04 | 0x08 | > | Mode | | | > +---------------+-------------------+-------------------------------+ > > Table 1: Bitmask Values for MPLS-TP CV Types > > > > > > Mirsky Expires March 24, 2014 [Page 4] > > Internet-Draft VCCV MPLS-TP CV September 2013 > > > 2.3. MPLS-TP CC-CV Type Operation > > Connectivity verification according to [RFC6428] is part of MPLS-TP > CC/CV operation that can be used with VCCV Control Channel Type 1 > [RFC5085] . If VCCV CC Type 1 selected, then PEs might select one of > MPLS-TP CC-CV types as VCCV CV mechanism to be used for this PW. > > 2.4. CV Type Selection > > CV selection rules that have been defined in Section 7 of [RFC5085] > and updated Section 4 of [RFC5885] are augmented in this document. > > If VCCV Control Channel Type 1 is chosen according to Section 7 > [RFC5085] and common set of proactive CV types advertized by both PEs > includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP > CC-CV takes precedence over any type of BFD CV. If multiple MPLS-TP > CV types advertised by both PEs, then following list sorted in > descending priority order is used: > > 1. 0x08 - coordinated mode for PW Fault Detection and AC/PW Fault > Status Signaling > > 2. 0x04 - coordinated mode for PW Fault Detection only > > 3. 0x02 - independent mode for PW Fault Detection and AC/PW Fault > Status Signaling > > 4. 0x01 - independent mode for PW Fault Detection only > > > 3. IANA Considerations > > The PW Interface Parameters Sub-TLV registry defined in [RFC4446]. > s/registry defined/registry is defined/ > > IANA is requested to reserve a new PW Interface Parameters Sub-TLV > type as follows: > > +-------------+--------+----------------------------+---------------+ > | Parameter | Length | Description | Reference | > | ID | | | | > +-------------+--------+----------------------------+---------------+ > | 0x19 | 4 | VCCV Extended CV Parameter | This document | > +-------------+--------+----------------------------+---------------+ > > Table 2: New PW Interface Parameters Sub-TLV > > > > > > > Mirsky Expires March 24, 2014 [Page 5] > > Internet-Draft VCCV MPLS-TP CV September 2013 > > > 3.1. VCCV Extended CV Types > > IANA is requested to set up a registry of ?VCCV Extended CV Types?. > s/?// (twice) > These are 8 bitfield values. Extended CV Type values 0x01, 0x02, > s/bitfield/bit/ > 0x04 and 0x08 are specified in Section 2.2 of this document. The > remaining bitfield values (0x10 through 0x80) are to be assigned by > s/bitfield// > IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV > Extended Control Verification Type description and a reference to an > RFC approved by the IESG are required for any assignment from this > registry. > > +--------------+----------------------------------------------------+ > | Bit(Value) | Description | > +--------------+----------------------------------------------------+ > | Bit 0 (0x01) | Independent mode for PW Fault Detection only | > | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW | > | | Fault Status Signaling | > | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only | > | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW | > | | Fault Status Signaling | > | Bit 4 (0x10) | Reserved | > | Bit 5 (0x20) | Reserved | > | Bit 6 (0x40) | Reserved | > | Bit 7 (0x80) | Reserved | > +--------------+----------------------------------------------------+ > > Table 3: MPLS Connectivity Verification (CV) Types > > > **** > --e89a8ff1cdd606f40304e9974bfc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greg,

Thanks, much appreciated.

Cheers,
A= ndy


= On Fri, Oct 25, 2013 at 5:05 PM, Gregory Mirsky <gregory.mirsky@= ericsson.com> wrote:

Dear Andy,<= /span>

thank you for your commen= ts and suggestions. All are accepted and I=92ll make appropriate changes to= publish the next version as soon as gate gets open.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Regards,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg<= u>

=A0<= /p>

From: Andrew G= . Malis [mailto:amali= s@gmail.com]
Sent: Tuesday, October 22, 2013 1:32 PM
To: Gregory Mirsky
Cc: pwe3@ietf.org=
Subject: Shepherd's review of draft-ietf-pwe3-mpls-tp-cv-adv-01<= u>

=A0

Greg,

As document shepherd = for draft-ietf-pwe3-mpls-tp-cv-adv, I did a WG last call review and have so= me comments. The good news is that the draft is mostly in good shape for pu= blication, it just needs a quick revision to address the comments below. Also, there were no other WG last call comm= ents which need to be addressed.

First of all, there a= re some idnits issues that need to be addressed:

=A0 Miscellaneous warnings:<=
/u>
=A0 ----------------------------------=
------------------------------------------
=A0
=A0 =3D=3D The document doesn't us=
e any RFC 2119 keywords, yet seems to have RFC
=A0=A0=A0=A0 2119 boilerplate text.=

=A0
=A0 -- The document date (September 20=
, 2013) is 32 days in the past.=A0 Is this
=A0=A0=A0=A0 intentional?
=A0
=A0
=A0 Checking references for intended s=
tatus: Proposed Standard
=A0 ----------------------------------=
------------------------------------------
=A0
=A0=A0=A0=A0 (See RFCs 3967 and 4897 f=
or information about using normative references
=A0=A0=A0=A0 to lower-maturity documen=
ts in RFCs)
=A0
=A0 =3D=3D Unused Reference: 'RFC5=
882' is defined on line 270, but no explicit
=A0=A0=A0=A0 reference was found in th=
e text
=A0
=A0 -- Obsolete informational referenc=
e (is this intentional?): RFC 2434
=A0=A0=A0=A0 (Obsoleted by RFC 5226)

I also have some comm= ents of my own, which are mostly editorial in nature. They are embedded in = the text below. Just do an update to address the nits and these comments, a= nd I'll be able to forward the draft for publication.

Thanks,
Andy

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

1.=A0 I= ntroduction

=A0=A0 Proactive Connectivity Verification (CV), Continuity Check (CC), and=
=A0=A0 Remote Defect Indication (RDI) for the MPLS Transport Profile
=A0=A0 [RFC6428] are applicable to all constructs of the MPLS-TP, including=
=A0=A0 pseudowires (PWs).=A0 If Control Plane is used to operate and manage= PW
s/Control Plane/a control plane/
s/PW/PWs/
=A0=A0 then procedure defined in [RFC5085] and [RFC5885] should be used to<= br> s/procedure/the procedures/
=A0=A0 select proper type of Control Channel and corresponding type of
=A0=A0 Connectivity Verification.=A0 This document specifies how signaling = and
=A0=A0 selection process modified to ensure backward compatibility and allo= w
s/process modified/processes are modified/
=A0=A0 use of proactive CV-CC-RDI over MPLS-TP PWs.

1.1.=A0 Conventions used in this document

1.1.1.=A0 Terminology

=A0=A0 BFD: Bidirectional Forwarding Detection

=A0=A0 CC: Continuity Check

=A0=A0 CV: Connectivity Verification

=A0=A0 PE: Provider Edge

=A0=A0 VCCV: Virtual Circuit Connectivity Verification

=A0=A0 VCCV CC: VCCV Control Channel

1.1.2.=A0 Requirements Language

=A0=A0 The key words "MUST", "MUST NOT", "REQUIRED= ", "SHALL", "SHALL NOT",
=A0=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED",= "NOT RECOMMENDED", "MAY", and
=A0=A0 "OPTIONAL" in this document are to be interpreted as descr= ibed in
=A0=A0 [RFC2119].


2.=A0 MPLS-TP CC-CV on Pseudowires

=A0=A0 PW VCCV can support several CV Types.=A0 Ability to support arbitrar= y
s/Types.=A0 Ability to support/Types, and can support/
=A0=A0 combination of CV modes advertised in CV Types field of VCCV
s/in CV/in the CV/
=A0=A0 Interface Parameter sub-TLV [RFC4446], [RFC4447].=A0 Currently six =A0=A0 types of CV been defined for PW VCCV out of eight bit long field. s/VCCV out of eight bit long field/VCCV/
=A0=A0 This document introduces four new CV types and, to accommodate them,=
=A0=A0 a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV=
=A0=A0 is defined.






Mirsky=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires March = 24, 2014=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page 3]

Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VCCV MPLS-TP CV=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 September 2013


2.1.=A0 VCCV Extended CV Advertisement sub-TLV

=A0=A0 The format of VCCV Extended CV Advertisement is a TLV where:

=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3
=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =A0=A0=A0 | Type =3D 0x19 |=A0=A0=A0 Length=A0=A0=A0=A0 |=A0=A0 CV Type=A0= =A0=A0 |=A0=A0 Reserved=A0=A0=A0=A0 |
=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 1: VCCV Extended CV pa= rameter format

=A0=A0 Length - the length of the sub-TLV, including type and the Length s/Length -/The Length field is/
=A0=A0 field itself.=A0 Minimum length is 4.=A0 It it isrecommended that s/Minimum/The minimum/
=A0=A0 extensions to the sub-TLV be done in 4 bytes increments with Reserve= d
=A0=A0 field being set to zero on transmit and ignored on receipt.

=A0=A0 Reserved field must be set to zeroes on transmit and ignored on
=A0=A0 receive.
s/Reserved/The Reserved/

=A0=A0 CV Type field is a bitmask that lists types of CV monitoring that a<= br> s/CV Type/The CV Type/
=A0=A0 PE is capable to support.=A0 VCCV Extended CV parameter sub-TLV must=
s/VCCV/The VCCV/
=A0=A0 appear in combination with VCCV parameter sub-TLV.=A0 If VCCV parame= ter
s/VCCV/the VCCV/ (twice in this line)
=A0=A0 sub-TLV is missing then VCCV Extended CV parameter sub-TLV should be=
s/VCCV/the VCCV/
=A0=A0 ignored.

2.2.=A0 MPLS-TP CC-CV Types

=A0=A0 The [RFC6428] defines coordinated and independent modes of monitorin= g
S/The //
=A0=A0 point-to-point bi-directional connection that can be applied to
=A0=A0 monitoring PWs.=A0 At the same time [RFC6310] defines how BFD-based = OAM
=A0=A0 can map and be mapped to status of an Attachment Circuit.=A0 Thus th= ere
=A0=A0 could be four MPLS-TP CV types as combination of modes and
=A0=A0 functionality:

=A0=A0 +---------------+-------------------+-------------------------------= +
=A0=A0 |=A0=A0=A0=A0 Modes=A0=A0=A0=A0 |=A0 Fault Detection=A0 |=A0=A0 Faul= t Detection and Status=A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 O= nly=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Signalling=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |
=A0=A0 +---------------+-------------------+-------------------------------= +
=A0=A0 |=A0 Independent=A0 |=A0=A0=A0=A0=A0=A0=A0 0x01=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x02=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 |=A0=A0=A0=A0=A0 Mode=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 |=A0 Coordinated=A0 |=A0=A0=A0=A0=A0=A0=A0 0x04=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x08=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 |=A0=A0=A0=A0=A0 Mode=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 +---------------+-------------------+-------------------------------= +

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 1: Bitmask Values for MPLS= -TP CV Types





Mirsky=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires March = 24, 2014=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page 4]

Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VCCV MPLS-TP CV=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 September 2013


2.3.=A0 MPLS-TP CC-CV Type Operation

=A0=A0 Connectivity verification according to [RFC6428] is part of MPLS-TP<= br> =A0=A0 CC/CV operation that can be used with VCCV Control Channel Type 1 =A0=A0 [RFC5085] .=A0 If VCCV CC Type 1 selected, then PEs might select one= of
=A0=A0 MPLS-TP CC-CV types as VCCV CV mechanism to be used for this PW.

2.4.=A0 CV Type Selection

=A0=A0 CV selection rules that have been defined in Section 7 of [RFC5085]<= br> =A0=A0 and updated Section 4 of [RFC5885] are augmented in this document.
=A0=A0 If VCCV Control Channel Type 1 is chosen according to Section 7
=A0=A0 [RFC5085] and common set of proactive CV types advertized by both PE= s
=A0=A0 includes MPLS-TP CC-CV types and some BFD CV types, then MPLS-TP
=A0=A0 CC-CV takes precedence over any type of BFD CV.=A0 If multiple MPLS-= TP
=A0=A0 CV types advertised by both PEs, then following list sorted in
=A0=A0 descending priority order is used:

=A0=A0 1.=A0 0x08 - coordinated mode for PW Fault Detection and AC/PW Fault=
=A0=A0=A0=A0=A0=A0 Status Signaling

=A0=A0 2.=A0 0x04 - coordinated mode for PW Fault Detection only

=A0=A0 3.=A0 0x02 - independent mode for PW Fault Detection and AC/PW Fault=
=A0=A0=A0=A0=A0=A0 Status Signaling

=A0=A0 4.=A0 0x01 - independent mode for PW Fault Detection only


3.=A0 IANA Considerations

=A0=A0 The PW Interface Parameters Sub-TLV registry defined in [RFC4446]. s/registry defined/registry is defined/

=A0=A0 IANA is requested to reserve a new PW Interface Parameters Sub-TLV =A0=A0 type as follows:

=A0=A0 +-------------+--------+----------------------------+---------------= +
=A0=A0 |=A0 Parameter=A0 | Length |=A0=A0=A0=A0=A0=A0=A0=A0 Description=A0= =A0=A0=A0=A0=A0=A0 | Reference=A0=A0=A0=A0 |
=A0=A0 |=A0=A0=A0=A0=A0 ID=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0 +-------------+--------+----------------------------+---------------= +
=A0=A0 |=A0=A0=A0=A0 0x19=A0=A0=A0 | 4=A0=A0=A0=A0=A0 | VCCV Extended CV Pa= rameter | This document |
=A0=A0 +-------------+--------+----------------------------+---------------= +

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 2: New PW Interface Parame= ters Sub-TLV






Mirsky=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires March = 24, 2014=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page 5]

Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VCCV MPLS-TP CV=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 September 2013


3.1.=A0 VCCV Extended CV Types

=A0=A0 IANA is requested to set up a registry of ?VCCV Extended CV Types?.<= br> s/?// (twice)
=A0=A0 These are 8 bitfield values.=A0 Extended CV Type values 0x01, 0x02,<= br> s/bitfield/bit/
=A0=A0 0x04 and 0x08 are specified in Section 2.2 of this document.=A0 The<= br> =A0=A0 remaining bitfield values (0x10 through 0x80) are to be assigned by<= br> s/bitfield//
=A0=A0 IANA using the "IETF Consensus" policy defined in [RFC2434= ].=A0 A VCCV
=A0=A0 Extended Control Verification Type description and a reference to an=
=A0=A0 RFC approved by the IESG are required for any assignment from this =A0=A0 registry.

=A0=A0 +--------------+----------------------------------------------------= +
=A0=A0 |=A0 Bit(Value)=A0 | Description=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 +--------------+----------------------------------------------------= +
=A0=A0 | Bit 0 (0x01) | Independent mode for PW Fault Detection only=A0=A0= =A0=A0=A0=A0 |
=A0=A0 | Bit 1 (0x02) | Independent mode for PW Fault Detection and AC/PW= =A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Fault Status Signaling=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 | Bit 2 (0x04) | Coordinated mode for PW Fault Detection only=A0=A0= =A0=A0=A0=A0 |
=A0=A0 | Bit 3 (0x08) | Coordinated mode for PW Fault Detection and AC/PW= =A0 |
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Fault Status Signaling=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
=A0=A0 | Bit 4 (0x10) | Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
=A0=A0 | Bit 5 (0x20) | Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
=A0=A0 | Bit 6 (0x40) | Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
=A0=A0 | Bit 7 (0x80) | Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |
=A0=A0 +--------------+----------------------------------------------------= +

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3: MPLS Connectivity Verification (= CV) Types



--e89a8ff1cdd606f40304e9974bfc-- From amalis@gmail.com Mon Oct 28 10:56:39 2013 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 931E311E828E for ; Mon, 28 Oct 2013 10:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 1aKIwqb-lX5R for ; Mon, 28 Oct 2013 10:56:38 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 31DFF11E828D for ; Mon, 28 Oct 2013 10:56:37 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wn1so4044716obc.13 for ; Mon, 28 Oct 2013 10:56:34 -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:cc:content-type; bh=zMil7gRMpn0990JAW5D2dL2UiHtq4yyfjTlQilXuxmc=; b=RnzXYgXgtKmNxm3l/79BFSAC/UAzJ34IstY4DJ7N3tQKaCcXSV1K3valf3o09hLX9l WJBQHl/UQn5Blayir7RyaoQ5gCJM+4DYx+Vebsqr1SHXMR8pCgWd4uBSk3mXt8FxvYRo QCbLYA9Upv/znAhyXowBLsEl/dPeDicNQk5oNgQT+Acr3DYB2D094AoDDQawk5bhlPyS +9Klk4NWsywEp9iOLVN9ClmOLnCI9Og9MVL2aDT2giAIe8vhJkBhXXh1xgIPVCs/ELOj DSAcDPtStzCq6hT7jHaxg4+GqhXJJU6v0MKUKo5aJ+sZ6WtuCVwdRI/Do8CNl2MxjTeo C5Og== X-Received: by 10.60.60.105 with SMTP id g9mr15880655oer.8.1382982994784; Mon, 28 Oct 2013 10:56:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.182.9 with HTTP; Mon, 28 Oct 2013 10:56:01 -0700 (PDT) From: "Andrew G. Malis" Date: Mon, 28 Oct 2013 13:56:01 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=089e0149d0ae22783e04e9d0d243 Cc: Rahul Aggarwal Subject: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements 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, 28 Oct 2013 17:56:39 -0000 --089e0149d0ae22783e04e9d0d243 Content-Type: text/plain; charset=ISO-8859-1 PWE3ers, You may recall that almost exactly two years ago, we sent draft-ietf-pwe3-p2mp-pw-requirements-05 to the IESG. It was sent back to the WG in February of 2012, and it took a while, but we now have that rewrite to submit back to the IESG. However, because of the length of time, and the fact that -06 just came out about a week ago (so few people have had a chance to re-read it), we are going to have a second WG last call before sending it back to the IESG. So please review the draft, which you can find at https://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-06 . If you would like to see what's changed, you can easily see that here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-pwe3-p2mp-pw-requirements-06.txt. Coincidentally, we are also polling for knowledge of IPR that applies to this draft to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). To date, there have been no IPR declarations on this draft. If you are listed as a document author or contributor please respond to this email whether or not you are aware of any additional IPR. The draft will not be forwarded to the IESG until a response has been received from each author and contributor. See the list of contributing authors in Section 8 to refresh your memory. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Also, if you are listed as an author or contributor and your address info has changed, please email back privately so that we can get that updated before submitting it to the IESG. Because this last call spans the IETF meeting, it will be open for three weeks, ending on November 18. Thanks, Andy --089e0149d0ae22783e04e9d0d243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
PWE3ers,

You may recall t= hat almost exactly two years ago, we sent draft-ietf-pwe3-p2mp-pw-requireme= nts-05 to the IESG. It was sent back to the WG in February of 2012, and it = took a while, but we now have that rewrite to submit back to the IESG.

However, because of the length of time, and the fact that -06 jus= t came out about a week ago (so few people have had a chance to re-read it)= , we are going to have a second WG last call before sending it back to the = IESG.

So please review the draft, which you can find at https://to= ols.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-06 . If you woul= d like to see what's changed, you can easily see that here: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-p2mp-pw-requi= rements-06.txt .

Coincidentally, we are also polling for knowledge of IPR that
applies to this draft to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378
for = more details). To date, there have been no IPR declarations on this
draf= t.

If you are listed as a document author or contributor please respond
to this email whether or not you are aware of any additional IPR. The
draft will not be forwarded to the IESG until a response has been
received from each author and contributor. See the list of contributing
= authors in Section 8 to refresh your memory.

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

Also, if you are listed as an author or contributo= r and your address info has changed, please email back privately so that we= can get that updated before submitting it to the IESG.

Because this last call spans the IETF meeting, it will be op= en for three weeks, ending on November 18.

Thanks,
And= y

--089e0149d0ae22783e04e9d0d243-- From Frederic.Jounay@orange.ch Tue Oct 29 01:06:12 2013 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 68B6421F9F74 for ; Tue, 29 Oct 2013 01:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 NhOlcaJCy01r for ; Tue, 29 Oct 2013 01:06:06 -0700 (PDT) Received: from smtp10.eds.ch (smtp10.eds.ch [195.160.148.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2893F21F9DFA for ; Tue, 29 Oct 2013 01:05:53 -0700 (PDT) X-AuditID: c3a09427-b7ff56d000002edf-2b-526f6c5f2706 Received: from chbbochs054.orange.ch (Unknown_Domain [204.104.149.85]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by smtp10.eds.ch () with SMTP id EE.E0.11999.F5C6F625; Tue, 29 Oct 2013 09:05:51 +0100 (CET) Received: from CHCROCHC051.orange.ch ([fe80:0000:0000:0000:704b:3a68:12.14.247.83]) by chbbochs054.orange.ch ([172.25.9.54]) with mapi; Tue, 29 Oct 2013 09:05:50 +0100 From: =?iso-8859-1?Q?Jounay_Fr=E9d=E9ric?= To: "Andrew G. Malis" , "pwe3@ietf.org" Date: Tue, 29 Oct 2013 09:05:49 +0100 Thread-Topic: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements Thread-Index: Ac7UBy2czD0onTrMTg+4XO4HSWpLGQAdm83A Message-ID: <78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3@CHCROCHC051.orange.ch> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3CHCROCHC051_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsVyJmNqqG58Tn6Qwf0zQhb3ri5jt+j7tIXF YtGlK2wOzB47Z91l91iy5CeTx6xZh5kCmKO4bFJSczLLUov07RK4MnZOn8JYcNK5YtPv/6wN jPetuhg5OSQETCQ6jj9khrDFJC7cW88GYgsJNDNJTLqS2sXIBWSvZpRYc+EiC0iCTcBNYsmV qUwgtoiAp8THnh9gzcwCmhLdM76D1bAIqErcXXsQrEZYIFGiu/sQC0R9ksSOljbWLkYOINtI 4vGcAJAwr0CAxOl5+5kh9gZIPLo+H+wGToFAicN/u8BaGYFu+35qDRPEKnGJW0/mM0HcLCCx ZM95qPtFJV4+/scKUS8qcad9PSNEfb7Es+7PjBC7BCVOznzCMoFRdBaSUbOQlM1CUgYR15O4 MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2Vcx8hbnlhQYGuilphTrJWdsYgRG3OEFU9R3ME6/ YH6IUYCDUYmH9xFzfpAQa2JZcWXuIUYJDmYlEd4dwUAh3pTEyqrUovz4otKc1OJDjNIcLEri vAETVIOEBNITS1KzU1MLUotgskwcnFINjO6+hj8ql9ZP2GR7teBee6lNa/Kd5cfP2f0O+7To wZJ3F113Vnx0/em4qOplzXK1B1qfXJkjLb9cZIvnF3/TKrVWTj5yc+6iLz2LCnae7/xWPGHV 45BVdw+vnvfU9Fnx9lUxir33PDL/nqjhu8y8pe6cvoaFWu0Ge8sqWSHl7qOn+h2Snt+dxKXE UpyRaKjFXFScCACi2ymztAIAAA== Cc: Rahul Aggarwal Subject: Re: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 08:06:12 -0000 --_000_78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3CHCROCHC051_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm not aware of any patent related to this draft BR, Fred From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Monday, 28 October 2013 18:56 To: pwe3@ietf.org Cc: Rahul Aggarwal Subject: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp= -pw-requirements PWE3ers, You may recall that almost exactly two years ago, we sent draft-ietf-pwe3-p= 2mp-pw-requirements-05 to the IESG. It was sent back to the WG in February = of 2012, and it took a while, but we now have that rewrite to submit back t= o the IESG. However, because of the length of time, and the fact that -06 just came out= about a week ago (so few people have had a chance to re-read it), we are g= oing to have a second WG last call before sending it back to the IESG. So please review the draft, which you can find at https://tools.ietf.org/ht= ml/draft-ietf-pwe3-p2mp-pw-requirements-06 . If you would like to see what'= s changed, you can easily see that here: https://tools.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-pwe3-p2mp-pw-requirements-06.txt . Coincidentally, we are also polling for knowledge of IPR that applies to this draft to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). To date, there have been no IPR declarations on this draft. If you are listed as a document author or contributor please respond to this email whether or not you are aware of any additional IPR. The draft will not be forwarded to the IESG until a response has been received from each author and contributor. See the list of contributing authors in Section 8 to refresh your memory. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Also, if you are listed as an author or contributor and your address info h= as changed, please email back privately so that we can get that updated bef= ore submitting it to the IESG. Because this last call spans the IETF meeting, it will be open for three we= eks, ending on November 18. Thanks, Andy --_000_78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3CHCROCHC051_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I’m not aware of any patent related to this = draft

 

BR,

Fred

&n= bsp;

From: pwe= 3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Andre= w G. Malis
Sent: Monday, 28 October 2013 18:56
To: pwe3= @ietf.org
Cc: Rahul Aggarwal
Subject: [PWE3] Second WG = last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements

 

<= div>

PWE3ers,=

You may recal= l that almost exactly two years ago, we sent draft-ietf-pwe3-p2mp-pw-requir= ements-05 to the IESG. It was sent back to the WG in February of 2012, and = it took a while, but we now have that rewrite to submit back to the IESG.

Howe= ver, because of the length of time, and the fact that -06 just came out abo= ut a week ago (so few people have had a chance to re-read it), we are going= to have a second WG last call before sending it back to the IESG.

So please r= eview the draft, which you can find at https://tools.ietf.org/html/dra= ft-ietf-pwe3-p2mp-pw-requirements-06 . If you would like to see what's = changed, you can easily see that here: https://tools.iet= f.org/rfcdiff?url2=3Ddraft-ietf-pwe3-p2mp-pw-requirements-06.txt .
<= br>Coincidentally, we are also polling for knowledge of IPR that
applies= to this draft to ensure that IPR has been disclosed in
compliance with = IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378
for more details). T= o date, there have been no IPR declarations on this
draft.

If you= are listed as a document author or contributor please respond
to this e= mail whether or not you are aware of any additional IPR. The
draft will = not be forwarded to the IESG until a response has been
received from eac= h author and contributor. See the list of contributing
authors in Sectio= n 8 to refresh your memory.

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

Also, if you are listed as an author or contributor and your address inf= o has changed, please email back privately so that we can get that updated = before submitting it to the IESG.

 

Because this last call spans the IETF meeting, it will be ope= n for three weeks, ending on November 18.

Thanks,
Andy

<= /div>
= --_000_78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3CHCROCHC051_-- From giles.heron@gmail.com Tue Oct 29 04:24:58 2013 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 2562C11E8147 for ; Tue, 29 Oct 2013 04:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 OxuaWIlMmXVF for ; Tue, 29 Oct 2013 04:24:57 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 450D211E816B for ; Tue, 29 Oct 2013 04:24:55 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so5216992eek.15 for ; Tue, 29 Oct 2013 04:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3WdHEHoGkfLB11ulq5NoGLqTJvCT861hbBKHGVgCWJk=; b=WoWSGqQWbNt1P/Cw7mfDpLzWka5JaSSwwOW61VemSjXxuOpRd9qPekqKv1PwVCVa39 ofawFtaWhg7rtQ2ZYPplbtzwCJcLuhFK2yMp/SMzMCqUf7h9NoJSTX/twilRaxsSaxZ2 BV5Ip3MNBkDDHeLuyX/TWy6hj6giNLmIAglNZY768kRPjd1K57DqqbXMxXWGs4p99Vq1 c3t5n9GCEiZ4VBobFwgxL21MWvcJgYx/LHg2AHPSHdWCKYT8MMckxXnctCX/BeWND3f8 F1H2Qkt10mhJ1Jpcuazd5TOecpkcciq++nxq2OrndKknScvfhr417NQzikO+iNQkWhTG 9w5g== X-Received: by 10.15.76.65 with SMTP id m41mr2150414eey.94.1383045895104; Tue, 29 Oct 2013 04:24:55 -0700 (PDT) Received: from ?IPv6:2001:420:4082:1252:757b:cd0c:3244:12bd? ([2001:420:4082:1252:757b:cd0c:3244:12bd]) by mx.google.com with ESMTPSA id h45sm69136627eeg.5.2013.10.29.04.24.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 04:24:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Giles Heron In-Reply-To: <78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3@CHCROCHC051.orange.ch> Date: Tue, 29 Oct 2013 11:24:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78046FD1C8FE0345AFBC11640A8DF6E201840B3D8DB3@CHCROCHC051.orange.ch> To: =?windows-1252?Q?Jounay_Fr=E9d=E9ric?= X-Mailer: Apple Mail (2.1510) Cc: Rahul Aggarwal , "pwe3@ietf.org" Subject: Re: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 11:24:58 -0000 Likewise - I'm not aware of any IPR related to this draft. On 29 Oct 2013, at 08:05, Jounay Fr=E9d=E9ric = wrote: > Hi, > =20 > I=92m not aware of any patent related to this draft > =20 > BR, > Fred > =20 > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Andrew G. Malis > Sent: Monday, 28 October 2013 18:56 > To: pwe3@ietf.org > Cc: Rahul Aggarwal > Subject: [PWE3] Second WG last call (and IPR call) for = draft-ietf-pwe3-p2mp-pw-requirements > =20 > PWE3ers, >=20 > You may recall that almost exactly two years ago, we sent = draft-ietf-pwe3-p2mp-pw-requirements-05 to the IESG. It was sent back to = the WG in February of 2012, and it took a while, but we now have that = rewrite to submit back to the IESG. >=20 > However, because of the length of time, and the fact that -06 just = came out about a week ago (so few people have had a chance to re-read = it), we are going to have a second WG last call before sending it back = to the IESG. >=20 > So please review the draft, which you can find at = https://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-06 . If = you would like to see what's changed, you can easily see that = here:https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-p2mp-pw-require= ments-06.txt . >=20 > Coincidentally, we are also polling for knowledge of IPR that > applies to this draft to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378=20 > for more details). To date, there have been no IPR declarations on = this > draft. >=20 > If you are listed as a document author or contributor please respond > to this email whether or not you are aware of any additional IPR. The > draft will not be forwarded to the IESG until a response has been > received from each author and contributor. See the list of = contributing > authors in Section 8 to refresh your memory. >=20 > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. >=20 > Also, if you are listed as an author or contributor and your address = info has changed, please email back privately so that we can get that = updated before submitting it to the IESG. > =20 > Because this last call spans the IETF meeting, it will be open for = three weeks, ending on November 18. >=20 > Thanks, > Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From matthew.bocci@alcatel-lucent.com Tue Oct 29 13:17:29 2013 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 269BB11E80E9 for ; Tue, 29 Oct 2013 13:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.118 X-Spam-Level: X-Spam-Status: No, score=-110.118 tagged_above=-999 required=5 tests=[AWL=0.480, 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 BEVmCri58lSF for ; Tue, 29 Oct 2013 13:17:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 76C5121F9A65 for ; Tue, 29 Oct 2013 13:17:20 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9TKHFKC002382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Oct 2013 15:17:16 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9TKHC0H011887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 21:17:12 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.189]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 29 Oct 2013 21:17:12 +0100 From: "Bocci, Matthew (Matthew)" To: "Andrew G. Malis" , "pwe3@ietf.org" Thread-Topic: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements Thread-Index: AQHO1OPZjJURD8nYB0WgmtrS6O8yKQ== Date: Tue, 29 Oct 2013 20:17:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_CE95C7C854983matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Rahul Aggarwal Subject: Re: [PWE3] Second WG last call (and IPR call) for draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:17:30 -0000 --_000_CE95C7C854983matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, I am not aware of any IPR. Matthew On 28/10/2013 17:56, "Andrew G. Malis" > wrote: PWE3ers, You may recall that almost exactly two years ago, we sent draft-ietf-pwe3-p= 2mp-pw-requirements-05 to the IESG. It was sent back to the WG in February = of 2012, and it took a while, but we now have that rewrite to submit back t= o the IESG. However, because of the length of time, and the fact that -06 just came out= about a week ago (so few people have had a chance to re-read it), we are g= oing to have a second WG last call before sending it back to the IESG. So please review the draft, which you can find at https://tools.ietf.org/ht= ml/draft-ietf-pwe3-p2mp-pw-requirements-06 . If you would like to see what'= s changed, you can easily see that here: https://tools.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-pwe3-p2mp-pw-requirements-06.txt . Coincidentally, we are also polling for knowledge of IPR that applies to this draft to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). To date, there have been no IPR declarations on this draft. If you are listed as a document author or contributor please respond to this email whether or not you are aware of any additional IPR. The draft will not be forwarded to the IESG until a response has been received from each author and contributor. See the list of contributing authors in Section 8 to refresh your memory. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Also, if you are listed as an author or contributor and your address info h= as changed, please email back privately so that we can get that updated bef= ore submitting it to the IESG. Because this last call spans the IETF meeting, it will be open for three we= eks, ending on November 18. Thanks, Andy --_000_CE95C7C854983matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Andy,

I am not aware of any IPR.

Matthew

On 28/10/2013 17:56, "Andrew G. Malis" <amalis@gmail.com> wrote:

PWE3ers,

You may recall that almost exactly two years ago, we sent draft-ietf-pwe3-p= 2mp-pw-requirements-05 to the IESG. It was sent back to the WG in February = of 2012, and it took a while, but we now have that rewrite to submit back t= o the IESG.

However, because of the length of time, and the fact that -06 just came out= about a week ago (so few people have had a chance to re-read it), we are g= oing to have a second WG last call before sending it back to the IESG.

So please review the draft, which you can find at https://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-06 . I= f you would like to see what's changed, you can easily see that here: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-p2mp-pw-requirements-= 06.txt .

Coincidentally, we are also polling for knowledge of IPR that
applies to this draft to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378
for more details). To date, there have been no IPR declarations on this
draft.

If you are listed as a document author or contributor please respond
to this email whether or not you are aware of any additional IPR. The
draft will not be forwarded to the IESG until a response has been
received from each author and contributor. See the list of contributing
authors in Section 8 to refresh your memory.

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

Also, if you are listed as an author or contributor and your address i= nfo has changed, please email back privately so that we can get that update= d before submitting it to the IESG.

Because this last call spans the IETF meeting, it will be open for thr= ee weeks, ending on November 18.

Thanks,
Andy

 --_000_CE95C7C854983matthewboccialcatellucentcom_-- From stbryant@cisco.com Wed Oct 30 07:19:36 2013 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 E488D11E822F for ; Wed, 30 Oct 2013 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 qBrP0cD2IY3V for ; Wed, 30 Oct 2013 07:19:31 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E3EA621F9ECA for ; Wed, 30 Oct 2013 07:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2910; q=dns/txt; s=iport; t=1383142761; x=1384352361; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=ql+ZIaD8M1b3TFxDSx+9O9b2pM1JyNVmLsY8M5kEJC8=; b=TT1vw04BeVXgENvNvzdArNmVuedqxZtz05LvfXNPw5mdq7tE6wlVawPz OvU1u1a3LYPQWRi4kZpz7ItdnSUUoMQXHgctA0NHmwRyyWNuiPhOL9OwS vCWVJI5wXe98hrQKemCU2rjLCk5DV6OzN4GZDDn/4lX75UlbU7Nhn2NuJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAH8UcVKQ/khM/2dsb2JhbABZgwfBfxZ0gmRAPRYYAwIBAgFLAQwIAQGIA6AVmmKUAgOUKoNgkgmDJg X-IronPort-AV: E=Sophos;i="4.93,601,1378857600"; d="scan'208";a="19127855" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 30 Oct 2013 14:19:19 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9UEJEO0009730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 14:19:15 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9UEJDAi011434; Wed, 30 Oct 2013 14:19:13 GMT Message-ID: <52711561.1090209@cisco.com> Date: Wed, 30 Oct 2013 14:19:13 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: pwe3 , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] AD comments on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 14:19:37 -0000 I am about to put this into IETF LC. Please consider the following as LC comments. - Stewart Network Working Group Luca Martini (Ed.) Internet Draft Cisco Systems Inc. Expires: April 2014 Intended status: Standards Track Matthew Bocci (Ed.) Updates: 6073 Florin Balus (Ed.) Alcatel-Lucent October 8, 2013 Dynamic Placement of Multi-Segment Pseudowires draft-ietf-pwe3-dynamic-ms-pw-19.txt SB> it updates the length value of the PW Switching Point PE Sub-TLV Type 0x06 to 14. SB> It is confusing to talk about the "length value" of a TLV. I think you SB> mean "length" 2.1. Changes to Existing PW Signaling This document also updates the length value of the PW Switching Point PE Sub-TLV Type 0x06 to 14. SB> Same comment as above 4.2. LDP Signaling The complete definitions of the content of the SENDER_TSPEC objects are found in [TSPEC] section 3.1. SB> TSPEC is actually RFC2210 isn't it? SB> If so that would be a much better reference identifier 4.2.1. Equal Cost Multi Path (ECMP) in PW Routing A next hop selection for a specific PW may find a match with a PW route that has multiple next hops associated with it. Multiple next hops may be either configured explicitly as static routes or may be learned through BGP routing procedures. Implementations at and S-PE SB> s/and/an/ or T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV, for load balancing of PWs across multiple next-hops. The details of such selection algorithms are outside the scope of this document. SB> Presumable FAT is another option? 4.2.2. Active/Passive T-PE Election Procedure The determination of which T-PE assumes the active role SHOULD be done as follows: the Source Attachment Individual Identifier (SAII) and TAII are compared as unsigned integers, if the SAII is bigger then the T-PE assumes the active role. SB> This does not look quite precise enough. You need to specify which bytes SB> and the bit order. What you say is technically correct SB> but isn't it clearer to say that the T-PE with the larger SB> SAII is active? SB> I do not see (pointer to) a definition of SAII or TAII in this draft 6. Operations and Maintenance (OAM) In this case, the following TLV type (0x06) MUST be used in place of type 0x01 in the PW switching point TLV: SB> This is "PW Switching Point PE sub-TLV" in RFC6073 SB> SB> Are there any interoperability issues with the change of length to SB> 14, i.e. is there any length 12 code in the wild? From iesg-secretary@ietf.org Wed Oct 30 07:24:15 2013 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 5586311E8180; Wed, 30 Oct 2013 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, 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 ZFfYu4uo6Ss5; Wed, 30 Oct 2013 07:24:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FDE11E8233; Wed, 30 Oct 2013 07:24:06 -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.81 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131030142406.6933.20282.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 07:24:06 -0700 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Dynamic Placement of Multi-Segment Pseudowires) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 14:24:15 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Dynamic Placement of Multi-Segment Pseudowires' as 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 2013-11-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There is a requirement for service providers to be able to extend the reach of pseudowires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC6073 as follows: it updates the length value of the PW Switching Point PE Sub-TLV Type 0x06 to 14. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2176/ http://datatracker.ietf.org/ipr/1810/ http://datatracker.ietf.org/ipr/1885/ http://datatracker.ietf.org/ipr/998/ http://datatracker.ietf.org/ipr/1879/