From nobody Tue Jul 8 04:55:19 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E811B2A58 for ; Tue, 8 Jul 2014 04:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMlq8tlQ3yVo for ; Tue, 8 Jul 2014 04:55:14 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD011B2A29 for ; Tue, 8 Jul 2014 04:55:13 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so736628qap.4 for ; Tue, 08 Jul 2014 04:55:13 -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=FDi6y2JaBYQfzCvCPpJeaDZXveQlPo6BLnMq1cMO5bs=; b=I6HG/ieb45/tgxjrVHVGlaOorXslg6eb2ngaGZdgdCIwv5DTBTpQCwjF2MTUtzfDAn cVse20cQgkdhmIxhRqU6YqvGAXWpx5tbNmmIYsszHiE79AdPxZf1PK+43FVMGiJJplYk G1h01fRNT0CrNVnhY9/4nmwCEope4MjyMLxRrBt1KQSfNxTa69GYBfQysVPJeSYBeeV4 8TWbderegOzfK9DpEgODFpjMVRdT2Z9Chq227QtcN49hexx6BuO9TDxiQivxH0rTilZr I7uXUYWUZ9eZl41+rw59QvLK2a/gXh5C9ABEryX9H+wfaqt37P9EmoS401i5J5U1I407 /oSg== X-Received: by 10.140.98.35 with SMTP id n32mr56858055qge.111.1404820513192; Tue, 08 Jul 2014 04:55:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.47.150 with HTTP; Tue, 8 Jul 2014 04:54:53 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 8 Jul 2014 07:54:53 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a113aad84a97fbf04fdad4326 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/gjclvoFKdPf9bgw7wEYkp5w_bZ4 Subject: [PWE3] Fwd: PWE3 IETF 90 Slot Requests - Toronto X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 11:55:15 -0000 --001a113aad84a97fbf04fdad4326 Content-Type: text/plain; charset=UTF-8 PWE3ers, The agenda is now final, and our meeting is at 17:30-18:30 on Thursday. As always, please send agenda requests to david.sinicrope@ericsson.com, see below for details. Thanks, Andy ---------- Forwarded message ---------- From: David Sinicrope Date: Mon, Jun 23, 2014 at 1:29 PM Subject: [PWE3] PWE3 IETF 90 Slot Requests - Toronto To: "IETF.PWE3" Hi All, It's that time again. If you need a presentation slot for the IETF 90 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 resolved via the presentation during the meeting (e.g., need to address security issues and get direction from the WG): - requested duration (norm is 10 min): - speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --001a113aad84a97fbf04fdad4326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PWE3ers,

The agenda is now final, and o= ur meeting is at 17:30-18:30 on Thursday. As always, please send agenda req= uests to=C2=A0david.sinicro= pe@ericsson.com, see below for details.

Thanks,
Andy

---------- Forwarded message ----------
From: David Sinicrope <david.sinicrope@ericsson.com>
Date: Mon, Jun 23, 2014 at 1:29 PM
Subject: [PWE3] PWE3 IETF 90 Slot Req= uests - Toronto
To: "IETF.PWE3" <pwe3@ietf.org>

Hi All,
It's that time again. =C2=A0

If you need a presentation slot for the IETF 90 PWE3 session, please r= eply to this email (subject intact) completing the form below:

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

Thanks!
Dave

--001a113aad84a97fbf04fdad4326-- From nobody Fri Jul 11 02:09:50 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514571A0B17 for ; Fri, 11 Jul 2014 02:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acCu0LgZlddb for ; Fri, 11 Jul 2014 02:09:48 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCACC1A0453 for ; Fri, 11 Jul 2014 02:09:47 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so999468wib.1 for ; Fri, 11 Jul 2014 02:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=U7Ek/ewoLh1qeAe52NAo0ZPutp4N1UUy+ktGXNqJFGY=; b=1E4g0UR1UveMaLd0zqUay3ABTzlWKMsP6BlhzJmWCo4osaXDClAbWfDraSNkwDNEC5 d6E5jJJuakogJ51atDcWEWmQgPgIyynnNLskNQ/8k/dofdKg2PCsoUpCcPDWFqOC4aR7 tMxAx3MGMD+1+qcdQzLBwKbRIU3asqbH10JFrA2emQAQcWebXg+6Eoo1Wq80BdV1z8p0 df/8VK+OmPE7eKLdrOrYGJvvXW0rOatuGI00uCBshbz4rvfTfgwkIQSiF5jyteVO5mjI v7qdnSSCw7xqY+5L0BaUyLnIXer/3BYvDMhE8Z2QXxkt1bTa4NSxOxUB9uYk6jHzuRpe o3LQ== X-Received: by 10.180.126.9 with SMTP id mu9mr3152111wib.69.1405069783852; Fri, 11 Jul 2014 02:09:43 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id au7sm3856904wjc.41.2014.07.11.02.09.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 02:09:43 -0700 (PDT) Message-ID: <53BFA9D3.20800@gmail.com> Date: Fri, 11 Jul 2014 11:09:39 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pwe3 References: <20140701170314.8591.2298.idtracker@ietfa.amsl.com> In-Reply-To: <20140701170314.8591.2298.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/i9NbP9XJUgn8feJ1FGixUE4hcOQ Subject: Re: [PWE3] I-D Action: draft-shawam-pwe3-ms-pw-protection-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 09:09:49 -0000 All, After publication of RFC6378 and RFC7271 The ITU-T has approved recommendation G.8131 based on these RFCs. However, during the drafting of this recommendation operators expressed their concern that this recommendation only applies to LSPs, and not to PWs, in particular MS-PWs. To address their concern we started working on this draft. When it becomes an RFC it will be used to extend G.8131 to include PWs. Cheers, Huub. ============= On 01-07-14 19:03, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Encapsulation for PSC for Multi-Segment Pseudowires > Authors : Huub van Helvoort > Loa Andersson > Andrew G. Malis > Jongyoon Shin > Lei Wang > Alessandro D'Alessandro > Filename : draft-shawam-pwe3-ms-pw-protection-00.txt > Pages : 4 > Date : 2014-07-01 > > Abstract: > In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection', as > well as in the later updates of this RFC, the Protection State > Coordiantion (PSC) protocol was defined for MPLS LSPs only. This > draft extends RFC 6378 to be applicable for pseudowires as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-00 > > > 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/ > > _______________________________________________ > 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 nobody Fri Jul 11 05:51:50 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199E71B2878 for ; Fri, 11 Jul 2014 05:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4h38LIxpurg for ; Fri, 11 Jul 2014 05:51:45 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404EA1A0AAE for ; Fri, 11 Jul 2014 05:51:44 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6BCpfKT004131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jul 2014 07:51:43 -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 s6BCpfDa008025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 14:51:41 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 11 Jul 2014 14:51:41 +0200 From: "Bocci, Matthew (Matthew)" To: "adrian@olddog.co.uk" , "draft-ietf-pwe3-mspw-er.all@tools.ietf.org" Thread-Topic: AD review of draft-ietf-pwe3-mspw-er Thread-Index: Ac+Fv2l5OVX70rFXTR6Kuhl0xMjYsAXPw9cA Date: Fri, 11 Jul 2014 12:51:40 +0000 Message-ID: References: <01dc01cf85bf$6c8ad7c0$45a08740$@olddog.co.uk> In-Reply-To: <01dc01cf85bf$6c8ad7c0$45a08740$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Nh398ZG2IscstWHZQ0WYU8nu_tk Cc: "pwe3@ietf.org" Subject: Re: [PWE3] AD review of draft-ietf-pwe3-mspw-er X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:51:48 -0000 Hi Adrian, Thanks very much for your detailed review. I=B9ve replied to your comments in-line below, and will revise the draft to incorporate the required changes, shortly. Best regards Matthew On 11/06/2014 22:52, "Adrian Farrel" wrote: Authors, Thanks for your work on this document. I have conducted my normal AD review having received the publication request. The purpose of the review is to find issues and concerns that improve the quality of the document for readability and implementation, and to remove issues that might otherwise get found during IETF last call, directorate reviews, and IESG evaluation. I think that in general this document is fine, but I think it needs some work on clarity. Hopefully none of my points is contentious, and they can all be handled through some fairly simple edits. of course, every point is open for discussion and you can refute each and every one of them. I'll put the document into "Revised I-D Needed" state and wait to see an update and/or email from you. Thanks, Adrian =3D=3D=3D On a copyright thing... Are you sure that some of this material hadn't been lifted pretty much unchanged from RFC 3212? You might at least acknowledge that in the Acknowledgements section. MB> Agreed. I propose adding the following text to the acknowledgements section as well as adding a reference to RFC3212 in section 4.2. "The authors of this document gratefully acknowledge the contribution of the=20 RFC3212 authors though the specification of TLVs, which are reused by this document." --- Section 1 For 1:1 protection of MS-PWs with primary and backup paths, MS-PWs SHOULD be established through a diverse set of S-PEs (Switching Provider-Edge) nodes to avoid any single points of failure at PW level. I think s/SHOULD be/need to be/ The points are: - This is really not a case for RFC 2119 language - "should" is not really good enough for proper 1:1 protection MB> I agree --- Do you not think that the Introduction should discuss a little about how the path might be known? Specifically how the head-end T-PE knows what explicit route to use. It may be enough to say "In many deployments the head-end T-PE will not have a view of the topology of S-PEs and so the explicit route will need to be supplied from a management application. How that management application determines the explicit route is outside the scope of this document." MB> Agreed. I'll add that statement to the introduction. --- Section 1 This draft proposes an additional mechanism Don't say "draft" say "document" because you want this text in an RFC. Don't "propose", "define" or "specify" because you want this in a protocol specification. MB> Agreed --- Section 3.1 needs to discuss how uniqueness of "S-PE addresses" is guaranteed/arranged. MB> Actually, this section is simply a duplication of RFC7267, Section 3.2. This is a=20 result of this draft being forked from draft-ietf-pwe3-dynamic-ms-pw. While I agree with your comments below on this section, we could just rephrase the section in this draft as follows and raise an errata to clarify any points in RFC7267, as follows: "An S-PE Address is an address used to identify a given S-PE among the set of S-PEs=20 belonging to the PSNs that may be used by an MS-PW. Each S-PE MUST be assigned an address as specified in [RFC6267] Section 3.2. An S-PE that is capable of dynamic MS-PW signaling but that has not been assigned an S-PE address and receives a Label Mapping message=20 for a dynamic MS-PW MUST follow the procedures of [RFC7276] Section 3.2." I suggest you formally define the term "S-PE address" What does "format similar to" actually mean? --- Section 3.1 If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned with an S-PE address, then on receiving a Dynamic MS-PW label mapping message the S-PE MUST return a label release with the "Resources Unavailable" ( 0x00000038)" status code. It is not clear to me whether this is new normative behavior or a restatement of draft-ietf-pwe3-dynamic-ms-pw. This isn't helped by the fact that "Dynamic MS-PW label mapping message" seems to be a new term. You should probably define the term explicitly somehow with reference to what it contains that makes it such a message (not just an ordinary label mapping message) and a reference to draft-ietf-pwe3-dynamic-ms-pw. Then you need to help clarify if this is new behavior. If it is not, then you can include "As described in [ref]..." If it *is* new behavior for an existing message you have to explain how this is backward compatible with current processing of this message. If it is new behavior for a *new* message (i.e. defined in this document) then the text is very out of order and at the least you need some explanation of where this message is defined and what it does. MB> Agreed. It should be aligned with RFC7267. Please see the proposal above. --- Section 3 might usefully say some overview stuff like: - An explicitly routed PW is set up using a Label Mapping message that carries an ordered list of the S-PEs through which the PW is expected to run. - The ordered list is encoded as a series of ER Hop TLVs encoded in a ER TLV that is carried in the Label Mapping message. Doing this would save the reader ploughing through section 3 trying to work out what it is all about. MB> Agreed. I will add an introductory paragraph based on your text. --- If the ER Hop TLV can contain an IP address identifying an abstract node, why is it necessary for each S-PE to have a unique S-PE address formed as an AII? MB>=20 --- Section 3.2 Length Specifies the length of the value field in bytes. There is, of course, no "value" field, so you could be a little clearer. Unfortunately, there is currently a theme in the IESG on multi-byte integer fields that means you need to say how the integer is encoded on the wire, so you need to add "encoded in line format". BUT... Wait a minute. You are re-using 0x0800 for the ER TLV. Good. We don't need to define multiple TLVs for the same function. But why are you writing this document as though you are defining the TLV? Why is there no mention of RFC 3212? The same questions apply to the ER Hop TLV and the two of its types that you are re-using. This wouldn't take a lot of text and would allow you to delete a fair bit. Something along the lines of... The process defined in this document makes use of the ER TLV defined in [RFC3212]. This TLV can be placed in a Label Mapping message used for dynamic PW setup as described in Section 4. =20 The ER TLV contains one or more ER Hop TLVs, each describing a hop along the desired path or the PW. The procedures described in this document allow for the use of the "IPv4 Prefix ER-Hop TLV" and the "IPv6 Prefix ER-Hop TLV" (both defined in [RFC3212]) and also the "L2 PW address of PW Switching Point" defined in this document. MB> RFC3212 references were originally included in the text from draft-ietf-dynamic-ms-pw (see Version 13), but these were removed due to some comments around last call time that=20 we were tying the fate of this draft to the future fate of RFC3212. Personally, I am=20 OK with reinstating the references as you propose. --- Curiously, in 3.4.1 you have IP Address A four-byte field indicating the IP Address. while in 3.4.2 you have IPv6 address A 128-bit unicast host addresses. It makes one wonder. This issue would disappear with the fix previously mentioned. MB> OK --- For both the IPv4 and IPv6 hops, I think you need to think about (and document) whether you support less than fully specified IP addresses. For both of the prefix lengths you appear to allow 1-n (n =3D 32 or 128) yet for IPv6 you seem to say it is a unicast host address which would preclude anything other than 128. MB> It does seem that way, although that's also how RFC3212 defines it. I will discuss with the other authors and make a proposal. --- 3.4.3 needs some work... The section title says "ER-Hop 3: L2 PW Address" but while this may be the third ER-Hop type you support in this usage, the hop type is actually 5. I suggest you remove the numbers from all three subsection titles. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0802 | Length =3D 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value you have used in 0x0805. But (of course) you should use TBD1 and reflect that in the IANA section. MB> Agreed |L| Reserved | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=3D02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Having to fields called "Length" makes the documentation ambiguous. Suggest you make the first one "TLV-Length" | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U/F These bits MUST be set to zero and the procedures of [RFC5036] followed when the TLV is not known to the receiving node. Type A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW Address, Type =3D 0x0805 Length Specifies the length of the value field in bytes =3D 18. L Bit Set to indicate Loose hop. Cleared to indicate a strict hop. PreLen Prefix Length 1-96 It is slightly curious that RFC 5003 didn't find a need for indicating the prefix length. Since it is (presumably!) your intention that the count to 96 spans the Global ID, Prefix, and AC ID fields, I think you need to make that clear here and describe its usage later. Otherwise one would rationally assume that the prefix length applies to the prefix field. MB> Agreed. I will follow up with the co-authors to clarify and propose some revised text.=20 L2 PW Address An AII Address as defined in [RFC5003]. Rather than say this (which is confusing because there is no such L2 PW Address field) you should say "All other fields (AII Type, Length, Global ID, Prefix, and AC ID) define the L2 PW Address and are to be set and interpreted as defined in Section 3.2 of [RFC5003]." MB> agreed --- 4.1 A PW Label Mapping Message containing an explicit route TLV MUST specify the next hop for a given MS-PW path. What do you mean "MUST"? Surely... A PW Label Mapping Message containing an Explicit Route TLV specifies the next hop for a given MS-PW path. MB> agreed --- 4.1 Selection of this next hop MAY involve a selection from a set of possible alternatives. s/MAY/may/ MB> OK --- 4.1 The mechanism used to select a particular path is also outside of the scope of this document, but each node MUST attempt to determine a loop-free path. Note that such mechanisms MAY be overridden by local policy. This is ambiguous... "MUST attempt" but if it can't find one it is OK to go ahead with a loop? Local policy may override attempting to find a loop-free path? Local policy may override the mechanism to select a path (which is a local policy on account of not being part of this document)? What information does an S-PE have available to select path and determine whether there is a loop? What should an S-PE do if a path can't be selected without a loop? MB> I agree there are some procedures missing here. For a T-PE, if a loop free path cannot be found, then it must not attempt to signal the MS-PW. For an S-PE, if it cannot determine a loop free path, then the received Label Mapping MUST be released with a=20 status code of "PW Loop Detected" as per Section 4.2.3 of RFC7267. I'll discuss with the=20 authors and propose some text below. =20 --- 4.1 1. The node receiving the Label Mapping Message must evaluate the first ER-Hop. This one should be "MUST", but you also need to qualify with "...that contains an ER TLV." MB> agreed --- 4.1 If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. And how will it make that determination? MB> This is the same as RFC3212, where a specific node determines if it is a member of=20 an abstract node if its address lies within the prefix (as determined but the prefix=20 length) specified in the ER-Hop TLV. --- 4.1 If there is no first ER-Hop, the message is also in error and the node should return a "Bad Explicit Routing TLV Error" (0x04000001) status code in a Label Release Message sent to upstream node. I presume this means if there is an ER TLV that does not contain an ER Hop TLV. MB> YEs I presume it remains legal to have a Label Mapping message without an ER TLV per point 2 of this section. MB> Yes Perhaps you could clarify this. MB> I'll clarify in the next version of the draft. --- Section 5 This draft proposes one new TLV type: TLV Type Suggested Value Reference ------------------------------------ --------------- --------- L2 PW Address of Switching Point 0x0805 This Document I think this needs to read... IANA is requested to assign a further code point from the IETF Consensus portion of this registry as follows: TLV Type Value Reference ------------------------------------ ------- --------- L2 PW Address of Switching Point TBD1 This Document A value of 0x0805 is requested. MB> Agreed. From nobody Mon Jul 14 03:20:09 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF551A038B for ; Mon, 14 Jul 2014 03:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBWYdue7YGdC for ; Mon, 14 Jul 2014 03:20:06 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FF51A0389 for ; Mon, 14 Jul 2014 03:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2616; q=dns/txt; s=iport; t=1405333206; x=1406542806; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=fd9DFFNjyciCM2c+1jiyWH59iY5Y/S44liCPY89Vlas=; b=OwbrDlE4YcImRFjOD34phSGMyQdi0pUfTiQ1I5epplkn+4uzZ3iMULBT 9EZTLB9qV9tKbWE07jaBbZDzLhWYprv8K+OGlVId+TydJ/NEVwFFvIneN 7EZfLHjNz8BqbmEOVfNAeEf/k2+SPg02MvXpI254bMufcYVopIAzag/TW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAO2tw1OtJssW/2dsb2JhbABZg2CDS75MCodDAYEudYQEAQEEAQEBIBU2ChELGAICBRYLAgIJAwIBAgEVMAYBDAYCAQEFiDkNr1WGf5BVF4EsjWw6gneBTAWbDoFKhUiGeIYTg0Vr X-IronPort-AV: E=Sophos;i="5.01,657,1400025600"; d="scan'208";a="110397254" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 14 Jul 2014 10:20:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6EAK0ke020138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 10:20:01 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6EAJxt8003389; Mon, 14 Jul 2014 11:19:59 +0100 (BST) Message-ID: <53C3AECF.1000802@cisco.com> Date: Mon, 14 Jul 2014 11:19:59 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: huubatwork@gmail.com, pwe3 References: <20140701170314.8591.2298.idtracker@ietfa.amsl.com> <53BFA9D3.20800@gmail.com> In-Reply-To: <53BFA9D3.20800@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/92FZiLpnXNg7LQmefi1QHw118yk Subject: Re: [PWE3] I-D Action: draft-shawam-pwe3-ms-pw-protection-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Jul 2014 10:20:07 -0000 Huub, This is going to need quite a lot more detail, both in terms of specific updates to RFC6378/7271 and in terms of operation in the PW context. Stewart On 11/07/2014 10:09, Huub van Helvoort wrote: > All, > > After publication of RFC6378 and RFC7271 The ITU-T has approved > recommendation G.8131 based on these RFCs. > > However, during the drafting of this recommendation operators > expressed their concern that this recommendation only applies > to LSPs, and not to PWs, in particular MS-PWs. > > To address their concern we started working on this draft. > When it becomes an RFC it will be used to extend G.8131 to > include PWs. > > Cheers, Huub. > > ============= > > On 01-07-14 19:03, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Encapsulation for PSC for Multi-Segment >> Pseudowires >> Authors : Huub van Helvoort >> Loa Andersson >> Andrew G. Malis >> Jongyoon Shin >> Lei Wang >> Alessandro D'Alessandro >> Filename : draft-shawam-pwe3-ms-pw-protection-00.txt >> Pages : 4 >> Date : 2014-07-01 >> >> Abstract: >> In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection', as >> well as in the later updates of this RFC, the Protection State >> Coordiantion (PSC) protocol was defined for MPLS LSPs only. This >> draft extends RFC 6378 to be applicable for pseudowires as well. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-00 >> >> >> 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/ >> >> _______________________________________________ >> 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 >> > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Mon Jul 14 07:50:10 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266321A08EC for ; Mon, 14 Jul 2014 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb6uAIwV66cV for ; Mon, 14 Jul 2014 07:50:06 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158511A0659 for ; Mon, 14 Jul 2014 07:50:06 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so3344411qac.12 for ; Mon, 14 Jul 2014 07:50:05 -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=H394pYy889dIPKhyfb9km3vksRUPxNxiETBef6WTCCw=; b=s5Dugyrvyy4ujKVgCl1x3WeYa/6hteZS62jfZzHr/rW6xQ5g1mX3jjIywEc8ks/tGc e/lT/OEMb9XMQOJfQ31dgRaLBgCZmMSGR42CYo0u1Eath7Gu4kwXmeY8VGQ67c0m2onJ n0TzYu2pwrTUR4jkuEex6kTQlWCNPpl5TXugC6MrnWwcYEk4Vdvn++4T98pEGl2GcNxq /UZj4KfyzAnKC9IbRHX8rtXRLVqupXvWt6wgzaiXY7TFj2WV7Vv4mNPJFYMLgUeIZV88 FLEdT8vo3URYl43vaF0gqPhf5hAr+PP++12cKRtAt3aX7oV2LKOpVGlNiP7hxRyNnCBs 7R8A== X-Received: by 10.224.65.134 with SMTP id j6mr23046800qai.90.1405349405239; Mon, 14 Jul 2014 07:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.78 with HTTP; Mon, 14 Jul 2014 07:49:45 -0700 (PDT) In-Reply-To: <53C3AECF.1000802@cisco.com> References: <20140701170314.8591.2298.idtracker@ietfa.amsl.com> <53BFA9D3.20800@gmail.com> <53C3AECF.1000802@cisco.com> From: "Andrew G. Malis" Date: Mon, 14 Jul 2014 10:49:45 -0400 Message-ID: To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a11c2c9a415b9bc04fe28680c Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/XKYZECzLexMuRHYw4k52msepgJk Cc: pwe3 , "huubatwork@gmail.com" Subject: Re: [PWE3] I-D Action: draft-shawam-pwe3-ms-pw-protection-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 14:50:09 -0000 --001a11c2c9a415b9bc04fe28680c Content-Type: text/plain; charset=UTF-8 Stewart, Thanks for the comment. This is obviously just an initial draft, we would appreciate any further comments from you and the list on where we can add detail in future revisions. The overall intention is that operation will be basically identical to that for statically provisioned MPLS-TP LSPs in RFC 6378. Cheers, Andy On Mon, Jul 14, 2014 at 6:19 AM, Stewart Bryant wrote: > Huub, > > This is going to need quite a lot more detail, both > in terms of specific updates to RFC6378/7271 and in terms > of operation in the PW context. > > Stewart > > > On 11/07/2014 10:09, Huub van Helvoort wrote: > >> All, >> >> After publication of RFC6378 and RFC7271 The ITU-T has approved >> recommendation G.8131 based on these RFCs. >> >> However, during the drafting of this recommendation operators >> expressed their concern that this recommendation only applies >> to LSPs, and not to PWs, in particular MS-PWs. >> >> To address their concern we started working on this draft. >> When it becomes an RFC it will be used to extend G.8131 to >> include PWs. >> >> Cheers, Huub. >> >> ============= >> >> On 01-07-14 19:03, internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Encapsulation for PSC for Multi-Segment >>> Pseudowires >>> Authors : Huub van Helvoort >>> Loa Andersson >>> Andrew G. Malis >>> Jongyoon Shin >>> Lei Wang >>> Alessandro D'Alessandro >>> Filename : draft-shawam-pwe3-ms-pw-protection-00.txt >>> Pages : 4 >>> Date : 2014-07-01 >>> >>> Abstract: >>> In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection', as >>> well as in the later updates of this RFC, the Protection State >>> Coordiantion (PSC) protocol was defined for MPLS LSPs only. This >>> draft extends RFC 6378 to be applicable for pseudowires as well. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-00 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --001a11c2c9a415b9bc04fe28680c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

Thanks for the comment. This i= s obviously just an initial draft, we would appreciate any further comments= from you and the list on where we can add detail in future revisions. The = overall intention is that operation will be basically identical to that for= statically provisioned MPLS-TP LSPs in RFC 6378.

Cheers,
Andy


On Mon, Jul 14, 2014 at 6:19 AM, S= tewart Bryant <stbryant@cisco.com> wrote:
Huub,

This is going to need quite a lot more detail, both
in terms of specific updates to RFC6378/7271 and in terms
of operation in the PW context.

Stewart


On 11/07/2014 10:09, Huub van Helvoort wrote:
All,

After publication of RFC6378 and RFC7271 The ITU-T has approved
recommendation G.8131 based on these RFCs.

However, during the drafting of this recommendation operators
expressed their concern that this recommendation only applies
to LSPs, and not to PWs, in particular MS-PWs.

To address their concern we started working on this draft.
When it becomes an RFC it will be used to extend G.8131 to
include PWs.

Cheers, Huub.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On 01-07-14 19:03, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Encapsulation for PSC for Multi-Segment Pseudowires
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Huu= b van Helvoort
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Loa Andersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Andrew G. Malis
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jongyoon Shin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Lei Wang
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Alessandro D'Alessandro
=C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-shawam-pwe3-ms-pw= -protection-00.txt
=C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 4
=C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2014-07-01
Abstract:
=C2=A0 =C2=A0 In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Prot= ection', as
=C2=A0 =C2=A0 well as in the later updates of this RFC, the Protection Stat= e
=C2=A0 =C2=A0 Coordiantion (PSC) protocol was defined for MPLS LSPs only. T= his
=C2=A0 =C2=A0 draft extends RFC 6378 to be applicable for pseudowires as we= ll.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shawa= m-pwe3-ms-pw-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-shawam-pwe3-ms-= pw-protection-00


Please note that it may take a couple of minutes from the time of submissio= n
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@iet= f.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





--
For corporate legal information go to:

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


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

--001a11c2c9a415b9bc04fe28680c-- From nobody Mon Jul 14 08:25:32 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B536F1A0A86 for ; Mon, 14 Jul 2014 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfZ69YYX9Rwk for ; Mon, 14 Jul 2014 08:25:19 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EAF1A0A91 for ; Mon, 14 Jul 2014 08:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15274; q=dns/txt; s=iport; t=1405351519; x=1406561119; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=d2mOoQ7/QNehKJTZDoiH4iGi8ra6L6YG/dhVboyibtc=; b=Ma22o6DR037VxUzV7M5obzJ8THjNZDaSBsLMmPxgstY52Jw7+eSwKiq5 XNZF2nwu2jMKDFL2L0NFBrf+UhPpiS7L0kzAdFLQSoN6nJavFGOaXIYQp ml9u9x7e+yI/BnkLvapOLv5lJrGqCPI8BUp/4j44h/3zarM9mdxvON2GR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAPj0w1OtJssW/2dsb2JhbABZg2DCIQEJh0MBgSt1hAQBAQQBAQFrCgEQCxgJFggHCQMCAQIBFR8RBg0BBQIBAQWIOQ23KpBhF49LBwmEOgWbDoFKhUiGeIYUg0Vr X-IronPort-AV: E=Sophos;i="5.01,659,1400025600"; d="scan'208,217";a="106594061" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 14 Jul 2014 15:25:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6EFPFVs007725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 15:25:15 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6EFPErW019481; Mon, 14 Jul 2014 16:25:15 +0100 (BST) Message-ID: <53C3F65A.6020305@cisco.com> Date: Mon, 14 Jul 2014 16:25:14 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Andrew G. Malis" References: <20140701170314.8591.2298.idtracker@ietfa.amsl.com> <53BFA9D3.20800@gmail.com> <53C3AECF.1000802@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080601010002040005010109" Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/uXAG2JR-55t5O4XfDcgEtSVHWag Cc: pwe3 , "huubatwork@gmail.com" Subject: Re: [PWE3] I-D Action: draft-shawam-pwe3-ms-pw-protection-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Jul 2014 15:25:25 -0000 This is a multi-part message in MIME format. --------------080601010002040005010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andy, An overarching question - SS-PW and/or MS-PW? MPLS-TP does not say much about MS-PW and I am not sure whether or not they are needed. In the case of SS-PW the LSP are entirely congruent, so presumably your concern is bandwidth of the underlying LSP causing you to need to spread your repair across a number of LSPs and thus the LSP and PW repair are mutually exclusive - correct? Stewart On 14/07/2014 15:49, Andrew G. Malis wrote: > Stewart, > > Thanks for the comment. This is obviously just an initial draft, we > would appreciate any further comments from you and the list on where > we can add detail in future revisions. The overall intention is that > operation will be basically identical to that for statically > provisioned MPLS-TP LSPs in RFC 6378. > > Cheers, > Andy > > > On Mon, Jul 14, 2014 at 6:19 AM, Stewart Bryant > wrote: > > Huub, > > This is going to need quite a lot more detail, both > in terms of specific updates to RFC6378/7271 and in terms > of operation in the PW context. > > Stewart > > > On 11/07/2014 10:09, Huub van Helvoort wrote: > > All, > > After publication of RFC6378 and RFC7271 The ITU-T has approved > recommendation G.8131 based on these RFCs. > > However, during the drafting of this recommendation operators > expressed their concern that this recommendation only applies > to LSPs, and not to PWs, in particular MS-PWs. > > To address their concern we started working on this draft. > When it becomes an RFC it will be used to extend G.8131 to > include PWs. > > Cheers, Huub. > > ============= > > On 01-07-14 19:03, internet-drafts@ietf.org > wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Encapsulation for PSC for > Multi-Segment Pseudowires > Authors : Huub van Helvoort > Loa Andersson > Andrew G. Malis > Jongyoon Shin > Lei Wang > Alessandro D'Alessandro > Filename : > draft-shawam-pwe3-ms-pw-protection-00.txt > Pages : 4 > Date : 2014-07-01 > > Abstract: > In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear > Protection', as > well as in the later updates of this RFC, the > Protection State > Coordiantion (PSC) protocol was defined for MPLS LSPs > only. This > draft extends RFC 6378 to be applicable for > pseudowires as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-00 > > > 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/ > > _______________________________________________ > 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 > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------080601010002040005010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andy,

An overarching question - SS-PW and/or MS-PW?

MPLS-TP does not say much about MS-PW and I am not sure whether or not they are needed.

In the case of SS-PW  the LSP are entirely congruent, so presumably your concern is bandwidth of the underlying LSP causing you to need to spread your repair across a number of LSPs and thus the LSP and PW repair are mutually exclusive - correct?

Stewart



On 14/07/2014 15:49, Andrew G. Malis wrote:
Stewart,

Thanks for the comment. This is obviously just an initial draft, we would appreciate any further comments from you and the list on where we can add detail in future revisions. The overall intention is that operation will be basically identical to that for statically provisioned MPLS-TP LSPs in RFC 6378.

Cheers,
Andy


On Mon, Jul 14, 2014 at 6:19 AM, Stewart Bryant <stbryant@cisco.com> wrote:
Huub,

This is going to need quite a lot more detail, both
in terms of specific updates to RFC6378/7271 and in terms
of operation in the PW context.

Stewart


On 11/07/2014 10:09, Huub van Helvoort wrote:
All,

After publication of RFC6378 and RFC7271 The ITU-T has approved
recommendation G.8131 based on these RFCs.

However, during the drafting of this recommendation operators
expressed their concern that this recommendation only applies
to LSPs, and not to PWs, in particular MS-PWs.

To address their concern we started working on this draft.
When it becomes an RFC it will be used to extend G.8131 to
include PWs.

Cheers, Huub.

=============

On 01-07-14 19:03, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.


         Title           : Encapsulation for PSC for Multi-Segment Pseudowires
         Authors         : Huub van Helvoort
                           Loa Andersson
                           Andrew G. Malis
                           Jongyoon Shin
                           Lei Wang
                           Alessandro D'Alessandro
    Filename        : draft-shawam-pwe3-ms-pw-protection-00.txt
    Pages           : 4
    Date            : 2014-07-01

Abstract:
    In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection', as
    well as in the later updates of this RFC, the Protection State
    Coordiantion (PSC) protocol was defined for MPLS LSPs only. This
    draft extends RFC 6378 to be applicable for pseudowires as well.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-00


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/

_______________________________________________
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





--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


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



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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------080601010002040005010109-- From nobody Mon Jul 14 08:43:00 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB21A0AA3 for ; Mon, 14 Jul 2014 08:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gDq2eBili7n for ; Mon, 14 Jul 2014 08:42:53 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149771A0AA2 for ; Mon, 14 Jul 2014 08:42:53 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l6so3776418qcy.31 for ; Mon, 14 Jul 2014 08:42:52 -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=oTqdd6i/YYZkSS04023z5tAwy3jopRWu/xlw7+Bo5lY=; b=NJq7bbUvKzF9hfxD53CIWCn4aYTvOpzFxICWqKVse41bk4j7aW+KfrfeRNdSzN9f7r j2NwI9fVfUriRWNG8Xfp3gXH8emDosomK/FIefE6C0AGjSJsU5o1wJzEzv9BPmK+zAs0 5TW7DlI3DC2rZl6NmRTsZQ90o2huJm02GNiKXVqnGpVbc5ad1wr79+045TgZKbV84+mM efcgfep1xrMcUBRO2T0B1uzlCYYGj7Jj1m1nc+jUGQHF9V8LER/nDXMJX4fhIEJntHaB LMYqephOKBslx12f4zswi3y/eqfOlorhaDGCSt8hY8y3SnPp3KYT4CjZuXQY0xzJ5UF0 kP/Q== X-Received: by 10.140.49.76 with SMTP id p70mr24717013qga.86.1405352572305; Mon, 14 Jul 2014 08:42:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.78 with HTTP; Mon, 14 Jul 2014 08:42:32 -0700 (PDT) In-Reply-To: <53C3F65A.6020305@cisco.com> References: <20140701170314.8591.2298.idtracker@ietfa.amsl.com> <53BFA9D3.20800@gmail.com> <53C3AECF.1000802@cisco.com> <53C3F65A.6020305@cisco.com> From: "Andrew G. Malis" Date: Mon, 14 Jul 2014 11:42:32 -0400 Message-ID: To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a11370a34db475c04fe29244d Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/kKeQUT2FEt47lVHRtn7c0tH0Z7E Cc: pwe3 , "huubatwork@gmail.com" Subject: Re: [PWE3] I-D Action: draft-shawam-pwe3-ms-pw-protection-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 15:42:56 -0000 --001a11370a34db475c04fe29244d Content-Type: text/plain; charset=UTF-8 Stewart, This draft is explicitly meant for statically provisioned MS-PWs running over MPLS-TP LSPs, in order to protect for S-PE failure. Each of the component SS-PWs are automatically protected by the underlying LSP protection, so for SS-PWs, there will only be one level of repair, at the LSP level. We tried to make this clear in the draft. We can try to make that more clear in the next revision. Generally, MS-PWs are needed over MPLS-TP for the same reasons that they're needed over MPLS. Cheers, Andy On Mon, Jul 14, 2014 at 11:25 AM, Stewart Bryant wrote: > Andy, > > An overarching question - SS-PW and/or MS-PW? > > MPLS-TP does not say much about MS-PW and I am not sure whether or not > they are needed. > > In the case of SS-PW the LSP are entirely congruent, so presumably your > concern is bandwidth of the underlying LSP causing you to need to spread > your repair across a number of LSPs and thus the LSP and PW repair are > mutually exclusive - correct? > > Stewart > > > > > On 14/07/2014 15:49, Andrew G. Malis wrote: > > Stewart, > > Thanks for the comment. This is obviously just an initial draft, we > would appreciate any further comments from you and the list on where we can > add detail in future revisions. The overall intention is that operation > will be basically identical to that for statically provisioned MPLS-TP LSPs > in RFC 6378. > > Cheers, > Andy > > > On Mon, Jul 14, 2014 at 6:19 AM, Stewart Bryant > wrote: > >> Huub, >> >> This is going to need quite a lot more detail, both >> in terms of specific updates to RFC6378/7271 and in terms >> of operation in the PW context. >> >> Stewart >> >> >> On 11/07/2014 10:09, Huub van Helvoort wrote: >> >>> All, >>> >>> After publication of RFC6378 and RFC7271 The ITU-T has approved >>> recommendation G.8131 based on these RFCs. >>> >>> However, during the drafting of this recommendation operators >>> expressed their concern that this recommendation only applies >>> to LSPs, and not to PWs, in particular MS-PWs. >>> >>> To address their concern we started working on this draft. >>> When it becomes an RFC it will be used to extend G.8131 to >>> include PWs. >>> >>> Cheers, Huub. >>> >>> ============= >>> >>> On 01-07-14 19:03, internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Encapsulation for PSC for Multi-Segment >>>> Pseudowires >>>> Authors : Huub van Helvoort >>>> Loa Andersson >>>> Andrew G. Malis >>>> Jongyoon Shin >>>> Lei Wang >>>> Alessandro D'Alessandro >>>> Filename : draft-shawam-pwe3-ms-pw-protection-00.txt >>>> Pages : 4 >>>> Date : 2014-07-01 >>>> >>>> Abstract: >>>> In RFC 6378 'MPLS Transport Profile (MPLS-TP) Linear Protection', as >>>> well as in the later updates of this RFC, the Protection State >>>> Coordiantion (PSC) protocol was defined for MPLS LSPs only. This >>>> draft extends RFC 6378 to be applicable for pseudowires as well. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-00 >>>> >>>> >>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>> >>> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > > > _______________________________________________ > pwe3 mailing listpwe3@ietf.orghttps://www.ietf.org/mailman/listinfo/pwe3 > > > > -- > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > --001a11370a34db475c04fe29244d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

This draft is explicitly meant= for statically provisioned MS-PWs running over MPLS-TP LSPs, in order to p= rotect for S-PE failure. Each of the component SS-PWs are automatically pro= tected by the underlying LSP protection, so for SS-PWs, there will only be = one level of repair, at the LSP level. We tried to make this clear in the d= raft. We can try to make that more clear in the next revision.

Generally, MS-PWs are needed over MPLS-TP for the same = reasons that they're needed over MPLS.=C2=A0

C= heers,
Andy

On Mon, Jul 14, 2014 at 11:25 AM, Stewart Bryant <stbryant@cisco.com&= gt; wrote:
=20 =20 =20
Andy,

An overarching question - SS-PW and/or MS-PW?

MPLS-TP does not say much about MS-PW and I am not sure whether or not they are needed.

In the case of SS-PW=C2=A0 the LSP are entirely congruent, so presumably your concern is bandwidth of the underlying LSP causing you to need to spread your repair across a number of LSPs and thus the LSP and PW repair are mutually exclusive - correct?

Stewart




On 14/07/2014 15:49, Andrew G. Malis wrote:
=20
Stewart,

Thanks for the comment. This is obviously just an initial draft, we would appreciate any further comments from you and the list on where we can add detail in future revisions. The overall intention is that operation will be basically identical to that for statically provisioned MPLS-TP LSPs in RFC 6378.

Cheers,
Andy


On Mon, Jul 14, 2014 at 6:19 AM, Stewart Bryant <stbryant@cisco.com> wrote:
Huub,

This is going to need quite a lot more detail, both
in terms of specific updates to RFC6378/7271 and in terms
of operation in the PW context.

Stewart


On 11/07/2014 10:09, Huub van Helvoort wrote:
All,

After publication of RFC6378 and RFC7271 The ITU-T has approved
recommendation G.8131 based on these RFCs.

However, during the drafting of this recommendation operators
expressed their concern that this recommendation only applies
to LSPs, and not to PWs, in particular MS-PWs.

To address their concern we started working on this draft.
When it becomes an RFC it will be used to extend G.8131 to
include PWs.

Cheers, Huub.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On 01-07-14 19:03, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : Encapsulation for PSC for Multi-Segment Pseudowires
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0= =C2=A0 =C2=A0 : Huub van Helvoort
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Loa Andersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andrew G. Malis
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jongyoon Shin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lei Wang
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alessandro D'Alessandro
=C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: dra= ft-shawam-pwe3-ms-pw-protection-00.txt
=C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 4
=C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 2014-07-01

Abstract:
=C2=A0 =C2=A0 In RFC 6378 'MPLS Transport Profile (= MPLS-TP) Linear Protection', as
=C2=A0 =C2=A0 well as in the later updates of this RFC,= the Protection State
=C2=A0 =C2=A0 Coordiantion (PSC) protocol was defined f= or MPLS LSPs only. This
=C2=A0 =C2=A0 draft extends RFC 6378 to be applicable f= or pseudowires as well.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-shawam-pwe3-ms-pw-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-sh= awam-pwe3-ms-pw-protection-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at too= ls.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-announc= e
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt





--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_busi= ness/legal/cri/index.html


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



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



--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c=
ri/index.html

--001a11370a34db475c04fe29244d-- From nobody Wed Jul 16 08:43:20 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A32A1B2BA8 for ; Wed, 16 Jul 2014 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEy45W8zY5DO for ; Wed, 16 Jul 2014 08:42:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5181B2A93 for ; Wed, 16 Jul 2014 08:42:41 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-ef-53c648608855 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 03.DE.25146.06846C35; Wed, 16 Jul 2014 11:39:45 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 11:42:33 -0400 From: David Sinicrope To: IETF.PWE3 Thread-Topic: [PWE3] PWE3 IETF 90 Slot Requests - Toronto - SLIDES Thread-Index: AQHPoQyPCovda/bv5kCtYLqXnZAuoQ== Date: Wed, 16 Jul 2014 15:42:32 +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.1.130117 x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_CFEC14E613E4C9davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXSPn26ix7Fgg2PdfBZ9n7awODB6LFny kymAMYrLJiU1J7MstUjfLoErY8XMFcwF520rnn1eytTA2GvaxcjJISFgIjGx/zQThC0mceHe erYuRi4OIYGjjBIfp/yBcpYzSiz4MpMNpIoNqGPdxj0sILaIgKzE6+v3wOLCAo4St3Yvhoo7 SezrecYOYetJHG79BhZnEVCVmH38I1g9r4CVxMbjV8FsToFAiQXt91hBbEagK76fWgN2EbOA uMStJ/OhrhOQWLLnPDOELSrx8vE/sHpRoPnr23dD1ShJzHl9jRmiN17i+40HjBC7BCVOznzC MoFRZBaSsbOQlM1CUgYRN5B4f24+M4StLbFs4WsoW19i45ezjBC2tcTmVTNYkNUsYORYxchR WpxalptuZLiJERhDxyTYHHcwLvhkeYhRgINRiYf3gfHRYCHWxLLiytxDjNIcLErivJrV84KF BNITS1KzU1MLUovii0pzUosPMTJxcEo1MJas7RP7UHXNunaFx8y2wPR1SzKkDPflTlXbvWCV reQdQz/9VwyHvtvvW3lctSu5++eDakaj+z57ojeJO4Q0v9n3+Vrm4d3L50+fyn5posu983Z9 mxf82RszpbuGz+39vdDKpzMX5M3v2sB26bxhWMHijzxtW2YsCW+Kc5f9w3xwwwRN+XmTYm4r sRRnJBpqMRcVJwIAKCHPWoICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Ni5yLzRZnjhNY5RcVdsyJDwsFuE Subject: [PWE3] FW: PWE3 IETF 90 Slot Requests - Toronto - SLIDES X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 15:43:17 -0000 --_000_CFEC14E613E4C9davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/90/agenda/agenda-90-pwe3 Hi All, Above, is a link to the current PWE3 agenda for Toronto. - If you requested a slot and it is not present, my apologies, please reply to this email and let me know. - If you have a slot, please send me your slides as soon as possible. I need to have your slides no later than Wednesday July 23 at noon Toronto= time to ensure they are uploaded for the session. If you don=92t intend to submit s= lides for your slot, I need no know that as well. Please Note: If I don=92t have slides by the deadline, (or notice there won= =92t be slides), the slot may be removed from the agenda. Please let me know if you have questions. Thanks! Dave On Mon, Jun 23, 2014 at 1:29 PM, David Sinicrope > wrote: Hi All, It's that time again. If you need a presentation slot for the IETF 90 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 during the meeting (e.g., need to address secu= rity issues and get direction from the WG): - requested duration (norm is 10 min): - speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_CFEC14E613E4C9davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <28593C8952A40444A4CDA8400F192E0E@ericsson.com> Content-Transfer-Encoding: quoted-printable


Hi All, 

Above, is a link to the current PWE3 agenda for Toronto.

- If you requested a slot and it is not present, my apologies, please
reply to this email and let me know.

- If you have a slot, please send me your slides as soon as possible.
I need to have your slides no later th= an  Wednesday July 23 at noon Toronto time to
ensure they are uploaded for the session. If you don=92t intend to submit s= lides for your slot, I
need no know that as well.

Please Note: If I don=92t have slides by the deadline, (or notice there won= =92t be slides), the
slot may be removed from the agenda.

Please let me know if you have questions.
Thanks!
Dave


On Mon, Jun 23, 2014 at 1:29 PM, David Sinicrope= <david= .sinicrope@ericsson.com> wrote:
Hi All,
It's that time again.  

If you need a presentation slot for the IETF 90 PWE3 session, please r= eply 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 during the meeting  (e.g., need to ad= dress security issues and get direction from the WG):  
- requested duration (norm is 10 min):  
- speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE):  

Thanks!
Dave

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


 --_000_CFEC14E613E4C9davidsinicropeericssoncom_-- From nobody Wed Jul 16 16:24:26 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36661A0140 for ; Wed, 16 Jul 2014 16:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-Y1w0wisgKn for ; Wed, 16 Jul 2014 16:24:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C364E1A0393 for ; Wed, 16 Jul 2014 16:24:10 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-f6-53c6b6f882f1 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.66.05330.9F6B6C35; Wed, 16 Jul 2014 19:31:37 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 19:24:09 -0400 From: David Sinicrope To: IETF.PWE3 Thread-Topic: [PWE3] PWE3 IETF 90 Slot Requests - Toronto - SLIDES Thread-Index: AQHPoQyPCovda/bv5kCtYLqXnZAuoZujV/kA Date: Wed, 16 Jul 2014 23:24:08 +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.1.130117 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFEC817A13E5C5davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPuO7PbceCDU4+FrPo+7SFxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGT8mHGcvuOtVcb8puIFxv0MXIyeHhICJxMoLJ5ggbDGJC/fW s3UxcnEICRxllOh6fJgVwlnOKHHkxmxGkCo2oI51G/ewgNgiArISr6/fYwOxhQUcJU5OXM8E EXeS2NfzjB3CNpLoX/eBGcRmEVCVaH+2ixXE5hWwkri0bSlYPaeAtcSbrT/B4oxAV3w/tQYs ziwgLnHryXyo6wQkluw5zwxhi0q8fPwPrF5UQE9ifftuqBpFiX3909kheuMlnuxYywyxS1Di 5MwnLBMYRWYhGTsLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0v8mXuSHVnNAkaO VYwcpcWpZbnpRgabGIERdEyCTXcH456XlocYBTgYlXh4FXyPBQuxJpYVV+YeYpTmYFES551V Oy9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Pry9UPbuy/t/Jpz4Wudz/4aq9fs3HeqXyO 4XBrgcIKNdE/G+v6Fzsx84opvE0q0vl9d2oH2+95keszFjz46dVgcpRZ4VJXRtSffxO6Yy/X NEz7/LrFaNqBgkt29bNjYsIjbgu4T7+/YvMmtdsdmX8Wncib0XGnrkiF742Uu2rm5AMRB5YF Tb6pxFKckWioxVxUnAgAAGUimYECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Z6v9uP4Fj2mWIJj-78m-H0KBkI8 Subject: Re: [PWE3] PWE3 IETF 90 Slot Requests - Toronto - SLIDES X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:24:18 -0000 --_000_CFEC817A13E5C5davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Presenters, Please reply to this email when sending your slides. It will save us both = a great deal of time and confusion. Thanks! Dave From: David A Sinicrope > Date: Wednesday, July 16, 2014 at 11:42 AM To: "IETF.PWE3" > Subject: FW: [PWE3] PWE3 IETF 90 Slot Requests - Toronto - SLIDES http://www.ietf.org/proceedings/90/agenda/agenda-90-pwe3 Hi All, Above, is a link to the current PWE3 agenda for Toronto. - If you requested a slot and it is not present, my apologies, please reply to this email and let me know. - If you have a slot, please send me your slides as soon as possible. I need to have your slides no later than Wednesday July 23 at noon Toronto= time to ensure they are uploaded for the session. If you don=92t intend to submit s= lides for your slot, I need no know that as well. Please Note: If I don=92t have slides by the deadline, (or notice there won= =92t be slides), the slot may be removed from the agenda. Please let me know if you have questions. Thanks! Dave On Mon, Jun 23, 2014 at 1:29 PM, David Sinicrope > wrote: Hi All, It's that time again. If you need a presentation slot for the IETF 90 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 during the meeting (e.g., need to address secu= rity issues and get direction from the WG): - requested duration (norm is 10 min): - speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_CFEC817A13E5C5davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Presenters,
Please reply to this email when sending your slides.  It will sav= e us both a great deal of time and confusion.
Thanks!
Dave

From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Wednesday, July 16, 2014 at 1= 1:42 AM
To: "IETF.PWE3" <pwe3@ietf.org>
Subject: FW: [PWE3] PWE3 IETF 90 Sl= ot Requests - Toronto - SLIDES



Hi All, 

Above, is a link to the current PWE3 agenda for Toronto.

- If you requested a slot and it is not present, my apologies, please
reply to this email and let me know.

- If you have a slot, please send me your slides as soon as possible.
I need to have your slides no later th= an  Wednesday July 23 at noon Toronto time to
ensure they are uploaded for the session. If you don=92t intend to submit s= lides for your slot, I
need no know that as well.

Please Note: If I don=92t have slides by the deadline, (or notice there won= =92t be slides), the
slot may be removed from the agenda.

Please let me know if you have questions.
Thanks!
Dave


On Mon, Jun 23, 2014 at 1:29 PM, David Sinicrope= <david= .sinicrope@ericsson.com> wrote:
Hi All,
It's that time again.  

If you need a presentation slot for the IETF 90 PWE3 session, please r= eply 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 during the meeting  (e.g., need to ad= dress security issues and get direction from the WG):  
- requested duration (norm is 10 min):  
- speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE):  

Thanks!
Dave

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


 --_000_CFEC817A13E5C5davidsinicropeericssoncom_-- From nobody Thu Jul 17 13:54:30 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789DF1B27B9 for ; Thu, 17 Jul 2014 13:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxXJgGaKH1oM for ; Thu, 17 Jul 2014 13:54:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C09B1A0280 for ; Thu, 17 Jul 2014 13:54:25 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6HKsLp1012902; Thu, 17 Jul 2014 21:54:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6HKsItx012887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 21:54:18 +0100 From: "Adrian Farrel" To: "'Bocci, Matthew \(Matthew\)'" , References: <01dc01cf85bf$6c8ad7c0$45a08740$@olddog.co.uk> In-Reply-To: Date: Thu, 17 Jul 2014 21:54:22 +0100 Message-ID: <059c01cfa201$4ad3b850$e07b28f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHOxwKU/BIH0qkRhUbpWPA2yPh9FgJqb034m5Mg/RA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20824.002 X-TM-AS-Result: No--30.745-10.0-31-10 X-imss-scan-details: No--30.745-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFq+9Go4BgFPZvHkpkyUphL9Ud7Bjfo+5jQRx1ZQY4Xt8tLu X2hj/M7UJP00JqzxhIB7aKUDRbhLKCjrjvzj49diJrUxoq6hvw/2acON9Q+rnuOxOq7LQlGLvL4 BuAuBsSnwKlP0KoRKbvac0QEup10Xfh0BByKSGpMlcqT+ugT9EIxSiPvIuF4MjPODI4m6bId576 my5IxjuvvJeoxUpIu6n4/cyEjucyW1UAN2vPuTMgRH1Nr7oERdk8UlXQzLGbx0QbvL4PujkK7mY Da7MoGa0tJGicxmiABwk1K+UrXHII9Tk4aumaegytPf0+gM21ZMkOX0UoduuZGntM3CLyHIeDQZ Zv+Gu30VPtH9EQas3HIfs9QZhLvCU1zG93opzFyjFYHTfcPkwnH1PtMiCrmF30xSgZEFQrI4UBB O/94egnioecYD5Bummw9trAtyipQLj6umkFEndrMjW/sniEQK8GRhP/nTHNZrhR1KtG8cZ9uB9n RBrQLNWcTCIZBK1JZqoyAp1VSpDxnrFEMoRsxoaDCzqDR7DPblPUem/J5c5Jh8u7mojKy+rcFzn sQHTX+PgzQ0Erc0tvy/E948lLb8VHtwUQgyP8QuLk8NfSpYerNYRMFA9XfyjU56jjASCeFaapAz RzPL/iB3VCBA4MU3Kg3xX/Pr9pFXrZyNmXN0n2ivjLE8DPtZNACnndLvXwdnnK6mXN72m3iqSo/ 0rKU59eFoxur7d5J4g0hFkcRCiv9ehdaP6yTuf01qcJQDhV6FKXsoBdprwgzvg1/q1MH2sYKQLF UbB7tqkRA4CdDcJgn0+N42iHg9HyzWFbk8FLWeAiCmPx4NwJXxsKTUj1Z+cl9zWW7buV7kA/7Kq i9Jmau6xVHLhqfxvECLuM+h4RB+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/2y2unUnksPZNw-nUrnD-xHLy70E Cc: pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-mspw-er X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 20:54:29 -0000 All looking good to me, Matthew. Just waiting for you to post. A > -----Original Message----- > From: Bocci, Matthew (Matthew) = [mailto:matthew.bocci@alcatel-lucent.com] > Sent: 11 July 2014 13:52 > To: adrian@olddog.co.uk; draft-ietf-pwe3-mspw-er.all@tools.ietf.org > Cc: pwe3@ietf.org > Subject: Re: AD review of draft-ietf-pwe3-mspw-er >=20 > Hi Adrian, >=20 > Thanks very much for your detailed review. >=20 > I=B9ve replied to your comments in-line below, and will revise the = draft to > incorporate the required changes, shortly. >=20 > Best regards >=20 > Matthew >=20 >=20 >=20 > On 11/06/2014 22:52, "Adrian Farrel" wrote: >=20 > Authors, >=20 > Thanks for your work on this document. I have conducted my normal AD > review having received the publication request. The purpose of the > review is to find issues and concerns that improve the quality of the > document for readability and implementation, and to remove issues that > might otherwise get found during IETF last call, directorate reviews, > and IESG evaluation. >=20 > I think that in general this document is fine, but I think it needs = some > work on clarity. Hopefully none of my points is contentious, and they > can all be handled through some fairly simple edits. of course, every > point is open for discussion and you can refute each and every one of > them. >=20 > I'll put the document into "Revised I-D Needed" state and wait to see = an > update and/or email from you. >=20 > Thanks, > Adrian >=20 > =3D=3D=3D >=20 > On a copyright thing... > Are you sure that some of this material hadn't been lifted pretty much > unchanged from RFC 3212? You might at least acknowledge that in the > Acknowledgements section. >=20 > MB> Agreed. I propose adding the following text to the = acknowledgements > section as well as adding a reference to RFC3212 in section 4.2. >=20 > "The authors of this document gratefully acknowledge the contribution = of > the > RFC3212 authors though the specification of TLVs, which are reused by = this > document." >=20 > --- >=20 > Section 1 >=20 > For 1:1 protection of MS-PWs with > primary and backup paths, MS-PWs SHOULD be established through a > diverse set of S-PEs (Switching Provider-Edge) nodes to avoid any > single points of failure at PW level. >=20 > I think s/SHOULD be/need to be/ > The points are: > - This is really not a case for RFC 2119 language > - "should" is not really good enough for proper 1:1 protection >=20 > MB> I agree >=20 > --- >=20 > Do you not think that the Introduction should discuss a little about = how > the path might be known? Specifically how the head-end T-PE knows what > explicit route to use. It may be enough to say "In many deployments = the > head-end T-PE will not have a view of the topology of S-PEs and so the > explicit route will need to be supplied from a management application. > How that management application determines the explicit route is = outside > the scope of this document." >=20 > MB> Agreed. I'll add that statement to the introduction. >=20 > --- >=20 > Section 1 >=20 > This draft proposes an additional mechanism >=20 > Don't say "draft" say "document" because you want this text in an RFC. > Don't "propose", "define" or "specify" because you want this in a > protocol specification. >=20 > MB> Agreed >=20 > --- >=20 > Section 3.1 needs to discuss how uniqueness of "S-PE addresses" is > guaranteed/arranged. >=20 > MB> Actually, this section is simply a duplication of RFC7267, Section > 3.2. This is a > result of this draft being forked from draft-ietf-pwe3-dynamic-ms-pw. > While I agree > with your comments below on this section, we could just > rephrase the section in this draft as follows and raise an errata to > clarify any > points in RFC7267, as follows: >=20 > "An S-PE Address is an address used to identify a given S-PE among the = set > of S-PEs > belonging to the PSNs that may be used by an MS-PW. Each S-PE MUST be > assigned an address > as specified in [RFC6267] Section 3.2. An S-PE that is capable of = dynamic > MS-PW signaling > but that has not been assigned an S-PE address and receives a Label > Mapping message > for a dynamic MS-PW MUST follow the procedures of [RFC7276] Section = 3.2." >=20 >=20 >=20 > I suggest you formally define the term "S-PE address" >=20 >=20 >=20 > What does "format similar to" actually mean? >=20 >=20 >=20 > --- >=20 > Section 3.1 >=20 > If an S-PE is capable of Dynamic MS-PW signaling, but is not = assigned > with an S-PE address, then on receiving a Dynamic MS-PW label = mapping > message the S-PE MUST return a label release with the "Resources > Unavailable" ( 0x00000038)" status code. >=20 > It is not clear to me whether this is new normative behavior or a > restatement of draft-ietf-pwe3-dynamic-ms-pw. This isn't helped by the > fact that "Dynamic MS-PW label mapping message" seems to be a new = term. >=20 > You should probably define the term explicitly somehow with reference = to > what it contains that makes it such a message (not just an ordinary > label mapping message) and a reference to = draft-ietf-pwe3-dynamic-ms-pw. >=20 > Then you need to help clarify if this is new behavior. If it is not, > then you can include "As described in [ref]..." If it *is* new = behavior > for an existing message you have to explain how this is backward > compatible with current processing of this message. If it is new > behavior for a *new* message (i.e. defined in this document) then the > text is very out of order and at the least you need some explanation = of > where this message is defined and what it does. >=20 > MB> Agreed. It should be aligned with RFC7267. Please see the proposal > above. >=20 > --- >=20 > Section 3 might usefully say some overview stuff like: > - An explicitly routed PW is set up using a Label Mapping message that > carries an ordered list of the S-PEs through which the PW is = expected > to run. > - The ordered list is encoded as a series of ER Hop TLVs encoded in a > ER TLV that is carried in the Label Mapping message. >=20 > Doing this would save the reader ploughing through section 3 trying to > work out what it is all about. >=20 > MB> Agreed. I will add an introductory paragraph based on your text. >=20 >=20 >=20 > --- >=20 > If the ER Hop TLV can contain an IP address identifying an abstract > node, why is it necessary for each S-PE to have a unique S-PE address > formed as an AII? >=20 > MB> > --- >=20 > Section 3.2 >=20 > Length > Specifies the length of the value field in bytes. >=20 > There is, of course, no "value" field, so you could be a little = clearer. > Unfortunately, there is currently a theme in the IESG on multi-byte > integer fields that means you need to say how the integer is encoded = on > the wire, so you need to add "encoded in line format". >=20 > BUT... >=20 > Wait a minute. You are re-using 0x0800 for the ER TLV. Good. We don't > need to define multiple TLVs for the same function. But why are you > writing this document as though you are defining the TLV? Why is there > no mention of RFC 3212? >=20 > The same questions apply to the ER Hop TLV and the two of its types > that you are re-using. >=20 > This wouldn't take a lot of text and would allow you to delete a fair > bit. Something along the lines of... >=20 > The process defined in this document makes use of the ER TLV = defined > in [RFC3212]. This TLV can be placed in a Label Mapping message = used > for dynamic PW setup as described in Section 4. >=20 > The ER TLV contains one or more ER Hop TLVs, each describing a hop > along the desired path or the PW. The procedures described in this > document allow for the use of the "IPv4 Prefix ER-Hop TLV" and the > "IPv6 Prefix ER-Hop TLV" (both defined in [RFC3212]) and also the > "L2 PW address of PW Switching Point" defined in this document. >=20 >=20 > MB> RFC3212 references were originally included in the text from > draft-ietf-dynamic-ms-pw > (see Version 13), but these were removed due to some comments around = last > call time that > we were tying the fate of this draft to the future fate of RFC3212. > Personally, I am > OK with reinstating the references as you propose. >=20 > --- >=20 > Curiously, in 3.4.1 you have > IP Address > A four-byte field indicating the IP Address. > while in 3.4.2 you have > IPv6 address > A 128-bit unicast host addresses. > It makes one wonder. >=20 > This issue would disappear with the fix previously mentioned. >=20 > MB> OK >=20 > --- >=20 > For both the IPv4 and IPv6 hops, I think you need to think about (and > document) whether you support less than fully specified IP addresses. > For both of the prefix lengths you appear to allow 1-n (n =3D 32 or = 128) > yet for IPv6 you seem to say it is a unicast host address which would > preclude anything other than 128. >=20 > MB> It does seem that way, although that's also how RFC3212 defines = it. > I will discuss with the other authors and make a proposal. >=20 > --- >=20 > 3.4.3 needs some work... >=20 > The section title says "ER-Hop 3: L2 PW Address" but while this may be > the third ER-Hop type you support in this usage, the hop type is > actually 5. >=20 >=20 > I suggest you remove the numbers from all three subsection > titles. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| 0x0802 | Length =3D 18 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The value you have used in 0x0805. But (of course) you should use > TBD1 and reflect that in the IANA section. >=20 > MB> Agreed >=20 >=20 > |L| Reserved | PreLen | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AII Type=3D02 | Length | Global ID = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Having to fields called "Length" makes the documentation ambiguous. > Suggest you make the first one "TLV-Length" >=20 >=20 > | Global ID (contd.) | Prefix | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix (contd.) | AC ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AC ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > U/F > These bits MUST be set to zero and the procedures of = [RFC5036] > followed when the TLV is not known to the receiving node. >=20 >=20 > Type > A fourteen-bit field carrying the value of the ER-Hop 3, L2 = PW > Address, Type =3D 0x0805 >=20 > Length > Specifies the length of the value field in bytes =3D 18. >=20 > L Bit > Set to indicate Loose hop. > Cleared to indicate a strict hop. >=20 > PreLen > Prefix Length 1-96 >=20 > It is slightly curious that RFC 5003 didn't find a need for indicating > the prefix length. Since it is (presumably!) your intention that the > count to 96 spans the Global ID, Prefix, and AC ID fields, I think you > need to make that clear here and describe its usage later. Otherwise > one would rationally assume that the prefix length applies to the = prefix > field. >=20 > MB> Agreed. I will follow up with the co-authors to clarify and = propose > some revised text. >=20 > L2 PW Address > An AII Address as defined in [RFC5003]. >=20 > Rather than say this (which is confusing because there is no such L2 = PW > Address field) you should say "All other fields (AII Type, Length, = Global > ID, Prefix, and AC ID) define the L2 PW Address and are to be set and > interpreted as defined in Section 3.2 of [RFC5003]." >=20 > MB> agreed >=20 > --- >=20 > 4.1 >=20 > A PW Label Mapping Message containing an explicit route TLV MUST > specify the next hop for a given MS-PW path. >=20 > What do you mean "MUST"? Surely... >=20 > A PW Label Mapping Message containing an Explicit Route TLV = specifies > the next hop for a given MS-PW path. >=20 > MB> agreed >=20 > --- >=20 > 4.1 >=20 > Selection of this next > hop MAY involve a selection from a set of possible alternatives. >=20 > s/MAY/may/ >=20 > MB> OK >=20 > --- >=20 > 4.1 >=20 > The mechanism > used to select a particular path is also outside of the scope of = this > document, but each node MUST attempt to determine a loop-free path. > Note that such mechanisms MAY be overridden by local policy. >=20 > This is ambiguous... >=20 > "MUST attempt" but if it can't find one it is OK to go ahead with a > loop? >=20 >=20 > Local policy may override attempting to find a loop-free path? >=20 > Local policy may override the mechanism to select a path (which is a > local policy on account of not being part of this document)? >=20 > What information does an S-PE have available to select path and > determine whether there is a loop? >=20 > What should an S-PE do if a path can't be selected without a loop? >=20 >=20 > MB> I agree there are some procedures missing here. For a T-PE, if a = loop > free path > cannot be found, then it must not attempt to signal the MS-PW. For an > S-PE, if it cannot > determine a loop free path, then the received Label Mapping MUST be > released with a > status code of "PW Loop Detected" as per Section 4.2.3 of RFC7267. = I'll > discuss with the > authors and propose some text below. >=20 > --- >=20 > 4.1 >=20 > 1. The node receiving the Label Mapping Message must evaluate the > first ER-Hop. >=20 > This one should be "MUST", but you also need to qualify with "...that > contains an ER TLV." >=20 > MB> agreed >=20 > --- >=20 > 4.1 >=20 > If the L bit is set and the local node > is not part of the abstract node described by the first ER-Hop, > the node selects a next hop that is along the path to the > abstract node described by the first ER-Hop. >=20 > And how will it make that determination? >=20 > MB> This is the same as RFC3212, where a specific node determines if = it is > a member of > an abstract node if its address lies within the prefix (as determined = but > the prefix > length) specified in the ER-Hop TLV. >=20 >=20 > --- >=20 > 4.1 >=20 > If there is no first > ER-Hop, the message is also in error and the node should return = a > "Bad Explicit Routing TLV Error" (0x04000001) status code in a > Label Release Message sent to upstream node. >=20 > I presume this means if there is an ER TLV that does not contain an ER > Hop TLV. >=20 > MB> YEs >=20 > I presume it remains legal to have a Label Mapping message without an > ER TLV per point 2 of this section. >=20 > MB> Yes >=20 > Perhaps you could clarify this. >=20 > MB> I'll clarify in the next version of the draft. >=20 > --- >=20 > Section 5 >=20 > This draft proposes one new TLV type: >=20 > TLV Type Suggested Value Reference > ------------------------------------ --------------- --------- > L2 PW Address of Switching Point 0x0805 This = Document >=20 > I think this needs to read... >=20 > IANA is requested to assign a further code point from the IETF > Consensus portion of this registry as follows: >=20 > TLV Type Value Reference > ------------------------------------ ------- --------- > L2 PW Address of Switching Point TBD1 This Document >=20 > A value of 0x0805 is requested. >=20 > MB> Agreed. >=20 From nobody Wed Jul 23 07:46:11 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1551B1B292D for ; Wed, 23 Jul 2014 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTx7L1NPMBXE for ; Wed, 23 Jul 2014 07:46:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1761B2865 for ; Wed, 23 Jul 2014 07:46:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN33065; Wed, 23 Jul 2014 14:46:04 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:46:03 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 22:45:56 +0800 From: "Dongjie (Jimmy)" To: "pwe3@ietf.org" Thread-Topic: Appreciate review and comments on draft-cheng-pwe3-mpls-tp-dual-homing-protection-00 Thread-Index: Ac+mhNMhPx98MSdLT5mgDWOCvyiNZA== Date: Wed, 23 Jul 2014 14:45:55 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336C6AF1@nkgeml512-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.47.156.54] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927336C6AF1nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/QR6iPTGjtTjPPq1pFqsJw6QmgOs Subject: [PWE3] Appreciate review and comments on draft-cheng-pwe3-mpls-tp-dual-homing-protection-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:46:10 -0000 --_000_76CD132C3ADEF848BD84D028D243C927336C6AF1nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We have submitted a new version of draft-cheng-pwe3-mpls-tp-dual-homing-pro= tection-00 with clarification of typical scenarios and rearrangement of the= solution section. This draft will be presented on Thursday's PWE3 session, and the authors wo= uld like to encourage your review and comments on it. Many thanks, Jie (on behalf of all co-authors) --_000_76CD132C3ADEF848BD84D028D243C927336C6AF1nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

We have submitted a new version= of draft-cheng-pwe3-mpls-tp-dual-homing-protection-00 with clarification o= f typical scenarios and rearrangement of the solution section.

 

This draft will be presented on= Thursday’s PWE3 session, and the authors would like to encourage you= r review and comments on it.

 

 

Many thanks,<= /p>

Jie (on behalf of all co-author= s)

--_000_76CD132C3ADEF848BD84D028D243C927336C6AF1nkgeml512mbxchi_-- From nobody Wed Jul 23 21:09:02 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169A01ABB90 for ; Wed, 23 Jul 2014 21:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq61OpuoOfw2 for ; Wed, 23 Jul 2014 21:08:58 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8AE1ABB31 for ; Wed, 23 Jul 2014 21:08:57 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6O48mH6000090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 23:08:49 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s6O48ld1016009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 00:08:47 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 24 Jul 2014 00:08:47 -0400 Received: from SG70YWXCHMBA06.zap.alcatel-lucent.com ([169.254.6.126]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 12:08:39 +0800 From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" To: "pwe3@ietf.org" , Jiangyuanlong Thread-Topic: Re: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt Thread-Index: Ac+m9PJodoQ98eygQUujszevc3JAUg== Date: Thu, 24 Jul 2014 04:08:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/R6Wo-wn5LTK1vLixEwPVI5FaGDU Subject: Re: [PWE3] New Version Notification for draft-jiang-pwe3-mc-pon-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 04:09:00 -0000 Hi Yuanlong, Thanks for including DSL and P2P in use cases in Introduction. However the = TLV's and procedures are still PON specific. I would suggest to make the TLV and procedures generic so they are applicab= le to DSL and P2P Ethernet as well. Also in access network i.e. PON and P2P ethernet there is significant amoun= t of dynamic information e.g. DHCP leases, PPP sessions etc which are maint= ained by OLT for each subscriber, the draft should cover the procedure for = synchronization of this dynamic information between the two OLT's. One additional point current draft does not cover the procedure for PON con= figuration TLV when & how it would be used. Also it would be good to have some discussion/feedback on mailing list on t= he expanded draft to see if it covers all scenario's. Thanks -- Shrinivas Joshi -----Original Message----- Hi colleagues, =20 We had updated the draft to a new revision. The main updates include: 1. Add more application scenarios, such as MSO and DSL; 2. Add support to a deployment scenario of partly protection raised by some= service providers; 3. Add Chenbin and Yimin to our co-authors; 4. Substantial editorial changes.=20 Please feedback you opinions on this version. Thanks! Regards, Yuanlong -----Original Message----- From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]=20 Sent: Wednesday, April 02, 2014 11:19 AM To: Yimin Shen; Luoyong (Dennis); Chengbin Shen; Chengbin Shen; Edwin Malle= tte; Yimin Shen; Edwin Mallette; Jiangyuanlong; Jiangyuanlong; Luoyong (Den= nis) Subject: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt A new version of I-D, draft-jiang-pwe3-mc-pon-02.txt has been successfully submitted by Yuanlong Jiang and posted to the IETF repository. Name: draft-jiang-pwe3-mc-pon Revision: 02 Title: Multi-chassis PON Protection in MPLS Document date: 2014-04-02 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-jiang-pwe3-mc-pon= -02.txt Status: https://datatracker.ietf.org/doc/draft-jiang-pwe3-mc-pon/ Htmlized: http://tools.ietf.org/html/draft-jiang-pwe3-mc-pon-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-pwe3-mc-pon-= 02 Abstract: MPLS is being deployed deeper into operator networks, often to or past the access network node. Separately network access nodes such as PON OLTs have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multi-homing support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the multi-chassis PON protection architecture in MPLS and also proposes the ICCP extension to support it. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 24 07:28:02 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91821A03B5; Thu, 24 Jul 2014 07:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMBG_RfVP9Nc; Thu, 24 Jul 2014 07:27:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C8B1A0354; Thu, 24 Jul 2014 07:27:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724142756.13227.84689.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 07:27:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/NY86NX5KdNvbFLQC9UMFogiVhgo Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-endpoint-fast-protection-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:27:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : PW Endpoint Fast Failure Protection Authors : Yimin Shen Rahul Aggarwal Wim Henderickx Yuanlong Jiang Filename : draft-ietf-pwe3-endpoint-fast-protection-01.txt Pages : 29 Date : 2014-07-24 Abstract: This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Designed on the basis of multi-homed CE, PW redundancy, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. In particular, the router can restore PW traffic in the order of tens of milliseconds, by transmitting the traffic to a protector through a pre-established bypass tunnel. Therefore, the mechanism can reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-endpoint-fast-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pwe3-endpoint-fast-protection-01 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 nobody Thu Jul 24 12:04:40 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52911A002A for ; Thu, 24 Jul 2014 12:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoIOTZWJWub4 for ; Thu, 24 Jul 2014 12:04:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D84D1A0146 for ; Thu, 24 Jul 2014 12:04:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKM51997; Thu, 24 Jul 2014 19:04:35 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 20:04:34 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Fri, 25 Jul 2014 03:04:22 +0800 From: Jiangyuanlong To: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" , "pwe3@ietf.org" Thread-Topic: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt Thread-Index: Ac+m9PJodoQ98eygQUujszevc3JAUgAdmh6A Date: Thu, 24 Jul 2014 19:04:22 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A780EBC@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/RJU0Hd93T_8jfNy3aR7X1G0EIVE Cc: Zhuhengjun Subject: Re: [PWE3] New Version Notification for draft-jiang-pwe3-mc-pon-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:04:38 -0000 Hi Joshi, Thank you for the detailed comments, please see my comments inline. Best regards, Yuanlong -----Original Message----- From: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) [mailto:shrinivas_ashok.josh= i@alcatel-lucent.com]=20 Sent: Thursday, July 24, 2014 12:09 PM To: pwe3@ietf.org; Jiangyuanlong Subject: Re: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt Hi Yuanlong, Thanks for including DSL and P2P in use cases in Introduction. However the = TLV's and procedures are still PON specific. I would suggest to make the TLV and procedures generic so they are applicab= le to DSL and P2P Ethernet as well. [YJ] I agree that most TLVs and procedures may be similar, but have some do= ubts that TLVs of PON and the others may use the same format, such as per S= ec. 4.1.5. "PON ONU Database Sync TLV", it seems they do have their special= parameters. But what concerns me most is the scalability and economics of = DSL dual-homing, unlike PON trunk protection where a tree of ONUs can be pr= otected by merely two trunk links, DSL needs two subscriber line for each u= ser. However, opinions from service providers are needed.=20 Also in access network i.e. PON and P2P ethernet there is significant amoun= t of dynamic information e.g. DHCP leases, PPP sessions etc which are maint= ained by OLT for each subscriber, the draft should cover the procedure for = synchronization of this dynamic information between the two OLT's. [YJ] This is a good problem space, we can add these materials definitely if= the WG have a consensus, and your inputs will be greatly appreciated. One additional point current draft does not cover the procedure for PON con= figuration TLV when & how it would be used. [YL] it is used in configuration phase, and a device (OLT or router with PO= N interfaces) notifies its peer what its local configuration is. We will ad= d some texts into the next revision to make it clear.=20 Also it would be good to have some discussion/feedback on mailing list on t= he expanded draft to see if it covers all scenario's. [YL] Yes, more discussions are greatly welcome and helpful to drive this wo= rk. Thanks -- Shrinivas Joshi -----Original Message----- Hi colleagues, =20 We had updated the draft to a new revision. The main updates include: 1. Add more application scenarios, such as MSO and DSL; 2. Add support to a deployment scenario of partly protection raised by some= service providers; 3. Add Chenbin and Yimin to our co-authors; 4. Substantial editorial changes.=20 Please feedback you opinions on this version. Thanks! Regards, Yuanlong -----Original Message----- From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]=20 Sent: Wednesday, April 02, 2014 11:19 AM To: Yimin Shen; Luoyong (Dennis); Chengbin Shen; Chengbin Shen; Edwin Malle= tte; Yimin Shen; Edwin Mallette; Jiangyuanlong; Jiangyuanlong; Luoyong (Den= nis) Subject: New Version Notification for draft-jiang-pwe3-mc-pon-02.txt A new version of I-D, draft-jiang-pwe3-mc-pon-02.txt has been successfully submitted by Yuanlong Jiang and posted to the IETF repository. Name: draft-jiang-pwe3-mc-pon Revision: 02 Title: Multi-chassis PON Protection in MPLS Document date: 2014-04-02 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-jiang-pwe3-mc-pon= -02.txt Status: https://datatracker.ietf.org/doc/draft-jiang-pwe3-mc-pon/ Htmlized: http://tools.ietf.org/html/draft-jiang-pwe3-mc-pon-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-jiang-pwe3-mc-pon-= 02 Abstract: MPLS is being deployed deeper into operator networks, often to or past the access network node. Separately network access nodes such as PON OLTs have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multi-homing support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the multi-chassis PON protection architecture in MPLS and also proposes the ICCP extension to support it. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 24 13:43:13 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED181ADDC6; Thu, 24 Jul 2014 13:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Zh2MYgYLYk; Thu, 24 Jul 2014 13:43:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 820001A0A9D; Thu, 24 Jul 2014 13:43:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724204309.28101.81871.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 13:43:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/S830NX0iQA8fIYc2QVpUesE78yA Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-congcons-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:43:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire Congestion Considerations Authors : Yaakov (Jonathan) Stein David L. Black Bob Briscoe Filename : draft-ietf-pwe3-congcons-02.txt Pages : 22 Date : 2014-07-24 Abstract: Pseudowires (PWs) have become a common mechanism for tunneling traffic, and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. It is thus worthwhile specifying under what conditions such competition is safe, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as TDM PWs) we derive a bound under which such PWs consume no more network capacity than a TCP flow. We also propose employing a transport circuit breaker [I-D.fairhurst-tsvwg-circuit-breaker] that shuts down a TDM PW consistently surpassing this bound, as the emulated TDM service itself would be be of insufficient quality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-congcons/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pwe3-congcons-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 nobody Thu Jul 24 13:52:09 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581E51A03BD for ; Thu, 24 Jul 2014 13:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4yEYfhqt8Eu for ; Thu, 24 Jul 2014 13:52:07 -0700 (PDT) Received: from rad.co.il (mailrelay01-ib1.rad.com [94.188.133.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D653A1A035D for ; Thu, 24 Jul 2014 13:52:06 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES256-SHA encrypted SMTP; 24 Jul 2014 23:39:50 +0300 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 24 Jul 2014 23:52:00 +0300 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Thu, 24 Jul 2014 23:52:00 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: [PWE3] I-D Action: draft-ietf-pwe3-congcons-02.txt Thread-Index: AQHPp3/padlYTvljHUSVDq9zqa1LVJuvsu3w Date: Thu, 24 Jul 2014 20:51:59 +0000 Message-ID: References: <20140724204309.28101.81871.idtracker@ietfa.amsl.com> In-Reply-To: <20140724204309.28101.81871.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090208.53D171F2.012C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 (Unknown) Spam-Score: -2.40 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/9fahb9I-IHETMl7zNGF13mlMcdM Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-congcons-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:52:08 -0000 Please look at the PDF version only (the txt version does not have the graphs). Y(J)S -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: 24 July, 2014 16:43 To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-congcons-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : Pseudowire Congestion Considerations Authors : Yaakov (Jonathan) Stein David L. Black Bob Briscoe Filename : draft-ietf-pwe3-congcons-02.txt Pages : 22 Date : 2014-07-24 Abstract: Pseudowires (PWs) have become a common mechanism for tunneling traffic, and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. It is thus worthwhile specifying under what conditions such competition is safe, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as TDM PWs) we derive a bound under which such PWs consume no more network capacity than a TCP flow. We also propose employing a transport circuit breaker [I-D.fairhurst-tsvwg-circuit-breaker] that shuts down a TDM PW consistently surpassing this bound, as the emulated TDM service itself would be be of insufficient quality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-congcons/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-congcons-02 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Fri Jul 25 07:29:42 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE941B2977 for ; Fri, 25 Jul 2014 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCb7Ed27FMmD for ; Fri, 25 Jul 2014 07:29:26 -0700 (PDT) Received: from rad.co.il (mailrelay02-ib2.rad.com [91.143.228.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9AB1B2968 for ; Fri, 25 Jul 2014 07:29:25 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES256-SHA encrypted SMTP; 25 Jul 2014 17:29:21 +0300 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 25 Jul 2014 17:29:20 +0300 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Fri, 25 Jul 2014 17:29:08 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: not with a bang but a whimper Thread-Index: Ac+oFMhGPtIHRn5RRr6nq3Flkv1j8Q== Date: Fri, 25 Jul 2014 14:29:07 +0000 Message-ID: <560d4ed77488400199a101d12731079d@exrad6.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: multipart/alternative; boundary="_000_560d4ed77488400199a101d12731079dexrad6adradcoil_" MIME-Version: 1.0 Spam-Score: -2.40 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/dS1SLAv2XUQ8s3X8SS664T4DuvA Subject: [PWE3] not with a bang but a whimper X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:29:34 -0000 --_000_560d4ed77488400199a101d12731079dexrad6adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yesterday we held the 40th and final PWE3 WG meeting. There will be no PWE3 meeting in Honolulu. Not that the IETF has decided that all of our work is complete (although IMO we could have decided that a few years ago) but due to a reorg in the routing area. It has been about 14 years since the original Martini (ATM), Malis (SDH), a= nd Anavi (TDM) drafts, the CEOT, PWOT, and PWE3 BoFs, leading to the formation of PWE3 in time for= IETF-51. Just before the meeting I submitted a new version of the congestion conside= rations draft, a draft which I was originally asked to produce by transport AD Scott Bradn= er. Indeed, it was because of congestion considerations that PWE3 was originall= y in the transport area, before being moved to the Internet and thereafter to routing areas. I would like to say that it has been a fun 14 years, and thank everyone who has contributed to the formation of PWE3 technology. Y(J)S --_000_560d4ed77488400199a101d12731079dexrad6adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yesterday we held the 40th and final PWE3= WG meeting.

There will be no PWE3 meeting in Honolulu.

 

Not that the IETF has decided that all of our work i= s complete

(although IMO we could have decided that a few years= ago)

but due to a reorg in the routing area.

 

It has been about 14 years since the original Martin= i (ATM), Malis (SDH), and Anavi (TDM) drafts,

the CEOT, PWOT, and PWE3 BoFs, leading to the format= ion of PWE3 in time for IETF-51.

 

Just before the meeting I submitted a new version of= the congestion considerations draft,

a draft which I was originally asked to produce by t= ransport AD Scott Bradner.

Indeed, it was because of congestion considerations = that PWE3 was originally in the transport area,

before being moved to the Internet and thereafter to= routing areas.

 

I would like to say that it has been a fun 14 years,=

and thank everyone who has contributed to the format= ion of PWE3 technology.

 

Y(J)S

 

--_000_560d4ed77488400199a101d12731079dexrad6adradcoil_-- From nobody Fri Jul 25 07:51:54 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66871B27AF for ; Fri, 25 Jul 2014 07:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyDbLsXbD1xb for ; Fri, 25 Jul 2014 07:51:51 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434DF1A02E7 for ; Fri, 25 Jul 2014 07:51:51 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id k15so4739646qaq.27 for ; Fri, 25 Jul 2014 07:51:49 -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=qj3S4syRdjNpQN4GXjSFePStTvoFEMYCaUEoJET5vkE=; b=I9wbh/mFwTnA7akzPLAYf9tY+9dgoZT9HkDkOwWE9JzWtgvYxxM75D4RW4fjJd47fa oxJKlo4J18yzF5IicmNTZ5kWH2acRBFBcXDTl90dk6IRwA4cKVrWaizaRWGtS1bYCfSy EFvgfAqhI5iS3FeBKw1u1fKdhcPH6hqpjDR8OFbY0PdsyAqC718Bph6p7uAWZTvA7I9t thP0Cx7p2meFg47N0pl1RhOWWiLtpFGxJ2XEM/J+g8IqRBysjogoCl7f88szDSQgL2Ps inb5IfpEKHuzD6C6Bl6j30rqa03AirjL9dbxm1Ap0g7Tlmcs2tMG/DlVm8rSTdH6C1Ig 5tKA== X-Received: by 10.140.37.178 with SMTP id r47mr26772820qgr.59.1406299909685; Fri, 25 Jul 2014 07:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Fri, 25 Jul 2014 07:51:29 -0700 (PDT) In-Reply-To: <560d4ed77488400199a101d12731079d@exrad6.ad.rad.co.il> References: <560d4ed77488400199a101d12731079d@exrad6.ad.rad.co.il> From: "Andrew G. Malis" Date: Fri, 25 Jul 2014 10:51:29 -0400 Message-ID: To: Yaakov Stein Content-Type: multipart/alternative; boundary=001a11c15352908a1c04ff05b644 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Ea_GNgTxrL-W2TSo_lAv7T2BLb4 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] not with a bang but a whimper X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:51:53 -0000 --001a11c15352908a1c04ff05b644 Content-Type: text/plain; charset=UTF-8 Yaakov, Thanks for bring this up, and for your contributions to the PWE3 WG over the years. And of course, thanks to everyone else that has contribututed as well! PWEers, to add to Yaakov's email, and for the benefit of those of you not in Toronto (or in Toronto but not at the Routing Area meeting), I highly recommend that you read the slide deck presented at the Routing Area meeting yesterday, which you can find at http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-3.ppt . The details of the Routing Area reorganization start at slide 26 in this deck. There may be fine-tuning as we work on the new WG charters, but for the most part, PWE3's work will continue in the new "LDP-enabled services" working group. For now, it's still business as usual, and we will continue the PWE3 WG work on the existing PWE3 email list. Any changes to this will be announced on this list. Cheers, Andy On Fri, Jul 25, 2014 at 10:29 AM, Yaakov Stein wrote: > Yesterday we held the 40th and final PWE3 WG meeting. > > There will be no PWE3 meeting in Honolulu. > > > > Not that the IETF has decided that all of our work is complete > > (although IMO we could have decided that a few years ago) > > but due to a reorg in the routing area. > > > > It has been about 14 years since the original Martini (ATM), Malis (SDH), > and Anavi (TDM) drafts, > > the CEOT, PWOT, and PWE3 BoFs, leading to the formation of PWE3 in time > for IETF-51. > > > > Just before the meeting I submitted a new version of the congestion > considerations draft, > > a draft which I was originally asked to produce by transport AD Scott > Bradner. > > Indeed, it was because of congestion considerations that PWE3 was > originally in the transport area, > > before being moved to the Internet and thereafter to routing areas. > > > > I would like to say that it has been a fun 14 years, > > and thank everyone who has contributed to the formation of PWE3 technology. > > > > Y(J)S > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --001a11c15352908a1c04ff05b644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yaakov,

Thanks for bring thi= s up, and for your contributions to the PWE3 WG over the years.
<= br>
And of course, thanks to everyone else that has contribututed= as well!

PWEers, to add to Yaakov's email, and for the benef= it of those of you not in Toronto (or in Toronto but not at the Routing Are= a meeting), I highly recommend that you read the slide deck presented at th= e Routing Area meeting yesterday, which you can find at=C2=A0http://www.= ietf.org/proceedings/90/slides/slides-90-rtgarea-3.ppt . The details of= the Routing Area reorganization start at slide 26 in this deck.=C2=A0

There may be fine-tuning as we work on the new WG chart= ers, but for the most part, PWE3's work will continue in the new "= LDP-enabled services" working group. For now, it's still business = as usual, and we will continue the PWE3 WG work on the existing PWE3 email = list. Any changes to this will be announced on this list.

Cheers,
Andy


On Fri, Jul 25, 2014 at 10:29 AM, = Yaakov Stein <yaakov_s@rad.com> wrote:

Yesterday we held the 40th and final PWE3= WG meeting.

There will be no PWE3 meeting in Honolulu.=

=C2=A0

Not that the IETF has decided that all of our work i= s complete

(although IMO we could have decided that a few years= ago)

but due to a reorg in the routing area.

=C2=A0

It has been about 14 years since the original Martin= i (ATM), Malis (SDH), and Anavi (TDM) drafts,

the CEOT, PWOT, and PWE3 BoFs, leading to the format= ion of PWE3 in time for IETF-51.

=C2=A0

Just before the meeting I submitted a new version of= the congestion considerations draft,

a draft which I was originally asked to produce by t= ransport AD Scott Bradner.

Indeed, it was because of congestion considerations = that PWE3 was originally in the transport area,

before being moved to the Internet and thereafter to= routing areas.

=C2=A0

I would like to say that it has been a fun 14 years,=

and thank everyone who has contributed to the format= ion of PWE3 technology.

=C2=A0

Y(J)S

=C2=A0


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


--001a11c15352908a1c04ff05b644-- From nobody Fri Jul 25 07:57:18 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD10D1B29C0 for ; Fri, 25 Jul 2014 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X60WYaLVqJrG for ; Fri, 25 Jul 2014 07:57:14 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74EC1B29B6 for ; Fri, 25 Jul 2014 07:57:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6PEv6ZD003057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jul 2014 09:57:08 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6PEuMUE021286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Jul 2014 16:57:00 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 25 Jul 2014 16:56:04 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Thread-Topic: WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqBiOFwGKWlhnR0Cl4HRHJXR0fQ== Date: Fri, 25 Jul 2014 14:56:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <449ED3861D314E4CB0C861DDC79AE47F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/1l48L5ZH-tv3eDU13WBhR3l1bUs Subject: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:57:17 -0000 This email begins a second two week working group last call for http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . Please review the draft and post any comments to the PWE3 list. If you have read the draft, even if you don=B9t have any comments, but woul= d like to see the draft progressed, please can you indicate this to the list. This working group last call will end on Friday August 8th, 2014. Best regards Matthew and Andy From nobody Fri Jul 25 08:01:27 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D661B29C1 for ; Fri, 25 Jul 2014 08:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3T4CowU_ovg for ; Fri, 25 Jul 2014 08:01:16 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413BE1A02D1 for ; Fri, 25 Jul 2014 08:01:16 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6PF1Cck003949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jul 2014 10:01:15 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6PF0LMV000967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Jul 2014 17:01:09 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 25 Jul 2014 17:00:28 +0200 From: "Henderickx, Wim (Wim)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqBkrz1cuClV2ZEa4ZJz+eA8Q3w== Date: Fri, 25 Jul 2014 15:00:28 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="euc-kr" Content-ID: <7BE4531282AD6D43A48DE069EC052F0D@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/1-ycIlZeUFo2iM5BpZjxNIFvcnU Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:01:25 -0000 QXMgYSBjby1hdXRob3IgSSByZWFkIHRoaXMgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkNCg0KT24g MjUvMDcvMTQgMTA6NTYsICJCb2NjaSwgTWF0dGhldyAoTWF0dGhldykiDQo8bWF0dGhldy5ib2Nj aUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KDQo+VGhpcyBlbWFpbCBiZWdpbnMgYSBzZWNv bmQgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yDQo+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wd2UzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi0wMSAu DQo+DQo+UGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHBvc3QgYW55IGNvbW1lbnRzIHRvIHRo ZSBQV0UzIGxpc3QuDQo+DQo+SWYgeW91IGhhdmUgcmVhZCB0aGUgZHJhZnQsIGV2ZW4gaWYgeW91 IGRvbqn2dCBoYXZlIGFueSBjb21tZW50cywgYnV0IHdvdWxkDQo+bGlrZSB0byBzZWUgdGhlIGRy YWZ0IHByb2dyZXNzZWQsICBwbGVhc2UgY2FuIHlvdSBpbmRpY2F0ZSB0aGlzIHRvIHRoZQ0KPmxp c3QuDQo+DQo+VGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB3aWxsIGVuZCBvbiBGcmlkYXkg QXVndXN0IDh0aCwgMjAxNC4NCj4NCj4NCj5CZXN0IHJlZ2FyZHMNCj4NCj4NCj5NYXR0aGV3IGFu ZCBBbmR5DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5wd2UzIG1haWxpbmcgbGlzdA0KPnB3ZTNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCg0K From nobody Fri Jul 25 08:23:31 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B51C1B287A for ; Fri, 25 Jul 2014 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmW6bRIzeU6w for ; Fri, 25 Jul 2014 08:23:20 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F36B1A0318 for ; Fri, 25 Jul 2014 08:23:20 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so4573252qaq.39 for ; Fri, 25 Jul 2014 08:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ms8RxTf/96IPpHE34HlueMWfrjqg4DFTan0blv3oer8=; b=AHYEBC72c7cV3NPXVK7KMXbu0SfctY3mgOM1PbY1Esw+eAHzMeeByB4g49/B6cJqvv maRv21CaEWBqVEOlZ/TbprWVhnMYGLkh/dwAu8GVydPBCbCShcR7L8DXDoQilsZ/5UBA WOPJnlv13GtnQFR17i19935zGZcSZEsBte+4Mgt1jH9jb6CzS02VDHjsJxspXeBSnBt5 W+GjkBEXicw5V+B7aBs8vt98ITR/emARdJhzNcZYY+usUBfcycJcP0+y10lu9hhs0Ny+ taR8HKWGbjWxzcpnVhA8TgOIwbFPwdYHOUMtfsUHcb2fEuWsmodkkyXJzds2MeH4ezPk Nq2w== X-Received: by 10.140.88.41 with SMTP id s38mr16472135qgd.73.1406301799547; Fri, 25 Jul 2014 08:23:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Fri, 25 Jul 2014 08:22:59 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 25 Jul 2014 11:22:59 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a11c13e7e358b3004ff062785 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/_6GxX-Vmfy3fXuULe5Tpm-kNbR8 Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:23:26 -0000 --001a11c13e7e358b3004ff062785 Content-Type: text/plain; charset=UTF-8 http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG last call. As part of the last call process, we need to poll the authors and WG for IPR information on the draft. Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there are currently no IPR disclosures in the IETF datatracker. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the PWE3 WG mailing list. The document will not advance to the next stage until a response has been received from each author and each contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Andy --001a11c13e7e358b3004ff062785 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://www.ietf.org/id/draft-ietf= -pwe3-congcons-02.pdf is now in PWE3 WG last call. As part of the last = call process, we need to poll the authors and WG for IPR information on the= draft.

Are you aware of any=C2=A0IPR= =C2=A0that applies to=C2=A0draft-ietf-pwe3-congcons-02?

If so, has this=C2=A0IPR=C2=A0been disclosed in compliance with IETF=C2=A0IPR=C2=A0rules
(see RFCs 3979,= 4879, 3669 and 5378 for more details)? Note that there
are currently no=C2=A0IPR=C2=A0disclosures in the IETF datatracker.

If you are listed as a document = author or contributor please respond
to this email r= egardless of whether or not you are aware of any
relevant=C2=A0I= PR. The = response needs to be sent to the PWE3 WG mailing
list. The docum= ent will not advance to the next stage until a response
has been received from each author and each c= ontributor.

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=C2=A0=C2= =A0that has not yet been disclosed in conformance with IETF
rules.
Thanks,
Andy
=
--001a11c13e7e358b3004ff062785-- From nobody Fri Jul 25 08:24:37 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504051B2925 for ; Fri, 25 Jul 2014 08:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu6X5xb9qFOa for ; Fri, 25 Jul 2014 08:24:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7451B287A for ; Fri, 25 Jul 2014 08:24:28 -0700 (PDT) Received: from BY2PR05CA002.namprd05.prod.outlook.com (10.242.32.32) by CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 25 Jul 2014 15:24:27 +0000 Received: from BY2FFO11FD010.protection.gbl (2a01:111:f400:7c0c::124) by BY2PR05CA002.outlook.office365.com (2a01:111:e400:2c2a::32) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Fri, 25 Jul 2014 15:24:26 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Fri, 25 Jul 2014 15:24:26 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 25 Jul 2014 08:24:26 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s6PFOPn92012 for ; Fri, 25 Jul 2014 08:24:25 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201407251524.s6PFOPn92012@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91461.1406301864.1@juniper.net> Date: Fri, 25 Jul 2014 08:24:25 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(199002)(189002)(51704005)(105596002)(83322001)(81542001)(85852003)(74662001)(2351001)(110136001)(31966008)(16796002)(95666004)(47776003)(81156004)(97756001)(107046002)(46406003)(86362001)(81342001)(84676001)(15202345003)(20776003)(4396001)(107886001)(106466001)(46102001)(6806004)(92726001)(92566001)(74502001)(44976005)(19580395003)(85306003)(79102001)(102836001)(83072002)(54356999)(76482001)(229853001)(80022001)(99396002)(23726002)(77982001)(97736001)(15975445006)(69596002)(87936001)(21056001)(50986999)(50466002)(64706001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB732; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02830F0362 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/-BX0ZNi33px3tS51CXBR7mzPrD4 Subject: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:24:35 -0000 Hi, > This email begins a second two week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . > > Please review the draft and post any comments to the PWE3 list. > > If you have read the draft, even if you don't have any comments, but would > like to see the draft progressed, please can you indicate this to the list. > > This working group last call will end on Friday August 8th, 2014. I would like to see the draft progressed. Yakov. From nobody Fri Jul 25 10:39:14 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCFC1A0334 for ; Fri, 25 Jul 2014 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuwIkSEUM5OC for ; Fri, 25 Jul 2014 10:39:12 -0700 (PDT) Received: from rad.co.il (mailrelay01-ib2.rad.com [91.143.228.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D081A0309 for ; Fri, 25 Jul 2014 10:39:11 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES256-SHA encrypted SMTP; 25 Jul 2014 20:26:51 +0300 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 25 Jul 2014 20:39:04 +0300 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Fri, 25 Jul 2014 20:39:04 +0300 From: Yaakov Stein To: "Andrew G. Malis" , "pwe3@ietf.org" Thread-Topic: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 Thread-Index: AQHPqBxqzwhORIesakKxufe7h6gk5JuxDkQQ Date: Fri, 25 Jul 2014 17:39:03 +0000 Message-ID: <0a58870234304bcc94cb11311e5b87dd@exrad6.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: multipart/alternative; boundary="_000_0a58870234304bcc94cb11311e5b87ddexrad6adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0C0206.53D2963C.003A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 (Unknown) Spam-Score: -2.00 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/8aq4dymEhmGzZA95iWO4U2x9ov4 Subject: Re: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:39:13 -0000 --_000_0a58870234304bcc94cb11311e5b87ddexrad6adradcoil_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWdhcmRpbmcgdGhpcyBkcmFmdC4NCg0KWShKKVMN Cg0KRnJvbTogcHdlMyBbbWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFuZHJldyBHLiBNYWxpcw0KU2VudDogMjUgSnVseSwgMjAxNCAxMToyMw0KVG86IHB3ZTNAaWV0 Zi5vcmcNClN1YmplY3Q6IFtQV0UzXSBJUFIgcG9sbCBmb3IgZHJhZnQtaWV0Zi1wd2UzLWNvbmdj b25zLTAyDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25z LTAyLnBkZiBpcyBub3cgaW4gUFdFMyBXRyBsYXN0IGNhbGwuIEFzIHBhcnQgb2YgdGhlIGxhc3Qg Y2FsbCBwcm9jZXNzLCB3ZSBuZWVkIHRvIHBvbGwgdGhlIGF1dGhvcnMgYW5kIFdHIGZvciBJUFIg aW5mb3JtYXRpb24gb24gdGhlIGRyYWZ0Lg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMj8NCg0KSWYgc28sIGhhcyB0 aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMN CihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyBO b3RlIHRoYXQgdGhlcmUNCmFyZSBjdXJyZW50bHkgbm8gSVBSIGRpc2Nsb3N1cmVzIGluIHRoZSBJ RVRGIGRhdGF0cmFja2VyLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhv ciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZA0KdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNz IG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55DQpyZWxldmFudCBJUFIuIFRo ZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBQV0UzIFdHIG1haWxpbmcNCmxpc3Qu IFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEg cmVzcG9uc2UNCmhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGVhY2ggY29u dHJpYnV0b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIFBXRTMgV0cgZW1haWwgbGlzdCBidXQgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yDQpvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhw bGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZQ0Kb2YgYW55IElQUiB0aGF0IGhh cyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURg0KcnVsZXMu DQoNClRoYW5rcywNCkFuZHkNCg== --_000_0a58870234304bcc94cb11311e5b87ddexrad6adradcoil_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVnYXJk aW5nIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZKEopUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcHdlMyBbbWFpbHRv OnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEcuIE1h bGlzPGJyPg0KPGI+U2VudDo8L2I+IDI1IEp1bHksIDIwMTQgMTE6MjM8YnI+DQo8Yj5Ubzo8L2I+ IHB3ZTNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1BXRTNdIElQUiBwb2xsIGZvciBk cmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMi5wZGYiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyLnBkZjwvYT4gaXMgbm93IGluIFBXRTMgV0cgbGFz dCBjYWxsLiBBcyBwYXJ0IG9mIHRoZSBsYXN0IGNhbGwgcHJvY2Vzcywgd2UNCiBuZWVkIHRvIHBv bGwgdGhlIGF1dGhvcnMgYW5kIFdHIGZvciBJUFIgaW5mb3JtYXRpb24gb24gdGhlIGRyYWZ0Ljwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpBcmUgeW91IGF3YXJl IG9mIGFueSZuYnNwOzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGRkZGQ0MiPklQUjwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwO3RoYXQgYXBwbGllcyB0byZuYnNwO2RyYWZ0LWlldGYtcHdl My1jb25nY29ucy0wMj88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJy Pg0KSWYgc28sIGhhcyB0aGlzJm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+ SVBSPC9zcGFuPiZuYnNwO2JlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGJm5i c3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPiZuYnNwO3J1bGVz PGJyPg0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cyk/IE5vdGUgdGhhdCB0aGVyZTxicj4NCmFyZSBjdXJyZW50bHkgbm8mbmJzcDs8c3BhbiBzdHls ZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3NwYW4+Jm5ic3A7ZGlzY2xvc3VyZXMgaW4gdGhl IElFVEYgZGF0YXRyYWNrZXIuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1 bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQ8YnI+DQp0byB0aGlzIGVt YWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnk8YnI+ DQpyZWxldmFudCZuYnNwOzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGRkZGQ0MiPklQUjwvc3Bh bj4uIFRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBQV0UzIFdHIG1haWxpbmc8 YnI+DQpsaXN0LiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFn ZSB1bnRpbCBhIHJlc3BvbnNlPGJyPg0KaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhv ciBhbmQgZWFjaCBjb250cmlidXRvci48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIG9uIHRoZSBQV0Uz IFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcjxicj4NCm9yIGNv bnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJl IGF3YXJlPGJyPg0Kb2YgYW55Jm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+ SVBSPC9zcGFuPiZuYnNwO3RoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9y bWFuY2Ugd2l0aCBJRVRGPGJyPg0KcnVsZXMuPGJyPg0KPGJyPg0KVGhhbmtzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5BbmR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0a58870234304bcc94cb11311e5b87ddexrad6adradcoil_-- From nobody Fri Jul 25 13:52:46 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527431A0252 for ; Fri, 25 Jul 2014 13:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTgBfAwQJhl2 for ; Fri, 25 Jul 2014 13:52:41 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5CF1A024E for ; Fri, 25 Jul 2014 13:52:41 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id h136so3773034oig.7 for ; Fri, 25 Jul 2014 13:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GwOXxz4Z9GZpPdqSROWIL0Yzv8kY7faCl5Uc0/3njbI=; b=FGir71OX+ScyxtOd15Cgh0Nau6gfmSTt5TQcUmsHXpfiibuxZ6kZC6DGfamaizhesu qxNqsG+dlq87HG8p+bm494SDqa/Yq8ITixr0QL1vgP22IETBTSSQcMwL9EK0/q6uPnAU Lvt2B27RLU1GNyRRQj6MsNzCjpkzeB0MOPN21pswq5VgQVrHvjFa/rX0PhJMuqT11eho +uAvCcKPH3d1UaMag7WMDPbNOKMTi45Ah0mFYZmxIdQzsgK8yUbZmY/mPEy19jd1NpUj US4YCtgDb5Ye3VQvm+r8N5bRw+Qszf4WdYHAGI1NkWfTsKiDdyI9kmXFH593z/JVuNIS 8O+g== X-Received: by 10.60.125.103 with SMTP id mp7mr26819358oeb.53.1406321560435; Fri, 25 Jul 2014 13:52:40 -0700 (PDT) MIME-Version: 1.0 Sender: amalis@gmail.com Received: by 10.76.170.137 with HTTP; Fri, 25 Jul 2014 13:52:20 -0700 (PDT) In-Reply-To: References: <560d4ed77488400199a101d12731079d@exrad6.ad.rad.co.il> From: "Andrew G. Malis" Date: Fri, 25 Jul 2014 16:52:20 -0400 X-Google-Sender-Auth: qRvO_QYTAmErEL6rHFzBpeo8xx8 Message-ID: To: "Andrew G. Malis" Content-Type: multipart/alternative; boundary=047d7b3442fc0cd00404ff0ac10f Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/HWE6OCrq_9j-SQFh_Dvsc4dzwfk Cc: Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] not with a bang but a whimper X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 20:52:43 -0000 --047d7b3442fc0cd00404ff0ac10f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable An update from today: The =E2=80=9CLDP-Enabled Services (LES)=E2=80=9D work= ing group has been renamed as =E2=80=9CPseudowire- and LDP-enabled Services (PALS)=E2=80= =9D. Cheers, Andy On Fri, Jul 25, 2014 at 10:51 AM, Andrew G. Malis wrote= : > Yaakov, > > Thanks for bring this up, and for your contributions to the PWE3 WG over > the years. > > And of course, thanks to everyone else that has contribututed as well! > > PWEers, to add to Yaakov's email, and for the benefit of those of you not > in Toronto (or in Toronto but not at the Routing Area meeting), I highly > recommend that you read the slide deck presented at the Routing Area > meeting yesterday, which you can find at > http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-3.ppt . The > details of the Routing Area reorganization start at slide 26 in this deck= . > > There may be fine-tuning as we work on the new WG charters, but for the > most part, PWE3's work will continue in the new "LDP-enabled services" > working group. For now, it's still business as usual, and we will continu= e > the PWE3 WG work on the existing PWE3 email list. Any changes to this wil= l > be announced on this list. > > Cheers, > Andy > > > On Fri, Jul 25, 2014 at 10:29 AM, Yaakov Stein wrote: > >> Yesterday we held the 40th and final PWE3 WG meeting. >> >> There will be no PWE3 meeting in Honolulu. >> >> >> >> Not that the IETF has decided that all of our work is complete >> >> (although IMO we could have decided that a few years ago) >> >> but due to a reorg in the routing area. >> >> >> >> It has been about 14 years since the original Martini (ATM), Malis (SDH)= , >> and Anavi (TDM) drafts, >> >> the CEOT, PWOT, and PWE3 BoFs, leading to the formation of PWE3 in time >> for IETF-51. >> >> >> >> Just before the meeting I submitted a new version of the congestion >> considerations draft, >> >> a draft which I was originally asked to produce by transport AD Scott >> Bradner. >> >> Indeed, it was because of congestion considerations that PWE3 was >> originally in the transport area, >> >> before being moved to the Internet and thereafter to routing areas. >> >> >> >> I would like to say that it has been a fun 14 years, >> >> and thank everyone who has contributed to the formation of PWE3 >> technology. >> >> >> >> Y(J)S >> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --047d7b3442fc0cd00404ff0ac10f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
An update from today:=C2=A0The =E2=80=9CLDP-Enabled Servic= es (LES)=E2=80=9D working group has been renamed as =E2=80=9CPseudowire- an= d LDP-enabled Services (PALS)=E2=80=9D.

Cheers,
Andy



On Fri, Jul 25, 2014 at 10:51 AM, Andrew= G. Malis <agmalis@gmail.com> wrote:
Yaakov,

Thanks for bring thi= s up, and for your contributions to the PWE3 WG over the years.
<= br>
And of course, thanks to everyone else that has contribututed= as well!

PWEers, to add to Yaakov's email, and for the benef= it of those of you not in Toronto (or in Toronto but not at the Routing Are= a meeting), I highly recommend that you read the slide deck presented at th= e Routing Area meeting yesterday, which you can find at=C2=A0http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-3.ppt . The details of the Routing Area reorganization start at slide 26 in thi= s deck.=C2=A0

There may be fine-tuning as we work on the new WG chart= ers, but for the most part, PWE3's work will continue in the new "= LDP-enabled services" working group. For now, it's still business = as usual, and we will continue the PWE3 WG work on the existing PWE3 email = list. Any changes to this will be announced on this list.

Cheers,
Andy


Yesterday we held the 40th and final PWE3= WG meeting.

There will be no PWE3 meeting in Honolulu.=

=C2=A0

Not that the IETF has decided that all of our work i= s complete

(although IMO we could have decided that a few years= ago)

but due to a reorg in the routing area.

=C2=A0

It has been about 14 years since the original Martin= i (ATM), Malis (SDH), and Anavi (TDM) drafts,

the CEOT, PWOT, and PWE3 BoFs, leading to the format= ion of PWE3 in time for IETF-51.

=C2=A0

Just before the meeting I submitted a new version of= the congestion considerations draft,

a draft which I was originally asked to produce by t= ransport AD Scott Bradner.

Indeed, it was because of congestion considerations = that PWE3 was originally in the transport area,

before being moved to the Internet and thereafter to= routing areas.

=C2=A0

I would like to say that it has been a fun 14 years,=

and thank everyone who has contributed to the format= ion of PWE3 technology.

=C2=A0

Y(J)S

=C2=A0


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



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


--047d7b3442fc0cd00404ff0ac10f-- From nobody Sat Jul 26 22:22:58 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D388A1A007B for ; Sat, 26 Jul 2014 22:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqiuc9x35Uja for ; Sat, 26 Jul 2014 22:22:49 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42FA1A0022 for ; Sat, 26 Jul 2014 22:22:48 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so6944478qgf.21 for ; Sat, 26 Jul 2014 22:22:48 -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=/GDvFQLnX3Pa5H1qnUwDK0yQENd3b9ntGVdaAd74Hw8=; b=lxrZVNaTOTsxcGZUUdTGg7J+oES7WGrekKlaRlwu7lGxjJR0g8hxPOLc8zvjp96x33 iETy3bNqNFJa91ZchXreMtgs1hD9RdMdqpZG7YgYMf00QnLCJedRK1ZgTnIoVHFj5Hsl z9XyFKjhNGa/UPk8rCVGhBazGkX1cDhsI6LeZGptvdQcbkM5Lq9Q3/XZIeaYeZGp5WX4 v4sIIrO6fQ0kmeGNGhZaWyy+Ca1rzcAebhUersY5mE9tpJLhoqoKAw+60fRS+wBmJTrj Gn4cCAXcUM/YJL/aGWxNS4VE2bocmsRu9YwMARYfXXjH0hSzJQ+m5/R4OOjnXu3fxuFi FpBQ== X-Received: by 10.224.15.72 with SMTP id j8mr45970912qaa.8.1406438568014; Sat, 26 Jul 2014 22:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Sat, 26 Jul 2014 22:22:26 -0700 (PDT) In-Reply-To: References: <560d4ed77488400199a101d12731079d@exrad6.ad.rad.co.il> From: "Andrew G. Malis" Date: Sun, 27 Jul 2014 01:22:26 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=047d7bea31843ebbca04ff25ff31 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/gtXXC18QxhObd6e511OnkO0emsI Subject: Re: [PWE3] not with a bang but a whimper X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 05:22:56 -0000 --047d7bea31843ebbca04ff25ff31 Content-Type: text/plain; charset=UTF-8 All, Adrian has updated the slides, and the correct link is http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-4.ppt . Cheers, Andy On Fri, Jul 25, 2014 at 10:51 AM, Andrew G. Malis wrote: > Yaakov, > > Thanks for bring this up, and for your contributions to the PWE3 WG over > the years. > > And of course, thanks to everyone else that has contribututed as well! > > PWEers, to add to Yaakov's email, and for the benefit of those of you not > in Toronto (or in Toronto but not at the Routing Area meeting), I highly > recommend that you read the slide deck presented at the Routing Area > meeting yesterday, which you can find at > http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-3.ppt . The > details of the Routing Area reorganization start at slide 26 in this deck. > > There may be fine-tuning as we work on the new WG charters, but for the > most part, PWE3's work will continue in the new "LDP-enabled services" > working group. For now, it's still business as usual, and we will continue > the PWE3 WG work on the existing PWE3 email list. Any changes to this will > be announced on this list. > > Cheers, > Andy > > > On Fri, Jul 25, 2014 at 10:29 AM, Yaakov Stein wrote: > >> Yesterday we held the 40th and final PWE3 WG meeting. >> >> There will be no PWE3 meeting in Honolulu. >> >> >> >> Not that the IETF has decided that all of our work is complete >> >> (although IMO we could have decided that a few years ago) >> >> but due to a reorg in the routing area. >> >> >> >> It has been about 14 years since the original Martini (ATM), Malis (SDH), >> and Anavi (TDM) drafts, >> >> the CEOT, PWOT, and PWE3 BoFs, leading to the formation of PWE3 in time >> for IETF-51. >> >> >> >> Just before the meeting I submitted a new version of the congestion >> considerations draft, >> >> a draft which I was originally asked to produce by transport AD Scott >> Bradner. >> >> Indeed, it was because of congestion considerations that PWE3 was >> originally in the transport area, >> >> before being moved to the Internet and thereafter to routing areas. >> >> >> >> I would like to say that it has been a fun 14 years, >> >> and thank everyone who has contributed to the formation of PWE3 >> technology. >> >> >> >> Y(J)S >> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > --047d7bea31843ebbca04ff25ff31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Adrian has updated the slides, and= the correct link is=C2=A0http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-4.ppt= =C2=A0.

Cheers,
Andy
=

On Fri, Jul 25, 2014 at 10:51 AM, Andrew= G. Malis <agmalis@gmail.com> wrote:
Yaakov,

=
Thanks for bring this up, and for your contributions to the PWE3= WG over the years.

And of course, thanks to everyone else that has contrib= ututed as well!

PWEers, to add to Yaakov's email, and for the benef= it of those of you not in Toronto (or in Toronto but not at the Routing Are= a meeting), I highly recommend that you read the slide deck presented at th= e Routing Area meeting yesterday, which you can find at=C2=A0http://www.ietf.org/proceedings/90/slides/slides-90-rtgarea-3.ppt . The details of the Routing Area reorganization start at slide 26 in thi= s deck.=C2=A0

There may be fine-tuning as we work on the new WG chart= ers, but for the most part, PWE3's work will continue in the new "= LDP-enabled services" working group. For now, it's still business = as usual, and we will continue the PWE3 WG work on the existing PWE3 email = list. Any changes to this will be announced on this list.

Cheers,
Andy


Yesterday we held the 40th and final PWE3= WG meeting.

There will be no PWE3 meeting in Honolulu.=

=C2=A0

Not that the IETF has decided that all of our work i= s complete

(although IMO we could have decided that a few years= ago)

but due to a reorg in the routing area.

=C2=A0

It has been about 14 years since the original Martin= i (ATM), Malis (SDH), and Anavi (TDM) drafts,

the CEOT, PWOT, and PWE3 BoFs, leading to the format= ion of PWE3 in time for IETF-51.

=C2=A0

Just before the meeting I submitted a new version of= the congestion considerations draft,

a draft which I was originally asked to produce by t= ransport AD Scott Bradner.

Indeed, it was because of congestion considerations = that PWE3 was originally in the transport area,

before being moved to the Internet and thereafter to= routing areas.

=C2=A0

I would like to say that it has been a fun 14 years,=

and thank everyone who has contributed to the format= ion of PWE3 technology.

=C2=A0

Y(J)S

=C2=A0


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



--047d7bea31843ebbca04ff25ff31-- From nobody Sun Jul 27 08:49:46 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55861A03A5 for ; Sun, 27 Jul 2014 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPmyKr_X0SSU for ; Sun, 27 Jul 2014 08:49:43 -0700 (PDT) Received: from rad.co.il (mailrelay01-ib1.rad.com [94.188.133.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD4D1A03AC for ; Sun, 27 Jul 2014 08:49:42 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES256-SHA encrypted SMTP; 27 Jul 2014 18:37:13 +0300 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sun, 27 Jul 2014 18:49:19 +0300 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Sun, 27 Jul 2014 18:49:19 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: draft-jiang-pwe3-mc-pon Thread-Index: Ac+pslB+jjdflssJRm62TKLfnjjPbg== Date: Sun, 27 Jul 2014 15:49:18 +0000 Message-ID: <10f3d01039fb4d77bea5cf35095ec3c9@exrad6.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: multipart/alternative; boundary="_000_10f3d01039fb4d77bea5cf35095ec3c9exrad6adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090204.53D51F93.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 (Unknown) Spam-Score: -2.40 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/n9Y8-tkIYzlvZTkgs7I8P1NijNE Subject: [PWE3] draft-jiang-pwe3-mc-pon X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 15:49:44 -0000 --_000_10f3d01039fb4d77bea5cf35095ec3c9exrad6adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, As I asked at the session last week, I am interested in hearing if anyone k= nows of deployment of Type B PON protection, which is the case this draft is trying to facilit= ate. If this is heavily deployed, then I support adoption of this draft. If it is not deployed, then I think we don't need it. Y(J)S --_000_10f3d01039fb4d77bea5cf35095ec3c9exrad6adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

As I asked at the session last week, I am interested= in hearing if anyone knows of deployment

of Type B PON protection, which is the case this dra= ft is trying to facilitate.

 

If this is heavily deployed, then I support adoption= of this draft.

If it is not deployed, then I think we don’t n= eed it.

 

Y(J)S

 

--_000_10f3d01039fb4d77bea5cf35095ec3c9exrad6adradcoil_-- From nobody Sun Jul 27 12:47:38 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947F91A01A9 for ; Sun, 27 Jul 2014 12:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJmS_xMny1hL for ; Sun, 27 Jul 2014 12:47:33 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F511A0171 for ; Sun, 27 Jul 2014 12:47:32 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6RJlTHu015521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2014 15:47:29 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6RJlTHu015521 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1406490449; bh=g2ercMYhEG2p5hfLkA+X17lRsdM=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=hJj66B7V9xiMrUtpipzIdNmgfZlzkjX6nsoZhERw1QwMWqyar8XoXvw4WbzBbZdGA A95sYDhD2716ME6NSOLLxeU0ulpDfh6LHEleApFXgsHV6PMz2Xn/T5R9nZqpsUWiMf D6FpyZLqPgpIrIIy3lRZnHTOcEVfcsFKn9OTOsB0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s6RJlTHu015521 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd02.lss.emc.com (RSA Interceptor); Sun, 27 Jul 2014 15:47:12 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s6RJlC6S006039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Jul 2014 15:47:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.186]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Sun, 27 Jul 2014 15:47:12 -0400 From: "Black, David" To: "Andrew G. Malis" , "pwe3@ietf.org" Date: Sun, 27 Jul 2014 15:47:11 -0400 Thread-Topic: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 Thread-Index: AQHPqBxqzwhORIesakKxufe7h6gk5JuxDkQQgANIiNA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077860DE34@MX15A.corp.emc.com> References: <0a58870234304bcc94cb11311e5b87dd@exrad6.ad.rad.co.il> In-Reply-To: <0a58870234304bcc94cb11311e5b87dd@exrad6.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712077860DE34MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/5IVjo9GvtpkwiFu1sFj0GfRBkoU Subject: Re: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 19:47:35 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712077860DE34MX15Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBhbHNvIG5vdCBhd2FyZSBvbiBhbnkgSVBSIHRoYXQgaXMgcmVsZXZhbnQgdG8gdGhpcyBk cmFmdC4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KDQpGcm9tOiBwd2UzIFttYWlsdG86cHdlMy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWWFha292IFN0ZWluDQpTZW50OiBGcmlkYXksIEp1 bHkgMjUsIDIwMTQgMTozOSBQTQ0KVG86IEFuZHJldyBHLiBNYWxpczsgcHdlM0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtQV0UzXSBJUFIgcG9sbCBmb3IgZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25z LTAyDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVnYXJkaW5nIHRoaXMgZHJhZnQuDQoN ClkoSilTDQoNCkZyb206IHB3ZTMgW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IDI1IEp1bHksIDIwMTQgMTE6MjMNClRvOiBw d2UzQGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYub3JnPg0KU3ViamVjdDogW1BXRTNdIElQUiBw b2xsIGZvciBkcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDINCg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDIucGRmIGlzIG5vdyBpbiBQV0UzIFdHIGxh c3QgY2FsbC4gQXMgcGFydCBvZiB0aGUgbGFzdCBjYWxsIHByb2Nlc3MsIHdlIG5lZWQgdG8gcG9s bCB0aGUgYXV0aG9ycyBhbmQgV0cgZm9yIElQUiBpbmZvcm1hdGlvbiBvbiB0aGUgZHJhZnQuDQoN CkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1wd2Uz LWNvbmdjb25zLTAyPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njkg YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/IE5vdGUgdGhhdCB0aGVyZQ0KYXJlIGN1cnJlbnRs eSBubyBJUFIgZGlzY2xvc3VyZXMgaW4gdGhlIElFVEYgZGF0YXRyYWNrZXIuDQoNCklmIHlvdSBh cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNw b25kDQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBh d2FyZSBvZiBhbnkNCnJlbGV2YW50IElQUi4gVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQg dG8gdGhlIFBXRTMgV0cgbWFpbGluZw0KbGlzdC4gVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFu Y2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KaGFzIGJlZW4gcmVjZWl2ZWQg ZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFjaCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0 aGUgUFdFMyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3INCm9y IGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3Ug YXJlIGF3YXJlDQpvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4g Y29uZm9ybWFuY2Ugd2l0aCBJRVRGDQpydWxlcy4NCg0KVGhhbmtzLA0KQW5keQ0K --_000_8D3D17ACE214DC429325B2B98F3AE712077860DE34MX15Acorpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5JIGFtIGFsc28gbm90IGF3YXJlIG9u IGFueSBJUFIgdGhhdCBpcyByZWxldmFudCB0byB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+VGhhbmtzLDxi cj4tLURhdmlkPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp bic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ IHB3ZTMgW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+ WWFha292IFN0ZWluPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTozOSBQ TTxicj48Yj5Ubzo8L2I+IEFuZHJldyBHLiBNYWxpczsgcHdlM0BpZXRmLm9yZzxicj48Yj5TdWJq ZWN0OjwvYj4gUmU6IFtQV0UzXSBJUFIgcG9sbCBmb3IgZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25z LTAyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlZ2FyZGluZyB0aGlzIGRyYWZ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+WShKKVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4gcHdlMyBbPGEgaHJlZj0ibWFpbHRvOnB3ZTMtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBP ZiA8L2I+QW5kcmV3IEcuIE1hbGlzPGJyPjxiPlNlbnQ6PC9iPiAyNSBKdWx5LCAyMDE0IDExOjIz PGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0Zi5v cmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBbUFdFM10gSVBSIHBvbGwgZm9yIGRyYWZ0LWlldGYt cHdlMy1jb25nY29ucy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMi5wZGYiPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyLnBkZjwvYT4gaXMgbm93 IGluIFBXRTMgV0cgbGFzdCBjYWxsLiBBcyBwYXJ0IG9mIHRoZSBsYXN0IGNhbGwgcHJvY2Vzcywg d2UgbmVlZCB0byBwb2xsIHRoZSBhdXRob3JzIGFuZCBXRyBmb3IgSVBSIGluZm9ybWF0aW9uIG9u IHRoZSBkcmFmdC48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxicj48YnI+QXJlIHlvdSBhd2FyZSBvZiBhbnkmbmJz cDs8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRkNDJz5JUFI8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7dGhhdCBhcHBs aWVzIHRvJm5ic3A7ZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyPzwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PGJy Pjxicj5JZiBzbywgaGFzIHRoaXMmbmJzcDs8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRkND Jz5JUFI8L3NwYW4+Jm5ic3A7YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYm bmJzcDs8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRkNDJz5JUFI8L3NwYW4+Jm5ic3A7cnVs ZXM8YnI+KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cyk/IE5vdGUgdGhhdCB0aGVyZTxicj5hcmUgY3VycmVudGx5IG5vJm5ic3A7PHNwYW4gc3R5bGU9 J2JhY2tncm91bmQ6I0ZGRkZDQyc+SVBSPC9zcGFuPiZuYnNwO2Rpc2Nsb3N1cmVzIGluIHRoZSBJ RVRGIGRhdGF0cmFja2VyLjxicj48YnI+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQ8YnI+dG8gdGhpcyBlbWFpbCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55PGJyPnJlbGV2YW50 Jm5ic3A7PHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6I0ZGRkZDQyc+SVBSPC9zcGFuPi4gVGhlIHJl c3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIFBXRTMgV0cgbWFpbGluZzxicj5saXN0LiBU aGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJl c3BvbnNlPGJyPmhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGVhY2ggY29u dHJpYnV0b3IuPGJyPjxicj5JZiB5b3UgYXJlIG9uIHRoZSBQV0UzIFdHIGVtYWlsIGxpc3QgYnV0 IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcjxicj5vciBjb250cmlidXRvciwgdGhlbiBwbGVh c2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZTxicj5vZiBhbnkmbmJz cDs8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDojRkZGRkNDJz5JUFI8L3NwYW4+Jm5ic3A7dGhhdCBo YXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEY8YnI+cnVs ZXMuPGJyPjxicj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5BbmR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_8D3D17ACE214DC429325B2B98F3AE712077860DE34MX15Acorpemcc_-- From nobody Mon Jul 28 01:04:06 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755371A027C for ; Mon, 28 Jul 2014 01:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CCW08eK8qsK for ; Mon, 28 Jul 2014 01:03:56 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A452C1A02CF for ; Mon, 28 Jul 2014 01:03:47 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 08:03:45 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Mon, 28 Jul 2014 08:03:45 +0000 From: Alexander Vainshtein To: "Andrew G. Malis" Thread-Topic: WG Last call for draft-ietf-pwe3-congcons-02? (was: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02) Thread-Index: Ac+qOnLyjQPVLiOSTqGFx2WWHFeNEg== Date: Mon, 28 Jul 2014 08:03:44 +0000 Message-ID: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(377454003)(243025005)(199002)(189002)(252514010)(110136001)(95666004)(106356001)(105586002)(33646002)(19609705001)(15975445006)(85306003)(1411001)(66066001)(80022001)(77982001)(19617315012)(229853001)(76482001)(21056001)(83072002)(107046002)(19580395003)(85852003)(83322001)(76576001)(79102001)(15202345003)(16236675004)(46102001)(50986999)(101416001)(19300405004)(54356999)(81542001)(87936001)(31966008)(74316001)(4396001)(99396002)(92566001)(2656002)(64706001)(86362001)(19580405001)(20776003)(19625215002)(74502001)(81342001)(74662001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_11d70b862da7462989dc64a485a03840AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Lwpc5-DYMmHOMMf33e7pRHcXVP0 Cc: "pwe3@ietf.org" Subject: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 08:04:03 -0000 --_000_11d70b862da7462989dc64a485a03840AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSBhbmQgYWxsLA0KU29tZWhvdyBJIGRpZCBub3QgZmluZCBhbiBleHBsaWNpdCBXR0xDIG1l c3NhZ2UgZm9yIHRoaXMgZHJhZnQgKG5laXRoZXIgaW4gbXkgYXJjaGl2ZSBub3IgaW4gdGhlIFdH IG9uZSkuDQoNCk5ldmVydGhlbGVzcywgSSBzdXBwb3J0IHJlcXVlc3RpbmcgcHVibGljYXRpb24g b2YgdGhpcyBkcmFmdCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCg0KDQpJIGhhdmUgYSBmZXcg ZWRpdG9yaWFsIGNvbW1lbnRzOg0KDQoxLiAgICAgICBPbiBwYWdlIDYgdGhlIHRleHQgc2F5cyDi gJxJbnRlcm5hdGlvbmFsIHN0YW5kYXJkcyBwbGFjZSBzdHJpbmdlbnQgbGltaXRzIG9uIHRoZSBu dW1iZXIgb2Ygc3VjaCBmYXVsdHMgdG9sZXJhdGVk4oCdLiAgSSBhc3N1bWUgdGhlIHJlZmVyZW5j ZSBpcyB0byBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjgyNiwgYnV0IGl0IHdvdWxkIGJlIG5pY2Ug dG8gc3RhdGUgdGhhdCBleHBsaWNpdGx5OyBJIGFtIGFsc28gbm90IHN1cmUgd2hldGhlciBwbHVy YWwgKOKAnHN0YW5kYXJkc+KAnSkgaXMganVzdGlmaWVkIGhlcmUuDQoNCjIuICAgICAgIEFsc28g b24gcGFnZSA2LCBJIHN1Z2dlc3QgaW5zZXJ0aW5nIHRoZSBtdWx0aXBsaWNhdGlvbiBzaWducyAo YXN0ZXJpc2tzKSBpbiB0aGUgZm9ybXVsYSAgaW4gdGhlIHNhbWUgd2F5IGl0IGlzIGRvbmUgaW4g U2VjdGlvbiAzLjEgb2YgUkZDIDUzNDg8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM0 OD4gKGZyb20gd2hpY2ggdGhpcyBmb3JtdWxhIGlzIHRha2VuKQ0KDQozLiAgICAgICBPbiBwYWdl IDExLCDigJxTZWNvbmQsIHRoZSBkZXJpdmF0aW9uIGFzc3VtZWQgdGhhdCB0aGUgVERNIFBXIHdh cyBjb21wZXRpbmcgd2l0aCBsb25nLWxpdmVkIFRETSBmbG93c+KAnSBwcmVzdW1hYmx5IHNob3Vs ZCBiZSDigJxTZWNvbmQsIHRoZSBkZXJpdmF0aW9uIGFzc3VtZWQgdGhhdCB0aGUgVERNIFBXIHdh cyBjb21wZXRpbmcgd2l0aCBsb25nLWxpdmVkIFRDUCBmbG93c+KAnS4NCg0KNC4gICAgICAgT24g cGFnZSAxOCwg4oCcTm90ZSB0aGF0IGlmIHRoZSBlcnJvciBjb25kaXRpb24gQUlTIHdhcyBkZXRl Y3RlZCBhY2NvcmRpbmcgdG8gdGhlIGNyaXRlcmlhIG9mIElUVS1UIFJlY29tbWVuZGF0aW9uIEcu Nzc1IFtHODI2XeKAnSBwcmVzdW1hYmx5IHNob3VsZCBiZSDigJxOb3RlIHRoYXQgaWYgdGhlIGVy cm9yIGNvbmRpdGlvbiBBSVMgd2FzIGRldGVjdGVkIGFjY29yZGluZyB0byB0aGUgY3JpdGVyaWEg b2YgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43NzUgW0c3NzVd4oCdLg0KDQoNCg0KSU1PIG5laXRo ZXIgb2YgdGhlc2UgY29tbWVudHMgcmVxdWlyZXMgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdCBwcmlvciB0byByZXF1ZXN0aW5nIGl0cyBwdWJsaWNhdGlvbjsgaG9wZWZ1bGx5IHRo ZXkgY2FuIGJlIGhhbmRsZWQgaW4gdGhlIHByb2Nlc3Mgb2YgYXBwcm92YWwgYW5kIHB1YmxpY2F0 aW9uLg0KDQpJ4oCZZCBsaWtlIHRvIHRoYW5rIFlhYWtvdiwgRGF2aWQgYW5kIEJvYiBmb3IgdGhl aXIgZWZmb3J0LiBJIGZpbmQgdmVyeSBzeW1ib2xpYyB0aGF0IHRoZSBjb25nZXN0aW9uIGlzc3Vl IHRoYXQgaGFzIGJlZW4gcmFpc2VkIGluIHRoZSBlYXJseSBkYXlzIG9mIFBXRTMgaXMg4oCTIGF0 IGxvbmcgbGFzdCDigJMgc3VjY2Vzc2Z1bGx5IHJlc29sdmVkIHdpdGhvdXQgYW55IHJldHJvLWZp dHRpbmcgb2Ygd2lkZWx5IGRlcGxveWVkIG1lY2hhbmlzbXMgZGVmaW5lZCBieSB0aGUgUFdFMy4N Cg0KUmVnYXJkcywNCiAgICAgICBTYXNoYQ0KRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tDQpNb2JpbGU6IDA1NC05MjY2MzAyDQoNCkZyb206IHB3ZTMgW21haWx0bzpwd2Uz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IEZy aWRheSwgSnVseSAyNSwgMjAxNCA2OjIzIFBNDQpUbzogcHdlM0BpZXRmLm9yZw0KU3ViamVjdDog W1BXRTNdIElQUiBwb2xsIGZvciBkcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDINCg0KaHR0cDov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDIucGRmIGlzIG5vdyBp biBQV0UzIFdHIGxhc3QgY2FsbC4gQXMgcGFydCBvZiB0aGUgbGFzdCBjYWxsIHByb2Nlc3MsIHdl IG5lZWQgdG8gcG9sbCB0aGUgYXV0aG9ycyBhbmQgV0cgZm9yIElQUiBpbmZvcm1hdGlvbiBvbiB0 aGUgZHJhZnQuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJh ZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5Nzks IDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/IE5vdGUgdGhhdCB0aGVyZQ0K YXJlIGN1cnJlbnRseSBubyBJUFIgZGlzY2xvc3VyZXMgaW4gdGhlIElFVEYgZGF0YXRyYWNrZXIu DQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9y IHBsZWFzZSByZXNwb25kDQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBu b3QgeW91IGFyZSBhd2FyZSBvZiBhbnkNCnJlbGV2YW50IElQUi4gVGhlIHJlc3BvbnNlIG5lZWRz IHRvIGJlIHNlbnQgdG8gdGhlIFBXRTMgV0cgbWFpbGluZw0KbGlzdC4gVGhlIGRvY3VtZW50IHdp bGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KaGFzIGJl ZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFjaCBjb250cmlidXRvci4NCg0KSWYg eW91IGFyZSBvbiB0aGUgUFdFMyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBh biBhdXRob3INCm9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQg b25seSBpZiB5b3UgYXJlIGF3YXJlDQpvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBk aXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGDQpydWxlcy4NCg0KVGhhbmtzLA0KQW5k eQ0K --_000_11d70b862da7462989dc64a485a03840AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkFoYXJvbmk7DQoJcGFub3NlLTE6MiAxIDggMyAyIDEg NCAzIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJ Y29sb3I6IzFGNDk3RDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpu b25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0KcC5EZWZhdWx0LCBsaS5EZWZh dWx0LCBkaXYuRGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTpEZWZhdWx0Ow0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTUwNzU2OTA1Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDMyOTM3ODMyIDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjE3ODE2ODU0NjQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE5MzA1NjI2NTIgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5IGFuZCBhbGws PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvbWVob3cgSSBkaWQgbm90IGZpbmQgYW4g ZXhwbGljaXQgV0dMQyBtZXNzYWdlIGZvciB0aGlzIGRyYWZ0IChuZWl0aGVyIGluIG15IGFyY2hp dmUgbm9yIGluIHRoZSBXRyBvbmUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TmV2ZXJ0aGVsZXNzLCBJIHN1cHBvcnQg cmVxdWVzdGluZyBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGFuIEluZm9ybWF0aW9uYWwg UkZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iRGVmYXVsdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgaGF2ZSBhIGZldyBlZGl0b3JpYWwgY29tbWVudHM6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iRGVmYXVsdCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gcGFnZSA2 IHRoZSB0ZXh0IHNheXMg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5J bnRlcm5hdGlvbmFsIHN0YW5kYXJkcyBwbGFjZSBzdHJpbmdlbnQgbGltaXRzIG9uIHRoZSBudW1i ZXINCiBvZiBzdWNoIGZhdWx0cyB0b2xlcmF0ZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnS4gJm5ic3A7SSBhc3N1bWUgdGhlIHJlZmVyZW5jZSBp cyB0byBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjgyNiwgYnV0IGl0IHdvdWxkIGJlIG5pY2UgdG8g c3RhdGUgdGhhdCBleHBsaWNpdGx5OyBJIGFtIGFsc28gbm90IHN1cmUgd2hldGhlciBwbHVyYWwg KOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtiYWNrZ3JvdW5kOnllbGxv dzttc28taGlnaGxpZ2h0OnllbGxvdyI+c3RhbmRhcmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0pDQogaXMganVzdGlmaWVkIGhlcmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IkRlZmF1bHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRS Ij48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28g b24gcGFnZSA2LCBJIHN1Z2dlc3QgaW5zZXJ0aW5nIHRoZSBtdWx0aXBsaWNhdGlvbiBzaWducyAo YXN0ZXJpc2tzKSBpbiB0aGUgZm9ybXVsYSAmbmJzcDtpbiB0aGUgc2FtZSB3YXkgaXQgaXMgZG9u ZSBpbiBTZWN0aW9uDQogMy4xIG9mIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzUzNDgiPlJGQyA1MzQ4PC9hPiAoZnJvbSB3aGljaCB0aGlzIGZvcm11bGEgaXMgdGFrZW4p PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IkRlZmF1bHQiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRp cj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk9uIHBhZ2UgMTEsIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2Vj b25kLCB0aGUgZGVyaXZhdGlvbiBhc3N1bWVkIHRoYXQgdGhlIFRETSBQVyB3YXMgY29tcGV0aW5n IHdpdGggbG9uZy1saXZlZA0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdo bGlnaHQ6eWVsbG93Ij5URE08L3NwYW4+IGZsb3dzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0gcHJlc3VtYWJseSBzaG91bGQgYmUg4oCcPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWNvbmQsIHRoZSBkZXJpdmF0aW9uIGFz c3VtZWQgdGhhdCB0aGUNCiBURE0gUFcgd2FzIGNvbXBldGluZyB3aXRoIGxvbmctbGl2ZWQgPHNw YW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4NClRDUDwv c3Bhbj4gZmxvd3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPuKAnS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IkRlZmF1bHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk9uIHBhZ2UgMTgsIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Tm90ZSB0aGF0IGlmIHRoZSBlcnJvciBjb25kaXRpb24gQUlTIHdhcyBkZXRl Y3RlZCBhY2NvcmRpbmcgdG8gdGhlIGNyaXRlcmlhDQogb2YgSVRVLVQgUmVjb21tZW5kYXRpb24g Ry43NzUgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93 Ij4NCltHODI2XTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPuKAnSBwcmVzdW1hYmx5IHNob3VsZCBiZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPk5vdGUgdGhhdCBpZiB0aGUgZXJyb3IgY29uZGl0aW9uIEFJUyB3 YXMgZGV0ZWN0ZWQgYWNjb3JkaW5nIHRvIHRoZSBjcml0ZXJpYSBvZiBJVFUtVCBSZWNvbW1lbmRh dGlvbg0KIEcuNzc1IDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0 OnllbGxvdyI+W0c3NzVdPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJEZWZh dWx0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IkRlZmF1bHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTU8gbmVpdGhlciBvZiB0aGVzZSBjb21tZW50cyBy ZXF1aXJlcyBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHByaW9yIHRvIHJlcXVl c3RpbmcgaXRzIHB1YmxpY2F0aW9uOyBob3BlZnVsbHkgdGhleSBjYW4gYmUgaGFuZGxlZCBpbiB0 aGUgcHJvY2VzcyBvZg0KIGFwcHJvdmFsIGFuZCBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlk IGxpa2UgdG8gdGhhbmsgWWFha292LCBEYXZpZCBhbmQgQm9iIGZvciB0aGVpciBlZmZvcnQuIEkg ZmluZCB2ZXJ5IHN5bWJvbGljIHRoYXQgdGhlIGNvbmdlc3Rpb24gaXNzdWUgdGhhdCBoYXMgYmVl biByYWlzZWQgaW4gdGhlIGVhcmx5IGRheXMgb2YgUFdFMyBpcyDigJMNCiBhdCBsb25nIGxhc3Qg 4oCTIHN1Y2Nlc3NmdWxseSByZXNvbHZlZCB3aXRob3V0IGFueSByZXRyby1maXR0aW5nIG9mIHdp ZGVseSBkZXBsb3llZCBtZWNoYW5pc21zIGRlZmluZWQgYnkgdGhlIFBXRTMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU2FzaGENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5F bWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+TW9iaWxlOiAwNTQtOTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBwd2UzIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBKdWx5IDI1LCAyMDE0IDY6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IHB3ZTNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1BXRTNdIElQUiBwb2xsIGZvciBkcmFmdC1pZXRmLXB3ZTMt Y29uZ2NvbnMtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt aWV0Zi1wd2UzLWNvbmdjb25zLTAyLnBkZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLXB3ZTMtY29uZ2NvbnMtMDIucGRmPC9hPiBpcyBub3cgaW4gUFdFMyBXRyBsYXN0IGNhbGwu IEFzIHBhcnQgb2YgdGhlIGxhc3QgY2FsbCBwcm9jZXNzLCB3ZQ0KIG5lZWQgdG8gcG9sbCB0aGUg YXV0aG9ycyBhbmQgV0cgZm9yIElQUiBpbmZvcm1hdGlvbiBvbiB0aGUgZHJhZnQuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCkFyZSB5b3UgYXdhcmUgb2YgYW55 Jm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7dGhhdCBhcHBsaWVzIHRvJm5ic3A7ZHJhZnQtaWV0Zi1wd2UzLWNvbmdj b25zLTAyPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpJZiBz bywgaGFzIHRoaXMmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3Nw YW4+Jm5ic3A7YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYmbmJzcDs8c3Bh biBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3NwYW4+Jm5ic3A7cnVsZXM8YnI+DQoo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gTm90 ZSB0aGF0IHRoZXJlPGJyPg0KYXJlIGN1cnJlbnRseSBubyZuYnNwOzxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOiNGRkZGQ0MiPklQUjwvc3Bhbj4mbmJzcDtkaXNjbG9zdXJlcyBpbiB0aGUgSUVURiBk YXRhdHJhY2tlci48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1 dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZDxicj4NCnRvIHRoaXMgZW1haWwgcmVn YXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueTxicj4NCnJlbGV2 YW50Jm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPi4gVGhl IHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIFBXRTMgV0cgbWFpbGluZzxicj4NCmxp c3QuIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGls IGEgcmVzcG9uc2U8YnI+DQpoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBl YWNoIGNvbnRyaWJ1dG9yLjxicj4NCjxicj4NCklmIHlvdSBhcmUgb24gdGhlIFBXRTMgV0cgZW1h aWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yPGJyPg0Kb3IgY29udHJpYnV0 b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmU8 YnI+DQpvZiBhbnkmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3Nw YW4+Jm5ic3A7dGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3 aXRoIElFVEY8YnI+DQpydWxlcy48YnI+DQo8YnI+DQpUaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkFuZHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_11d70b862da7462989dc64a485a03840AM3PR03MB612eurprd03pro_-- From nobody Mon Jul 28 02:47:53 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DED31A0360 for ; Mon, 28 Jul 2014 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYgeLqha4yx2 for ; Mon, 28 Jul 2014 02:47:50 -0700 (PDT) Received: from EMEA-ESG-SMTP.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336B01A035E for ; Mon, 28 Jul 2014 02:47:50 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CF1E669A26CFF for ; Mon, 28 Jul 2014 09:47:46 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6S9lmYg015451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Jul 2014 11:47:48 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 28 Jul 2014 11:47:48 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Thread-Topic: Toronto Minutes Thread-Index: AQHPqkj9s7yforCCgU6Ik8LG+TlHWg== Date: Mon, 28 Jul 2014 09:47:47 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.39] Content-Type: multipart/mixed; boundary="_004_CFFBDAD267240matthewboccialcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/PjXgkXLjznk0mk8buDBmmDnEHzE Subject: [PWE3] Toronto Minutes X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 09:47:52 -0000 --_004_CFFBDAD267240matthewboccialcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_CFFBDAD267240matthewboccialcatellucentcom_" --_000_CFFBDAD267240matthewboccialcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIHRoZSBkcmFmdCBtaW51dGVzIGZyb20gVG9yb250 by4gTWFueSB0aGFua3MgdG8gRGF2ZSBmb3IgdGFraW5nIHRoZXNlLg0KDQpQbGVhc2UgbGV0IG1l IGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRzL2NvcnJlY3Rpb25zLg0KDQpNYXR0aGV3DQoN Cg== --_000_CFFBDAD267240matthewboccialcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <2DB370DFFCA2194CAE845A16C37DD088@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+QWxs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2UgZmluZCBhdHRhY2hlZCB0aGUg ZHJhZnQgbWludXRlcyBmcm9tIFRvcm9udG8uIE1hbnkgdGhhbmtzIHRvIERhdmUgZm9yIHRha2lu ZyB0aGVzZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBsZWFzZSBsZXQgbWUga25v dyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMvY29ycmVjdGlvbnMuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5NYXR0aGV3PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CFFBDAD267240matthewboccialcatellucentcom_-- --_004_CFFBDAD267240matthewboccialcatellucentcom_ Content-Type: text/plain; name="00 PWE3.Agenda.IETF90.Minutes.txt" Content-Description: 00 PWE3.Agenda.IETF90.Minutes.txt Content-Disposition: attachment; filename="00 PWE3.Agenda.IETF90.Minutes.txt"; size=8056; creation-date="Mon, 28 Jul 2014 09:47:47 GMT"; modification-date="Mon, 28 Jul 2014 09:47:47 GMT" Content-ID: Content-Transfer-Encoding: base64 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKgpJRVRGIDkwIFBXRTMgLSBUaHVyc2RheSwgSnVseSAyNCwgMjAxNCAtIDE3 OjMwIC0gMTg6MzAgIE1hbml0b2JhCig0NS82MCBtaW4gYWxsb2NhdGVkOyAqKiBQbGVhc2Ugbm90 ZSB0aGUgdGltZSBhZGp1c3RtZW50cy4pCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKQ2hhaXJzOiBNYXR0aGV3IEJv Y2NpIGFuZCBBbmR5IE1hbGlzClNlY3JldGFyeTogRGF2aWQgU2luaWNyb3BlCih4ID0gc2xpZGUg c2V0cyBOT1QgcmVjZWl2ZWQgYXMgb2YgSnVseSAyNCwgMjAxNCAwMTowMCBUb3JvbnRvIFRpbWUp CgoxLiAxNSBtaW4gLSBBZ2VuZGEgYmFzaCwgV0cgQWdlbmRhIGFuZCBTdGF0dXMgLSBBbmR5IE1B TElTIGFuZCBNYXR0aGV3IEJPQ0NJCk1hdGhldyBhbmQgQW5keSBzdGFydGVkIHRoZSBtZWV0aW5n LgpTZWUgdGhlIHNsaWRlcy4gIApBIGZldyB0aGluZ3MgbmVlZCB0byBiZSBkZWxldGVkIGZyb20g dGhlIG1pbGVzdG9uZXMsIHBlcmhhcHMgYSBNUyBQVyBNSUIgZm9yIGV4YW1wbGUKVGhyZWUgbG9u ZyBzdGFuZGluZyBSRkNzIHdlcmUgcHVibGlzaGVkLi4uIGFuZCB0aGVyZSB3YXMgbXVjaCByZWpv aWNpbmcuCgplbmRwb2ludC1mYXN0LXByb3RlY3Rpb24gZHJhZnQgaGFkIG5vIGNvbW1lbnRzIGlu IFdHIExDIC0gaXQgaXMgYSAtMDAgd291bGQgbGlrZSB0byBoYXZlIG1vcmUgY29tbWVudHMuICBN UExTIFdHIGRlcGVuZGluZyBvbiBpdC4gIFRoZXJlIHdpbGwgYmUgYSBzZWNvbmQgV0cgTEMgZm9y IHRoZSBkb2N1bWVudC4gIEl0IHdhcyBqdXN0IHVwZGF0ZWQgdG8gMDEuICBNYXR0aGV3IHBvbGxl ZCB0aGUgZHJhZnQgZm9yIHdobyByZWFkIHRoZSBkcmFmdC4gT25seSB0d28gaW4gdGhlIHJvb20u CgpJQ0NQLVNUUCBkcmFmdCAtIG5vIGNvbW1lbnRzIG9uIExDIGluaXRpYWxseS4gIEFuZHkga2Vw dCBsYXN0IGNhbGwgb3BlbiBhbmQgc29saWNpdGVkIGNvbW1lbnRzIHdoaWNoIGNhbWUgYW5kIHdl cmUgdmVyeSBnb29kLCBhbmQgY2hhbmdlcyBtYWRlLiAgQW5vdGhlciByZXZpZXcgd2lsbCBiZSBk b25lIGFuZCBhbiBhZGRpdGlvbmFsIHJldmlzaW9uIHdpbGwgYmUgcG9zdGVkIGZvciBXRyByZXZp ZXcgYW5kIHRoZSBkb2N1bWVudCB3aWxsIGdvIGZvciBhIHNlY29uZCBXRyBMQy4gIFRoYW5rcyB0 byBTYXNoYSBhbmQgb3RoZXJzIGZvciBzdGVwcGluZyB1cCB0byByZXZpZXdpbmcgdGhlIGRvY3Vt ZW50LgoKRG9jIFN0YXR1cyA0IHNsaWRlCkEgbnVtYmVyIG9mIGRyYWZ0cyBleHBpcmVkIHRoYXQg bWF5IGJlIHJlYWR5IGZvciBsYXN0IGNhbGwgLSAKVkNDViBmb3IgZ2FsIGRyYWZ0IC0gZWRpdG9y IGF0IGxvc3MgZm9yIGN5Y2xlcwoKNDQ0N2JpcyAtIEdpbGVzIHdpbGwgdXBkYXRlIDQ0NDctYmlz IChwZXIgSmFiYmVyKQpjb25nY29ucyB3YXMganVzdCB1cGRhdGVkIGJ5IFlKUy0gQXJlYSBkaXJl Y3RvciByZXF1ZXN0ZWQgdG8gd3JpdGUgdGhpcyAxNSB5ZWFycyBhZ28uICBUaGlzIHNob3VsZCBw dXQgdG8gcmVzdCB0aGUgdHJhbnNwb3J0IGlzc3Vlcy4gIFlKUyByZXF1ZXN0ZWQgbGFzdCBjYWxs LgoKbXBscy10cC1vdmVyLWJpZGlyLWxzcCAtIGF1dGhvciAoTWFjaCBDaGVuKSBiZWxpZXZlcyBp dCBpcyByZWFkeSBmb3IgbGFzdCBjYWxsLgpPQU0tY29uZmlnIC0gYXV0aG9ycyBhbHNvIHRoaW5r IGl0IGlzIHJlYWR5ClMtUEUgcmVkdW5kYW5jeSBkcmFmdCB3YXMgYWxzbyBub3RlZCBhcyByZWFk eSBmb3IgbGFzdCBjYWxsLgoKUmVtaW5kZXIgc2xpZGUKClJvdXRpbmcgQXJlYSBSZXR1bmluZyAt IHR1cm4gUFdFMyBpbnRvIExEUC1lbmFibGVkIFNlcnZpY2VzIFdHCndvdWxkIGNvdmVyIAotIFBX RTMgKHNvIGV4aXN0aW5nIHdvcmspCi0gUFcgZW5hYmxlZCBMMlZQTgotIExEUCBleHRlbnNpb25z IHdpbGwgYmUgcmV2aWV3ZWQgaW4gTVBMUwpBIG5ldyBjaGFydGVyIHdpbGwgYmUgZHJhZnRlZCBh bmQgZGlzY3Vzc2VkIG9uIHJvdXRpbmcgZGlzY3VzcyBsaXN0LiAgRmlyc3QgbWVldGluZyBhdCB0 aGUgbmV4dCBJRVRGLiAgVGhpcyBpbXBsaWVzIHRoaXMgaXMgdGhlIExBU1QgTUVFVElORyBPRiBQ V0UzIHdoaWNoIGhhcyBiZWVuIGdvaW5nIGZvciBjbG9zZSB0byAxNCB5ZWFycy4KClRoZSBjaGFp cnMgbm90ZWQgdGhhdCB0aGluZ3Mgd2lsbCBjb250aW51ZSB0byBydW4gYnVzaW5lc3MgYXMgdXN1 YWwgYW5kIHdlIHdpbGwgYmUgYnJpbmdpbmcgaW4gYWRkaXRpb25hbCB3b3JrIGFuZCBjaGFuZ2lu ZyB0aGUgV0cgbmFtZS4KCldoZW4gdGhlIFBXRTMvTERQIEVuYWJsZWQgU2VydmljZXMgQ2hhcnRl ciBpcyBkaXNjdXNzZWQsIGl0IHdpbGwgYmUgYW5ub3VuY2VkIGJ5IHRoZSBjaGFpcnMgb24gdGhl IHJvdXRpbmcgYXJlYSBkaXNjdXNzIGxpc3QuCgpZSlM6IGEgbGl0dGxlIGJpdCBhcnRpZmljaWFs IHRoYXQgUFdFMyBpcyBjYWxsZWQgTERQIGVuYWJsZWQuICBUaGVyZSBhcmUgb3RoZXIgcHJvdG9j b2xzIGNvbnNpZGVyZWQuICBXYXMgZ29pbmcgdG8gYXNrIHRvIGNvbnNpZGVyIHRoYXQgUFdFMyBn byBkb3JtYW50IHJhdGhlciB0aGFuIGxldHRpbmcgd29yayBsYW5ndWlzaC4gIFRoZSBXRyBoYXMg Z29uZSBmb3IgMTQgeWVhcnMgYW5kIHdlIGFyZSBjbG9zZSB0byBkb25lCkFkcmlhbjogd291bGQg YmUgZ29vZCB0byBoYXZlIHRoaXMgV0cgc2F5IHdlIGFyZSBkb25lIGFuZCBjbG9zZS4gIFdlIGFy ZW4ndCBmb2xkaW5nIFBXIGludG8gTERQIGVuYWJsZWQgc2VydmljZXMsIHdlIGFyZSB3cmFwcGlu ZyB1cCBQVyBhbmQgaGF2aW5nIGEgcGxhY2UgZm9yIExEUCBlbmFibGVkIHNlcnZpY2VzLiAgCllK UzogYW5kIHRoZSBuZXcgZ3JvdXAgd2lsbCBkZWFsIHdpdGggc3RhdGljYWxseSBjb25maWd1cmVk IFBXIGRyYWZ0cyB3aGljaCB3ZSBkbyBpbiBQV0UzLiAKQWRyaWFuOiBob3cgbWFueSBkcmFmdHMg YXJlIGluIHRoaXMgY2F0ZWdvcnk/Ck1hdHRoZXc6IG9ubHkgcmVhbGx5IG9uZSB0aGF0IGlzIGEg Y29ybmVyIGNhc2UKQWRyaWFuOiBjYW4gaGFuZGxlZCB0aHJvdWdoIEFEIG9yIHJvdXRpbmcgd29y a2luZyBncm91cC4KTWF0dGhldzogd2UndmUgdHJpZWQgdG8gZG8gUFcgd29yayBpbiB0aGUgc2Ft ZSB3YXkgYXMgTERQIHRvIGtlZXAgdGhpbmdzIHNpbWlsYXIuICBXb3VsZCBiZSBiZXR0ZXIgdG8g Z28gd2l0aCBMRFAgZW5hYmxlZC4KQWRyaWFuOiBpZiB0aGUgc3RhdGljIFBXIGRyYWZ0cyBhcmUg dGhlIGxhc3QgZHJhZnQgZm9yIFBXIGFuZCB3b3VsZCBjbG9zZSB0aGVuIGRvbid0IG5lZWQgdG8g aW5jbHVkZSBQVyBpbiBuZXcgY2hhcnRlci4KTG9hOiBjYXJldGFrZXJzIGFyZSBub3QgdW5oZWFy ZCBvZiBpbiBJRVRGLiBUaGlzIExEUCBlbmFibGVkIGdyb3VwIHdpbGwgdGFrZSBjYXJlIG9mIFBX RTMgZ29pbmcgZm9yd2FyZCBhcyB0aGVyZSBpcyBzb21lIHdvcmsgYmVpbmcgZG9uZS4gIE1hdHRo ZXcgdXNlZCB0aGUgd29yZCBwcm9wb3NhbCBmb3IgdGhlIHJvdXRpbmcgYXJlYSByZXR1bmUuICBG dXJ0aGVyIGFsb25nIGFzIHRoYXQuICAKQWRyaWFuOiB3ZSBhcmUgcHJvcG9zaW5nIHRoYXQgd2Ug bWFuZGF0ZSB0aGUgY2hhbmdlcy4KWUpTOiBJbnRlcmVzdGluZyB0aGF0IHRoZSBmb2xrcyB3aG8g d2VyZSBhdCB0aGUgZmlyc3QgbWVldGluZywgdGhleSBhcmUgc3RpbGwgYXQgSUVURiBhbmQgdGhl eSBhcmUgbm90IGJvdGhlcmluZyB0byBnbyB0byB0aGUgbWVldGluZy4gIApMb2E6IGNyb3NzIFBX RTMgYW5kIE1QTFMgLSBvbmUgZHJhZnQgaW4gTVBMUyBkZXBlbmRpbmcgb24gdHdvIFBXRTMgZHJh ZnRzLiAgT25lIHdhcyB0aGUgb25lIHJlZnJlc2hlZCB0b2RheSBhbmQgd2lsbCBnbyB0byBXRyBM Qy4gIE90aGVyIG9uZSBpcyBhIGRyYWZ0IHRoYXQgaGFzIGJlZW4gZG9ybWFudCBzaW5jZSAyMDEy LiAgUHJvcG9zZWQgdG8gdGVybWluYXRlIHRoYXQgZHJhZnQgc28gdGhhdCB0ZXh0IHJlbGF0ZWQg dG8gaXQgY2FuIGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVmZXJlbmNpbmcgZHJhZnQuICBUaGUgZHJh ZnQgaXMgTERQIGV4dGVuc2lvbnMgZm9yIFAyTVAuICAKTWF0dGhldzogdGhlIENoYWlycyB3aWxs IHBvbGwgdGhlIGF1dGhvcnMgdG8gc2VlIGlmIGl0IHdpbGwgYmUgcHJvZ3Jlc3NlZC4KTG9hOiBo b3dldmVyIHRoZXkgd291bGQgbmVlZCB0byBzdGFydCBvdmVyCgoKMi4gMTAgbWluIC0gTXVsdGkt Y2hhc3NpcyBQT04gUHJvdGVjdGlvbiBpbiBNUExTIC0gWXVhbmxvbmcgSklBTkcKaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctcHdlMy1tYy1wb24KT2JqZWN0aXZlIC0gZ2V0 IGRpcmVjdGlvbiBmcm9tIHRoZSBXRwoKRWQgTWFsbGV0dGUgcHJlc2VudGVkIC0gClRoZSBwcm90 ZWN0aW9uIG9mIGEgdHJlZSBvZiBEU0wgaXMgZm9yIEZpYmVyIHRoZSBjdXJiIGFuZCBWU0RMLgpM b29raW5nIGZvciBXRyBndWlkYW5jZSwgKGRlc3BpdGUgbGFjayBvZiBsaXN0IGludGVyZXN0KS4g IApZSlM6IGhvdyBtdWNoIGlzIGRlcGxveWVkIHdpdGggdGhlIDI6biBzcGxpdHRlcnM/CkVkOiBC cmlnaHQgSG91c2Ugd291bGQgcHJvYmFibHkgZG8gaXQuIFRoZSBzcGxpdHRlciB3b3VsZCBiZSBp biBob3VzZSBhcyBpdCBzb2x2ZXMgb3RoZXIgaXNzdWVzLiAgUE9OIGlzIGdyb3dpbmcsIGJ1dCBu b3QgYSBncmVhdCBkZWFsIGRlcGxveWVkIGluIE5BIGNhYmxlLgpZdWFubG9uZzogdXNlZCBmb3Ig c21hbGwgY2VsbCBiYWNraGF1bC4gQ2FuIHByb3RlY3QgYSBidW5jaCBvZiBzbWFsbCBjZWxscy4g IApZSlM6IHNvIGZhciBpbnRlcmVzdCBpbiwgYnV0IG5vdCBkZXBsb3llZC4gIDI6TiBzcGxpdHRl ciBuZWVkcyB0byByZXN5bmNoLiAgV2h5IGRvIHdlIG5lZWQgaWYgcGh5IG5vdCB0aGVyZS4KQW5k eTogcGxlYXNlIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIGxpc3QuCk1hdHRoZXc6IHJlYWRlcnM/ IDQsIG9ubHkgb25lIGNvbW1lbnRlciBvbiB0aGUgbGlzdAoKMy4gMTAgbWluIC0gRHVhbC1Ib21p bmcgUHJvdGVjdGlvbiBmb3IgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgUHNldWRv d2lyZXMgLSBXZWlxaWFuZyBDSEVORyAKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2hlbmctcHdlMy1tcGxzLXRwLWR1YWwtaG9taW5nLXByb3RlY3Rpb24tMDAgCk9iamVjdGl2ZSAt IGRyYWZ0IGludHJvZHVjdGlvbiAKCldlaXFpYW5nIHByZXNlbnRlZCAtIApkcmFmdCBwcmVzZW50 ZWQgaW4gSUVURiA4OCBhbmQgcmVuYW1lZC4KTWFueSBzaXR1YXRpb25zIHVzaW5nIHN0YXRpYyBw cm92aXNpb25pbmcuIFdhbnQgYSBzaW1wbGUgc29sdXRpb24gc3VjaCBhcyBsaW5lYXIgcHJvdGVj dGlvbiBmb3IgZHVhbCBob21pbmcgdGhhdCBpcyBlYXN5IHRvIG9wZXJhdGUuClRoZSBzb2x1dGlv biBpcyBkZXBsb3llZCB0byBhbGwgQ2hpbmEgTW9iaWxlIDNHIGJhc2Ugc3RhdGlvbnMuCgpEaWZm ZXJlbnQgTWVjaGFuaXNtcyAKT3BlcmF0b3Igd2FudHMgbG9jYWwgcHJvdGVjdGlvbiBub3QgY2F1 c2luZyBuZXR3b3JrIHN3aXRjaGluZwpNUExTLVRQIExpbmVhciBQcm90ZWN0aW9uIDYzNzggZG9l cyBub3QgY292ZXIgZHVhbCBob21pbmcKClR5cGljYWwgU2NlbmFyaW8gc2xpZGUKY292ZXIgdGhy ZWUgdHlwZXMgb2YgZmFpbHVyZXM6IFBXLCBub2RlIGFuZCBBQyBmYWlsdXJlLgpQRTEgYW5kIFBF MiBoYXZlIGNvb3JkaW5hdGlvbiBtZXNzYWdlcywgd29ya2luZyBsaWtlIG9uZSBub2RlClBFMyBy dW5uaW5nIEFQUyAoY291bGQgcnVuIFBTQykKSWYgUEUxIGZhaWxzIFBFMiBhbmQgMyBkZXRlY3Qg ZmFpbHVyZSBhbmQgc3dpdGNoLgoKUHJvcG9zZWQgU29sdXRpb24gc2xpZGUKUHJvY2VkdXJlcyBz bGlkZQpCZW5lZml0cyBzbGlkZQpOZXh0IHN0ZXBzIC0gYXNraW5nIGZvciBXRyBhZG9wdGlvbgpZ SlM6IGlzIHRoaXMgdGhlIG9uZSB0aGF0IGRvZXNuJ3QgdXNlIExEUD8KTWF0dGhldzogTm8sIEkg d2FzIHRhbGtpbmcgYWJvdXQgV0cgZHJhZnRzCllKUzpkbyB5b3UgbmVlZCBhIG5ldyBBQ0g/Cldl aXFpYW5nOiBubyB3ZSBjb3VsZCB1c2UgZXhpc3RpbmcsIGJ1dCBuZWVkIHRvIHVzZSB3aGF0IGlz IHByb3Blci4KWUpTOiBpZiBwdXJwb3NlIG9mIGRyYWZ0IGlzIHRvIHJlcXVlc3QgY29kZSBwb2lu dHMgZnJvbSBJQU5BLCB0aGlzIGxvb2tzIGxpa2Ugc29tZXRoaW5nIHdlIGFscmVhZHkgaGF2ZS4g IExldCdzIGp1c3QgbWFrZSB0aGlzIGluZm9ybWF0aW9uYWwgUkZDLiBXZSBhbHJlYWR5IGhhdmUg YSBtZWNoYW5pc20gYW5kIHdvdWxkbid0IGJlIHdpZGVseSB1c2UuICAKV2VpcWlhbmc6IHdoeSBp bmZvcm1hdGlvbmFsPwpZSlM6IHdlIGFscmVhZHkgaGF2ZSBtZWNoYW5pc21zIHRoYXQgZG8gdGhp cyBlLmcuLCBQVyByZWR1bmRhbmN5CldlaXF1aWFuZzogZm9yIHByb3RlY3Rpb24gaG93IGNhbiB3 ZSBkZXRlcm1pbmUgaXQgaXMgaW5mb3JtYXRpb25hbCBvciBzdGFuZGFyZHMuICAKQW5keTogdGhp cyBpcyBzb21ldGhpbmcgdG8gYmUgdGFrZW4gdG8gdGhlIGxpc3QuICBUaGUgdGV4dCBhcyB3cml0 dGVuIHJlcXVpcmVzIGEgbmV3IHJlZ2lzdHJ5LgoKCjQuIDEwIG1pbiAtIEVuY2Fwc3VsYXRpb24g Zm9yIFBTQyBmb3IgTXVsdGktU2VnbWVudCBQc2V1ZG93aXJlcyAtIExvYSBBTkRFUlNTT04gCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoYXdhbS1wd2UzLW1zLXB3LXByb3RlY3Rp b24tMDAudHh0IApPYmplY3RpdmUgLSBub25lIHByb3ZpZGVkCgpMb2EgcHJlc2VudGVkIHRoZSBz bGlkZXMKVGhpcyBpcyBhIGNhc2UgdGhhdCBpcyBhIGNvcm5lciBjYXNlIGJ1dCBpdCBpcyBpbXBv cnRhbnQuCldpdGggYSBzdGF0aWNhbGx5IHByb3Zpc2lvbmVkIE1TLVBXLCB0aGUgY3VycmVudCBs aW5lIHByb3RlY3Rpb24gc3RhbmRhcmQgZG9lc24ndCBjb3ZlciB0aGUgUy1QRXMuIAoKVGhlcmUg d2FzIHNvbWUgY29uY2x1c2lvbiB0aGF0IG9uZSBjb3VsZCB1c2Ugc3RhdGljIFBXIHNpZ25hbGlu ZyB0byBoYW5kbGUgdGhpcyBjYXNlLgpUaGUgZHJhZnQgbmVlZHMgbW9yZSBkZXRhaWxzIGFuZCBj b21tZW50cy4gCklmIHRoaXMgY2FuIGJlIGRvbmUgd2l0aCBleGlzdGluZyBtZWNoYW5pc21zLCB3 b3VsZCBiZSBoYXBweSB0byBkaXNjb250aW51ZSB0aGUgd29yay4KNC01IGZvbGtzIHJlYWQgdGhl IGRyYWZ0LgpNYXR0aGV3OiB0aGVyZSB3YXMgYSBkcmFmdCAzLTQgeWVhcnMgYWdvIHRvIHVzZSBQ U0Mgb24gUFdzLgpQbGVhc2UgY29tbWVudCBvbiB0aGUgbGlzdCB3aGV0aGVyIHRoZXJlIGlzIGEg cHJvYmxlbSB0aGF0IGlzbid0IGFkZHJlc3NlZC4KCk5vIGZ1cnRoZXIgY29tbWVudC4KQW5keSBh bmQgTWF0dGhldyBjbG9zZWQgdGhlIG1lZXRpbmcuCgoKCgoKKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCk92ZXJmbG93 IChXaWxsIGJlIHByZXNlbnRlZCBpZiB0aW1lIHBlcm1pdHMuKQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCgp4eC4g LSBOb25lIGN1cnJlbnRseQoKKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpSRU1PVEUgSU5GT1JNQVRJT04gRk9SIFRI RSBQV0UzIFNFU1NJT04oUykKKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpSZW1vdGUgUGFydGljaXBhdGlvbiBJbmZv OiAKaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkwL3JlbW90ZS1wYXJ0aWNpcGF0aW9uLmh0 bWwKCi0gTm8gV2ViRXgKCi0gQXVkaW8gd2lsbCBiZSBvbjogaHR0cDovL2lldGY5MHN0cmVhbWlu Zy5kbnNhbGlhcy5uZXQvaWV0Zi9pZXRmOTAzLm0zdSAKCi0gSmFiYmVyIHJvb20gaXMgInB3ZTMi ICBAamFiYmVyLmlldGYub3JnCg== --_004_CFFBDAD267240matthewboccialcatellucentcom_-- From nobody Mon Jul 28 04:16:33 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B651A0402 for ; Mon, 28 Jul 2014 04:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELvdEIbicE4d for ; Mon, 28 Jul 2014 04:16:25 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D8F1A03CB for ; Mon, 28 Jul 2014 04:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26118; q=dns/txt; s=iport; t=1406546167; x=1407755767; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=5IC0+8e0LuP87RKuIopeh7sA1RojtmL/M7mVS9icU5I=; b=aaZWLOQFkmokUgK4LpTr4yPEBNvL6FwVYv6vt72Jb3ovu9Rnq2UJftxj BRMECuPD075y2evT4UyBkOpIHaZf3Xnt9EwTNlkXO8azFTM6bitX0IBES IILYeo3sP2wJxenDVr6gBOV+eMlY1zmRxL4WQ/c7cPlz9cMJR5Q6yEo1w w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAE0w1lOtJssW/2dsb2JhbABZgkeBGVfLbAEJh0UBgSp3hAMBAQECAgEBARoQQQYEARALEQQBAQEJFgEBAgQHCQMCAQIBFR8JCAYBDAEFAgEBBYg5Da02j3IXjmoRAS4iBgEGhEQFjRyOMIFSknqCA4FHawGBCw X-IronPort-AV: E=Sophos;i="5.01,748,1400025600"; d="scan'208,217";a="125336786" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 28 Jul 2014 11:16:05 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6SBG1JZ006290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 11:16:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6SBFw2N010407; Mon, 28 Jul 2014 12:16:00 +0100 (BST) Message-ID: <53D630EE.4000008@cisco.com> Date: Mon, 28 Jul 2014 12:15:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexander Vainshtein , "Andrew G. Malis" References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------070304000008080206020407" Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Bu9m_Jv1kOBSr4ZweEAdEvIoUnA Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Jul 2014 11:16:29 -0000 This is a multi-part message in MIME format. --------------070304000008080206020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is a well written draft, that makes a useful contribution to a long standing problem and I fully support its publication as an RFC. I have a few comments that I would request that the authors consider and a couple of nits. I also agree with the points that Sasha makes, and am also pleased that no changes are required to this widely deployed packet transport mechanism. Firstly I think that you should say a little bit more about the circuit breaker than you currently do, in particular the interaction with the control plane and the restart procedure. Secondly, whilst Ethernet PWs are a good example and by far the most common elastic case they are not the only elastic PWs type. You need a line in the text pointing out the equivalence and possibly naming the current types that behave in the same way as IP. SB> Where does ATM fit into the taxonomy? SB> Also what about FC Port Mode? nits: such a PW is inable to respond to congestion in a TCP-like manner; SB> That should be unable the packet loss rate PLR SB> PLR should be (PLR) The circuit breaker needs a ref on first use, and maybe a little description since it is a new concept in PWE3 - Stewart On 28/07/2014 09:03, Alexander Vainshtein wrote: > > Andy and all, > > Somehow I did not find an explicit WGLC message for this draft > (neither in my archive nor in the WG one). > > Nevertheless, I support requesting publication of this draft as an > Informational RFC. > > I have a few editorial comments: > > 1.On page 6 the text says "International standards place stringent > limits on the number of such faults tolerated". I assume the > reference is to ITU-T Recommendation G.826, but it would be nice to > state that explicitly; I am also not sure whether plural ("standards") > is justified here. > > 2.Also on page 6, I suggest inserting the multiplication signs > (asterisks) in the formula in the same way it is done in Section 3.1 > of RFC 5348 (from which this > formula is taken) > > 3.On page 11, "Second, the derivation assumed that the TDM PW was > competing with long-lived TDM flows" presumably should be "Second, the > derivation assumed that the TDM PW was competing with long-lived TCP > flows". > > 4.On page 18, "Note that if the error condition AIS was detected > according to the criteria of ITU-T Recommendation G.775 [G826]" > presumably should be "Note that if the error condition AIS was > detected according to the criteria of ITU-T Recommendation G.775 [G775]". > > IMO neither of these comments requires posting a new version of the > draft prior to requesting its publication; hopefully they can be > handled in the process of approval and publication. > > I'd like to thank Yaakov, David and Bob for their effort. I find very > symbolic that the congestion issue that has been raised in the early > days of PWE3 is -- at long last -- successfully resolved without any > retro-fitting of widely deployed mechanisms defined by the PWE3. > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > *From:*pwe3 [mailto:pwe3-bounces@ietf.org] *On Behalf Of *Andrew G. Malis > *Sent:* Friday, July 25, 2014 6:23 PM > *To:* pwe3@ietf.org > *Subject:* [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 > > http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 > WG last call. As part of the last call process, we need to poll the > authors and WG for IPR information on the draft. > > Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there > are currently no IPR disclosures in the IETF datatracker. > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. The response needs to be sent to the PWE3 WG mailing > list. The document will not advance to the next stage until a response > has been received from each author and each contributor. > > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > Thanks, > > Andy > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070304000008080206020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This is a well written draft, that makes a useful
contribution to a long standing problem and
I fully support its publication as an RFC.

I have a few comments that I would request
that the authors consider and a couple
of nits. I also agree with the points that
Sasha makes, and am also pleased that no
changes are required to this widely deployed
packet transport mechanism.

Firstly I think that you should say a little bit
more about the circuit breaker than you currently
do, in particular the interaction with the control plane
and the restart procedure.

Secondly, whilst Ethernet PWs are a good example
and by far the most common elastic case they are not
the only elastic PWs type. You need a line in the text
pointing out the equivalence and possibly naming
the current types that behave in the same way as
IP.

SB> Where does ATM fit into the taxonomy?

SB> Also what about FC Port Mode?


nits:

such a PW is inable to respond to congestion in a
TCP-like manner;

SB> That should be unable

the packet loss rate PLR

SB> PLR should be (PLR)

The circuit breaker needs a ref on first
use, and maybe a little description since
it is a new concept in PWE3

- Stewart



On 28/07/2014 09:03, Alexander Vainshtein wrote:

Andy and all,

Somehow I did not find an explicit WGLC message for this draft (neither in my archive nor in the WG one).

 

Nevertheless, I support requesting publication of this draft as an Informational RFC.

 

I have a few editorial comments:

1.       On page 6 the text says “International standards place stringent limits on the number of such faults tolerated”.  I assume the reference is to ITU-T Recommendation G.826, but it would be nice to state that explicitly; I am also not sure whether plural (“standards”) is justified here.

2.       Also on page 6, I suggest inserting the multiplication signs (asterisks) in the formula  in the same way it is done in Section 3.1 of RFC 5348 (from which this formula is taken)

3.       On page 11, “Second, the derivation assumed that the TDM PW was competing with long-lived TDM flows” presumably should be “Second, the derivation assumed that the TDM PW was competing with long-lived TCP flows”.  

4.       On page 18, “Note that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]” presumably should be “Note that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775]”.

 

IMO neither of these comments requires posting a new version of the draft prior to requesting its publication; hopefully they can be handled in the process of approval and publication.

 

I’d like to thank Yaakov, David and Bob for their effort. I find very symbolic that the congestion issue that has been raised in the early days of PWE3 is – at long last – successfully resolved without any retro-fitting of widely deployed mechanisms defined by the PWE3.

 

Regards,

       Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02

 

http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG last call. As part of the last call process, we need to poll the authors and WG for IPR information on the draft.

Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no IPR disclosures in the IETF datatracker.

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

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

Thanks,

Andy



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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070304000008080206020407-- From nobody Mon Jul 28 05:11:50 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0231A1A0162 for ; Mon, 28 Jul 2014 05:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rSi3QpeZL_V for ; Mon, 28 Jul 2014 05:11:37 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB601A040B for ; Mon, 28 Jul 2014 05:11:33 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 12:11:31 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Mon, 28 Jul 2014 12:11:31 +0000 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) Thread-Index: AQHPqlVhpmio+eBrs0KjDhWSQ4CCKpu1YSmA Date: Mon, 28 Jul 2014 12:11:30 +0000 Message-ID: <1d874f1da4534d98af29d6c0baaaadd8@AM3PR03MB612.eurprd03.prod.outlook.com> References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> <53D630EE.4000008@cisco.com> In-Reply-To: <53D630EE.4000008@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(252514010)(164054003)(85664002)(51444003)(377454003)(479174003)(243025005)(76176999)(101416001)(19300405004)(50986999)(46102001)(16236675004)(15202345003)(54356999)(81542001)(76576001)(79102001)(81342001)(74662001)(2656002)(92566001)(64706001)(31966008)(86362001)(87936001)(74316001)(4396001)(99396002)(74502001)(19625215002)(19580405001)(20776003)(15975445006)(85306003)(77982001)(66066001)(80022001)(110136001)(2351001)(105586002)(33646002)(95666004)(106356001)(19617315012)(107046002)(83072002)(85852003)(83322001)(19580395003)(106116001)(76482001)(21056001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_1d874f1da4534d98af29d6c0baaaadd8AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/UNI684qDV9VIdMgKXTcHUY4e1I4 Cc: "Andrew G. Malis" , "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:11:48 -0000 --_000_1d874f1da4534d98af29d6c0baaaadd8AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart and all, I fully agree with you that the term "circuit breaker" has not been used in= the PWE3 discussions until now. However, I think that it has been implicitly defined in Section 6.5. of RFC= 3985, and its usage has be= en defined also in Section 8 of RFC 4553. Not sure how important this is; but if the authors decide to expand the "ci= rcuit breaker" notion, these references could be handy. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Monday, July 28, 2014 2:16 PM To: Alexander Vainshtein; Andrew G. Malis Cc: pwe3@ietf.org Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR= poll for draft-ietf-pwe3-congcons-02) This is a well written draft, that makes a useful contribution to a long standing problem and I fully support its publication as an RFC. I have a few comments that I would request that the authors consider and a couple of nits. I also agree with the points that Sasha makes, and am also pleased that no changes are required to this widely deployed packet transport mechanism. Firstly I think that you should say a little bit more about the circuit breaker than you currently do, in particular the interaction with the control plane and the restart procedure. Secondly, whilst Ethernet PWs are a good example and by far the most common elastic case they are not the only elastic PWs type. You need a line in the text pointing out the equivalence and possibly naming the current types that behave in the same way as IP. SB> Where does ATM fit into the taxonomy? SB> Also what about FC Port Mode? nits: such a PW is inable to respond to congestion in a TCP-like manner; SB> That should be unable the packet loss rate PLR SB> PLR should be (PLR) The circuit breaker needs a ref on first use, and maybe a little description since it is a new concept in PWE3 - Stewart On 28/07/2014 09:03, Alexander Vainshtein wrote: Andy and all, Somehow I did not find an explicit WGLC message for this draft (neither in = my archive nor in the WG one). Nevertheless, I support requesting publication of this draft as an Informat= ional RFC. I have a few editorial comments: 1. On page 6 the text says "International standards place stringent limits = on the number of such faults tolerated". I assume the reference is to ITU-= T Recommendation G.826, but it would be nice to state that explicitly; I am= also not sure whether plural ("standards") is justified here. 2. Also on page 6, I suggest inserting the multiplication signs (asterisks)= in the formula in the same way it is done in Section 3.1 of RFC 5348 (from which this formula is taken) 3. On page 11, "Second, the derivation assumed that the TDM PW was competin= g with long-lived TDM flows" presumably should be "Second, the derivation a= ssumed that the TDM PW was competing with long-lived TCP flows". 4. On page 18, "Note that if the error condition AIS was detected according= to the criteria of ITU-T Recommendation G.775 [G826]" presumably should be= "Note that if the error condition AIS was detected according to the criter= ia of ITU-T Recommendation G.775 [G775]". IMO neither of these comments requires posting a new version of the draft p= rior to requesting its publication; hopefully they can be handled in the pr= ocess of approval and publication. I'd like to thank Yaakov, David and Bob for their effort. I find very symbo= lic that the congestion issue that has been raised in the early days of PWE= 3 is - at long last - successfully resolved without any retro-fitting of wi= dely deployed mechanisms defined by the PWE3. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, July 25, 2014 6:23 PM To: pwe3@ietf.org Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG la= st call. As part of the last call process, we need to poll the authors and = WG for IPR information on the draft. Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there are currently no IPR disclosures in the IETF datatracker. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the PWE3 WG mailing list. The document will not advance to the next stage until a response has been received from each author and each contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Andy _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_1d874f1da4534d98af29d6c0baaaadd8AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart and all,

I fully agree with you th= at the term “circuit breaker” has not been used in the PWE3 dis= cussions until now.

However, I think that it = has been implicitly defined in Section 6.5. of = RFC 3985, and its usage has been defined also in Section 8 of RFC 4= 553.

Not sure how important th= is is; but if the authors decide to expand the “circuit breaker”= ; notion, these references could be handy.

 <= /p>

Regards,

    &= nbsp;  Sasha

Email: Alexander.Vainshte= in@ecitele.com

Mobile: 054-9266302<= /o:p>

 <= /p>

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, July 28, 2014 2:16 PM
To: Alexander Vainshtein; Andrew G. Malis
Cc: pwe3@ietf.org
Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (w= as: IPR poll for draft-ietf-pwe3-congcons-02)

 

This is a well writte= n draft, that makes a useful
contribution to a long standing problem and
I fully support its publication as an RFC.

I have a few comments that I would request
that the authors consider and a couple
of nits. I also agree with the points that
Sasha makes, and am also pleased that no
changes are required to this widely deployed
packet transport mechanism.

Firstly I think that you should say a little bit
more about the circuit breaker than you currently
do, in particular the interaction with the control plane
and the restart procedure.

Secondly, whilst Ethernet PWs are a good example
and by far the most common elastic case they are not
the only elastic PWs type. You need a line in the text
pointing out the equivalence and possibly naming
the current types that behave in the same way as
IP.

SB> Where does ATM fit into the taxonomy?

SB> Also what about FC Port Mode?


nits:

such a PW is inable to respond to congestion in a
TCP-like manner;<= /p>


SB> That should be unable

the packet loss rate PLR

SB> PLR should be (PLR)

The circuit breaker needs a ref on first use, and maybe a little description since<= br> it is a new concept in PWE3

- Stewart



On 28/07/2014 09:03, Alexander Vainshtein wrote:

Andy and all,=

Somehow I did not find an= explicit WGLC message for this draft (neither in my archive nor in the WG = one).

 <= /p>

Nevertheless, I support r= equesting publication of this draft as an Informational RFC.

 <= /p>

I have a few editorial comm= ents:

1. On page 6 the text says “Int= ernational standards place stringent limits on the number of such faults tolerated”.  I assume = the reference is to ITU-T Recommendation G.826, but it would be nice to sta= te that explicitly; I am also not sure whether plural (“standards= ”) is justified here.

2. Also on page 6, I suggest inserting the multiplication signs (asterisks) i= n the formula  in the same way it is done in Section 3.1 of RFC 5348 (from which= this formula is taken)

3. On page 11, “Second, the der= ivation assumed that the TDM PW was competing with long-lived TDM flows” presumably should be “Second, the derivation assumed that the TDM PW was competing with long-lived TCP flows”.  

4. On page 18, “Note that if th= e error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]” presumably should be= “Note that if the error cond= ition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775]= ”.

 

IMO neither of these commen= ts requires posting a new version of the draft prior to requesting its publ= ication; hopefully they can be handled in the process of approval and publication.

 <= /p>

I’d like to thank Y= aakov, David and Bob for their effort. I find very symbolic that the conges= tion issue that has been raised in the early days of PWE3 is – at long last – successfully resolved without any retro-fitting of wi= dely deployed mechanisms defined by the PWE3.

 <= /p>

Regards,

    &= nbsp;  Sasha

Email: Alexander.Vainshtein@ec= itele.com

Mobile: 054-9266302

 <= /p>

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02=

 

http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now = in PWE3 WG last call. As part of the last call process, we need to poll the authors and WG for IPR information on the draft.

Are you aware of any IPR&nb= sp;that applies to draft-ietf-pwe3-congcons-02?

If so, has this IPR bee= n disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no IPR di= sclosures in the IETF datatracker.

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response n= eeds to be sent to the PWE3 WG mailing
list. The document will not advance to the next stage until a response
has been received from each author and each contributor.

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

Thanks,

Andy




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




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_1d874f1da4534d98af29d6c0baaaadd8AM3PR03MB612eurprd03pro_-- From nobody Mon Jul 28 05:49:27 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563881A0185 for ; Mon, 28 Jul 2014 05:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShwsJVIPrGKl for ; Mon, 28 Jul 2014 05:49:17 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882211A031F for ; Mon, 28 Jul 2014 05:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32658; q=dns/txt; s=iport; t=1406551756; x=1407761356; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Z2CFXoG34aM0bZCajLOD7nK4gSylvMZgPEjEmd3QW04=; b=jEM5D7LgdyHVgtD8Z7xvb+SqZFtJD0TF3ww/fmuN7g6EUAoq3zR4HoLw 1/eHKA+7W7U6MvGplEtT94i/rLdW5VbVyEx5N3+BozCY0fbRwrGYnVgp2 ncEoOKhA39xzkdFBJ8T4e/JHQBEQOR4XhESk0cF4LPXg7yQxg+F129kNO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAO1F1lOtJssW/2dsb2JhbABZgkeBGVfLfgEJh0UBgSh3hAMBAQECAgEBARoQQQYEARALEQQBAQEJFgEBAgQHCQMCAQIBFR8JCAYNAQUCAQEFiDkNrWiPfheOahEBLiIGAQaERAWNHI4wgVKSeoIDgUdrAYEL X-IronPort-AV: E=Sophos;i="5.01,749,1400025600"; d="scan'208,217";a="120640290" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 28 Jul 2014 12:49:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6SCnDr3022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 12:49:13 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6SCnAAm012810; Mon, 28 Jul 2014 13:49:12 +0100 (BST) Message-ID: <53D646C6.5050406@cisco.com> Date: Mon, 28 Jul 2014 13:49:10 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexander Vainshtein References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> <53D630EE.4000008@cisco.com> <1d874f1da4534d98af29d6c0baaaadd8@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <1d874f1da4534d98af29d6c0baaaadd8@AM3PR03MB612.eurprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------060808020809080607050000" Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/NIRPLrP8tWeTIyz_o6TrXCD9bdw Cc: "Andrew G. Malis" , "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Jul 2014 12:49:24 -0000 This is a multi-part message in MIME format. --------------060808020809080607050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Those refs would be handy. I think that it just takes a couple of sentences and will anticipate the various directorate and IESG review comments. S On 28/07/2014 13:11, Alexander Vainshtein wrote: > > Stewart and all, > > I fully agree with you that the term "circuit breaker" has not been > used in the PWE3 discussions until now. > > However, I think that it has been implicitly defined in Section 6.5. > of RFC 3985 , and its > usage has been defined also in Section 8 of RFC 4553 > . > > Not sure how important this is; but if the authors decide to expand > the "circuit breaker" notion, these references could be handy. > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Monday, July 28, 2014 2:16 PM > *To:* Alexander Vainshtein; Andrew G. Malis > *Cc:* pwe3@ietf.org > *Subject:* Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? > (was: IPR poll for draft-ietf-pwe3-congcons-02) > > This is a well written draft, that makes a useful > contribution to a long standing problem and > I fully support its publication as an RFC. > > I have a few comments that I would request > that the authors consider and a couple > of nits. I also agree with the points that > Sasha makes, and am also pleased that no > changes are required to this widely deployed > packet transport mechanism. > > Firstly I think that you should say a little bit > more about the circuit breaker than you currently > do, in particular the interaction with the control plane > and the restart procedure. > > Secondly, whilst Ethernet PWs are a good example > and by far the most common elastic case they are not > the only elastic PWs type. You need a line in the text > pointing out the equivalence and possibly naming > the current types that behave in the same way as > IP. > > SB> Where does ATM fit into the taxonomy? > > SB> Also what about FC Port Mode? > > > nits: > > such a PW is inable to respond to congestion in a > TCP-like manner; > > > SB> That should be unable > > the packet loss rate PLR > > SB> PLR should be (PLR) > > The circuit breaker needs a ref on first > use, and maybe a little description since > it is a new concept in PWE3 > > - Stewart > > > > On 28/07/2014 09:03, Alexander Vainshtein wrote: > > Andy and all, > > Somehow I did not find an explicit WGLC message for this draft > (neither in my archive nor in the WG one). > > Nevertheless, I support requesting publication of this draft as an > Informational RFC. > > I have a few editorial comments: > > 1.On page 6 the text says "International standards place stringent > limits on the number of such faults tolerated". I assume the > reference is to ITU-T Recommendation G.826, but it would be nice > to state that explicitly; I am also not sure whether plural > ("standards") is justified here. > > 2.Also on page 6, I suggest inserting the multiplication signs > (asterisks) in the formula in the same way it is done in Section > 3.1 of RFC 5348 (from which > this formula is taken) > > 3.On page 11, "Second, the derivation assumed that the TDM PW was > competing with long-lived TDM flows" presumably should be "Second, > the derivation assumed that the TDM PW was competing with > long-lived TCP flows". > > 4.On page 18, "Note that if the error condition AIS was detected > according to the criteria of ITU-T Recommendation G.775 [G826]" > presumably should be "Note that if the error condition AIS was > detected according to the criteria of ITU-T Recommendation G.775 > [G775]". > > IMO neither of these comments requires posting a new version of > the draft prior to requesting its publication; hopefully they can > be handled in the process of approval and publication. > > I'd like to thank Yaakov, David and Bob for their effort. I find > very symbolic that the congestion issue that has been raised in > the early days of PWE3 is -- at long last -- successfully resolved > without any retro-fitting of widely deployed mechanisms defined by > the PWE3. > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > > Mobile: 054-9266302 > > *From:*pwe3 [mailto:pwe3-bounces@ietf.org] *On Behalf Of *Andrew > G. Malis > *Sent:* Friday, July 25, 2014 6:23 PM > *To:* pwe3@ietf.org > *Subject:* [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 > > http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in > PWE3 WG last call. As part of the last call process, we need to > poll the authors and WG for IPR information on the draft. > > Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there > are currently no IPR disclosures in the IETF datatracker. > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. The response needs to be sent to the PWE3 WG mailing > list. The document will not advance to the next stage until a response > has been received from each author and each contributor. > > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > Thanks, > > Andy > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------060808020809080607050000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Those refs would be handy. I think that it just takes a couple
of sentences and will anticipate the various directorate and
IESG review comments.

S



On 28/07/2014 13:11, Alexander Vainshtein wrote:

Stewart and all,

I fully agree with you that the term “circuit breaker” has not been used in the PWE3 discussions until now.

However, I think that it has been implicitly defined in Section 6.5. of RFC 3985, and its usage has been defined also in Section 8 of RFC 4553.

Not sure how important this is; but if the authors decide to expand the “circuit breaker” notion, these references could be handy.

 

Regards,

       Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, July 28, 2014 2:16 PM
To: Alexander Vainshtein; Andrew G. Malis
Cc: pwe3@ietf.org
Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02)

 

This is a well written draft, that makes a useful
contribution to a long standing problem and
I fully support its publication as an RFC.

I have a few comments that I would request
that the authors consider and a couple
of nits. I also agree with the points that
Sasha makes, and am also pleased that no
changes are required to this widely deployed
packet transport mechanism.

Firstly I think that you should say a little bit
more about the circuit breaker than you currently
do, in particular the interaction with the control plane
and the restart procedure.

Secondly, whilst Ethernet PWs are a good example
and by far the most common elastic case they are not
the only elastic PWs type. You need a line in the text
pointing out the equivalence and possibly naming
the current types that behave in the same way as
IP.

SB> Where does ATM fit into the taxonomy?

SB> Also what about FC Port Mode?


nits:

such a PW is inable to respond to congestion in a
TCP-like manner;


SB> That should be unable

the packet loss rate PLR

SB> PLR should be (PLR)

The circuit breaker needs a ref on first
use, and maybe a little description since
it is a new concept in PWE3

- Stewart



On 28/07/2014 09:03, Alexander Vainshtein wrote:

Andy and all,

Somehow I did not find an explicit WGLC message for this draft (neither in my archive nor in the WG one).

 

Nevertheless, I support requesting publication of this draft as an Informational RFC.

 

I have a few editorial comments:

1. On page 6 the text says “International standards place stringent limits on the number of such faults tolerated”.  I assume the reference is to ITU-T Recommendation G.826, but it would be nice to state that explicitly; I am also not sure whether plural (“standards”) is justified here.

2. Also on page 6, I suggest inserting the multiplication signs (asterisks) in the formula  in the same way it is done in Section 3.1 of RFC 5348 (from which this formula is taken)

3. On page 11, “Second, the derivation assumed that the TDM PW was competing with long-lived TDM flows” presumably should be “Second, the derivation assumed that the TDM PW was competing with long-lived TCP flows”.  

4. On page 18, “Note that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]” presumably should be “Note that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775]”.

 

IMO neither of these comments requires posting a new version of the draft prior to requesting its publication; hopefully they can be handled in the process of approval and publication.

 

I’d like to thank Yaakov, David and Bob for their effort. I find very symbolic that the congestion issue that has been raised in the early days of PWE3 is – at long last – successfully resolved without any retro-fitting of widely deployed mechanisms defined by the PWE3.

 

Regards,

       Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02

 

http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG last call. As part of the last call process, we need to poll the authors and WG for IPR information on the draft.

Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no IPR disclosures in the IETF datatracker.

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

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

Thanks,

Andy




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




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------060808020809080607050000-- From nobody Mon Jul 28 05:53:51 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142601A031F for ; Mon, 28 Jul 2014 05:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGDcWNAVqoQu for ; Mon, 28 Jul 2014 05:53:46 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7831A0196 for ; Mon, 28 Jul 2014 05:53:46 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id cm18so7749788qab.18 for ; Mon, 28 Jul 2014 05:53:45 -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=NSdGRKxlr+4mHp8s50BOJONKUiGPQE7NZ9XmWIW/7w8=; b=NoBLmA90MWdbaFuSEf5Z8ZVxizIcw7XiRzVk6/aoo4NmuXmRWPjChA5fDygA9ufM7I mQ/4J+ZUyz4x6KtLUppx8dvd3ETCjW5/eKGrk/EmmRSB7XC/ObbXMyvzkxSBvEba2qAx CdckdsYlpQncR0Vn1wlfYxwr5lBtuE0RcyKgyxH6qv2HYg8yk9oGFMkvIIybtKdH4tQO 2wMa77eZuNdLg2ltPmdqmPDplKU+mvf7hb3Cvowc/+afQR4inZ2o10XzJnowS4oBdTBq dGxfwrFKPVwc+g1+Mdf3nZrHcH1yi2Wp9m7hQ8GyMxTukJX5DWUISVBE44dev9vA8xmO PqrA== X-Received: by 10.140.107.131 with SMTP id h3mr60515987qgf.83.1406552025869; Mon, 28 Jul 2014 05:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Mon, 28 Jul 2014 05:53:25 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 28 Jul 2014 08:53:25 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a113a7f76dc321004ff4069d7 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/oU8Rn15sg7b2NbUrXIpEZsazb0w Subject: [PWE3] Fwd: WG Last Call draft-ietf-pwe3-congcons-02.pdf X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:53:48 -0000 --001a113a7f76dc321004ff4069d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I meant to send this on Friday, for some reason it never made it out on the list ... so I'm resending. This email begins a two week working group last call for http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf . Be sure to use the PDF version, as this is only version that has the diagrams (when you see the diagrams, you'll realize why). Please review the draft and post any comments to the PWE3 list. If you have read the draft, even if you don=C2=B9t have any comments, but w= ould like to see the draft progressed, please can you indicate this to the list. This working group last call will end on Monday, August 11th, 2014. Best regards, Andy and Matthew --001a113a7f76dc321004ff4069d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I meant to send this on Friday, for some reason it never m= ade it out on the list ... so I'm resending.

This email begins a two week working group last call for=C2=A0http://www.ietf.org/id/draft= -ietf-pwe3-congcons-02.pdf . Be sure to use the PDF version, as this is= only version that has the diagrams (when you see the diagrams, you'll = realize why).

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

If you have read the draft, even= if you don=C2=B9t have any comments, but would=C2=A0like to see the draft progress= ed, =C2=A0please can you indicate this to the=C2=A0list.

This working group last call wil= l end on=C2=A0Monday, August 11th, 2014.

Best regard= s,
Andy and Matthew


--001a113a7f76dc321004ff4069d7-- From nobody Mon Jul 28 05:55:45 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955821A0193 for ; Mon, 28 Jul 2014 05:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvWlD15AyRsw for ; Mon, 28 Jul 2014 05:55:41 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E159B1A031F for ; Mon, 28 Jul 2014 05:55:40 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so8494477qgf.17 for ; Mon, 28 Jul 2014 05:55:40 -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=0m56Io87Mj5Moj5WtOCPxH/89/UFYALTXNCpNu9N1Co=; b=u9MaCaG9hxR6RrUM0AK01LfGND+jqg36/r6G6wSIRk2V6Uc4qlL8wpXkgiRAut22z3 PRyTAvxfMaxTrGc/lX1oKrX0wq29gZnziWqwhyY2BaJPC8gsUltrTHslXs7NKjh5c/wY +0U4Phe4E7D9F/Qz2Vrn0UM9Jr2p8DJQqQWsWMbOFCj9jNKCkxYPTgM1Yg0K0f8Z96/y GXPNoWVZwYLXSHmmpT773/vRyrrNEyTmLREDmy+zf79+T9A9aTVb+T+B01Ff7X05Owxx 6qN4PoYqH39qSV+LrAw7Ko2wmEeGXI2O6IaTw+EhCtWTRtdwDjiG4Mj55QyI9n/oQiKX J6PQ== X-Received: by 10.140.37.178 with SMTP id r47mr59548442qgr.59.1406552140111; Mon, 28 Jul 2014 05:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Mon, 28 Jul 2014 05:55:19 -0700 (PDT) In-Reply-To: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> From: "Andrew G. Malis" Date: Mon, 28 Jul 2014 08:55:19 -0400 Message-ID: To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=001a11c15352ab680604ff407098 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/cUY5mJsjNCfcwStvyzD_XQM9cIQ Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:55:43 -0000 --001a11c15352ab680604ff407098 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sasha, Thanks for this note! For some reason, the WG last call never made it onto the list, so I just resent it. And thanks for your comments on the draft. These will be addressed during publication along with other received comments. Cheers, Andy On Mon, Jul 28, 2014 at 4:03 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Andy and all, > > Somehow I did not find an explicit WGLC message for this draft (neither i= n > my archive nor in the WG one). > > > > Nevertheless, I support requesting publication of this draft as an > Informational RFC. > > > > I have a few editorial comments: > > 1. On page 6 the text says =E2=80=9CInternational standards place s= tringent > limits on the number of such faults tolerated=E2=80=9D. I assume the ref= erence > is to ITU-T Recommendation G.826, but it would be nice to state that > explicitly; I am also not sure whether plural (=E2=80=9Cstandards=E2=80= =9D) is justified > here. > > 2. Also on page 6, I suggest inserting the multiplication signs > (asterisks) in the formula in the same way it is done in Section 3.1 of = RFC > 5348 (from which this formula is > taken) > > 3. On page 11, =E2=80=9CSecond, the derivation assumed that the TDM= PW was > competing with long-lived TDM flows=E2=80=9D presumably should be =E2=80= =9CSecond, the > derivation assumed that the TDM PW was competing with long-lived TCP flow= s=E2=80=9D. > > > 4. On page 18, =E2=80=9CNote that if the error condition AIS was de= tected > according to the criteria of ITU-T Recommendation G.775 [G826]=E2=80=9D > presumably should be =E2=80=9CNote that if the error condition AIS was de= tected > according to the criteria of ITU-T Recommendation G.775 [G775]=E2=80=9D. > > > > IMO neither of these comments requires posting a new version of the draft > prior to requesting its publication; hopefully they can be handled in the > process of approval and publication. > > > > I=E2=80=99d like to thank Yaakov, David and Bob for their effort. I find = very > symbolic that the congestion issue that has been raised in the early days > of PWE3 is =E2=80=93 at long last =E2=80=93 successfully resolved without= any retro-fitting > of widely deployed mechanisms defined by the PWE3. > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > > *From:* pwe3 [mailto:pwe3-bounces@ietf.org] *On Behalf Of *Andrew G. Mali= s > *Sent:* Friday, July 25, 2014 6:23 PM > *To:* pwe3@ietf.org > *Subject:* [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 > > > > http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG > last call. As part of the last call process, we need to poll the authors > and WG for IPR information on the draft. > > Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there > are currently no IPR disclosures in the IETF datatracker. > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. The response needs to be sent to the PWE3 WG mailing > list. The document will not advance to the next stage until a response > has been received from each author and each contributor. > > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > Thanks, > > Andy > --001a11c15352ab680604ff407098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sasha,

Thanks for this note! For some r= eason, the WG last call never made it onto the list, so I just resent it.

And thanks for your comments on the draft. These wi= ll be addressed during publication along with other received comments.

Cheers,
Andy


On Mon, Jul 28, 2014 at 4:03 AM, A= lexander Vainshtein <Alexander.Vainshtein@ecitele.com&g= t; wrote:

Andy and all,

Somehow I did not find an= explicit WGLC message for this draft (neither in my archive nor in the WG = one).

=C2=A0

Nevertheless, I support r= equesting publication of this draft as an Informational RFC.<= /span>

=C2=A0

I have a few editorial comments:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On page 6 the text says =E2=80=9CInternational standards place stringent limits on the number of such faults tolerated=E2=80=9D. =C2= =A0I assume the reference is to ITU-T Recommendation G.826, but it would be= nice to state that explicitly; I am also not sure whether plural (=E2=80= =9Cstandards=E2=80=9D) is justified here.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Also on page 6, I suggest inserting the multiplication signs (asterisk= s) in the formula =C2=A0in the same way it is done in Section 3.1 of RF= C 5348 (from which this formula is taken)

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On page 11, =E2=80=9CSecond, t= he derivation assumed that the TDM PW was competing with long-lived TDM flows=E2=80=9D presumably should be =E2=80=9CSecond, the derivation assumed that the TDM PW was competing with long-lived TCP flows=E2=80=9D. =C2=A0<= u>

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On page 18, =E2=80=9CNote that= if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]=E2=80=9D presumably should = be =E2=80=9CNote that if the error = condition AIS was detected according to the criteria of ITU-T Recommendatio= n G.775 [G775]=E2=80=9D.

=C2=A0

IMO neither of these comments requires postin= g a new version of the draft prior to requesting its publication; hopefully= they can be handled in the process of approval and publication.

=C2=A0

I=E2=80=99d like to thank= Yaakov, David and Bob for their effort. I find very symbolic that the cong= estion issue that has been raised in the early days of PWE3 is =E2=80=93 at long last =E2=80=93 successfully resolved without any retro-fitting of = widely deployed mechanisms defined by the PWE3.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Sasha

Email: Alexander.Vainshtein@ec= itele.com

Mobile: 054-9266302

=C2=A0

From: pwe3 [ma= ilto:pwe3-bounce= s@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org=
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02

=C2=A0

http://www.ietf.org/id/draft-ietf-pwe3-congcons-= 02.pdf is now in PWE3 WG last call. As part of the last call process, w= e need to poll the authors and WG for IPR information on the draft.

Are you aware of any=C2=A0IPR=C2= =A0that applies to=C2=A0draft-ietf-pwe3-congcons-02?

If so, has this=C2=A0IPR=C2=A0bee= n disclosed in compliance with IETF=C2=A0IPR=C2=A0rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no=C2=A0IPR=C2=A0di= sclosures in the IETF datatracker.

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant=C2=A0IPR. The response n= eeds to be sent to the PWE3 WG mailing
list. The document will not advance to the next stage until a response
has been received from each author and each 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=C2=A0IPR=C2=A0that has not= yet been disclosed in conformance with IETF
rules.

Thanks,

Andy


--001a11c15352ab680604ff407098-- From nobody Mon Jul 28 05:56:45 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A501A0193 for ; Mon, 28 Jul 2014 05:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHFig_1lLDUO for ; Mon, 28 Jul 2014 05:56:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5F41A0196 for ; Mon, 28 Jul 2014 05:56:36 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 12:56:34 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Mon, 28 Jul 2014 12:56:34 +0000 From: Alexander Vainshtein To: "Andrew G. Malis" Thread-Topic: WG Last call for draft-ietf-pwe3-congcons-02? (was: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02) Thread-Index: AQHPqmM+qrBrTO+cs0+CwbD3mqX/iZu1cdMA Date: Mon, 28 Jul 2014 12:56:34 +0000 Message-ID: References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(252514010)(189002)(199002)(24454002)(377454003)(164054003)(243025005)(2656002)(95666004)(77982001)(19625215002)(92566001)(81542001)(81342001)(87936001)(79102001)(101416001)(76576001)(85306003)(4396001)(1411001)(76176999)(16236675004)(76482001)(19609705001)(15975445006)(99396002)(21056001)(107046002)(86362001)(74502001)(15202345003)(31966008)(19617315012)(54356999)(33646002)(19580395003)(19580405001)(83322001)(74662001)(110136001)(105586002)(20776003)(50986999)(85852003)(64706001)(83072002)(19300405004)(80022001)(106356001)(66066001)(106116001)(46102001)(74316001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_db8b9dc8b225472490cf0a1959f8b650AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/nhIrgDYzR9jhrh875Is8lZkEaT8 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:56:40 -0000 --_000_db8b9dc8b225472490cf0a1959f8b650AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwNCllvdSBhcmUgYWx3YXlzIHdlbGNvbWUhDQoNClJlZ2FyZHMsDQogICAgICAgU2FzaGEN CkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KTW9iaWxlOiAwNTQtOTI2 NjMwMg0KDQpGcm9tOiBBbmRyZXcgRy4gTWFsaXMgW21haWx0bzphZ21hbGlzQGdtYWlsLmNvbV0N ClNlbnQ6IE1vbmRheSwgSnVseSAyOCwgMjAxNCAzOjU1IFBNDQpUbzogQWxleGFuZGVyIFZhaW5z aHRlaW4NCkNjOiBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogV0cgTGFzdCBjYWxsIGZvciBk cmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDI/ICh3YXM6IFtQV0UzXSBJUFIgcG9sbCBmb3IgZHJh ZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyKQ0KDQpTYXNoYSwNCg0KVGhhbmtzIGZvciB0aGlzIG5v dGUhIEZvciBzb21lIHJlYXNvbiwgdGhlIFdHIGxhc3QgY2FsbCBuZXZlciBtYWRlIGl0IG9udG8g dGhlIGxpc3QsIHNvIEkganVzdCByZXNlbnQgaXQuDQoNCkFuZCB0aGFua3MgZm9yIHlvdXIgY29t bWVudHMgb24gdGhlIGRyYWZ0LiBUaGVzZSB3aWxsIGJlIGFkZHJlc3NlZCBkdXJpbmcgcHVibGlj YXRpb24gYWxvbmcgd2l0aCBvdGhlciByZWNlaXZlZCBjb21tZW50cy4NCg0KQ2hlZXJzLA0KQW5k eQ0KDQpPbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA0OjAzIEFNLCBBbGV4YW5kZXIgVmFpbnNodGVp biA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPj4gd3JvdGU6DQpBbmR5IGFuZCBhbGwsDQpTb21laG93IEkgZGlk IG5vdCBmaW5kIGFuIGV4cGxpY2l0IFdHTEMgbWVzc2FnZSBmb3IgdGhpcyBkcmFmdCAobmVpdGhl ciBpbiBteSBhcmNoaXZlIG5vciBpbiB0aGUgV0cgb25lKS4NCg0KTmV2ZXJ0aGVsZXNzLCBJIHN1 cHBvcnQgcmVxdWVzdGluZyBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGFuIEluZm9ybWF0 aW9uYWwgUkZDLg0KDQoNCkkgaGF2ZSBhIGZldyBlZGl0b3JpYWwgY29tbWVudHM6DQoNCjEuICAg ICAgIE9uIHBhZ2UgNiB0aGUgdGV4dCBzYXlzIOKAnEludGVybmF0aW9uYWwgc3RhbmRhcmRzIHBs YWNlIHN0cmluZ2VudCBsaW1pdHMgb24gdGhlIG51bWJlciBvZiBzdWNoIGZhdWx0cyB0b2xlcmF0 ZWTigJ0uICBJIGFzc3VtZSB0aGUgcmVmZXJlbmNlIGlzIHRvIElUVS1UIFJlY29tbWVuZGF0aW9u IEcuODI2LCBidXQgaXQgd291bGQgYmUgbmljZSB0byBzdGF0ZSB0aGF0IGV4cGxpY2l0bHk7IEkg YW0gYWxzbyBub3Qgc3VyZSB3aGV0aGVyIHBsdXJhbCAo4oCcc3RhbmRhcmRz4oCdKSBpcyBqdXN0 aWZpZWQgaGVyZS4NCg0KMi4gICAgICAgQWxzbyBvbiBwYWdlIDYsIEkgc3VnZ2VzdCBpbnNlcnRp bmcgdGhlIG11bHRpcGxpY2F0aW9uIHNpZ25zIChhc3Rlcmlza3MpIGluIHRoZSBmb3JtdWxhICBp biB0aGUgc2FtZSB3YXkgaXQgaXMgZG9uZSBpbiBTZWN0aW9uIDMuMSBvZiBSRkMgNTM0ODxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzQ4PiAoZnJvbSB3aGljaCB0aGlzIGZvcm11bGEg aXMgdGFrZW4pDQoNCjMuICAgICAgIE9uIHBhZ2UgMTEsIOKAnFNlY29uZCwgdGhlIGRlcml2YXRp b24gYXNzdW1lZCB0aGF0IHRoZSBURE0gUFcgd2FzIGNvbXBldGluZyB3aXRoIGxvbmctbGl2ZWQg VERNIGZsb3dz4oCdIHByZXN1bWFibHkgc2hvdWxkIGJlIOKAnFNlY29uZCwgdGhlIGRlcml2YXRp b24gYXNzdW1lZCB0aGF0IHRoZSBURE0gUFcgd2FzIGNvbXBldGluZyB3aXRoIGxvbmctbGl2ZWQg VENQIGZsb3dz4oCdLg0KDQo0LiAgICAgICBPbiBwYWdlIDE4LCDigJxOb3RlIHRoYXQgaWYgdGhl IGVycm9yIGNvbmRpdGlvbiBBSVMgd2FzIGRldGVjdGVkIGFjY29yZGluZyB0byB0aGUgY3JpdGVy aWEgb2YgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43NzUgW0c4MjZd4oCdIHByZXN1bWFibHkgc2hv dWxkIGJlIOKAnE5vdGUgdGhhdCBpZiB0aGUgZXJyb3IgY29uZGl0aW9uIEFJUyB3YXMgZGV0ZWN0 ZWQgYWNjb3JkaW5nIHRvIHRoZSBjcml0ZXJpYSBvZiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjc3 NSBbRzc3NV3igJ0uDQoNCg0KDQpJTU8gbmVpdGhlciBvZiB0aGVzZSBjb21tZW50cyByZXF1aXJl cyBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHByaW9yIHRvIHJlcXVlc3Rpbmcg aXRzIHB1YmxpY2F0aW9uOyBob3BlZnVsbHkgdGhleSBjYW4gYmUgaGFuZGxlZCBpbiB0aGUgcHJv Y2VzcyBvZiBhcHByb3ZhbCBhbmQgcHVibGljYXRpb24uDQoNCknigJlkIGxpa2UgdG8gdGhhbmsg WWFha292LCBEYXZpZCBhbmQgQm9iIGZvciB0aGVpciBlZmZvcnQuIEkgZmluZCB2ZXJ5IHN5bWJv bGljIHRoYXQgdGhlIGNvbmdlc3Rpb24gaXNzdWUgdGhhdCBoYXMgYmVlbiByYWlzZWQgaW4gdGhl IGVhcmx5IGRheXMgb2YgUFdFMyBpcyDigJMgYXQgbG9uZyBsYXN0IOKAkyBzdWNjZXNzZnVsbHkg cmVzb2x2ZWQgd2l0aG91dCBhbnkgcmV0cm8tZml0dGluZyBvZiB3aWRlbHkgZGVwbG95ZWQgbWVj aGFuaXNtcyBkZWZpbmVkIGJ5IHRoZSBQV0UzLg0KDQpSZWdhcmRzLA0KICAgICAgIFNhc2hhDQpF bWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPg0KTW9iaWxlOiAwNTQtOTI2NjMwMg0KDQpGcm9tOiBwd2Uz IFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgQW5kcmV3IEcuIE1hbGlzDQpTZW50OiBGcmlkYXksIEp1bHkgMjUs IDIwMTQgNjoyMyBQTQ0KVG86IHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbUFdFM10gSVBSIHBvbGwgZm9yIGRyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMg0K DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMi5wZGYg aXMgbm93IGluIFBXRTMgV0cgbGFzdCBjYWxsLiBBcyBwYXJ0IG9mIHRoZSBsYXN0IGNhbGwgcHJv Y2Vzcywgd2UgbmVlZCB0byBwb2xsIHRoZSBhdXRob3JzIGFuZCBXRyBmb3IgSVBSIGluZm9ybWF0 aW9uIG9uIHRoZSBkcmFmdC4NCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byBkcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDI/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gTm90ZSB0aGF0 IHRoZXJlDQphcmUgY3VycmVudGx5IG5vIElQUiBkaXNjbG9zdXJlcyBpbiB0aGUgSUVURiBkYXRh dHJhY2tlci4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29u dHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQNCnRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KcmVsZXZhbnQgSVBSLiBUaGUgcmVzcG9u c2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgUFdFMyBXRyBtYWlsaW5nDQpsaXN0LiBUaGUgZG9j dW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNl DQpoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBlYWNoIGNvbnRyaWJ1dG9y Lg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBQV0UzIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlz dGVkIGFzIGFuIGF1dGhvcg0Kb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkg cmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUNCm9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHll dCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYNCnJ1bGVzLg0KDQpUaGFu a3MsDQpBbmR5DQoNCg== --_000_db8b9dc8b225472490cf0a1959f8b650AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkFoYXJvbmk7DQoJcGFub3NlLTE6MiAxIDggMyAyIDEg NCAzIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6IzFGNDk3RDsNCgl0ZXh0 LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwt YWxpZ246YmFzZWxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WW91IGFyZSBhbHdheXMgd2VsY29tZSE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTYXNoYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVtYWls OiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Nb2JpbGU6IDA1NC05MjY2MzAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAyOCwgMjAxNCAzOjU1IFBNPGJyPg0K PGI+VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbjxicj4NCjxiPkNjOjwvYj4gcHdlM0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogV0cgTGFzdCBjYWxsIGZvciBkcmFmdC1pZXRm LXB3ZTMtY29uZ2NvbnMtMDI/ICh3YXM6IFtQV0UzXSBJUFIgcG9sbCBmb3IgZHJhZnQtaWV0Zi1w d2UzLWNvbmdjb25zLTAyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TYXNoYSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhpcyBub3RlISBGb3Igc29tZSByZWFzb24sIHRoZSBXRyBs YXN0IGNhbGwgbmV2ZXIgbWFkZSBpdCBvbnRvIHRoZSBsaXN0LCBzbyBJIGp1c3QgcmVzZW50IGl0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmQgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIG9uIHRoZSBkcmFmdC4gVGhlc2Ugd2lsbCBiZSBh ZGRyZXNzZWQgZHVyaW5nIHB1YmxpY2F0aW9uIGFsb25nIHdpdGggb3RoZXIgcmVjZWl2ZWQgY29t bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAyOCwgMjAx NCBhdCA0OjAzIEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keSBhbmQgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNvbWVob3cgSSBkaWQgbm90IGZpbmQgYW4gZXhwbGljaXQgV0dMQyBtZXNzYWdl IGZvciB0aGlzIGRyYWZ0IChuZWl0aGVyIGluIG15IGFyY2hpdmUgbm9yIGluIHRoZQ0KIFdHIG9u ZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TmV2ZXJ0aGVsZXNzLCBJIHN1cHBvcnQgcmVxdWVzdGluZyBwdWJs aWNhdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgYSBmZXcgZWRp dG9yaWFsIGNvbW1lbnRzOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uIHBhZ2UgNiB0aGUgdGV4dCBzYXlzIOKAnDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SW50ZXJuYXRpb25hbCBzdGFuZGFy ZHMgcGxhY2Ugc3RyaW5nZW50IGxpbWl0cyBvbiB0aGUgbnVtYmVyIG9mIHN1Y2ggZmF1bHRzIHRv bGVyYXRlZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 4oCdLg0KICZuYnNwO0kgYXNzdW1lIHRoZSByZWZlcmVuY2UgaXMgdG8gSVRVLVQgUmVjb21tZW5k YXRpb24gRy44MjYsIGJ1dCBpdCB3b3VsZCBiZSBuaWNlIHRvIHN0YXRlIHRoYXQgZXhwbGljaXRs eTsgSSBhbSBhbHNvIG5vdCBzdXJlIHdoZXRoZXIgcGx1cmFsICjigJw8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7YmFja2dyb3VuZDp5ZWxsb3ciPnN0YW5kYXJkczwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdKQ0KIGlzIGp1c3Rp ZmllZCBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbHNvIG9uIHBhZ2UgNiwgSSBzdWdnZXN0IGluc2VydGluZyB0 aGUgbXVsdGlwbGljYXRpb24gc2lnbnMgKGFzdGVyaXNrcykgaW4gdGhlIGZvcm11bGEgJm5ic3A7 aW4gdGhlIHNhbWUgd2F5IGl0IGlzIGRvbmUgaW4gU2VjdGlvbiAzLjEgb2YNCjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzNDgiIHRhcmdldD0iX2JsYW5rIj5SRkMgNTM0 ODwvYT4gKGZyb20gd2hpY2ggdGhpcyBmb3JtdWxhIGlzIHRha2VuKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiBwYWdl IDExLCDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNlY29uZCwgdGhl IGRlcml2YXRpb24gYXNzdW1lZCB0aGF0IHRoZSBURE0gUFcgd2FzIGNvbXBldGluZyB3aXRoIGxv bmctbGl2ZWQNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+VERNPC9zcGFuPiBmbG93 czwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdIHBy ZXN1bWFibHkgc2hvdWxkIGJlIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+U2Vjb25kLCB0aGUgZGVyaXZhdGlvbiBhc3N1bWVkIHRoYXQgdGhlIFRETSBQVyB3YXMgY29t cGV0aW5nDQogd2l0aCBsb25nLWxpdmVkIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+ VENQPC9zcGFuPiBmbG93czwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+4oCdLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+NC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gcGFnZSAxOCwg4oCcPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Ob3RlIHRoYXQgaWYgdGhlIGVycm9yIGNvbmRpdGlv biBBSVMgd2FzIGRldGVjdGVkIGFjY29yZGluZyB0byB0aGUgY3JpdGVyaWEgb2YgSVRVLVQgUmVj b21tZW5kYXRpb24gRy43NzUNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+W0c4MjZd PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 4oCdIHByZXN1bWFibHkgc2hvdWxkIGJlIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Tm90ZSB0aGF0IGlmIHRoZSBlcnJvciBjb25kaXRpb24gQUlTIHdhcyBkZXRlY3Rl ZCBhY2NvcmRpbmcgdG8NCiB0aGUgY3JpdGVyaWEgb2YgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43 NzUgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5bRzc3NV08L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JTU8gbmVpdGhlciBvZiB0aGVzZSBjb21tZW50cyByZXF1aXJl cyBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHByaW9yIHRvIHJlcXVlc3Rpbmcg aXRzIHB1YmxpY2F0aW9uOyBob3BlZnVsbHkgdGhleSBjYW4gYmUgaGFuZGxlZCBpbiB0aGUgcHJv Y2VzcyBvZiBhcHByb3ZhbCBhbmQgcHVibGljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQgbGlr ZSB0byB0aGFuayBZYWFrb3YsIERhdmlkIGFuZCBCb2IgZm9yIHRoZWlyIGVmZm9ydC4gSSBmaW5k IHZlcnkgc3ltYm9saWMgdGhhdCB0aGUgY29uZ2VzdGlvbg0KIGlzc3VlIHRoYXQgaGFzIGJlZW4g cmFpc2VkIGluIHRoZSBlYXJseSBkYXlzIG9mIFBXRTMgaXMg4oCTIGF0IGxvbmcgbGFzdCDigJMg c3VjY2Vzc2Z1bGx5IHJlc29sdmVkIHdpdGhvdXQgYW55IHJldHJvLWZpdHRpbmcgb2Ygd2lkZWx5 IGRlcGxveWVkIG1lY2hhbmlzbXMgZGVmaW5lZCBieSB0aGUgUFdFMy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RW1haWw6DQo8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Nb2JpbGU6IDA1NC05MjY2MzAyPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBwd2UzIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB3 ZTMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJldyBHLiBN YWxpczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgNjoyMyBQTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5wd2UzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUFdFM10gSVBSIHBvbGwg Zm9yIGRyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyLnBkZiIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25z LTAyLnBkZjwvYT4NCiBpcyBub3cgaW4gUFdFMyBXRyBsYXN0IGNhbGwuIEFzIHBhcnQgb2YgdGhl IGxhc3QgY2FsbCBwcm9jZXNzLCB3ZSBuZWVkIHRvIHBvbGwgdGhlIGF1dGhvcnMgYW5kIFdHIGZv ciBJUFIgaW5mb3JtYXRpb24gb24gdGhlIGRyYWZ0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48YnI+DQo8YnI+DQpBcmUgeW91IGF3YXJlIG9mIGFueSZuYnNwOzxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOiNGRkZGQ0MiPklQUjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO3Ro YXQgYXBwbGllcyB0byZuYnNwO2RyYWZ0LWlldGYtcHdlMy1jb25nY29ucy0wMj88L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KSWYgc28sIGhhcyB0aGlzJm5ic3A7 PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPiZuYnNwO2JlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGJm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPiZuYnNwO3J1bGVzPGJyPg0KKHNlZSBSRkNzIDM5NzksIDQ4 NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/IE5vdGUgdGhhdCB0aGVyZTxicj4N CmFyZSBjdXJyZW50bHkgbm8mbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5J UFI8L3NwYW4+Jm5ic3A7ZGlzY2xvc3VyZXMgaW4gdGhlIElFVEYgZGF0YXRyYWNrZXIuPGJyPg0K PGJyPg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0 b3IgcGxlYXNlIHJlc3BvbmQ8YnI+DQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnk8YnI+DQpyZWxldmFudCZuYnNwOzxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kOiNGRkZGQ0MiPklQUjwvc3Bhbj4uIFRoZSByZXNwb25zZSBuZWVkcyB0 byBiZSBzZW50IHRvIHRoZSBQV0UzIFdHIG1haWxpbmc8YnI+DQpsaXN0LiBUaGUgZG9jdW1lbnQg d2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlPGJyPg0K aGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFjaCBjb250cmlidXRvci48 YnI+DQo8YnI+DQpJZiB5b3UgYXJlIG9uIHRoZSBQV0UzIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBu b3QgbGlzdGVkIGFzIGFuIGF1dGhvcjxicj4NCm9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBl eHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlPGJyPg0Kb2YgYW55Jm5ic3A7 PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPiZuYnNwO3RoYXQgaGFz IG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGPGJyPg0KcnVs ZXMuPGJyPg0KPGJyPg0KVGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFuZHk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_db8b9dc8b225472490cf0a1959f8b650AM3PR03MB612eurprd03pro_-- From nobody Mon Jul 28 05:57:56 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A62C1A0193 for ; Mon, 28 Jul 2014 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihAJIVcidUMW for ; Mon, 28 Jul 2014 05:57:52 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF001A0185 for ; Mon, 28 Jul 2014 05:57:51 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so8415682qgd.37 for ; Mon, 28 Jul 2014 05:57:51 -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=pI9AHNi9M3/CI3yOrLTRaMeJZucF2P2rjpyGwJCo0Gs=; b=Thv+/hq0ieoy3nOJjM1y3134yNFnUA46Nt3FT/zH6bG/hetQm7T5GVx/rbY4AZhZBU UMsZvvT2jD0EvOPoHemC5iSkRyMaO9VRnZpTVDbgAOCWeP02mVzqaCg+YcWQcFqxLG7v lJ9gZMT6i8C+XJRNhvGHDMpXJ4zbdQMujHBISZlnRQANFgPbyfC9w92lg5FRcIO1cYNe EJUtd5tcEHth7VqUHEjkb6MSI1r7dx5UkY1P3rNguDXn6MjeQ+Pb7HI9JY7xet+UOajz s2oTmdwRY+MK6LNSIuOTb9k1bPrIeAo/6k2WDAc6mW3uCzFSkA0Ah0z/ELRtVA2jnSM1 prwg== X-Received: by 10.224.3.201 with SMTP id 9mr57119741qao.73.1406552271176; Mon, 28 Jul 2014 05:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Mon, 28 Jul 2014 05:57:30 -0700 (PDT) In-Reply-To: <53D646C6.5050406@cisco.com> References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> <53D630EE.4000008@cisco.com> <1d874f1da4534d98af29d6c0baaaadd8@AM3PR03MB612.eurprd03.prod.outlook.com> <53D646C6.5050406@cisco.com> From: "Andrew G. Malis" Date: Mon, 28 Jul 2014 08:57:30 -0400 Message-ID: To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a11c24cfc7b668f04ff4078d3 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/ZRcEsxgngMwfahEcrDU2Tux_0SI Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:57:55 -0000 --001a11c24cfc7b668f04ff4078d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stewart, Thanks for your quick comments as well. Cheers, Andy On Mon, Jul 28, 2014 at 8:49 AM, Stewart Bryant wrote: > Those refs would be handy. I think that it just takes a couple > of sentences and will anticipate the various directorate and > IESG review comments. > > S > > > > > On 28/07/2014 13:11, Alexander Vainshtein wrote: > > Stewart and all, > > I fully agree with you that the term =E2=80=9Ccircuit breaker=E2=80=9D ha= s not been used > in the PWE3 discussions until now. > > However, I think that it has been implicitly defined in Section 6.5. of > RFC 3985 , and its usage > has been defined also in Section 8 of RFC 4553 > . > > Not sure how important this is; but if the authors decide to expand the > =E2=80=9Ccircuit breaker=E2=80=9D notion, these references could be handy= . > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > > *From:* Stewart Bryant [mailto:stbryant@cisco.com ] > *Sent:* Monday, July 28, 2014 2:16 PM > *To:* Alexander Vainshtein; Andrew G. Malis > *Cc:* pwe3@ietf.org > *Subject:* Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: > IPR poll for draft-ietf-pwe3-congcons-02) > > > > This is a well written draft, that makes a useful > contribution to a long standing problem and > I fully support its publication as an RFC. > > I have a few comments that I would request > that the authors consider and a couple > of nits. I also agree with the points that > Sasha makes, and am also pleased that no > changes are required to this widely deployed > packet transport mechanism. > > Firstly I think that you should say a little bit > more about the circuit breaker than you currently > do, in particular the interaction with the control plane > and the restart procedure. > > Secondly, whilst Ethernet PWs are a good example > and by far the most common elastic case they are not > the only elastic PWs type. You need a line in the text > pointing out the equivalence and possibly naming > the current types that behave in the same way as > IP. > > SB> Where does ATM fit into the taxonomy? > > SB> Also what about FC Port Mode? > > > nits: > > such a PW is inable to respond to congestion in a > TCP-like manner; > > > SB> That should be unable > > the packet loss rate PLR > > SB> PLR should be (PLR) > > The circuit breaker needs a ref on first > use, and maybe a little description since > it is a new concept in PWE3 > > - Stewart > > > > On 28/07/2014 09:03, Alexander Vainshtein wrote: > > Andy and all, > > Somehow I did not find an explicit WGLC message for this draft (neither i= n > my archive nor in the WG one). > > > > Nevertheless, I support requesting publication of this draft as an > Informational RFC. > > > > I have a few editorial comments: > > 1. On page 6 the text says =E2=80=9CInternational standards place stringe= nt > limits on the number of such faults tolerated=E2=80=9D. I assume the ref= erence > is to ITU-T Recommendation G.826, but it would be nice to state that > explicitly; I am also not sure whether plural (=E2=80=9Cstandards=E2=80= =9D) is justified > here. > > 2. Also on page 6, I suggest inserting the multiplication signs > (asterisks) in the formula in the same way it is done in Section 3.1 of = RFC > 5348 (from which this formula is > taken) > > 3. On page 11, =E2=80=9CSecond, the derivation assumed that the TDM PW wa= s > competing with long-lived TDM flows=E2=80=9D presumably should be =E2=80= =9CSecond, the > derivation assumed that the TDM PW was competing with long-lived TCP flow= s=E2=80=9D. > > > 4. On page 18, =E2=80=9CNote that if the error condition AIS was detected > according to the criteria of ITU-T Recommendation G.775 [G826]=E2=80=9D > presumably should be =E2=80=9CNote that if the error condition AIS was de= tected > according to the criteria of ITU-T Recommendation G.775 [G775]=E2=80=9D. > > > > IMO neither of these comments requires posting a new version of the draft > prior to requesting its publication; hopefully they can be handled in the > process of approval and publication. > > > > I=E2=80=99d like to thank Yaakov, David and Bob for their effort. I find = very > symbolic that the congestion issue that has been raised in the early days > of PWE3 is =E2=80=93 at long last =E2=80=93 successfully resolved without= any retro-fitting > of widely deployed mechanisms defined by the PWE3. > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > > *From:* pwe3 [mailto:pwe3-bounces@ietf.org ] *On > Behalf Of *Andrew G. Malis > *Sent:* Friday, July 25, 2014 6:23 PM > *To:* pwe3@ietf.org > *Subject:* [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 > > > > http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG > last call. As part of the last call process, we need to poll the authors > and WG for IPR information on the draft. > > Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there > are currently no IPR disclosures in the IETF datatracker. > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. The response needs to be sent to the PWE3 WG mailing > list. The document will not advance to the next stage until a response > has been received from each author and each contributor. > > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > Thanks, > > Andy > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > -- > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --001a11c24cfc7b668f04ff4078d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

Thanks for your quick comments= as well.

Cheers,
Andy


On Mon, Jul 28, 201= 4 at 8:49 AM, Stewart Bryant <stbryant@cisco.com> wrote:
=20 =20 =20
Those refs would be handy. I think that it just takes a couple
of sentences and will anticipate the various directorate and
IESG review comments.<= br>
S




On 28/07/2014 13:11, Alexander Vainshtein wrote:
=20 =20 =20

Stewart and all,

I fully agree with you that the term =E2=80=9Ccircuit breaker=E2= =80=9D has not been used in the PWE3 discussions until now.

However, I think that it has been implicitly defined in Section 6.5. of RFC 3985, and its usage has been defined also in Section 8 of RFC 4553.

Not sure how important this is; but if the authors decide to expand the =E2=80=9Ccircuit breaker=E2=80=9D notion, these refe= rences could be handy.

=C2=A0<= /u>

Regards,=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

=C2=A0<= /u>

From:<= /span> Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, July 28, 2014 2:16 PM
To: Alexander Vainshtein; Andrew G. Malis
Cc: pwe3@ietf.org
Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02)

=C2=A0

This is a well written draft, that makes a useful
contribution to a long standing problem and
I fully support its publication as an RFC.

I have a few comments that I would request
that the authors consider and a couple
of nits. I also agree with the points that
Sasha makes, and am also pleased that no
changes are required to this widely deployed
packet transport mechanism.

Firstly I think that you should say a little bit
more about the circuit breaker than you currently
do, in particular the interaction with the control plane
and the restart procedure.

Secondly, whilst Ethernet PWs are a good example
and by far the most common elastic case they are not
the only elastic PWs type. You need a line in the text
pointing out the equivalence and possibly naming
the current types that behave in the same way as
IP.

SB> Where does ATM fit into the taxonomy?

SB> Also what about FC Port Mode?


nits:

such a PW is inable to respond t= o congestion in a
TCP-like manner;<= u>


SB> That should be unable

t= he packet loss rate PLR

SB> PLR should be (PLR)

The circuit breaker needs a ref on first
use, and maybe a little description since
it is a new concept in PWE3

- Stewart



On 28/07/2014 09:03, Alexander Vainshtein wrote:

Andy and all,

Somehow I did not find an explicit WGLC message for this draft (neither in my archive nor in the WG one).=

=C2=A0=

Nevertheless, I support requesting publication of this draft as an Informational RFC.

=C2=A0=

I have a few editorial comments:

1.On page 6 the text says =E2=80=9CInternational standards place stringent limits on the number of such faults tolerated=E2=80=9D. =C2=A0I assume the reference is to ITU-T Recommendation G.826, but it would be nice to state that explicitly; I am also not sure whether plural (=E2=80=9Cstandards=E2=80=9D) is justified here.

2.Also on page 6, I suggest inserting the multiplication signs (asterisks) in the formula =C2=A0in the same way it is done in Section 3.1 of RFC 5348 (from which this formula is taken)

3.On page 11, =E2=80=9CS= econd, the derivation assumed that the TDM PW was competing with long-lived TDM flows=E2=80=9D presumably should be =E2=80=9CSecond, the derivation assumed that the TDM PW was competing with long-lived TCP flows=E2=80= =9D. =C2=A0

4.On page 18, =E2=80=9CN= ote that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]=E2=80=9D presumably should be =E2=80=9CNote that if the error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775]=E2=80=9D.

=C2=A0

IMO neither of these comments requires posting a new version of the draft prior to requesting its publication; hopefully they can be handled in the process of approval and publication.

=C2=A0=

I=E2=80=99d like to thank Yaakov, David and Bob for their effort. I find very symbolic that the congestion issue that has been raised in the early days of PWE3 is =E2=80=93 at long = last =E2=80=93 successfully resolved without any retro-fitting o= f widely deployed mechanisms defined by the PWE3.

=C2=A0=

Regards,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

=C2=A0=

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02

=C2=A0

http://www.ietf.org/id/draft-iet= f-pwe3-congcons-02.pdf is now in PWE3 WG last call. As part of the last call process, we need to poll the authors and WG for IPR information on the draft.

Are you aware of any=C2=A0IPR=C2=A0that applies to=C2=A0draft-ietf-pwe3-congcons-02?

If so, has this=C2=A0IPR=C2=A0been disclosed in compliance with IETF=C2=A0IPR=C2=A0rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no=C2=A0IPR=C2=A0disclosures in the IETF datatracker.

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant=C2=A0IPR. The response needs to be sent to the PWE3 WG mailing list. The document will not advance to the next stage until a response
has been received from each author and each 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=C2=A0IPR=C2=A0that has not yet been disclosed in conformance with IETF
rules.

Thanks,

Andy




_______________________________________________<=
/u>
pwe3 mailing list
pwe3@ie=
tf.org
https://www.ietf.org/mailman/listinfo/pwe3=





-- 
For corporate legal information go to:
=C2=A0
http://www.cisco.com/web/about/doing_b=
usiness/legal/cri/index.html
=C2=A0


--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c=
ri/index.html

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


--001a11c24cfc7b668f04ff4078d3-- From nobody Mon Jul 28 07:57:23 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD771B2863 for ; Mon, 28 Jul 2014 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B658QIqGbTL0 for ; Mon, 28 Jul 2014 07:57:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A1D1B2864 for ; Mon, 28 Jul 2014 07:57:12 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 14:57:10 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0995.014; Mon, 28 Jul 2014 14:57:10 +0000 From: John E Drake To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqBiOFwGKWlhnR0Cl4HRHJXR0fZu1mCzw Date: Mon, 28 Jul 2014 14:57:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(189002)(199002)(51704005)(99396002)(74316001)(86362001)(106356001)(95666004)(83072002)(20776003)(85852003)(105586002)(99286002)(54356999)(101416001)(107046002)(19580405001)(107886001)(83322001)(64706001)(33646002)(50986999)(106116001)(19580395003)(85306003)(76176999)(87936001)(76482001)(81542001)(81342001)(92566001)(79102001)(76576001)(77982001)(80022001)(74662001)(31966008)(21056001)(4396001)(74502001)(46102001)(15202345003)(66066001)(2656002)(15975445006)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/O_5p3dblR21PUqNeqEdS3f39Yqc Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:57:22 -0000 Support Yours Irrespectively, John > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew > (Matthew) > Sent: Friday, July 25, 2014 7:56 AM > To: pwe3@ietf.org > Subject: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection= -01 >=20 > This email begins a second two week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . >=20 > Please review the draft and post any comments to the PWE3 list. >=20 > If you have read the draft, even if you don=B9t have any comments, but wo= uld like > to see the draft progressed, please can you indicate this to the list. >=20 > This working group last call will end on Friday August 8th, 2014. >=20 >=20 > Best regards >=20 >=20 > Matthew and Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Jul 29 00:01:26 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D541ABD17 for ; Tue, 29 Jul 2014 00:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl04SydCaa2N for ; Tue, 29 Jul 2014 00:01:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604B61ABB35 for ; Tue, 29 Jul 2014 00:01:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHR73333; Tue, 29 Jul 2014 07:01:20 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 08:01:19 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.76]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 15:01:12 +0800 From: Jiangyuanlong To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqBiOFwGKWlhnR0Cl4HRHJXR0fZu2pD4w Date: Tue, 29 Jul 2014 07:01:11 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A781B66@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Ke7CvwZyCRP0rrQZpcy_PNWOxpM Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 07:01:25 -0000 I have reviewed it and support its publication as a co-author. Regards, Yuanlong -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matt= hew) Sent: Friday, July 25, 2014 10:56 PM To: pwe3@ietf.org Subject: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-0= 1 This email begins a second two week working group last call for http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . Please review the draft and post any comments to the PWE3 list. If you have read the draft, even if you don=B9t have any comments, but woul= d like to see the draft progressed, please can you indicate this to the list. This working group last call will end on Friday August 8th, 2014. Best regards Matthew and Andy _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Jul 29 01:40:48 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4D81A00FA for ; Tue, 29 Jul 2014 01:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVoyyDgvWOcI for ; Tue, 29 Jul 2014 01:40:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B271A0086 for ; Tue, 29 Jul 2014 01:40:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKQ44035; Tue, 29 Jul 2014 08:40:42 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 09:40:41 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 16:40:34 +0800 From: Mach Chen To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqBiOFwGKWlhnR0Cl4HRHJXR0fZu2vTJw Date: Tue, 29 Jul 2014 08:40:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/g52x-c-9_70DTzub8iANrKPruUg Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 08:40:46 -0000 I have read the draft and think it's ready for publication. BTW, I run the idnits tool and found the following nits, they need to be so= lved before the publication. Miscellaneous warnings: -------------------------------------------------------------------------= --- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, = it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. =3D=3D The expression 'MAY NOT', while looking like RFC 2119 requirements= text, is not defined in RFC 2119, and should not be used. Consider using 'M= UST NOT' instead (if that is what you mean). =20 Found 'MAY NOT' in this paragraph: =20 In this model, the protector is a dedicated P router or PE router that serves the role. In egress AC protection and egress PE node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In S-PE node protection, the protector M= AY or MAY NOT be a backup S-PE on the backup PW. =3D=3D The expression 'MAY NOT', while looking like RFC 2119 requirements= text, is not defined in RFC 2119, and should not be used. Consider using 'M= UST NOT' instead (if that is what you mean). =20 Found 'MAY NOT' in this paragraph: =20 At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rel= y on an end-to-end OAM mechanism between the CEs. The AC used for the C= E to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. -- The document date (July 24, 2014) is 5 days in the past. Is this 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: 'RFC3985' is defined on line 1153, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5659' is defined on line 1156, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC4447' is defined on line 1160, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5331' is defined on line 1164, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5036' is defined on line 1168, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5561' is defined on line 1171, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC2205' is defined on line 1174, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3209' is defined on line 1178, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC4090' is defined on line 1182, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5286' is defined on line 1186, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5714' is defined on line 1189, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3471' is defined on line 1192, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3472' is defined on line 1196, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3031' is defined on line 1201, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC2328' is defined on line 1204, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5880' is defined on line 1206, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC6389' is defined on line 1209, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5920' is defined on line 1219, but no explic= it reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 5659 ** Downref: Normative reference to an Informational RFC: RFC 5714 Summary: 3 errors (**), 0 flaws (~~), 20 warnings (=3D=3D), 2 comments= (--). Run idnits with the --verbose option for more detailed information abo= ut the items above. Best regards, Mach > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew > (Matthew) > Sent: Friday, July 25, 2014 10:56 PM > To: pwe3@ietf.org > Subject: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection= -01 >=20 > This email begins a second two week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . >=20 > Please review the draft and post any comments to the PWE3 list. >=20 > If you have read the draft, even if you don=B9t have any comments, but wo= uld like > to see the draft progressed, please can you indicate this to the list. >=20 > This working group last call will end on Friday August 8th, 2014. >=20 >=20 > Best regards >=20 >=20 > Matthew and Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Jul 29 05:35:24 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA401B2848 for ; Tue, 29 Jul 2014 05:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4weDSD2R3aqC for ; Tue, 29 Jul 2014 05:35:21 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1CE1B283E for ; Tue, 29 Jul 2014 05:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=814; q=dns/txt; s=iport; t=1406637321; x=1407846921; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=VxUzO7aTzwmxVqOQgtVnghEcuDg2ppfHiqmKx3GK6xk=; b=evv6GOQBmJixWfMJjEhOFq+b+5ZZg9ZYZtGdzNfQHx6LU2AMajvdrdaT i1xEp+F95kv6hS+shLzztwMS+Z8yQDUbvcYnmrguExsUa7NXLGSkglTkI c25USnARIbDGEywoprSdyKcUWRgdCG9J8/pZr2lpHsBhvJAiAanuuCge6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMEAEyU11OtJssW/2dsb2JhbABZg2BXy2QKh0sBgSR3hAQBAQQBAQEaGzYKEQsSBgkWDwkDAgECARUiDgYBDAYCAQGIPg2uLpBSF45qEQFXhEoBBJtMgVKSfINKa4EM X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="125692762" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 29 Jul 2014 12:35:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6TCZGv1022352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 12:35:17 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6TCZGrE027481; Tue, 29 Jul 2014 13:35:16 +0100 (BST) Message-ID: <53D79504.4050904@cisco.com> Date: Tue, 29 Jul 2014 13:35:16 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yakov Rekhter , pwe3@ietf.org References: <201407251524.s6PFOPn92012@magenta.juniper.net> In-Reply-To: <201407251524.s6PFOPn92012@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/VzKQqf5Sn9RRLbDE5LeHniVMQy0 Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Jul 2014 12:35:23 -0000 On 25/07/2014 16:24, Yakov Rekhter wrote: > Hi, > >> This email begins a second two week working group last call for >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . >> >> Please review the draft and post any comments to the PWE3 list. >> >> If you have read the draft, even if you don't have any comments, but would >> like to see the draft progressed, please can you indicate this to the list. >> >> This working group last call will end on Friday August 8th, 2014. > I would like to see the draft progressed. > > Yakov. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > Yakov Doesn't this draft implicitly make a number of extensions to the MPLS architecture? Stewart From nobody Tue Jul 29 06:43:08 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827701B2873 for ; Tue, 29 Jul 2014 06:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTvprGuRub_n for ; Tue, 29 Jul 2014 06:43:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA3A1AC0D1 for ; Tue, 29 Jul 2014 06:43:05 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 13:42:56 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 13:42:56 +0000 From: Yimin Shen To: Mach Chen , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqwjPZEMLsoL0+kmAkYMs8kzvCJu3D4+Q Date: Tue, 29 Jul 2014 13:42:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(199002)(377454003)(51704005)(164054003)(21056001)(81342001)(66066001)(4396001)(106116001)(95666004)(105586002)(77982001)(99286002)(80022001)(85306003)(20776003)(64706001)(74502001)(74316001)(79102001)(15975445006)(106356001)(81542001)(33646002)(15202345003)(76576001)(87936001)(107046002)(107886001)(46102001)(54356999)(50986999)(76176999)(2656002)(74662001)(101416001)(83072002)(19580405001)(86362001)(99396002)(19580395003)(83322001)(85852003)(76482001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB728; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/b1hUdkWFOeD43XC-hiFBQb3ddEE Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:43:07 -0000 Thanks Mach! We will fix them. Thanks, /Yimin -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Mach Chen Sent: Tuesday, July 29, 2014 4:41 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protecti= on-01 I have read the draft and think it's ready for publication. BTW, I run the idnits tool and found the following nits, they need to be so= lved before the publication. Miscellaneous warnings: -------------------------------------------------------------------------= --- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, = it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. =3D=3D The expression 'MAY NOT', while looking like RFC 2119 requirements= text, is not defined in RFC 2119, and should not be used. Consider using 'M= UST NOT' instead (if that is what you mean). =20 Found 'MAY NOT' in this paragraph: =20 In this model, the protector is a dedicated P router or PE router that serves the role. In egress AC protection and egress PE node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In S-PE node protection, the protector M= AY or MAY NOT be a backup S-PE on the backup PW. =3D=3D The expression 'MAY NOT', while looking like RFC 2119 requirements= text, is not defined in RFC 2119, and should not be used. Consider using 'M= UST NOT' instead (if that is what you mean). =20 Found 'MAY NOT' in this paragraph: =20 At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rel= y on an end-to-end OAM mechanism between the CEs. The AC used for the C= E to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. -- The document date (July 24, 2014) is 5 days in the past. Is this 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: 'RFC3985' is defined on line 1153, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5659' is defined on line 1156, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC4447' is defined on line 1160, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5331' is defined on line 1164, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5036' is defined on line 1168, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5561' is defined on line 1171, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC2205' is defined on line 1174, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3209' is defined on line 1178, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC4090' is defined on line 1182, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5286' is defined on line 1186, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5714' is defined on line 1189, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3471' is defined on line 1192, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3472' is defined on line 1196, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3031' is defined on line 1201, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC2328' is defined on line 1204, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5880' is defined on line 1206, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC6389' is defined on line 1209, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC5920' is defined on line 1219, but no explic= it reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 5659 ** Downref: Normative reference to an Informational RFC: RFC 5714 Summary: 3 errors (**), 0 flaws (~~), 20 warnings (=3D=3D), 2 comments= (--). Run idnits with the --verbose option for more detailed information abo= ut the items above. Best regards, Mach > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew > (Matthew) > Sent: Friday, July 25, 2014 10:56 PM > To: pwe3@ietf.org > Subject: [PWE3] WG Last Call for=20 > draft-ietf-pwe3-endpoint-fast-protection-01 >=20 > This email begins a second two week working group last call for > http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01 . >=20 > Please review the draft and post any comments to the PWE3 list. >=20 > If you have read the draft, even if you don=B9t have any comments, but=20 > would like to see the draft progressed, please can you indicate this to = the list. >=20 > This working group last call will end on Friday August 8th, 2014. >=20 >=20 > Best regards >=20 >=20 > Matthew and Andy >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Jul 29 06:54:35 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45C81B28BC for ; Tue, 29 Jul 2014 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrpMlZQ2fB7U for ; Tue, 29 Jul 2014 06:54:29 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E8E1B2884 for ; Tue, 29 Jul 2014 06:54:28 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES256-SHA encrypted SMTP; 29 Jul 2014 16:54:22 +0300 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 29 Jul 2014 16:54:21 +0300 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Tue, 29 Jul 2014 16:54:21 +0300 From: Yaakov Stein To: Alexander Vainshtein Thread-Topic: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) Thread-Index: Ac+qOnLyjQPVLiOSTqGFx2WWHFeNEgA+e5Kg Date: Tue, 29 Jul 2014 13:54:20 +0000 Message-ID: References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: multipart/alternative; boundary="_000_b081bc1b54c842f2b302b065b85e4a6aexrad6adradcoil_" MIME-Version: 1.0 Spam-Score: -2.00 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/h-B_Zhv6Kz_gZSTkw_oarZn6icY Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 13:54:33 -0000 --_000_b081bc1b54c842f2b302b065b85e4a6aexrad6adradcoil_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FzaGEsDQoNClRoYW5rcyBmb3Igc3BvdHRpbmcgdGhlc2UgcHJvYmxlbXMgaW4gdGhlIGRyYWZ0 LCBhbGwgb2Ygd2hpY2ggYXJlIGdvb2QgY2F0Y2hlcy4NCg0KSSB3aWxsIGZpeCBpbiBhIGZpbmFs IHJlc3BpbiBhZnRlciB0aGUgV0cgTEMuDQoNClkoSilTDQoNCkZyb206IHB3ZTMgW21haWx0bzpw d2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgVmFpbnNodGVpbg0K U2VudDogMjggSnVseSwgMjAxNCAwMzowNA0KVG86IEFuZHJldyBHLiBNYWxpcw0KQ2M6IHB3ZTNA aWV0Zi5vcmcNClN1YmplY3Q6IFtQV0UzXSBXRyBMYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtcHdl My1jb25nY29ucy0wMj8gKHdhczogSVBSIHBvbGwgZm9yIGRyYWZ0LWlldGYtcHdlMy1jb25nY29u cy0wMikNCg0KQW5keSBhbmQgYWxsLA0KU29tZWhvdyBJIGRpZCBub3QgZmluZCBhbiBleHBsaWNp dCBXR0xDIG1lc3NhZ2UgZm9yIHRoaXMgZHJhZnQgKG5laXRoZXIgaW4gbXkgYXJjaGl2ZSBub3Ig aW4gdGhlIFdHIG9uZSkuDQoNCk5ldmVydGhlbGVzcywgSSBzdXBwb3J0IHJlcXVlc3RpbmcgcHVi bGljYXRpb24gb2YgdGhpcyBkcmFmdCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCg0KDQpJIGhh dmUgYSBmZXcgZWRpdG9yaWFsIGNvbW1lbnRzOg0KDQoxLiAgICAgICBPbiBwYWdlIDYgdGhlIHRl eHQgc2F5cyDigJxJbnRlcm5hdGlvbmFsIHN0YW5kYXJkcyBwbGFjZSBzdHJpbmdlbnQgbGltaXRz IG9uIHRoZSBudW1iZXIgb2Ygc3VjaCBmYXVsdHMgdG9sZXJhdGVk4oCdLiAgSSBhc3N1bWUgdGhl IHJlZmVyZW5jZSBpcyB0byBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjgyNiwgYnV0IGl0IHdvdWxk IGJlIG5pY2UgdG8gc3RhdGUgdGhhdCBleHBsaWNpdGx5OyBJIGFtIGFsc28gbm90IHN1cmUgd2hl dGhlciBwbHVyYWwgKOKAnHN0YW5kYXJkc+KAnSkgaXMganVzdGlmaWVkIGhlcmUuDQoNCjIuICAg ICAgIEFsc28gb24gcGFnZSA2LCBJIHN1Z2dlc3QgaW5zZXJ0aW5nIHRoZSBtdWx0aXBsaWNhdGlv biBzaWducyAoYXN0ZXJpc2tzKSBpbiB0aGUgZm9ybXVsYSAgaW4gdGhlIHNhbWUgd2F5IGl0IGlz IGRvbmUgaW4gU2VjdGlvbiAzLjEgb2YgUkZDIDUzNDg8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTM0OD4gKGZyb20gd2hpY2ggdGhpcyBmb3JtdWxhIGlzIHRha2VuKQ0KDQozLiAgICAg ICBPbiBwYWdlIDExLCDigJxTZWNvbmQsIHRoZSBkZXJpdmF0aW9uIGFzc3VtZWQgdGhhdCB0aGUg VERNIFBXIHdhcyBjb21wZXRpbmcgd2l0aCBsb25nLWxpdmVkIFRETSBmbG93c+KAnSBwcmVzdW1h Ymx5IHNob3VsZCBiZSDigJxTZWNvbmQsIHRoZSBkZXJpdmF0aW9uIGFzc3VtZWQgdGhhdCB0aGUg VERNIFBXIHdhcyBjb21wZXRpbmcgd2l0aCBsb25nLWxpdmVkIFRDUCBmbG93c+KAnS4NCg0KNC4g ICAgICAgT24gcGFnZSAxOCwg4oCcTm90ZSB0aGF0IGlmIHRoZSBlcnJvciBjb25kaXRpb24gQUlT IHdhcyBkZXRlY3RlZCBhY2NvcmRpbmcgdG8gdGhlIGNyaXRlcmlhIG9mIElUVS1UIFJlY29tbWVu ZGF0aW9uIEcuNzc1IFtHODI2XeKAnSBwcmVzdW1hYmx5IHNob3VsZCBiZSDigJxOb3RlIHRoYXQg aWYgdGhlIGVycm9yIGNvbmRpdGlvbiBBSVMgd2FzIGRldGVjdGVkIGFjY29yZGluZyB0byB0aGUg Y3JpdGVyaWEgb2YgSVRVLVQgUmVjb21tZW5kYXRpb24gRy43NzUgW0c3NzVd4oCdLg0KDQoNCg0K SU1PIG5laXRoZXIgb2YgdGhlc2UgY29tbWVudHMgcmVxdWlyZXMgcG9zdGluZyBhIG5ldyB2ZXJz aW9uIG9mIHRoZSBkcmFmdCBwcmlvciB0byByZXF1ZXN0aW5nIGl0cyBwdWJsaWNhdGlvbjsgaG9w ZWZ1bGx5IHRoZXkgY2FuIGJlIGhhbmRsZWQgaW4gdGhlIHByb2Nlc3Mgb2YgYXBwcm92YWwgYW5k IHB1YmxpY2F0aW9uLg0KDQpJ4oCZZCBsaWtlIHRvIHRoYW5rIFlhYWtvdiwgRGF2aWQgYW5kIEJv YiBmb3IgdGhlaXIgZWZmb3J0LiBJIGZpbmQgdmVyeSBzeW1ib2xpYyB0aGF0IHRoZSBjb25nZXN0 aW9uIGlzc3VlIHRoYXQgaGFzIGJlZW4gcmFpc2VkIGluIHRoZSBlYXJseSBkYXlzIG9mIFBXRTMg aXMg4oCTIGF0IGxvbmcgbGFzdCDigJMgc3VjY2Vzc2Z1bGx5IHJlc29sdmVkIHdpdGhvdXQgYW55 IHJldHJvLWZpdHRpbmcgb2Ygd2lkZWx5IGRlcGxveWVkIG1lY2hhbmlzbXMgZGVmaW5lZCBieSB0 aGUgUFdFMy4NCg0KUmVnYXJkcywNCiAgICAgICBTYXNoYQ0KRW1haWw6IEFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4NCk1vYmlsZTogMDU0LTkyNjYzMDINCg0KRnJvbTogcHdlMyBbbWFpbHRvOnB3ZTMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDogRnJpZGF5LCBK dWx5IDI1LCAyMDE0IDY6MjMgUE0NClRvOiBwd2UzQGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYu b3JnPg0KU3ViamVjdDogW1BXRTNdIElQUiBwb2xsIGZvciBkcmFmdC1pZXRmLXB3ZTMtY29uZ2Nv bnMtMDINCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMt MDIucGRmIGlzIG5vdyBpbiBQV0UzIFdHIGxhc3QgY2FsbC4gQXMgcGFydCBvZiB0aGUgbGFzdCBj YWxsIHByb2Nlc3MsIHdlIG5lZWQgdG8gcG9sbCB0aGUgYXV0aG9ycyBhbmQgV0cgZm9yIElQUiBp bmZvcm1hdGlvbiBvbiB0aGUgZHJhZnQuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0 IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25zLTAyPw0KDQpJZiBzbywgaGFzIHRo aXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0K KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/IE5v dGUgdGhhdCB0aGVyZQ0KYXJlIGN1cnJlbnRseSBubyBJUFIgZGlzY2xvc3VyZXMgaW4gdGhlIElF VEYgZGF0YXRyYWNrZXIuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9y IG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kDQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkNCnJlbGV2YW50IElQUi4gVGhl IHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIFBXRTMgV0cgbWFpbGluZw0KbGlzdC4g VGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSBy ZXNwb25zZQ0KaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFjaCBjb250 cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0aGUgUFdFMyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUg bm90IGxpc3RlZCBhcyBhbiBhdXRob3INCm9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBs aWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlDQpvZiBhbnkgSVBSIHRoYXQgaGFz IG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGDQpydWxlcy4N Cg0KVGhhbmtzLA0KQW5keQ0K --_000_b081bc1b54c842f2b302b065b85e4a6aexrad6adradcoil_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLkRlZmF1bHQsIGxpLkRlZmF1bHQsIGRpdi5E ZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOkRlZmF1bHQ7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hdXRvc3BhY2U6bm9uZTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFu dDsNCgljb2xvcjojMUY0OTdEOw0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0 aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTE1MDc1NjkwNTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQzMjkzNzgzMiA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNhc2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBzcG90dGluZyB0aGVzZSBwcm9i bGVtcyBpbiB0aGUgZHJhZnQsIGFsbCBvZiB3aGljaCBhcmUgZ29vZCBjYXRjaGVzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB3aWxsIGZpeCBpbiBhIGZpbmFsIHJlc3BpbiBhZnRlciB0aGUgV0cgTEMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WShKKVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHB3ZTMgW21haWx0bzpw d2UzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsZXhhbmRlciBWYWlu c2h0ZWluPGJyPg0KPGI+U2VudDo8L2I+IDI4IEp1bHksIDIwMTQgMDM6MDQ8YnI+DQo8Yj5Ubzo8 L2I+IEFuZHJldyBHLiBNYWxpczxicj4NCjxiPkNjOjwvYj4gcHdlM0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbUFdFM10gV0cgTGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXB3ZTMtY29u Z2NvbnMtMDI/ICh3YXM6IElQUiBwb2xsIGZvciBkcmFmdC1pZXRmLXB3ZTMtY29uZ2NvbnMtMDIp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHkgYW5kIGFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U29tZWhvdyBJIGRpZCBub3QgZmluZCBhbiBleHBsaWNpdCBX R0xDIG1lc3NhZ2UgZm9yIHRoaXMgZHJhZnQgKG5laXRoZXIgaW4gbXkgYXJjaGl2ZSBub3IgaW4g dGhlIFdHIG9uZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OZXZlcnRoZWxlc3MsIEkgc3VwcG9ydCByZXF1ZXN0aW5n IHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJEZWZhdWx0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSBoYXZlIGEgZmV3IGVkaXRvcmlhbCBjb21tZW50czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJEZWZhdWx0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiBwYWdlIDYgdGhlIHRleHQgc2F5 cyDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkludGVybmF0aW9uYWwg c3RhbmRhcmRzIHBsYWNlIHN0cmluZ2VudCBsaW1pdHMgb24gdGhlIG51bWJlcg0KIG9mIHN1Y2gg ZmF1bHRzIHRvbGVyYXRlZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+4oCdLiAmbmJzcDtJIGFzc3VtZSB0aGUgcmVmZXJlbmNlIGlzIHRvIElUVS1UIFJl Y29tbWVuZGF0aW9uIEcuODI2LCBidXQgaXQgd291bGQgYmUgbmljZSB0byBzdGF0ZSB0aGF0IGV4 cGxpY2l0bHk7IEkgYW0gYWxzbyBub3Qgc3VyZSB3aGV0aGVyIHBsdXJhbCAo4oCcPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGln aHQ6eWVsbG93Ij5zdGFuZGFyZHM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPuKAnSkNCiBpcyBqdXN0aWZpZWQgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iRGVmYXVsdCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxzbyBvbiBwYWdlIDYsIEkgc3Vn Z2VzdCBpbnNlcnRpbmcgdGhlIG11bHRpcGxpY2F0aW9uIHNpZ25zIChhc3Rlcmlza3MpIGluIHRo ZSBmb3JtdWxhICZuYnNwO2luIHRoZSBzYW1lIHdheSBpdCBpcyBkb25lIGluIFNlY3Rpb24NCiAz LjEgb2YgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM0OCI+UkZDIDUz NDg8L2E+IChmcm9tIHdoaWNoIHRoaXMgZm9ybXVsYSBpcyB0YWtlbik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iRGVmYXVsdCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gcGFnZSAxMSwg4oCcPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWNvbmQsIHRoZSBkZXJpdmF0aW9u IGFzc3VtZWQgdGhhdCB0aGUgVERNIFBXIHdhcyBjb21wZXRpbmcgd2l0aCBsb25nLWxpdmVkDQo8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPlRETTwv c3Bhbj4gZmxvd3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPuKAnSBwcmVzdW1hYmx5IHNob3VsZCBiZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPlNlY29uZCwgdGhlIGRlcml2YXRpb24gYXNzdW1lZCB0aGF0IHRoZQ0KIFRE TSBQVyB3YXMgY29tcGV0aW5nIHdpdGggbG9uZy1saXZlZCA8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPg0KVENQPC9zcGFuPiBmbG93czwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iRGVmYXVsdCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIi Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gcGFn ZSAxOCwg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Ob3RlIHRoYXQg aWYgdGhlIGVycm9yIGNvbmRpdGlvbiBBSVMgd2FzIGRldGVjdGVkIGFjY29yZGluZyB0byB0aGUg Y3JpdGVyaWENCiBvZiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjc3NSA8c3BhbiBzdHlsZT0iYmFj a2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPg0KW0c4MjZdPC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdIHByZXN1bWFi bHkgc2hvdWxkIGJlIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Tm90 ZSB0aGF0IGlmIHRoZSBlcnJvciBjb25kaXRpb24gQUlTIHdhcyBkZXRlY3RlZCBhY2NvcmRpbmcg dG8gdGhlIGNyaXRlcmlhIG9mIElUVS1UIFJlY29tbWVuZGF0aW9uDQogRy43NzUgPHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5bRzc3NV08L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IkRlZmF1bHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iRGVmYXVsdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklNTyBuZWl0aGVyIG9mIHRoZXNlIGNvbW1lbnRzIHJlcXVpcmVzIHBvc3RpbmcgYSBuZXcg dmVyc2lvbiBvZiB0aGUgZHJhZnQgcHJpb3IgdG8gcmVxdWVzdGluZyBpdHMgcHVibGljYXRpb247 IGhvcGVmdWxseSB0aGV5IGNhbiBiZSBoYW5kbGVkIGluIHRoZSBwcm9jZXNzIG9mDQogYXBwcm92 YWwgYW5kIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQgbGlrZSB0byB0aGFuayBZYWFrb3Ys IERhdmlkIGFuZCBCb2IgZm9yIHRoZWlyIGVmZm9ydC4gSSBmaW5kIHZlcnkgc3ltYm9saWMgdGhh dCB0aGUgY29uZ2VzdGlvbiBpc3N1ZSB0aGF0IGhhcyBiZWVuIHJhaXNlZCBpbiB0aGUgZWFybHkg ZGF5cyBvZiBQV0UzIGlzIOKAkw0KIGF0IGxvbmcgbGFzdCDigJMgc3VjY2Vzc2Z1bGx5IHJlc29s dmVkIHdpdGhvdXQgYW55IHJldHJvLWZpdHRpbmcgb2Ygd2lkZWx5IGRlcGxveWVkIG1lY2hhbmlz bXMgZGVmaW5lZCBieSB0aGUgUFdFMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNo YQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVtYWlsOg0KPGEgaHJlZj0ibWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9iaWxlOiAwNTQt OTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBwd2Uz IFs8YSBocmVmPSJtYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cHdlMy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEcuIE1hbGlzPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyNSwgMjAxNCA2OjIzIFBNPGJyPg0KPGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86cHdlM0BpZXRmLm9yZyI+cHdlM0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW1BXRTNdIElQUiBwb2xsIGZvciBkcmFmdC1pZXRmLXB3ZTMtY29u Z2NvbnMtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0 Zi1wd2UzLWNvbmdjb25zLTAyLnBkZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXB3ZTMtY29uZ2NvbnMtMDIucGRmPC9hPiBpcyBub3cgaW4gUFdFMyBXRyBsYXN0IGNhbGwuIEFz IHBhcnQgb2YgdGhlIGxhc3QgY2FsbCBwcm9jZXNzLCB3ZQ0KIG5lZWQgdG8gcG9sbCB0aGUgYXV0 aG9ycyBhbmQgV0cgZm9yIElQUiBpbmZvcm1hdGlvbiBvbiB0aGUgZHJhZnQuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCkFyZSB5b3UgYXdhcmUgb2YgYW55Jm5i c3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7dGhhdCBhcHBsaWVzIHRvJm5ic3A7ZHJhZnQtaWV0Zi1wd2UzLWNvbmdjb25z LTAyPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpJZiBzbywg aGFzIHRoaXMmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3NwYW4+ Jm5ic3A7YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYmbmJzcDs8c3BhbiBz dHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3NwYW4+Jm5ic3A7cnVsZXM8YnI+DQooc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gTm90ZSB0 aGF0IHRoZXJlPGJyPg0KYXJlIGN1cnJlbnRseSBubyZuYnNwOzxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kOiNGRkZGQ0MiPklQUjwvc3Bhbj4mbmJzcDtkaXNjbG9zdXJlcyBpbiB0aGUgSUVURiBkYXRh dHJhY2tlci48YnI+DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhv ciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZDxicj4NCnRvIHRoaXMgZW1haWwgcmVnYXJk bGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueTxicj4NCnJlbGV2YW50 Jm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+SVBSPC9zcGFuPi4gVGhlIHJl c3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIFBXRTMgV0cgbWFpbGluZzxicj4NCmxpc3Qu IFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEg cmVzcG9uc2U8YnI+DQpoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBlYWNo IGNvbnRyaWJ1dG9yLjxicj4NCjxicj4NCklmIHlvdSBhcmUgb24gdGhlIFBXRTMgV0cgZW1haWwg bGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yPGJyPg0Kb3IgY29udHJpYnV0b3Is IHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmU8YnI+ DQpvZiBhbnkmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5JUFI8L3NwYW4+ Jm5ic3A7dGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRo IElFVEY8YnI+DQpydWxlcy48YnI+DQo8YnI+DQpUaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkFuZHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_b081bc1b54c842f2b302b065b85e4a6aexrad6adradcoil_-- From nobody Tue Jul 29 07:02:57 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A831A01C6 for ; Tue, 29 Jul 2014 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egomH5HvIohn for ; Tue, 29 Jul 2014 07:02:51 -0700 (PDT) Received: from rad.co.il (mailrelay02-ib2.rad.com [91.143.228.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED2B1A03D6 for ; Tue, 29 Jul 2014 07:02:50 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES256-SHA encrypted SMTP; 29 Jul 2014 17:02:44 +0300 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 29 Jul 2014 17:02:43 +0300 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Tue, 29 Jul 2014 17:02:43 +0300 From: Yaakov Stein To: "stbryant@cisco.com" Thread-Topic: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) Thread-Index: AQHPqlVsKTLQN/nD6U262AYuZfLhv5u3FISw Date: Tue, 29 Jul 2014 14:02:43 +0000 Message-ID: <666bdda0bb324e1793f5821d84e0fbfe@exrad6.ad.rad.co.il> References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> <53D630EE.4000008@cisco.com> In-Reply-To: <53D630EE.4000008@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: multipart/alternative; boundary="_000_666bdda0bb324e1793f5821d84e0fbfeexrad6adradcoil_" MIME-Version: 1.0 Spam-Score: -2.40 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/a0nxC8cjn9bUJFFIspGVfUg5GKQ Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:02:55 -0000 --_000_666bdda0bb324e1793f5821d84e0fbfeexrad6adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, I referenced the circuit breaker work where it first mentioned in a substa= ntive way, rather than in passing in the introduction. Of course I can add the referen= ce further up. The draft uses Ethernet PWs as the archetypical elastic PW. The conclusion is true for any PW carrying congestion responsive traffic, but the proof for other cases, e.g., for TCP/IP over ATM over PW is harder. Some may recall that I explicitly covered this case in an earlier version o= f this draft, but my co-authors thought that it added little to the flow of the argument, at a cost of a long digression and having to use language with which the tr= ansport area people would not be comfortable. A more major issue is what happens when the Ethernet PW carries half TCP traffic and half UDP traffic. This we specifically avoided. Of course, the major problem with this draft is going to be the pictures! But as Alice asked "what is the use of an RFC without pictures?". (I'm waiting for Bob and Eve to answer that one) Y(J)S From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: 28 July, 2014 06:16 To: Alexander Vainshtein; Andrew G. Malis Cc: pwe3@ietf.org Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR= poll for draft-ietf-pwe3-congcons-02) This is a well written draft, that makes a useful contribution to a long standing problem and I fully support its publication as an RFC. I have a few comments that I would request that the authors consider and a couple of nits. I also agree with the points that Sasha makes, and am also pleased that no changes are required to this widely deployed packet transport mechanism. Firstly I think that you should say a little bit more about the circuit breaker than you currently do, in particular the interaction with the control plane and the restart procedure. Secondly, whilst Ethernet PWs are a good example and by far the most common elastic case they are not the only elastic PWs type. You need a line in the text pointing out the equivalence and possibly naming the current types that behave in the same way as IP. SB> Where does ATM fit into the taxonomy? SB> Also what about FC Port Mode? nits: such a PW is inable to respond to congestion in a TCP-like manner; SB> That should be unable the packet loss rate PLR SB> PLR should be (PLR) The circuit breaker needs a ref on first use, and maybe a little description since it is a new concept in PWE3 - Stewart On 28/07/2014 09:03, Alexander Vainshtein wrote: Andy and all, Somehow I did not find an explicit WGLC message for this draft (neither in = my archive nor in the WG one). Nevertheless, I support requesting publication of this draft as an Informat= ional RFC. I have a few editorial comments: 1. On page 6 the text says "International standards place stringent limits = on the number of such faults tolerated". I assume the reference is to ITU-= T Recommendation G.826, but it would be nice to state that explicitly; I am= also not sure whether plural ("standards") is justified here. 2. Also on page 6, I suggest inserting the multiplication signs (asterisks)= in the formula in the same way it is done in Section 3.1 of RFC 5348 (from which this formula is taken) 3. On page 11, "Second, the derivation assumed that the TDM PW was competin= g with long-lived TDM flows" presumably should be "Second, the derivation a= ssumed that the TDM PW was competing with long-lived TCP flows". 4. On page 18, "Note that if the error condition AIS was detected according= to the criteria of ITU-T Recommendation G.775 [G826]" presumably should be= "Note that if the error condition AIS was detected according to the criter= ia of ITU-T Recommendation G.775 [G775]". IMO neither of these comments requires posting a new version of the draft p= rior to requesting its publication; hopefully they can be handled in the pr= ocess of approval and publication. I'd like to thank Yaakov, David and Bob for their effort. I find very symbo= lic that the congestion issue that has been raised in the early days of PWE= 3 is - at long last - successfully resolved without any retro-fitting of wi= dely deployed mechanisms defined by the PWE3. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, July 25, 2014 6:23 PM To: pwe3@ietf.org Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG la= st call. As part of the last call process, we need to poll the authors and = WG for IPR information on the draft. Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there are currently no IPR disclosures in the IETF datatracker. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the PWE3 WG mailing list. The document will not advance to the next stage until a response has been received from each author and each contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Andy _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_666bdda0bb324e1793f5821d84e0fbfeexrad6adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

I referenced the circuit = breaker work where it  first mentioned in a substantive way,

rather than in passing in= the introduction. Of course I can add the reference further up.=

 <= /p>

The draft uses Ethernet P= Ws as the archetypical elastic PW.

The conclusion is true fo= r any PW carrying congestion responsive traffic,

but the proof for other c= ases, e.g., for TCP/IP over ATM over PW is harder.

Some may recall that I ex= plicitly covered this case in an earlier version of this draft,<= /span>

but my co-authors thought= that it added little to the flow of the argument,

at a cost of a long digre= ssion and having to use language with which the transport area people

would not be comfortable.=

 <= /p>

A more major issue is wha= t happens when the Ethernet PW carries

half TCP traffic and half= UDP traffic. This we specifically avoided.

 <= /p>

Of course, the major prob= lem with this draft is going to be the pictures!

But as Alice asked “= ;what is the use of an RFC without pictures?”.

(I’m waiting for Bo= b and Eve to answer that one)

 <= /p>

Y(J)S

 <= /p>

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: 28 July, 2014 06:16
To: Alexander Vainshtein; Andrew G. Malis
Cc: pwe3@ietf.org
Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (w= as: IPR poll for draft-ietf-pwe3-congcons-02)

 

This is a well writte= n draft, that makes a useful
contribution to a long standing problem and
I fully support its publication as an RFC.

I have a few comments that I would request
that the authors consider and a couple
of nits. I also agree with the points that
Sasha makes, and am also pleased that no
changes are required to this widely deployed
packet transport mechanism.

Firstly I think that you should say a little bit
more about the circuit breaker than you currently
do, in particular the interaction with the control plane
and the restart procedure.

Secondly, whilst Ethernet PWs are a good example
and by far the most common elastic case they are not
the only elastic PWs type. You need a line in the text
pointing out the equivalence and possibly naming
the current types that behave in the same way as
IP.

SB> Where does ATM fit into the taxonomy?

SB> Also what about FC Port Mode?


nits:

such a PW is inable to respond to conges= tion in a
TCP-like manner;<= /p>


SB> That should be unable

the packe= t loss rate PLR

SB> PLR should be (PLR)

The circuit breaker needs a ref on first use, and maybe a little description since<= br> it is a new concept in PWE3

- Stewart



On 28/07/2014 09:03, Alexander Vainshtein wrote:

Andy and all,=

Somehow I did not find an= explicit WGLC message for this draft (neither in my archive nor in the WG = one).

 <= /p>

Nevertheless, I support r= equesting publication of this draft as an Informational RFC.

 <= /p>

I have a few editorial comm= ents:

1. On page 6 the text says “Int= ernational standards place stringent limits on the number of such faults tolerated”.  I assume = the reference is to ITU-T Recommendation G.826, but it would be nice to sta= te that explicitly; I am also not sure whether plural (“standards= ”) is justified here.

2. Also on page 6, I suggest inserting the multiplication signs (asterisks) i= n the formula  in the same way it is done in Section 3.1 of RFC 5348 (from which= this formula is taken)

3. On page 11, “Second, the der= ivation assumed that the TDM PW was competing with long-lived TDM flows” presumably should be “Second, the derivation assumed that the TDM PW was competing with long-lived TCP flows”.  

4. On page 18, “Note that if th= e error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]” presumably should be= “Note that if the error cond= ition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G775]= ”.

 

IMO neither of these commen= ts requires posting a new version of the draft prior to requesting its publ= ication; hopefully they can be handled in the process of approval and publication.

 <= /p>

I’d like to thank Y= aakov, David and Bob for their effort. I find very symbolic that the conges= tion issue that has been raised in the early days of PWE3 is – at long last – successfully resolved without any retro-fitting of wi= dely deployed mechanisms defined by the PWE3.

 <= /p>

Regards,

    &= nbsp;  Sasha

Email: Alexander.Vainshtein@ec= itele.com

Mobile: 054-9266302

 <= /p>

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02=

 

http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now = in PWE3 WG last call. As part of the last call process, we need to poll the authors and WG for IPR information on the draft.

Are you aware of any IPR&nb= sp;that applies to draft-ietf-pwe3-congcons-02?

If so, has this IPR bee= n disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no IPR di= sclosures in the IETF datatracker.

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response n= eeds to be sent to the PWE3 WG mailing
list. The document will not advance to the next stage until a response
has been received from each author and each contributor.

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

Thanks,

Andy




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




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_666bdda0bb324e1793f5821d84e0fbfeexrad6adradcoil_-- From nobody Tue Jul 29 07:08:16 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6B41B28BC for ; Tue, 29 Jul 2014 07:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2u6qwYdnSwh for ; Tue, 29 Jul 2014 07:07:53 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE861B2838 for ; Tue, 29 Jul 2014 07:07:44 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 14:07:42 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 14:07:42 +0000 From: Alexander Vainshtein To: "stbryant@cisco.com" , Yakov Rekhter , "pwe3@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqymWveYGLBru1kCsLuzIRj9tdJu3CWCA Date: Tue, 29 Jul 2014 14:07:41 +0000 Message-ID: References: <201407251524.s6PFOPn92012@magenta.juniper.net> <53D79504.4050904@cisco.com> In-Reply-To: <53D79504.4050904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(377454003)(479174003)(24454002)(37854004)(199002)(189002)(13464003)(252514010)(95666004)(33646002)(106356001)(106116001)(83072002)(77982001)(66066001)(85306003)(105586002)(80022001)(85852003)(107046002)(107886001)(76482001)(19580395003)(21056001)(83322001)(15975445006)(79102001)(15202345003)(76576001)(1941001)(76176999)(50986999)(101416001)(54356999)(81542001)(46102001)(74502001)(64706001)(19580405001)(86362001)(87936001)(20776003)(2656002)(74662001)(81342001)(74316001)(4396001)(99396002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/4i8PkJoj9NAP2JRvybb4QYm3bSY Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:08:04 -0000 Stewart, Yakov and all, I have started reading the draft, and it seems that it breaks quite a few c= ommon architectural assumptions. The following text from Section 3.1 "Single-Segment PW" looks highly proble= matic to me: At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CEs. The AC used for the CE to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. . To the best of my order for the pair of interconnected CEs to be able to op= erate in this way each of them should treat the pair of ACs shown in Figure= 1 as a single logical entity. E.g., if we are speaking about Ethernet PWs, each CE could treat Ethernet l= inks supporting these two ACs as a single Link Aggregation Group. However, = the draft does not mention any such thing (or at least I did not find it). = =20 Do I miss something important here? I also wonder whether, in the single segment PW scenario, the same level of= protection could not be achieved with ICCP (RFC 7275) running between eac= h pair of PEs and, possibly with 4 (instead of 2) PWs. For the reference, = ICCP (or RFC 7275) is not mentioned in the draft, even if a possible altern= ative solution to some of the problems it solves. ( Stewart did not specify in his email which MPLS architecture principles he = thinks are broken by this draft. I think, however, that some PWE3 architectural principles are definitely ar= e broken, and this includes: - Bi-directional nature of the PW - it seems that the draft allows each a P= W be Up in one direction and Down in the other one - Lack of dependencies between the PSN tunnels and the PWs they carry.=20 * Consider the network diagram shown in Figure 5 in Section 4.1 * The text suggests that the tunnel between PE1 and PE2 must recognize PE4= as the "protector" node for the PW it carries * What is supposed to happen if the tunnel between PE1 and PE2 carries, sa= y, 10 PWs, each with its own backup PE PE4-1, ... PE4-10)?=20 - Lack of dependencies between the mechanism used for the tunnel setup (LDP= , RSVP-TE, manual configuration etc.) and the PWs this tunnel carries. * Is the protection model described in Section 4.1 compatible with Tunnel = LSPs being set up by LDP? With, say, GRE tunnels carrying the PWs using MPL= S-in-GRE? Last but not least, I would like to understand better how the draft is prot= ecting MS-PWs against S-PE failures.=20 Specifically, I'd like to understand whether it is applicable to the case w= hen each pair of T-PEs resides in its own AS, with two pairs of directly co= nnected ASBRs between these two ASs acting as S-PEs. There would be no nee= d to set up any tunnel LSPs between each pair of S-PEs in this scenario. I would appreciate an analysis of this scenario regarding ability to protec= t about the ASBR/S-PE failure. IMO it is a relevant scenario because MS-PWs= are one of the methods to provide inter-AS services. My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, July 29, 2014 3:35 PM > To: Yakov Rekhter; pwe3@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > On 25/07/2014 16:24, Yakov Rekhter wrote: > > Hi, > > > >> This email begins a second two week working group last call for > >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01= . > >> > >> Please review the draft and post any comments to the PWE3 list. > >> > >> If you have read the draft, even if you don't have any comments, but > >> would like to see the draft progressed, please can you indicate this = to the > list. > >> > >> This working group last call will end on Friday August 8th, 2014. > > I would like to see the draft progressed. > > > > Yakov. > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > Yakov >=20 > Doesn't this draft implicitly make a number of extensions to the MPLS > architecture? >=20 > Stewart >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Tue Jul 29 07:26:14 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3815A1B28CA for ; Tue, 29 Jul 2014 07:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-GLWoNBUdyQ for ; Tue, 29 Jul 2014 07:26:06 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E3E1B2896 for ; Tue, 29 Jul 2014 07:26:05 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so10518585qga.36 for ; Tue, 29 Jul 2014 07:26:04 -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=TiNnEmhoSMPvzQ2z3xAKe5n6tLFOyNmuo6vC3GCIGw8=; b=1AZ2em2GARlxdSzMnLJmbujuunGT0V44kWS7JepXBobSfw6YfiNDwn+xcUj0puv+bc yzW2dYAkshRzKh9KmnMjC8Of7PVwqX0T4lBngBu4MWgbw2w4wv1MHq/OUqkbNo68BxCh +hdPtBZY449qa4OsP1WsZk70Cgk8T42ceUCFSxH6Hv1Hv/QHvizck64/AGCQDdtVpfi7 jQY059c7wb+4ChUe+b2AtLX7UxLSNquHYADq/1RcbWeuWn9uLbNkX6V+bYLCOB6DD60y FLRNcPAgyDjodbCWjHLrk+gQvGtI+y6mXBWKBw6/syoR7HoyNnxfMXu43cg9dwqHvmfo ZqzQ== X-Received: by 10.140.88.41 with SMTP id s38mr3681815qgd.73.1406643964321; Tue, 29 Jul 2014 07:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Tue, 29 Jul 2014 07:25:43 -0700 (PDT) In-Reply-To: <666bdda0bb324e1793f5821d84e0fbfe@exrad6.ad.rad.co.il> References: <11d70b862da7462989dc64a485a03840@AM3PR03MB612.eurprd03.prod.outlook.com> <53D630EE.4000008@cisco.com> <666bdda0bb324e1793f5821d84e0fbfe@exrad6.ad.rad.co.il> From: "Andrew G. Malis" Date: Tue, 29 Jul 2014 10:25:43 -0400 Message-ID: To: Yaakov Stein Content-Type: multipart/alternative; boundary=001a11c13e7ed1a4af04ff55d135 Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/P1CAtfwwIy-4TH7siaw7f_viYns Cc: "pwe3@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: IPR poll for draft-ietf-pwe3-congcons-02) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 14:26:12 -0000 --001a11c13e7ed1a4af04ff55d135 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yaakov, There's a precedent for RFCs that only have the diagrams in the PDF version. As one example that comes to mind, see RFC 1144. Cheers, Andy On Tue, Jul 29, 2014 at 10:02 AM, Yaakov Stein wrote: > Stewart, > > > > I referenced the circuit breaker work where it first mentioned in a > substantive way, > > rather than in passing in the introduction. Of course I can add the > reference further up. > > > > The draft uses Ethernet PWs as the archetypical elastic PW. > > The conclusion is true for any PW carrying congestion responsive traffic, > > but the proof for other cases, e.g., for TCP/IP over ATM over PW is harde= r. > > Some may recall that I explicitly covered this case in an earlier version > of this draft, > > but my co-authors thought that it added little to the flow of the argumen= t, > > at a cost of a long digression and having to use language with which the > transport area people > > would not be comfortable. > > > > A more major issue is what happens when the Ethernet PW carries > > half TCP traffic and half UDP traffic. This we specifically avoided. > > > > Of course, the major problem with this draft is going to be the pictures! > > But as Alice asked =E2=80=9Cwhat is the use of an RFC without pictures?= =E2=80=9D. > > (I=E2=80=99m waiting for Bob and Eve to answer that one) > > > > Y(J)S > > > > *From:* pwe3 [mailto:pwe3-bounces@ietf.org] *On Behalf Of *Stewart Bryant > *Sent:* 28 July, 2014 06:16 > *To:* Alexander Vainshtein; Andrew G. Malis > *Cc:* pwe3@ietf.org > *Subject:* Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (was: > IPR poll for draft-ietf-pwe3-congcons-02) > > > > This is a well written draft, that makes a useful > contribution to a long standing problem and > I fully support its publication as an RFC. > > I have a few comments that I would request > that the authors consider and a couple > of nits. I also agree with the points that > Sasha makes, and am also pleased that no > changes are required to this widely deployed > packet transport mechanism. > > Firstly I think that you should say a little bit > more about the circuit breaker than you currently > do, in particular the interaction with the control plane > and the restart procedure. > > Secondly, whilst Ethernet PWs are a good example > and by far the most common elastic case they are not > the only elastic PWs type. You need a line in the text > pointing out the equivalence and possibly naming > the current types that behave in the same way as > IP. > > SB> Where does ATM fit into the taxonomy? > > SB> Also what about FC Port Mode? > > > nits: > > such a PW is inable to respond to congestion in a > TCP-like manner; > > > SB> That should be unable > > the packet loss rate PLR > > SB> PLR should be (PLR) > > The circuit breaker needs a ref on first > use, and maybe a little description since > it is a new concept in PWE3 > > - Stewart > > > > On 28/07/2014 09:03, Alexander Vainshtein wrote: > > Andy and all, > > Somehow I did not find an explicit WGLC message for this draft (neither i= n > my archive nor in the WG one). > > > > Nevertheless, I support requesting publication of this draft as an > Informational RFC. > > > > I have a few editorial comments: > > 1. On page 6 the text says =E2=80=9CInternational standards place stringe= nt > limits on the number of such faults tolerated=E2=80=9D. I assume the ref= erence > is to ITU-T Recommendation G.826, but it would be nice to state that > explicitly; I am also not sure whether plural (=E2=80=9Cstandards=E2=80= =9D) is justified > here. > > 2. Also on page 6, I suggest inserting the multiplication signs > (asterisks) in the formula in the same way it is done in Section 3.1 of = RFC > 5348 (from which this formula is > taken) > > 3. On page 11, =E2=80=9CSecond, the derivation assumed that the TDM PW wa= s > competing with long-lived TDM flows=E2=80=9D presumably should be =E2=80= =9CSecond, the > derivation assumed that the TDM PW was competing with long-lived TCP flow= s=E2=80=9D. > > > 4. On page 18, =E2=80=9CNote that if the error condition AIS was detected > according to the criteria of ITU-T Recommendation G.775 [G826]=E2=80=9D > presumably should be =E2=80=9CNote that if the error condition AIS was de= tected > according to the criteria of ITU-T Recommendation G.775 [G775]=E2=80=9D. > > > > IMO neither of these comments requires posting a new version of the draft > prior to requesting its publication; hopefully they can be handled in the > process of approval and publication. > > > > I=E2=80=99d like to thank Yaakov, David and Bob for their effort. I find = very > symbolic that the congestion issue that has been raised in the early days > of PWE3 is =E2=80=93 at long last =E2=80=93 successfully resolved without= any retro-fitting > of widely deployed mechanisms defined by the PWE3. > > > > Regards, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > > *From:* pwe3 [mailto:pwe3-bounces@ietf.org ] *On > Behalf Of *Andrew G. Malis > *Sent:* Friday, July 25, 2014 6:23 PM > *To:* pwe3@ietf.org > *Subject:* [PWE3] IPR poll for draft-ietf-pwe3-congcons-02 > > > > http://www.ietf.org/id/draft-ietf-pwe3-congcons-02.pdf is now in PWE3 WG > last call. As part of the last call process, we need to poll the authors > and WG for IPR information on the draft. > > Are you aware of any IPR that applies to draft-ietf-pwe3-congcons-02? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there > are currently no IPR disclosures in the IETF datatracker. > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. The response needs to be sent to the PWE3 WG mailing > list. The document will not advance to the next stage until a response > has been received from each author and each contributor. > > If you are on the PWE3 WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > Thanks, > > Andy > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --001a11c13e7ed1a4af04ff55d135 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yaakov,

There's a precedent for RFC= s that only have the diagrams in the PDF version. As one example that comes= to mind, see RFC 1144.

Cheers,
Andy


On Tue,= Jul 29, 2014 at 10:02 AM, Yaakov Stein <yaakov_s@rad.com> wr= ote:

Stewart,

=C2=A0

I referenced the circuit = breaker work where it =C2=A0first mentioned in a substantive way,=

rather than in passing in= the introduction. Of course I can add the reference further up.<= /u>

=C2=A0

The draft uses Ethernet P= Ws as the archetypical elastic PW.

The conclusion is true fo= r any PW carrying congestion responsive traffic,

but the proof for other c= ases, e.g., for TCP/IP over ATM over PW is harder.

Some may recall that I ex= plicitly covered this case in an earlier version of this draft,

but my co-authors thought= that it added little to the flow of the argument,

at a cost of a long digre= ssion and having to use language with which the transport area people

would not be comfortable.=

=C2=A0

A more major issue is wha= t happens when the Ethernet PW carries

half TCP traffic and half= UDP traffic. This we specifically avoided.

=C2=A0

Of course, the major prob= lem with this draft is going to be the pictures!

But as Alice asked =E2=80= =9Cwhat is the use of an RFC without pictures?=E2=80=9D.

(I=E2=80=99m waiting for = Bob and Eve to answer that one)

=C2=A0

Y(J)S

=C2=A0

From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: 28 July, 2014 06:16
To: Alexander Vainshtein; Andrew G. Malis
Cc: pwe3@ietf.org=
Subject: Re: [PWE3] WG Last call for draft-ietf-pwe3-congcons-02? (w= as: IPR poll for draft-ietf-pwe3-congcons-02)

=C2=A0

This is a well writte= n draft, that makes a useful
contribution to a long standing problem and
I fully support its publication as an RFC.

I have a few comments that I would request
that the authors consider and a couple
of nits. I also agree with the points that
Sasha makes, and am also pleased that no
changes are required to this widely deployed
packet transport mechanism.

Firstly I think that you should say a little bit
more about the circuit breaker than you currently
do, in particular the interaction with the control plane
and the restart procedure.

Secondly, whilst Ethernet PWs are a good example
and by far the most common elastic case they are not
the only elastic PWs type. You need a line in the text
pointing out the equivalence and possibly naming
the current types that behave in the same way as
IP.

SB> Where does ATM fit into the taxonomy?

SB> Also what about FC Port Mode?


nits:

such a PW is inable to respond to conges= tion in a
TCP-like manner;


SB> That should be unable

the packe= t loss rate PLR

SB> PLR should be (PLR)

The circuit breaker needs a ref on first
use, and maybe a little description since
it is a new concept in PWE3

- Stewart



On 28/07/2014 09:03, Alexander Vainshtein wrote:

Andy and all,

Somehow I did not find an= explicit WGLC message for this draft (neither in my archive nor in the WG = one).

=C2=A0

Nevertheless, I support r= equesting publication of this draft as an Informational RFC.<= u>

=C2=A0

I have a few editorial comments:

1. On= page 6 the text says =E2=80=9CInte= rnational standards place stringent limits on the number of such faults tolerated=E2=80=9D. =C2=A0I assum= e the reference is to ITU-T Recommendation G.826, but it would be nice to s= tate that explicitly; I am also not sure whether plural (=E2=80=9Cstandards=E2=80=9D) is justified here.

2. Al= so on page 6, I suggest inserting the multiplication signs (asterisks) in t= he formula =C2=A0in the same way it is done in Section 3.1 of RFC 53= 48 (from which this formula is taken)

3. On= page 11, =E2=80=9CSecond, the deri= vation assumed that the TDM PW was competing with long-lived TDM flows=E2=80=9D presumably should be =E2=80=9CSecond, the derivation assumed that the TDM PW was competing with long-lived TCP flows=E2=80=9D. =C2=A0<= u>

4. On= page 18, =E2=80=9CNote that if the= error condition AIS was detected according to the criteria of ITU-T Recommendation G.775 [G826]=E2=80=9D presumably should = be =E2=80=9CNote that if the error = condition AIS was detected according to the criteria of ITU-T Recommendatio= n G.775 [G775]=E2=80=9D.

=C2=A0

IMO neither of these comments requires postin= g a new version of the draft prior to requesting its publication; hopefully= they can be handled in the process of approval and publication.

=C2=A0

I=E2=80=99d like to thank= Yaakov, David and Bob for their effort. I find very symbolic that the cong= estion issue that has been raised in the early days of PWE3 is =E2=80=93 at long last =E2=80=93 successfully resolved without any retro-fitting of = widely deployed mechanisms defined by the PWE3.

=C2=A0

Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Sasha

Email: Alexa= nder.Vainshtein@ecitele.com

Mobile: 054-9266302

=C2=A0

From: pwe3 [mailto:pwe3-bounce= s@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, July 25, 2014 6:23 PM
To: pwe3@ietf.org=
Subject: [PWE3] IPR poll for draft-ietf-pwe3-congcons-02

=C2=A0

http://www.ietf.org/id/draft-ietf-pwe3-congcons-= 02.pdf is now in PWE3 WG last call. As part of the last call process, w= e need to poll the authors and WG for IPR information on the draft.

Are you aware of any=C2=A0IPR=C2= =A0that applies to=C2=A0draft-ietf-pwe3-congcons-02?

If so, has this=C2=A0IPR=C2=A0bee= n disclosed in compliance with IETF=C2=A0IPR=C2=A0rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Note that there
are currently no=C2=A0IPR=C2=A0di= sclosures in the IETF datatracker.

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant=C2=A0IPR. The response n= eeds to be sent to the PWE3 WG mailing
list. The document will not advance to the next stage until a response
has been received from each author and each 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=C2=A0IPR=C2=A0that has not= yet been disclosed in conformance with IETF
rules.

Thanks,

Andy




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




-- 
For corporate legal information go to:
=C2=A0
http://www.cisco.com/web/about/doing_business/le=
gal/cri/index.html
=C2=A0

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


--001a11c13e7ed1a4af04ff55d135-- From nobody Tue Jul 29 07:53:45 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD71B2933; Tue, 29 Jul 2014 07:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyMirroDghWe; Tue, 29 Jul 2014 07:53:36 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA351B2822; Tue, 29 Jul 2014 07:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59017; q=dns/txt; s=iport; t=1406645615; x=1407855215; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=gWxjGB09u62iIinWcfsfv/YWkoPC3EYdG/DfsTDTC74=; b=XbbRR243kGaqpk9ZHQJCohuYaTbCxkaDnP/GWYsU69vTms9xKbQfIdmS hw7T9Za9CGLa2iPNrPmRgJOsa2A+kygYXGipJdONEx7Sv7oOe1TQ5XhWo kI8AsMqkGslfGw2uucS5NmZIwKpIjDNkxlIYEhUWDxNPmrVeBC64fR6h9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHq011OtJssW/2dsb2JhbABQCdRWgxyBJXeEJAECChEvBgwbEg80AjgUAQwBBwEBF4gnn1+PBpBVF45hEAMBJC4FhFEBBJcqhCKUToNKgW4BAR4EAg X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="126451892" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 29 Jul 2014 14:53:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6TErVKA022467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 14:53:31 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6TErTA7003579; Tue, 29 Jul 2014 15:53:30 +0100 (BST) Message-ID: <53D7B569.60400@cisco.com> Date: Tue, 29 Jul 2014 15:53:29 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pwe3 , "pwe3-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/6tak-p26wR-Qc5cMsi18Azl7SVc Cc: "mpls@ietf.org" Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Jul 2014 14:53:45 -0000 I do not support the publication of this draft without: 1) An assurance that MPLS WG has reviewed it and is happy with the extensions that seem to be made to the MPLS architecture 2) A formal description of those extensions or a pointer to those extensions in another RFC. 3) Significant clarification of how the detail of this mechanism works. For this to work you need to have co-ordinated label spaces in multiple PEs which is something that was investigated by the SPRING WG and found not to work, particularly when different manufacturers equipments were involved. As far as I can see you also need to peek below the top of stack to do a fast reroute operation which is not a currently defined MPLS operation. There seem to be a lot of details and clarifications missing that need to be provided, and I am not entirely convinced that all of the items declared out of scope are legitimately out of scope and not needed in order for a multi-vendor solution to be implemented. It would be useful to me (and I suspect to other readers) to see what the dataplane looks like at various points in the normal and repair path to verify that all parties have the right information for this to work under normal and various fault conditions. I have a number of comments inline that need to be addressed before this can proceed. - Stewart PW Endpoint Fast Failure Protection draft-ietf-pwe3-endpoint-fast-protection-01 Abstract This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Designed on the basis of multi-homed CE, PW redundancy, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. In particular, the router can restore PW traffic in the order of tens of milliseconds, SB> Not sure it's wise to specify a performance claim in a standards SB> track RFC. by transmitting the traffic to a protector through a pre-established bypass tunnel. Therefore, the mechanism can reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. === 1. Introduction Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment can be thought of as a connection between a pair of forwarders hosted by two PEs, carrying an emulated layer-2 service over a packet switched network (PSN). In the single-segment PW (SS-PW) case, a forwarder binds a PW to an attachment circuit (AC). In the multi- segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW segment to an AC, while a forwarder on a switching PE (S-PE) binds one PW segment to another PW segment. In each direction between the PEs, PW packets are transported by a PSN tunnel, which is called a transport tunnel. SB> Did we ever your the term transport tunnel before? 3. Reference Models and Failure Cases The mechanism in this document intends to use these topologies for local repair purposes. SB> The toplology is not a mechanism. Are you saying that the mechanims SB> only works in this topology? This SHALL enable local repair and global repair to work in tandem to achieve broader coverage of protection for services. SB> I have no idea how a SHALL in capitals applies here. 3.1. Single-Segment PW |<-------------- PW1 --------------->| - PE1 -------------- P1 ---------------- PE2 - / \ / \ CE1 CE2 \ / \ / - PE3 -------------- P2 ---------------- PE4 - |<-------------- PW2 --------------->| Figure 1 Each CE is multi-homed to two PEs. Hence, there are two divergent paths between the CEs. SB> It does not follow that the paths are divergent! Who knows SB> what happens in the IP layer and the underlying transport SB> network. At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. SB> May not be the same what? If they are actually the same AC you SB> have no redundancy. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CEs. The AC used for the CE to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. From the perspective of traffic flowing towards a given CE, the set of PWs, PEs and ACs involved can be viewed to serve primary and backup (or active and standby) roles. When the network is in a steady state, the PW that is intended to carry the traffic is referred to as a primary PW. The PE at the egress of the primary PW is a primary PE. The AC connecting the CE and the primary PE is a primary AC. The other PW may be used to carry the traffic upon a network failure, and is referred to as a backup PW. The PE at the egress of the backup PW is a backup PE. The AC connecting the CE and the backup PE is a backup AC. In this document, the following primary and backup roles are assigned for the traffic going from CE1 to CE2: Primary PW: PW1 Yimin Shen, et al. Expires January 25, 2015 [Page 5] Internet-Draft PW Endpoint Fast Failure Protection July 2014 Primary PE: PE2 Primary AC: CE2-PE2 Backup PW: PW2 Backup PE: PE4 Backup AC: CE2-PE4 In this case, an egress AC failure refers to the failure of the AC CE2-PE2. An egress node failure refers to the failure of PE2. The backup PE, backup PW and backup AC may be used to carry traffic after a PW endpoint failure, when CE1 and CE2 switches traffic to PW2 in local repair or global repair, as described later in this document. |<-------------- PW1 --------------->| ------------- P1 ---------------- PE2 - / \ / \ CE1 -- PE1 CE2 \ / \ / ------------- P2 ---------------- PE4 - |<-------------- PW2 --------------->| Figure 2 Figure 2 shows another possible scenario, where CE1 is single-homed to PE1, while CE2 remains multi-homed to PE2 and PE4. From the perspective of egress protection for the traffic from CE1 to CE2, this topology is not much different than Figure 1. However, for the SB> "not much different than Figure 1" is not helpful, either it is the same, or you need to explain the difference. traffic in the direction from CE2 to CE1, PE1 must anticipate traffic on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. SB> What does it mean to anticipate traffic. 3.2. Multi-Segment PW Yimin Shen, et al. Expires January 25, 2015 [Page 6] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 -------------- SPE1 --------------- TPE2 - / \ / \ CE1 CE2 \ / \ / - TPE3 -------------- SPE2 --------------- TPE4 - |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 3 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW environment. PW1 and PW2 are both MS-PWs. PW1 is established between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at SPE1. PW2 is established between TPE3 and TPE4, and switched between segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW segments are not shown in this figure for clarity. In this document, the following primary and backup roles are assigned for the traffic going from CE1 to CE2: Primary PW: PW1 Primary T-PE: TPE2 Primary S-PE: SPE1 Primary AC: CE2-TPE2 Backup PW: PW2 Backup T-PE: TPE4 Backup S-PE: SPE2 Backup AC: CE2-TPE4 In this case, an egress AC failure refers to the failure of the AC CE2-TPE2. An egress node failure refers to the failure of TPE2. An S-PE failure refers to the failure of SPE1. Yimin Shen, et al. Expires January 25, 2015 [Page 7] Internet-Draft PW Endpoint Fast Failure Protection July 2014 The backup T-PE, backup PW and backup AC are used for protecting the primary PW against egress AC failure and egress node failure. The backup S-PE and the backup PW are used for protecting the primary PW against S-PE failure, as described later in this document. For consistency with the SS-PW scenario, primary T-PEs and a primary S-PEs may simply be referred to as primary PEs in this document, where specifics is not required. Similarly, backup T-PEs and backup S-PEs may be referred to as backup PEs. 4. Theory of Operation The fast protection mechanism in this document provides three types of protection for PWs, corresponding to the three types of failures described in Section 1. a. Egress AC protection b. Egress (T-)PE node protection c. S-PE node protection The mechanism assumes a multi-homed CE with connectivity to a primary PE and a backup PE, and the existence of a backup PW in the network. In S-PE node protection, it also assumes the existence of a backup S-PE on the backup PW. SB> Do the PWs need to be symmetric - could you have more S-PEs on one that you have on the other? 4.1. Local Repair and Protector The mechanism relies on local repair to be performed by routers SB> Do you mean routers or PEs? Routers of more likely LSRs operate at a different layer and have no business knowing about PWs. SB> Has this work been reviewed my MPLS WG? I am concerned that you are doing a bunch of layer violation without explaining the how this is achieved or whether it is acceptable within the MPLS architecture. upstream adjacent to failures. Each of these routers is referred to as a "point of local repair" (PLR). A PLR MUST be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In anticipation of the failure, the PLR MUST also pre-establish a bypass PSN tunnel to a "protector", and pre-install a bypass route in the data plane. The bypass tunnel MUST have the property that it will not be affected by the topology changes in the event of the failure. SB> This is far too imprecise - you need to separate operations and topologies in the PW layer from operations and topologies in the PSN layer SB> In each case you need to be clear how you are detecting failure by specifying the MEPs and MIPs you are testing. Upon detecting the failure, the PLR MUST invoke the bypass route in the data plane, and reroute PW traffic to the protector through the bypass tunnel. The protector MUST in turn send the traffic to the target CE. SB> No the protector knows nothing about CEs - they are in the client layer, and you can only protect at the server layer or the server's server layer. This procedure is referred to as local repair. Different routers may serve as PLR and protector in different scenarios. SB> Remember they are not routers - they are xPEs or LSRs. SB> In each of the following we need to note that these are not RFC3985 PEs, even if they take no part in the protection such as the PEs on the left. Indeed I am wondering if you need to update RFC3985 and RFC5659 Yimin Shen, et al. Expires January 25, 2015 [Page 8] Internet-Draft PW Endpoint Fast Failure Protection July 2014 o In egress AC protection, the PLR is the primary PE that terminates the primary PW and hosts the primary AC, and the protector is the backup PE (Figure 4). |<-------------- PW1 --------------->| - PE1 -------------- P1 ---------------- PE2 - / PLR \ / | \ CE1 bypass| CE2 \ | / \ | / - PE3 -------------- P2 ---------------- PE4 - protector |<-------------- PW2 --------------->| Figure 4 o In egress PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW, and the protector is the backup PE (Figure 5). |<-------------- PW1 --------------->| - PE1 -------------- P1 ------- P3 ----- PE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - PE3 -------------- P2 ---------------- PE4 - protector |<-------------- PW2 --------------->| Figure 5 SB> Note that it is nothing like as clean as this, if as you later have, some of P3's traffic needs to go to PE4 and some to PE5. Also what about the o In S-PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW segment, and the protector is the backup S-PE (Figure 6). Yimin Shen, et al. Expires January 25, 2015 [Page 9] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - protector |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 6 A PLR can realize its role based on configuration or the signaling of transport tunnel. For example, in the case where the transport tunnel is signaled by RSVP, the penultimate hop router could realize SB> Could realize is not sufficient. The mechanism needs to be unconditional. that it is the PLR for egress (T-)PE or S-PE failure based on the RRO in Resv message, which should indicate that the router is one hop away from the PE. The detail of how this could be achieved on a per- protocol basis is out of the scope of this document. SB> So where is it in scope? How do I find out how to do it? In all scenarios, when a PLR reroutes traffic through a bypass tunnel to a protector during local repair, it MUST keep the label of the primary PW intact in the packets. This obviates the need for the PLR to maintain bypass routes on a per-PW basis, and allows a single bypass tunnel to carry traffic for multiple PWs. SB> OK, but didn't I read something about PE protecting subsets of the egress traffic of other PEs? How would that work without per PW information? The procedure also requires that the protector SHOULD be able to forward the traffic based on a PW label that is assigned by the primary PE, and ensure the traffic to eventually reach the target CE. From the protector's perspective, this PW label is an upstream assigned label (RFC 5331). SB> .. but the protector may be a P router and know nothing about PWs. To accomplish this, the protector SHOULD learning the PW label from the primary PE prior to the failure, and install proper forwarding state for the PW label in a dedicated label space for the primary PE. SB> This is a new PE to P router protocol During local repair, the protector SHOULD perform PW label lookup in this label space. SB> This has to be signed off by MPLS WG SB> How can this only be a SHOULD - why is it not a MUST? SB> What do you do to ensure that they even have compatible label managers? SB> Doesn't this mean a P router looking up two labels to do the repair? The above examples have shown the scenarios where the protectors are backup (T/S-)PEs. In other scenarios, a protector may be a dedicated router that assumes such role, separate from the backup (T/S-)PE of a primary PW. During local repair, the PLR MUST still reroute traffic to the protector through a bypass tunnel. The protector MUST in turn send the traffic to the backup (T/S-)PE, which MUST then send the Yimin Shen, et al. Expires January 25, 2015 [Page 10] Internet-Draft PW Endpoint Fast Failure Protection July 2014 traffic to the target CE via a backup AC or a backup PW segment. More detail will be described in Section 4.3. 4.2. Context Identifier A protector MAY protect multiple primary PEs. SB> This requires that a P router knows about PWs - how does it do that? The protector MUST maintain a separate label space for each primary PE. Likewise, the PWs terminated on a primary PE MAY be protected by multiple protectors, each for a subset of the PWs. In any case, a given primary PW SHOULD be associated with one and only one pair of {primary PE, protector}. An IPv4/v6 address is assigned to each ordered pair of {primary PE, protector} to facilitate protection establishment. This address is referred to as a "context identifier". It MUST be globally unique, or unique in the address space of the network where the primary PE and the protector reside. SB> I think you need to make clear that this is not backwards compatible with existing PW PEs. SB> You also need to explain how the IP based context identifier mechanism works. Is it in the control plane or the data plane? 4.2.1. Semantics The semantics of a context identifier is twofold. o It identifies a primary PE and an associated protector. In other words, it identifies a primary PE on a per protector basis. A given primary PE may be protected by multiple protectors, each for a subset of the primary PWs terminated on the primary PE. A distinct context identifier MUST be assigned to the primary PE and each protector. For each primary PW, its ingress PE MUST set up or resolve a transport tunnel with destination as the context identifier of the {primary PE, protector}, rather than a private IP address of the primary PE. This not only allows the transport tunnel to reach the primary PE, but also conveys the identity of the protector to the PLR(s) along the transport tunnel. Each PLR can in turn use this information to set up a bypass tunnel to the protector without relying on local configuration. o It indentifies the primary PE's label space on the protector. The protector may protect PWs for multiple primary PEs. For each primary PE, it MUST maintain a separate label space to store the PW labels assigned by that primary PE. It MUST associate a PW label with a label space via the context identifier of the {primary PE, protector}, as described below. SB> Is this context identifier an IP address or an MPLS label? Where is it carried? In addition to the normal LDP PW signaling, the primary PE MUST have a targeted LDP session with the protector, and advertise PW labels to the protector via LDP Label Mapping messages (See Yimin Shen, et al. Expires January 25, 2015 [Page 11] Internet-Draft PW Endpoint Fast Failure Protection July 2014 Section 5 for detail). The primary PE MUST attach the context identifier to each message. Upon receiving the message, the protector MUST install the advertised PW label in the label space identified by the context identifier. SB> I am currently confused about how a data packet carries the PW label provided by another PE. When a PLR sets up or resolve a bypass tunnel to the protector, it MUST set the destination to the context identifier, rather than a private IP address of the protector. Once established, the bypass tunnel, with either its MPLS label or IP tunnel destination address, is used as the identifier of label space. On the protector, all PW packets received on the bypass tunnel MUST be forwarded based on a label lookup in that label space. SB> I do not understand the data plane structure that the above sentence is describing. 4.2.2. Advertisement and Path Computation Using a context identifier as destination for both transport tunnel and bypass tunnel requires both the primary PE and the protector to advertise the context identifier via IGP as an IP address reachable through both routers in routing domain and/or TE domain. This imposes the following requirements on path computation for these tunnels. o For the transport tunnel, the ingress PE MUST choose the primary PE as the actual endpoint. o For the bypass tunnel, the PLR MUST choose the protector as the actual endpoint. In egress (T-)PE node protection and S-PE node protection, the bypass tunnel MUST avoid the primary (S-)PE. The detail of how the primary PE and the protector may advertise a context identifier is independent of this mechanism and out of the scope of this document. SB> Given that you give signalling data structures later, I am confused as to how this can be out of scope of this text. Surely this is needed to implement an interoperable solution? One approach would be to advertise it as a virtual proxy node connected to both routers, with the link between the proxy node and the primary PE having a more preferable IGP or TE metric than the link between the proxy node and the protector. The ultimate goal is for a path computation algorithm, such as CSPF (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP- FRR-MRT]), to be able to compute the paths that meet the above requirements. 4.3. Protection Models There are two protection models based on the location of a protector. A network MAY use either model, or a combination of both. Yimin Shen, et al. Expires January 25, 2015 [Page 12] Internet-Draft PW Endpoint Fast Failure Protection July 2014 4.3.1. Co-located Protector In this model, the protector is a backup PE that is directly connected to the target CE via a backup AC, or it is a backup S-PE on a backup PW. That is, the protector is co-located with the backup (S-)PE. Examples of this model have been introduced in Figure 4, Figure 5 and Figure 6 in Section 4.1. In egress AC protection and egress PE node protection, when a protector receives traffic from the PLR, it forwards the traffic to the CE via the backup AC. This is shown in Figure 7, where PE2 is the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 (the backup PE) is the protector. |<-------------- PW1 --------------->| - PE1 -------------- P1 ------- P3 ----- PE2 ---- / PLR \ PLR \ / \ | \ CE1 bypass\ |bypass CE2 \ \ | / \ \ | / - PE3 -------------- P2 ---------------- PE4 ---- protector |<-------------- PW2 --------------->| Figure 7 In S-PE node protection, when a protector receives traffic from the PLR, it MUST forward the traffic via the next segment of the backup PW. The T-PE of the backup PW MUST in turn forward the traffic to the CE via a backup AC. This is shown in Figure 8, where P4 is the PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector for SPE1. Yimin Shen, et al. Expires January 25, 2015 [Page 13] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - protector |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 8 In the co-located protector model, the number of context identifiers needed by a network is the number of distinct {primary PE, backup PE} pairs. From the perspective of scalability, the model is suitable for networks where the number of backup PEs for any given primary PE is relatively small. 4.3.2. Centralized Protector In this model, the protector is a dedicated P router or PE router that serves the role. In egress AC protection and egress PE node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In S-PE node protection, the protector MAY or MAY NOT be a backup S-PE on the backup PW. In egress AC protection and egress PE node protection, when the protector receives traffic from the PLR, if the protector has a direct connection (i.e. backup AC) to the CE, it MUST forward the traffic to the CE via the backup AC, which is similar to Figure 7. Otherwise, it MUST forward the traffic to a backup PE, which MUST then forward the traffic to the CE via a backup AC. This is shown in Figure 9, where the protector receives traffic from P3 (the PLR for egress PE failure) or PE2 (the PLR for egress AC failure) and forwards the traffic to PE4 (the backup PE). The protector may be protecting other PWs as well, which is not shown in this figure for clarity. SB> If you are going to cover the shared case, I think you need to make it much clearer how the PWs are identified from the received data packets. Yimin Shen, et al. Expires January 25, 2015 [Page 14] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<------------- PW1 --------------->| - PE1 ------------- P1 ------- P3 ----- PE2 -- / PLR \ PLR \ / \ / \ / bypass\ /bypass \ / \ / \ CE1 protector CE2 \ \ / \ \ / \ \ / \ \ / - PE3 ------------- P2 -----------------PE4 -- |<------------- PW2 --------------->| Figure 9 In S-PE node protection, when the protector receives traffic from the PLR, if the protector is a backup S-PE of the backup PW, it MUST forward the traffic via the next segment of the backup PW, and the T-PE of the backup PW MUST forward the traffic to the CE via a backup AC, which is similar to Figure 8. Otherwise, the protector MUST first forward the traffic to the backup S-PE, which MUST then forward the traffic via the next segment of the backup PW. Finally, the T-PE of the backup PW MUST forward the traffic to the CE via a backup AC. This is shown in Figure 10, where the protector forwards traffic to SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4, and TPE4 finally forwards traffic to CE2. The protector may be protecting other PW segments as well, which is not shown in this figure for clarity. Yimin Shen, et al. Expires January 25, 2015 [Page 15] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ / bypass\ \ / \ \ CE1 protector CE2 \ \ / \ \ / \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 10 The centralized protector model provides the convenience for multiple primary PEs to share one protector. Each primary PE MAY only need the one protector to protect all of its PWs. From the perspective of scalability, the number of context identifiers needed by a network MAY be bound to the number of primary PEs. 4.4. Transport Tunnel The ingress PE of a primary PW associates the PW with the primary egress PE through LDP signaling. In addition, as mentioned in Section 4.2.1, the ingress PE MUST associate the transport tunnel of the PW with the context identifier of the {primary PE, protector}, and set up or resolve the transport tunnel by using the context identifier as destination. This not only ensures that PW traffic be transported to the primary PE, but also facilitates bypass tunnel establishment at PLR(s), as the context identifier implies the identity of the protector as well. This is also the case for a multi-segment PW, where the ingress PE and egress PE are T/S-PEs. The association between the transport tunnel and the context identifier at the ingress PE MAY be achieved by configuration or an auto-discovery mechanism. In the later case, the ingress PE MAY learn the context identifier from the primary (egress) PE, if the primary PE advertises the context identifier as "third party next hop" in IPv4/v6 Interface_ID (RFC 3471, RFC 3472) in the LDP Label Mapping message of the primary PW. Yimin Shen, et al. Expires January 25, 2015 [Page 16] Internet-Draft PW Endpoint Fast Failure Protection July 2014 4.5. Bypass Tunnel A PLR may protect multiple PWs associated with one or multiple pairs of {primary PE, protector}. The PLR MUST establish a bypass tunnel to each protector for each distinct context identifier associated with that protector. The destination of the bypass tunnel MUST be the context identifier (Section 4.2.1). The PLR may derive the context identifier from the destination of the transport tunnel that traverses it. For examples, in Figure 7 and Figure 9, a bypass tunnel is established from PE2 (PLR for egress AC failure) to the protector, and another bypass tunnel is established from P3 (PLR for egress node failure) to the protector. In Figure 8 and Figure 10, a bypass tunnel is established from P4 (PLR for S-PE failure) to the protector. During local repair, the PLR reroutes traffic to the protector through a bypass tunnel with PW label intact in the packets. This normally involves pushing a label to the label stack, if the bypass tunnel is an MPLS tunnel, or pushing an IP header to the packets, if the bypass tunnel is an IP tunnel. SB> Surely it is normally a swap? SB> I am somewhat confused about what this all looks like when this is IP. The only PS/IP other than for SATOP are defined by L2TPv3 WG. There is no IP MS-PW definition that I am aware of. I think you need to be much clearer about what is going on when you discuss PW over IP egress repair. The protector MUST in turn forward the traffic based on the PW label. To achieve such kind of forwarding, the protector MUST rely on the bypass tunnel as a context to determine the primary PE's label space. If the bypass tunnel is an MPLS tunnel, the protector MUST have assigned a non-reserved label to the bypass tunnel during the establishment of the bypass tunnel, and hence this label can serve as the context. If the bypass tunnel is an IP tunnel, the protector can simply rely on the context identifier carried as the destination address in IP header. A bypass tunnel MUST have the property that it is not affected by the topology changes caused by the failure. Therefore, it can be used to transmit traffic for local repair. It SHOULD remain effective, until the traffic is moved to another fully functional egress AC, PW and/or transport tunnel. 4.6. Forwarding State on Protector A protector MUST learn PW labels from all the primary PEs that it protects (Section 5.2), and maintain the PW labels in respective label spaces of the primary PEs. In the control plane, a label space is identified by the context identifier of a pair of {primary PE, protector}. In the forwarding plane, it is indicated by the bypass tunnel(s) destined for the context identifier. SB> Are you saying that this mechanism mandates no PHP? Yimin Shen, et al. Expires January 25, 2015 [Page 17] Internet-Draft PW Endpoint Fast Failure Protection July 2014 4.6.1. Examples of Co-located Protector In Figure 7, PE4 is a co-located protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, PE4}. It learns PW1's label from PE2, and installs an forwarding entry for the label in that label space. The nexthop of the forwarding entry indicates a label pop with outgoing interface pointing to the backup AC CE2-PE4. SB> I am not sure what you are describing in the above. Is this an MPLS operation or a PW operation. If the latter it is not a simple label pop. In Figure 8, SPE2 is a co-located protector that protects PW1 against S-PE failure. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, SPE2}. It learns SEG1's label from SPE1, and installs a forwarding entry in the label space. The nexthop of the forwarding entry indicates a label swap to SEG4's label. 4.6.2. Examples of Centralized Protector In the centralized protector model, for each primary PW of which the protector is not a backup (S-)PE, the protector MUST also learn the label of the backup PW from the backup (S-)PE (Section 5.3). This is the backup (S-)PE that the protector will forward traffic to. The protector MUST install a forwarding entry with label swap from the primary PW's label to the backup PW's label. In Figure 9, the protector is a centralized protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, protector}. It learns PW1's label from PE2, and PW2's label from PE4. It installs a forwarding entry for PW1's label in the label space. The nexthop of the forwarding entry indicates a label swap to PW2's label. In Figure 10, the protector is a centralized protector that protects the PW segment SEG1 of PW1 against the node failure of SPE1. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, protector}. It learns SEG1's label from SPE1, and learns SEG3's label from SPE2. It installs a forwarding entry for SEG1's label in the label space. The nexthop of the forwarding entry indicates a label swap to SEG3's label. 5. LDP Extensions As described in previous sections, a targeted LDP session MUST be established between each pair of primary PE and protector. The primary PE sends Label Mapping message over this session to advertise primary PW labels to the protector. In the centralized protector Yimin Shen, et al. Expires January 25, 2015 [Page 18] Internet-Draft PW Endpoint Fast Failure Protection July 2014 model, a targeted LDP session MUST also be established between a backup (S-)PE and a protector. The backup PE sends Label Mapping message over this session to advertise backup PW labels to the protector. To facilitate the procedures, this document defines a new "Protection FEC Element" TLV. The Label Mapping messages of both the LDP sessions above MUST carry this TLV to indicate the identity of a primary PW. Specifically, in the centralized protector model, the Protection FEC Element TLV advertised by a backup (S-)PE MUST match the one advertised by the primary PE, so that the protector can associate the primary PW's label with the backup PW's label, and perform a label swap. This document also defines the encoding of Capability Parameter TLV (RFC 5561) for a new "Egress Protection Capability", to allow a protector to announce its capability of processing the above Protection FEC Element TLV and performing context specific label switching for PW labels. The procedures in this section are only applicable, if the protector advertises the Egress Protection Capability, the primary PE supports the advertisement of the Protection FEC Element TLV, and in the centralized protector model, the backup PE also supports the advertisement of the Protection FEC Element TLV. 5.1. Egress Protection Capability TLV A protector MUST advertise the Egress Protection Capability TLV in its Initialization message and Capability message, over the LDP session with a primary PE. In the centralized protector model, the protector MUST also advertise the TLV over the LDP session with a backup PE. The TLV carries one or multiple context identifiers. To the primary PE, the TLV SHOULD carry the context identifier of the {primary PE, protector}. In the centralized protector model, the TLV SHOULD carry to the backup PE multiple context identifiers, one for each {primary PE, protector} where the backup PE serves as a backup for the primary PE. This TLV SHOULD NOT be advertised by the primary PE or the backup PE to the protector. The processing of the Egress Protection Capability TLV by a receiving router SHOULD follow the procedures defined in RFC 5561. In particular, the router SHOULD advertise PW information to the protector by using the Protection FEC Element TLV, only after it has received the Egress Protection Capability TLV from the protector. It SHOULD validate each context identifier included in the TLV, and advertise the information of only those PWs that are associated with the context identifier. It SHOULD withdraw previously advertised Yimin Shen, et al. Expires January 25, 2015 [Page 19] Internet-Draft PW Endpoint Fast Failure Protection July 2014 Protection FEC TLVs, when the protector has withdrawn a previously advertised context identifier or the entire Egress Protection Capability TLV via Capability message. The encoding of the Egress Protection Capability TLV is defined as below. It conforms to the format of Capability Parameter TLV specified in RFC 5561. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Egress Protection (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ | | | ~ Capability Data = context identifier(s) ~ | | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 The U-bit MUST be set to 1 so that a receiver MUST silently ignore this TLV if unknown to it, and continue processing the rest of the message. The F-bit MUST be set to 0 since this TLV is sent only in Initialization and Capability messages, which are not forwarded. The TLV Code Point is TBD. It needs to be assigned by IANA. The S-bit indicates whether the sender is advertising (S=1) or withdrawing (S=0) the capability. The "Capability Data" is encoded with the context identifier of the {primary PE, protector}. SB> where is the structure of {primary PE, protector} defined? 5.2. PW Label Distribution from Primary PE to Protector A primary PE SHOULD advertise a primary PW's label to a protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV (see Section 5.4 for encoding), and an Upstream- Assigned Label TLV (RFC 6389) encoded with the PW's label. The combination of the Protection FEC Element TLV and the PW label represents the primary PE's forwarding state for the PW. The Label Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC Yimin Shen, et al. Expires January 25, 2015 [Page 20] Internet-Draft PW Endpoint Fast Failure Protection July 2014 6389, RFC 3471) encoded with the context identifier of the {primary PE, protector}. The protector that receives this Label Mapping message SHOULD install a forwarding entry for the PW label in the label space identified by the context identifier. The nexthop of the forwarding entry SHOULD ensure packets to be sent towards the target CE via a backup AC or a backup (S-)PE, depending on the protection scenario. The protector SHOULD silently discard a Label Mapping message if the included context identifier is unknown to it. 5.3. PW Label Distribution from Backup PE to Protector In the centralized protector model, a backup PE SHOULD advertise a backup PW's label to a protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV and a Generic Label TLV encoded with the backup PW's label. This Protection FEC Element MUST be identical to the Protection FEC Element TLV that the primary PE advertises to the protector (Section 5.2). The context identifier SHOULD NOT be encoded in Interface_ID TLV in this message. The protector that receives this Label Mapping message SHOULD associate the backup PW with the primary PW, based on the common Protection FEC Element TLV. It SHOULD distinguish between the Label Mapping message from the primary PE and the Label Mapping message from the backup PE based on the respective presence and absence of context identifier in Interface_ID TLV. It SHOULD install a forwarding entry for the primary PW's label in the label space identified by the context identifier. The nexthop of the forwarding entry SHOULD indicate a label swap to the backup PW's label, followed by a label push or IP header push for a transport tunnel to the backup PE. 5.4. Protection FEC Element TLV The Protection FEC Element TLV has type 0x83. Its format is defined as below: Yimin Shen, et al. Expires January 25, 2015 [Page 21] Internet-Draft PW Endpoint Fast Failure Protection July 2014 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(0x83) | Reserved | Encoding Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ PW Information ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 - Encoding Type Type of format that PW Information field is encoded. - Length Length of PW Information field in octets. - PW Information Field of variable length that specifies a PW For Encoding Type, 1 is defined for the PWid FEC Element format, and 2 is defined for the Generalized PWid FEC Element format (RFC 4447). 5.4.1. Encoding Format for PWid Yimin Shen, et al. Expires January 25, 2015 [Page 22] Internet-Draft PW Endpoint Fast Failure Protection July 2014 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(0x83) | Reserved | Enc Type(1) | Length(16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 - Ingress PE Address IP address of the ingress PE of PW. - Egress PE Address IP address of the egress PE of PW. SB> How does this work for IPv6? - Group ID An arbitrary 32-bit value that represents a group of PWs and that is used to create groups in the PW space. - PW ID A non-zero 32-bit connection ID that, together with the PW Type field, identifies a particular PW. - Control word bit (C) A bit that flags the presence of a control word on this PW. If C = 1, control word is present; If C = 0, control word is not present. - PW Type A 15-bit quantity that represents the type of PW. SB> Needs a ref Yimin Shen, et al. Expires January 25, 2015 [Page 23] Internet-Draft PW Endpoint Fast Failure Protection July 2014 5.4.2. Encoding Format for Generalized PWid 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(0x83) | Reserved | Enc Type(2) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 - Ingress PE Address IP address of the ingress PE of PW. - Egress PE Address IP address of the egress PE of PW. SB> IPv6? - Control word bit (C) A bit that flags the presence of a control word on this PW. If C = 1, control word is present; If C = 0, control word is not present. - PW Type A 15-bit quantity that represents the type of PW. Yimin Shen, et al. Expires January 25, 2015 [Page 24] Internet-Draft PW Endpoint Fast Failure Protection July 2014 - AGI Type, Length, Value, AGI Value Attachment Group Identifier of PW. - SAII Type, Length, Value, SAII Value Source Attachment Individual Identifier of PW. - TAII Type, Length, Value, TAII Value Target Attachment Individual Identifier of PW. 6. Revertive Behavior Subsequent to local repair, there are three strategies for the network to restore traffic to a fully functional PW. o Global revertive mode If the ingress CE is multi-homed (Figure 1), it MAY switch the traffic to a backup AC which is bound to a backup PW. Alternatively, if the ingress PE hosts a backup PW (Figure 2), the ingress PE MAY switch the traffic to the backup PW. These procedures are referred to as global repair. Possible triggers of a global repair include PW status, OAM, and BFD. o Control plane revertive mode In egress PE node protection and S-PE node protection, it is possible that the failure is limited to the link between the PLR and the primary (S-)PE, whereas the primary (S-)PE is still up. In this case, the PLR or an upstream router along the transport tunnel MAY reroute the tunnel around the failed link via an alternative path. Thus, the transport tunnel can continue to be used to carry the PW traffic to the primary (S-)PE. This procedure is driven by control plane convergence, and is referred to as control plane repair. o Local revertive mode The PLR MAY move traffic back to the primary PW, after the failure is resolved. In egress AC protection, upon detecting that the primary AC is restored, the PLR MAY start forwarding traffic over the AC again. Likewise, in egress PE node protection and S-PE node protection, upon detecting that the primary PE is restored, the PLR MAY re-establish the primary transport tunnel through the primary PE, and move the traffic from the bypass tunnel back to Yimin Shen, et al. Expires January 25, 2015 [Page 25] Internet-Draft PW Endpoint Fast Failure Protection July 2014 the transport tunnel. These procedures are referred to as local reversion. The fast protection mechanism in this document SHOULD be used in tandem with the global revertive mode. Particularly in the case of egress (S-)PE failure, if the ingress PE or the protector loses communication with the (S-)PE for an extensive period of time, the LDP session between them may go down. Consequently, the ingress PE may bring down the primary PW, or the protector may remove the forwarding entry of the primary PW label. In either case, the service will be disrupted. In other words, although the fast protection can temporarily repair traffic, control plane state may eventually be timed out if the failure persists. Therefore, it is recommended that the global revertive mode SHOULD be set up in advance, so that traffic can be moved to a fully functional backup PW shortly after the local repair. The control plane revertive mode may always happen as part of the convergence of control plane protocols. However, it is only applicable to the specific scenarios described above. The local revertive mode is optional. In the circumstances where the failure is caused by resource flapping, local reversion MAY be dampened to limit potential disruptions. Local revertive mode MAY be disabled completely by configuration. 7. IANA Considerations This document defines the encoding of the Capability Parameter TLV for the new "Egress Protection Capability" in Section 5. This would require IANA to assign a TLV Code Point to it. This document defines a new LDP Protection FEC Element TLV in Section 5. IANA has assigned the type value 0x83 to it. SB> I am very confused about what explicit actions you are asking IANA to take. Are you saying that there are no IANA actions? 8. Security Considerations The security considerations discussed in RFC 5036, RFC 5331, RFC 3209, and RFC 4090 apply to this document. SB> Are there any PW security considerations that apply? SB> This is a new PW operational mode, so I am surprised that there are no new security considerations. An early security review might be useful. From nobody Tue Jul 29 09:56:36 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213C01B28EE for ; Tue, 29 Jul 2014 09:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbBOLODJBlqU for ; Tue, 29 Jul 2014 09:56:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB351A037D for ; Tue, 29 Jul 2014 09:56:29 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB224.namprd05.prod.outlook.com (10.242.41.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 16:56:26 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Tue, 29 Jul 2014 16:56:26 +0000 From: Yimin Shen To: Alexander Vainshtein , "stbryant@cisco.com" , Yakov Rekhter , "pwe3@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqByPzRsIO8QlbkK+kbMBZ9MDf5u3AuAAgAAZ0oCAABjewA== Date: Tue, 29 Jul 2014 16:56:26 +0000 Message-ID: <04f15bedf2be4c7480d3e9ca01bdfd7f@BY2PR05MB728.namprd05.prod.outlook.com> References: <201407251524.s6PFOPn92012@magenta.juniper.net> <53D79504.4050904@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(13464003)(479174003)(189002)(199002)(37854004)(24454002)(52604005)(51704005)(252514010)(164054003)(85852003)(74662001)(74502001)(81342001)(86362001)(92566001)(105586002)(31966008)(83072002)(106116001)(19580395003)(99286002)(74316001)(95666004)(85306003)(66066001)(80022001)(15202345003)(4396001)(64706001)(101416001)(20776003)(81542001)(83322001)(50986999)(19580405001)(76176999)(76482001)(54356999)(21056001)(99396002)(87936001)(46102001)(77982001)(33646002)(15975445006)(107046002)(76576001)(2656002)(106356001)(107886001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB224; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/ww1VjiVE0nnS09oPJ6d0o0KfSW0 Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 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 Jul 2014 16:56:33 -0000 Hi Sasha, Thanks very much for the review and comments. Please see my responses inlin= e. Hope they are helpful. Thanks, /Yimin -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Tuesday, July 29, 2014 10:08 AM To: stbryant@cisco.com; Yakov Rekhter; pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protecti= on-01 Stewart, Yakov and all, I have started reading the draft, and it seems that it breaks quite a few c= ommon architectural assumptions. [yshen] This draft is fully based on the PWE3 architecture and the MS-PW ar= chitecture. The following text from Section 3.1 "Single-Segment PW" looks highly proble= matic to me: At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CEs. The AC used for the CE to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. . To the best of my order for the pair of interconnected CEs to be able to op= erate in this way each of them should treat the pair of ACs shown in Figure= 1 as a single logical entity. E.g., if we are speaking about Ethernet PWs, each CE could treat Ethernet l= inks supporting these two ACs as a single Link Aggregation Group. However, = the draft does not mention any such thing (or at least I did not find it). = =20 Do I miss something important here? [yshen] It is a logical view that the CE is dual-home to 2 PEs over 2 disti= nct ACs. AC is a concept well defined in RFC 3985. In terms of the actual P= E-CE connection in the case of Ethernet, the CE could have 2 distinct Ether= net links or 2 VLANs over a single LAG. I also wonder whether, in the single segment PW scenario, the same level of= protection could not be achieved with ICCP (RFC 7275) running between eac= h pair of PEs and, possibly with 4 (instead of 2) PWs. For the reference, = ICCP (or RFC 7275) is not mentioned in the draft, even if a possible altern= ative solution to some of the problems it solves. ( [yshen] Thanks for pointing out ICCP. We will mention it in the next revisi= on. In this draft we broadly refer to such kind of mechanism as "control pl= ane repair". The purpose of this draft is to locally repair traffic at the = failure point, in order to reduce traffic loss before ICCP or other control= plane repair mechanism kicks in. Stewart did not specify in his email which MPLS architecture principles he = thinks are broken by this draft. I think, however, that some PWE3 architectural principles are definitely ar= e broken, and this includes: - Bi-directional nature of the PW - it seems that the draft allows each a P= W be Up in one direction and Down in the other one [yshen] No, the draft does not allow that. It only says that we can send tr= affic of one direction over one PW, while sending traffic of the opposite d= irection over another PW (i.e. backup PW). Both PWs should be up bidirectio= nally. - Lack of dependencies between the PSN tunnels and the PWs they carry.=20 * Consider the network diagram shown in Figure 5 in Section 4.1 * The text suggests that the tunnel between PE1 and PE2 must recognize PE4= as the "protector" node for the PW it carries * What is supposed to happen if the tunnel between PE1 and PE2 carries, sa= y, 10 PWs, each with its own backup PE PE4-1, ... PE4-10)?=20 [yshen] In your example, the 10 PWs are protected by 10 different protector= s. In this case, you would need 10 different tunnels, destined to 10 differ= ent context IDs (one context ID per ). If multiple PWs are prot= ected by the same protector, they can be carried by the same tunnel. - Lack of dependencies between the mechanism used for the tunnel setup (LDP= , RSVP-TE, manual configuration etc.) and the PWs this tunnel carries. * Is the protection model described in Section 4.1 compatible with Tunnel = LSPs being set up by LDP? With, say, GRE tunnels carrying the PWs using MPL= S-in-GRE? [yshen] Yes, it is compatible. The draft is generic on transport layer, and= it allows tunnels to be LDP, RSVP-TE, GRE, etc. These protocols already pr= ovide sufficient machineries for setting up transport tunnels and bypass tu= nnels. Therefore, the draft doesn't require new extension to these LSP sign= aling protocols. Last but not least, I would like to understand better how the draft is prot= ecting MS-PWs against S-PE failures.=20 Specifically, I'd like to understand whether it is applicable to the case w= hen each pair of T-PEs resides in its own AS, with two pairs of directly co= nnected ASBRs between these two ASs acting as S-PEs. There would be no nee= d to set up any tunnel LSPs between each pair of S-PEs in this scenario. I would appreciate an analysis of this scenario regarding ability to protec= t about the ASBR/S-PE failure. IMO it is a relevant scenario because MS-PWs= are one of the methods to provide inter-AS services. [yshen] The MS-PW topology in this draft is based on the Figure-4 of RFC 56= 59, which is slightly different than the scenario you mentioned above. Howe= ver, the mechanism in this draft does apply to this scenario as well. It sh= ould work equally if S-PEs are one-hop or multi-hops away from each other. = Please see the picture below. In this case, SPE1 ~ SPE4 are ASBRs. When SPE= 4 detects the failure of SPE3, it will do a local repair and redirect PW tr= affic to SPE4 which is the protector. The bypass between SPE1 and SPE4 may = be a one-hop tunnel or a multi-hop tunnel, depending on the actual topology= between the 2 AS'. In any case, SPE4 will send PW traffic over a tunnel to= TPE4.=20 |<--------------- PW1 ----------->| - TPE1 -------- SPE1 - SPE3 --------- TPE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - TPE3 -------- SPE2 - SPE4 --------- TPE4 - protector |<--------------- PW2 ----------->| My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, July 29, 2014 3:35 PM > To: Yakov Rekhter; pwe3@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > On 25/07/2014 16:24, Yakov Rekhter wrote: > > Hi, > > > >> This email begins a second two week working group last call for > >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-01= . > >> > >> Please review the draft and post any comments to the PWE3 list. > >> > >> If you have read the draft, even if you don't have any comments,=20 > >> but would like to see the draft progressed, please can you=20 > >> indicate this to the > list. > >> > >> This working group last call will end on Friday August 8th, 2014. > > I would like to see the draft progressed. > > > > Yakov. > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > Yakov >=20 > Doesn't this draft implicitly make a number of extensions to the MPLS=20 > architecture? >=20 > Stewart >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Wed Jul 30 01:08:41 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAD71B29BE for ; Wed, 30 Jul 2014 01:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJQiniZU8G-D for ; Wed, 30 Jul 2014 01:08:33 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF10A1B2973 for ; Wed, 30 Jul 2014 01:08:28 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 08:08:26 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Wed, 30 Jul 2014 08:08:26 +0000 From: Alexander Vainshtein To: Yimin Shen Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqymWveYGLBru1kCsLuzIRj9tdJu3CWCAgAA8XgCAAPc/IA== Date: Wed, 30 Jul 2014 08:08:26 +0000 Message-ID: <2597291f7b074922b690e4b06999cf1a@AM3PR03MB612.eurprd03.prod.outlook.com> References: <201407251524.s6PFOPn92012@magenta.juniper.net> <53D79504.4050904@cisco.com> <04f15bedf2be4c7480d3e9ca01bdfd7f@BY2PR05MB728.namprd05.prod.outlook.com> In-Reply-To: <04f15bedf2be4c7480d3e9ca01bdfd7f@BY2PR05MB728.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(252514010)(189002)(199002)(479174003)(377454003)(37854004)(164054003)(13464003)(52604005)(24454002)(51704005)(85306003)(77982001)(95666004)(4396001)(76482001)(2656002)(81342001)(87936001)(81542001)(92566001)(76576001)(101416001)(561944003)(107046002)(76176999)(21056001)(99396002)(86362001)(93886003)(54356999)(19580395003)(83322001)(15202345003)(19580405001)(15975445006)(20776003)(74502001)(31966008)(33646002)(74662001)(110136001)(64706001)(106356001)(50986999)(80022001)(79102001)(83072002)(105586002)(66066001)(85852003)(46102001)(106116001)(74316001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/bwn-qXRbudB-nRU3ybbzWEkNCag Cc: Yakov Rekhter , "pwe3@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 08:08:39 -0000 Yimin hi, Lots of thanks for a prompt response. Unfortunately, from my point of view, the issues I've raised still remain u= nresolved. Please see additional questions inline below. Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Yimin Shen [mailto:yshen@juniper.net] > Sent: Tuesday, July 29, 2014 7:56 PM > To: Alexander Vainshtein; stbryant@cisco.com; Yakov Rekhter; > pwe3@ietf.org > Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > Hi Sasha, >=20 > Thanks very much for the review and comments. Please see my responses > inline. Hope they are helpful. >=20 >=20 > Thanks, >=20 > /Yimin >=20 >=20 >=20 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander > Vainshtein > Sent: Tuesday, July 29, 2014 10:08 AM > To: stbryant@cisco.com; Yakov Rekhter; pwe3@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > Stewart, Yakov and all, > I have started reading the draft, and it seems that it breaks quite a few > common architectural assumptions. >=20 > [yshen] This draft is fully based on the PWE3 architecture and the MS-PW > architecture. >=20 > The following text from Section 3.1 "Single-Segment PW" looks highly > problematic to me: > > At any given time, each CE sends traffic via only one AC and receives > traffic via only one AC. The two ACs MAY or MAY NOT be the same. > The AC used to send traffic is determined by the CE, and MAY rely on > an end-to-end OAM mechanism between the CEs. The AC used for the CE > to receive traffic is determined by the state of the network and the > protection mechanism in use, as described later in this document. > . >=20 > To the best of my order for the pair of interconnected CEs to be able to > operate in this way each of them should treat the pair of ACs shown in Fi= gure > 1 as a single logical entity. > E.g., if we are speaking about Ethernet PWs, each CE could treat Ethernet > links supporting these two ACs as a single Link Aggregation Group. Howeve= r, > the draft does not mention any such thing (or at least I did not find it)= . >=20 > Do I miss something important here? >=20 > [yshen] It is a logical view that the CE is dual-home to 2 PEs over 2 dis= tinct > ACs. AC is a concept well defined in RFC 3985. In terms of the actual PE-= CE > connection in the case of Ethernet, the CE could have 2 distinct Ethernet= links > or 2 VLANs over a single LAG. >=20 [[Sasha]] If I read your response correctly, each dual-homed CE treats each= if its two ACs as an individual entity. I see this is as highly problematic. E.g., consider the case when CE1 and C= E2 are two CE routers running some link-state routing protocol between them= . - In the normal situation, CE1 probably would see its two ACs as two paral= lel bi-directional links. - With PW redundancy, one of these links (one that corresponds to the curre= nt Active PW) would be Up and the other one - Down - With your proposal, the typical link-state routing protocol between CE1 a= nd CE2 would not be able to form any adjacencies across any of these links,= because this process requires bi-directional link connectivity; so regardl= ess of whatever happens in the PW domain CE1 and CE2 would consider each ot= her as unreachable across this domain. Did I miss something? (I intentionally leave aside protocols like OLSR that= can handle unidirectional links). > I also wonder whether, in the single segment PW scenario, the same level = of > protection could not be achieved with ICCP (RFC 7275) running between > each pair of PEs and, possibly with 4 (instead of 2) PWs. For the refere= nce, > ICCP (or RFC 7275) is not mentioned in the draft, even if a possible alte= rnative > solution to some of the problems it solves. ( >=20 > [yshen] Thanks for pointing out ICCP. We will mention it in the next revi= sion. > In this draft we broadly refer to such kind of mechanism as "control plan= e > repair". The purpose of this draft is to locally repair traffic at the fa= ilure point, > in order to reduce traffic loss before ICCP or other control plane repair > mechanism kicks in. [[Sasha]] I am not sure ICCP in this case would mean slow protection. Its f= unction here would be just to synchronize the state of PWs between PE1 and = PE3/PE2 and PE4, and this can be reasonably fast IMO. The Protection State = Coordination (PSC) protocol in RFC 6378 looks like an analog (with some str= etch of course), and it is supposed to provide pretty fast protection switc= hing. >=20 > Stewart did not specify in his email which MPLS architecture principles h= e > thinks are broken by this draft. >=20 > I think, however, that some PWE3 architectural principles are definitely = are > broken, and this includes: > - Bi-directional nature of the PW - it seems that the draft allows each a= PW be > Up in one direction and Down in the other one >=20 > [yshen] No, the draft does not allow that. It only says that we can send = traffic > of one direction over one PW, while sending traffic of the opposite direc= tion > over another PW (i.e. backup PW). Both PWs should be up bidirectionally. >=20 >=20 [[Sasha]] Sorry but I do not understand that. The draft discusses something= like the "egress AC failure". If, say. PE1 detects that, I expect it woul= d send a PW Status with "PW not Forwarding" and "Local AC Transmit Fault" b= its set to PE2. Would this not mean that the PW between PE1 and PE2 is Down= ? > - Lack of dependencies between the PSN tunnels and the PWs they carry. > * Consider the network diagram shown in Figure 5 in Section 4.1 > * The text suggests that the tunnel between PE1 and PE2 must > recognize PE4 as the "protector" node for the PW it carries > * What is supposed to happen if the tunnel between PE1 and PE2 > carries, say, 10 PWs, each with its own backup PE PE4-1, ... PE4-10)? >=20 > [yshen] In your example, the 10 PWs are protected by 10 different > protectors. In this case, you would need 10 different tunnels, destined t= o 10 > different context IDs (one context ID per ). If multiple PWs = are > protected by the same protector, they can be carried by the same tunnel. >=20 [[Sasha]] This looks like a non-scalable solution to me. >=20 > - Lack of dependencies between the mechanism used for the tunnel setup > (LDP, RSVP-TE, manual configuration etc.) and the PWs this tunnel carries= . > * Is the protection model described in Section 4.1 compatible with > Tunnel LSPs being set up by LDP? With, say, GRE tunnels carrying the PWs > using MPLS-in-GRE? >=20 > [yshen] Yes, it is compatible. The draft is generic on transport layer, a= nd it > allows tunnels to be LDP, RSVP-TE, GRE, etc. These protocols already prov= ide > sufficient machineries for setting up transport tunnels and bypass tunnel= s. > Therefore, the draft doesn't require new extension to these LSP signaling > protocols. >=20 [[Sasha]] Sorry but this does not match your response to my previous questi= on/issue where you have explained that you effectively need a tunnel per PW= between PE1 and PE2. RSVP-TE can provide that; but how is LDP supposed to = do that? > Last but not least, I would like to understand better how the draft is > protecting MS-PWs against S-PE failures. > Specifically, I'd like to understand whether it is applicable to the case= when > each pair of T-PEs resides in its own AS, with two pairs of directly conn= ected > ASBRs between these two ASs acting as S-PEs. There would be no need to > set up any tunnel LSPs between each pair of S-PEs in this scenario. > I would appreciate an analysis of this scenario regarding ability to prot= ect > about the ASBR/S-PE failure. IMO it is a relevant scenario because MS-PWs > are one of the methods to provide inter-AS services. >=20 > [yshen] The MS-PW topology in this draft is based on the Figure-4 of RFC > 5659, which is slightly different than the scenario you mentioned above. > [[Sasha]] Figure 4 in RFC 5659 does not say anything about inter-AS. > > However, the mechanism in this draft does apply to this scenario as well.= It > should work equally if S-PEs are one-hop or multi-hops away from each > other. Please see the picture below. In this case, SPE1 ~ SPE4 are ASBRs. > When SPE4 detects the failure of SPE3, it will do a local repair and redi= rect PW > traffic to SPE4 which is the protector. The bypass between SPE1 and SPE4 > may be a one-hop tunnel or a multi-hop tunnel, depending on the actual > topology between the 2 AS'. > [[Sasha]] This approach can work if SPE1 is directly connected to SPE4 beca= use in this case there would be no need for a tunnel LSP between them.=20 I do not see a simple way to set up an LSP between SPE1 (in AS-1) and SPE4(= in AS-2) if such connectivity is not present; could you possibly expand on = how this is supposed to happen? > > In any case, SPE4 will send PW traffic over a > tunnel to TPE4. >=20 > |<--------------- PW1 ----------->| >=20 > - TPE1 -------- SPE1 - SPE3 --------- TPE2 - > / PLR \ \ > / \ \ > CE1 bypass\ CE2 > \ \ / > \ \ / > - TPE3 -------- SPE2 - SPE4 --------- TPE4 - > protector >=20 > |<--------------- PW2 ----------->| >=20 > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 > > -----Original Message----- > > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Tuesday, July 29, 2014 3:35 PM > > To: Yakov Rekhter; pwe3@ietf.org > > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > > protection-01 > > > > On 25/07/2014 16:24, Yakov Rekhter wrote: > > > Hi, > > > > > >> This email begins a second two week working group last call for > > >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-= 01 . > > >> > > >> Please review the draft and post any comments to the PWE3 list. > > >> > > >> If you have read the draft, even if you don't have any comments, > > >> but would like to see the draft progressed, please can you > > >> indicate this to the > > list. > > >> > > >> This working group last call will end on Friday August 8th, 2014. > > > I would like to see the draft progressed. > > > > > > Yakov. > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > Yakov > > > > Doesn't this draft implicitly make a number of extensions to the MPLS > > architecture? > > > > Stewart > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From nobody Wed Jul 30 12:08:11 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A251A0397; Wed, 30 Jul 2014 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNPhve0D48yt; Wed, 30 Jul 2014 12:07:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3DF1A0340; Wed, 30 Jul 2014 12:07:57 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB727.namprd05.prod.outlook.com (10.141.223.23) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 19:07:48 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Wed, 30 Jul 2014 19:07:48 +0000 From: Yimin Shen To: "stbryant@cisco.com" , pwe3 , "pwe3-chairs@tools.ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqzzbzRsIO8QlbkK+kbMBZ9MDf5u4teQw Date: Wed, 30 Jul 2014 19:07:46 +0000 Message-ID: References: <53D7B569.60400@cisco.com> In-Reply-To: <53D7B569.60400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(37854004)(13464003)(189002)(199002)(377454003)(164054003)(21056001)(54356999)(50986999)(106356001)(19580405001)(92566001)(83072002)(85852003)(101416001)(85306003)(99286002)(106116001)(76576001)(107046002)(77982001)(79102001)(74316001)(2656002)(83322001)(46102001)(76482001)(4396001)(81542001)(74502001)(15975445006)(95666004)(81342001)(64706001)(76176999)(66066001)(87936001)(86362001)(19580395003)(31966008)(33646002)(99396002)(20776003)(80022001)(74662001)(24736002)(108616003)(579004)(559001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB727; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/A1Xg6YE2JweeS5cohX2d6TEOeDE Cc: "mpls@ietf.org" Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:08:06 -0000 Hi Stewart, Thanks very much for the detailed review and comments. I'd like to highligh= t a few things below about this draft, and then respond to your comments in= line. Hope you could give the draft another closer look. [1] This draft is completely based on the PWE3 and the MS-PW architecture. = It is also based on RFC 5331 " MPLS Upstream Label Assignment and Context-S= pecific Label Space". So ideally readers should be familiar with that RFC. [2] The draft mentions two important roles of routers, PLR (point of local = repair) and protector.=20 [3] PLR performs local repair in dataplane, based on pre-installed backup f= orwarding state pointing to a bypass tunnel. There is no control-plane invo= lvement in local repair. This is similar to the existing IP/MPLS fast-rerou= te mechanisms. Therefore, it can achieve restore traffic with a similar per= formance to those mechanisms. That is the main goal of this draft. [4] When doing local repair, the PLR only swaps the top label (i.e. tunnel = label) to a bypass tunnel's label, and keeps the PW label (allocated by pri= mary/protected PE) intact. The PLR doesn't need to know or understand the P= W label. [5] The protector is the router at the other end of the bypass tunnel. It i= s responsible for forwarding the traffic further, so that the traffic can e= ventually reach the target CE. The protector must understand the PW label a= llocated by the primary PE. This is achieved by using the context label for= warding paradigm specified in RFC 5331. This draft defines some LDP extensi= ons to allow the primary PE to advertise PW labels to the protector. The pr= otector locally maintains a label space for these PW labels of the protecte= d PE, and looks up the PW label in this label space. The bypass tunnel serv= es as the pointer to this label space. [6] This draft also introduces the concept of "context ID". A context ID is= an IP address identifying a pair of . It serves a= s the destination of transport tunnel. PWs carried by the tunnel will be re= directed to the protector X during local repair. PWs to the same primary PE= but protected by a different protector Y cannot be carried by this tunnel.= Rather, they must be carried by a tunnel destined for context ID of . [7] A PLR may be any router in the network, including P or PE router. The d= raft assumes that it doesn't know or care about PW info. [8] A protector is a PE router in the "co-located" model. It may be a P rou= ter in the "centralized" model. For the later case, the draft describes how= to use the new LDP extensions for the protector to learn and assoicate pri= mary PW and backup PW and install forwarding entries in the context label t= able. Thanks, /Yimin -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Tuesday, July 29, 2014 10:53 AM To: pwe3; pwe3-chairs@tools.ietf.org Cc: mpls@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protecti= on-01 I do not support the publication of this draft without: 1) An assurance that MPLS WG has reviewed it and is happy with the extensions that seem to be made to the MPLS architecture 2) A formal description of those extensions or a pointer to those extensions in another RFC. 3) Significant clarification of how the detail of this mechanism works. For this to work you need to have co-ordinated label spaces in multiple PEs which is something that was investigated by the SPRING WG and found not to work, particularly when different manufacturers equipments were involved. [yshen] This draft does not rely on label space coordination. Rather, it is= based on context label forwarding paradigm specified in RFC 5331.=20 As far as I can see you also need to peek below the top of stack to do a fast reroute operation which is not a currently defined MPLS operation. There seem to be a lot of details and clarifications missing that need to be provided, and I am not entirely convinced that all of the items declared out of scope are legitimately out of scope and not needed in order for a multi-vendor solution to be implemented. It would be useful to me (and I suspect to other readers) to see what the dataplane looks like at various points in the normal and repair path to verify that all parties have the right information for this to work under normal and various fault conditions. I have a number of comments inline that need to be addressed before this can proceed. - Stewart PW Endpoint Fast Failure Protection draft-ietf-pwe3-endpoint-fast-protection-01 Abstract This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Designed on the basis of multi-homed CE, PW redundancy, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. In particular, the router can restore PW traffic in the order of tens of milliseconds, SB> Not sure it's wise to specify a performance claim in a standards SB> track RFC. [yshen] If this is viewed as inappropriate, we can remove it. by transmitting the traffic to a protector through a pre-established bypass tunnel. Therefore, the mechanism can reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. =3D=3D=3D 1. Introduction Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment can be thought of as a connection between a pair of forwarders hosted by two PEs, carrying an emulated layer-2 service over a packet switched network (PSN). In the single-segment PW (SS-PW) case, a forwarder binds a PW to an attachment circuit (AC). In the multi- segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW segment to an AC, while a forwarder on a switching PE (S-PE) binds one PW segment to another PW segment. In each direction between the PEs, PW packets are transported by a PSN tunnel, which is called a transport tunnel. SB> Did we ever your the term transport tunnel before? [yshen] This is mainly for clarity. We could change it to " which is called a transport tunnel *in this document*". Or we can completely rep= lace "transport tunnel" with just "tunnel". 3. Reference Models and Failure Cases The mechanism in this document intends to use these topologies for local repair purposes. SB> The toplology is not a mechanism. Are you saying that the mechanims SB> only works in this topology? [yshen] No, these topologies are only examples for use by subsequent sectio= ns to describe the mechanisms. The mechanisms should equally work for other= topologies as well. This SHALL enable local repair and global repair to work in tandem to achieve broader coverage of protection for services. SB> I have no idea how a SHALL in capitals applies here. [yshen] Will fix this. 3.1. Single-Segment PW |<-------------- PW1 --------------->| - PE1 -------------- P1 ---------------- PE2 - / \ / \ CE1 CE2 \ / \ / - PE3 -------------- P2 ---------------- PE4 - |<-------------- PW2 --------------->| Figure 1 Each CE is multi-homed to two PEs. Hence, there are two divergent paths between the CEs. SB> It does not follow that the paths are divergent! Who knows SB> what happens in the IP layer and the underlying transport SB> network. [yshen] We could rephrase this and remove "divergent". All we want to say h= ere is that there are two distinct sets of AC-PW-AC between the CEs. At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. SB> May not be the same what? If they are actually the same AC you SB> have no redundancy. [yshen] Will rephrase it. All we want to say is that at a given time, the C= E may send traffic over one AC and receive traffic over another AC. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CEs. The AC used for the CE to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. From the perspective of traffic flowing towards a given CE, the set of PWs, PEs and ACs involved can be viewed to serve primary and backup (or active and standby) roles. When the network is in a steady state, the PW that is intended to carry the traffic is referred to as a primary PW. The PE at the egress of the primary PW is a primary PE. The AC connecting the CE and the primary PE is a primary AC. The other PW may be used to carry the traffic upon a network failure, and is referred to as a backup PW. The PE at the egress of the backup PW is a backup PE. The AC connecting the CE and the backup PE is a backup AC. In this document, the following primary and backup roles are assigned for the traffic going from CE1 to CE2: Primary PW: PW1 Yimin Shen, et al. Expires January 25, 2015 [Page 5] Internet-Draft PW Endpoint Fast Failure Protection July 2014 Primary PE: PE2 Primary AC: CE2-PE2 Backup PW: PW2 Backup PE: PE4 Backup AC: CE2-PE4 In this case, an egress AC failure refers to the failure of the AC CE2-PE2. An egress node failure refers to the failure of PE2. The backup PE, backup PW and backup AC may be used to carry traffic after a PW endpoint failure, when CE1 and CE2 switches traffic to PW2 in local repair or global repair, as described later in this document. |<-------------- PW1 --------------->| ------------- P1 ---------------- PE2 - / \ / \ CE1 -- PE1 CE2 \ / \ / ------------- P2 ---------------- PE4 - |<-------------- PW2 --------------->| Figure 2 Figure 2 shows another possible scenario, where CE1 is single-homed to PE1, while CE2 remains multi-homed to PE2 and PE4. From the perspective of egress protection for the traffic from CE1 to CE2, this topology is not much different than Figure 1. However, for the SB> "not much different than Figure 1" is not helpful, either it is the same, or you need to explain the difference. [yshen] Will rephrase. The difference is actually described after "However.= ..". traffic in the direction from CE2 to CE1, PE1 must anticipate traffic on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. SB> What does it mean to anticipate traffic. [yshen] To anticipate incoming traffic over either PW1 or PW2. Will rephras= e. 3.2. Multi-Segment PW Yimin Shen, et al. Expires January 25, 2015 [Page 6] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 -------------- SPE1 --------------- TPE2 - / \ / \ CE1 CE2 \ / \ / - TPE3 -------------- SPE2 --------------- TPE4 - |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 3 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW environment. PW1 and PW2 are both MS-PWs. PW1 is established between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at SPE1. PW2 is established between TPE3 and TPE4, and switched between segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW segments are not shown in this figure for clarity. In this document, the following primary and backup roles are assigned for the traffic going from CE1 to CE2: Primary PW: PW1 Primary T-PE: TPE2 Primary S-PE: SPE1 Primary AC: CE2-TPE2 Backup PW: PW2 Backup T-PE: TPE4 Backup S-PE: SPE2 Backup AC: CE2-TPE4 In this case, an egress AC failure refers to the failure of the AC CE2-TPE2. An egress node failure refers to the failure of TPE2. An S-PE failure refers to the failure of SPE1. Yimin Shen, et al. Expires January 25, 2015 [Page 7] Internet-Draft PW Endpoint Fast Failure Protection July 2014 The backup T-PE, backup PW and backup AC are used for protecting the primary PW against egress AC failure and egress node failure. The backup S-PE and the backup PW are used for protecting the primary PW against S-PE failure, as described later in this document. For consistency with the SS-PW scenario, primary T-PEs and a primary S-PEs may simply be referred to as primary PEs in this document, where specifics is not required. Similarly, backup T-PEs and backup S-PEs may be referred to as backup PEs. 4. Theory of Operation The fast protection mechanism in this document provides three types of protection for PWs, corresponding to the three types of failures described in Section 1. a. Egress AC protection b. Egress (T-)PE node protection c. S-PE node protection The mechanism assumes a multi-homed CE with connectivity to a primary PE and a backup PE, and the existence of a backup PW in the network. In S-PE node protection, it also assumes the existence of a backup S-PE on the backup PW. SB> Do the PWs need to be symmetric - could you have more S-PEs on one that you have on the other? [yshen] You could. For a given S-PE, as long as you can find another PE to = serve as protector, it will work.=20 4.1. Local Repair and Protector The mechanism relies on local repair to be performed by routers SB> Do you mean routers or PEs? Routers of more likely LSRs operate at a different layer and have no business knowing about PWs. [yshen] routers (LSRs). Yes, they have no idea about PWs. This draft doesn'= t assume they know or care about PWs. SB> Has this work been reviewed my MPLS WG? I am concerned that you are doing a bunch of layer violation without explaining the how this is achieved or whether it is acceptable within the MPLS architecture. [yshen] There is no layer violation. The PLR simply redirect traffic from t= he original tunnel to a bypass tunnel, by doing a top label swap, without t= ouching, changing or knowing the PW label. Please take a close look at the = text. upstream adjacent to failures. Each of these routers is referred to as a "point of local repair" (PLR). A PLR MUST be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In anticipation of the failure, the PLR MUST also pre-establish a bypass PSN tunnel to a "protector", and pre-install a bypass route in the data plane. The bypass tunnel MUST have the property that it will not be affected by the topology changes in the event of the failure. SB> This is far too imprecise - you need to separate operations and topologies in the PW layer from operations and topologies in the PSN layer [yshen] Similar to existing IP/MPLS fast-reroute RFCs, this draft doesn't r= estrict local repair trigger to any specific failure detection mechanisms. = Any mechanism will work.=20 SB> In each case you need to be clear how you are detecting failure by specifying the MEPs and MIPs you are testing. Upon detecting the failure, the PLR MUST invoke the bypass route in the data plane, and reroute PW traffic to the protector through the bypass tunnel. The protector MUST in turn send the traffic to the target CE. SB> No the protector knows nothing about CEs - they are in the client layer, and you can only protect at the server layer or the server's server layer. [yshen] In collocated model, the protector is a PE. In the centralized mode= l, the protector may be an LSR , and it needs to participate in LDP PW sign= aling to understand PWs. See the related sections and LDP extensions in thi= s draft. This centralized model is optional. This procedure is referred to as local repair. Different routers may serve as PLR and protector in different scenarios. SB> Remember they are not routers - they are xPEs or LSRs. [yshen] Again, in collocated model, the protector is a PE. In the centraliz= ed model, the protector may be an LSR , and it needs to participate in LDP = PW signaling to understand PWs. See the related sections and LDP extensions= in this draft. But this centralized model is optional. [yshen] PLRs may be LSRs, but they don't need to know PWs, because all they= do is to swap top label (tunnel label) to a bypass tunnel's label. SB> In each of the following we need to note that these are not RFC3985 PEs, even if they take no part in the protection such as the PEs on the left. Indeed I am wondering if you need to update RFC3985 and RFC5659 [yshen] There is no need to update RFC3985 and RFC5659. Yimin Shen, et al. Expires January 25, 2015 [Page 8] Internet-Draft PW Endpoint Fast Failure Protection July 2014 o In egress AC protection, the PLR is the primary PE that terminates the primary PW and hosts the primary AC, and the protector is the backup PE (Figure 4). |<-------------- PW1 --------------->| - PE1 -------------- P1 ---------------- PE2 - / PLR \ / | \ CE1 bypass| CE2 \ | / \ | / - PE3 -------------- P2 ---------------- PE4 - protector |<-------------- PW2 --------------->| Figure 4 o In egress PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW, and the protector is the backup PE (Figure 5). |<-------------- PW1 --------------->| - PE1 -------------- P1 ------- P3 ----- PE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - PE3 -------------- P2 ---------------- PE4 - protector |<-------------- PW2 --------------->| Figure 5 SB> Note that it is nothing like as clean as this, if as you later have, some of P3's traffic needs to go to PE4 and some to PE5. Also what about the [yshen] Note that we are talking about a single PW, rather than multiple PW= s carried by a single tunnel. o In S-PE node protection, the PLR is the penultimate hop router of the transport tunnel of the primary PW segment, and the protector is the backup S-PE (Figure 6). Yimin Shen, et al. Expires January 25, 2015 [Page 9] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - protector |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 6 A PLR can realize its role based on configuration or the signaling of transport tunnel. For example, in the case where the transport tunnel is signaled by RSVP, the penultimate hop router could realize SB> Could realize is not sufficient. The mechanism needs to be=20 unconditional. [yshen] Will rephrase. that it is the PLR for egress (T-)PE or S-PE failure based on the RRO in Resv message, which should indicate that the router is one hop away from the PE. The detail of how this could be achieved on a per- protocol basis is out of the scope of this document. SB> So where is it in scope? How do I find out how to do it? In all scenarios, when a PLR reroutes traffic through a bypass tunnel to a protector during local repair, it MUST keep the label of the primary PW intact in the packets. This obviates the need for the PLR to maintain bypass routes on a per-PW basis, and allows a single bypass tunnel to carry traffic for multiple PWs. SB> OK, but didn't I read something about PE protecting subsets of the egress traffic of other PEs? How would that work without per PW information= ? [yshen] PWs to a given PE may be protected by multiple protectors. A set of= PWs sharing the same protector X can be carried by the same tunnel (destin= ed to the context ID of ). PWs protected by a different prot= ector Y must be carried by different tunnel (destined to the context ID of = ). The PLR of each tunnel doesn't need to know PW info. All = it does is to swap tunnel label to a bypass tunnel's label, and the bypass = tunnel will guide the traffic to the intended protector. The procedure also requires that the protector SHOULD be able to forward the traffic based on a PW label that is assigned by the primary PE, and ensure the traffic to eventually reach the target CE. From the protector's perspective, this PW label is an upstream assigned label (RFC 5331). SB> .. but the protector may be a P router and know nothing about PWs. [yshen] Again, in collocated model, the protector is a PE. In the centraliz= ed model, the protector may be an LSR , and it needs to participate in LDP = PW signaling to understand PWs. See the related sections and LDP extensions= in this draft. But this centralized model is optional. To accomplish this, the protector SHOULD learning the PW label from the primary PE prior to the failure, and install proper forwarding state for the PW label in a dedicated label space for the primary PE. SB> This is a new PE to P router protocol [yshen] The LDP extension is defined in a subsequent section. During local repair, the protector SHOULD perform PW label lookup in this label space. SB> This has to be signed off by MPLS WG SB> How can this only be a SHOULD - why is it not a MUST? [yshen] Will rephrase. SB> What do you do to ensure that they even have compatible label managers? [yshen] The LDP extensions defined in this draft covers how to negotiate th= e capability. SB> Doesn't this mean a P router looking up two labels to do the repair? [yshen] PLR only swaps the top label (i.e. tunnel label) to bypass label ta= ble, when doing the local repair. The above examples have shown the scenarios where the protectors are backup (T/S-)PEs. In other scenarios, a protector may be a dedicated router that assumes such role, separate from the backup (T/S-)PE of a primary PW. During local repair, the PLR MUST still reroute traffic to the protector through a bypass tunnel. The protector MUST in turn send the traffic to the backup (T/S-)PE, which MUST then send the Yimin Shen, et al. Expires January 25, 2015 [Page 10] Internet-Draft PW Endpoint Fast Failure Protection July 2014 traffic to the target CE via a backup AC or a backup PW segment. More detail will be described in Section 4.3. 4.2. Context Identifier A protector MAY protect multiple primary PEs. SB> This requires that a P router knows about PWs - how does it do that? [yshen] The protector will perform context label forwarding. The bypass tun= nel points to a context label table, and the protector looks up the PW labe= l in that table. The protector MUST maintain a separate label space for each primary PE. Likewise, the PWs terminated on a primary PE MAY be protected by multiple protectors, each for a subset of the PWs. In any case, a given primary PW SHOULD be associated with one and only one pair of {primary PE, protector}. An IPv4/v6 address is assigned to each ordered pair of {primary PE, protector} to facilitate protection establishment. This address is referred to as a "context identifier". It MUST be globally unique, or unique in the address space of the network where the primary PE and the protector reside. SB> I think you need to make clear that this is not backwards compatible with existing PW PEs. [yshen] PEs will need to support the extensions defined by this draft. SB> You also need to explain how the IP based context identifier mechanism works. Is it in the control plane or the data plane? 4.2.1. Semantics The semantics of a context identifier is twofold. o It identifies a primary PE and an associated protector. In other words, it identifies a primary PE on a per protector basis. A given primary PE may be protected by multiple protectors, each for a subset of the primary PWs terminated on the primary PE. A distinct context identifier MUST be assigned to the primary PE and each protector. For each primary PW, its ingress PE MUST set up or resolve a transport tunnel with destination as the context identifier of the {primary PE, protector}, rather than a private IP address of the primary PE. This not only allows the transport tunnel to reach the primary PE, but also conveys the identity of the protector to the PLR(s) along the transport tunnel. Each PLR can in turn use this information to set up a bypass tunnel to the protector without relying on local configuration. o It indentifies the primary PE's label space on the protector. The protector may protect PWs for multiple primary PEs. For each primary PE, it MUST maintain a separate label space to store the PW labels assigned by that primary PE. It MUST associate a PW label with a label space via the context identifier of the {primary PE, protector}, as described below. SB> Is this context identifier an IP address or an MPLS label? Where is it carried? [yshen] a context identifier is an IP address. If the tunnel is IP tunnel, = it is carried in IP header as dest address. If the tunnel is MPLS tunnel, i= t is indicated by the label. In addition to the normal LDP PW signaling, the primary PE MUST have a targeted LDP session with the protector, and advertise PW labels to the protector via LDP Label Mapping messages (See Yimin Shen, et al. Expires January 25, 2015 [Page 11] Internet-Draft PW Endpoint Fast Failure Protection July 2014 Section 5 for detail). The primary PE MUST attach the context identifier to each message. Upon receiving the message, the protector MUST install the advertised PW label in the label space identified by the context identifier. SB> I am currently confused about how a data packet carries the PW label provided by another PE. When a PLR sets up or resolve a bypass tunnel to the protector, it MUST set the destination to the context identifier, rather than a private IP address of the protector. Once established, the bypass tunnel, with either its MPLS label or IP tunnel destination address, is used as the identifier of label space. On the protector, all PW packets received on the bypass tunnel MUST be forwarded based on a label lookup in that label space. SB> I do not understand the data plane structure that the above sentence is describing. [yshen] This is basically the context label forwarding paradigm (RFC 5331).= From the protector's perspective, the bypass tunnel serves as a context, a= nd indicates the label space of the primary PE where the PW label must be l= ooked up. 4.2.2. Advertisement and Path Computation Using a context identifier as destination for both transport tunnel and bypass tunnel requires both the primary PE and the protector to advertise the context identifier via IGP as an IP address reachable through both routers in routing domain and/or TE domain. This imposes the following requirements on path computation for these tunnels. o For the transport tunnel, the ingress PE MUST choose the primary PE as the actual endpoint. o For the bypass tunnel, the PLR MUST choose the protector as the actual endpoint. In egress (T-)PE node protection and S-PE node protection, the bypass tunnel MUST avoid the primary (S-)PE. The detail of how the primary PE and the protector may advertise a context identifier is independent of this mechanism and out of the scope of this document. SB> Given that you give signalling data structures later, I am confused as to how this can be out of scope of this text. Surely this is needed to implement an interoperable solution? [yshen] There is no new extension needed for IGP. Both PEs advertise the co= ntext ID. That's it. Will rephrase it. One approach would be to advertise it as a virtual proxy node connected to both routers, with the link between the proxy node and the primary PE having a more preferable IGP or TE metric than the link between the proxy node and the protector. The ultimate goal is for a path computation algorithm, such as CSPF (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP- FRR-MRT]), to be able to compute the paths that meet the above requirements. 4.3. Protection Models There are two protection models based on the location of a protector. A network MAY use either model, or a combination of both. Yimin Shen, et al. Expires January 25, 2015 [Page 12] Internet-Draft PW Endpoint Fast Failure Protection July 2014 4.3.1. Co-located Protector In this model, the protector is a backup PE that is directly connected to the target CE via a backup AC, or it is a backup S-PE on a backup PW. That is, the protector is co-located with the backup (S-)PE. Examples of this model have been introduced in Figure 4, Figure 5 and Figure 6 in Section 4.1. In egress AC protection and egress PE node protection, when a protector receives traffic from the PLR, it forwards the traffic to the CE via the backup AC. This is shown in Figure 7, where PE2 is the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 (the backup PE) is the protector. |<-------------- PW1 --------------->| - PE1 -------------- P1 ------- P3 ----- PE2 ---- / PLR \ PLR \ / \ | \ CE1 bypass\ |bypass CE2 \ \ | / \ \ | / - PE3 -------------- P2 ---------------- PE4 ---- protector |<-------------- PW2 --------------->| Figure 7 In S-PE node protection, when a protector receives traffic from the PLR, it MUST forward the traffic via the next segment of the backup PW. The T-PE of the backup PW MUST in turn forward the traffic to the CE via a backup AC. This is shown in Figure 8, where P4 is the PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector for SPE1. Yimin Shen, et al. Expires January 25, 2015 [Page 13] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ CE1 bypass\ CE2 \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - protector |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 8 In the co-located protector model, the number of context identifiers needed by a network is the number of distinct {primary PE, backup PE} pairs. From the perspective of scalability, the model is suitable for networks where the number of backup PEs for any given primary PE is relatively small. 4.3.2. Centralized Protector In this model, the protector is a dedicated P router or PE router that serves the role. In egress AC protection and egress PE node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In S-PE node protection, the protector MAY or MAY NOT be a backup S-PE on the backup PW. In egress AC protection and egress PE node protection, when the protector receives traffic from the PLR, if the protector has a direct connection (i.e. backup AC) to the CE, it MUST forward the traffic to the CE via the backup AC, which is similar to Figure 7. Otherwise, it MUST forward the traffic to a backup PE, which MUST then forward the traffic to the CE via a backup AC. This is shown in Figure 9, where the protector receives traffic from P3 (the PLR for egress PE failure) or PE2 (the PLR for egress AC failure) and forwards the traffic to PE4 (the backup PE). The protector may be protecting other PWs as well, which is not shown in this figure for clarity. SB> If you are going to cover the shared case, I think you need to make it much clearer how the PWs are identified from the received data packets. Yimin Shen, et al. Expires January 25, 2015 [Page 14] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<------------- PW1 --------------->| - PE1 ------------- P1 ------- P3 ----- PE2 -- / PLR \ PLR \ / \ / \ / bypass\ /bypass \ / \ / \ CE1 protector CE2 \ \ / \ \ / \ \ / \ \ / - PE3 ------------- P2 -----------------PE4 -- |<------------- PW2 --------------->| Figure 9 In S-PE node protection, when the protector receives traffic from the PLR, if the protector is a backup S-PE of the backup PW, it MUST forward the traffic via the next segment of the backup PW, and the T-PE of the backup PW MUST forward the traffic to the CE via a backup AC, which is similar to Figure 8. Otherwise, the protector MUST first forward the traffic to the backup S-PE, which MUST then forward the traffic via the next segment of the backup PW. Finally, the T-PE of the backup PW MUST forward the traffic to the CE via a backup AC. This is shown in Figure 10, where the protector forwards traffic to SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4, and TPE4 finally forwards traffic to CE2. The protector may be protecting other PW segments as well, which is not shown in this figure for clarity. Yimin Shen, et al. Expires January 25, 2015 [Page 15] Internet-Draft PW Endpoint Fast Failure Protection July 2014 |<--------------- PW1 --------------->| |<----- SEG1 ----->|<----- SEG2 ----->| - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - / PLR \ \ / \ \ / bypass\ \ / \ \ CE1 protector CE2 \ \ / \ \ / \ \ / \ \ / - TPE3 --------------- SPE2 -------------- TPE4 - |<----- SEG3 ----->|<----- SEG4 ----->| |<--------------- PW2 --------------->| Figure 10 The centralized protector model provides the convenience for multiple primary PEs to share one protector. Each primary PE MAY only need the one protector to protect all of its PWs. From the perspective of scalability, the number of context identifiers needed by a network MAY be bound to the number of primary PEs. 4.4. Transport Tunnel The ingress PE of a primary PW associates the PW with the primary egress PE through LDP signaling. In addition, as mentioned in Section 4.2.1, the ingress PE MUST associate the transport tunnel of the PW with the context identifier of the {primary PE, protector}, and set up or resolve the transport tunnel by using the context identifier as destination. This not only ensures that PW traffic be transported to the primary PE, but also facilitates bypass tunnel establishment at PLR(s), as the context identifier implies the identity of the protector as well. This is also the case for a multi-segment PW, where the ingress PE and egress PE are T/S-PEs. The association between the transport tunnel and the context identifier at the ingress PE MAY be achieved by configuration or an auto-discovery mechanism. In the later case, the ingress PE MAY learn the context identifier from the primary (egress) PE, if the primary PE advertises the context identifier as "third party next hop" in IPv4/v6 Interface_ID (RFC 3471, RFC 3472) in the LDP Label Mapping message of the primary PW. Yimin Shen, et al. Expires January 25, 2015 [Page 16] Internet-Draft PW Endpoint Fast Failure Protection July 2014 4.5. Bypass Tunnel A PLR may protect multiple PWs associated with one or multiple pairs of {primary PE, protector}. The PLR MUST establish a bypass tunnel to each protector for each distinct context identifier associated with that protector. The destination of the bypass tunnel MUST be the context identifier (Section 4.2.1). The PLR may derive the context identifier from the destination of the transport tunnel that traverses it. For examples, in Figure 7 and Figure 9, a bypass tunnel is established from PE2 (PLR for egress AC failure) to the protector, and another bypass tunnel is established from P3 (PLR for egress node failure) to the protector. In Figure 8 and Figure 10, a bypass tunnel is established from P4 (PLR for S-PE failure) to the protector. During local repair, the PLR reroutes traffic to the protector through a bypass tunnel with PW label intact in the packets. This normally involves pushing a label to the label stack, if the bypass tunnel is an MPLS tunnel, or pushing an IP header to the packets, if the bypass tunnel is an IP tunnel. SB> Surely it is normally a swap? [yshen] yes, this is just a label swap of the top label, from tunnel label = to bypass tunnel label. SB> I am somewhat confused about what this all looks like when this is IP. The only PS/IP other than for SATOP are defined by L2TPv3 WG. There is no IP MS-PW definition that I am aware of. I think you need to be much clearer about what is going on when you discuss PW over IP=20 egress repair. The protector MUST in turn forward the traffic based on the PW label. To achieve such kind of forwarding, the protector MUST rely on the bypass tunnel as a context to determine the primary PE's label space. If the bypass tunnel is an MPLS tunnel, the protector MUST have assigned a non-reserved label to the bypass tunnel during the establishment of the bypass tunnel, and hence this label can serve as the context. If the bypass tunnel is an IP tunnel, the protector can simply rely on the context identifier carried as the destination address in IP header. A bypass tunnel MUST have the property that it is not affected by the topology changes caused by the failure. Therefore, it can be used to transmit traffic for local repair. It SHOULD remain effective, until the traffic is moved to another fully functional egress AC, PW and/or transport tunnel. 4.6. Forwarding State on Protector A protector MUST learn PW labels from all the primary PEs that it protects (Section 5.2), and maintain the PW labels in respective label spaces of the primary PEs. In the control plane, a label space is identified by the context identifier of a pair of {primary PE, protector}. In the forwarding plane, it is indicated by the bypass tunnel(s) destined for the context identifier. SB> Are you saying that this mechanism mandates no PHP? [yshen] It mandates PHP for bypass tunnels only, as their labels serve as c= ontexts on protectors. This is not mandatory for normal tunnels. Yimin Shen, et al. Expires January 25, 2015 [Page 17] Internet-Draft PW Endpoint Fast Failure Protection July 2014 4.6.1. Examples of Co-located Protector In Figure 7, PE4 is a co-located protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, PE4}. It learns PW1's label from PE2, and installs an forwarding entry for the label in that label space. The nexthop of the forwarding entry indicates a label pop with outgoing interface pointing to the backup AC CE2-PE4. SB> I am not sure what you are describing in the above. Is this an MPLS operation or a PW operation. If the latter it is not a simple label pop. [yshen] It is PW label pop.=20 In Figure 8, SPE2 is a co-located protector that protects PW1 against S-PE failure. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, SPE2}. It learns SEG1's label from SPE1, and installs a forwarding entry in the label space. The nexthop of the forwarding entry indicates a label swap to SEG4's label. 4.6.2. Examples of Centralized Protector In the centralized protector model, for each primary PW of which the protector is not a backup (S-)PE, the protector MUST also learn the label of the backup PW from the backup (S-)PE (Section 5.3). This is the backup (S-)PE that the protector will forward traffic to. The protector MUST install a forwarding entry with label swap from the primary PW's label to the backup PW's label. In Figure 9, the protector is a centralized protector that protects PW1 against egress AC failure and egress node failure. It maintains a label space for PE2, which is identified by the context identifier of {PE2, protector}. It learns PW1's label from PE2, and PW2's label from PE4. It installs a forwarding entry for PW1's label in the label space. The nexthop of the forwarding entry indicates a label swap to PW2's label. In Figure 10, the protector is a centralized protector that protects the PW segment SEG1 of PW1 against the node failure of SPE1. It maintains a label space for SPE1, which is identified by the context identifier of {SPE1, protector}. It learns SEG1's label from SPE1, and learns SEG3's label from SPE2. It installs a forwarding entry for SEG1's label in the label space. The nexthop of the forwarding entry indicates a label swap to SEG3's label. 5. LDP Extensions As described in previous sections, a targeted LDP session MUST be established between each pair of primary PE and protector. The primary PE sends Label Mapping message over this session to advertise primary PW labels to the protector. In the centralized protector Yimin Shen, et al. Expires January 25, 2015 [Page 18] Internet-Draft PW Endpoint Fast Failure Protection July 2014 model, a targeted LDP session MUST also be established between a backup (S-)PE and a protector. The backup PE sends Label Mapping message over this session to advertise backup PW labels to the protector. To facilitate the procedures, this document defines a new "Protection FEC Element" TLV. The Label Mapping messages of both the LDP sessions above MUST carry this TLV to indicate the identity of a primary PW. Specifically, in the centralized protector model, the Protection FEC Element TLV advertised by a backup (S-)PE MUST match the one advertised by the primary PE, so that the protector can associate the primary PW's label with the backup PW's label, and perform a label swap. This document also defines the encoding of Capability Parameter TLV (RFC 5561) for a new "Egress Protection Capability", to allow a protector to announce its capability of processing the above Protection FEC Element TLV and performing context specific label switching for PW labels. The procedures in this section are only applicable, if the protector advertises the Egress Protection Capability, the primary PE supports the advertisement of the Protection FEC Element TLV, and in the centralized protector model, the backup PE also supports the advertisement of the Protection FEC Element TLV. 5.1. Egress Protection Capability TLV A protector MUST advertise the Egress Protection Capability TLV in its Initialization message and Capability message, over the LDP session with a primary PE. In the centralized protector model, the protector MUST also advertise the TLV over the LDP session with a backup PE. The TLV carries one or multiple context identifiers. To the primary PE, the TLV SHOULD carry the context identifier of the {primary PE, protector}. In the centralized protector model, the TLV SHOULD carry to the backup PE multiple context identifiers, one for each {primary PE, protector} where the backup PE serves as a backup for the primary PE. This TLV SHOULD NOT be advertised by the primary PE or the backup PE to the protector. The processing of the Egress Protection Capability TLV by a receiving router SHOULD follow the procedures defined in RFC 5561. In particular, the router SHOULD advertise PW information to the protector by using the Protection FEC Element TLV, only after it has received the Egress Protection Capability TLV from the protector. It SHOULD validate each context identifier included in the TLV, and advertise the information of only those PWs that are associated with the context identifier. It SHOULD withdraw previously advertised Yimin Shen, et al. Expires January 25, 2015 [Page 19] Internet-Draft PW Endpoint Fast Failure Protection July 2014 Protection FEC TLVs, when the protector has withdrawn a previously advertised context identifier or the entire Egress Protection Capability TLV via Capability message. The encoding of the Egress Protection Capability TLV is defined as below. It conforms to the format of Capability Parameter TLV specified in RFC 5561. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Egress Protection (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ | | | ~ Capability Data =3D context identifier(s) ~ | | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 The U-bit MUST be set to 1 so that a receiver MUST silently ignore this TLV if unknown to it, and continue processing the rest of the message. The F-bit MUST be set to 0 since this TLV is sent only in Initialization and Capability messages, which are not forwarded. The TLV Code Point is TBD. It needs to be assigned by IANA. The S-bit indicates whether the sender is advertising (S=3D1) or withdrawing (S=3D0) the capability. The "Capability Data" is encoded with the context identifier of the {primary PE, protector}. SB> where is the structure of {primary PE, protector} defined? [yshen] The Protection FEC Element TLV carries the context ID of {primary P= E, protector}. The {primary PE, protector} tuple itself is not encoded. 5.2. PW Label Distribution from Primary PE to Protector A primary PE SHOULD advertise a primary PW's label to a protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV (see Section 5.4 for encoding), and an Upstream- Assigned Label TLV (RFC 6389) encoded with the PW's label. The combination of the Protection FEC Element TLV and the PW label represents the primary PE's forwarding state for the PW. The Label Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC Yimin Shen, et al. Expires January 25, 2015 [Page 20] Internet-Draft PW Endpoint Fast Failure Protection July 2014 6389, RFC 3471) encoded with the context identifier of the {primary PE, protector}. The protector that receives this Label Mapping message SHOULD install a forwarding entry for the PW label in the label space identified by the context identifier. The nexthop of the forwarding entry SHOULD ensure packets to be sent towards the target CE via a backup AC or a backup (S-)PE, depending on the protection scenario. The protector SHOULD silently discard a Label Mapping message if the included context identifier is unknown to it. 5.3. PW Label Distribution from Backup PE to Protector In the centralized protector model, a backup PE SHOULD advertise a backup PW's label to a protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV and a Generic Label TLV encoded with the backup PW's label. This Protection FEC Element MUST be identical to the Protection FEC Element TLV that the primary PE advertises to the protector (Section 5.2). The context identifier SHOULD NOT be encoded in Interface_ID TLV in this message. The protector that receives this Label Mapping message SHOULD associate the backup PW with the primary PW, based on the common Protection FEC Element TLV. It SHOULD distinguish between the Label Mapping message from the primary PE and the Label Mapping message from the backup PE based on the respective presence and absence of context identifier in Interface_ID TLV. It SHOULD install a forwarding entry for the primary PW's label in the label space identified by the context identifier. The nexthop of the forwarding entry SHOULD indicate a label swap to the backup PW's label, followed by a label push or IP header push for a transport tunnel to the backup PE. 5.4. Protection FEC Element TLV The Protection FEC Element TLV has type 0x83. Its format is defined as below: Yimin Shen, et al. Expires January 25, 2015 [Page 21] Internet-Draft PW Endpoint Fast Failure Protection July 2014 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(0x83) | Reserved | Encoding Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ PW Information ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 - Encoding Type Type of format that PW Information field is encoded. - Length Length of PW Information field in octets. - PW Information Field of variable length that specifies a PW For Encoding Type, 1 is defined for the PWid FEC Element format, and 2 is defined for the Generalized PWid FEC Element format (RFC 4447). 5.4.1. Encoding Format for PWid Yimin Shen, et al. Expires January 25, 2015 [Page 22] Internet-Draft PW Endpoint Fast Failure Protection July 2014 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(0x83) | Reserved | Enc Type(1) | Length(16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 - Ingress PE Address IP address of the ingress PE of PW. - Egress PE Address IP address of the egress PE of PW. SB> How does this work for IPv6? - Group ID An arbitrary 32-bit value that represents a group of PWs and that is used to create groups in the PW space. - PW ID A non-zero 32-bit connection ID that, together with the PW Type field, identifies a particular PW. - Control word bit (C) A bit that flags the presence of a control word on this PW. If C =3D 1, control word is present; If C =3D 0, control word is not present. - PW Type A 15-bit quantity that represents the type of PW. SB> Needs a ref Yimin Shen, et al. Expires January 25, 2015 [Page 23] Internet-Draft PW Endpoint Fast Failure Protection July 2014 5.4.2. Encoding Format for Generalized PWid 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(0x83) | Reserved | Enc Type(2) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 - Ingress PE Address IP address of the ingress PE of PW. - Egress PE Address IP address of the egress PE of PW. SB> IPv6? - Control word bit (C) A bit that flags the presence of a control word on this PW. If C =3D 1, control word is present; If C =3D 0, control word is not present. - PW Type A 15-bit quantity that represents the type of PW. Yimin Shen, et al. Expires January 25, 2015 [Page 24] Internet-Draft PW Endpoint Fast Failure Protection July 2014 - AGI Type, Length, Value, AGI Value Attachment Group Identifier of PW. - SAII Type, Length, Value, SAII Value Source Attachment Individual Identifier of PW. - TAII Type, Length, Value, TAII Value Target Attachment Individual Identifier of PW. 6. Revertive Behavior Subsequent to local repair, there are three strategies for the network to restore traffic to a fully functional PW. o Global revertive mode If the ingress CE is multi-homed (Figure 1), it MAY switch the traffic to a backup AC which is bound to a backup PW. Alternatively, if the ingress PE hosts a backup PW (Figure 2), the ingress PE MAY switch the traffic to the backup PW. These procedures are referred to as global repair. Possible triggers of a global repair include PW status, OAM, and BFD. o Control plane revertive mode In egress PE node protection and S-PE node protection, it is possible that the failure is limited to the link between the PLR and the primary (S-)PE, whereas the primary (S-)PE is still up. In this case, the PLR or an upstream router along the transport tunnel MAY reroute the tunnel around the failed link via an alternative path. Thus, the transport tunnel can continue to be used to carry the PW traffic to the primary (S-)PE. This procedure is driven by control plane convergence, and is referred to as control plane repair. o Local revertive mode The PLR MAY move traffic back to the primary PW, after the failure is resolved. In egress AC protection, upon detecting that the primary AC is restored, the PLR MAY start forwarding traffic over the AC again. Likewise, in egress PE node protection and S-PE node protection, upon detecting that the primary PE is restored, the PLR MAY re-establish the primary transport tunnel through the primary PE, and move the traffic from the bypass tunnel back to Yimin Shen, et al. Expires January 25, 2015 [Page 25] Internet-Draft PW Endpoint Fast Failure Protection July 2014 the transport tunnel. These procedures are referred to as local reversion. The fast protection mechanism in this document SHOULD be used in tandem with the global revertive mode. Particularly in the case of egress (S-)PE failure, if the ingress PE or the protector loses communication with the (S-)PE for an extensive period of time, the LDP session between them may go down. Consequently, the ingress PE may bring down the primary PW, or the protector may remove the forwarding entry of the primary PW label. In either case, the service will be disrupted. In other words, although the fast protection can temporarily repair traffic, control plane state may eventually be timed out if the failure persists. Therefore, it is recommended that the global revertive mode SHOULD be set up in advance, so that traffic can be moved to a fully functional backup PW shortly after the local repair. The control plane revertive mode may always happen as part of the convergence of control plane protocols. However, it is only applicable to the specific scenarios described above. The local revertive mode is optional. In the circumstances where the failure is caused by resource flapping, local reversion MAY be dampened to limit potential disruptions. Local revertive mode MAY be disabled completely by configuration. 7. IANA Considerations This document defines the encoding of the Capability Parameter TLV for the new "Egress Protection Capability" in Section 5. This would require IANA to assign a TLV Code Point to it. This document defines a new LDP Protection FEC Element TLV in Section 5. IANA has assigned the type value 0x83 to it. SB> I am very confused about what explicit actions you are asking IANA=20 to take. Are you saying that there are no IANA actions? [yshen] Need IANA to assign a TLV code to "Egress Protection Capability", a= s said above. 8. Security Considerations The security considerations discussed in RFC 5036, RFC 5331, RFC 3209, and RFC 4090 apply to this document. SB> Are there any PW security considerations that apply? SB> This is a new PW operational mode, so I am surprised that there are no new security considerations. An early security review might be useful. [yshen] Not sure about any specific security issues. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nobody Wed Jul 30 14:22:21 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DAB1A049F for ; Wed, 30 Jul 2014 14:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG7Tdbp62-Ek for ; Wed, 30 Jul 2014 14:22:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9EC1A046A for ; Wed, 30 Jul 2014 14:22:17 -0700 (PDT) Received: from BL2PR05MB210.namprd05.prod.outlook.com (10.242.198.145) by BL2PR05MB212.namprd05.prod.outlook.com (10.242.198.150) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 21:22:16 +0000 Received: from BL2PR05MB210.namprd05.prod.outlook.com ([169.254.6.161]) by BL2PR05MB210.namprd05.prod.outlook.com ([169.254.6.161]) with mapi id 15.00.0995.014; Wed, 30 Jul 2014 21:22:16 +0000 From: Yakov Rekhter To: "stbryant@cisco.com" , "pwe3@ietf.org" Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqymQOZS3piQEo0SsGwmCrQU6UZu5Ifxw Date: Wed, 30 Jul 2014 21:22:15 +0000 Message-ID: <189bd398a4e64d2f88e3981c2a778105@BL2PR05MB210.namprd05.prod.outlook.com> References: <201407251524.s6PFOPn92012@magenta.juniper.net> <53D79504.4050904@cisco.com> In-Reply-To: <53D79504.4050904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(51704005)(24454002)(199002)(189002)(479174003)(377454003)(81342001)(15202345003)(19580405001)(81542001)(20776003)(4396001)(46102001)(80022001)(76482001)(86362001)(19580395003)(83322001)(99396002)(74502001)(83072002)(76576001)(74662001)(31966008)(21056001)(74316001)(92566001)(2656002)(101416001)(15975445006)(77096002)(76176999)(106116001)(107886001)(54356999)(106356001)(50986999)(66066001)(33646002)(85852003)(87936001)(77982001)(107046002)(85306003)(79102001)(95666004)(99286002)(64706001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB212; H:BL2PR05MB210.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/HBOaGrUKGEyq_XN4tY1SxdZcM2g Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:22:19 -0000 Stewart, > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, July 29, 2014 8:35 AM > To: Yakov Rekhter; pwe3@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > On 25/07/2014 16:24, Yakov Rekhter wrote: > > Hi, > > > >> This email begins a second two week working group last call for > >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection- > 01 . > >> > >> Please review the draft and post any comments to the PWE3 list. > >> > >> If you have read the draft, even if you don't have any comments, but > >> would like to see the draft progressed, please can you indicate > this to the list. > >> > >> This working group last call will end on Friday August 8th, 2014. > > I would like to see the draft progressed. > > > > Yakov. > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > Yakov >=20 > Doesn't this draft implicitly make a number of extensions to the MPLS > architecture? If you think it does, then please elaborate on do you think are these exten= sions. Yakov. From nobody Wed Jul 30 16:22:22 2014 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4181A0350 for ; Wed, 30 Jul 2014 16:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjjbdRvhU0Kf for ; Wed, 30 Jul 2014 16:22:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78631A0345 for ; Wed, 30 Jul 2014 16:22:16 -0700 (PDT) Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB221.namprd05.prod.outlook.com (10.242.41.154) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 23:22:07 +0000 Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.0995.014; Wed, 30 Jul 2014 23:22:08 +0000 From: Yimin Shen To: Alexander Vainshtein Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 Thread-Index: AQHPqByPzRsIO8QlbkK+kbMBZ9MDf5u3AuAAgAAZ0oCAABjewIABFRcAgADf/TA= Date: Wed, 30 Jul 2014 23:22:07 +0000 Message-ID: <30e13900814f41a681151971cbe9ebef@BY2PR05MB728.namprd05.prod.outlook.com> References: <201407251524.s6PFOPn92012@magenta.juniper.net> <53D79504.4050904@cisco.com> <04f15bedf2be4c7480d3e9ca01bdfd7f@BY2PR05MB728.namprd05.prod.outlook.com> <2597291f7b074922b690e4b06999cf1a@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <2597291f7b074922b690e4b06999cf1a@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(52604005)(51704005)(479174003)(377454003)(13464003)(252514010)(164054003)(199002)(189002)(24454002)(37854004)(83072002)(33646002)(85852003)(4396001)(64706001)(80022001)(2656002)(15202345003)(87936001)(20776003)(85306003)(66066001)(76576001)(74662001)(74502001)(101416001)(561944003)(86362001)(81342001)(95666004)(106356001)(99286002)(77982001)(106116001)(76176999)(105586002)(81542001)(76482001)(79102001)(21056001)(110136001)(107046002)(15975445006)(19580395003)(83322001)(99396002)(93886003)(92566001)(19580405001)(50986999)(46102001)(54356999)(31966008)(74316001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB221; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/MsBlLbmTE6wTZju9V4_NPW0widI Cc: Yakov Rekhter , "pwe3@ietf.org" , "stbryant@cisco.com" Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Pseudowire Emulation Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 23:22:20 -0000 Hi Sasha, Thanks again for your comments. Please see inline... Thanks, /Yimin -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Wednesday, July 30, 2014 4:08 AM To: Yimin Shen Cc: stbryant@cisco.com; Yakov Rekhter; pwe3@ietf.org Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protecti= on-01 Yimin hi, Lots of thanks for a prompt response. Unfortunately, from my point of view, the issues I've raised still remain u= nresolved. Please see additional questions inline below. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Yimin Shen [mailto:yshen@juniper.net] > Sent: Tuesday, July 29, 2014 7:56 PM > To: Alexander Vainshtein; stbryant@cisco.com; Yakov Rekhter;=20 > pwe3@ietf.org > Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > Hi Sasha, >=20 > Thanks very much for the review and comments. Please see my responses=20 > inline. Hope they are helpful. >=20 >=20 > Thanks, >=20 > /Yimin >=20 >=20 >=20 > -----Original Message----- > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander=20 > Vainshtein > Sent: Tuesday, July 29, 2014 10:08 AM > To: stbryant@cisco.com; Yakov Rekhter; pwe3@ietf.org > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > protection-01 >=20 > Stewart, Yakov and all, > I have started reading the draft, and it seems that it breaks quite a=20 > few common architectural assumptions. >=20 > [yshen] This draft is fully based on the PWE3 architecture and the=20 > MS-PW architecture. >=20 > The following text from Section 3.1 "Single-Segment PW" looks highly=20 > problematic to me: > > At any given time, each CE sends traffic via only one AC and receives > traffic via only one AC. The two ACs MAY or MAY NOT be the same. > The AC used to send traffic is determined by the CE, and MAY rely on > an end-to-end OAM mechanism between the CEs. The AC used for the CE > to receive traffic is determined by the state of the network and the > protection mechanism in use, as described later in this document. > . >=20 > To the best of my order for the pair of interconnected CEs to be able=20 > to operate in this way each of them should treat the pair of ACs shown=20 > in Figure > 1 as a single logical entity. > E.g., if we are speaking about Ethernet PWs, each CE could treat=20 > Ethernet links supporting these two ACs as a single Link Aggregation=20 > Group. However, the draft does not mention any such thing (or at least I = did not find it). >=20 > Do I miss something important here? >=20 > [yshen] It is a logical view that the CE is dual-home to 2 PEs over 2=20 > distinct ACs. AC is a concept well defined in RFC 3985. In terms of=20 > the actual PE-CE connection in the case of Ethernet, the CE could have=20 > 2 distinct Ethernet links or 2 VLANs over a single LAG. >=20 [[Sasha]] If I read your response correctly, each dual-homed CE treats each= if its two ACs as an individual entity. I see this is as highly problematic. E.g., consider the case when CE1 and C= E2 are two CE routers running some link-state routing protocol between them= . - In the normal situation, CE1 probably would see its two ACs as two paral= lel bi-directional links. - With PW redundancy, one of these links (one that corresponds to the curre= nt Active PW) would be Up and the other one - Down - With your proposal, the typical link-state routing protocol between CE1 a= nd CE2 would not be able to form any adjacencies across any of these links,= because this process requires bi-directional link connectivity; so regardl= ess of whatever happens in the PW domain CE1 and CE2 would consider each ot= her as unreachable across this domain. Did I miss something? (I intentionally leave aside protocols like OLSR that= can handle unidirectional links). [yshen] I'm lost in the last 2 bullets. This draft assumes active-active PW= s and bidirectional ACs. I think you are talking about how to run Layer 3 b= etween CEs with an overlay model, which I don't think is in scope of PWE3 a= rchitecture.=20 > I also wonder whether, in the single segment PW scenario, the same=20 > level of protection could not be achieved with ICCP (RFC 7275)=20 > running between each pair of PEs and, possibly with 4 (instead of 2)=20 > PWs. For the reference, ICCP (or RFC 7275) is not mentioned in the=20 > draft, even if a possible alternative solution to some of the problems=20 > it solves. ( >=20 > [yshen] Thanks for pointing out ICCP. We will mention it in the next revi= sion. > In this draft we broadly refer to such kind of mechanism as "control=20 > plane repair". The purpose of this draft is to locally repair traffic=20 > at the failure point, in order to reduce traffic loss before ICCP or=20 > other control plane repair mechanism kicks in. [[Sasha]] I am not sure ICCP in this case would mean slow protection. Its f= unction here would be just to synchronize the state of PWs between PE1 and = PE3/PE2 and PE4, and this can be reasonably fast IMO. The Protection State = Coordination (PSC) protocol in RFC 6378 looks like an analog (with some str= etch of course), and it is supposed to provide pretty fast protection switc= hing. [yshen] The draft doesn't comment specifically on ICCP performance. General= ly speaking, local repair mechanism tends to have the least overhead when r= estoring traffic. This is because both failure detection and traffic restor= ation are done right in the dataplane. It doesn't rely on dataplane to cont= rol plane notification (for failure event) or control plane protocol. For t= his exact reason there have been various IP/MPLS fast-reroute mechanisms de= fined by IETF. Of course, in a given scenario where the delay in global rep= air or control plane repair is tolerable for users, they don't have to use = local repair. Local repair is for the case where it is desirable to reduce = traffic loss even further. Note that local repair is a temporary repair, an= d it doesn't prevent global repair or control plane repair to perform a per= manent repair. I believe the draft has specifically mentioned this. >=20 > Stewart did not specify in his email which MPLS architecture=20 > principles he thinks are broken by this draft. >=20 > I think, however, that some PWE3 architectural principles are=20 > definitely are broken, and this includes: > - Bi-directional nature of the PW - it seems that the draft allows=20 > each a PW be Up in one direction and Down in the other one >=20 > [yshen] No, the draft does not allow that. It only says that we can=20 > send traffic of one direction over one PW, while sending traffic of=20 > the opposite direction over another PW (i.e. backup PW). Both PWs should = be up bidirectionally. >=20 >=20 [[Sasha]] Sorry but I do not understand that. The draft discusses something= like the "egress AC failure". If, say. PE1 detects that, I expect it woul= d send a PW Status with "PW not Forwarding" and "Local AC Transmit Fault" b= its set to PE2. Would this not mean that the PW between PE1 and PE2 is Down= ? [yshen] In case of egress AC failure, CE2 will detect the failure and start= to send traffic over PW2 (i.e. the backup PW). CE1 should also start to se= nd traffic over the backup PW2. This may be triggered by many events, e.g. = [1] PE1's notification to CE1 based on the PW status you mentioned above (b= ut it is not mandatory); or [2] CE1 receiving traffic from PE3. In any case= , it may take some time for CE1 to do so. Before this happens on CE1, the t= raffic is still going over PW1 (primary PW) which is being locally repaired= by PE2.=20 > - Lack of dependencies between the PSN tunnels and the PWs they carry. > * Consider the network diagram shown in Figure 5 in Section 4.1 > * The text suggests that the tunnel between PE1 and PE2 must=20 > recognize PE4 as the "protector" node for the PW it carries > * What is supposed to happen if the tunnel between PE1 and PE2=20 > carries, say, 10 PWs, each with its own backup PE PE4-1, ... PE4-10)? >=20 > [yshen] In your example, the 10 PWs are protected by 10 different=20 > protectors. In this case, you would need 10 different tunnels,=20 > destined to 10 different context IDs (one context ID per PE4-x>). If multiple PWs are protected by the same protector, they can be= carried by the same tunnel. >=20 [[Sasha]] This looks like a non-scalable solution to me. [yshen] I'm not sure there is any scalability issue here. We basically need= one tunnel per context ID, i.e. per . In reality, t= he number of should not be high. The draft also spe= cifies the centralized model for reducing the number of context IDs.=20 >=20 > - Lack of dependencies between the mechanism used for the tunnel setup=20 > (LDP, RSVP-TE, manual configuration etc.) and the PWs this tunnel carries= . > * Is the protection model described in Section 4.1 compatible with=20 > Tunnel LSPs being set up by LDP? With, say, GRE tunnels carrying the=20 > PWs using MPLS-in-GRE? >=20 > [yshen] Yes, it is compatible. The draft is generic on transport=20 > layer, and it allows tunnels to be LDP, RSVP-TE, GRE, etc. These=20 > protocols already provide sufficient machineries for setting up transport= tunnels and bypass tunnels. > Therefore, the draft doesn't require new extension to these LSP=20 > signaling protocols. >=20 [[Sasha]] Sorry but this does not match your response to my previous questi= on/issue where you have explained that you effectively need a tunnel per PW= between PE1 and PE2. RSVP-TE can provide that; but how is LDP supposed to = do that? [yshen] Again, a tunnel can carry multiple PWs, if these PWs are protected = by the same protector. You could use 10 different protectors to protect 10 = PWs, but in reality when SP design their network, they should ask why they = have to do so. Regarding LDP, it is one FEC per context ID, and nothing spe= cial. > Last but not least, I would like to understand better how the draft is=20 > protecting MS-PWs against S-PE failures. > Specifically, I'd like to understand whether it is applicable to the=20 > case when each pair of T-PEs resides in its own AS, with two pairs of=20 > directly connected ASBRs between these two ASs acting as S-PEs. There=20 > would be no need to set up any tunnel LSPs between each pair of S-PEs in = this scenario. > I would appreciate an analysis of this scenario regarding ability to=20 > protect about the ASBR/S-PE failure. IMO it is a relevant scenario=20 > because MS-PWs are one of the methods to provide inter-AS services. >=20 > [yshen] The MS-PW topology in this draft is based on the Figure-4 of=20 > RFC 5659, which is slightly different than the scenario you mentioned abo= ve. > [[Sasha]] Figure 4 in RFC 5659 does not say anything about inter-AS. > > However, the mechanism in this draft does apply to this scenario as=20 > well. It should work equally if S-PEs are one-hop or multi-hops away=20 > from each other. Please see the picture below. In this case, SPE1 ~ SPE4 = are ASBRs. > When SPE4 detects the failure of SPE3, it will do a local repair and=20 > redirect PW traffic to SPE4 which is the protector. The bypass between=20 > SPE1 and SPE4 may be a one-hop tunnel or a multi-hop tunnel, depending=20 > on the actual topology between the 2 AS'. > [[Sasha]] This approach can work if SPE1 is directly connected to SPE4 beca= use in this case there would be no need for a tunnel LSP between them.=20 I do not see a simple way to set up an LSP between SPE1 (in AS-1) and SPE4(= in AS-2) if such connectivity is not present; could you possibly expand on = how this is supposed to happen? [yshen] Sasha, if you don't have a bypass tunnel (due to specific topology = or policy or whatever), you won't get any IP/MPLS fast-reroute mechanism to= work :) However it doesn't mean the mechanism is broken. In your case, I d= on't see any technique issue why you cannot set up a inter-AS bypass from S= PE1-SPE2-SPE4. > > In any case, SPE4 will send PW traffic over a > tunnel to TPE4. >=20 > |<--------------- PW1 ----------->| >=20 > - TPE1 -------- SPE1 - SPE3 --------- TPE2 - > / PLR \ \ > / \ \ > CE1 bypass\ CE2 > \ \ / > \ \ / > - TPE3 -------- SPE2 - SPE4 --------- TPE4 - > protector >=20 > |<--------------- PW2 ----------->| >=20 > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 > > -----Original Message----- > > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart=20 > > Bryant > > Sent: Tuesday, July 29, 2014 3:35 PM > > To: Yakov Rekhter; pwe3@ietf.org > > Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast- > > protection-01 > > > > On 25/07/2014 16:24, Yakov Rekhter wrote: > > > Hi, > > > > > >> This email begins a second two week working group last call for > > >> http://tools.ietf.org/html/draft-ietf-pwe3-endpoint-fast-protection-= 01 . > > >> > > >> Please review the draft and post any comments to the PWE3 list. > > >> > > >> If you have read the draft, even if you don't have any comments,=20 > > >> but would like to see the draft progressed, please can you=20 > > >> indicate this to the > > list. > > >> > > >> This working group last call will end on Friday August 8th, 2014. > > > I would like to see the draft progressed. > > > > > > Yakov. > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > Yakov > > > > Doesn't this draft implicitly make a number of extensions to the=20 > > MPLS architecture? > > > > Stewart > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3