From srivatsan.raghavan@aricent.com Tue Jan 3 23:27:06 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F6821F844F for ; Tue, 3 Jan 2012 23:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf3ugN9M7wNW for ; Tue, 3 Jan 2012 23:27:06 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id BC1D721F860F for ; Tue, 3 Jan 2012 23:27:05 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 25C7436B26 for ; Wed, 4 Jan 2012 12:56:15 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 0F37136B24 for ; Wed, 4 Jan 2012 12:56:15 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 4 Jan 2012 12:57:02 +0530 From: Srivatsan Raghavan To: pwe3 Date: Wed, 4 Jan 2012 12:58:26 +0530 Thread-Topic: RFC 5086 : CCS signalling query Thread-Index: Acy9qH6xWzqV2Pt3SrOFM/Q/D1NWLANCLP/g Message-ID: References: <4EE63982.7020403@trajano.us.es> <07F7D7DED63154409F13298786A2ADC90427FBB4@EXRAD5.ad.rad.co.il> <4EE73621.1090802@trajano.us.es> <07F7D7DED63154409F13298786A2ADC9042831D9@EXRAD5.ad.rad.co.il> <4EE87FF4.5090704@trajano.us.es> <07F7D7DED63154409F13298786A2ADC90429ABF6@EXRAD5.ad.rad.co.il> <4EEE1F41.6020403@trajano.us.es> In-Reply-To: <4EEE1F41.6020403@trajano.us.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] RFC 5086 : CCS signalling query X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 07:27:06 -0000 Hi authors RFC 5086 states [ in Section 5.3 ] that=20 " Encoding of CE application state for telephony application using CCS = will be considered in a separate document. " Could the authors point out if a separate document exists for CCS encoding = ? Specifically, should CCS be treated as=20 i) pure bearer [ and M bits in CW set to 00 ] and CCS time slot interpreta= tion left to the end points [ to recover SS7 messages etc.], that is interm= ediate nodes doing PW encap/decap need not attach any meaning to CCS=20 or=20 ii) treated as signaling [ and M bits set to 11 ]=20 Thx Srivatsan From Alexander.Vainshtein@ecitele.com Wed Jan 4 00:26:44 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A4821F86CA for ; Wed, 4 Jan 2012 00:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFtC6E636J-1 for ; Wed, 4 Jan 2012 00:26:43 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 0E73821F86C6 for ; Wed, 4 Jan 2012 00:26:42 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1325665594!9527710!16 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 16378 invoked from network); 4 Jan 2012 08:26:41 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-182.messagelabs.com with SMTP; 4 Jan 2012 08:26:41 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-6b-4f040e3b3c98 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 8A.28.08306.B3E040F4; Wed, 4 Jan 2012 10:30:51 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 4 Jan 2012 10:26:38 +0200 From: Alexander Vainshtein To: Srivatsan Raghavan , pwe3 Date: Wed, 4 Jan 2012 10:26:38 +0200 Thread-Topic: RFC 5086 : CCS signaling query Thread-Index: AczKupLHOg7sN1KOT/mbtaSgyR/SuA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTXUzTUBjNXcvoJsUywF0mxlGRqDCygcYRmdGEBHwgoPCiL1i669awdXPt kPkCUYM6E9AQTdyLGOe/QiTTaMBEwSigKP7/GxUSFElUJCIxOluqOON9Oveec77T25xLYLqL agPB8SLy8YyLVmvxltHxCdOKRLzMfOeg1do0HsGtZ/ua8VWqkkg0ElcSDk+pylUbGkAhw/Me kRGR0Y4E1kaX+7hahg3QRs5uoy200etiWORGvGijGa8X8XZ6pdb43yqUZBxvRDzrsXO8w0av qSgzWa3LCkwWemXWAkv+Cm2lkxOMyORmOJfRjQSBcSCjdLIxgjk/vpwC3l5NXVPktLoBXIsP Ag0BqaXw8dButYLnwMFX7RLWEjrqEoAjvdswZdMC4GjPFC6r1JQNdpx+Oe1IoUph0/0fIAgI Aqcy4cO2evk4mcqG9843xyuSHHj37Z7f8lz4bcfnaUxSa2H45jaVjIEUPNl/ZhpjlB4+Gz6k Uj6IguGuO5iCU+H7oZ9xij4VvtjZDhR9DmztHFcrOBseO/wBU+Ynwb6Dw7jiTYNXTzzB94KU UExEKMYeirGHYuytAD8F0jiXV6x2O8x5Jo9fzEUsJyIXymU97g6gdODdRfD81uJuQBGATiAN jViZLo6pFQLubpBGqOhUcpcaL9MlVnvsAScjOKt8fhcSugEkMDqFPLpQkpN2JrAV+Tx/KKv0 Q/dhhlmsR2obL1blm83/bGg9uYcdK9VRDqlUNQh5ke+PNZ0gaEiGE6TEJB9yoLpNnEv8S6sI jZycICUPyhpS8DJugXMofD/IMOjJNpmgZMLp52e8cuHro9HoKNBL90wmN8uqBOk5zLhHpcEq afDkpHwlQSr8DGVoAHPZD9vzbhR3zH59b+LBkizP8uiVtky15fuWioYsbf16++FT7kBX6Gtj wc+W4/iPxJ3F/uC5OQPPzOIiLuX2p3lHCi4UVR6YCH4ZzksKdc5r3P64zx9/6Mnl/UxG5931 rwZE7GT9WJe2KP3pupFxe0ZxcfqbmmjJ6uvzH00aNJk9D6poXHAyliWYT2B+AXad05TLAwAA Subject: Re: [PWE3] RFC 5086 : CCS signaling query X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:26:44 -0000 Srivatsan hi, AFAIK, there are no documents that describe encoding of CE application state= s for telephony applications using CCS. Regards, Sasha > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Srivatsan Raghavan > Sent: Wednesday, January 04, 2012 9:28 AM > To: pwe3 > Subject: [PWE3] RFC 5086 : CCS signalling query > > Hi authors > > > RFC 5086 states [ in Section 5.3 ] that > " Encoding of CE application state for telephony application using CCS = will > be considered in a separate document. " > > Could the authors point out if a separate document exists for CCS encoding > ? > > Specifically, should CCS be treated as > i) pure bearer [ and M bits in CW set to 00 ] and CCS time slot interpret= ation > left to the end points [ to recover SS7 messages etc.], that is intermedia= te > nodes doing PW encap/decap need not attach any meaning to CCS > > or > > ii) treated as signaling [ and M bits set to 11 ] > > > > Thx > Srivatsan > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From srivatsan.raghavan@aricent.com Wed Jan 4 05:24:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F6521F8735 for ; Wed, 4 Jan 2012 05:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeZMvXHsNPLP for ; Wed, 4 Jan 2012 05:24:19 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id E610721F8604 for ; Wed, 4 Jan 2012 05:24:18 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id A4C3036B3C for ; Wed, 4 Jan 2012 18:53:28 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 8F62A36B32 for ; Wed, 4 Jan 2012 18:53:28 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Wed, 4 Jan 2012 18:54:16 +0530 From: Srivatsan Raghavan To: Alexander Vainshtein , pwe3 Date: Wed, 4 Jan 2012 18:55:39 +0530 Thread-Topic: RFC 5086 : CCS signaling query Thread-Index: AczKupLHOg7sN1KOT/mbtaSgyR/SuAAKXYTw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] RFC 5086 : CCS signaling query X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:24:20 -0000 Hi Sasha Thanks for your response.=20 Given the fact there is no IETF document which describes the procedure for = CCS encoding in CW, is then the general guideline to treat CCS traffic as b= earer traffic [ and set M bits to 00 ] ? Thx Srivatsan -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Wednesday, January 04, 2012 1:57 PM To: Srivatsan Raghavan; pwe3 Subject: RE: RFC 5086 : CCS signaling query Srivatsan hi, AFAIK, there are no documents that describe encoding of CE application stat= es for telephony applications using CCS. Regards, Sasha > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Srivatsan Raghavan > Sent: Wednesday, January 04, 2012 9:28 AM > To: pwe3 > Subject: [PWE3] RFC 5086 : CCS signalling query >=20 > Hi authors >=20 >=20 > RFC 5086 states [ in Section 5.3 ] that > " Encoding of CE application state for telephony application using CCS = will > be considered in a separate document. " >=20 > Could the authors point out if a separate document exists for CCS encodin= g > ? >=20 > Specifically, should CCS be treated as > i) pure bearer [ and M bits in CW set to 00 ] and CCS time slot interpre= tation > left to the end points [ to recover SS7 messages etc.], that is intermedi= ate > nodes doing PW encap/decap need not attach any meaning to CCS >=20 > or >=20 > ii) treated as signaling [ and M bits set to 11 ] >=20 >=20 >=20 > Thx > Srivatsan >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From javi@trajano.us.es Wed Jan 4 07:33:03 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3739121F870E for ; Wed, 4 Jan 2012 07:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.048 X-Spam-Level: X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKGurvK4YRMg for ; Wed, 4 Jan 2012 07:33:02 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by ietfa.amsl.com (Postfix) with ESMTP id 162B521F871B for ; Wed, 4 Jan 2012 07:33:01 -0800 (PST) Received: (qmail 28568 invoked from network); 4 Jan 2012 16:32:55 +0100 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 4 Jan 2012 16:32:55 +0100 Received: (qmail 19788 invoked by uid 507); 4 Jan 2012 15:32:59 -0000 Received: from 127.0.0.1 by antivirus2 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.97.3/14245. Clear:RC:1(127.0.0.1):. Processed in 0.030423 secs); 04 Jan 2012 15:32:59 -0000 Received: from unknown (HELO antivirus2) (127.0.0.1) by us.es with SMTP; 4 Jan 2012 15:32:59 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus2 (F-Secure/fsigk_smtp/406/antivirus2); Wed, 04 Jan 2012 16:32:59 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/406/antivirus2) Received: (qmail 15153 invoked from network); 4 Jan 2012 16:32:51 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 4 Jan 2012 16:32:51 +0100 Received: from [127.0.0.1] (112.pool85-56-79.dynamic.orange.es [85.56.79.112]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id q04FWwL7032020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Jan 2012 16:32:59 +0100 Message-ID: <4F047122.8000203@trajano.us.es> Date: Wed, 04 Jan 2012 16:32:50 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] HDLC mode [RFC5087] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 15:33:03 -0000 I have a E1 interface in which 3 channels carry CSS (obiously, HDLC), and the signalling of each channel isindependent of the other. If I apply the HDLC Format Payload [RFC5087/Clause 5.3], how many TDMPWs (in HDLC-mode) would be established? * Only 1 HDLC-mode TDMPW for the 3 CSS-channels. * 3 HDLC-mode TDMPWs, one for each CSS-channel. Regards, Javi From yaakov_s@rad.com Sat Jan 7 11:20:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D5421F84EA for ; Sat, 7 Jan 2012 11:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR2GgjgliqqC for ; Sat, 7 Jan 2012 11:20:47 -0800 (PST) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5FF21F84DE for ; Sat, 7 Jan 2012 11:20:43 -0800 (PST) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 7 Jan 2012 21:11:21 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Sat, 7 Jan 2012 21:20:40 +0200 From: Yaakov Stein To: Javi Thread-Topic: [PWE3] HDLC mode [RFC5087] Thread-Index: AQHMyvYsDdh2SsMcckuQVwk6JaLFI5YBTH+A Date: Sat, 7 Jan 2012 19:20:39 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9042C6EB6@EXRAD5.ad.rad.co.il> References: <4F047122.8000203@trajano.us.es> In-Reply-To: <4F047122.8000203@trajano.us.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] HDLC mode [RFC5087] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 19:20:47 -0000 Javi It would seem to require 3, since there is no way to differentiate between = the data of the three channels. Pardon my asking - but why are there 3 CSS channels for a single E1 ? Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Jav= i Sent: Wednesday, January 04, 2012 17:33 To: pwe3@ietf.org Subject: [PWE3] HDLC mode [RFC5087] I have a E1 interface in which 3 channels carry CSS (obiously, HDLC),=20 and the signalling of each channel isindependent of the other. If I apply the HDLC Format Payload [RFC5087/Clause 5.3], how many TDMPWs=20 (in HDLC-mode) would be established? * Only 1 HDLC-mode TDMPW for the 3 CSS-channels. * 3 HDLC-mode TDMPWs, one for each CSS-channel. Regards, Javi _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From scott.mansfield@ericsson.com Sun Jan 8 05:54:59 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE921F857D; Sun, 8 Jan 2012 05:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw2VTqNPz50Q; Sun, 8 Jan 2012 05:54:58 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A62EB21F857A; Sun, 8 Jan 2012 05:54:58 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q08Dslvg030164; Sun, 8 Jan 2012 07:54:50 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 8 Jan 2012 08:54:41 -0500 From: Scott Mansfield To: "ietf@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Sun, 8 Jan 2012 08:53:05 -0500 Thread-Topic: New Liaison Statement, "LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "swallow@cisco.com" , "stbryant@cisco.com" , "rcallon@juniper.net" , "lberger@labn.net" , "andrew.g.malis@verizon.com" , "dbrungard@att.com" Subject: [PWE3] FW: New Liaison Statement, "LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 13:54:59 -0000 This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determine= d recommendation G.8113.1 (May 2011). The liaison also provides a pointer = to the internet draft draft-betts-itu-oam-ach-code-point that requests an A= Ch code point that is needed by G.8113.1. This is a liaison that will requ= ire a response and the ITU-T has requested a response no later than 1 Augus= t 2012. I would suggest that we use the liaison response to provide the ou= tcome of running the IETF process required to assign the requested code poi= nt. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 > = From scott.mansfield@ericsson.com Sun Jan 8 06:03:02 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618A21F857F; Sun, 8 Jan 2012 06:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6toldkBkO4w; Sun, 8 Jan 2012 06:03:02 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1521F857A; Sun, 8 Jan 2012 06:03:02 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q08E2xVd015650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jan 2012 08:02:59 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 8 Jan 2012 09:02:58 -0500 From: Scott Mansfield To: "ietf@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Sun, 8 Jan 2012 09:01:22 -0500 Thread-Topic: New Liaison Statement, "LS368 - MPLS-TP Recommendations" Thread-Index: AczN4pkSBaUC0mYaQoOGlA/HaKlurQAKkiSA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "swallow@cisco.com" , "stbryant@cisco.com" , "rcallon@juniper.net" , "lberger@labn.net" , "andrew.g.malis@verizon.com" , "dbrungard@att.com" Subject: [PWE3] FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 14:03:02 -0000 This is a liaison from SG15 Q9, Q12, and Q14 providing the text of G.8110.1= , G.8121, and G.8151. This liaison is for information only. G.8110.1 was = approved at the SG15 plenary meeting in December 2011. G.8121 and G.8151 e= ntered the alternative approval process (AAP) and will enter a 4 week last = call (the last call hasn't been initiated yet). Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:51 AM > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; mpls@ietf.org;=20 > lear@cisco.com; Scott Mansfield; stbryant@cisco.com;=20 > adrian@olddog.co.uk; malcolm.betts@zte.com.cn; Ghani Abbas;=20 > Kam.Lam@alcatel-lucent.com; tsbsg15@itu.int;=20 > greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations" >=20 > Title: LS368 - MPLS-TP Recommendations > Submission Date: 2012-01-08 > URL of the IETF Web page: /liaison/1126/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: Multiprotocol Label Switching (rcallon@juniper.net,=20 > swallow@cisco.com, loa@pi.nu) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,mpl > s@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com,stbryan > t@cisco.com,adrian@olddog.co.uk > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact:=20 > malcolm.betts@zte.com.cn,Ghani.Abbas@ericsson.com,Kam.Lam@alca > tel-lucent.com > Purpose: For information >=20 > Body: At the December 2011 meeting of ITU-T Study Group 15,=20 > Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS=20 > Transport Profile (MPLS-TP) layer network" was approved. A=20 > copy is attached for your information. =20 > We would like to draw your attention to clause 10 that=20 > describes the MPLS-TP Diff-Serv Architecture. > In addition, the approval process was initiated for=20 > Recommendations ITU-T G.8121/Y.1381 "Characteristics of=20 > MPLS-TP Network Equipment Functional Blocks" and ITU-T=20 > G.8151/Y.1374 "Management aspects of the MPLS-TP network element". >=20 > Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1. >=20 > Attachment(s): >=20 > LS368 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1308.pdf >=20 > LS368 - Att1_PLEN-517Rev3=20 > https://datatracker.ietf.org/documents/LIAISON/file1309.pdf >=20 > LS368 - Att2_PLEN-540Rev1=20 > https://datatracker.ietf.org/documents/LIAISON/file1310.pdf >=20 > LS368 - Att3_PLEN-543Rev1=20 > https://datatracker.ietf.org/documents/LIAISON/file1311.pdf >=20 >=20 > = From nurit.sprecher@nsn.com Mon Jan 9 09:20:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8911E809B; Mon, 9 Jan 2012 09:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLnwcX7-t59J; Mon, 9 Jan 2012 09:20:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61311E809A; Mon, 9 Jan 2012 09:20:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q09HK3XF004485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:20:03 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q09HJrxG026756; Mon, 9 Jan 2012 18:20:03 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:20:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 18:19:57 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cAADpI3OA= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Scott Mansfield" , , , , X-OriginalArrivalTime: 09 Jan 2012 17:20:02.0328 (UTC) FILETIME=[EBF91980:01CCCEF2] Cc: swallow@cisco.com, andrew.g.malis@verizon.com, dbrungard@att.com, stbryant@cisco.com Subject: Re: [PWE3] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:20:11 -0000 Support -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = ext Scott Mansfield Sent: =E0 08 =E9=F0=E5=E0=F8 2012 15:53 To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = andrew.g.malis@verizon.com; dbrungard@att.com Subject: FW: New Liaison Statement, "LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration = andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" This is a liaison from the ITU-T SG15 WP3 providing a copy of the = Determined recommendation G.8113.1 (May 2011). The liaison also = provides a pointer to the internet draft = draft-betts-itu-oam-ach-code-point that requests an ACh code point that = is needed by G.8113.1. This is a liaison that will require a response = and the ITU-T has requested a response no later than 1 August 2012. I = would suggest that we use the liaison response to provide the outcome of = running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From nurit.sprecher@nsn.com Mon Jan 9 09:41:53 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D055311E80E6; Mon, 9 Jan 2012 09:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgfjPvmaeHaC; Mon, 9 Jan 2012 09:41:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0811E80BD; Mon, 9 Jan 2012 09:41:52 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q09HfkoF014113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:41:46 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q09HfkhZ009479; Mon, 9 Jan 2012 18:41:46 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:41:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 18:41:43 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326405178E7C@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cAADpI3OAAAL2zAA== References: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Scott Mansfield" , , , , X-OriginalArrivalTime: 09 Jan 2012 17:41:46.0156 (UTC) FILETIME=[F51D76C0:01CCCEF5] Cc: andrew.g.malis@verizon.com, dbrungard@att.com Subject: Re: [PWE3] [CCAMP] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:41:54 -0000 When saying support, I mean of course that I fully support the proposal = of Scott! -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: =E1 09 =E9=F0=E5=E0=F8 2012 19:20 To: ext Scott Mansfield; ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; = ccamp@ietf.org Cc: andrew.g.malis@verizon.com; dbrungard@att.com Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration = andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Support -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = ext Scott Mansfield Sent: =E0 08 =E9=F0=E5=E0=F8 2012 15:53 To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = andrew.g.malis@verizon.com; dbrungard@att.com Subject: FW: New Liaison Statement, "LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration = andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" This is a liaison from the ITU-T SG15 WP3 providing a copy of the = Determined recommendation G.8113.1 (May 2011). The liaison also = provides a pointer to the internet draft = draft-betts-itu-oam-ach-code-point that requests an ACh code point that = is needed by G.8113.1. This is a liaison that will require a response = and the ITU-T has requested a response no later than 1 August 2012. I = would suggest that we use the liaison response to provide the outcome of = running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Mon Jan 9 18:36:47 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124C11E80C8; Mon, 9 Jan 2012 18:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuOYMzgdtpN3; Mon, 9 Jan 2012 18:36:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C62421F84FC; Mon, 9 Jan 2012 18:36:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120110023647.14526.74383.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 18:36:47 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 02:36:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : LDP Typed Wildcard FEC for the PW FEC Elements Author(s) : Kamran Raza Sami Boutros Carlos Pignataro Filename : draft-ietf-pwe3-pw-typed-wc-fec-01.txt Pages : 8 Date : 2012-01-09 The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW (0x82) FEC element types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.txt From Alexander.Vainshtein@ecitele.com Wed Jan 11 02:38:15 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9721F8683 for ; Wed, 11 Jan 2012 02:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to0VENZV6XLQ for ; Wed, 11 Jan 2012 02:38:14 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id C4DDE21F8663 for ; Wed, 11 Jan 2012 02:38:13 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1326278240!47923906!27 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 28120 invoked from network); 11 Jan 2012 10:37:37 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-27.messagelabs.com with SMTP; 11 Jan 2012 10:37:37 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-f0-4f0d67867d5e Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id D8.E2.08306.6876D0F4; Wed, 11 Jan 2012 12:42:14 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 11 Jan 2012 12:38:10 +0200 From: Alexander Vainshtein To: Srivatsan Raghavan , pwe3 Date: Wed, 11 Jan 2012 12:38:09 +0200 Thread-Topic: RFC 5086 : CCS signaling query Thread-Index: AczKupLHOg7sN1KOT/mbtaSgyR/SuAAKXYTwAVn51QA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRzmvTvXbe3iNj/2KiXjyihzMbVgWss+/skgVhRZEdm5vW6H223s TtGgkiIFCz/SCv1HS4s+NMNWafVPgoQSaQVlpZWlkRoRs281u9ulGd1fz73P8/ye3/vy+5G4 vl8VQ3K8iPw862ZUGqJyJPjZVOSkbObuolRLaTBAWJo6y4i12MbAVCBsY0PDD2wLtrsQrGZ5 3iuyIjI6kGC3Mlv8XB5rL2CMnMPKJDJGn5u1Iw/iRSvD+nyIdzBrNMb/vtWSjOONiLd7HRzv tDLp22wmi2VliimRWbN4YWLyKs12FycYkcnDcm6jBwkC60RG6WRfAHcNFJdivvLY/Hc3hvBC cBWWADUJ6RWwpOELUHAU7HnZrJKxnm4DsOeorgRoJFwFYLD+dYhQ0VbYcrk/hCPozbD08WTI TNBx8NrxCkzG4fQy+Oh62RxFkwAfvjn2R58Ka1+dC2koeis8fbiPUAJqAZy88zBEqOmd8Gyw PlQUSB1962oMneO0AT4frMWUTmnYcKcbV3AkHH77K0zRR8K+4mag6BNg3e2gSsHL4Pkzo7gS rIOd1YOE4o2Gdy/0EuUgqmZWRM0se80se80sex0gLoFozu0TszxOc5LJmysuR3ZORG603O71 tABlON63ghf3l7YDmgSMlkpGWps+jM0TCjztIJrEmEhqB6Js+nlZXkeBixVcmf5cNxLaASRx JoKqdkgc5WAL9iO/d5qySE9dgcfMtXulMeTFzGSz+Z8fxkAds3/YrKed0rTlIORD/mnrfJJk IKXNlqrq/MiJ8rM5t/iXxki1nKyVkglZQwk+1iNwToXvAiayt67uAdATvJdHMQbqo9w6LYtc ufxMHXkrDk1NTY0Ag3TncEotl9JKOzNTaUQKwaSQwBWtHCJtxQwVUwhMWUtejj5QV6ngqwXx 3y8lVJ0i55sy6IhNSRnOn2P9vviRjoMRY4EEUbdudH12SWug9Nbo0MSJT4vabg84NjzbMx6+ V7cr7cP2+u7J+yfnNk505A3FDVur9zYNpxPuI3FpN3sf5z25N97jMjRevFXW9TTlayzd6Oqs VFku5PAH0jGGEFxsYjzuF9jfC+7TtvADAAA= Subject: Re: [PWE3] RFC 5086 : CCS signaling query X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:38:15 -0000 Srivatsan hi, I apologize for a delayed response. My understanding of the context for your question is like following: - You are using a CESoPSN PW to transport a group of timeslots between a pai= r of CEs - These CEs run a telephony application using CCS. If this is the case, treating the timeslot that carries CCS as the bearer an= d including it into the same CESoPSN PW *with M bits set to the value that r= eflects RDI if necessary) would be clearly OK. Please note that this is exactly what would happen if you were using a SAToP= PW to carry an entire E1 or T1 between the said pair of CEs. (You would probably want to operate this CESoPSN PW in the mode that emulate= s fractional E1/T1 to make it as close to a SAToP PW as possible.) Hopefully this note addresses your concerns. Regards, Sasha > -----Original Message----- > From: Srivatsan Raghavan [mailto:srivatsan.raghavan@aricent.com] > Sent: Wednesday, January 04, 2012 3:26 PM > To: Alexander Vainshtein; pwe3 > Subject: RE: RFC 5086 : CCS signaling query > > Hi Sasha > > Thanks for your response. > > Given the fact there is no IETF document which describes the procedure for > CCS encoding in CW, is then the general guideline to treat CCS traffic as > bearer traffic [ and set M bits to 00 ] ? > > Thx > Srivatsan > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Wednesday, January 04, 2012 1:57 PM > To: Srivatsan Raghavan; pwe3 > Subject: RE: RFC 5086 : CCS signaling query > > Srivatsan hi, > AFAIK, there are no documents that describe encoding of CE application > states for telephony applications using CCS. > > Regards, > Sasha > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > > Of Srivatsan Raghavan > > Sent: Wednesday, January 04, 2012 9:28 AM > > To: pwe3 > > Subject: [PWE3] RFC 5086 : CCS signalling query > > > > Hi authors > > > > > > RFC 5086 states [ in Section 5.3 ] that > > " Encoding of CE application state for telephony application using CCS > will > > be considered in a separate document. " > > > > Could the authors point out if a separate document exists for CCS > encoding > > ? > > > > Specifically, should CCS be treated as > > i) pure bearer [ and M bits in CW set to 00 ] and CCS time slot > interpretation > > left to the end points [ to recover SS7 messages etc.], that is intermed= iate > > nodes doing PW encap/decap need not attach any meaning to CCS > > > > or > > > > ii) treated as signaling [ and M bits set to 11 ] > > > > > > > > Thx > > Srivatsan > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us= by > e-mail, phone or fax, and then delete the original and all copies thereof. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From skraza@cisco.com Wed Jan 11 09:50:02 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A572921F8674 for ; Wed, 11 Jan 2012 09:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDqEphx1r2-e for ; Wed, 11 Jan 2012 09:50:01 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5C21F8629 for ; Wed, 11 Jan 2012 09:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=2610; q=dns/txt; s=iport; t=1326304201; x=1327513801; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=36zU7isGk/k7Oh+18A8JCHK7qYRYm2BLt0MgE378SEI=; b=AyykkBriIbbgGuIzi3yBsvpNv3sCXCxSbL2tb9C1Sude9xHP1Cla0hdC /JoQ30PvcVinv+puaspxyIA6GEUiEHUdqocVzfEAquJeTywmdWYT27a3z 00LJTXt3MXlfTqAVV00Yo9Dpt6sPmjrNPlllD/h4uabjkTbR7E5zz9Gvl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGADHLDU+tJV2c/2dsb2JhbABCrQICgQWBcgEBAQQSAScCATwSARkDAQJ+CAEBBAENBSKgZQGeRYwdBIg6jFKOI4Q3 X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; d="scan'208";a="50354226" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jan 2012 17:50:01 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q0BHo0ar028895; Wed, 11 Jan 2012 17:50:00 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 11:50:00 -0600 Received: from 161.44.193.212 ([161.44.193.212]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jan 2012 17:50:00 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 11 Jan 2012 12:50:04 -0500 From: Kamran Raza To: , Siva Sivabalan via prrq Message-ID: Thread-Topic: "Typed Wildcard FEC" format for "P2MP PW FEC element" Thread-Index: AczPyBORVDX/0jmxSgG+iPIklnBj6AAwV8eV In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jan 2012 17:50:00.0833 (UTC) FILETIME=[70CAAF10:01CCD089] Cc: "Malis, Andrew G \(Andy\)" , "Carlos Pignataro \(cpignata\)" , pwe3@ietf.org Subject: [PWE3] "Typed Wildcard FEC" format for "P2MP PW FEC element" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:50:02 -0000 Dear P2MP-PW authors, Our draft (draft-ietf-pwe3-pw-typed-wc-fec-01) defines the format of LDP Typed Wildcard FEC for PW FEC element types. Currently, this draft defines format for all types of PW FECs PWid 0x80, Gen Pwid 0x81, and P2MP PW 0x82. According to "LDP Typed Wildcard FEC" Spec RFC5918, it is the responsibility of any "new" FEC designer to also define Typed Wildcard format for it. Since your p2mp-pw draft is defining new FEC type P2MP PW (0x82), we think that the better place/home for the definition of P2MP PW Typed Wildcard FEC is your p2mp-pw draft instead of ours. We are sending this email to check if you are okay adding the definition of Typed WC P2MP PW FEC in your draft. This can be just a para in your doc with pointer/reference towards our draft (if you agree with the current def), or some extended version of our definition as you deem appropriate for your FEC. [ Please Note: The similar approach was taken in mLDP spec RFC 6388, which defined new P2MP/MP2MP FEC types as well as their Typed Wildcard format ] We have already spoken to PWE3 WG chairs (CC'ed here) and they are also okay with this proposal. Please let us know so that we can update our draft to remove P2MP PW. Thx, -- Kamran, Sami, Carlos > > ------ Forwarded Message > From: > Date: Mon, 09 Jan 2012 18:36:47 -0800 > To: Syed Kamran Raza > Cc: , , Syed Kamran Raza > > Subject: New Version Notification for > draft-ietf-pwe3-pw-typed-wc-fec-01.txt > > A new version of I-D, draft-ietf-pwe3-pw-typed-wc-fec-01.txt has been > successfully submitted by Kamran Raza and posted to the IETF repository. > > Filename: draft-ietf-pwe3-pw-typed-wc-fec > Revision: 01 > Title: LDP Typed Wildcard FEC for the PW FEC Elements > Creation date: 2012-01-09 > WG ID: pwe3 > Number of pages: 8 > > Abstract: > The "Typed Wildcard Forwarding Equivalence Class (FEC) > Element" > defines an extension to the Label Distribution Protocol (LDP) that > can be used when it is desired to request or withdraw or release all > label bindings for a given FEC Element type. However, a typed > wildcard FEC element must be individually defined for each FEC > element type. This specification defines the typed wildcard FEC > elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW > (0x82) FEC element types. > > > > > > The IETF Secretariat > ------ End of Forwarded Message From msiva@cisco.com Wed Jan 11 10:27:13 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5803321F86D0 for ; Wed, 11 Jan 2012 10:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHreOXiLdYLI for ; Wed, 11 Jan 2012 10:27:12 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8673D21F86AA for ; Wed, 11 Jan 2012 10:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3130; q=dns/txt; s=iport; t=1326306432; x=1327516032; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fWe39hm3c/osT5qviaGN0r8+9jq9l3MAu0kRVnivDlQ=; b=Oatt5H8onE6I+LAYFEUoHwR1RoNxS3h4y+ZywQc9aYIw3N0pnitzR5A4 HFuKhyH7PVyTWY63A+LT3q83WAzkzwOgBc1c1PWV1p7BBomACoE2o3MuI M+epsjcp2sNu5An36CUTpVUynENO5LlKmAVZ8JOWqMXFI/Lpfly0KGOHg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAObTDU+tJV2a/2dsb2JhbABDrQaBBYFyAQEBBBIBHQo/DAQCAQgRAwEBAQsGGAYBTggBAQQBEggaoGUBnkaLOmMEiDqfLQ X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; d="scan'208";a="47762156" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jan 2012 18:27:12 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0BIRCBK026225; Wed, 11 Jan 2012 18:27:12 GMT Received: from xmb-rcd-104.cisco.com ([72.163.62.146]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:27:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 12:27:10 -0600 Message-ID: <45FC0B0A070BF345870B2710BADC670A080D86D2@XMB-RCD-104.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Typed Wildcard FEC" format for "P2MP PW FEC element" Thread-Index: AczPyBORVDX/0jmxSgG+iPIklnBj6AAwV8eVAADo/CA= References: From: "Siva Sivabalan (msiva)" To: "Kamran Raza (skraza)" , X-OriginalArrivalTime: 11 Jan 2012 18:27:11.0970 (UTC) FILETIME=[A2A72C20:01CCD08E] Cc: "Malis, Andrew G \(Andy\)" , "Carlos Pignataro \(cpignata\)" , pwe3@ietf.org Subject: Re: [PWE3] "Typed Wildcard FEC" format for "P2MP PW FEC element" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:27:13 -0000 Hi Kamran, Sure, we can add the definition of Typed WC P2MP PW FEC in the P2MP PW draft. Thanks, Siva -----Original Message----- From: Kamran Raza (skraza)=20 Sent: Wednesday, January 11, 2012 12:50 PM To: draft-ietf-pwe3-p2mp-pw@tools.ietf.org; Siva Sivabalan (msiva) Cc: pwe3@ietf.org; Malis, Andrew G (Andy); matthew.bocci@alcatel-lucent.com; Sami Boutros (sboutros); Carlos Pignataro (cpignata) Subject: "Typed Wildcard FEC" format for "P2MP PW FEC element" Dear P2MP-PW authors, Our draft (draft-ietf-pwe3-pw-typed-wc-fec-01) defines the format of LDP Typed Wildcard FEC for PW FEC element types. Currently, this draft defines format for all types of PW FECs PWid 0x80, Gen Pwid 0x81, and P2MP PW 0x82. According to "LDP Typed Wildcard FEC" Spec RFC5918, it is the responsibility of any "new" FEC designer to also define Typed Wildcard format for it. Since your p2mp-pw draft is defining new FEC type P2MP PW (0x82), we think that the better place/home for the definition of P2MP PW Typed Wildcard FEC is your p2mp-pw draft instead of ours. We are sending this email to check if you are okay adding the definition of Typed WC P2MP PW FEC in your draft. This can be just a para in your doc with pointer/reference towards our draft (if you agree with the current def), or some extended version of our definition as you deem appropriate for your FEC. [ Please Note: The similar approach was taken in mLDP spec RFC 6388, which defined new P2MP/MP2MP FEC types as well as their Typed Wildcard format ] =20 We have already spoken to PWE3 WG chairs (CC'ed here) and they are also okay with this proposal. Please let us know so that we can update our draft to remove P2MP PW. Thx, -- Kamran, Sami, Carlos >=20 > ------ Forwarded Message > From: > Date: Mon, 09 Jan 2012 18:36:47 -0800 > To: Syed Kamran Raza > Cc: , , Syed Kamran Raza > > Subject: New Version Notification for > draft-ietf-pwe3-pw-typed-wc-fec-01.txt >=20 > A new version of I-D, draft-ietf-pwe3-pw-typed-wc-fec-01.txt has been > successfully submitted by Kamran Raza and posted to the IETF repository. >=20 > Filename: draft-ietf-pwe3-pw-typed-wc-fec > Revision: 01 > Title: LDP Typed Wildcard FEC for the PW FEC Elements > Creation date: 2012-01-09 > WG ID: pwe3 > Number of pages: 8 >=20 > Abstract: > The "Typed Wildcard Forwarding Equivalence Class (FEC) > Element" > defines an extension to the Label Distribution Protocol (LDP) that > can be used when it is desired to request or withdraw or release all > label bindings for a given FEC Element type. However, a typed > wildcard FEC element must be individually defined for each FEC > element type. This specification defines the typed wildcard FEC > elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW > (0x82) FEC element types. >=20 >=20 > =20 >=20 >=20 > The IETF Secretariat >=20 ------ End of Forwarded Message From amalis@gmail.com Wed Jan 11 10:36:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82621F874C for ; Wed, 11 Jan 2012 10:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3sxy+ZfM8gu for ; Wed, 11 Jan 2012 10:36:47 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0737721F8747 for ; Wed, 11 Jan 2012 10:36:46 -0800 (PST) Received: by ggnr5 with SMTP id r5so604897ggn.31 for ; Wed, 11 Jan 2012 10:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Y/FSEDWvGtbbN8FPqCFoK+h+dw4SY/ZjIWQedEttWJU=; b=e5sT6k3WxC3Bc+IfjtuaHBNrir+QXZsWTfOfP2rI2R8PJuGvXy1MqdbPZl9fIK9l2S 4O8NGmMe5vkjybjrWMjI125srQCrTtM0CxbMj/WkRP6GtwnrXi5bl2ycRHfYofWweo6S R3LW1e8nMsXYeOzbDF3pt4V3NaX6/bc7VUZgQ= Received: by 10.50.222.233 with SMTP id qp9mr7938087igc.1.1326307006237; Wed, 11 Jan 2012 10:36:46 -0800 (PST) MIME-Version: 1.0 Sender: amalis@gmail.com Received: by 10.50.158.196 with HTTP; Wed, 11 Jan 2012 10:36:25 -0800 (PST) In-Reply-To: <45FC0B0A070BF345870B2710BADC670A080D86D2@XMB-RCD-104.cisco.com> References: <45FC0B0A070BF345870B2710BADC670A080D86D2@XMB-RCD-104.cisco.com> From: "Andrew G. Malis" Date: Wed, 11 Jan 2012 13:36:25 -0500 X-Google-Sender-Auth: nZvaJWg1nASpu390BZpSXfuXE3w Message-ID: To: "Siva Sivabalan (msiva)" Content-Type: multipart/alternative; boundary=14dae93406d7f84c9f04b644e9f3 Cc: "Carlos Pignataro \(cpignata\)" , pwe3@ietf.org, draft-ietf-pwe3-p2mp-pw@tools.ietf.org Subject: Re: [PWE3] "Typed Wildcard FEC" format for "P2MP PW FEC element" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:36:48 -0000 --14dae93406d7f84c9f04b644e9f3 Content-Type: text/plain; charset=ISO-8859-1 Siva, Thanks! Kamran, Please send a summary to the WG on moving the definition to the p2mp-pw draft, and you can say that this has been agreed by the authors of both drafts and the WG chairs. Thanks, Andy On Wed, Jan 11, 2012 at 1:27 PM, Siva Sivabalan (msiva) wrote: > Hi Kamran, > > Sure, we can add the definition of Typed WC P2MP PW FEC in the P2MP PW > draft. > > Thanks, > Siva > > -----Original Message----- > From: Kamran Raza (skraza) > Sent: Wednesday, January 11, 2012 12:50 PM > To: draft-ietf-pwe3-p2mp-pw@tools.ietf.org; Siva Sivabalan (msiva) > Cc: pwe3@ietf.org; Malis, Andrew G (Andy); > matthew.bocci@alcatel-lucent.com; Sami Boutros (sboutros); Carlos > Pignataro (cpignata) > Subject: "Typed Wildcard FEC" format for "P2MP PW FEC element" > > Dear P2MP-PW authors, > > Our draft (draft-ietf-pwe3-pw-typed-wc-fec-01) defines the format of LDP > Typed Wildcard FEC for PW FEC element types. Currently, this draft > defines > format for all types of PW FECs PWid 0x80, Gen Pwid 0x81, and P2MP PW > 0x82. > > According to "LDP Typed Wildcard FEC" Spec RFC5918, it is the > responsibility > of any "new" FEC designer to also define Typed Wildcard format for it. > Since > your p2mp-pw draft is defining new FEC type P2MP PW (0x82), we think > that > the better place/home for the definition of P2MP PW Typed Wildcard FEC > is > your p2mp-pw draft instead of ours. > > We are sending this email to check if you are okay adding the definition > of > Typed WC P2MP PW FEC in your draft. This can be just a para in your doc > with > pointer/reference towards our draft (if you agree with the current def), > or > some extended version of our definition as you deem appropriate for your > FEC. > > [ Please Note: The similar approach was taken in mLDP spec RFC 6388, > which > defined new P2MP/MP2MP FEC types as well as their Typed Wildcard format > ] > > We have already spoken to PWE3 WG chairs (CC'ed here) and they are also > okay > with this proposal. Please let us know so that we can update our draft > to > remove P2MP PW. > > Thx, > > -- Kamran, Sami, Carlos > > > > > ------ Forwarded Message > > From: > > Date: Mon, 09 Jan 2012 18:36:47 -0800 > > To: Syed Kamran Raza > > Cc: , , Syed Kamran Raza > > > > Subject: New Version Notification for > > draft-ietf-pwe3-pw-typed-wc-fec-01.txt > > > > A new version of I-D, draft-ietf-pwe3-pw-typed-wc-fec-01.txt has been > > successfully submitted by Kamran Raza and posted to the IETF > repository. > > > > Filename: draft-ietf-pwe3-pw-typed-wc-fec > > Revision: 01 > > Title: LDP Typed Wildcard FEC for the PW FEC Elements > > Creation date: 2012-01-09 > > WG ID: pwe3 > > Number of pages: 8 > > > > Abstract: > > The "Typed Wildcard Forwarding Equivalence Class (FEC) > > Element" > > defines an extension to the Label Distribution Protocol (LDP) that > > can be used when it is desired to request or withdraw or release > all > > label bindings for a given FEC Element type. However, a typed > > wildcard FEC element must be individually defined for each FEC > > element type. This specification defines the typed wildcard FEC > > elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW > > (0x82) FEC element types. > > > > > > > > > > > > The IETF Secretariat > > > > ------ End of Forwarded Message > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --14dae93406d7f84c9f04b644e9f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Siva,

Thanks!

Kamran,

Please send a summary to the WG = on moving the definition to the p2mp-pw draft, and you can say that this ha= s been agreed by the authors of both drafts and the WG chairs.

Thank= s,
Andy

On Wed, Jan 11, 2012 at 1:27 PM, Siv= a Sivabalan (msiva) <msiva@cisco.com> wrote:
Hi Kamran,

Sure, we can add the definition of Typed WC P2MP PW FEC in the P2MP PW
draft.

Thanks,
Siva

-----Original Message-----
From: Kamran Raza (skraza)
Sent: Wednesday, January 11, 2012 12:50 PM
To: draft-ietf-pw= e3-p2mp-pw@tools.ietf.org; Siva Sivabalan (msiva)
Cc: pwe3@ietf.org; Malis, Andrew G (An= dy);
matthew.bocci@alcatel-l= ucent.com; Sami Boutros (sboutros); Carlos
Pignataro (cpignata)
Subject: "Typed Wildcard FEC" format for "P2MP PW FEC elemen= t"

Dear P2MP-PW authors,

Our draft (draft-ietf-pwe3-pw-typed-wc-fec-01) defines the format of LDP Typed Wildcard FEC for PW FEC element types. Currently, this draft
defines
format for all types of PW FECs PWid 0x80, Gen Pwid 0x81, and P2MP PW
0x82.

According to "LDP Typed Wildcard FEC" Spec RFC5918, it is the
responsibility
of any "new" FEC designer to also define Typed Wildcard format fo= r it.
Since
your p2mp-pw draft is defining new FEC type P2MP PW (0x82), we think
that
the better place/home for the definition of P2MP PW Typed Wildcard FEC
is
your p2mp-pw draft instead of ours.

We are sending this email to check if you are okay adding the definition of
Typed WC P2MP PW FEC in your draft. This can be just a para in your doc
with
pointer/reference towards our draft (if you agree with the current def), or
some extended version of our definition as you deem appropriate for your FEC.

[ Please Note: The similar approach was taken in mLDP spec RFC 6388,
which
defined new P2MP/MP2MP FEC types as well as their Typed Wildcard format
]

We have already spoken to PWE3 WG chairs (CC'ed here) and they are also=
okay
with this proposal. Please let us know so that we can update our draft
to
remove P2MP PW.

Thx,

-- Kamran, Sami, Carlos

>
> ------ Forwarded Message
> From: <internet-drafts@= ietf.org>
> Date: Mon, 09 Jan 2012 18:36:47 -0800
> To: Syed Kamran Raza <skraza@ci= sco.com>
> Cc: <cpignata@cisco.com&g= t;, <sboutros@cisco.com>, S= yed Kamran Raza
> <skraza@cisco.com>
> Subject: New Version Notification for
> draft-ietf-pwe3-pw-typed-wc-fec-01.txt
>
> A new version of I-D, draft-ietf-pwe3-pw-typed-wc-fec-01.txt has been<= br> > successfully submitted by Kamran Raza and posted to the IETF
repository.
>
> Filename: =A0draft-ietf-pwe3-pw-typed-wc-fec
> Revision: =A001
> Title: =A0 LDP Typed Wildcard FEC for the PW FEC Elements
> Creation date: =A02012-01-09
> WG ID: =A0 pwe3
> Number of pages: 8
>
> Abstract:
> =A0 =A0The &quot;Typed Wildcard Forwarding Equivalence Class (FEC)=
> Element&quot;
> =A0 =A0defines an extension to the Label Distribution Protocol (LDP) t= hat
> =A0 =A0can be used when it is desired to request or withdraw or releas= e
all
> =A0 =A0label bindings for a given FEC Element type. =A0However, a type= d
> =A0 =A0wildcard FEC element must be individually defined for each FEC<= br> > =A0 =A0element type. =A0This specification defines the typed wildcard = FEC
> =A0 =A0elements for the PWid (0x80), Generalized PWid (0x81), and P2MP= PW
> =A0 =A0(0x82) FEC element types.
>
>
>
>
>
> The IETF Secretariat
>

------ End of Forwarded Message

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

--14dae93406d7f84c9f04b644e9f3-- From skraza@cisco.com Wed Jan 11 10:59:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D136411E8073 for ; Wed, 11 Jan 2012 10:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxaZUg4cpkhj for ; Wed, 11 Jan 2012 10:59:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9420111E807A for ; Wed, 11 Jan 2012 10:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=11652; q=dns/txt; s=iport; t=1326308389; x=1327517989; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=LyBeLZOOzEgoVNWcsWTNcVjznkH27Ktsc9WCZM3q7Qw=; b=dQSiPCZsv3rGDoOT2wTdCpNDzFTdp3d2dZPoBhGwSTYreTIXUTTFkZ0o JLSWVbMLDP6mBYWS6Ng6wMzdSRLg0Usi12jIFCJz5RcXMs3/h5SUJ+fav Tx9oKnurgMOQTsIi4OWirNI+IpXexg/bnm22lYQJ0vAnm2W8hcadqzeol 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQ6AAXcDU+tJV2a/2dsb2JhbABAA4JOqUJ0AoEFDIFmAQEBAwEBAQEPASoYEQgLBQcGAQgRAwEBAQFVKAgBAQQBDQUih1gImQcBnk+IfIMhBIgHM4xSjiOENw X-IronPort-AV: E=Sophos;i="4.71,494,1320624000"; d="scan'208,217";a="50396780" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jan 2012 18:59:49 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0BIxnDZ009127; Wed, 11 Jan 2012 18:59:49 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:59:48 -0600 Received: from 161.44.193.212 ([161.44.193.212]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jan 2012 18:59:48 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 11 Jan 2012 13:59:49 -0500 From: Kamran Raza To: "Andrew G. Malis" , "Siva Sivabalan (msiva)" Message-ID: Thread-Topic: [PWE3] "Typed Wildcard FEC" format for "P2MP PW FEC element" Thread-Index: AczQkzEiqEZ/WtK27Uy0Jke/i172MA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3409135192_3232578" X-OriginalArrivalTime: 11 Jan 2012 18:59:48.0979 (UTC) FILETIME=[311F0C30:01CCD093] Cc: "Carlos Pignataro \(cpignata\)" , pwe3@ietf.org, draft-ietf-pwe3-p2mp-pw@tools.ietf.org Subject: Re: [PWE3] "Typed Wildcard FEC" format for "P2MP PW FEC element" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:59:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3409135192_3232578 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks Siva. In summary: 1. I will update draft-ietf-pwe3-pw-typed-wc-fec-01 to remove P2MP FEC and its references from our draft. 2. We can work together to port this definition to p2mp-pw draft, and then p2mp-p2 authors can update it accordingly. Best Rgds. -- Kamran On 12-01-11 1:36 PM, "Andrew G. Malis" wrote: > Siva, >=20 > Thanks! >=20 > Kamran, >=20 > Please send a summary to the WG on moving the definition to the p2mp-pw d= raft, > and you can say that this has been agreed by the authors of both drafts a= nd > the WG chairs. >=20 > Thanks, > Andy >=20 > On Wed, Jan 11, 2012 at 1:27 PM, Siva Sivabalan (msiva) > wrote: >> Hi Kamran, >>=20 >> Sure, we can add the definition of Typed WC P2MP PW FEC in the P2MP PW >> draft. >>=20 >> Thanks, >> Siva >>=20 >> -----Original Message----- >> From: Kamran Raza (skraza) >> Sent: Wednesday, January 11, 2012 12:50 PM >> To: draft-ietf-pwe3-p2mp-pw@tools.ietf.org; Siva Sivabalan (msiva) >> Cc: pwe3@ietf.org; Malis, Andrew G (Andy); >> matthew.bocci@alcatel-lucent.com; Sami Boutros (sboutros); Carlos >> Pignataro (cpignata) >> Subject: "Typed Wildcard FEC" format for "P2MP PW FEC element" >>=20 >> Dear P2MP-PW authors, >>=20 >> Our draft (draft-ietf-pwe3-pw-typed-wc-fec-01) defines the format of LDP >> Typed Wildcard FEC for PW FEC element types. Currently, this draft >> defines >> format for all types of PW FECs PWid 0x80, Gen Pwid 0x81, and P2MP PW >> 0x82. >>=20 >> According to "LDP Typed Wildcard FEC" Spec RFC5918, it is the >> responsibility >> of any "new" FEC designer to also define Typed Wildcard format for it. >> Since >> your p2mp-pw draft is defining new FEC type P2MP PW (0x82), we think >> that >> the better place/home for the definition of P2MP PW Typed Wildcard FEC >> is >> your p2mp-pw draft instead of ours. >>=20 >> We are sending this email to check if you are okay adding the definition >> of >> Typed WC P2MP PW FEC in your draft. This can be just a para in your doc >> with >> pointer/reference towards our draft (if you agree with the current def), >> or >> some extended version of our definition as you deem appropriate for your >> FEC. >>=20 >> [ Please Note: The similar approach was taken in mLDP spec RFC 6388, >> which >> defined new P2MP/MP2MP FEC types as well as their Typed Wildcard format >> ] >>=20 >> We have already spoken to PWE3 WG chairs (CC'ed here) and they are also >> okay >> with this proposal. Please let us know so that we can update our draft >> to >> remove P2MP PW. >>=20 >> Thx, >>=20 >> -- Kamran, Sami, Carlos >>=20 >>> > >>> > ------ Forwarded Message >>> > From: >>> > Date: Mon, 09 Jan 2012 18:36:47 -0800 >>> > To: Syed Kamran Raza >>> > Cc: , , Syed Kamran Raza >>> > >>> > Subject: New Version Notification for >>> > draft-ietf-pwe3-pw-typed-wc-fec-01.txt >>> > >>> > A new version of I-D, draft-ietf-pwe3-pw-typed-wc-fec-01.txt has been >>> > successfully submitted by Kamran Raza and posted to the IETF >> repository. >>> > >>> > Filename: =A0draft-ietf-pwe3-pw-typed-wc-fec >>> > Revision: =A001 >>> > Title: =A0 LDP Typed Wildcard FEC for the PW FEC Elements >>> > Creation date: =A02012-01-09 >>> > WG ID: =A0 pwe3 >>> > Number of pages: 8 >>> > >>> > Abstract: >>> > =A0 =A0The "Typed Wildcard Forwarding Equivalence Class (FEC) >>> > Element" >>> > =A0 =A0defines an extension to the Label Distribution Protocol (LDP) that >>> > =A0 =A0can be used when it is desired to request or withdraw or release >> all >>> > =A0 =A0label bindings for a given FEC Element type. =A0However, a typed >>> > =A0 =A0wildcard FEC element must be individually defined for each FEC >>> > =A0 =A0element type. =A0This specification defines the typed wildcard FEC >>> > =A0 =A0elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW >>> > =A0 =A0(0x82) FEC element types. >>> > >>> > >>> > >>> > >>> > >>> > The IETF Secretariat >>> > >>=20 >> ------ End of Forwarded Message >>=20 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --B_3409135192_3232578 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] "Typed Wildcard FEC" format for "P2MP PW F= EC element" Thanks Siva.

In summary:
  1. I will update draft-ietf-pwe3-pw-typed-wc-fec-01 to = remove P2MP FEC and its references from our draft.
  2. We can work together to  port this definition to p2= mp-pw draft, and then p2mp-p2 authors can update it accordingly.

Best Rgds.
-- Kamran

On 12-01-11 1:36 PM, "Andrew G. Malis" <andrew.g.malis@verizon.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Siva,

Thanks!

Kamran,

Please send a summary to the WG on moving the definition to the p2mp-pw dra= ft, and you can say that this has been agreed by the authors of both drafts = and the WG chairs.

Thanks,
Andy

On Wed, Jan 11, 2012 at 1:27 PM, Siva Sivabalan (msiva) <msiva@cisco.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hi Kamran,

Sure, we can add the definition of Typed WC P2MP PW FEC in the P2MP PW
draft.

Thanks,
Siva

-----Original Message-----
From: Kamran Raza (skraza)
Sent: Wednesday, January 11, 2012 12:50 PM
To: draft-ietf-pwe3-p2mp-p= w@tools.ietf.org; Siva Sivabalan (msiva)
Cc: pwe3@ietf.org; Malis, Andrew G (Andy);
matthew.bocci@alcatel-lucent.com= ; Sami Boutros (sboutros); Carlos
Pignataro (cpignata)
Subject: "Typed Wildcard FEC" format for "P2MP PW FEC elemen= t"

Dear P2MP-PW authors,

Our draft (draft-ietf-pwe3-pw-typed-wc-fec-01) defines the format of LDP Typed Wildcard FEC for PW FEC element types. Currently, this draft
defines
format for all types of PW FECs PWid 0x80, Gen Pwid 0x81, and P2MP PW
0x82.

According to "LDP Typed Wildcard FEC" Spec RFC5918, it is the
responsibility
of any "new" FEC designer to also define Typed Wildcard format fo= r it.
Since
your p2mp-pw draft is defining new FEC type P2MP PW (0x82), we think
that
the better place/home for the definition of P2MP PW Typed Wildcard FEC
is
your p2mp-pw draft instead of ours.

We are sending this email to check if you are okay adding the definition of
Typed WC P2MP PW FEC in your draft. This can be just a para in your doc
with
pointer/reference towards our draft (if you agree with the current def), or
some extended version of our definition as you deem appropriate for your FEC.

[ Please Note: The similar approach was taken in mLDP spec RFC 6388,
which
defined new P2MP/MP2MP FEC types as well as their Typed Wildcard format
]

We have already spoken to PWE3 WG chairs (CC'ed here) and they are also
okay
with this proposal. Please let us know so that we can update our draft
to
remove P2MP PW.

Thx,

-- Kamran, Sami, Carlos

>
> ------ Forwarded Message
> From: <internet-drafts@ietf.org<= /a>>
> Date: Mon, 09 Jan 2012 18:36:47 -0800
> To: Syed Kamran Raza <skraza@cisco.com>
> Cc: <cpignata@cisco.com>, <<= a href=3D"sboutros@cisco.com">sboutros@cisco.com>, Syed Kamran Raza
> <skraza@cisco.com>
> Subject: New Version Notification for
> draft-ietf-pwe3-pw-typed-wc-fec-01.txt
>
> A new version of I-D, draft-ietf-pwe3-pw-typed-wc-fec-01.txt has been<= BR> > successfully submitted by Kamran Raza and posted to the IETF
repository.
>
> Filename: =A0draft-ietf-pwe3-pw-typed-wc-fec
> Revision: =A001
> Title: =A0 LDP Typed Wildcard FEC for the PW FEC Elements
> Creation date: =A02012-01-09
> WG ID: =A0 pwe3
> Number of pages: 8
>
> Abstract:
> =A0 =A0The &quot;Typed Wildcard Forwarding Equivalence Class (FEC)
> Element&quot;
> =A0 =A0defines an extension to the Label Distribution Protocol (LDP) that<= BR> > =A0 =A0can be used when it is desired to request or withdraw or release all
> =A0 =A0label bindings for a given FEC Element type. =A0However, a typed
> =A0 =A0wildcard FEC element must be individually defined for each FEC
> =A0 =A0element type. =A0This specification defines the typed wildcard FEC > =A0 =A0elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW<= BR> > =A0 =A0(0x82) FEC element types.
>
>
>
>
>
> The IETF Secretariat
>

------ End of Forwarded Message

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

=
--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.co= m



--B_3409135192_3232578-- From matthew.bocci@alcatel-lucent.com Thu Jan 12 10:41:25 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73ECA21F867B for ; Thu, 12 Jan 2012 10:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzxE-KGz6Bqm for ; Thu, 12 Jan 2012 10:41:24 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 90FB421F8679 for ; Thu, 12 Jan 2012 10:41:23 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0CIfMK2027398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 12 Jan 2012 19:41:22 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 12 Jan 2012 19:41:22 +0100 From: "Bocci, Matthew (Matthew)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Thu, 12 Jan 2012 19:41:20 +0100 Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: AczRWcdfVaKeiyTTRQqP/aF9xGtJGg== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB34D40E20E19matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-pw-vccv-impl-survey-results-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:41:25 -0000 --_000_CB34D40E20E19matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We did not receive any comments on this draft. I have a few editorial comme= nts below, but subject to those being addressed by the authors, since this = draft is simply an informational document detailing the results of a survey= that was requested by the working group and which has been reviewed a numb= er of times in the past, I think we can move forward with its publication. I will send a document shepherd write up shortly. My comments are as follows: 1. Introduction: "The PWE3 working group has defined many encapsulations of various Layer 1 and Layer 2 links. Within these encapsulations, there are often several modes of encapsulation which have differing requirements in order to fully emulate the service. As such, the use of the PWE3 Control Word is mandated in many of the encapsulations, but not all. This can present interoperability issues related to A) Control Word use and B) VCCV Control Channel negotiation in mixed implementation environments." 1st sentence: I think you should refer to the IETF rather than the PWE3 wor= king group here, since we are talking about IETF consensus documents. Also, I think we should say that encapsulate layer 1 and layer 2 service-sp= ecific PDUs and circuit data, rather than links (as per RFC3985). 2) Acknowledgements: I think it would be good to list the respondents liste= d in section 2.1 in the acknowledgements section. 3) References: I think the reference to RFC2119 can be removed. You can als= o remove the section on RFC2119 language since it is not used in this infor= mational document. I think you should also add complete references for all= of the RFCs referenced in the body of the document to the informative refe= rences section. Best regards, Matthew On 23/11/2011 15:42, "Bocci, Matthew (Matthew)" > wrote: This email begins a two week working group last call for draft-ietf-pwe3-pw= -vccv-impl-survey-results-00. Please post any comments to the PWE3 mailing list. This working group last call will end on Thursday 8th December 2011. Regards, Matthew & Andy --_000_CB34D40E20E19matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,

We did not receive any comments on this draft. I have a few editorial= comments below, but subject to those being addressed by the authors, since= this draft is simply an informational document detailing the results of a = survey that was requested by the working group and which has been reviewed = a number of times in the past, I think we can move forward with its publica= tion.

I will send a document shepherd write up sho= rtly.

My comments are as follows:

  1. Introduction:

    "The PWE3 work= ing group has defined many encapsulations of various
       = ;Layer 1 and Layer 2 links.  Within these encapsulations, there are
       often several modes of encapsulation which have differ= ing
       requirements in order to fully emulate the servi= ce.  As such, the use
       of the PWE3 Control Word = is mandated in many of the encapsulations,
       but not a= ll.  This can present interoperability issues related to A)
    =    Control Word use and B) VCCV Control Channel negotiation in mi= xed
       implementation environments."
    1st sentence: I think you should refer to the IETF rather than= the PWE3 working group here, since we are talking about IETF consensus doc= uments.
    Also, I think we should say that encapsulate layer 1 and = layer 2 service-specific PDUs and circuit data, rather than links (as per R= FC3985).

    2) Acknowledgements: I think it would be = good to list the respondents listed in section 2.1 in the acknowledgements = section.

    3) References: I think the reference to R= FC2119 can be removed. You can also remove the section on RFC2119 language = since it is not used in this informational document.  I think you shou= ld also add complete references for all of the RFCs referenced in the body = of the document to the informative references section.
= Best regards,

Matthew

On 23/11/2011 15:42, "Bocci, Matthew (M= atthew)" <matthew.bo= cci@alcatel-lucent.com> wrote:

This email begins a two week working group last call for draft-ietf-= pwe3-pw-vccv-impl-survey-results-00.

Please post a= ny comments to the PWE3 mailing list.

This working= group last call will end on Thursday 8th December 2011.

Regards,

Matthew & Andy
--_000_CB34D40E20E19matthewboccialcatellucentcom_-- From internet-drafts@ietf.org Thu Jan 12 11:17:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E388021F8636; Thu, 12 Jan 2012 11:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UECVNH6ThTH; Thu, 12 Jan 2012 11:17:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCFC21F8589; Thu, 12 Jan 2012 11:17:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112191746.12104.36205.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 11:17:46 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:17:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : LDP Typed Wildcard FEC for PWid and Generalized PWid FEC= Elements Author(s) : Kamran Raza Sami Boutros Carlos Pignataro Filename : draft-ietf-pwe3-pw-typed-wc-fec-02.txt Pages : 7 Date : 2012-01-12 The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-02.txt From amalis@gmail.com Thu Jan 12 11:48:56 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8FE21F8613 for ; Thu, 12 Jan 2012 11:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-Sc79L-LAUn for ; Thu, 12 Jan 2012 11:48:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D54221F855E for ; Thu, 12 Jan 2012 11:48:56 -0800 (PST) Received: by ggnr5 with SMTP id r5so1425702ggn.31 for ; Thu, 12 Jan 2012 11:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=Papo/3bHEyRFpMUqPJXnGMVsSEuiP/Zi4rx6SAondSE=; b=nvkuEZDOmkEH3g8OeIe+WRXSH0LENiHjJDO8bWwSkVvr1twUq/FGualcpxfP4BETwt 1wGGRJAVXbvkFyFNerKTuXlTH2kXQM+1vNYduHK39JTMfmkpNxNEByBOwE894VZzhHOu cTbFV0m7VlnS03c+8srKvgxE7izu9wKwbYwVU= Received: by 10.50.36.230 with SMTP id t6mr5808713igj.5.1326397735810; Thu, 12 Jan 2012 11:48:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.158.196 with HTTP; Thu, 12 Jan 2012 11:48:32 -0800 (PST) From: "Andrew G. Malis" Date: Thu, 12 Jan 2012 14:48:32 -0500 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=14dae934054fdfb66304b65a09bd Subject: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:48:56 -0000 --14dae934054fdfb66304b65a09bd Content-Type: text/plain; charset=ISO-8859-1 This email begins a two week working group last call for draft-ietf-pwe3-pw-typed-wc-fec-02. Please post any comments to the PWE3 mailing list. This working group last call will end on Thursday 26 January 2012. Regards, Andy & Matthew --14dae934054fdfb66304b65a09bd Content-Type: text/html; charset=ISO-8859-1
This email begins a two week working group last call for draft-ietf-pwe3-pw-typed-wc-fec-02.

Please post any comments to the PWE3 mailing list.

This working group last call will end on Thursday 26 January 2012.

Regards,
Andy & Matthew

--14dae934054fdfb66304b65a09bd-- From zheng.zhi@zte.com.cn Fri Jan 13 00:52:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6771721F8470 for ; Fri, 13 Jan 2012 00:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.035 X-Spam-Level: X-Spam-Status: No, score=-101.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsgvREJa0Gjf for ; Fri, 13 Jan 2012 00:52:06 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E0C8921F8476 for ; Fri, 13 Jan 2012 00:52:03 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901397396305; Fri, 13 Jan 2012 16:29:45 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 81125.1397396305; Fri, 13 Jan 2012 16:51:36 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id q0D8pmcu038353 for ; Fri, 13 Jan 2012 16:51:48 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Message-Id: <201201130851.q0D8pmcu038353@mse02.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0D8nssA033495; Fri, 13 Jan 2012 16:49:55 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) To: draft-ietf-pwe3-iccp@tools.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: Ryan Zheng Date: Fri, 13 Jan 2012 16:49:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-13 16:49:57, Serialize complete at 2012-01-13 16:49:57 Content-Type: multipart/alternative; boundary="=_alternative 0030A6AC48257984_=" X-MAIL: mse02.zte.com.cn q0D8pmcu038353 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: pwe3@ietf.org Subject: [PWE3] Question on draft-ietf-pwe3-iccp-06 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 08:52:07 -0000 This is a multipart message in MIME format. --=_alternative 0030A6AC48257984_= Content-Type: text/plain; charset="US-ASCII" Hi Luca and other authors, One question on this draft: In Section 11.2, a new LDP TLV is suggested: Type Description 0x701 LDP TCP/IP Port TLV But I did not find any other description about this new TLV in the draft. Could you make some clarifications about this TLV? Like format, usage...That will be appreciated. Thanks a lot! Ryan --=_alternative 0030A6AC48257984_= Content-Type: text/html; charset="US-ASCII"
Hi Luca and other authors,

One question on this draft:

In Section 11.2, a new LDP TLV is suggested:
Type  Description
0x701 LDP TCP/IP Port TLV

But I did not find any other description about this new TLV in the draft.

Could you make some clarifications about this TLV? Like format, usage...That will be appreciated.

Thanks a lot!

Ryan --=_alternative 0030A6AC48257984_=-- From agmalis@gmail.com Fri Jan 13 02:58:41 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5082321F85F1; Fri, 13 Jan 2012 02:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr2P6ztzYa6I; Fri, 13 Jan 2012 02:58:40 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7747421F8565; Fri, 13 Jan 2012 02:58:40 -0800 (PST) Received: by qcsc1 with SMTP id c1so234103qcs.31 for ; Fri, 13 Jan 2012 02:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pKZzjJ5xHHCDs1650CJJDWBj3iS31Y38YZw2pUoyn+I=; b=UG+lNakycHtApIhEzcUyq7wUf/hBNO/gA/00+Sqhx6inuXEjmFEVKFBm7GbK9C0XdW jH/EV0vX3I5Bo7fcS+RTedFvocz89AS694H9zqoanQ+uq3l1UHq1+Dfah0KK9HXn9MPz vAM7zh9fzbwbemchAYPgvcxK4yjtIbmy/aDW8= Received: by 10.229.136.70 with SMTP id q6mr66498qct.137.1326452317260; Fri, 13 Jan 2012 02:58:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.84.130 with HTTP; Fri, 13 Jan 2012 02:58:16 -0800 (PST) In-Reply-To: <4F100B87.7000905@pi.nu> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> <4F100B87.7000905@pi.nu> From: "Andrew G. Malis" Date: Fri, 13 Jan 2012 05:58:16 -0500 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , pwe3@ietf.org, "ietf@ietf.org" Subject: Re: [PWE3] [mpls] point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 10:58:41 -0000 Also taking my chair hat off ... as Malcolm stated that G.8113.1 applies to PWs, and the requested allocation is in a registry that originated in the PWE3 working group, I agree that a PWE3 WG last call is warranted. This could certainly take place in parallel with the MPLS WG last call. Cheers, Andy On Fri, Jan 13, 2012 at 5:46 AM, Loa Andersson wrote: > All (taking chair hat off), > > I agree with Ross's comments below that if the document is last called > it should go through a wg last call (pwe3 and mpls) and through an IETF > last call. > > I agree that these last calls could be in parallel is necessary, but I > believe that running the wg last call first and the IETF last call would > be beneficial. Given that we have a stable document with stable > references to last call. > > /Loa > > > > On 2012-01-13 06:43, Ross Callon wrote: >>> >>> Adrian wrote: >>> My review of the write-up and discussions... >>> >>> 3. There seems to be quite a feeling on the mailing lists that this >>> document >>> should be run through the MPLS working group. The write-up makes a case >>> for >>> progressing it as AD sponsored. As far as I can see, the main assertion= s >>> to >>> answer are as follows. Do you have a view on these points before I make= a >>> decision on what to do? >>> >>> a. This is a proposal to use an MPLS code point and so is part of MPLS = by >>> definition. >>> >>> b. The type of network being managed by the OAM described in G.8113.1 i= s >>> an MPLS >>> network. Therefore, this is clearly relevant to the MPLS working . >>> >>> Do you object to this going through the MPLS on principle, or were you >>> just >>> hoping to save the WG the work? If the latter, and if the WG wants to >>> look at >>> the draft, the easiest approach seems to be to redirect the work to the >>> working >>> group. >> >> >> My personal opinion (speaking as an individual)... >> >> It is pretty clear that there is a lot of interest in this topic in the > > MPLS WG. It also is clear that this proposal is very much about MPLS. > Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MP= LS > WG. >> >> >> It seems clear that the document also needs IETF last call. I assume thi= s > > means that one last call would be posted to both the MPLS and IETF WG lis= ts. >> >> >> It seems that this same last call should also be copied to the PWE3 list= . >> >> Ross >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From matthew.bocci@alcatel-lucent.com Fri Jan 13 09:08:01 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757F221F857A for ; Fri, 13 Jan 2012 09:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.617 X-Spam-Level: X-Spam-Status: No, score=-105.617 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzGDu9cIlT7G for ; Fri, 13 Jan 2012 09:08:00 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id C8CC621F8530 for ; Fri, 13 Jan 2012 09:07:59 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0DH7vIx007733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Jan 2012 18:07:57 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 13 Jan 2012 18:07:57 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Fri, 13 Jan 2012 18:07:56 +0100 Thread-Topic: Document shepherd write-up for draft-ietf-pwe3-packet-pw-02.txt Thread-Index: AczSFeWcRqoaAxEuTxm6oFk3908GMA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB36156C216DBmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [PWE3] Document shepherd write-up for draft-ietf-pwe3-packet-pw-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:08:01 -0000 --_000_CB36156C216DBmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-pwe3-packet-pw-02.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has received significant review by the WG and received a number of comments during WG last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. Although there were was an alternative proposal for a mechanism to support Packet PWs presented at a number of IETFs, that proposal has not been adopted by the working group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are a couple of minor I-D nits related to a copyright dat= e and a missing reference. These should be fixed before publication. There are no formal review criteria. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists and seems reasonable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. This document is a product of the PWE3 working group. This document is BCP. Working Group Summary Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. Document Quality There are no concerns with document quality. --_000_CB36156C216DBmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
draft-ietf-pwe3-pac= ket-pw-02.txt

Document Shepard Write-Up
=

    (1.a) Who is the Document Sheph= erd for this document? Has the 
        =   Document Shepherd personally reviewed this version of the 
          document and, in particular, does = he or she believe this 
          v= ersion is ready for forwarding to the IESG for publication? 

<= /span>Matthew Bocci (matthew.bocci@alcatel-lucent.com)
  &nb= sp;     Yes, I have reviewed the document and I believe it is rea= dy for 
        forwarding to the IESG.<= /div>


    (1.b) Has the documen= t had adequate review both from key WG members 
   = ;       and from key non-WG members? Does the Document Sheph= erd have 
          any concerns ab= out the depth or breadth of the reviews that 
    =       have been performed? 

&n= bsp;       Yes, the document has received adequate review. T= he document has
        received significant = review by the WG and received a number 
     =   of comments during WG last call.


    (1.c) Does the Document Shepherd have concerns that the= document 
          needs more rev= iew from a particular or broader perspective, 
   =       e.g., security, operational complexity, someone famil= iar with 
          AAA, internatio= nalization or XML? 

      &nbs= p;No.


    (1.d) Does the = Document Shepherd have any specific concerns or 
  &nbs= p;       issues with this document that the Responsible Area= Director 
          and/or the IES= G should be aware of? For example, perhaps he 
   =       or she is uncomfortable with certain parts of the doc= ument, or 
          has concerns w= hether there really is a need for it. In any 
    =       event, if the WG has discussed those issues and has in= dicated 
          that it still wi= shes to advance the document, detail those 
    &n= bsp;     concerns here. Has an IPR disclosure related to this doc= ument 
          been filed? If so,= please include a reference to the 
      &nb= sp;   disclosure and summarize the WG discussion and conclusion on&nbs= p;
          this issue. 

       No specific concerns. 


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

   =   I am comfortable that the document represents WG consensus and has<= /div>
      been reviewed by a reasonable number of acti= ve WG participants. 
      Although there wer= e was an alternative proposal for a mechanism to 
  &nb= sp;   support Packet PWs presented at a number of IETFs, that proposal= has
      not been adopted by the working group.&= nbsp;
 

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

      =  None indicated.


   = (1.g) Has the Document Shepherd personally verified that the 
          document satisfies all ID nits? (See&= nbsp;
          http://www.ietf.org/ID-C= hecklist.html and 
          http:/= /tools.ietf.org/tools/idnits/). Boilerplate checks are 
&nbs= p;         not enough; this check needs to be thorough.= Has the document 
          met al= l formal review criteria it needs to, such as the MIB 
 = ;         Doctor, media type and URI type reviews? = ;


       Yes. T= here are a couple of minor I-D nits related to a copyright date 
=
       and a missing reference. These should be fi= xed before publication.
       There are no f= ormal review criteria.

    (1.h) Has the= document split its references into normative and 
  &n= bsp;       informative? Are there normative references to do= cuments that 
          are not rea= dy for advancement or are otherwise in an unclear 
  &n= bsp;       state? If such normative references exist, what i= s the 
          strategy for their= completion? Are there normative references 
    &= nbsp;     that are downward references, as described in [RFC3967]= ? If 
          so, list these down= ward references to support the Area 
      &n= bsp;   Director in the Last Call procedure for them [RFC3967]. 

      Yes, the references are split = appropriately. 



    (1.i) Has the Document Shepherd verified that the document I= ANA 
          consideration sectio= n exists and is consistent with the body 
    &nbs= p;     of the document? If the document specifies protocol <= /div>
          extensions, are reservations r= equested in appropriate IANA 
        &n= bsp; registries? Are the IANA registries clearly identified? If 
=
          the document creates a new registry= , does it define the 
          pro= posed initial contents of the registry and an allocation 
&n= bsp;         procedure for future registrations? Does i= t suggest a 
          reasonable n= ame for the new registry? See [RFC5226]. If the 
  &nbs= p;       document describes an Expert Review process has She= pherd 
          conferred with the= Responsible Area Director so that the IESG 
    &= nbsp;     can appoint the needed Expert during the IESG Evaluatio= n? 

      The IANA considerati= ons section exists and seems reasonable.


    (1.j) Has the Document Shepherd verified that sections = of the 
          document that are= written in a formal language, such as XML 
    &n= bsp;     code, BNF rules, MIB definitions, etc., validate correct= ly in 
          an automated check= er? 

      There are no sectio= ns that use a formal language.


&nbs= p;   (1.k) The IESG approval announcement includes a Document 
          Announcement Write-Up. Please pr= ovide such a Document 
          An= nouncement Write-Up? Recent examples can be found in the
  &= nbsp;       "Action" announcements for approved documents. T= he approval 
          announcement= contains the following sections: 

Technical = Summary

   This document describes a pse= udowire mechanism that is used to
   transport a packet= service over an MPLS PSN is the case where the
   clie= nt LSR and the server PE are co-resident in the same equipment.
&= nbsp;  This pseudowire mechanism may be used to carry all of the requi= red
   layer 2 and layer 3 protocols between the pair o= f client LSRs.

   This document is a pro= duct of the PWE3 working group.

   This = document is BCP.

Working Group Summary
<= br>
   Network transport service providers and their us= ers are
   seeking to rationalize their networks by mig= rating their
   existing services and platforms onto IP= or MPLS enabled
   IP packet switched networks (PSN). = This migration requires
   communications services that= can emulate the essential
   properties of traditional= communications links over a PSN.
   Some service provi= ders wish to use MPLS technology to
   replace existing= transport network infrastructure, relying
   upon pseu= dowire technology is an integral component of
   these = network convergence architectures.

   Ps= eudowire Emulation Edge to Edge (PWE3) will specify the
  &n= bsp;encapsulation, transport, control, management, interworking
&= nbsp;  and security of services emulated over IETF-specified PSNs.

Document Quality

  &nbs= p;There are no concerns with document quality.

--_000_CB36156C216DBmatthewboccialcatellucentcom_-- From lizho.jin@gmail.com Sun Jan 15 05:43:39 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88721F84C4 for ; Sun, 15 Jan 2012 05:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es7rfcVakvMm for ; Sun, 15 Jan 2012 05:43:38 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEDF021F84C3 for ; Sun, 15 Jan 2012 05:43:37 -0800 (PST) Received: by qcsc1 with SMTP id c1so1235116qcs.31 for ; Sun, 15 Jan 2012 05:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZhEEr3lWUuR3QKwr6xK7afY7hpKQo5/p7Kzs9K7r9s4=; b=GrlctgwGQTno/Fyji2IozsQN0i+q9i7iPK9kFHZcqa3Sp+HXLB3XDYMDnKFbzkj9fu sIVHkoaiEwXCr9kT5QK8UqKlHN1u6Lb2FTCs4xJe17Sde12cT/v/Loyek3A2dyVHyaSG 8ejdRRw12KxyVlEncQpPkQsKn3flbzX/B9TkE= MIME-Version: 1.0 Received: by 10.229.77.28 with SMTP id e28mr2903415qck.117.1326635014064; Sun, 15 Jan 2012 05:43:34 -0800 (PST) Received: by 10.224.1.7 with HTTP; Sun, 15 Jan 2012 05:43:34 -0800 (PST) Date: Sun, 15 Jan 2012 21:43:34 +0800 Message-ID: From: Lizhong Jin To: skraza@cisco.com Content-Type: multipart/alternative; boundary=001d605b9febc28a3204b691488d Cc: cpignata@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 13:43:39 -0000 --001d605b9febc28a3204b691488d Content-Type: text/plain; charset=ISO-8859-1 Hi Kamran, I review this new version, and in section 3, it says: "Label TLV in label messages to further constraint the wildcard to all FECs of the specified FEC type [and its specific filter] that are also bound to the specified label." Does that mean, there would be one label allocated for more than one PW-FEC? The PW label would be allocated from the per-platform label space. Could you give me an example that one PW label is allocated for more than one PW-FEC? Thank you. Lizhong > ------------------------------ > > Message: 3 > Date: Thu, 12 Jan 2012 14:48:32 -0500 > From: "Andrew G. Malis" > To: pwe3@ietf.org > Subject: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > This email begins a two week working group last call for > draft-ietf-pwe3-pw-typed-wc-fec-02. > > Please post any comments to the PWE3 mailing list. > > This working group last call will end on Thursday 26 January 2012. > > Regards, > Andy & Matthew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/pwe3/attachments/20120112/c7bfef1f/attachment.htm > > > > ------------------------------ > --001d605b9febc28a3204b691488d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kamran,
I review this new version, and in section 3, it says: "Label TLV = in label messages to further constraint the wildcard to=A0all FECs of the s= pecified FEC type [and its specific filter] that=A0are also bound to the sp= ecified label."
Does that mean, there would be one label allocated for more than one P= W-FEC? The PW label would be allocated from the per-platform label space. C= ould you give me an example that one PW=A0label=A0is allocated for more tha= n one PW-FEC?
=A0
Thank you.
Lizhong
=A0
=A0
------------------------------
Message: 3
Date: Thu, 12 Jan 2012 14:48:32 -0500
From: "Andrew = G. Malis" <amalis@gmail.com= >
To: pwe3@ietf.org
Subject: [PWE3] W= G last call for draft-ietf-pwe3-pw-typed-wc-fec-02
Message-ID:
=A0 = =A0 =A0 =A0<CAK+d4xtmnnxQ5ZppXvYy18ik6LxdbNwp7kyYakC4sVcL=3DEiKFQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

This emai= l begins a two week working group last call for
draft-ietf-pwe3-pw-typed= -wc-fec-02.

Please post any comments to the PWE3 mailing list.

This working group last call will end on Thursday 26 January 2012.
<= br>Regards,
Andy & Matthew
-------------- next part -------------= -
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/pwe3/attachments/20= 120112/c7bfef1f/attachment.htm>

------------------------------
--001d605b9febc28a3204b691488d-- From ssalam@cisco.com Mon Jan 16 14:25:31 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE1921F86A9 for ; Mon, 16 Jan 2012 14:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYTZRJnaLn01 for ; Mon, 16 Jan 2012 14:25:29 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E5E5F21F86AF for ; Mon, 16 Jan 2012 14:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssalam@cisco.com; l=2345; q=dns/txt; s=iport; t=1326752729; x=1327962329; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=eKsJTNGvAxfnSkNCaBB9ON6qs1pB58KDnNKfW4m1QYY=; b=YGEumna8dsAXONYqzKUpYHlTbuZ3diYchodP/Q+IhY+KHKNqG75Mwnul vM3ozWJ9VAUkt9D1aQhOsVs2x4ZnvIN8dINVe8MkLMHK/wM2N4ILAcKGS gceg/m1xZd4lbkPUm65I4kzgUyjT6F+t5RiRYc2regMtuzBCuZ580gvvb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMCiFE+rRDoJ/2dsb2JhbABEgk2pYx1vgQWBcgEBAQMBEgEqPBIBCAQBgRgBAQQOBSKHWJd4AZ4LiV0CAQENBQQRBQEGAQEGAQUMBAEBBgIFAwEBBwEBAgEBBQMBAQEBAoF7gQqEHASIO4xWkmI X-IronPort-AV: E=Sophos;i="4.71,520,1320624000"; d="scan'208,217";a="23963587" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 16 Jan 2012 22:25:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0GMPTHb013061; Mon, 16 Jan 2012 22:25:29 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 14:25:29 -0800 Received: from 10.21.88.32 ([10.21.88.32]) by xmb-sjc-233.amer.cisco.com ([128.107.191.88]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Jan 2012 22:25:29 +0000 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Mon, 16 Jan 2012 14:25:28 -0800 From: Samer Salam To: Ryan Zheng Message-ID: Thread-Topic: Question on draft-ietf-pwe3-iccp-06 Thread-Index: AczUnb/Qmh5aPGLPBke7U7LPiN65cg== In-Reply-To: <201201130851.q0D8pqGa038762@mse02.zte.com.cn> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3409568728_88683354" X-OriginalArrivalTime: 16 Jan 2012 22:25:29.0465 (UTC) FILETIME=[C0B08690:01CCD49D] Cc: Luca Martini , pwe3@ietf.org Subject: Re: [PWE3] Question on draft-ietf-pwe3-iccp-06 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 22:25:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3409568728_88683354 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Ryan, At some point of time, we were envisioning that this TLV would play a role in the setup of dedicated LDP sessions for ICCP transport (per section 4.6). However, that was not pursued, so we should remove the reference to this TLV. Regards, Samer On 12-01-13 12:49 AM, "Ryan Zheng" wrote: > > Hi Luca and other authors, > > One question on this draft: > > In Section 11.2, a new LDP TLV is suggested: > Type Description > 0x701 LDP TCP/IP Port TLV > > But I did not find any other description about this new TLV in the draft. > > Could you make some clarifications about this TLV? Like format, usage...That > will be appreciated. > > Thanks a lot! > > Ryan --B_3409568728_88683354 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: Question on draft-ietf-pwe3-iccp-06 Hi Ryan,

At some point of time, we were envisioning that this TLV would play a role = in the setup of dedicated LDP sessions for ICCP transport (per section 4.6).= However, that was not pursued, so we should remove the reference to this TL= V.

Regards,
Samer


On 12-01-13 12:49 AM, "Ryan Zheng" <zheng.zhi@zte.com.cn> wrote:

<= SPAN STYLE=3D'font-size:11pt'>
Hi Luca and other authors,

One question on this draft:

In Section 11.2, a new LDP TLV is suggested:
Type  Description
0x701 LDP TCP/IP Port TLV

But I did not find any other description about this new TLV in the draft. <= BR>
Could you make some clarifications about this TLV? Like format, usage...Tha= t will be appreciated.

Thanks a lot!

Ryan
--B_3409568728_88683354-- From skraza@cisco.com Tue Jan 17 05:07:27 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE321F8594 for ; Tue, 17 Jan 2012 05:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JD7zcCPqdrM for ; Tue, 17 Jan 2012 05:07:26 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4613C21F8574 for ; Tue, 17 Jan 2012 05:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6537; q=dns/txt; s=iport; t=1326805646; x=1328015246; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=891BSdeFb+IZzrPhbICzVkhs/s1UZcEGVLNLp8tpCmc=; b=W3BPxklIYedb6HGXnUukdt5A1CdA4QFCOdOgdd2W2qa9bOmfvuOMkYrE 3PN/wrYXwbtC/Um4c5uHO69qOfwxePL/puidlc6D8g+jKwG15D6Vg+T2V 161c51be21Rip7A4KkrxxLWRyt4pXT843ZlB9R6nRzmtmcx6jsUBV8j1Y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANZxFU+tJXG8/2dsb2JhbABBA4JNqXIdaYEFgXIBAQEDARIBCiAYEQgLBQ0BCA4DAwECUC4IAQEEDgUJGYdYCJd3AZ5AiV0CAQENBQQRBQEGAQEGAQUMBAEBBgIFAwEBBwEBAgEBCAEBAQOBWwgNBQYFBwEGBxoYBxAnXwIEFoMhBIgIM4xWinuHZA X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208,217";a="49071938" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jan 2012 13:07:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0HD7PLU007375; Tue, 17 Jan 2012 13:07:25 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 07:07:25 -0600 Received: from 10.86.246.62 ([10.86.246.62]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 17 Jan 2012 13:07:24 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 17 Jan 2012 08:07:23 -0500 From: Kamran Raza To: Lizhong Jin Message-ID: Thread-Topic: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 Thread-Index: AczVGPOdWBJdTo/JnkOGz/ioy5ZuTQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3409632443_10261243" X-OriginalArrivalTime: 17 Jan 2012 13:07:25.0449 (UTC) FILETIME=[F512E790:01CCD518] Cc: cpignata@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 13:07:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3409632443_10261243 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Lizhong, Although same label (e.g. Implicit-null) can be used for more than one prefix FEC, currently I do not see an example / usage of same label for PW FEC. However, LDP Typed Wildcard spec/guidelines RFC 5918 allows a FEC designer to possibly constrain Typed Wildcarding in a scope of some label, hence the same applies to Typed WC PW FEC; We should conform to Typed WC guidelines while defining Typed WC FEC for a FEC and hence we should leave this possibility for future even if it does not seem to apply currently. Moreover, It does not harm as it is an optional param anyways. HTC. On 12-01-15 8:43 AM, "Lizhong Jin" wrote: > Hi Kamran, > I review this new version, and in section 3, it says: "Label TLV in label > messages to further constraint the wildcard to=A0all FECs of the specified = FEC > type [and its specific filter] that=A0are also bound to the specified label= ." > Does that mean, there would be one label allocated for more than one PW-F= EC? > The PW label would be allocated from the per-platform label space. Could = you > give me an example that one PW=A0label=A0is allocated for more than one PW-FE= C? > =A0 > Thank you. > Lizhong > =A0 > =A0 >> ------------------------------ >>=20 >> Message: 3 >> Date: Thu, 12 Jan 2012 14:48:32 -0500 >> From: "Andrew G. Malis" >> To: pwe3@ietf.org >> Subject: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 >> Message-ID: >> =A0 =A0 =A0 =A0 >> Content-Type: text/plain; charset=3D"iso-8859-1" >>=20 >> This email begins a two week working group last call for >> draft-ietf-pwe3-pw-typed-wc-fec-02. >>=20 >> Please post any comments to the PWE3 mailing list. >>=20 >> This working group last call will end on Thursday 26 January 2012. >>=20 >> Regards, >> Andy & Matthew >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL:=20 >> > chment.htm> >>=20 >> ------------------------------ >=20 --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --B_3409632443_10261243 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi Lizhong,<BR> <BR> Although same label (e.g. Implicit-null) can be used for more than one pref= ix FEC, currently I do not see an example / usage of same label for PW FEC. = However, LDP Typed Wildcard spec/guidelines RFC 5918 allows a FEC designer t= o possibly constrain Typed Wildcarding in a scope of some label, hence the s= ame applies to Typed WC PW FEC;  We should conform to Typed WC guidelin= es while defining Typed WC FEC for a FEC and hence we should leave this poss= ibility for future even if it does not seem to apply currently. Moreover, It= does not harm as it is an optional param anyways.<BR> <BR> HTC.<BR> <BR> On 12-01-15 8:43 AM, "Lizhong Jin" <<a href=3D"lizho.jin@gmail.c= om">lizho.jin@gmail.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Hi Kamran,<BR> I review this new version, and in section 3, it says: "Label TLV in la= bel messages to further constraint the wildcard to=A0all FECs of the specified= FEC type [and its specific filter] that=A0are also bound to the specified lab= el."<BR> Does that mean, there would be one label allocated for more than one PW-FEC= ? The PW label would be allocated from the per-platform label space. Could y= ou give me an example that one PW=A0label=A0is allocated for more than one PW-FE= C?<BR> =A0<BR> Thank you.<BR> Lizhong<BR> =A0<BR> =A0<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>------------------------------<BR> <BR> Message: 3<BR> Date: Thu, 12 Jan 2012 14:48:32 -0500<BR> From: "Andrew G. Malis" <<a href=3D"amalis@gmail.com">amalis@gma= il.com</a>><BR> To: <a href=3D"pwe3@ietf.org">pwe3@ietf.org</a><BR> Subject: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02<BR> Message-ID:<BR> =A0 =A0 =A0 =A0<<a href=3D"CAK+d4xtmnnxQ5ZppXvYy18ik6LxdbNwp7kyYakC4sVcL=3DEiKFQ@mai= l.gmail.com">CAK+d4xtmnnxQ5ZppXvYy18ik6LxdbNwp7kyYakC4sVcL=3DEiKFQ@mail.gmail.= com</a>><BR> Content-Type: text/plain; charset=3D"iso-8859-1"<BR> <BR> This email begins a two week working group last call for<BR> draft-ietf-pwe3-pw-typed-wc-fec-02.<BR> <BR> Please post any comments to the PWE3 mailing list.<BR> <BR> This working group last call will end on Thursday 26 January 2012.<BR> <BR> Regards,<BR> Andy & Matthew<BR> -------------- next part --------------<BR> An HTML attachment was scrubbed...<BR> URL: <<a href=3D"http://www.ietf.org/mail-archive/web/pwe3/attachments/201= 20112/c7bfef1f/attachment.htm">http://www.ietf.org/mail-archive/web/pwe3/att= achments/20120112/c7bfef1f/attachment.htm</a>><BR> <BR> ------------------------------<BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><BR> -- <BR> </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Courier, Courier New"><SPAN STYLE=3D= 'font-size:9pt'>Syed Kamran Raza<BR> Technical Leader, SPRSG IOS-XR Routing (MPLS)<BR> Cisco Systems, Inc., <BR> Kanata, ON, K2K 3E8, Canada <BR> Ph: +1 (613) 254-4520<BR> <FONT COLOR=3D"#0F32EF"><U><a href=3D"http://www.cisco.com">http://www.cisco.co= m</a></U></FONT> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'><BR> <BR> <BR> </SPAN></FONT> </BODY> </HTML> --B_3409632443_10261243-- From davari@broadcom.com Tue Jan 17 17:53:05 2012 Return-Path: <davari@broadcom.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D4621F8611 for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 17:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQQIGOmipFLV for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 17:53:04 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 973DF21F84AE for <pwe3@ietf.org>; Tue, 17 Jan 2012 17:53:04 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 17 Jan 2012 18:01:30 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 17 Jan 2012 17:52:53 -0800 From: "Shahram Davari" <davari@broadcom.com> To: "pwe3@ietf.org" <pwe3@ietf.org> Date: Tue, 17 Jan 2012 17:52:50 -0800 Thread-Topic: GAL in PW question Thread-Index: AczVg+KfapUlCy+NSyC9/Qlq5zDcDA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7D@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6308F8703GG20168058-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7DSJEXCHCCR02co_ Subject: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 01:53:05 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7DSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, RFC 5586 now defines using GAL for PW. The question I have is don't we need= to define a new CC type encoding (as per RFC 5085) for signaling this capa= bility? Thanks Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7DSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 12 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi,<o:p></o:p></= p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>RFC 5586 n= ow defines using GAL for PW. The question I have is don’t we need to = define a new CC type encoding (as per RFC 5085) for signaling this capabili= ty?<o:p></o:p></p><p class=3DMsoNormal>  <o:p></o:p></p><p class=3DMso= Normal><o:p> </o:p></p><p class=3DMsoNormal>Thanks<o:p></o:p></p><p cl= ass=3DMsoNormal>Shahram<o:p></o:p></p></div></body></html>= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7DSJEXCHCCR02co_-- From gregory.mirsky@ericsson.com Tue Jan 17 18:07:11 2012 Return-Path: <gregory.mirsky@ericsson.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61521F86C4 for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 18:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeZhuxWABRyO for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 18:07:10 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6963021F84F9 for <pwe3@ietf.org>; Tue, 17 Jan 2012 18:07:10 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0I275ST002359; Tue, 17 Jan 2012 20:07:07 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 17 Jan 2012 21:06:59 -0500 From: Gregory Mirsky <gregory.mirsky@ericsson.com> To: Shahram Davari <davari@broadcom.com>, "pwe3@ietf.org" <pwe3@ietf.org> Date: Tue, 17 Jan 2012 21:06:58 -0500 Thread-Topic: GAL in PW question Thread-Index: AczVg+KfapUlCy+NSyC9/Qlq5zDcDAAAXiUQ Message-ID: <FE60A4E52763E84B935532D7D9294FF1322AEB2999@EUSAACMS0715.eamcs.ericsson.se> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7D@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F4C7D@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1322AEB2999EUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 02:07:11 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1322AEB2999EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shahram, I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL on PW as VCCV C= C Type 4. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Tuesday, January 17, 2012 5:53 PM To: pwe3@ietf.org Subject: [PWE3] GAL in PW question Hi, RFC 5586 now defines using GAL for PW. The question I have is don't we need= to define a new CC type encoding (as per RFC 5085) for signaling this capa= bility? Thanks Shahram --_000_FE60A4E52763E84B935532D7D9294FF1322AEB2999EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:m =3D=20 "http://schemas.microsoft.com/office/2004/12/omml"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6002.18538" name=3DGENERATOR> <STYLE>@font-face { font-family: Cambria Math; } @font-face { font-family: Calibri; } @page WordSection1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; } P.MsoNormal { FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif" } LI.MsoNormal { FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif" } DIV.MsoNormal { FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif" } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.EmailStyle17 { COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: pe= rsonal-compose } .MsoChpDefault { mso-style-type: export-only } DIV.WordSection1 { page: WordSection1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D458220302-18012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Hi Shahram,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D458220302-18012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>I think that draft-nadeau-pwe3-vccv-2-02 defines u= se of GAL=20 on PW as VCCV CC Type 4.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D458220302-18012012><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D458220302-18012012>  &n= bsp; <FONT=20 face=3DArial color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN=20 class=3D458220302-18012012>        <FONT= =20 face=3DArial color=3D#0000ff size=3D2>Greg</FONT></SPAN></DIV><BR> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] <B>On Behalf Of </B>Shahram=20 Davari<BR><B>Sent:</B> Tuesday, January 17, 2012 5:53 PM<BR><B>To:</B>=20 pwe3@ietf.org<BR><B>Subject:</B> [PWE3] GAL in PW question<BR></FONT><BR></= DIV> <DIV></DIV> <DIV class=3DWordSection1> <P class=3DMsoNormal>Hi,<o:p></o:p></P> <P class=3DMsoNormal><o:p> </o:p></P> <P class=3DMsoNormal>RFC 5586 now defines using GAL for PW. The question I = have is=20 don’t we need to define a new CC type encoding (as per RFC 5085) for = signaling=20 this capability?<o:p></o:p></P> <P class=3DMsoNormal> <o:p></o:p></P> <P class=3DMsoNormal><o:p> </o:p></P> <P class=3DMsoNormal>Thanks<o:p></o:p></P> <P class=3DMsoNormal>Shahram<o:p></o:p></P></DIV></BODY></HTML> --_000_FE60A4E52763E84B935532D7D9294FF1322AEB2999EUSAACMS0715e_-- From davari@broadcom.com Tue Jan 17 21:26:05 2012 Return-Path: <davari@broadcom.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3C1F0C3F for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 21:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd-zloq7PaxQ for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 21:26:04 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 33F451F0C35 for <pwe3@ietf.org>; Tue, 17 Jan 2012 21:26:03 -0800 (PST) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 17 Jan 2012 21:33:56 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 17 Jan 2012 21:25:49 -0800 From: "Shahram Davari" <davari@broadcom.com> To: "'gregory.mirsky@ericsson.com'" <gregory.mirsky@ericsson.com>, "'pwe3@ietf.org'" <pwe3@ietf.org> Date: Tue, 17 Jan 2012 21:25:48 -0800 Thread-Topic: GAL in PW question Thread-Index: AczVg+KfapUlCy+NSyC9/Qlq5zDcDAAAXiUQAAcR440= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <FE60A4E52763E84B935532D7D9294FF1322AEB2999@EUSAACMS0715.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6308864E50415092021-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56SJEXCHCCR02co_ Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 05:26:05 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 R3JlYXQsIGJ1dCBmaXJzdCBvZiBpdCBpcyBleHBpcmVkIGFuZCBzZWNvbmRseSBpdCBpcyBpbmZv cm1hdGlvbmFsLiBJIHRoaW5rIHdlIG5lZWQgdG8gYnJpbmcgaXQgYmFjayB0byBzdGFuZGFyZHMg dHJhY2suDQoNClRoeA0KU2hhaHJhbQ0KDQpGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIw MTIgMDY6MDYgUE0NClRvOiBTaGFocmFtIERhdmFyaTsgcHdlM0BpZXRmLm9yZyA8cHdlM0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBHQUwgaW4gUFcgcXVlc3Rpb24NCg0KSGkgU2hhaHJhbSwNCkkg dGhpbmsgdGhhdCBkcmFmdC1uYWRlYXUtcHdlMy12Y2N2LTItMDIgZGVmaW5lcyB1c2Ugb2YgR0FM IG9uIFBXIGFzIFZDQ1YgQ0MgVHlwZSA0Lg0KDQogICAgUmVnYXJkcywNCiAgICAgICAgR3JlZw0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcHdlMy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hhaHJh bSBEYXZhcmkNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIgNTo1MyBQTQ0KVG86IHB3 ZTNAaWV0Zi5vcmcNClN1YmplY3Q6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCg0KSGksDQoN ClJGQyA1NTg2IG5vdyBkZWZpbmVzIHVzaW5nIEdBTCBmb3IgUFcuIFRoZSBxdWVzdGlvbiBJIGhh dmUgaXMgZG9u4oCZdCB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBDQyB0eXBlIGVuY29kaW5nIChh cyBwZXIgUkZDIDUwODUpIGZvciBzaWduYWxpbmcgdGhpcyBjYXBhYmlsaXR5Pw0KDQoNClRoYW5r cw0KU2hhaHJhbQ0K --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj48aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCIgeG1sbnM6 dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0 LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIj48aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVdpbmRvd3MtMTI1MiI+DQo8bWV0YSBjb250 ZW50PSJNU0hUTUwgNi4wMC42MDAyLjE4NTM4IiBuYW1lPSJHRU5FUkFUT1IiPg0KPHN0eWxlPkBm b250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYW1icmlhIE1hdGg7DQp9DQpAZm9udC1mYWNlIHsN Cglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7c2l6ZTogOC41 aW4gMTEuMGluOyBtYXJnaW46IDEuMGluIDEuMGluIDEuMGluIDEuMGluOyB9DQpQLk1zb05vcm1h bCB7DQoJRk9OVC1TSVpFOiAxMXB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTog IkNhbGlicmkiLCJzYW5zLXNlcmlmIg0KfQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEx cHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDExcHQ7IE1BUkdJTjogMGluIDBp biAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiDQp9DQpBOmxpbmsgew0K CUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9y aXR5OiA5OQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KQTp2aXNpdGVkIHsN CglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXBy aW9yaXR5OiA5OQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBs ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0N ClNQQU4uRW1haWxTdHlsZTE3IHsNCglDT0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6ICJD YWxpYnJpIiwic2Fucy1zZXJpZiI7IG1zby1zdHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9 DQouTXNvQ2hwRGVmYXVsdCB7DQoJbXNvLXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5DQp9DQpESVYu V29yZFNlY3Rpb24xIHsNCglwYWdlOiBXb3JkU2VjdGlvbjENCn0NCjwvc3R5bGU+DQo8IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiB2bGluaz0icHVycGxlIiBsaW5rPSJibHVlIj48Zm9udCBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQpHcmVhdCwgYnV0IGZpcnN0IG9mIGl0IGlzIGV4cGly ZWQgYW5kIHNlY29uZGx5IGl0IGlzIGluZm9ybWF0aW9uYWwuIEkgdGhpbmsgd2UgbmVlZCB0byBi cmluZyBpdCBiYWNrIHRvIHN0YW5kYXJkcyB0cmFjay48YnI+PGJyPlRoeDxicj5TaGFocmFtPC9m b250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9tPC9iPjogR3JlZ29yeSBNaXJza3kgW21haWx0bzpn cmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb21dDTxicj48Yj5TZW50PC9iPjogVHVlc2RheSwgSmFu dWFyeSAxNywgMjAxMiAwNjowNiBQTTxicj48Yj5UbzwvYj46IFNoYWhyYW0gRGF2YXJpOyBwd2Uz QGlldGYub3JnICZsdDtwd2UzQGlldGYub3JnJmd0Ow08YnI+PGI+U3ViamVjdDwvYj46IFJFOiBH QUwgaW4gUFcgcXVlc3Rpb24NPGJyPjwvZm9udD4mbmJzcDs8YnI+PC9kaXY+DQoNCjxkaXYgZGly PSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0iNDU4MjIwMzAyLTE4MDEyMDEyIj48Zm9u dCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPkhpIFNoYWhyYW0sPC9mb250 Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0i NDU4MjIwMzAyLTE4MDEyMDEyIj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNp emU9IjIiPkkgdGhpbmsgdGhhdCBkcmFmdC1uYWRlYXUtcHdlMy12Y2N2LTItMDIgZGVmaW5lcyB1 c2Ugb2YgR0FMIA0Kb24gUFcgYXMgVkNDViBDQyBUeXBlIDQuPC9mb250Pjwvc3Bhbj48L2Rpdj4N CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3BhbiBjbGFzcz0iNDU4MjIwMzAyLTE4MDEy MDEyIj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjwvZm9udD48 L3NwYW4+Jm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4gY2xh c3M9IjQ1ODIyMDMwMi0xODAxMjAxMiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxmb250IGZhY2U9IkFy aWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+UmVnYXJkcyw8L2ZvbnQ+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuIGNsYXNzPSI0NTgyMjAzMDItMTgw MTIwMTIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Zm9udCBm YWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPkdyZWc8L2ZvbnQ+PC9zcGFuPjwv ZGl2Pjxicj4NCjxkaXYgY2xhc3M9Ik91dGxvb2tNZXNzYWdlSGVhZGVyIiBsYW5nPSJlbi11cyIg ZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPGZvbnQgZmFjZT0i VGFob21hIiBzaXplPSIyIj48Yj5Gcm9tOjwvYj4gcHdlMy1ib3VuY2VzQGlldGYub3JnIA0KW21h aWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+U2hhaHJhbSAN CkRhdmFyaTxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiA1OjUzIFBN PGJyPjxiPlRvOjwvYj4gDQpwd2UzQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbUFdFM10g R0FMIGluIFBXIHF1ZXN0aW9uPGJyPjwvZm9udD48YnI+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SRkMgNTU4NiBub3cgZGVmaW5lcyB1c2luZyBHQUwgZm9yIFBXLiBU aGUgcXVlc3Rpb24gSSBoYXZlIGlzIA0KZG9u4oCZdCB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBD QyB0eXBlIGVuY29kaW5nIChhcyBwZXIgUkZDIDUwODUpIGZvciBzaWduYWxpbmcgDQp0aGlzIGNh cGFiaWxpdHk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TaGFocmFtPG86cD48L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4NCg== --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56SJEXCHCCR02co_-- From gregimirsky@gmail.com Tue Jan 17 22:04:02 2012 Return-Path: <gregimirsky@gmail.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA43821F86D0 for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 22:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woxPs1c2yAPr for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 22:04:02 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D872E21F86C6 for <pwe3@ietf.org>; Tue, 17 Jan 2012 22:04:01 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4353877obb.31 for <pwe3@ietf.org>; Tue, 17 Jan 2012 22:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8N1/cP22JJ+6sBdtkL3Dt6LAdn/9kVaVh1UDcMz5hns=; b=vg7B0qQav0bbRoTbCwrpA5f48s2YtgJ16j88PSlLmantLECHNTJqJ9snaEYqv7RRVs e3EowPrx33cKdIF2DpGCFo/ez8keWd6VWiMhVL+XCZXq63QbaG+nx/oTDrbcKlq4nBQp HF8Tqyss/6ZwYk3VjXQKKs9NT8Ozpuov3NfdU= MIME-Version: 1.0 Received: by 10.182.86.229 with SMTP id s5mr17860521obz.37.1326866641318; Tue, 17 Jan 2012 22:04:01 -0800 (PST) Received: by 10.182.38.72 with HTTP; Tue, 17 Jan 2012 22:04:01 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56@SJEXCHCCR02.corp.ad.broadcom.com> References: <FE60A4E52763E84B935532D7D9294FF1322AEB2999@EUSAACMS0715.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 17 Jan 2012 22:04:01 -0800 Message-ID: <CA+RyBmXS4tqgxiJ_mgOUFygPGjpQeKrdpzRE++eg2J1DFvGB=A@mail.gmail.com> From: Greg Mirsky <gregimirsky@gmail.com> To: Shahram Davari <davari@broadcom.com> Content-Type: multipart/alternative; boundary=f46d0444ef6bd1f37f04b6c736d1 Cc: "pwe3@ietf.org" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 06:04:03 -0000 --f46d0444ef6bd1f37f04b6c736d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Shahram, you're right, I've noticed that even though the proposal clearly defines new behavior it, strangely, is on Informational track. But I think that this is not a big problem and it can be easily put on standard's track next time authors submit new revision. I think we'll learn of their plans soon. Regards, Greg On Tue, Jan 17, 2012 at 9:25 PM, Shahram Davari <davari@broadcom.com> wrote= : > ** > Great, but first of it is expired and secondly it is informational. I > think we need to bring it back to standards track. > > Thx > Shahram > > *From*: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > *Sent*: Tuesday, January 17, 2012 06:06 PM > *To*: Shahram Davari; pwe3@ietf.org <pwe3@ietf.org> > *Subject*: RE: GAL in PW question > > Hi Shahram, > I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL on PW as VCCV > CC Type 4. > > Regards, > Greg > > ------------------------------ > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf > Of *Shahram Davari > *Sent:* Tuesday, January 17, 2012 5:53 PM > *To:* pwe3@ietf.org > *Subject:* [PWE3] GAL in PW question > > Hi,**** > > ** ** > > RFC 5586 now defines using GAL for PW. The question I have is don=92t we > need to define a new CC type encoding (as per RFC 5085) for signaling thi= s > capability?**** > > **** > > ** ** > > Thanks**** > > Shahram**** > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --f46d0444ef6bd1f37f04b6c736d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Shahram,<br>you're right, I've noticed that even though the prop= osal clearly defines new behavior it, strangely, is on Informational track.= But I think that this is not a big problem and it can be easily put on sta= ndard's track next time authors submit new revision. I think we'll = learn of their plans soon.<br> <br>Regards,<br>Greg<br><br><div class=3D"gmail_quote">On Tue, Jan 17, 2012= at 9:25 PM, Shahram Davari <span dir=3D"ltr"><<a href=3D"mailto:davari@= broadcom.com">davari@broadcom.com</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> <u></u> <div vlink=3D"purple" link=3D"blue" lang=3D"EN-US"><font style=3D"font-size= :11.0pt;font-family:"Calibri","sans-serif";color:#1f497= d"> Great, but first of it is expired and secondly it is informational. I think= we need to bring it back to standards track.<br><br>Thx<br>Shahram</font><= br>=A0<br> <div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in = 0in 0in"> <font style=3D"font-size:10.0pt;font-family:"Tahoma","sans-s= erif""> <b>From</b>: Gregory Mirsky [mailto:<a href=3D"mailto:gregory.mirsky@ericss= on.com" target=3D"_blank">gregory.mirsky@ericsson.com</a>] <br><b>Sent</b>: Tuesday, January 17, 2012 06:06 PM<br><b>To</b>: Shahram D= avari; <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org</a>= <<a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org</a>&g= t; <br><b>Subject</b>: RE: GAL in PW question <br></font>=A0<br></div><div><div class=3D"h5"> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial= ">Hi Shahram,</font></span></div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial= ">I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL=20 on PW as VCCV CC Type 4.</font></span></div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial= "></font></span>=A0</div> <div dir=3D"ltr" align=3D"left"><span>=A0=A0=A0 <font color=3D"#0000ff" fac= e=3D"Arial">Regards,</font></span></div> <div dir=3D"ltr" align=3D"left"><span>=A0=A0=A0=A0=A0=A0=A0 <font color=3D"= #0000ff" face=3D"Arial">Greg</font></span></div><br> <div dir=3D"ltr" lang=3D"en-us" align=3D"left"> <hr> <font face=3D"Tahoma"><b>From:</b> <a href=3D"mailto:pwe3-bounces@ietf.org"= target=3D"_blank">pwe3-bounces@ietf.org</a>=20 [mailto:<a href=3D"mailto:pwe3-bounces@ietf.org" target=3D"_blank">pwe3-bou= nces@ietf.org</a>] <b>On Behalf Of </b>Shahram=20 Davari<br><b>Sent:</b> Tuesday, January 17, 2012 5:53 PM<br><b>To:</b>=20 <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org</a><br><b>= Subject:</b> [PWE3] GAL in PW question<br></font><br></div> <div></div> <div> <p class=3D"MsoNormal">Hi,<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=A0<u></u></p> <p class=3D"MsoNormal">RFC 5586 now defines using GAL for PW. The question = I have is=20 don=92t we need to define a new CC type encoding (as per RFC 5085) for sign= aling=20 this capability?<u></u><u></u></p> <p class=3D"MsoNormal">=A0<u></u><u></u></p> <p class=3D"MsoNormal"><u></u>=A0<u></u></p> <p class=3D"MsoNormal">Thanks<u></u><u></u></p> <p class=3D"MsoNormal">Shahram<u></u><u></u></p></div></div></div></div> <br>_______________________________________________<br> pwe3 mailing list<br> <a href=3D"mailto:pwe3@ietf.org">pwe3@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/pwe3</a><br> <br></blockquote></div><br> --f46d0444ef6bd1f37f04b6c736d1-- From Alexander.Vainshtein@ecitele.com Tue Jan 17 23:20:21 2012 Return-Path: <Alexander.Vainshtein@ecitele.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63CF11E80A3 for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 23:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGWXK28XNSmz for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 23:20:20 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 20E0E11E8083 for <pwe3@ietf.org>; Tue, 17 Jan 2012 23:20:19 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1326871160!57360233!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 12359 invoked from network); 18 Jan 2012 07:19:20 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-27.messagelabs.com with SMTP; 18 Jan 2012 07:19:20 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-56-4f167f2e6019 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 5E.93.03709.E2F761F4; Wed, 18 Jan 2012 10:13:34 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 18 Jan 2012 09:20:17 +0200 From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> To: Greg Mirsky <gregimirsky@gmail.com>, Shahram Davari <davari@broadcom.com> Date: Wed, 18 Jan 2012 09:19:40 +0200 Thread-Topic: [PWE3] GAL in PW question Thread-Index: AczVpuq1HIwiZy5FS92XTqpr3c9bKAACf6G/ Message-ID: <A3C5DF08D38B6049839A6F553B331C760115ED9B68AA@ILPTMAIL02.ecitele.com> References: <FE60A4E52763E84B935532D7D9294FF1322AEB2999@EUSAACMS0715.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D56@SJEXCHCCR02.corp.ad.broadcom.com>, <CA+RyBmXS4tqgxiJ_mgOUFygPGjpQeKrdpzRE++eg2J1DFvGB=A@mail.gmail.com> In-Reply-To: <CA+RyBmXS4tqgxiJ_mgOUFygPGjpQeKrdpzRE++eg2J1DFvGB=A@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115ED9B68AAILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTW0gUURjmzOxltN2YNnf3KD1MY9l1bbcbG7Z2oUAD0S700ItNu8fdqd2Z aWaUNpO2IuxmKF2gLVsji7KLJUVqUSQVtHSPokyLMhHNEESSArOZnTRfevvOd/n//xz+Q+CW fcY0guVkJHJMkDYk64709A84Mnfa8p2Ng7Pd9RW57h/HO/Xuw/03dEvxnOinp4acpmi7Mae2 9idWgG+IgMUMx/EyIyPKhySvhy4Q2RLGG6Yp1uehXTQlBBkvCiFO9tCMICDOR2cnL1ZIlqMQ 5+V9LOf30Llr8x1u94JFDhednZHumpeVvC7AShRyhBg2SIWQJDF+RCmMOirnQz6qiBcpOYAo ceMRPPDw9gOdULVsW2PFKWME7HMfAEkEJOfDxmiFUcM2+OJjveEASCYs5D0A23cPYtrhOID7 62r1qstAemDDpXaDilPIPPi5aSjB42Q6vHVyT4LXkVNhZet3TMUTyQzY0/zJqPmnwS8PNX8K ORcOve5M+M3kahiPVeq0Zr0AHquOJ4QkRTh3qC4RBsp4g/HLmNbMDlu/xjBtbBLW3nmOa9gK uzt+6zW/FbaV1wPNz8Ndb8uNWrMJ8PGJrzrNnwrvX3inqwS26Jiy0TGR6JiIxjth37MYruFZ 8PyZb3/xHHh94CkYy9cAYx2wskFB3hTyO12ZyMvKKIgyvXyoAWhr1NUIfsWmtACSALTJPP2u Nd+iZ0qkcKgFpBIYbTXf3WrLt4zfxPvCAUYKFIrFQSS1AEjgdIp540JFM/uY8HYk8iPSSuX5 q/C0cV5e3QK5cJ7T+f8DbTd3envzLKRf2c0tCAlIHKkziSBoaB5S208QkR9tK2KD8j8ZI5LU MUzKGDZeHUMSmJDE+jU9DianKaXVMKkKgWJuNKt+oJ3Dw8M9wK5ceqL5quoyKTs7mu5RCmNK 4eBei1pY+TejUloElK7xxMo+no48edP33jjI2LNWbHYAU9u0ANY1p6gw/f697B9PDnJtz9tu dpQ0pKyvETLexMnyyKnea5cspowXS1Y+4F4+snXkPspt0F/dsrCrWQgfLb4dpvCT/TuabpSS UvWV37ubz59NZXd9WH7CJRU2tZZ1E68uTq8amFFgX+WkdVKAcc3ERYn5A/XFOOgbBAAA Cc: "pwe3@ietf.org" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 07:20:21 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B68AAILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dear Greg, Shahram and all, I see only two alternatives here: 1. Define VCCV Type 4 (GAL-based) explicitly in a Standard Track document= that updates 5085. The definition must also address the issue of priorities= among the CC types when the peers support multiple PW types, etc. 2. Decide that in spite of 5586 allowing usage of GAL with PWs it will not= be used - for good or until further notice (5586 does not specify any usag= e of GAL with PWs, simply allows it). My 2c, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Greg Mirsky= [gregimirsky@gmail.com] Sent: Wednesday, January 18, 2012 8:04 AM To: Shahram Davari Cc: pwe3@ietf.org Subject: Re: [PWE3] GAL in PW question Hi Shahram, you're right, I've noticed that even though the proposal clearly defines new= behavior it, strangely, is on Informational track. But I think that this is= not a big problem and it can be easily put on standard's track next time au= thors submit new revision. I think we'll learn of their plans soon. Regards, Greg On Tue, Jan 17, 2012 at 9:25 PM, Shahram Davari <davari@broadcom.com<mailto:= davari@broadcom.com>> wrote: Great, but first of it is expired and secondly it is informational. I think= we need to bring it back to standards track. Thx Shahram From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com<mailto:gregory.mirs= ky@ericsson.com>] Sent: Tuesday, January 17, 2012 06:06 PM To: Shahram Davari; pwe3@ietf.org<mailto:pwe3@ietf.org> <pwe3@ietf.org<mailt= o:pwe3@ietf.org>> Subject: RE: GAL in PW question Hi Shahram, I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL on PW as VCCV CC= Type 4. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org<mailto:pwe3-bounces@ietf.org> [mailto:pwe3-bounc= es@ietf.org<mailto:pwe3-bounces@ietf.org>] On Behalf Of Shahram Davari Sent: Tuesday, January 17, 2012 5:53 PM To: pwe3@ietf.org<mailto:pwe3@ietf.org> Subject: [PWE3] GAL in PW question Hi, RFC 5586 now defines using GAL for PW. The question I have is don=92t we nee= d to define a new CC type encoding (as per RFC 5085) for signaling this capa= bility? Thanks Shahram _______________________________________________ pwe3 mailing list pwe3@ietf.org<mailto:pwe3@ietf.org> https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B68AAILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable <html dir=3D"ltr"><head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-12= 52"> <meta name=3D"GENERATOR" content=3D"MSHTML 8.00.7601.17720"> <style id=3D"owaTempEditStyle"></style><style title=3D"owaParaStyle"><!--P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } --></style> </head> <body ocsi=3D"x"> <div style=3D"FONT-FAMILY: Times New Roman; DIRECTION: ltr; COLOR: #000000;= FONT-SIZE: 16px"> <div>Dear Greg, Shahram<a></a> and all,</div> <div><font face=3D"times new roman">I see only two alternatives here:</font>= </div> <ol> <li><font face=3D"times new roman">Define VCCV Type 4 (GAL-based) explicitly= in a Standard Track document that updates 5085. The definition must also ad= dress the issue of priorities among the CC types when the peers support mult= iple PW types, etc.</font> </li><li><font face=3D"times new roman">Decide that in spite of 5586 allowin= g usage of GAL with PWs it will not be used  - for good or until furthe= r notice (5586 does not specify any usage of GAL with PWs, simply allows it)= .</font></li></ol> <p><font face=3D"times new roman">My 2c,</font></p> <p><font face=3D"times new roman">     Sasha</font></p> <div dir=3D"ltr"><font color=3D"#000000" size=3D"3" face=3D"Times New Roman"= ></font> </div> <div style=3D"DIRECTION: ltr" id=3D"divRpF64902"> <hr tabindex=3D"-1"> <font color=3D"#000000" size=3D"2" face=3D"Tahoma"><b>From:</b> pwe3-bounces= @ietf.org [pwe3-bounces@ietf.org] On Behalf Of Greg Mirsky [gregimirsky@gmai= l.com]<br> <b>Sent:</b> Wednesday, January 18, 2012 8:04 AM<br> <b>To:</b> Shahram Davari<br> <b>Cc:</b> pwe3@ietf.org<br> <b>Subject:</b> Re: [PWE3] GAL in PW question<br> </font><br> </div> <div></div> <div>Hi Shahram,<br> you're right, I've noticed that even though the proposal clearly defines new= behavior it, strangely, is on Informational track. But I think that this is= not a big problem and it can be easily put on standard's track next time au= thors submit new revision. I think we'll learn of their plans soon.<br> <br> Regards,<br> Greg<br> <br> <div class=3D"gmail_quote">On Tue, Jan 17, 2012 at 9:25 PM, Shahram Davari <= span dir=3D"ltr"> <<a href=3D"mailto:davari@broadcom.com">davari@broadcom.com</a>></span= > wrote:<br> <blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex;= PADDING-LEFT: 1ex" class=3D"gmail_quote"> <u></u> <div lang=3D"EN-US"><font style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLO= R: #1f497d; FONT-SIZE: 11pt">Great, but first of it is expired and secondly= it is informational. I think we need to bring it back to standards track.<b= r> <br> Thx<br> Shahram</font><br>  <br> <div style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-= BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt= solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <font style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"><b>From<= /b>: Gregory Mirsky [mailto:<a href=3D"mailto:gregory.mirsky@ericsson.com">g= regory.mirsky@ericsson.com</a>] <br> <b>Sent</b>: Tuesday, January 17, 2012 06:06 PM<br> <b>To</b>: Shahram Davari; <a href=3D"mailto:pwe3@ietf.org">pwe3@ietf.org</a= > <<a href=3D"mailto:pwe3@ietf.org">pwe3@ietf.org</a>> <br> <b>Subject</b>: RE: GAL in PW question <br> </font> <br> </div> <div> <div class=3D"h5"> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial"= >Hi Shahram,</font></span></div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial"= >I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL on PW as VCCV C= C Type 4.</font></span></div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial"= ></font></span> </div> <div dir=3D"ltr" align=3D"left"><span>    <font color=3D"#000= 0ff" face=3D"Arial">Regards,</font></span></div> <div dir=3D"ltr" align=3D"left"><span>      &n= bsp; <font color=3D"#0000ff" face=3D"Arial">Greg</font></span></div> <br> <div dir=3D"ltr" lang=3D"en-us" align=3D"left"> <hr> <font face=3D"Tahoma"><b>From:</b> <a href=3D"mailto:pwe3-bounces@ietf.org">= pwe3-bounces@ietf.org</a> [mailto:<a href=3D"mailto:pwe3-bounces@ietf.org">p= we3-bounces@ietf.org</a>] <b>On Behalf Of </b>Shahram Davari<br> <b>Sent:</b> Tuesday, January 17, 2012 5:53 PM<br> <b>To:</b> <a href=3D"mailto:pwe3@ietf.org">pwe3@ietf.org</a><br> <b>Subject:</b> [PWE3] GAL in PW question<br> </font><br> </div> <div></div> <div> <p class=3D"MsoNormal">Hi,<u></u><u></u></p> <p class=3D"MsoNormal"><u></u><u></u> </p> <p class=3D"MsoNormal">RFC 5586 now defines using GAL for PW. The question I= have is don=92t we need to define a new CC type encoding (as per RFC 5085)= for signaling this capability?<u></u><u></u></p> <p class=3D"MsoNormal"><u></u><u></u> </p> <p class=3D"MsoNormal"><u></u><u></u> </p> <p class=3D"MsoNormal">Thanks<u></u><u></u></p> <p class=3D"MsoNormal">Shahram<u></u><u></u></p> </div> </div> </div> </div> <br> _______________________________________________<br> pwe3 mailing list<br> <a href=3D"mailto:pwe3@ietf.org">pwe3@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/pwe3</a><br> <br> </blockquote> </div> <br> </div> </div> <p> This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. </p> </body> </html> --_000_A3C5DF08D38B6049839A6F553B331C760115ED9B68AAILPTMAIL02e_-- From davari@broadcom.com Tue Jan 17 23:50:10 2012 Return-Path: <davari@broadcom.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4C21F86B8 for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 23:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5cZjS-ye54j for <pwe3@ietfa.amsl.com>; Tue, 17 Jan 2012 23:50:09 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD9721F86B0 for <pwe3@ietf.org>; Tue, 17 Jan 2012 23:50:09 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 17 Jan 2012 23:58:31 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 17 Jan 2012 23:49:53 -0800 From: "Shahram Davari" <davari@broadcom.com> To: "'Alexander.Vainshtein@ecitele.com'" <Alexander.Vainshtein@ecitele.com>, "'gregimirsky@gmail.com'" <gregimirsky@gmail.com> Date: Tue, 17 Jan 2012 23:49:52 -0800 Thread-Topic: [PWE3] GAL in PW question Thread-Index: AczVpuq1HIwiZy5FS92XTqpr3c9bKAACf6G/AAE2aBo= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <A3C5DF08D38B6049839A6F553B331C760115ED9B68AA@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6308A42D3GG20227947-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57SJEXCHCCR02co_ Cc: "'pwe3@ietf.org'" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 07:50:10 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgU2FzaGEsDQoNClR3byBxdWVzdGlvbnM6DQoNCjEpIERvZXMgVkNDMSwgMiwgMyBhcHBseSB0 byBNUExTLVRQIFBXPw0KDQoyKSBzaG91bGQgYW4gTVBMUy1UUCBub2RlIGJlIGNvbmZpZ3VyZWQg aW4gb3JkZXIgdG8gcHJvY2VzcyByZWNlaXZlZCBWQ0NWNCBwYWNrZXRzPyBPciBpdCBzaG91bGQg anVzdCBwcm9jZXNzIHN1Y2ggcGFja2V0cyB3aXRob3V0IGFueSBjb25maWd1cmF0aW9uLg0KDQp0 aGFua3MNClNoYWhyYW0NCg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcs IDIwMTIgMTE6MTkgUE0NClRvOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPjsg U2hhaHJhbSBEYXZhcmkNCkNjOiBwd2UzQGlldGYub3JnIDxwd2UzQGlldGYub3JnPg0KU3ViamVj dDogUkU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCg0KRGVhciBHcmVnLCBTaGFocmFtIGFu ZCBhbGwsDQpJIHNlZSBvbmx5IHR3byBhbHRlcm5hdGl2ZXMgaGVyZToNCg0KIDEuICBEZWZpbmUg VkNDViBUeXBlIDQgKEdBTC1iYXNlZCkgZXhwbGljaXRseSBpbiBhIFN0YW5kYXJkIFRyYWNrIGRv Y3VtZW50IHRoYXQgdXBkYXRlcyA1MDg1LiBUaGUgZGVmaW5pdGlvbiBtdXN0IGFsc28gYWRkcmVz cyB0aGUgaXNzdWUgb2YgcHJpb3JpdGllcyBhbW9uZyB0aGUgQ0MgdHlwZXMgd2hlbiB0aGUgcGVl cnMgc3VwcG9ydCBtdWx0aXBsZSBQVyB0eXBlcywgZXRjLg0KIDIuICBEZWNpZGUgdGhhdCBpbiBz cGl0ZSBvZiA1NTg2IGFsbG93aW5nIHVzYWdlIG9mIEdBTCB3aXRoIFBXcyBpdCB3aWxsIG5vdCBi ZSB1c2VkICAtIGZvciBnb29kIG9yIHVudGlsIGZ1cnRoZXIgbm90aWNlICg1NTg2IGRvZXMgbm90 IHNwZWNpZnkgYW55IHVzYWdlIG9mIEdBTCB3aXRoIFBXcywgc2ltcGx5IGFsbG93cyBpdCkuDQoN Ck15IDJjLA0KDQogICAgIFNhc2hhDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbcHdlMy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgR3JlZyBNaXJza3kgW2dyZWdpbWlyc2t5QGdtYWlsLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxMiA4OjA0IEFNDQpUbzogU2hhaHJhbSBEYXZhcmkNCkNj OiBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1BXRTNdIEdBTCBpbiBQVyBxdWVzdGlvbg0K DQpIaSBTaGFocmFtLA0KeW91J3JlIHJpZ2h0LCBJJ3ZlIG5vdGljZWQgdGhhdCBldmVuIHRob3Vn aCB0aGUgcHJvcG9zYWwgY2xlYXJseSBkZWZpbmVzIG5ldyBiZWhhdmlvciBpdCwgc3RyYW5nZWx5 LCBpcyBvbiBJbmZvcm1hdGlvbmFsIHRyYWNrLiBCdXQgSSB0aGluayB0aGF0IHRoaXMgaXMgbm90 IGEgYmlnIHByb2JsZW0gYW5kIGl0IGNhbiBiZSBlYXNpbHkgcHV0IG9uIHN0YW5kYXJkJ3MgdHJh Y2sgbmV4dCB0aW1lIGF1dGhvcnMgc3VibWl0IG5ldyByZXZpc2lvbi4gSSB0aGluayB3ZSdsbCBs ZWFybiBvZiB0aGVpciBwbGFucyBzb29uLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIEph biAxNywgMjAxMiBhdCA5OjI1IFBNLCBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNv bTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+IHdyb3RlOg0KR3JlYXQsIGJ1dCBmaXJzdCBv ZiBpdCBpcyBleHBpcmVkIGFuZCBzZWNvbmRseSBpdCBpcyBpbmZvcm1hdGlvbmFsLiBJIHRoaW5r IHdlIG5lZWQgdG8gYnJpbmcgaXQgYmFjayB0byBzdGFuZGFyZHMgdHJhY2suDQoNClRoeA0KU2hh aHJhbQ0KDQpGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNz c29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPl0NClNlbnQ6IFR1ZXNk YXksIEphbnVhcnkgMTcsIDIwMTIgMDY6MDYgUE0NClRvOiBTaGFocmFtIERhdmFyaTsgcHdlM0Bp ZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4gPHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpIaSBTaGFocmFt LA0KSSB0aGluayB0aGF0IGRyYWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi0wMiBkZWZpbmVzIHVzZSBv ZiBHQUwgb24gUFcgYXMgVkNDViBDQyBUeXBlIDQuDQoNCiAgICBSZWdhcmRzLA0KICAgICAgICBH cmVnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBwd2UzLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwd2UzLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBTaGFocmFtIERhdmFyaQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiA1OjUzIFBN DQpUbzogcHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtQV0Uz XSBHQUwgaW4gUFcgcXVlc3Rpb24NCg0KSGksDQoNClJGQyA1NTg2IG5vdyBkZWZpbmVzIHVzaW5n IEdBTCBmb3IgUFcuIFRoZSBxdWVzdGlvbiBJIGhhdmUgaXMgZG9u4oCZdCB3ZSBuZWVkIHRvIGRl ZmluZSBhIG5ldyBDQyB0eXBlIGVuY29kaW5nIChhcyBwZXIgUkZDIDUwODUpIGZvciBzaWduYWxp bmcgdGhpcyBjYXBhYmlsaXR5Pw0KDQoNClRoYW5rcw0KU2hhaHJhbQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5nIGxpc3QNCnB3 ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3B3ZTMNCg0KDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2gg aXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVj b20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQo= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9V2luZG93cy0xMjUyIj4NCjxtZXRhIG5hbWU9IkdF TkVSQVRPUiIgY29udGVudD0iTVNIVE1MIDguMDAuNzYwMS4xNzcyMCI+DQo8c3R5bGUgaWQ9Im93 YVRlbXBFZGl0U3R5bGUiPjwvc3R5bGU+PHN0eWxlIHRpdGxlPSJvd2FQYXJhU3R5bGUiPjwhLS1Q IHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IG9jc2k9IngiPjxmb250IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4NCkhpIFNhc2hhLDxicj48YnI+VHdvIHF1ZXN0aW9uczo8YnI+PGJyPjEpIERv ZXMgVkNDMSwgMiwgMyBhcHBseSB0byBNUExTLVRQIFBXPzxicj48YnI+Mikgc2hvdWxkIGFuIE1Q TFMtVFAgbm9kZSBiZSBjb25maWd1cmVkICBpbiBvcmRlciB0byBwcm9jZXNzICByZWNlaXZlZCBW Q0NWNCBwYWNrZXRzPyBPciBpdCBzaG91bGQganVzdCBwcm9jZXNzIHN1Y2ggcGFja2V0cyB3aXRo b3V0IGFueSBjb25maWd1cmF0aW9uLiA8YnI+PGJyPnRoYW5rczxicj5TaGFocmFtPC9mb250Pjxi cj4mbmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+DQo8Yj5Gcm9tPC9iPjogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NPGJyPjxiPlNlbnQ8L2I+OiBUdWVzZGF5 LCBKYW51YXJ5IDE3LCAyMDEyIDExOjE5IFBNPGJyPjxiPlRvPC9iPjogR3JlZyBNaXJza3kgJmx0 O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs7IFNoYWhyYW0gRGF2YXJpDTxicj48Yj5DYzwvYj46 IHB3ZTNAaWV0Zi5vcmcgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TdWJqZWN0PC9iPjog UkU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NPGJyPjwvZm9udD4mbmJzcDs8YnI+PC9kaXY+ DQoNCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBUaW1lcyBOZXcgUm9tYW47IERJUkVDVElPTjog bHRyOyBDT0xPUjogIzAwMDAwMDsgRk9OVC1TSVpFOiAxNnB4Ij4NCjxkaXY+RGVhciBHcmVnLCZu YnNwO1NoYWhyYW08YT48L2E+IGFuZCBhbGwsPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9InRpbWVz IG5ldyByb21hbiI+SSBzZWUgb25seSB0d28gYWx0ZXJuYXRpdmVzIGhlcmU6PC9mb250PjwvZGl2 Pg0KPG9sPg0KPGxpPjxmb250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+RGVmaW5lIFZDQ1YgVHlw ZSA0IChHQUwtYmFzZWQpIGV4cGxpY2l0bHkgaW4gYSBTdGFuZGFyZCBUcmFjayBkb2N1bWVudCB0 aGF0IHVwZGF0ZXMgNTA4NS4gVGhlIGRlZmluaXRpb24gbXVzdCBhbHNvIGFkZHJlc3MgdGhlIGlz c3VlIG9mIHByaW9yaXRpZXMgYW1vbmcgdGhlIENDIHR5cGVzIHdoZW4gdGhlIHBlZXJzIHN1cHBv cnQgbXVsdGlwbGUgUFcgdHlwZXMsIGV0Yy48L2ZvbnQ+DQo8L2xpPjxsaT48Zm9udCBmYWNlPSJ0 aW1lcyBuZXcgcm9tYW4iPkRlY2lkZSB0aGF0IGluIHNwaXRlIG9mIDU1ODYgYWxsb3dpbmcgdXNh Z2Ugb2YgR0FMIHdpdGggUFdzIGl0IHdpbGwgbm90IGJlIHVzZWQmbmJzcDsgLSBmb3IgZ29vZCBv ciB1bnRpbCBmdXJ0aGVyIG5vdGljZSAoNTU4NiBkb2VzIG5vdCBzcGVjaWZ5IGFueSB1c2FnZSBv ZiBHQUwgd2l0aCBQV3MsIHNpbXBseSBhbGxvd3MgaXQpLjwvZm9udD48L2xpPjwvb2w+DQo8cD48 Zm9udCBmYWNlPSJ0aW1lcyBuZXcgcm9tYW4iPk15IDJjLDwvZm9udD48L3A+DQo8cD48Zm9udCBm YWNlPSJ0aW1lcyBuZXcgcm9tYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYTwvZm9u dD48L3A+DQo8ZGl2IGRpcj0ibHRyIj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJESVJF Q1RJT046IGx0ciIgaWQ9ImRpdlJwRjY0OTAyIj4NCjxociB0YWJpbmRleD0iLTEiPg0KPGZvbnQg Y29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IHB3ZTMt Ym91bmNlc0BpZXRmLm9yZyBbcHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3Jl ZyBNaXJza3kgW2dyZWdpbWlyc2t5QGdtYWlsLmNvbV08YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBKYW51YXJ5IDE4LCAyMDEyIDg6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFNoYWhyYW0gRGF2 YXJpPGJyPg0KPGI+Q2M6PC9iPiBwd2UzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbUFdFM10gR0FMIGluIFBXIHF1ZXN0aW9uPGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0KPGRp dj48L2Rpdj4NCjxkaXY+SGkgU2hhaHJhbSw8YnI+DQp5b3UncmUgcmlnaHQsIEkndmUgbm90aWNl ZCB0aGF0IGV2ZW4gdGhvdWdoIHRoZSBwcm9wb3NhbCBjbGVhcmx5IGRlZmluZXMgbmV3IGJlaGF2 aW9yIGl0LCBzdHJhbmdlbHksIGlzIG9uIEluZm9ybWF0aW9uYWwgdHJhY2suIEJ1dCBJIHRoaW5r IHRoYXQgdGhpcyBpcyBub3QgYSBiaWcgcHJvYmxlbSBhbmQgaXQgY2FuIGJlIGVhc2lseSBwdXQg b24gc3RhbmRhcmQncyB0cmFjayBuZXh0IHRpbWUgYXV0aG9ycyBzdWJtaXQgbmV3IHJldmlzaW9u LiBJDQogdGhpbmsgd2UnbGwgbGVhcm4gb2YgdGhlaXIgcGxhbnMgc29vbi48YnI+DQo8YnI+DQpS ZWdhcmRzLDxicj4NCkdyZWc8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g VHVlLCBKYW4gMTcsIDIwMTIgYXQgOToyNSBQTSwgU2hhaHJhbSBEYXZhcmkgPHNwYW4gZGlyPSJs dHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tIj5kYXZhcmlAYnJv YWRjb20uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIHN0eWxlPSJC T1JERVItTEVGVDogI2NjYyAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBB RERJTkctTEVGVDogMWV4IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPHU+PC91Pg0KPGRpdiBsYW5n PSJFTi1VUyI+PGZvbnQgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5HcmVhdCwgYnV0IGZpcnN0IG9mIGl0 IGlzIGV4cGlyZWQgYW5kIHNlY29uZGx5IGl0IGlzIGluZm9ybWF0aW9uYWwuIEkgdGhpbmsgd2Ug bmVlZCB0byBicmluZyBpdCBiYWNrIHRvIHN0YW5kYXJkcyB0cmFjay48YnI+DQo8YnI+DQpUaHg8 YnI+DQpTaGFocmFtPC9mb250Pjxicj4NCiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9IkJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U VE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1U T1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5H LVRPUDogM3B0Ij4NCjxmb250IHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2Vy aWYnOyBGT05ULVNJWkU6IDEwcHQiPjxiPkZyb208L2I+OiBHcmVnb3J5IE1pcnNreSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iPmdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50PC9iPjogVHVlc2RheSwgSmFudWFy eSAxNywgMjAxMiAwNjowNiBQTTxicj4NCjxiPlRvPC9iPjogU2hhaHJhbSBEYXZhcmk7IDxhIGhy ZWY9Im1haWx0bzpwd2UzQGlldGYub3JnIj5wd2UzQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U3Vi amVjdDwvYj46IFJFOiBHQUwgaW4gUFcgcXVlc3Rpb24gPGJyPg0KPC9mb250PiZuYnNwOzxicj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJs ZWZ0Ij48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQXJpYWwiPkhpIFNoYWhyYW0s PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48 Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQXJpYWwiPkkgdGhpbmsgdGhhdCBkcmFmdC1uYWRl YXUtcHdlMy12Y2N2LTItMDIgZGVmaW5lcyB1c2Ugb2YgR0FMIG9uIFBXIGFzIFZDQ1YgQ0MgVHlw ZSA0LjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNw YW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIGZhY2U9IkFyaWFsIj48L2ZvbnQ+PC9zcGFuPiZuYnNw OzwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPiZuYnNwOyZuYnNwOyZu YnNwOyA8Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQXJpYWwiPlJlZ2FyZHMsPC9mb250Pjwv c3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGZvbnQgY29sb3I9IiMwMDAwZmYiIGZh Y2U9IkFyaWFsIj5HcmVnPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxicj4NCjxkaXYgZGlyPSJsdHIi IGxhbmc9ImVuLXVzIiBhbGlnbj0ibGVmdCI+DQo8aHI+DQo8Zm9udCBmYWNlPSJUYWhvbWEiPjxi PkZyb206PC9iPiA8YSBocmVmPSJtYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnIj5wd2UzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnB3ZTMtYm91bmNlc0Bp ZXRmLm9yZyI+cHdlMy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ U2hhaHJhbSBEYXZhcmk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNywgMjAx MiA1OjUzIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cHdlM0BpZXRmLm9yZyI+ cHdlM0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1BXRTNdIEdBTCBpbiBQVyBx dWVzdGlvbjxicj4NCjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGksPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48dT48L3U+PHU+PC91PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyA1 NTg2IG5vdyBkZWZpbmVzIHVzaW5nIEdBTCBmb3IgUFcuIFRoZSBxdWVzdGlvbiBJIGhhdmUgaXMg ZG9u4oCZdCB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBDQyB0eXBlIGVuY29kaW5nIChhcyBwZXIg UkZDIDUwODUpIGZvciBzaWduYWxpbmcgdGhpcyBjYXBhYmlsaXR5Pzx1PjwvdT48dT48L3U+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91Pjx1PjwvdT4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48dT48L3U+PHU+PC91PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rczx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hhaHJh bTx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3 ZTMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wd2UzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wd2UzPC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBm b3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBD T05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57SJEXCHCCR02co_-- From gregimirsky@gmail.com Wed Jan 18 00:47:01 2012 Return-Path: <gregimirsky@gmail.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512021F8703 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 00:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2IfJV0xoAT0 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 00:47:01 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2A21F853A for <pwe3@ietf.org>; Wed, 18 Jan 2012 00:47:00 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4573529obb.31 for <pwe3@ietf.org>; Wed, 18 Jan 2012 00:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X47P3Mt6JzZbvSCJeGRtcu0WVvdCtxi06y2EakJhu8w=; b=tcjKmtbdFzgDveGfbX1j8uwuDbDkKDocjqKbCITLKHk4Hsj0Q0Dbknaq9uBEWbZBNF mItoj4LifxO6TcVCqoD4yuznCyI6QEol2RoVh9IqcEzG2Jbp4wNuoW6zg4DTtoZzfI4W 284jecZ/0jzhx1ywPhathHC3hKeGTbx80Y8Ck= MIME-Version: 1.0 Received: by 10.182.16.33 with SMTP id c1mr18312166obd.47.1326876419423; Wed, 18 Jan 2012 00:46:59 -0800 (PST) Received: by 10.182.38.72 with HTTP; Wed, 18 Jan 2012 00:46:59 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57@SJEXCHCCR02.corp.ad.broadcom.com> References: <A3C5DF08D38B6049839A6F553B331C760115ED9B68AA@ILPTMAIL02.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 18 Jan 2012 00:46:59 -0800 Message-ID: <CA+RyBmUeROp-ahnAwLmp-6u_VMLLTC_HRR2JENF=kd1PH=p2_Q@mail.gmail.com> From: Greg Mirsky <gregimirsky@gmail.com> To: Shahram Davari <davari@broadcom.com> Content-Type: multipart/alternative; boundary=f46d04479f93a3fdd504b6c97d3e Cc: "pwe3@ietf.org" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 08:47:01 -0000 --f46d04479f93a3fdd504b6c97d3e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Shahram, my $.02 in-line below. Regards, Greg On Tue, Jan 17, 2012 at 11:49 PM, Shahram Davari <davari@broadcom.com>wrote= : > Hi Sasha, > > Two questions: > > 1) Does VCC1, 2, 3 apply to MPLS-TP PW? > GIM>> Yes, absolutely. > > 2) should an MPLS-TP node be configured in order to process received VCCV= 4 > packets? Or it should just process such packets without any configuration= . > GIM>> PW VCCV CC Type 4 is, IMO, can be selected if all PEs support it > when dynamic signalling used. Or be the explicitly configured for static > PW. If another VCCV CC type selected/convigured, then packets with GAL mu= st > be dropped by PE. > Regards, Greg > thanks > Shahram > > *From*: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > *Sent*: Tuesday, January 17, 2012 11:19 PM > *To*: Greg Mirsky <gregimirsky@gmail.com>; Shahram Davari > *Cc*: pwe3@ietf.org <pwe3@ietf.org> > *Subject*: RE: [PWE3] GAL in PW question > > Dear Greg, Shahram and all, > I see only two alternatives here: > > 1. Define VCCV Type 4 (GAL-based) explicitly in a Standard Track > document that updates 5085. The definition must also address the issue= of > priorities among the CC types when the peers support multiple PW types= , etc. > 2. Decide that in spite of 5586 allowing usage of GAL with PWs it will > not be used - for good or until further notice (5586 does not specify= any > usage of GAL with PWs, simply allows it). > > My 2c, > > Sasha > > ------------------------------ > *From:* pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Greg > Mirsky [gregimirsky@gmail.com] > *Sent:* Wednesday, January 18, 2012 8:04 AM > *To:* Shahram Davari > *Cc:* pwe3@ietf.org > *Subject:* Re: [PWE3] GAL in PW question > > Hi Shahram, > you're right, I've noticed that even though the proposal clearly defines > new behavior it, strangely, is on Informational track. But I think that > this is not a big problem and it can be easily put on standard's track ne= xt > time authors submit new revision. I think we'll learn of their plans soon= . > > Regards, > Greg > > On Tue, Jan 17, 2012 at 9:25 PM, Shahram Davari <davari@broadcom.com>wrot= e: > >> ** >> Great, but first of it is expired and secondly it is informational. I >> think we need to bring it back to standards track. >> >> Thx >> Shahram >> >> *From*: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> *Sent*: Tuesday, January 17, 2012 06:06 PM >> *To*: Shahram Davari; pwe3@ietf.org <pwe3@ietf.org> >> *Subject*: RE: GAL in PW question >> >> Hi Shahram, >> I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL on PW as VCC= V >> CC Type 4. >> >> Regards, >> Greg >> >> ------------------------------ >> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf >> Of *Shahram Davari >> *Sent:* Tuesday, January 17, 2012 5:53 PM >> *To:* pwe3@ietf.org >> *Subject:* [PWE3] GAL in PW question >> >> Hi,**** >> >> **** >> >> RFC 5586 now defines using GAL for PW. The question I have is don=92t we >> need to define a new CC type encoding (as per RFC 5085) for signaling th= is >> capability?**** >> >> **** >> >> **** >> >> Thanks**** >> >> Shahram**** >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --f46d04479f93a3fdd504b6c97d3e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Shahram,<br>my $.02 in-line below.<br><br>Regards,<br>Greg<br><br><div c= lass=3D"gmail_quote">On Tue, Jan 17, 2012 at 11:49 PM, Shahram Davari <span= dir=3D"ltr"><<a href=3D"mailto:davari@broadcom.com">davari@broadcom.com= </a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div><font style=3D"font-size:11.0pt;font-family:"Calibri","= sans-serif";color:#1f497d"> Hi Sasha,<br><br>Two questions:<br><br>1) Does VCC1, 2, 3 apply to MPLS-TP = PW?<br>GIM>>=A0 Yes, absolutely.<br></font></div></blockquote><div>= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><font style=3D"font-size:11pt;font-family:"Calibri","sa= ns-serif";color:rgb(31,73,125)">2) should an MPLS-TP node be configure= d in order to process received VCCV4 packets? Or it should just process s= uch packets without any configuration. <br> GIM>> PW VCCV CC Type 4 is, IMO, can be selected if all PEs support i= t when </font><font style=3D"font-size:11pt;font-family:"Calibri"= ,"sans-serif";color:rgb(31,73,125)">dynamic signalling used</font= ><font style=3D"font-size:11pt;font-family:"Calibri","sans-s= erif";color:rgb(31,73,125)">. Or be the explicitly configured for stat= ic PW. If another VCCV CC type selected/convigured, then packets with GAL m= ust be dropped by PE.<br> </font></div></blockquote><div><br>Regards,<br>Greg <br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"><div><font style=3D"font-size:11pt;fon= t-family:"Calibri","sans-serif";color:rgb(31,73,125)">t= hanks<br> Shahram</font><br>=A0<br> <div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in = 0in 0in"> <font style=3D"font-size:10.0pt;font-family:"Tahoma","sans-s= erif""> <b>From</b>: Alexander Vainshtein [mailto:<a href=3D"mailto:Alexander.Vains= htein@ecitele.com" target=3D"_blank">Alexander.Vainshtein@ecitele.com</a>] <br><b>Sent</b>: Tuesday, January 17, 2012 11:19 PM<br><b>To</b>: Greg Mirs= ky <<a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirs= ky@gmail.com</a>>; Shahram Davari <br><b>Cc</b>: <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf= .org</a> <<a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.o= rg</a>> <br><b>Subject</b>: RE: [PWE3] GAL in PW question <br></font>=A0<br></div><div><div class=3D"h5"> <div style=3D"direction:ltr;font-size:16px;font-family:Times New Roman"> <div>Dear Greg,=A0Shahram<a></a> and all,</div> <div><font face=3D"times new roman">I see only two alternatives here:</font= ></div> <ol> <li><font face=3D"times new roman">Define VCCV Type 4 (GAL-based) explicitl= y in a Standard Track document that updates 5085. The definition must also = address the issue of priorities among the CC types when the peers support m= ultiple PW types, etc.</font> </li><li><font face=3D"times new roman">Decide that in spite of 5586 allowi= ng usage of GAL with PWs it will not be used=A0 - for good or until further= notice (5586 does not specify any usage of GAL with PWs, simply allows it)= .</font></li> </ol> <p><font face=3D"times new roman">My 2c,</font></p> <p><font face=3D"times new roman">=A0=A0=A0=A0 Sasha</font></p> <div dir=3D"ltr"><font color=3D"#000000" face=3D"Times New Roman" size=3D"3= "></font>=A0</div> <div style=3D"DIRECTION:ltr"> <hr> <font color=3D"#000000" face=3D"Tahoma"><b>From:</b> <a href=3D"mailto:pwe3= -bounces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org</a> [<a href=3D"= mailto:pwe3-bounces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org</a>] = On Behalf Of Greg Mirsky [<a href=3D"mailto:gregimirsky@gmail.com" target= =3D"_blank">gregimirsky@gmail.com</a>]<br> <b>Sent:</b> Wednesday, January 18, 2012 8:04 AM<br> <b>To:</b> Shahram Davari<br> <b>Cc:</b> <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org= </a><br> <b>Subject:</b> Re: [PWE3] GAL in PW question<br> </font><br> </div> <div></div> <div>Hi Shahram,<br> you're right, I've noticed that even though the proposal clearly de= fines new behavior it, strangely, is on Informational track. But I think th= at this is not a big problem and it can be easily put on standard's tra= ck next time authors submit new revision. I think we'll learn of their plans soon.<br> <br> Regards,<br> Greg<br> <br> <div class=3D"gmail_quote">On Tue, Jan 17, 2012 at 9:25 PM, Shahram Davari = <span dir=3D"ltr"> <<a href=3D"mailto:davari@broadcom.com" target=3D"_blank">davari@broadco= m.com</a>></span> wrote:<br> <blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA= DDING-LEFT:1ex" class=3D"gmail_quote"> <u></u> <div lang=3D"EN-US"><font style=3D"FONT-FAMILY:'Calibri','sans-= serif';COLOR:#1f497d;FONT-SIZE:11pt">Great, but first of it is expired = and secondly it is informational. I think we need to bring it back to stand= ards track.<br> <br> Thx<br> Shahram</font><br> =A0<br> <div style=3D"BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOT= TOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BOR= DER-RIGHT:medium none;PADDING-TOP:3pt"> <font style=3D"FONT-FAMILY:'Tahoma','sans-serif';FONT-SIZE:= 10pt"><b>From</b>: Gregory Mirsky [mailto:<a href=3D"mailto:gregory.mirsky@= ericsson.com" target=3D"_blank">gregory.mirsky@ericsson.com</a>] <br> <b>Sent</b>: Tuesday, January 17, 2012 06:06 PM<br> <b>To</b>: Shahram Davari; <a href=3D"mailto:pwe3@ietf.org" target=3D"_blan= k">pwe3@ietf.org</a> <<a href=3D"mailto:pwe3@ietf.org" target=3D"_blank"= >pwe3@ietf.org</a>> <br> <b>Subject</b>: RE: GAL in PW question <br> </font>=A0<br> </div> <div> <div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial= ">Hi Shahram,</font></span></div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial= ">I think that draft-nadeau-pwe3-vccv-2-02 defines use of GAL on PW as VCCV= CC Type 4.</font></span></div> <div dir=3D"ltr" align=3D"left"><span><font color=3D"#0000ff" face=3D"Arial= "></font></span>=A0</div> <div dir=3D"ltr" align=3D"left"><span>=A0=A0=A0 <font color=3D"#0000ff" fac= e=3D"Arial">Regards,</font></span></div> <div dir=3D"ltr" align=3D"left"><span>=A0=A0=A0=A0=A0=A0=A0 <font color=3D"= #0000ff" face=3D"Arial">Greg</font></span></div> <br> <div dir=3D"ltr" lang=3D"en-us" align=3D"left"> <hr> <font face=3D"Tahoma"><b>From:</b> <a href=3D"mailto:pwe3-bounces@ietf.org"= target=3D"_blank">pwe3-bounces@ietf.org</a> [mailto:<a href=3D"mailto:pwe3= -bounces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org</a>] <b>On Behalf Of </b>Shahram Davari<br> <b>Sent:</b> Tuesday, January 17, 2012 5:53 PM<br> <b>To:</b> <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org= </a><br> <b>Subject:</b> [PWE3] GAL in PW question<br> </font><br> </div> <div></div> <div> <p class=3D"MsoNormal">Hi,<u></u><u></u></p> <p class=3D"MsoNormal"><u></u><u></u>=A0</p> <p class=3D"MsoNormal">RFC 5586 now defines using GAL for PW. The question = I have is don=92t we need to define a new CC type encoding (as per RFC 5085= ) for signaling this capability?<u></u><u></u></p> <p class=3D"MsoNormal"><u></u><u></u>=A0</p> <p class=3D"MsoNormal"><u></u><u></u>=A0</p> <p class=3D"MsoNormal">Thanks<u></u><u></u></p> <p class=3D"MsoNormal">Shahram<u></u><u></u></p> </div> </div> </div> </div> <br> _______________________________________________<br> pwe3 mailing list<br> <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/pwe3</a><br> <br> </blockquote> </div> <br> </div> </div> <p> This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. </p> </div></div></div> </blockquote></div><br> --f46d04479f93a3fdd504b6c97d3e-- From Alexander.Vainshtein@ecitele.com Wed Jan 18 03:11:44 2012 Return-Path: <Alexander.Vainshtein@ecitele.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4470A21F8710 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 03:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.737 X-Spam-Level: X-Spam-Status: No, score=-3.737 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wn7NNEA-6rf for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 03:11:43 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 41E4621F863F for <pwe3@ietf.org>; Wed, 18 Jan 2012 03:11:42 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1326885085!11481015!8 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 14694 invoked from network); 18 Jan 2012 11:11:39 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-11.tower-216.messagelabs.com with SMTP; 18 Jan 2012 11:11:39 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-fc-4f16b56729b6 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 84.1B.03709.765B61F4; Wed, 18 Jan 2012 14:04:55 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 18 Jan 2012 13:11:38 +0200 From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> To: Shahram Davari <davari@broadcom.com> Date: Wed, 18 Jan 2012 13:11:36 +0200 Thread-Topic: [PWE3] GAL in PW question Thread-Index: AczVpuq1HIwiZy5FS92XTqpr3c9bKAACf6G/AAE2aBoAAWtewA== Message-ID: <A3C5DF08D38B6049839A6F553B331C760115EDE75329@ILPTMAIL02.ecitele.com> References: <A3C5DF08D38B6049839A6F553B331C760115ED9B68AA@ILPTMAIL02.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115EDE75329ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLsWRmVeSWpSXmKPExsUy+dWnL7rpW8X8Ddp+KFqs7/W0+DbtKatF 36ctLA7MHrPun2Xz2DnrLrvHkiU/mQKYoxoYbRLz8vJLEktSFVJSi5NtlQKKMssSkyuVFDJT bJUMlRQKchKTU3NT80pslRILClLzUpTsuGyAgpl5Cql5yfkpmXnptkqewf66FhamlrqGSnZq yobG1lwhGZnFCqm6uYmZOQq5qcXFiempCkARkFPzUlJTFNLyixRKMlIVihImM2fMOPmWveDL NsaKv4+nMzUwdmxi7GLk5JAQMJHY1XeEGcIWk7hwbz1bFyMXh5DAXkaJG79+M0E4Uxglmr5c ZQepYhOwldi0+i4biC0ioCFx8NYVsG5mgSiJD7NWg8VZBFQl1q78xQJiCwuoSbzadZ8dol5d 4tHRv6wQtpPEip0Xwa7gFQiUeNhznxFi2UJGiQUr/4MlOIGGNs46CtbACHTe91NrmCCWiUvc ejKfCeJsAYkle85DvSAq8fLxP6h6UYk77esZIerzJVZsPga1TFDi5MwnLBD1khIHV9xgmcAo NgvJ2FlIWmYhaZnFyAEU15RYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFM3MKSpJy0w0M 9VKTM0tSc1L1kvNzNzFC0tHzHYy/5qscYhTgYFTi4dXYJ+ovxJpYVlyZe4hRkoNJSZR373Ix fyG+pPyUyozE4oz4otKc1OJDjBIczEoivAlmQDnelMTKqtSifJiUKzD0JzJLcSfng5JBSbyx gQFujpI479PkN75CAunAxJmdmlqQWgQzR4aDQ0mCd+sKoBWCRanpqRVpmTklCGkmDk6QM3iA zlgPciJvcUFibnFmOkT+FKMuR8u56+cYhVjy8vNSpcR5q0AGCYAUZZTmwc0B5ab6////v2IU BwaAMK8WSBUPMAHDTXoFtIQJaIlHE9gSYCaCS0k1MAY2hO1uPs7ws5L/6nudaestlU6t8N3H zff3k+Wv+smNUfKzfygfZHHvZr2k+TRxlvmqB1wmPcUNxoklNgGL7to/rnmz6a/Ph0WqKcvc 0s5sNtpzZYuP4Y1audsLTl68cWHX/ONBj/eFnMz5IOx5yiUtYEK0W3XcrqwzTY/DzyWz/+l5 vWrF7qdKLMUZiYZazEXFiQDA3xQmKAQAAA== Cc: "'pwe3@ietf.org'" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 11:11:44 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760115EDE75329ILPTMAIL02e_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 U2hhaHJhbSwNClBsZWFzZSBzZWUgc29tZSBhbnN3ZXJzIGlubGluZSBiZWxvdy4NCg0KTXkg MmMsDQogICAgIFNhc2hhDQoNCkZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJp QGJyb2FkY29tLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxMiA5OjUw IEFNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW47ICdncmVnaW1pcnNreUBnbWFpbC5jb20n DQpDYzogJ3B3ZTNAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSZTogW1BXRTNdIEdBTCBpbiBQVyBx dWVzdGlvbg0KDQpIaSBTYXNoYSwNCg0KVHdvIHF1ZXN0aW9uczoNCg0KMSkgRG9lcyBWQ0Mx LCAyLCAzIGFwcGx5IHRvIE1QTFMtVFAgUFc/DQpbW1tTYXNoYV1dXSBJTUhPIGFuZCBGV0lX IFZDQ1YgVHlwZSAxIGRlZmluaXRlbHkgYXBwbGllcyBzaW5jZSBpdCBjYW4gYmUgdXNlZCB3 aXRob3V0IElQL1VEUCBlbmNhcHN1bGF0aW9uICh0aGUgdHlwZSBvZiB0aGUgT0FNIHBhY2tl dHMgaXMgZGVmaW5lZCBieSB0aGUgQS1DSCkuDQoNCg0KMikgU2hvdWxkIGFuIE1QTFMtVFAg bm9kZSBiZSBjb25maWd1cmVkIGluIG9yZGVyIHRvIHByb2Nlc3MgcmVjZWl2ZWQgVkNDVjQg cGFja2V0cz8gT3IgaXQgc2hvdWxkIGp1c3QgcHJvY2VzcyBzdWNoIHBhY2tldHMgd2l0aG91 dCBhbnkgY29uZmlndXJhdGlvbi4NCltbW1Nhc2hhXV1dIFNvIGZhciB0aGVyZSBoYXZlIGJl ZW4gbm8gbWFuZGF0b3J5IFZDQ1YgdHlwZSwgYW5kIFZDQ1YgVHlwZSAxIGhhcyBiZWVuIG1h bmRhdGVkIHdoZXJlIENXIGlzIHVzZWQuIFNvIEkgd291bGQgc2F5IHRoYXQsIGZvciB0aGUg cHVycG9zZSBvZiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBjb25maWd1cmF0aW9uIGFuZCBj b29yZGluYXRpb24gYXJlIHJlcXVpcmVkIHRvIHVzZSBWQ0NWIFR5cGUgNC4NCg0KDQp0aGFu a3MNClNoYWhyYW0NCg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkg MTcsIDIwMTIgMTE6MTkgUE0NClRvOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tPjsgU2hhaHJhbSBEYXZhcmkNCkNjOiBwd2UzQGlldGYub3JnIDxwd2UzQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCg0KRGVhciBHcmVn LCBTaGFocmFtIGFuZCBhbGwsDQpJIHNlZSBvbmx5IHR3byBhbHRlcm5hdGl2ZXMgaGVyZToN Cg0KIDEuICBEZWZpbmUgVkNDViBUeXBlIDQgKEdBTC1iYXNlZCkgZXhwbGljaXRseSBpbiBh IFN0YW5kYXJkIFRyYWNrIGRvY3VtZW50IHRoYXQgdXBkYXRlcyA1MDg1LiBUaGUgZGVmaW5p dGlvbiBtdXN0IGFsc28gYWRkcmVzcyB0aGUgaXNzdWUgb2YgcHJpb3JpdGllcyBhbW9uZyB0 aGUgQ0MgdHlwZXMgd2hlbiB0aGUgcGVlcnMgc3VwcG9ydCBtdWx0aXBsZSBQVyB0eXBlcywg ZXRjLg0KIDIuICBEZWNpZGUgdGhhdCBpbiBzcGl0ZSBvZiA1NTg2IGFsbG93aW5nIHVzYWdl IG9mIEdBTCB3aXRoIFBXcyBpdCB3aWxsIG5vdCBiZSB1c2VkICAtIGZvciBnb29kIG9yIHVu dGlsIGZ1cnRoZXIgbm90aWNlICg1NTg2IGRvZXMgbm90IHNwZWNpZnkgYW55IHVzYWdlIG9m IEdBTCB3aXRoIFBXcywgc2ltcGx5IGFsbG93cyBpdCkuDQoNCk15IDJjLA0KDQogICAgIFNh c2hhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBwd2UzLWJv dW5jZXNAaWV0Zi5vcmcgW3B3ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdy ZWcgTWlyc2t5IFtncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMTgsIDIwMTIgODowNCBBTQ0KVG86IFNoYWhyYW0gRGF2YXJpDQpDYzogcHdlM0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCkhpIFNo YWhyYW0sDQp5b3UncmUgcmlnaHQsIEkndmUgbm90aWNlZCB0aGF0IGV2ZW4gdGhvdWdoIHRo ZSBwcm9wb3NhbCBjbGVhcmx5IGRlZmluZXMgbmV3IGJlaGF2aW9yIGl0LCBzdHJhbmdlbHks IGlzIG9uIEluZm9ybWF0aW9uYWwgdHJhY2suIEJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBu b3QgYSBiaWcgcHJvYmxlbSBhbmQgaXQgY2FuIGJlIGVhc2lseSBwdXQgb24gc3RhbmRhcmQn cyB0cmFjayBuZXh0IHRpbWUgYXV0aG9ycyBzdWJtaXQgbmV3IHJldmlzaW9uLiBJIHRoaW5r IHdlJ2xsIGxlYXJuIG9mIHRoZWlyIHBsYW5zIHNvb24uDQoNClJlZ2FyZHMsDQpHcmVnDQpP biBUdWUsIEphbiAxNywgMjAxMiBhdCA5OjI1IFBNLCBTaGFocmFtIERhdmFyaSA8ZGF2YXJp QGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+IHdyb3RlOg0KR3Jl YXQsIGJ1dCBmaXJzdCBvZiBpdCBpcyBleHBpcmVkIGFuZCBzZWNvbmRseSBpdCBpcyBpbmZv cm1hdGlvbmFsLiBJIHRoaW5rIHdlIG5lZWQgdG8gYnJpbmcgaXQgYmFjayB0byBzdGFuZGFy ZHMgdHJhY2suDQoNClRoeA0KU2hhaHJhbQ0KDQpGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFp bHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lA ZXJpY3Nzb24uY29tPl0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIgMDY6MDYg UE0NClRvOiBTaGFocmFtIERhdmFyaTsgcHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRm Lm9yZz4gPHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UkU6IEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpIaSBTaGFocmFtLA0KSSB0aGluayB0aGF0IGRy YWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi0wMiBkZWZpbmVzIHVzZSBvZiBHQUwgb24gUFcgYXMg VkNDViBDQyBUeXBlIDQuDQoNCiAgICBSZWdhcmRzLA0KICAgICAgICBHcmVnDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwd2UzLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBT aGFocmFtIERhdmFyaQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiA1OjUzIFBN DQpUbzogcHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtQ V0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCkhpLA0KDQpSRkMgNTU4NiBub3cgZGVmaW5lcyB1 c2luZyBHQUwgZm9yIFBXLiBUaGUgcXVlc3Rpb24gSSBoYXZlIGlzIGRvbuKAmXQgd2UgbmVl ZCB0byBkZWZpbmUgYSBuZXcgQ0MgdHlwZSBlbmNvZGluZyAoYXMgcGVyIFJGQyA1MDg1KSBm b3Igc2lnbmFsaW5nIHRoaXMgY2FwYWJpbGl0eT8NCg0KDQpUaGFua3MNClNoYWhyYW0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMg bWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCg0KVGhpcyBlLW1h aWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBi ZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBw aG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3Bp ZXMgdGhlcmVvZi4NCg0KDQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0 aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENP TkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29t LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KDQo= --_000_A3C5DF08D38B6049839A6F553B331C760115EDE75329ILPTMAIL02e_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1l PUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVt KSI+PCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN TCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZp b3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQj Vk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6NTE2MTE1NTA2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot NzIxNjQ3ODUwO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNoYWhyYW0sPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlBsZWFzZSBzZWUgc29tZSBhbnN3ZXJzIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkgMmMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgIFNhc2hh PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBTaGFocmFtIERhdmFyaSBbbWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb21dIDxicj48 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE4LCAyMDEyIDk6NTAgQU08YnI+PGI+ VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgJ2dyZWdpbWlyc2t5QGdtYWlsLmNvbSc8 YnI+PGI+Q2M6PC9iPiAncHdlM0BpZXRmLm9yZyc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBb UFdFM10gR0FMIGluIFBXIHF1ZXN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IaSBTYXNoYSw8YnI+PGJyPlR3 byBxdWVzdGlvbnM6PGJyPjxicj4xKSBEb2VzIFZDQzEsIDIsIDMgYXBwbHkgdG8gTVBMUy1U UCBQVz88L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+W1tbU2FzaGFdXV0gPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JTUhPIGFuZCBGV0lXIFZDQ1YgVHlwZSAxIGRlZmluaXRlbHkgYXBwbGllcyBzaW5jZSBp dCBjYW4gYmUgdXNlZCB3aXRob3V0IElQL1VEUCBlbmNhcHN1bGF0aW9uICh0aGUgdHlwZSBv ZiB0aGUgT0FNIHBhY2tldHMgaXMgZGVmaW5lZCBieSB0aGUgQS1DSCkuIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48YnI+PGJyPjIpIFNob3VsZCBhbiBNUExTLVRQIG5vZGUgYmUgY29uZmlndXJlZCBpbiBv cmRlciB0byBwcm9jZXNzIHJlY2VpdmVkIFZDQ1Y0IHBhY2tldHM/IE9yIGl0IHNob3VsZCBq dXN0IHByb2Nlc3Mgc3VjaCBwYWNrZXRzIHdpdGhvdXQgYW55IGNvbmZpZ3VyYXRpb24uIDwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bW1tT YXNoYV1dXSA8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvIGZh ciB0aGVyZSBoYXZlIGJlZW4gbm8gbWFuZGF0b3J5IFZDQ1YgdHlwZSwgYW5kIFZDQ1YgVHlw ZSAxIGhhcyBiZWVuIG1hbmRhdGVkIHdoZXJlIENXIGlzIHVzZWQuIFNvIEkgd291bGQgc2F5 IHRoYXQsIGZvciB0aGUgcHVycG9zZSBvZiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBjb25m aWd1cmF0aW9uIGFuZCBjb29yZGluYXRpb24gYXJlIHJlcXVpcmVkIHRvIHVzZSBWQ0NWIFR5 cGUgNC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PGJyPjxicj50aGFua3M8YnI+U2hhaHJhbTwvc3Bhbj48YnI+ Jm5ic3A7PG86cD48L286cD48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb208L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ OiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tXSA8YnI+PGI+U2VudDwvYj46IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIg MTE6MTkgUE08YnI+PGI+VG88L2I+OiBHcmVnIE1pcnNreSAmbHQ7Z3JlZ2ltaXJza3lAZ21h aWwuY29tJmd0OzsgU2hhaHJhbSBEYXZhcmkgPGJyPjxiPkNjPC9iPjogcHdlM0BpZXRmLm9y ZyAmbHQ7cHdlM0BpZXRmLm9yZyZndDsgPGJyPjxiPlN1YmplY3Q8L2I+OiBSRTogW1BXRTNd IEdBTCBpbiBQVyBxdWVzdGlvbiA8YnI+PC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5EZWFyIEdyZWcsJm5ic3A7U2hhaHJhbSBhbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPkkgc2VlIG9ubHkgdHdvIGFsdGVybmF0aXZlcyBoZXJlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48b2wgc3RhcnQ9MSB0eXBlPTE+PGxpIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPkRlZmluZSBWQ0NWIFR5 cGUgNCAoR0FMLWJhc2VkKSBleHBsaWNpdGx5IGluIGEgU3RhbmRhcmQgVHJhY2sgZG9jdW1l bnQgdGhhdCB1cGRhdGVzIDUwODUuIFRoZSBkZWZpbml0aW9uIG11c3QgYWxzbyBhZGRyZXNz IHRoZSBpc3N1ZSBvZiBwcmlvcml0aWVzIGFtb25nIHRoZSBDQyB0eXBlcyB3aGVuIHRoZSBw ZWVycyBzdXBwb3J0IG11bHRpcGxlIFBXIHR5cGVzLCBldGMuIDxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSc+RGVjaWRlIHRoYXQgaW4gc3BpdGUgb2YgNTU4NiBhbGxvd2luZyB1c2FnZSBvZiBH QUwgd2l0aCBQV3MgaXQgd2lsbCBub3QgYmUgdXNlZCZuYnNwOyAtIGZvciBnb29kIG9yIHVu dGlsIGZ1cnRoZXIgbm90aWNlICg1NTg2IGRvZXMgbm90IHNwZWNpZnkgYW55IHVzYWdlIG9m IEdBTCB3aXRoIFBXcywgc2ltcGx5IGFsbG93cyBpdCkuPG86cD48L286cD48L2xpPjwvb2w+ PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5NeSAyYyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgU2FzaGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdiBpZD1kaXZScEY2NDkwMj48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1j ZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz4gcHdlMy1ib3VuY2VzQGlldGYub3JnIFtwd2UzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnIE1pcnNreSBbZ3JlZ2ltaXJza3lAZ21haWwuY29tXTxicj48Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDE4LCAyMDEyIDg6MDQgQU08YnI+PGI+VG86 PC9iPiBTaGFocmFtIERhdmFyaTxicj48Yj5DYzo8L2I+IHB3ZTNAaWV0Zi5vcmc8YnI+PGI+ U3ViamVjdDo8L2I+IFJlOiBbUFdFM10gR0FMIGluIFBXIHF1ZXN0aW9uPC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5IaSBTaGFocmFtLDxicj55b3UncmUgcmlnaHQsIEkndmUg bm90aWNlZCB0aGF0IGV2ZW4gdGhvdWdoIHRoZSBwcm9wb3NhbCBjbGVhcmx5IGRlZmluZXMg bmV3IGJlaGF2aW9yIGl0LCBzdHJhbmdlbHksIGlzIG9uIEluZm9ybWF0aW9uYWwgdHJhY2su IEJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBub3QgYSBiaWcgcHJvYmxlbSBhbmQgaXQgY2Fu IGJlIGVhc2lseSBwdXQgb24gc3RhbmRhcmQncyB0cmFjayBuZXh0IHRpbWUgYXV0aG9ycyBz dWJtaXQgbmV3IHJldmlzaW9uLiBJIHRoaW5rIHdlJ2xsIGxlYXJuIG9mIHRoZWlyIHBsYW5z IHNvb24uPGJyPjxicj5SZWdhcmRzLDxicj5HcmVnPG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T24gVHVl LCBKYW4gMTcsIDIwMTIgYXQgOToyNSBQTSwgU2hhaHJhbSBEYXZhcmkgJmx0OzxhIGhyZWY9 Im1haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tIj5kYXZhcmlAYnJvYWRjb20uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+R3JlYXQsIGJ1dCBmaXJzdCBvZiBpdCBpcyBl eHBpcmVkIGFuZCBzZWNvbmRseSBpdCBpcyBpbmZvcm1hdGlvbmFsLiBJIHRoaW5rIHdlIG5l ZWQgdG8gYnJpbmcgaXQgYmFjayB0byBzdGFuZGFyZHMgdHJhY2suPGJyPjxicj5UaHg8YnI+ U2hhaHJhbTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNz PU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb208L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+OiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iPmdyZWdvcnkubWlyc2t5QGVy aWNzc29uLmNvbTwvYT5dIDxicj48Yj5TZW50PC9iPjogVHVlc2RheSwgSmFudWFyeSAxNywg MjAxMiAwNjowNiBQTTxicj48Yj5UbzwvYj46IFNoYWhyYW0gRGF2YXJpOyA8YSBocmVmPSJt YWlsdG86cHdlM0BpZXRmLm9yZyI+cHdlM0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwd2UzQGlldGYub3JnIj5wd2UzQGlldGYub3JnPC9hPiZndDsgPGJyPjxiPlN1Ympl Y3Q8L2I+OiBSRTogR0FMIGluIFBXIHF1ZXN0aW9uIDxicj48L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+SGkgU2hhaHJhbSw8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibHVlJz5JIHRoaW5rIHRoYXQgZHJhZnQtbmFkZWF1LXB3ZTMtdmNjdi0yLTAyIGRlZmlu ZXMgdXNlIG9mIEdBTCBvbiBQVyBhcyBWQ0NWIENDIFR5cGUgNC48L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkdyZWc8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg Y2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXIn PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxp Z249Y2VudGVyPjwvc3Bhbj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IDxhIGhy ZWY9Im1haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmciPnB3ZTMtYm91bmNlc0BpZXRmLm9y ZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnIj5w d2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlNoYWhyYW0g RGF2YXJpPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDEyIDU6NTMg UE08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cHdlM0BpZXRmLm9yZyI+cHdlM0Bp ZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rp b248L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlJGQyA1 NTg2IG5vdyBkZWZpbmVzIHVzaW5nIEdBTCBmb3IgUFcuIFRoZSBxdWVzdGlvbiBJIGhhdmUg aXMgZG9u4oCZdCB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBDQyB0eXBlIGVuY29kaW5nIChh cyBwZXIgUkZDIDUwODUpIGZvciBzaWduYWxpbmcgdGhpcyBjYXBhYmlsaXR5PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlNoYWhyYW08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+cHdlMyBt YWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0 Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcHdlMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcHdlMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwPlRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50 ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24g d2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8g RUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQg dGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuIDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwPg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRl bmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3 aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBF Q0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0 aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCjwvcD4N CjwvYm9keT48L2h0bWw+ --_000_A3C5DF08D38B6049839A6F553B331C760115EDE75329ILPTMAIL02e_-- From lizho.jin@gmail.com Wed Jan 18 05:50:52 2012 Return-Path: <lizho.jin@gmail.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43CD21F8808 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 05:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbW37Ds2jaJG for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 05:50:51 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C323021F8802 for <pwe3@ietf.org>; Wed, 18 Jan 2012 05:50:50 -0800 (PST) Received: by qcsc1 with SMTP id c1so3143238qcs.31 for <pwe3@ietf.org>; Wed, 18 Jan 2012 05:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eo05RXYQGJR6CEPxqb6AijyuEqZvBsCqRP92UMpTdfM=; b=M9AiBzy15AjaRqRdEJS8+TlW5CxtwlaEv6C8B5Ee5gPdIw5J22SM8PGg6LZHEgQMhc YM45clO7dYipWi8KKBjXqqqgXs1TkkddfnBOhhPsFZ94GuHLyc+IAJFDCcut6EcaC3ys offatYWSsUPE/tpIXlv/wQTeCobjMpnZsCiM4= MIME-Version: 1.0 Received: by 10.229.77.24 with SMTP id e24mr8919879qck.0.1326894650142; Wed, 18 Jan 2012 05:50:50 -0800 (PST) Received: by 10.224.1.7 with HTTP; Wed, 18 Jan 2012 05:50:50 -0800 (PST) In-Reply-To: <CB3ADCBB.253C7%skraza@cisco.com> References: <CAH==cJzjo54j3kBFZXfy2ufOwigJYddQ=nA6LtQX_UVbwwoDkg@mail.gmail.com> <CB3ADCBB.253C7%skraza@cisco.com> Date: Wed, 18 Jan 2012 21:50:50 +0800 Message-ID: <CAH==cJy_eMtYUbRcsc2xNv88YSONCSmkmn4mXpJhSSEWMN-cuA@mail.gmail.com> From: Lizhong Jin <lizho.jin@gmail.com> To: Kamran Raza <skraza@cisco.com> Content-Type: multipart/alternative; boundary=002354470b1846b03204b6cdbc43 Cc: cpignata@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 13:50:52 -0000 --002354470b1846b03204b6cdbc43 Content-Type: text/plain; charset=ISO-8859-1 Hi Kamran, Thank you for the clarification. I am OK with that now. Lizhong 2012/1/17 Kamran Raza <skraza@cisco.com> > Hi Lizhong, > > Although same label (e.g. Implicit-null) can be used for more than one > prefix FEC, currently I do not see an example / usage of same label for PW > FEC. However, LDP Typed Wildcard spec/guidelines RFC 5918 allows a FEC > designer to possibly constrain Typed Wildcarding in a scope of some label, > hence the same applies to Typed WC PW FEC; We should conform to Typed WC > guidelines while defining Typed WC FEC for a FEC and hence we should leave > this possibility for future even if it does not seem to apply currently. > Moreover, It does not harm as it is an optional param anyways. > > HTC. > > > On 12-01-15 8:43 AM, "Lizhong Jin" <lizho.jin@gmail.com> wrote: > > Hi Kamran, > I review this new version, and in section 3, it says: "Label TLV in label > messages to further constraint the wildcard to all FECs of the specified > FEC type [and its specific filter] that are also bound to the specified > label." > Does that mean, there would be one label allocated for more than one > PW-FEC? The PW label would be allocated from the per-platform label space. > Could you give me an example that one PW label is allocated for more than > one PW-FEC? > > Thank you. > Lizhong > > > > ------------------------------ > > Message: 3 > Date: Thu, 12 Jan 2012 14:48:32 -0500 > From: "Andrew G. Malis" <amalis@gmail.com> > To: pwe3@ietf.org > Subject: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 > Message-ID: > <CAK+d4xtmnnxQ5ZppXvYy18ik6LxdbNwp7kyYakC4sVcL=EiKFQ@mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > This email begins a two week working group last call for > draft-ietf-pwe3-pw-typed-wc-fec-02. > > Please post any comments to the PWE3 mailing list. > > This working group last call will end on Thursday 26 January 2012. > > Regards, > Andy & Matthew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/pwe3/attachments/20120112/c7bfef1f/attachment.htm > > > > ------------------------------ > > > > -- > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > *http://www.cisco.com* > > > > --002354470b1846b03204b6cdbc43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Kamran,</div> <div>Thank you for the clarification. I am OK with that now.</div> <div>=A0</div> <div>Lizhong<br><br></div> <div class=3D"gmail_quote">2012/1/17 Kamran Raza <span dir=3D"ltr"><<a h= ref=3D"mailto:skraza@cisco.com">skraza@cisco.com</a>></span><br> <blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA= DDING-LEFT:1ex" class=3D"gmail_quote"> <div><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"FONT-= SIZE:11pt">Hi Lizhong,<br><br>Although same label (e.g. Implicit-null) can = be used for more than one prefix FEC, currently I do not see an example / u= sage of same label for PW FEC. However, LDP Typed Wildcard spec/guidelines = RFC 5918 allows a FEC designer to possibly constrain Typed Wildcarding in a= scope of some label, hence the same applies to Typed WC PW FEC; =A0We shou= ld conform to Typed WC guidelines while defining Typed WC FEC for a FEC and= hence we should leave this possibility for future even if it does not seem= to apply currently. Moreover, It does not harm as it is an optional param = anyways.<br> <br>HTC.=20 <div> <div class=3D"h5"><br><br>On 12-01-15 8:43 AM, "Lizhong Jin" <= <a href=3D"http://lizho.jin@gmail.com" target=3D"_blank">lizho.jin@gmail.co= m</a>> wrote:<br><br></div></div></span></font> <div> <div class=3D"h5"> <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style= =3D"FONT-SIZE:11pt">Hi Kamran,<br>I review this new version, and in section= 3, it says: "Label TLV in label messages to further constraint the wi= ldcard to=A0all FECs of the specified FEC type [and its specific filter] th= at=A0are also bound to the specified label."<br> Does that mean, there would be one label allocated for more than one PW-FEC= ? The PW label would be allocated from the per-platform label space. Could = you give me an example that one PW=A0label=A0is allocated for more than one= PW-FEC?<br> =A0<br>Thank you.<br>Lizhong<br>=A0<br>=A0<br></span></font> <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style= =3D"FONT-SIZE:11pt">------------------------------<br><br>Message: 3<br>Dat= e: Thu, 12 Jan 2012 14:48:32 -0500<br>From: "Andrew G. Malis" <= ;<a href=3D"http://amalis@gmail.com" target=3D"_blank">amalis@gmail.com</a>= ><br> To: <a href=3D"http://pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org</a><br= >Subject: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02<br>Mes= sage-ID:<br>=A0 =A0 =A0 =A0<<a href=3D"http://CAK+d4xtmnnxQ5ZppXvYy18ik6= LxdbNwp7kyYakC4sVcL=3DEiKFQ@mail.gmail.com" target=3D"_blank">CAK+d4xtmnnxQ= 5ZppXvYy18ik6LxdbNwp7kyYakC4sVcL=3DEiKFQ@mail.gmail.com</a>><br> Content-Type: text/plain; charset=3D"iso-8859-1"<br><br>This emai= l begins a two week working group last call for<br>draft-ietf-pwe3-pw-typed= -wc-fec-02.<br><br>Please post any comments to the PWE3 mailing list.<br> <br>This working group last call will end on Thursday 26 January 2012.<br><= br>Regards,<br>Andy & Matthew<br>-------------- next part -------------= -<br>An HTML attachment was scrubbed...<br>URL: <<a href=3D"http://www.i= etf.org/mail-archive/web/pwe3/attachments/20120112/c7bfef1f/attachment.htm"= target=3D"_blank">http://www.ietf.org/mail-archive/web/pwe3/attachments/20= 120112/c7bfef1f/attachment.htm</a>><br> <br>------------------------------<br></span></font></blockquote><font face= =3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"FONT-SIZE:11pt"><br>= </span></font></blockquote></div></div><span class=3D"HOEnZb"><font color= =3D"#888888"><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style= =3D"FONT-SIZE:11pt"><br> -- <br></span></font><font size=3D"1"><font face=3D"Courier, Courier New"><= span style=3D"FONT-SIZE:9pt">Syed Kamran Raza<br>Technical Leader, SPRSG IO= S-XR Routing (MPLS)<br>Cisco Systems, Inc., <br>Kanata, ON, K2K 3E8, Canada= <br> Ph: <a href=3D"tel:%2B1%20%28613%29%20254-4520" target=3D"_blank" value=3D"= +16132544520">+1 (613) 254-4520</a><br><font color=3D"#0f32ef"><u><a href= =3D"http://www.cisco.com/" target=3D"_blank">http://www.cisco.com</a></u></= font> <br> </span></font></font><font face=3D"Calibri, Verdana, Helvetica, Arial"><spa= n style=3D"FONT-SIZE:11pt"><br><br><br></span></font></font></span></div></= blockquote></div><br> --002354470b1846b03204b6cdbc43-- From davari@broadcom.com Wed Jan 18 07:37:10 2012 Return-Path: <davari@broadcom.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4017F21F86F3 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 07:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKI07icVDAtc for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 07:37:09 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 110BE21F86DB for <pwe3@ietf.org>; Wed, 18 Jan 2012 07:37:09 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 18 Jan 2012 07:46:06 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 18 Jan 2012 07:36:52 -0800 From: "Shahram Davari" <davari@broadcom.com> To: "'gregimirsky@gmail.com'" <gregimirsky@gmail.com> Date: Wed, 18 Jan 2012 07:36:51 -0800 Thread-Topic: [PWE3] GAL in PW question Thread-Index: AczVvccBOllSFmo1TvawN08Zg+yJogAOTjLw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D59@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <CA+RyBmUeROp-ahnAwLmp-6u_VMLLTC_HRR2JENF=kd1PH=p2_Q@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 630836B43DS17096102-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D59SJEXCHCCR02co_ Cc: "'pwe3@ietf.org'" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 18 Jan 2012 15:37:10 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D59SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhZ3JlZS4NCg0KVGh4DQpTRA0KDQpGcm9tOiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxMiAxMjo0NiBB TQ0KVG86IFNoYWhyYW0gRGF2YXJpDQpDYzogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPjsgcHdlM0BpZXRmLm9yZyA8cHdl M0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUFdFM10gR0FMIGluIFBXIHF1ZXN0aW9uDQoNCkhp IFNoYWhyYW0sDQpteSAkLjAyIGluLWxpbmUgYmVsb3cuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9u IFR1ZSwgSmFuIDE3LCAyMDEyIGF0IDExOjQ5IFBNLCBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJy b2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+IHdyb3RlOg0KSGkgU2FzaGEs DQoNClR3byBxdWVzdGlvbnM6DQoNCjEpIERvZXMgVkNDMSwgMiwgMyBhcHBseSB0byBNUExTLVRQ IFBXPw0KR0lNPj4gIFllcywgYWJzb2x1dGVseS4NCg0KMikgc2hvdWxkIGFuIE1QTFMtVFAgbm9k ZSBiZSBjb25maWd1cmVkIGluIG9yZGVyIHRvIHByb2Nlc3MgcmVjZWl2ZWQgVkNDVjQgcGFja2V0 cz8gT3IgaXQgc2hvdWxkIGp1c3QgcHJvY2VzcyBzdWNoIHBhY2tldHMgd2l0aG91dCBhbnkgY29u ZmlndXJhdGlvbi4NCkdJTT4+IFBXIFZDQ1YgQ0MgVHlwZSA0IGlzLCBJTU8sIGNhbiBiZSBzZWxl Y3RlZCBpZiBhbGwgUEVzIHN1cHBvcnQgaXQgd2hlbiBkeW5hbWljIHNpZ25hbGxpbmcgdXNlZC4g T3IgYmUgdGhlIGV4cGxpY2l0bHkgY29uZmlndXJlZCBmb3Igc3RhdGljIFBXLiBJZiBhbm90aGVy IFZDQ1YgQ0MgdHlwZSBzZWxlY3RlZC9jb252aWd1cmVkLCB0aGVuIHBhY2tldHMgd2l0aCBHQUwg bXVzdCBiZSBkcm9wcGVkIGJ5IFBFLg0KDQpSZWdhcmRzLA0KR3JlZw0KdGhhbmtzDQpTaGFocmFt DQoNCkZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPl0N ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIgMTE6MTkgUE0NClRvOiBHcmVnIE1pcnNr eSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pjsg U2hhaHJhbSBEYXZhcmkNCkNjOiBwd2UzQGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYub3JnPiA8 cHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW1BXRTNd IEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpEZWFyIEdyZWcsIFNoYWhyYW0gYW5kIGFsbCwNCkkgc2Vl IG9ubHkgdHdvIGFsdGVybmF0aXZlcyBoZXJlOg0KDQogMS4gIERlZmluZSBWQ0NWIFR5cGUgNCAo R0FMLWJhc2VkKSBleHBsaWNpdGx5IGluIGEgU3RhbmRhcmQgVHJhY2sgZG9jdW1lbnQgdGhhdCB1 cGRhdGVzIDUwODUuIFRoZSBkZWZpbml0aW9uIG11c3QgYWxzbyBhZGRyZXNzIHRoZSBpc3N1ZSBv ZiBwcmlvcml0aWVzIGFtb25nIHRoZSBDQyB0eXBlcyB3aGVuIHRoZSBwZWVycyBzdXBwb3J0IG11 bHRpcGxlIFBXIHR5cGVzLCBldGMuDQogMi4gIERlY2lkZSB0aGF0IGluIHNwaXRlIG9mIDU1ODYg YWxsb3dpbmcgdXNhZ2Ugb2YgR0FMIHdpdGggUFdzIGl0IHdpbGwgbm90IGJlIHVzZWQgIC0gZm9y IGdvb2Qgb3IgdW50aWwgZnVydGhlciBub3RpY2UgKDU1ODYgZG9lcyBub3Qgc3BlY2lmeSBhbnkg dXNhZ2Ugb2YgR0FMIHdpdGggUFdzLCBzaW1wbHkgYWxsb3dzIGl0KS4NCg0KTXkgMmMsDQoNCiAg ICAgU2FzaGENCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcHdl My1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmc+IFtwd2UzLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBHcmVnIE1pcnNreSBbZ3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBn bWFpbC5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE4LCAyMDEyIDg6MDQgQU0NClRv OiBTaGFocmFtIERhdmFyaQ0KQ2M6IHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW1BXRTNdIEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpIaSBTaGFocmFtLA0K eW91J3JlIHJpZ2h0LCBJJ3ZlIG5vdGljZWQgdGhhdCBldmVuIHRob3VnaCB0aGUgcHJvcG9zYWwg Y2xlYXJseSBkZWZpbmVzIG5ldyBiZWhhdmlvciBpdCwgc3RyYW5nZWx5LCBpcyBvbiBJbmZvcm1h dGlvbmFsIHRyYWNrLiBCdXQgSSB0aGluayB0aGF0IHRoaXMgaXMgbm90IGEgYmlnIHByb2JsZW0g YW5kIGl0IGNhbiBiZSBlYXNpbHkgcHV0IG9uIHN0YW5kYXJkJ3MgdHJhY2sgbmV4dCB0aW1lIGF1 dGhvcnMgc3VibWl0IG5ldyByZXZpc2lvbi4gSSB0aGluayB3ZSdsbCBsZWFybiBvZiB0aGVpciBw bGFucyBzb29uLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIEphbiAxNywgMjAxMiBhdCA5 OjI1IFBNLCBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJp QGJyb2FkY29tLmNvbT4+IHdyb3RlOg0KR3JlYXQsIGJ1dCBmaXJzdCBvZiBpdCBpcyBleHBpcmVk IGFuZCBzZWNvbmRseSBpdCBpcyBpbmZvcm1hdGlvbmFsLiBJIHRoaW5rIHdlIG5lZWQgdG8gYnJp bmcgaXQgYmFjayB0byBzdGFuZGFyZHMgdHJhY2suDQoNClRoeA0KU2hhaHJhbQ0KDQpGcm9tOiBH cmVnb3J5IE1pcnNreSBbbWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86 Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPl0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcs IDIwMTIgMDY6MDYgUE0NClRvOiBTaGFocmFtIERhdmFyaTsgcHdlM0BpZXRmLm9yZzxtYWlsdG86 cHdlM0BpZXRmLm9yZz4gPHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUkU6IEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpIaSBTaGFocmFtLA0KSSB0aGluayB0aGF0 IGRyYWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi0wMiBkZWZpbmVzIHVzZSBvZiBHQUwgb24gUFcgYXMg VkNDViBDQyBUeXBlIDQuDQoNCiAgICBSZWdhcmRzLA0KICAgICAgICBHcmVnDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBTaGFocmFtIERhdmFy aQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiA1OjUzIFBNDQpUbzogcHdlM0BpZXRm Lm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtQV0UzXSBHQUwgaW4gUFcgcXVl c3Rpb24NCg0KSGksDQoNClJGQyA1NTg2IG5vdyBkZWZpbmVzIHVzaW5nIEdBTCBmb3IgUFcuIFRo ZSBxdWVzdGlvbiBJIGhhdmUgaXMgZG9u4oCZdCB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBDQyB0 eXBlIGVuY29kaW5nIChhcyBwZXIgUkZDIDUwODUpIGZvciBzaWduYWxpbmcgdGhpcyBjYXBhYmls aXR5Pw0KDQoNClRoYW5rcw0KU2hhaHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5nIGxpc3QNCnB3ZTNAaWV0Zi5vcmc8bWFp bHRvOnB3ZTNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3B3ZTMNCg0KDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNp cGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFM IGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5 IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bGwgY29waWVzIHRoZXJlb2YuDQoNCg== --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D59SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KSSBhZ3JlZS48YnI+ PGJyPlRoeDxicj5TRDwvZm9udD48YnI+Jm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGI+RnJvbTwvYj46IEdyZWcgTWly c2t5IFttYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tXQ08YnI+PGI+U2VudDwvYj46IFdlZG5l c2RheSwgSmFudWFyeSAxOCwgMjAxMiAxMjo0NiBBTTxicj48Yj5UbzwvYj46IFNoYWhyYW0gRGF2 YXJpDTxicj48Yj5DYzwvYj46IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tICZsdDtB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZndDs7IHB3ZTNAaWV0Zi5vcmcgJmx0O3B3 ZTNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtQV0UzXSBHQUwgaW4gUFcg cXVlc3Rpb24NPGJyPjwvZm9udD4mbmJzcDs8YnI+PC9kaXY+DQpIaSBTaGFocmFtLDxicj5teSAk LjAyIGluLWxpbmUgYmVsb3cuPGJyPjxicj5SZWdhcmRzLDxicj5HcmVnPGJyPjxicj48ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBKYW4gMTcsIDIwMTIgYXQgMTE6NDkgUE0sIFNoYWhy YW0gRGF2YXJpIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmFyaUBicm9h ZGNvbS5jb20iPmRhdmFyaUBicm9hZGNvbS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQoNCg0KDQoNCjxk aXY+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPg0KSGkgU2FzaGEs PGJyPjxicj5Ud28gcXVlc3Rpb25zOjxicj48YnI+MSkgRG9lcyBWQ0MxLCAyLCAzIGFwcGx5IHRv IE1QTFMtVFAgUFc/PGJyPkdJTSZndDsmZ3Q7wqAgWWVzLCBhYnNvbHV0ZWx5Ljxicj48L2ZvbnQ+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+wqA8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB0IDBwdCAwcHQgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNv bGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pjxmb250IHN0eWxl PSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDMxLDczLDEyNSkiPjIpIHNob3VsZCBhbiBNUExTLVRQ IG5vZGUgYmUgY29uZmlndXJlZCAgaW4gb3JkZXIgdG8gcHJvY2VzcyAgcmVjZWl2ZWQgVkNDVjQg cGFja2V0cz8gT3IgaXQgc2hvdWxkIGp1c3QgcHJvY2VzcyBzdWNoIHBhY2tldHMgd2l0aG91dCBh bnkgY29uZmlndXJhdGlvbi4gPGJyPg0KR0lNJmd0OyZndDsgUFcgVkNDViBDQyBUeXBlIDQgaXMs IElNTywgY2FuIGJlIHNlbGVjdGVkIGlmIGFsbCBQRXMgc3VwcG9ydCBpdCB3aGVuIDwvZm9udD48 Zm9udCBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzMSw3MywxMjUpIj5keW5hbWljIHNp Z25hbGxpbmcgdXNlZDwvZm9udD48Zm9udCBzdHlsZT0iZm9udC1zaXplOjExcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigz MSw3MywxMjUpIj4uIE9yIGJlIHRoZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgZm9yIHN0YXRpYyBQ Vy4gSWYgYW5vdGhlciBWQ0NWIENDIHR5cGUgc2VsZWN0ZWQvY29udmlndXJlZCwgdGhlbiBwYWNr ZXRzIHdpdGggR0FMIG11c3QgYmUgZHJvcHBlZCBieSBQRS48YnI+DQo8L2ZvbnQ+PC9kaXY+PC9i bG9ja3F1b3RlPjxkaXY+PGJyPlJlZ2FyZHMsPGJyPkdyZWcgPGJyPjwvZGl2PjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHQgMHB0IDBwdCAwLjhleDtib3Jk ZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2 Pjxmb250IHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDMxLDczLDEyNSkiPnRoYW5rczxi cj4NClNoYWhyYW08L2ZvbnQ+PGJyPsKgPGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGI+RnJvbTwvYj46IEFsZXhhbmRlciBWYWlu c2h0ZWluIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208 L2E+XQ0KPGJyPjxiPlNlbnQ8L2I+OiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDEyIDExOjE5IFBN PGJyPjxiPlRvPC9iPjogR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNr eUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0 OzsgU2hhaHJhbSBEYXZhcmkNCjxicj48Yj5DYzwvYj46IDxhIGhyZWY9Im1haWx0bzpwd2UzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdlM0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwd2UzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdlM0BpZXRmLm9yZzwvYT4mZ3Q7 DQo8YnI+PGI+U3ViamVjdDwvYj46IFJFOiBbUFdFM10gR0FMIGluIFBXIHF1ZXN0aW9uDQo8YnI+ PC9mb250PsKgPGJyPjwvZGl2PjxkaXY+PGRpdiBjbGFzcz0iaDUiPg0KDQo8ZGl2IHN0eWxlPSJk aXJlY3Rpb246bHRyO2ZvbnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OlRpbWVzIE5ldyBSb21hbiI+ DQo8ZGl2PkRlYXIgR3JlZyzCoFNoYWhyYW08YT48L2E+IGFuZCBhbGwsPC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+SSBzZWUgb25seSB0d28gYWx0ZXJuYXRpdmVzIGhl cmU6PC9mb250PjwvZGl2Pg0KPG9sPg0KPGxpPjxmb250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+ RGVmaW5lIFZDQ1YgVHlwZSA0IChHQUwtYmFzZWQpIGV4cGxpY2l0bHkgaW4gYSBTdGFuZGFyZCBU cmFjayBkb2N1bWVudCB0aGF0IHVwZGF0ZXMgNTA4NS4gVGhlIGRlZmluaXRpb24gbXVzdCBhbHNv IGFkZHJlc3MgdGhlIGlzc3VlIG9mIHByaW9yaXRpZXMgYW1vbmcgdGhlIENDIHR5cGVzIHdoZW4g dGhlIHBlZXJzIHN1cHBvcnQgbXVsdGlwbGUgUFcgdHlwZXMsIGV0Yy48L2ZvbnQ+DQo8L2xpPjxs aT48Zm9udCBmYWNlPSJ0aW1lcyBuZXcgcm9tYW4iPkRlY2lkZSB0aGF0IGluIHNwaXRlIG9mIDU1 ODYgYWxsb3dpbmcgdXNhZ2Ugb2YgR0FMIHdpdGggUFdzIGl0IHdpbGwgbm90IGJlIHVzZWTCoCAt IGZvciBnb29kIG9yIHVudGlsIGZ1cnRoZXIgbm90aWNlICg1NTg2IGRvZXMgbm90IHNwZWNpZnkg YW55IHVzYWdlIG9mIEdBTCB3aXRoIFBXcywgc2ltcGx5IGFsbG93cyBpdCkuPC9mb250PjwvbGk+ DQo8L29sPg0KPHA+PGZvbnQgZmFjZT0idGltZXMgbmV3IHJvbWFuIj5NeSAyYyw8L2ZvbnQ+PC9w Pg0KPHA+PGZvbnQgZmFjZT0idGltZXMgbmV3IHJvbWFuIj7CoMKgwqDCoCBTYXNoYTwvZm9udD48 L3A+DQo8ZGl2IGRpcj0ibHRyIj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPSIzIj48L2ZvbnQ+wqA8L2Rpdj4NCjxkaXYgc3R5bGU9IkRJUkVDVElPTjps dHIiPg0KPGhyPg0KPGZvbnQgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8 L2I+IDxhIGhyZWY9Im1haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5wd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86cHdlMy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdlMy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIEdyZWcgTWlyc2t5IFs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPl08YnI+DQoNCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMTgsIDIwMTIgODowNCBBTTxicj4NCjxiPlRv OjwvYj4gU2hhaHJhbSBEYXZhcmk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwd2Uz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdlM0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb248YnI+DQo8L2ZvbnQ+PGJyPg0K PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5IaSBTaGFocmFtLDxicj4NCnlvdSYjMzk7cmUgcmln aHQsIEkmIzM5O3ZlIG5vdGljZWQgdGhhdCBldmVuIHRob3VnaCB0aGUgcHJvcG9zYWwgY2xlYXJs eSBkZWZpbmVzIG5ldyBiZWhhdmlvciBpdCwgc3RyYW5nZWx5LCBpcyBvbiBJbmZvcm1hdGlvbmFs IHRyYWNrLiBCdXQgSSB0aGluayB0aGF0IHRoaXMgaXMgbm90IGEgYmlnIHByb2JsZW0gYW5kIGl0 IGNhbiBiZSBlYXNpbHkgcHV0IG9uIHN0YW5kYXJkJiMzOTtzIHRyYWNrIG5leHQgdGltZSBhdXRo b3JzIHN1Ym1pdCBuZXcgcmV2aXNpb24uIEkNCiB0aGluayB3ZSYjMzk7bGwgbGVhcm4gb2YgdGhl aXIgcGxhbnMgc29vbi48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkdyZWc8YnI+DQo8YnI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBKYW4gMTcsIDIwMTIgYXQgOToyNSBQTSwg U2hhaHJhbSBEYXZhcmkgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZh cmlAYnJvYWRjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2YXJpQGJyb2FkY29tLmNvbTwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2Nj YyAxcHggc29saWQ7TUFSR0lOOjBweCAwcHggMHB4IDAuOGV4O1BBRERJTkctTEVGVDoxZXgiIGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8dT48L3U+DQo8ZGl2IGxhbmc9IkVOLVVTIj48Zm9udCBzdHls ZT0iRk9OVC1GQU1JTFk6JiMzOTtDYWxpYnJpJiMzOTssJiMzOTtzYW5zLXNlcmlmJiMzOTs7Q09M T1I6IzFmNDk3ZDtGT05ULVNJWkU6MTFwdCI+R3JlYXQsIGJ1dCBmaXJzdCBvZiBpdCBpcyBleHBp cmVkIGFuZCBzZWNvbmRseSBpdCBpcyBpbmZvcm1hdGlvbmFsLiBJIHRoaW5rIHdlIG5lZWQgdG8g YnJpbmcgaXQgYmFjayB0byBzdGFuZGFyZHMgdHJhY2suPGJyPg0KDQo8YnI+DQpUaHg8YnI+DQpT aGFocmFtPC9mb250Pjxicj4NCsKgPGJyPg0KPGRpdiBzdHlsZT0iQk9SREVSLUJPVFRPTTptZWRp dW0gbm9uZTtCT1JERVItTEVGVDptZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFERElO Ry1MRUZUOjBpbjtQQURESU5HLVJJR0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlk O0JPUkRFUi1SSUdIVDptZWRpdW0gbm9uZTtQQURESU5HLVRPUDozcHQiPg0KPGZvbnQgc3R5bGU9 IkZPTlQtRkFNSUxZOiYjMzk7VGFob21hJiMzOTssJiMzOTtzYW5zLXNlcmlmJiMzOTs7Rk9OVC1T SVpFOjEwcHQiPjxiPkZyb208L2I+OiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDwvYj46IFR1ZXNkYXksIEph bnVhcnkgMTcsIDIwMTIgMDY6MDYgUE08YnI+DQo8Yj5UbzwvYj46IFNoYWhyYW0gRGF2YXJpOyA8 YSBocmVmPSJtYWlsdG86cHdlM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB3ZTNAaWV0Zi5v cmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cHdlM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnB3ZTNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U3ViamVjdDwvYj46IFJFOiBHQUwgaW4g UFcgcXVlc3Rpb24gPGJyPg0KPC9mb250PsKgPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFj ZT0iQXJpYWwiPkhpIFNoYWhyYW0sPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIi IGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgZmFjZT0iQXJpYWwiPkkg dGhpbmsgdGhhdCBkcmFmdC1uYWRlYXUtcHdlMy12Y2N2LTItMDIgZGVmaW5lcyB1c2Ugb2YgR0FM IG9uIFBXIGFzIFZDQ1YgQ0MgVHlwZSA0LjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2IGRpcj0i bHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIGZhY2U9IkFyaWFs Ij48L2ZvbnQ+PC9zcGFuPsKgPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNw YW4+wqDCoMKgIDxmb250IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSJBcmlhbCI+UmVnYXJkcyw8L2Zv bnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPsKgwqDC oMKgwqDCoMKgIDxmb250IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSJBcmlhbCI+R3JlZzwvZm9udD48 L3NwYW4+PC9kaXY+DQo8YnI+DQo8ZGl2IGRpcj0ibHRyIiBsYW5nPSJlbi11cyIgYWxpZ249Imxl ZnQiPg0KPGhyPg0KPGZvbnQgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB3ZTMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+cHdlMy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+U2hhaHJhbSBEYXZhcmk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFy eSAxNywgMjAxMiA1OjUzIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cHdlM0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnB3ZTNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb248YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+ DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDx1PjwvdT48dT48 L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91Pjx1PjwvdT7CoDwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJGQyA1NTg2IG5vdyBkZWZpbmVzIHVzaW5nIEdBTCBmb3IgUFcuIFRo ZSBxdWVzdGlvbiBJIGhhdmUgaXMgZG9u4oCZdCB3ZSBuZWVkIHRvIGRlZmluZSBhIG5ldyBDQyB0 eXBlIGVuY29kaW5nIChhcyBwZXIgUkZDIDUwODUpIGZvciBzaWduYWxpbmcgdGhpcyBjYXBhYmls aXR5Pzx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91Pjx1Pjwv dT7CoDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT48dT48L3U+wqA8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNoYWhyYW08dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpwd2UzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpwd2UzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHdlM0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8L2E+PGJyPg0KPGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+DQpUaGlz IGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNv bnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJl IHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9m Lg0KPC9wPg0KPC9kaXY+PC9kaXY+PC9kaXY+DQoNCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+DQo= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D59SJEXCHCCR02co_-- From davari@broadcom.com Wed Jan 18 16:17:29 2012 Return-Path: <davari@broadcom.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5FB11E80D7 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 16:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+pY26AyGG2U for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 16:17:28 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD1C11E80D5 for <pwe3@ietf.org>; Wed, 18 Jan 2012 16:17:28 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 18 Jan 2012 16:26:36 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 18 Jan 2012 16:17:22 -0800 From: "Shahram Davari" <davari@broadcom.com> To: "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> Date: Wed, 18 Jan 2012 16:17:18 -0800 Thread-Topic: [PWE3] GAL in PW question Thread-Index: AczVpuq1HIwiZy5FS92XTqpr3c9bKAACf6G/AAE2aBoAAWtewAAhDUhA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F5386@SJEXCHCCR02.corp.ad.broadcom.com> References: <A3C5DF08D38B6049839A6F553B331C760115ED9B68AA@ILPTMAIL02.ecitele.com> <2C2F1EBA8050E74EA81502D5740B4BD6BBBC2E1D57@SJEXCHCCR02.corp.ad.broadcom.com> <A3C5DF08D38B6049839A6F553B331C760115EDE75329@ILPTMAIL02.ecitele.com> In-Reply-To: <A3C5DF08D38B6049839A6F553B331C760115EDE75329@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6309BCB13DS17219168-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F5386SJEXCHCCR02co_ Cc: "'pwe3@ietf.org'" <pwe3@ietf.org> Subject: Re: [PWE3] GAL in PW question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 00:17:29 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F5386SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhbmtzIFNhc2hhLCBzZWVtcyByZWFzb25hYmxlLg0KDQpUaHgNClNEDQoNCkZyb206IEFsZXhh bmRlciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21d DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTgsIDIwMTIgMzoxMiBBTQ0KVG86IFNoYWhyYW0g RGF2YXJpDQpDYzogJ3B3ZTNAaWV0Zi5vcmcnOyAnZ3JlZ2ltaXJza3lAZ21haWwuY29tJw0KU3Vi amVjdDogUkU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCg0KU2hhaHJhbSwNClBsZWFzZSBz ZWUgc29tZSBhbnN3ZXJzIGlubGluZSBiZWxvdy4NCg0KTXkgMmMsDQogICAgIFNhc2hhDQoNCkZy b206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxMiA5OjUwIEFNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRl aW47ICdncmVnaW1pcnNreUBnbWFpbC5jb20nDQpDYzogJ3B3ZTNAaWV0Zi5vcmcnDQpTdWJqZWN0 OiBSZTogW1BXRTNdIEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpIaSBTYXNoYSwNCg0KVHdvIHF1ZXN0 aW9uczoNCg0KMSkgRG9lcyBWQ0MxLCAyLCAzIGFwcGx5IHRvIE1QTFMtVFAgUFc/DQpbW1tTYXNo YV1dXSBJTUhPIGFuZCBGV0lXIFZDQ1YgVHlwZSAxIGRlZmluaXRlbHkgYXBwbGllcyBzaW5jZSBp dCBjYW4gYmUgdXNlZCB3aXRob3V0IElQL1VEUCBlbmNhcHN1bGF0aW9uICh0aGUgdHlwZSBvZiB0 aGUgT0FNIHBhY2tldHMgaXMgZGVmaW5lZCBieSB0aGUgQS1DSCkuDQoNCg0KMikgU2hvdWxkIGFu IE1QTFMtVFAgbm9kZSBiZSBjb25maWd1cmVkIGluIG9yZGVyIHRvIHByb2Nlc3MgcmVjZWl2ZWQg VkNDVjQgcGFja2V0cz8gT3IgaXQgc2hvdWxkIGp1c3QgcHJvY2VzcyBzdWNoIHBhY2tldHMgd2l0 aG91dCBhbnkgY29uZmlndXJhdGlvbi4NCltbW1Nhc2hhXV1dIFNvIGZhciB0aGVyZSBoYXZlIGJl ZW4gbm8gbWFuZGF0b3J5IFZDQ1YgdHlwZSwgYW5kIFZDQ1YgVHlwZSAxIGhhcyBiZWVuIG1hbmRh dGVkIHdoZXJlIENXIGlzIHVzZWQuIFNvIEkgd291bGQgc2F5IHRoYXQsIGZvciB0aGUgcHVycG9z ZSBvZiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCBjb25maWd1cmF0aW9uIGFuZCBjb29yZGluYXRp b24gYXJlIHJlcXVpcmVkIHRvIHVzZSBWQ0NWIFR5cGUgNC4NCg0KDQp0aGFua3MNClNoYWhyYW0N Cg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIgMTE6MTkgUE0N ClRvOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPjsgU2hhaHJhbSBEYXZhcmkN CkNjOiBwd2UzQGlldGYub3JnIDxwd2UzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtQV0UzXSBH QUwgaW4gUFcgcXVlc3Rpb24NCg0KRGVhciBHcmVnLCBTaGFocmFtIGFuZCBhbGwsDQpJIHNlZSBv bmx5IHR3byBhbHRlcm5hdGl2ZXMgaGVyZToNCg0KIDEuICBEZWZpbmUgVkNDViBUeXBlIDQgKEdB TC1iYXNlZCkgZXhwbGljaXRseSBpbiBhIFN0YW5kYXJkIFRyYWNrIGRvY3VtZW50IHRoYXQgdXBk YXRlcyA1MDg1LiBUaGUgZGVmaW5pdGlvbiBtdXN0IGFsc28gYWRkcmVzcyB0aGUgaXNzdWUgb2Yg cHJpb3JpdGllcyBhbW9uZyB0aGUgQ0MgdHlwZXMgd2hlbiB0aGUgcGVlcnMgc3VwcG9ydCBtdWx0 aXBsZSBQVyB0eXBlcywgZXRjLg0KIDIuICBEZWNpZGUgdGhhdCBpbiBzcGl0ZSBvZiA1NTg2IGFs bG93aW5nIHVzYWdlIG9mIEdBTCB3aXRoIFBXcyBpdCB3aWxsIG5vdCBiZSB1c2VkICAtIGZvciBn b29kIG9yIHVudGlsIGZ1cnRoZXIgbm90aWNlICg1NTg2IGRvZXMgbm90IHNwZWNpZnkgYW55IHVz YWdlIG9mIEdBTCB3aXRoIFBXcywgc2ltcGx5IGFsbG93cyBpdCkuDQoNCk15IDJjLA0KDQogICAg IFNhc2hhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBwd2UzLWJv dW5jZXNAaWV0Zi5vcmcgW3B3ZTMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcg TWlyc2t5IFtncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg MTgsIDIwMTIgODowNCBBTQ0KVG86IFNoYWhyYW0gRGF2YXJpDQpDYzogcHdlM0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24NCkhpIFNoYWhyYW0sDQp5b3Un cmUgcmlnaHQsIEkndmUgbm90aWNlZCB0aGF0IGV2ZW4gdGhvdWdoIHRoZSBwcm9wb3NhbCBjbGVh cmx5IGRlZmluZXMgbmV3IGJlaGF2aW9yIGl0LCBzdHJhbmdlbHksIGlzIG9uIEluZm9ybWF0aW9u YWwgdHJhY2suIEJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBub3QgYSBiaWcgcHJvYmxlbSBhbmQg aXQgY2FuIGJlIGVhc2lseSBwdXQgb24gc3RhbmRhcmQncyB0cmFjayBuZXh0IHRpbWUgYXV0aG9y cyBzdWJtaXQgbmV3IHJldmlzaW9uLiBJIHRoaW5rIHdlJ2xsIGxlYXJuIG9mIHRoZWlyIHBsYW5z IHNvb24uDQoNClJlZ2FyZHMsDQpHcmVnDQpPbiBUdWUsIEphbiAxNywgMjAxMiBhdCA5OjI1IFBN LCBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2Fk Y29tLmNvbT4+IHdyb3RlOg0KR3JlYXQsIGJ1dCBmaXJzdCBvZiBpdCBpcyBleHBpcmVkIGFuZCBz ZWNvbmRseSBpdCBpcyBpbmZvcm1hdGlvbmFsLiBJIHRoaW5rIHdlIG5lZWQgdG8gYnJpbmcgaXQg YmFjayB0byBzdGFuZGFyZHMgdHJhY2suDQoNClRoeA0KU2hhaHJhbQ0KDQpGcm9tOiBHcmVnb3J5 IE1pcnNreSBbbWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPl0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIg MDY6MDYgUE0NClRvOiBTaGFocmFtIERhdmFyaTsgcHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0Bp ZXRmLm9yZz4gPHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UkU6IEdBTCBpbiBQVyBxdWVzdGlvbg0KDQpIaSBTaGFocmFtLA0KSSB0aGluayB0aGF0IGRyYWZ0 LW5hZGVhdS1wd2UzLXZjY3YtMi0wMiBkZWZpbmVzIHVzZSBvZiBHQUwgb24gUFcgYXMgVkNDViBD QyBUeXBlIDQuDQoNCiAgICBSZWdhcmRzLA0KICAgICAgICBHcmVnDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnB3 ZTMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnB3ZTMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBTaGFocmFtIERhdmFyaQ0KU2Vu dDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiA1OjUzIFBNDQpUbzogcHdlM0BpZXRmLm9yZzxt YWlsdG86cHdlM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24N CkhpLA0KDQpSRkMgNTU4NiBub3cgZGVmaW5lcyB1c2luZyBHQUwgZm9yIFBXLiBUaGUgcXVlc3Rp b24gSSBoYXZlIGlzIGRvbuKAmXQgd2UgbmVlZCB0byBkZWZpbmUgYSBuZXcgQ0MgdHlwZSBlbmNv ZGluZyAoYXMgcGVyIFJGQyA1MDg1KSBmb3Igc2lnbmFsaW5nIHRoaXMgY2FwYWJpbGl0eT8NCg0K DQpUaGFua3MNClNoYWhyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnPG1haWx0bzpwd2Uz QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoN Cg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5 IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNo IG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBw aG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMg dGhlcmVvZi4NCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lw aWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwg YW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkg ZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFs bCBjb3BpZXMgdGhlcmVvZi4NCg== --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F5386SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTE2MTE1NTA2Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNzIxNjQ3ODUwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 NjQ1NDAyNzY4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4NTM4NDQ5MzY7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIFNhc2hh LCBzZWVtcyByZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGh4PGJyPlNEPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gQWxl eGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bV0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMTgsIDIwMTIgMzoxMiBBTTxi cj48Yj5Ubzo8L2I+IFNoYWhyYW0gRGF2YXJpPGJyPjxiPkNjOjwvYj4gJ3B3ZTNAaWV0Zi5vcmcn OyAnZ3JlZ2ltaXJza3lAZ21haWwuY29tJzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtQV0UzXSBH QUwgaW4gUFcgcXVlc3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlNoYWhyYW0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBsZWFzZSBzZWUgc29tZSBhbnN3ZXJz IGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkgMmMsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gU2hhaHJhbSBEYXZhcmkgW21haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tXSA8YnI+PGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxMiA5OjUwIEFNPGJyPjxiPlRvOjwvYj4g QWxleGFuZGVyIFZhaW5zaHRlaW47ICdncmVnaW1pcnNreUBnbWFpbC5jb20nPGJyPjxiPkNjOjwv Yj4gJ3B3ZTNAaWV0Zi5vcmcnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW1BXRTNdIEdBTCBpbiBQ VyBxdWVzdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SGkgU2FzaGEsPGJyPjxicj5Ud28gcXVlc3Rpb25zOjxicj48YnI+MSkgRG9l cyBWQ0MxLCAyLCAzIGFwcGx5IHRvIE1QTFMtVFAgUFc/PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltbW1Nhc2hhXV1d IDwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SU1ITyBhbmQgRldJVyBWQ0NW IFR5cGUgMSBkZWZpbml0ZWx5IGFwcGxpZXMgc2luY2UgaXQgY2FuIGJlIHVzZWQgd2l0aG91dCBJ UC9VRFAgZW5jYXBzdWxhdGlvbiAodGhlIHR5cGUgb2YgdGhlIE9BTSBwYWNrZXRzIGlzIGRlZmlu ZWQgYnkgdGhlIEEtQ0gpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PGJyPjxicj4yKSBTaG91bGQgYW4gTVBMUy1UUCBub2Rl IGJlIGNvbmZpZ3VyZWQgaW4gb3JkZXIgdG8gcHJvY2VzcyByZWNlaXZlZCBWQ0NWNCBwYWNrZXRz PyBPciBpdCBzaG91bGQganVzdCBwcm9jZXNzIHN1Y2ggcGFja2V0cyB3aXRob3V0IGFueSBjb25m aWd1cmF0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxp PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+W1tbU2FzaGFdXV0gPC9zcGFuPjwvaT48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5TbyBmYXIgdGhlcmUgaGF2ZSBiZWVuIG5vIG1hbmRhdG9yeSBWQ0NW IHR5cGUsIGFuZCBWQ0NWIFR5cGUgMSBoYXMgYmVlbiBtYW5kYXRlZCB3aGVyZSBDVyBpcyB1c2Vk LiBTbyBJIHdvdWxkIHNheSB0aGF0LCBmb3IgdGhlIHB1cnBvc2Ugb2YgYmFja3dhcmQgY29tcGF0 aWJpbGl0eSwgY29uZmlndXJhdGlvbiBhbmQgY29vcmRpbmF0aW9uIGFyZSByZXF1aXJlZCB0byB1 c2UgVkNDViBUeXBlIDQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxicj48YnI+dGhhbmtzPGJyPlNoYWhyYW08L3NwYW4+PGJy PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjogQWxleGFuZGVyIFZh aW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0gPGJyPjxi PlNlbnQ8L2I+OiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDEyIDExOjE5IFBNPGJyPjxiPlRvPC9i PjogR3JlZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs7IFNoYWhyYW0gRGF2 YXJpIDxicj48Yj5DYzwvYj46IHB3ZTNAaWV0Zi5vcmcgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7IDxi cj48Yj5TdWJqZWN0PC9iPjogUkU6IFtQV0UzXSBHQUwgaW4gUFcgcXVlc3Rpb24gPGJyPjwvc3Bh bj4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RGVhciBHcmVnLCZuYnNwO1NoYWhyYW0gYW5kIGFs bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JIHNlZSBvbmx5IHR3byBhbHRlcm5hdGl2ZXMgaGVyZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PG9sIHN0YXJ0PTEgdHlwZT0xPjxsaSBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zJz5EZWZpbmUgVkND ViBUeXBlIDQgKEdBTC1iYXNlZCkgZXhwbGljaXRseSBpbiBhIFN0YW5kYXJkIFRyYWNrIGRvY3Vt ZW50IHRoYXQgdXBkYXRlcyA1MDg1LiBUaGUgZGVmaW5pdGlvbiBtdXN0IGFsc28gYWRkcmVzcyB0 aGUgaXNzdWUgb2YgcHJpb3JpdGllcyBhbW9uZyB0aGUgQ0MgdHlwZXMgd2hlbiB0aGUgcGVlcnMg c3VwcG9ydCBtdWx0aXBsZSBQVyB0eXBlcywgZXRjLiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMnPkRlY2lkZSB0 aGF0IGluIHNwaXRlIG9mIDU1ODYgYWxsb3dpbmcgdXNhZ2Ugb2YgR0FMIHdpdGggUFdzIGl0IHdp bGwgbm90IGJlIHVzZWQmbmJzcDsgLSBmb3IgZ29vZCBvciB1bnRpbCBmdXJ0aGVyIG5vdGljZSAo NTU4NiBkb2VzIG5vdCBzcGVjaWZ5IGFueSB1c2FnZSBvZiBHQUwgd2l0aCBQV3MsIHNpbXBseSBh bGxvd3MgaXQpLjxvOnA+PC9vOnA+PC9saT48L29sPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+TXkgMmMsPG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgaWQ9ZGl2UnBGNjQ5MDI+PGRpdiBjbGFzcz1N c29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9z cGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbcHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR3JlZyBNaXJza3kgW2dyZWdpbWlyc2t5QGdtYWlsLmNvbV08YnI+PGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgSmFudWFyeSAxOCwgMjAxMiA4OjA0IEFNPGJyPjxiPlRvOjwvYj4gU2hhaHJh bSBEYXZhcmk8YnI+PGI+Q2M6PC9iPiBwd2UzQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBS ZTogW1BXRTNdIEdBTCBpbiBQVyBxdWVzdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+SGkg U2hhaHJhbSw8YnI+eW91J3JlIHJpZ2h0LCBJJ3ZlIG5vdGljZWQgdGhhdCBldmVuIHRob3VnaCB0 aGUgcHJvcG9zYWwgY2xlYXJseSBkZWZpbmVzIG5ldyBiZWhhdmlvciBpdCwgc3RyYW5nZWx5LCBp cyBvbiBJbmZvcm1hdGlvbmFsIHRyYWNrLiBCdXQgSSB0aGluayB0aGF0IHRoaXMgaXMgbm90IGEg YmlnIHByb2JsZW0gYW5kIGl0IGNhbiBiZSBlYXNpbHkgcHV0IG9uIHN0YW5kYXJkJ3MgdHJhY2sg bmV4dCB0aW1lIGF1dGhvcnMgc3VibWl0IG5ldyByZXZpc2lvbi4gSSB0aGluayB3ZSdsbCBsZWFy biBvZiB0aGVpciBwbGFucyBzb29uLjxicj48YnI+UmVnYXJkcyw8YnI+R3JlZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPk9uIFR1ZSwgSmFuIDE3LCAyMDEyIGF0IDk6MjUgUE0sIFNoYWhyYW0gRGF2YXJpICZsdDs8 YSBocmVmPSJtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbSI+ZGF2YXJpQGJyb2FkY29tLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkdyZWF0LCBidXQgZmlyc3Qgb2YgaXQgaXMgZXhwaXJl ZCBhbmQgc2Vjb25kbHkgaXQgaXMgaW5mb3JtYXRpb25hbC4gSSB0aGluayB3ZSBuZWVkIHRvIGJy aW5nIGl0IGJhY2sgdG8gc3RhbmRhcmRzIHRyYWNrLjxicj48YnI+VGh4PGJyPlNoYWhyYW08L3Nw YW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz5Gcm9tPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjogR3JlZ29y eSBNaXJza3kgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+XSA8YnI+PGI+U2VudDwvYj46IFR1 ZXNkYXksIEphbnVhcnkgMTcsIDIwMTIgMDY6MDYgUE08YnI+PGI+VG88L2I+OiBTaGFocmFtIERh dmFyaTsgPGEgaHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0Zi5vcmc8L2E+ICZs dDs8YSBocmVmPSJtYWlsdG86cHdlM0BpZXRmLm9yZyI+cHdlM0BpZXRmLm9yZzwvYT4mZ3Q7IDxi cj48Yj5TdWJqZWN0PC9iPjogUkU6IEdBTCBpbiBQVyBxdWVzdGlvbiA8YnI+PC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkhpIFNoYWhyYW0sPC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+ SSB0aGluayB0aGF0IGRyYWZ0LW5hZGVhdS1wd2UzLXZjY3YtMi0wMiBkZWZpbmVzIHVzZSBvZiBH QUwgb24gUFcgYXMgVkNDViBDQyBUeXBlIDQuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5S ZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5HcmVnPC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246 Y2VudGVyJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxociBzaXplPTIgd2lkdGg9IjEwMCUi IGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tYm90dG9tOjEyLjBwdCc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiA8YSBocmVmPSJtYWls dG86cHdlMy1ib3VuY2VzQGlldGYub3JnIj5wd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnB3ZTMtYm91bmNlc0BpZXRmLm9yZyI+cHdlMy1ib3VuY2VzQGll dGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5TaGFocmFtIERhdmFyaTxicj48Yj5TZW50 OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNywgMjAxMiA1OjUzIFBNPGJyPjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnB3ZTNAaWV0Zi5vcmciPnB3ZTNAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1Ympl Y3Q6PC9iPiBbUFdFM10gR0FMIGluIFBXIHF1ZXN0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5SRkMgNTU4NiBub3cgZGVmaW5lcyB1c2luZyBHQUwgZm9yIFBXLiBUaGUgcXVlc3Rpb24gSSBo YXZlIGlzIGRvbuKAmXQgd2UgbmVlZCB0byBkZWZpbmUgYSBuZXcgQ0MgdHlwZSBlbmNvZGluZyAo YXMgcGVyIFJGQyA1MDg1KSBmb3Igc2lnbmFsaW5nIHRoaXMgY2FwYWJpbGl0eT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGFua3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5T aGFocmFtPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPnB3ZTMgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpwd2UzQGlldGYu b3JnIj5wd2UzQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3B3ZTMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cD5UaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVu ZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNo IGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxl Y29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48 cD5UaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkg YW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2gg bWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBo b25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0 aGVyZW9mLiA8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBBD1F5386SJEXCHCCR02co_-- From zheng.zhi@zte.com.cn Wed Jan 18 16:48:09 2012 Return-Path: <zheng.zhi@zte.com.cn> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B760C21F85B4 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 16:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.035 X-Spam-Level: X-Spam-Status: No, score=-101.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5xEvVGaIiM5 for <pwe3@ietfa.amsl.com>; Wed, 18 Jan 2012 16:48:09 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D1EF821F85AA for <pwe3@ietf.org>; Wed, 18 Jan 2012 16:48:08 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901397396305; Thu, 19 Jan 2012 08:24:07 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.1397396305; Thu, 19 Jan 2012 08:48:05 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id q0J0m4V2001255 for <pwe3@ietf.org>; Thu, 19 Jan 2012 08:48:04 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) Message-Id: <201201190048.q0J0m4V2001255@mse02.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0I33TUj015270; Wed, 18 Jan 2012 11:03:29 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) In-Reply-To: <CB39E3D8.21927%ssalam@cisco.com> To: Samer Salam <ssalam@cisco.com> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: Ryan Zheng<zheng.zhi@zte.com.cn> Date: Wed, 18 Jan 2012 11:03:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-18 11:03:30, Serialize complete at 2012-01-18 11:03:30 Content-Type: multipart/alternative; boundary="=_alternative 0010F27B48257989_=" X-MAIL: mse02.zte.com.cn q0J0m4V2001255 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: Luca Martini <lmartini@cisco.com>, pwe3@ietf.org Subject: Re: [PWE3] Question on draft-ietf-pwe3-iccp-06 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 19 Jan 2012 00:48:09 -0000 This is a multipart message in MIME format. --=_alternative 0010F27B48257989_= Content-Type: text/plain; charset="US-ASCII" Hi Samer, Thank you for the prompt response. Now it is much clear for me on this point. IMHO, for the setup of dedicated LDP session (per section 4.6), the current LDP mechanism is adequate, and non IANA request is needed. Regards, Ryan Samer Salam <ssalam@cisco.com> wrote on 2012-01-17 06:25:28: > Hi Ryan, > > At some point of time, we were envisioning that this TLV would play > a role in the setup of dedicated LDP sessions for ICCP transport > (per section 4.6). However, that was not pursued, so we should > remove the reference to this TLV. > > Regards, > Samer > > > On 12-01-13 12:49 AM, "Ryan Zheng" <zheng.zhi@zte.com.cn> wrote: > > Hi Luca and other authors, > > One question on this draft: > > In Section 11.2, a new LDP TLV is suggested: > Type Description > 0x701 LDP TCP/IP Port TLV > > But I did not find any other description about this new TLV in the draft. > > Could you make some clarifications about this TLV? Like format, > usage...That will be appreciated. > > Thanks a lot! > > Ryan --=_alternative 0010F27B48257989_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Samer,</font> <br> <br><font size=2 face="sans-serif">Thank you for the prompt response. Now it is much clear for me on this point.</font> <br> <br><font size=2 face="sans-serif">IMHO, for the setup of dedicated LDP session (per section 4.6), the current LDP mechanism is adequate, and non IANA request is needed.</font> <br> <br><font size=2 face="sans-serif">Regards,</font> <br><font size=2 face="sans-serif">Ryan</font> <br><font size=1 face="Arial"> </font> <br> <br><font size=2><tt>Samer Salam <ssalam@cisco.com> wrote on 2012-01-17 06:25:28:<br> <br> > Hi Ryan,<br> > <br> > At some point of time, we were envisioning that this TLV would play <br> > a role in the setup of dedicated LDP sessions for ICCP transport <br> > (per section 4.6). However, that was not pursued, so we should <br> > remove the reference to this TLV.<br> > <br> > Regards,<br> > Samer<br> > <br> > <br> > On 12-01-13 12:49 AM, "Ryan Zheng" <zheng.zhi@zte.com.cn> wrote:<br> </tt></font> <br><font size=2><tt>> <br> > Hi Luca and other authors, <br> > <br> > One question on this draft: <br> > <br> > In Section 11.2, a new LDP TLV is suggested: <br> > Type  Description <br> > 0x701 LDP TCP/IP Port TLV <br> > <br> > But I did not find any other description about this new TLV in the draft. <br> > <br> > Could you make some clarifications about this TLV? Like format, <br> > usage...That will be appreciated. <br> > <br> > Thanks a lot! <br> > <br> > Ryan</tt></font> --=_alternative 0010F27B48257989_=-- From adrian@olddog.co.uk Sat Jan 21 09:11:04 2012 Return-Path: <adrian@olddog.co.uk> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569CA21F8501 for <pwe3@ietfa.amsl.com>; Sat, 21 Jan 2012 09:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS70SXKQMSyg for <pwe3@ietfa.amsl.com>; Sat, 21 Jan 2012 09:10:55 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA3C21F84FF for <pwe3@ietf.org>; Sat, 21 Jan 2012 09:10:30 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0LHALCW016419; Sat, 21 Jan 2012 17:10:23 GMT Received: from 950129200 (customer14808.96.ld.cust.t-mobile.co.uk [178.96.57.215] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0LHAID1016358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Jan 2012 17:10:19 GMT From: "Adrian Farrel" <adrian@olddog.co.uk> To: <draft-ietf-pwe3-packet-pw.all@tools.ietf.org> Date: Sat, 21 Jan 2012 17:10:19 -0000 Message-ID: <000e01ccd85f$8f00aa60$ad01ff20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczYX4SRBvp/l0q7QKm5mTqg+A2g+g== Content-Language: en-gb Cc: pwe3@ietf.org Subject: [PWE3] AD review of draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 21 Jan 2012 17:11:04 -0000 Hi, In addition to a question about the shepherd write-up which I sent to Matthew separately, I have a collection of small questions and nits for the authors. I think the nits are many enough to warrant a revision, and the questions might require a revision depending on the answers. Thanks, Adrian --- I started reading this in the belief that this is truly a BCP and I wrote the following: I think it would be helpful if both the Abstract and the Introduction (to a lesser and greater extent, respectively) noted that: - this document does not define any new procedures or protocol elements - this document indicates how a specific function is provided using existing tools and mechanisms - this document advises the Internet community on the best current practice for providing a packet service over an MPLS network However, when it comes to it, you are making to code point requests to IANA. This isn't a BCP is it? Shouldn't it be Standards Track? --- LSR needs to be expanded in the Abstract and para 3 of the Introduction. --- Section 1 s/via physical interface/via a physical interface/ --- Throughout the doc s/point to point/point-to-point/ s/point to multipoint/point-to-multipoint/ s/multipoint to multipoint/multipoint-to-multipoint/ --- Section 2 s/network is shown/network as shown/ --- Figure 1 is missing a title --- Section 2 It is not necessary to expand PSN, but if you want to, you should do it on first use (in section 1) --- Section 3 s/layer two/layer 2/ for consistency with the rest of the doc -- Section 7 congestion considerations being developed for PWs apply [RFC3985], [RFC5659]. I think you can delete "being" --- Section 9 I found what you have written a little open to (wilful) misinterpretation. Which code point has which name? Couldn't you have written: Dotted Decimal Description Reference ----------------------- -------------------------------- --------- 000.00x.000 PacketPWEthA [This RFC] 000.00x.001 PacketPWEthB [This RFC] Do you want to make it clear that x is open for IANA to choose? --- Appendix A I can see some good reasons to preserve the history of discussion, although this is not normally done with IETF documents that are concerned with setting out a specification on which consensus has been reached. If you want to carry on including the Appendix, you need to do several things: 1. Refer to it in the body of the text. I think this is most easily done from the Introduction. 2. State in the Appendix why it is included. You do a good job of saying what is in the Appendix, but not why the Appendix is there and what the reader is supposed to gain from it. 3. Make it clear (in the Appendix) that it is non-normative. From amalis@gmail.com Sat Jan 21 09:39:28 2012 Return-Path: <amalis@gmail.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F295921F84F7 for <pwe3@ietfa.amsl.com>; Sat, 21 Jan 2012 09:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyVzQR+i7WHp for <pwe3@ietfa.amsl.com>; Sat, 21 Jan 2012 09:39:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A20BB21F84F2 for <pwe3@ietf.org>; Sat, 21 Jan 2012 09:39:26 -0800 (PST) Received: by iagf6 with SMTP id f6so1122317iag.31 for <pwe3@ietf.org>; Sat, 21 Jan 2012 09:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5MA0hgJC0NLNXHhnOHEyGC+U1qxTqFOAj9yr9CcAj9I=; b=E+xGWaqPJqxEBH1lhk/vjZ0W8Rbfv6v6mL2PpXdn0LthI61cLQRxRXgpAZsorkdQwx ahty5jbP5JuwLLMkMkVxZlVkqjyT2bKpE7B78Dbzn6h5BAW9t/8cnoOMKylpA9iATHOJ 3AUD/tJHpPy5+zQCVb4vL1PLIHPwCqPAgtPlI= Received: by 10.42.146.202 with SMTP id k10mr2432447icv.13.1327167565269; Sat, 21 Jan 2012 09:39:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.168.69 with HTTP; Sat, 21 Jan 2012 09:39:04 -0800 (PST) In-Reply-To: <000e01ccd85f$8f00aa60$ad01ff20$@olddog.co.uk> References: <000e01ccd85f$8f00aa60$ad01ff20$@olddog.co.uk> From: "Andrew G. Malis" <amalis@gmail.com> Date: Sat, 21 Jan 2012 12:39:04 -0500 Message-ID: <CAK+d4xv_ncWXQWZjFkLead9r7KTYxkOz84aNf4ByR3fQYq6u-w@mail.gmail.com> To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=90e6ba6e8e9c490cab04b70d47b0 Cc: draft-ietf-pwe3-packet-pw.all@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 21 Jan 2012 17:39:28 -0000 --90e6ba6e8e9c490cab04b70d47b0 Content-Type: text/plain; charset=ISO-8859-1 Adrian, (speaking a co-author) Thanks for your review and comments. The code points were a relatively recent addition that came out of a discussion of what to put into the MAC address fields. But you're right, the IANA allocation probably does take it away from being a BCP. So I guess we're on the standards track now and will make the appropriate changes to the draft. The other comments look fine, including the IANA code points. We could suggest 3 and 4 as the two "X" values to make IANA's life easier. Appendix A was very useful during the development of the draft because it kept us from endlessly iterating on design choices, but I personally wouldn't have a problem with removing it at this point. Cheers, Andy On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <adrian@olddog.co.uk> wrote: > Hi, > > In addition to a question about the shepherd write-up which I sent to > Matthew > separately, I have a collection of small questions and nits for the > authors. I > think the nits are many enough to warrant a revision, and the questions > might > require a revision depending on the answers. > > Thanks, > Adrian > > --- > > I started reading this in the belief that this is truly a BCP and I > wrote the following: > > I think it would be helpful if both the Abstract and the Introduction > (to a lesser and greater extent, respectively) noted that: > - this document does not define any new procedures or protocol elements > - this document indicates how a specific function is provided using > existing tools and mechanisms > - this document advises the Internet community on the best current > practice for providing a packet service over an MPLS network > > However, when it comes to it, you are making to code point requests to > IANA. This isn't a BCP is it? Shouldn't it be Standards Track? > > --- > > LSR needs to be expanded in the Abstract and para 3 of the Introduction. > > --- > > Section 1 > > s/via physical interface/via a physical interface/ > > --- > > Throughout the doc > > s/point to point/point-to-point/ > s/point to multipoint/point-to-multipoint/ > s/multipoint to multipoint/multipoint-to-multipoint/ > > --- > > Section 2 > > s/network is shown/network as shown/ > > --- > > Figure 1 is missing a title > > --- > > Section 2 > It is not necessary to expand PSN, but if you want to, you should do it > on first use (in section 1) > > --- > > Section 3 > > s/layer two/layer 2/ for consistency with the rest of the doc > > -- > > Section 7 > > congestion considerations being developed for PWs apply [RFC3985], > [RFC5659]. > > I think you can delete "being" > > --- > > Section 9 > > I found what you have written a little open to (wilful) > misinterpretation. Which code point has which name? Couldn't you have > written: > > > Dotted Decimal Description Reference > ----------------------- -------------------------------- --------- > > 000.00x.000 PacketPWEthA [This RFC] > 000.00x.001 PacketPWEthB [This RFC] > > > Do you want to make it clear that x is open for IANA to choose? > > --- > > Appendix A > > I can see some good reasons to preserve the history of discussion, > although this is not normally done with IETF documents that are > concerned with setting out a specification on which consensus has been > reached. If you want to carry on including the Appendix, you need to do > several things: > > 1. Refer to it in the body of the text. I think this is most easily done > from the Introduction. > > 2. State in the Appendix why it is included. You do a good job of saying > what is in the Appendix, but not why the Appendix is there and what > the reader is supposed to gain from it. > > 3. Make it clear (in the Appendix) that it is non-normative. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --90e6ba6e8e9c490cab04b70d47b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adrian,<br><br>(speaking a co-author)<br><br>Thanks for your review and com= ments.<br><br>The code points were a relatively recent addition that came o= ut of a discussion of what to put into the MAC address fields. But you'= re right, the IANA allocation probably does take it away from being a BCP.<= br> <br>So I guess we're on the standards track now and will make the appro= priate changes to the draft.<br><br>The other comments look fine, including= the IANA code points. We could suggest 3 and 4 as the two "X" va= lues to make IANA's life easier.<br> <br>Appendix A was very useful during the development of the draft because = it kept us from endlessly iterating on design choices, but I personally wou= ldn't have a problem with removing it at this point.<br><br>Cheers,<br> Andy<br><br><div class=3D"gmail_quote">On Sat, Jan 21, 2012 at 12:10 PM, Ad= rian Farrel <span dir=3D"ltr"><<a href=3D"mailto:adrian@olddog.co.uk">ad= rian@olddog.co.uk</a>></span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br> <br> In addition to a question about the shepherd write-up which I sent to Matth= ew<br> separately, I have a collection of small questions and nits for the authors= . I<br> think the nits are many enough to warrant a revision, and the questions mig= ht<br> require a revision depending on the answers.<br> <br> Thanks,<br> Adrian<br> <br> ---<br> <br> I started reading this in the belief that this is truly a BCP and I<br> wrote the following:<br> <br> I think it would be helpful if both the Abstract and the Introduction<br> (to a lesser and greater extent, respectively) noted that:<br> - this document does not define any new procedures or protocol elements<br> - this document indicates how a specific function is provided using<br> =A0existing tools and mechanisms<br> - this document advises the Internet community on the best current<br> =A0practice for providing a packet service over an MPLS network<br> <br> However, when it comes to it, you are making to code point requests to<br> IANA. This isn't a BCP is it? Shouldn't it be Standards Track?<br> <br> ---<br> <br> LSR needs to be expanded in the Abstract and para 3 of the Introduction.<br= > <br> ---<br> <br> Section 1<br> <br> s/via physical interface/via a physical interface/<br> <br> ---<br> <br> Throughout the doc<br> <br> s/point to point/point-to-point/<br> s/point to multipoint/point-to-multipoint/<br> s/multipoint to multipoint/multipoint-to-multipoint/<br> <br> ---<br> <br> Section 2<br> <br> s/network is shown/network as shown/<br> <br> ---<br> <br> Figure 1 is missing a title<br> <br> ---<br> <br> Section 2<br> It is not necessary to expand PSN, but if you want to, you should do it<br> on first use (in section 1)<br> <br> ---<br> <br> Section 3<br> <br> s/layer two/layer 2/ =A0 for consistency with the rest of the doc<br> <br> --<br> <br> Section 7<br> <br> =A0 congestion considerations being developed for PWs apply [RFC3985],<br> =A0 [RFC5659].<br> <br> I think you can delete "being"<br> <br> ---<br> <br> Section 9<br> <br> I found what you have written a little open to (wilful)<br> misinterpretation. Which code point has which name? Couldn't you have<b= r> written:<br> <br> <br> =A0 Dotted Decimal =A0 =A0 =A0 =A0 =A0 Description =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Reference<br> =A0 ----------------------- =A0-------------------------------- =A0-------= --<br> <br> =A0 000.00x.000 =A0 =A0 =A0 =A0 =A0 =A0 =A0PacketPWEthA =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[This RFC]<br> =A0 000.00x.001 =A0 =A0 =A0 =A0 =A0 =A0 =A0PacketPWEthB =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[This RFC]<br> <br> <br> Do you want to make it clear that x is open for IANA to choose?<br> <br> ---<br> <br> Appendix A<br> <br> I can see some good reasons to preserve the history of discussion,<br> although this is not normally done with IETF documents that are<br> concerned with setting out a specification on which consensus has been<br> reached. If you want to carry on including the Appendix, you need to do<br> several things:<br> <br> 1. Refer to it in the body of the text. I think this is most easily done<br= > =A0 from the Introduction.<br> <br> 2. State in the Appendix why it is included. You do a good job of saying<br= > =A0 what is in the Appendix, but not why the Appendix is there and what<br= > =A0 the reader is supposed to gain from it.<br> <br> 3. Make it clear (in the Appendix) that it is non-normative.<br> <br> _______________________________________________<br> pwe3 mailing list<br> <a href=3D"mailto:pwe3@ietf.org">pwe3@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/pwe3</a><br> </blockquote></div><br> --90e6ba6e8e9c490cab04b70d47b0-- From amalis@gmail.com Sun Jan 22 05:44:32 2012 Return-Path: <amalis@gmail.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F07E21F8516 for <pwe3@ietfa.amsl.com>; Sun, 22 Jan 2012 05:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrY669DHzVdb for <pwe3@ietfa.amsl.com>; Sun, 22 Jan 2012 05:44:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4EC21F8514 for <pwe3@ietf.org>; Sun, 22 Jan 2012 05:44:31 -0800 (PST) Received: by iagf6 with SMTP id f6so2216430iag.31 for <pwe3@ietf.org>; Sun, 22 Jan 2012 05:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SKZ6MwddjEGnBrQv61vx7LnZev1jPG7YN1nIOQYpoa4=; b=J2gJA+SZIOoUZIlLVCW2C6F1KKPxrTlieiCdAiMtCGzqmz45UIP/R/QIf0YA/gaYOZ g46SQDTc4xQZ7LQ25E1trU76GY0bjuO7gw41iFjkdPFWeFcFW2ZVRFHwnSV2bTXChG8E WW7v42oOp987LWcGV5LTcqt6ZSrEiE70FglgA= Received: by 10.42.146.202 with SMTP id k10mr4760311icv.13.1327239871285; Sun, 22 Jan 2012 05:44:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.168.69 with HTTP; Sun, 22 Jan 2012 05:44:10 -0800 (PST) In-Reply-To: <CAK+d4xv_ncWXQWZjFkLead9r7KTYxkOz84aNf4ByR3fQYq6u-w@mail.gmail.com> References: <000e01ccd85f$8f00aa60$ad01ff20$@olddog.co.uk> <CAK+d4xv_ncWXQWZjFkLead9r7KTYxkOz84aNf4ByR3fQYq6u-w@mail.gmail.com> From: "Andrew G. Malis" <amalis@gmail.com> Date: Sun, 22 Jan 2012 08:44:10 -0500 Message-ID: <CAK+d4xudaFz=s02B0jxX4-C2xBciAv3yvSGqg-hbjBvmwz2Z0A@mail.gmail.com> To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=90e6ba6e8e9c0f486c04b71e1d3a Cc: draft-ietf-pwe3-packet-pw.all@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 22 Jan 2012 13:44:32 -0000 --90e6ba6e8e9c0f486c04b71e1d3a Content-Type: text/plain; charset=ISO-8859-1 Adrian, I meant suggesting just 3 as X. Cheers, Andy On Sat, Jan 21, 2012 at 12:39 PM, Andrew G. Malis <amalis@gmail.com> wrote: > Adrian, > > (speaking a co-author) > > Thanks for your review and comments. > > The code points were a relatively recent addition that came out of a > discussion of what to put into the MAC address fields. But you're right, > the IANA allocation probably does take it away from being a BCP. > > So I guess we're on the standards track now and will make the appropriate > changes to the draft. > > The other comments look fine, including the IANA code points. We could > suggest 3 and 4 as the two "X" values to make IANA's life easier. > > Appendix A was very useful during the development of the draft because it > kept us from endlessly iterating on design choices, but I personally > wouldn't have a problem with removing it at this point. > > Cheers, > Andy > > > On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <adrian@olddog.co.uk>wrote: > >> Hi, >> >> In addition to a question about the shepherd write-up which I sent to >> Matthew >> separately, I have a collection of small questions and nits for the >> authors. I >> think the nits are many enough to warrant a revision, and the questions >> might >> require a revision depending on the answers. >> >> Thanks, >> Adrian >> >> --- >> >> I started reading this in the belief that this is truly a BCP and I >> wrote the following: >> >> I think it would be helpful if both the Abstract and the Introduction >> (to a lesser and greater extent, respectively) noted that: >> - this document does not define any new procedures or protocol elements >> - this document indicates how a specific function is provided using >> existing tools and mechanisms >> - this document advises the Internet community on the best current >> practice for providing a packet service over an MPLS network >> >> However, when it comes to it, you are making to code point requests to >> IANA. This isn't a BCP is it? Shouldn't it be Standards Track? >> >> --- >> >> LSR needs to be expanded in the Abstract and para 3 of the Introduction. >> >> --- >> >> Section 1 >> >> s/via physical interface/via a physical interface/ >> >> --- >> >> Throughout the doc >> >> s/point to point/point-to-point/ >> s/point to multipoint/point-to-multipoint/ >> s/multipoint to multipoint/multipoint-to-multipoint/ >> >> --- >> >> Section 2 >> >> s/network is shown/network as shown/ >> >> --- >> >> Figure 1 is missing a title >> >> --- >> >> Section 2 >> It is not necessary to expand PSN, but if you want to, you should do it >> on first use (in section 1) >> >> --- >> >> Section 3 >> >> s/layer two/layer 2/ for consistency with the rest of the doc >> >> -- >> >> Section 7 >> >> congestion considerations being developed for PWs apply [RFC3985], >> [RFC5659]. >> >> I think you can delete "being" >> >> --- >> >> Section 9 >> >> I found what you have written a little open to (wilful) >> misinterpretation. Which code point has which name? Couldn't you have >> written: >> >> >> Dotted Decimal Description Reference >> ----------------------- -------------------------------- --------- >> >> 000.00x.000 PacketPWEthA [This RFC] >> 000.00x.001 PacketPWEthB [This RFC] >> >> >> Do you want to make it clear that x is open for IANA to choose? >> >> --- >> >> Appendix A >> >> I can see some good reasons to preserve the history of discussion, >> although this is not normally done with IETF documents that are >> concerned with setting out a specification on which consensus has been >> reached. If you want to carry on including the Appendix, you need to do >> several things: >> >> 1. Refer to it in the body of the text. I think this is most easily done >> from the Introduction. >> >> 2. State in the Appendix why it is included. You do a good job of saying >> what is in the Appendix, but not why the Appendix is there and what >> the reader is supposed to gain from it. >> >> 3. Make it clear (in the Appendix) that it is non-normative. >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > --90e6ba6e8e9c0f486c04b71e1d3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adrian,<br><br>I meant suggesting just 3 as X.<br><br>Cheers,<br>Andy<br><b= r><div class=3D"gmail_quote">On Sat, Jan 21, 2012 at 12:39 PM, Andrew G. Ma= lis <span dir=3D"ltr"><<a href=3D"mailto:amalis@gmail.com">amalis@gmail.= com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Adrian,<br><br>(speaking a co-author)<br><br= >Thanks for your review and comments.<br><br>The code points were a relativ= ely recent addition that came out of a discussion of what to put into the M= AC address fields. But you're right, the IANA allocation probably does = take it away from being a BCP.<br> <br>So I guess we're on the standards track now and will make the appro= priate changes to the draft.<br><br>The other comments look fine, including= the IANA code points. We could suggest 3 and 4 as the two "X" va= lues to make IANA's life easier.<br> <br>Appendix A was very useful during the development of the draft because = it kept us from endlessly iterating on design choices, but I personally wou= ldn't have a problem with removing it at this point.<br><br>Cheers,<br> Andy<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gmail_quo= te">On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <span dir=3D"ltr"><<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= </a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hi,<br> <br> In addition to a question about the shepherd write-up which I sent to Matth= ew<br> separately, I have a collection of small questions and nits for the authors= . I<br> think the nits are many enough to warrant a revision, and the questions mig= ht<br> require a revision depending on the answers.<br> <br> Thanks,<br> Adrian<br> <br> ---<br> <br> I started reading this in the belief that this is truly a BCP and I<br> wrote the following:<br> <br> I think it would be helpful if both the Abstract and the Introduction<br> (to a lesser and greater extent, respectively) noted that:<br> - this document does not define any new procedures or protocol elements<br> - this document indicates how a specific function is provided using<br> =A0existing tools and mechanisms<br> - this document advises the Internet community on the best current<br> =A0practice for providing a packet service over an MPLS network<br> <br> However, when it comes to it, you are making to code point requests to<br> IANA. This isn't a BCP is it? Shouldn't it be Standards Track?<br> <br> ---<br> <br> LSR needs to be expanded in the Abstract and para 3 of the Introduction.<br= > <br> ---<br> <br> Section 1<br> <br> s/via physical interface/via a physical interface/<br> <br> ---<br> <br> Throughout the doc<br> <br> s/point to point/point-to-point/<br> s/point to multipoint/point-to-multipoint/<br> s/multipoint to multipoint/multipoint-to-multipoint/<br> <br> ---<br> <br> Section 2<br> <br> s/network is shown/network as shown/<br> <br> ---<br> <br> Figure 1 is missing a title<br> <br> ---<br> <br> Section 2<br> It is not necessary to expand PSN, but if you want to, you should do it<br> on first use (in section 1)<br> <br> ---<br> <br> Section 3<br> <br> s/layer two/layer 2/ =A0 for consistency with the rest of the doc<br> <br> --<br> <br> Section 7<br> <br> =A0 congestion considerations being developed for PWs apply [RFC3985],<br> =A0 [RFC5659].<br> <br> I think you can delete "being"<br> <br> ---<br> <br> Section 9<br> <br> I found what you have written a little open to (wilful)<br> misinterpretation. Which code point has which name? Couldn't you have<b= r> written:<br> <br> <br> =A0 Dotted Decimal =A0 =A0 =A0 =A0 =A0 Description =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Reference<br> =A0 ----------------------- =A0-------------------------------- =A0-------= --<br> <br> =A0 000.00x.000 =A0 =A0 =A0 =A0 =A0 =A0 =A0PacketPWEthA =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[This RFC]<br> =A0 000.00x.001 =A0 =A0 =A0 =A0 =A0 =A0 =A0PacketPWEthB =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[This RFC]<br> <br> <br> Do you want to make it clear that x is open for IANA to choose?<br> <br> ---<br> <br> Appendix A<br> <br> I can see some good reasons to preserve the history of discussion,<br> although this is not normally done with IETF documents that are<br> concerned with setting out a specification on which consensus has been<br> reached. If you want to carry on including the Appendix, you need to do<br> several things:<br> <br> 1. Refer to it in the body of the text. I think this is most easily done<br= > =A0 from the Introduction.<br> <br> 2. State in the Appendix why it is included. You do a good job of saying<br= > =A0 what is in the Appendix, but not why the Appendix is there and what<br= > =A0 the reader is supposed to gain from it.<br> <br> 3. Make it clear (in the Appendix) that it is non-normative.<br> <br> _______________________________________________<br> pwe3 mailing list<br> <a href=3D"mailto:pwe3@ietf.org" target=3D"_blank">pwe3@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/pwe3" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/pwe3</a><br> </blockquote></div><br> </div></div></blockquote></div><br> --90e6ba6e8e9c0f486c04b71e1d3a-- From matthew.bocci@alcatel-lucent.com Mon Jan 23 03:41:54 2012 Return-Path: <matthew.bocci@alcatel-lucent.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E021F8624 for <pwe3@ietfa.amsl.com>; Mon, 23 Jan 2012 03:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.444 X-Spam-Level: X-Spam-Status: No, score=-105.444 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UphnKTLiVuJP for <pwe3@ietfa.amsl.com>; Mon, 23 Jan 2012 03:41:53 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id BD8C921F8615 for <pwe3@ietf.org>; Mon, 23 Jan 2012 03:41:52 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0NBdAEG004107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <pwe3@ietf.org>; Mon, 23 Jan 2012 12:41:49 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 23 Jan 2012 12:41:22 +0100 From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> To: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "pwe3@ietf.org" <pwe3@ietf.org> Date: Mon, 23 Jan 2012 12:41:20 +0100 Thread-Topic: [PWE3] Document shepherd write-up for draft-ietf-pwe3-packet-pw-02.txt Thread-Index: AczZw+1r2ws+f62lQxGG4GtQlLzPsw== Message-ID: <CB42F6EB.21B9E%matthew.bocci@alcatel-lucent.com> In-Reply-To: <CB36156C.216DB%matthew.bocci@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB42F6EB21B9Ematthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [PWE3] Document shepherd write-up for draft-ietf-pwe3-packet-pw-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 11:41:54 -0000 --_000_CB42F6EB21B9Ematthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, I have made some additions to the documents shepherd write up to provide so= me additional details in section 1.k, as required. Here is the revised write-up. Best regards, Matthew draft-ietf-pwe3-packet-pw-02.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has received significant review by the WG and received a number of comments during WG last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. Although there were was an alternative proposal for a mechanism to support Packet PWs presented at a number of IETFs, that proposal has not been adopted by the working group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There are a couple of minor I-D nits related to a copyright dat= e and a missing reference. These should be fixed before publication. There are no formal review criteria. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists and seems reasonable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. This document is a product of the PWE3 working group. This document is BCP. Working Group Summary This draft presents a number of alternative encapsulations for a generic= packet PW that were investigated by the authors and discussed in the WG over a per= iod of time (these are documented in the appendix), and a reaches a conclusion about = which one to use. However, an alternative approach was also proposed to the working g= roup by a different set of authors in a separate draft, and progressed over a peri= od of a number of IETFs. A consensus call was conducted by the chairs to tr= y to reach agreement on how to proceed. This resulted in the Ethernet PW encapsulat= ion approach, specified in draft-ietf-pwe3-packet-pw-02, being adopted and, = since this is documenting a new way to use an existing encapsulation, it was p= rogressed as a BCP rather than standards track. WG consensus could not be reached = on the alternative approach at that time. Document Quality The draft uses an existing Ethernet PW type that is widely deployed. As well as being used for interconnecting Ethernet attachment circuits, the= re are implementations that directly terminate the Ethernet PW on an IP interfa= ce e.g. on a VRF, which represents a subset of the proposal in the draft. Howeve= r, direct termination on an LSR, as shown in the draft, is not known to be widely = implemented/ deployed yet, although such as model has been requested by service provi= ders. There are no further concerns with document quality. The document does not specify any MIB changes or additions which would n= eed review. --_000_CB42F6EB21B9Ematthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-si= ze: 14px; font-family: Calibri, sans-serif; "><div>WG,</div><div><br></div>= <div>I have made some additions to the documents shepherd write up to provi= de some additional details in section 1.k, as required. </div><div><br= ></div><div>Here is the revised write-up.</div><div><br></div><div>Best reg= ards,</div><div><br></div><div>Matthew</div><div><br></div><div><div>draft-= ietf-pwe3-packet-pw-02.txt</div><div><br></div><div>Document Shepard Write-= Up</div><div><br></div><div><br></div><div>    (1.a) Who is the D= ocument Shepherd for this document? Has the </div><div>    &= nbsp;     Document Shepherd personally reviewed this version of t= he </div><div>          document and, in part= icular, does he or she believe this </div><div>      &n= bsp;   version is ready for forwarding to the IESG for publication?&nb= sp;</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"white-= space:pre"> </span>Matthew Bocci (matthew.bocci@alcatel-lucent.com)</div><d= iv>        Yes, I have reviewed the document and I beli= eve it is ready for </div><div>        forwarding = to the IESG.</div><div><br></div><div><br></div><div>    (1.b) Ha= s the document had adequate review both from key WG members </div><div= >          and from key non-WG members? Does the D= ocument Shepherd have </div><div>          an= y concerns about the depth or breadth of the reviews that </div><div>&= nbsp;         have been performed? </div><div><br>= </div><div>        Yes, the document has received adequ= ate review. The document has</div><div>        received= significant review by the WG and received a number </div><div>  =       of comments during WG last call.</div><div><br></div><= div><br></div><div>    (1.c) Does the Document Shepherd have conc= erns that the document </div><div>          n= eeds more review from a particular or broader perspective, </div><div>=           e.g., security, operational complexity, = someone familiar with </div><div>          AA= A, internationalization or XML? </div><div><br></div><div>   = ;    No.</div><div><br></div><div><br></div><div>    (1= .d) Does the Document Shepherd have any specific concerns or </div><di= v>          issues with this document that the Res= ponsible Area Director </div><div>          a= nd/or the IESG should be aware of? For example, perhaps he </div><div>=           or she is uncomfortable with certain par= ts of the document, or </div><div>          h= as concerns whether there really is a need for it. In any </div><div>&= nbsp;         event, if the WG has discussed those issu= es and has indicated </div><div>          tha= t it still wishes to advance the document, detail those </div><div>&nb= sp;         concerns here. Has an IPR disclosure relate= d to this document </div><div>          been = filed? If so, please include a reference to the </div><div>  &nbs= p;       disclosure and summarize the WG discussion and conc= lusion on </div><div>          this issue.&nb= sp;</div><div><br></div><div>       No specific concern= s. </div><div><br></div><div><br></div><div>    (1.e) How so= lid is the WG consensus behind this document? Does it </div><div> = ;         represent the strong concurrence of a few ind= ividuals, with </div><div>          others be= ing silent, or does the WG as a whole understand and </div><div> =         agree with it? </div><div><br></div><div>=       I am comfortable that the document represents WG conse= nsus and has</div><div>      been reviewed by a reasonable n= umber of active WG participants. </div><div>      Altho= ugh there were was an alternative proposal for a mechanism to </div><d= iv>      support Packet PWs presented at a number of IETFs, = that proposal has</div><div>      not been adopted by the wo= rking group. </div><div> </div><div><br></div><div>    = (1.f) Has anyone threatened an appeal or otherwise indicated extreme <= /div><div>          discontent? If so, please summ= arise the areas of conflict in </div><div>        =   separate email messages to the Responsible Area Director. (It <= /div><div>          should be in a separate email = because this questionnaire is </div><div>        &= nbsp; entered into the ID Tracker.) </div><div><br></div><div>  &= nbsp;    None indicated.</div><div><br></div><div><br></div><div>=     (1.g) Has the Document Shepherd personally verified that the&= nbsp;</div><div>          document satisfies all I= D nits? (See </div><div>          http://www.= ietf.org/ID-Checklist.html and </div><div>        =   http://tools.ietf.org/tools/idnits/). Boilerplate checks are </= div><div>          not enough; this check needs to= be thorough. Has the document </div><div>        =   met all formal review criteria it needs to, such as the MIB </d= iv><div>          Doctor, media type and URI type = reviews? </div><div><br></div><div><br></div><div>     =  Yes. There are a couple of minor I-D nits related to a copyright dat= e </div><div>       and a missing reference. These= should be fixed before publication.</div><div>       T= here are no formal review criteria.</div><div><br></div><div>    = (1.h) Has the document split its references into normative and </div><= div>          informative? Are there normative ref= erences to documents that </div><div>         = ; are not ready for advancement or are otherwise in an unclear </div><= div>          state? If such normative references = exist, what is the </div><div>          strat= egy for their completion? Are there normative references </div><div>&n= bsp;         that are downward references, as described= in [RFC3967]? If </div><div>          so, li= st these downward references to support the Area </div><div>  &nb= sp;       Director in the Last Call procedure for them [RFC3= 967]. </div><div><br></div><div>      Yes, the referenc= es are split appropriately. </div><div><br></div><div><br></div><div><= br></div><div>    (1.i) Has the Document Shepherd verified that t= he document IANA </div><div>          conside= ration section exists and is consistent with the body </div><div> = ;         of the document? If the document specifies pr= otocol </div><div>          extensions, are r= eservations requested in appropriate IANA </div><div>    &nb= sp;     registries? Are the IANA registries clearly identified? I= f </div><div>          the document creates a= new registry, does it define the </div><div>      &nbs= p;   proposed initial contents of the registry and an allocation = </div><div>          procedure for future registra= tions? Does it suggest a </div><div>         = reasonable name for the new registry? See [RFC5226]. If the </div><di= v>          document describes an Expert Review pr= ocess has Shepherd </div><div>          confe= rred with the Responsible Area Director so that the IESG </div><div>&n= bsp;         can appoint the needed Expert during the I= ESG Evaluation? </div><div><br></div><div>      The IAN= A considerations section exists and seems reasonable.</div><div><br></div><= div><br></div><div>    (1.j) Has the Document Shepherd verified t= hat sections of the </div><div>          docu= ment that are written in a formal language, such as XML </div><div>&nb= sp;         code, BNF rules, MIB definitions, etc., val= idate correctly in </div><div>          an au= tomated checker? </div><div><br></div><div>      There = are no sections that use a formal language.</div><div><br></div><div><br></= div><div>    (1.k) The IESG approval announcement includes a Docu= ment </div><div>          Announcement Write-= Up. Please provide such a Document </div><div>      &nb= sp;   Announcement Write-Up? Recent examples can be found in the</div>= <div>          "Action" announcements for approved= documents. The approval </div><div>         = announcement contains the following sections: </div><div><br></div><d= iv>Technical Summary</div><div><br></div><div>   This document de= scribes a pseudowire mechanism that is used to</div><div>   trans= port a packet service over an MPLS PSN is the case where the</div><div>&nbs= p;  client LSR and the server PE are co-resident in the same equipment= .</div><div>   This pseudowire mechanism may be used to carry all= of the required</div><div>   layer 2 and layer 3 protocols betwe= en the pair of client LSRs.</div><div><br></div><div>   This docu= ment is a product of the PWE3 working group.</div><div><br></div><div> = ;  This document is BCP.</div><div><br></div><div>Working Group Summar= y</div><div><br></div><div>   This draft presents a number of alt= ernative encapsulations for a generic packet PW</div><div>   that= were investigated by the authors and discussed in the WG over a period of = time</div><div>  (these are documented in the appendix), and a reaches= a conclusion about which one to</div><div>   use. However, an al= ternative approach was also proposed to the working group by a </div><= div>   different set of authors in a separate draft, and progress= ed over a period</div><div>   of a number of IETFs. A consensus c= all was conducted by the chairs to try to reach</div><div>   agre= ement on how to proceed. This resulted in the Ethernet PW encapsulation</di= v><div>   approach, specified in draft-ietf-pwe3-packet-pw-02, be= ing adopted and, since</div><div>   this is documenting a new way= to use an existing encapsulation, it was progressed </div><div> =  as a BCP rather than standards track. WG consensus could not be reac= hed on the</div><div>   alternative approach at that time. <= /div><div><br></div><div>Document Quality</div><div><br></div><div>  &= nbsp;The draft uses an existing Ethernet PW type that is widely deployed. A= s</div><div>   well as being used for interconnecting Ethernet at= tachment circuits, there are</div><div>   implementations that di= rectly terminate the Ethernet PW on an IP interface e.g.</div><div>  &= nbsp;on a VRF, which represents a subset of the proposal in the draft. Howe= ver, direct</div><div>   termination on an LSR, as shown in the d= raft, is not known to be widely implemented/</div><div>   deploye= d yet, although such as model has been requested by service providers. = ;</div><div><br></div><div>   There are no further concerns with = document quality.</div><div><br></div><div>   The document does n= ot specify any MIB changes or additions which would need review.</div><div>= <br></div><div>   </div><div><br></div><div><br></div><div> --_000_CB42F6EB21B9Ematthewboccialcatellucentcom_-- From amalis@gmail.com Mon Jan 23 12:19:41 2012 Return-Path: <amalis@gmail.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857321F86EF for <pwe3@ietfa.amsl.com>; Mon, 23 Jan 2012 12:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zONS-aLiGyq3 for <pwe3@ietfa.amsl.com>; Mon, 23 Jan 2012 12:19:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7ECE21F86D1 for <pwe3@ietf.org>; Mon, 23 Jan 2012 12:19:40 -0800 (PST) Received: by iagf6 with SMTP id f6so4459846iag.31 for <pwe3@ietf.org>; Mon, 23 Jan 2012 12:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=VYNGwpDfplxuvXzl/jDgUkFOJ+fbz6dxcKUDEoOgqe0=; b=YFkri5pt5vScEqVhvXDrvaxSJXWe5ag1WrdNUJjxxVroJWvDyUKX0YypD7EnQ09ZEP A4zmbsswi5WutW7oNbrntQdvPEAI8aH6NqvnSsz0ruZ3+lSdROwrHK3SAECPbyOIS2Xq iPeQfaN5KxyW+pmzoiJVa4zvTks3dTXo2T9f8= Received: by 10.42.131.136 with SMTP id z8mr9387300ics.5.1327349980258; Mon, 23 Jan 2012 12:19:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.168.69 with HTTP; Mon, 23 Jan 2012 12:19:19 -0800 (PST) From: "Andrew G. Malis" <amalis@gmail.com> Date: Mon, 23 Jan 2012 15:19:19 -0500 Message-ID: <CAK+d4xsSRN-t6Rc0Ea-UeoJwouaDbNGtxWAfqx5eyr6pobT7xQ@mail.gmail.com> To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e81cc10e38304b737c06a Subject: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 20:19:41 -0000 --90e6ba6e81cc10e38304b737c06a Content-Type: text/plain; charset=ISO-8859-1 This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward. Thanks, Andy and Matthew --90e6ba6e81cc10e38304b737c06a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This begins a two-week PWE3 WG adoption call for <a href=3D"https://tools.i= etf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02" target=3D"_blank">https:= //tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02</a> , ending Feb= ruary 6. Please respond with your approval, disapproval, and other comments= to the PWE3 list. If you don't support the adoption, providing a reaso= n would be useful to the authors and the working group, but is not required= . Of course, the reason why you support the draft is also welcome, but also= optional. This request will be a part of PWE3 WG adoption calls going forw= ard.<br> <br>Thanks,<br>Andy and Matthew<br><br> --90e6ba6e81cc10e38304b737c06a-- From skraza@cisco.com Mon Jan 23 13:48:46 2012 Return-Path: <skraza@cisco.com> X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1234721F8677 for <pwe3@ietfa.amsl.com>; Mon, 23 Jan 2012 13:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=1.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjecHZzki4Mw for <pwe3@ietfa.amsl.com>; Mon, 23 Jan 2012 13:48:45 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7241221F8670 for <pwe3@ietf.org>; Mon, 23 Jan 2012 13:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=2939; q=dns/txt; s=iport; t=1327355325; x=1328564925; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=IaudfyS4j4as0yML/0S3X/rxjkjPbRh1bwkT5qAEnOU=; b=Gqqn+ba+h1/5vOiNWy3p3+rP8ehLEOtYb+LRNtOhz3F+No+GZTAP6Pyu blAteZPdqsfEYI3HGotXbfwBfxA/8x5jy816QHmPqYGKH2wiUvwPPAyIR oURZFD4Tq2L99v5NCeFEn8ese23dutGq8fXeeNh6HcmW5QqaBzUBwH98o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FAP/UHU+tJXG//2dsb2JhbABCgk2qcmkCgQWBcgEBAQMBAQEBDwEKIDEQDQEIBGMGMAEBBAESIodaCJowAZ4mBIwmBIg7jF6LA4MthDw X-IronPort-AV: E=Sophos;i="4.71,557,1320624000"; d="scan'208,217";a="53275495" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jan 2012 21:48:45 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0NLmj2g004473; Mon, 23 Jan 2012 21:48:45 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 15:48:44 -0600 Received: from 161.44.193.212 ([161.44.193.212]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Jan 2012 21:48:44 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 23 Jan 2012 16:48:44 -0500 From: Kamran Raza <skraza@cisco.com> To: "Andrew G. Malis" <amalis@gmail.com>, <pwe3@ietf.org> Message-ID: <CB433FEC.257D7%skraza@cisco.com> Thread-Topic: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 Thread-Index: AczaGMcFKk4FfFDEZ0KDKZbWea3fGg== In-Reply-To: <CAK+d4xsSRN-t6Rc0Ea-UeoJwouaDbNGtxWAfqx5eyr6pobT7xQ@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3410182124_30137552" X-OriginalArrivalTime: 23 Jan 2012 21:48:44.0988 (UTC) FILETIME=[C79C47C0:01CCDA18] Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pwe3> List-Post: <mailto:pwe3@ietf.org> List-Help: <mailto:pwe3-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2012 21:48:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3410182124_30137552 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 (Support). -- Kamran On 12-01-23 3:19 PM, "Andrew G. Malis" <amalis@gmail.com> wrote: > This begins a two-week PWE3 WG adoption call for > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending > February 6. Please respond with your approval, disapproval, and other comments > to the PWE3 list. If you don't support the adoption, providing a reason would > be useful to the authors and the working group, but is not required. Of > course, the reason why you support the draft is also welcome, but also > optional. This request will be a part of PWE3 WG adoption calls going forward. > > Thanks, > Andy and Matthew > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --B_3410182124_30137552 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-= mac-wd-02 +1 (Support).

-- Kamran

On 12-01-23 3:19 PM, "Andrew G. Malis" <amalis@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>This begins a two-week PWE3 WG adoption call for= = https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , endin= g February 6. Please respond with your approval, disapproval, and other comm= ents to the PWE3 list. If you don't support the adoption, providing a reason= would be useful to the authors and the working group, but is not required. = Of course, the reason why you support the draft is also welcome, but also op= tional. This request will be a part of PWE3 WG adoption calls going forward.=

Thanks,
Andy and Matthew


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



 --B_3410182124_30137552-- From DanielC@orckit.com Mon Jan 23 22:14:13 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC16121F85C9 for ; Mon, 23 Jan 2012 22:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.376 X-Spam-Level: * X-Spam-Status: No, score=1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI8ONH44rao7 for ; Mon, 23 Jan 2012 22:14:12 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59B21F85C7 for ; Mon, 23 Jan 2012 22:14:11 -0800 (PST) Received: from 1.1.40.5 ([1.1.40.5]) by tlvmail1.corrigent.com ([1.1.40.5]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jan 2012 06:16:43 +0000 Date: Tue, 24 Jan 2012 08:13:56 +0200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <02f901ccda5f$be22440a$05280101@corrigent.com> Importance: normal X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [PWE3] Starting WG adoption call fordraft-boutros-pwe3-mpls-tp-mac-wd-02 Thread-Index: AczaX74iognRnPrZT7iLt8RxcK+y8g== From: "Daniel Cohn" To: "Andrew G. Malis" , MIME-Version: 1.0 Subject: Re: [PWE3] Starting WG adoption call fordraft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:14:13 -0000 Support=0A= =0A= Thumb typed - please be tolerant=0A= =0A= "Andrew G. Malis" wrote:=0A= =0A= This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , = ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing = a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also = welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward. Thanks, Andy and Matthew From matthew.bocci@alcatel-lucent.com Tue Jan 24 02:35:49 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4CA21F85A0 for ; Tue, 24 Jan 2012 02:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJVzq+mfMPYp for ; Tue, 24 Jan 2012 02:35:48 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2D82321F859B for ; Tue, 24 Jan 2012 02:35:47 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0OAWHSR011319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Jan 2012 11:35:44 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 24 Jan 2012 11:35:29 +0100 From: "Bocci, Matthew (Matthew)" To: "Andrew G. Malis" , "adrian@olddog.co.uk" Date: Tue, 24 Jan 2012 11:35:26 +0100 Thread-Topic: [PWE3] AD review of draft-ietf-pwe3-packet-pw Thread-Index: Aczag+POolcGDiYgTP++0b1TlTmWzw== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB44381721DC6matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "draft-ietf-pwe3-packet-pw.all@tools.ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] AD review of draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 10:35:49 -0000 --_000_CB44381721DC6matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Progressing this as a BCP or informational draft was an outcome of the cons= ensus call that enabled us to progress this draft vs. draft-kini-pwe3-pkt-= encap-efficient-ip-mpls-02.txt. However, I agree that it makes sense to cha= nge it to standards track because of the IANA request for a code point from= an IETF consensus space. Working Group: please be aware of this proposed change and send any comment= s to the PWE3 list. Regards Matthew On 22/01/2012 13:44, "Andrew G. Malis" > wrote: Adrian, I meant suggesting just 3 as X. Cheers, Andy On Sat, Jan 21, 2012 at 12:39 PM, Andrew G. Malis > wrote: Adrian, (speaking a co-author) Thanks for your review and comments. The code points were a relatively recent addition that came out of a discus= sion of what to put into the MAC address fields. But you're right, the IANA= allocation probably does take it away from being a BCP. So I guess we're on the standards track now and will make the appropriate c= hanges to the draft. The other comments look fine, including the IANA code points. We could sugg= est 3 and 4 as the two "X" values to make IANA's life easier. Appendix A was very useful during the development of the draft because it k= ept us from endlessly iterating on design choices, but I personally wouldn'= t have a problem with removing it at this point. Cheers, Andy On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel > wrote: Hi, In addition to a question about the shepherd write-up which I sent to Matth= ew separately, I have a collection of small questions and nits for the authors= . I think the nits are many enough to warrant a revision, and the questions mig= ht require a revision depending on the answers. Thanks, Adrian --- I started reading this in the belief that this is truly a BCP and I wrote the following: I think it would be helpful if both the Abstract and the Introduction (to a lesser and greater extent, respectively) noted that: - this document does not define any new procedures or protocol elements - this document indicates how a specific function is provided using existing tools and mechanisms - this document advises the Internet community on the best current practice for providing a packet service over an MPLS network However, when it comes to it, you are making to code point requests to IANA. This isn't a BCP is it? Shouldn't it be Standards Track? --- LSR needs to be expanded in the Abstract and para 3 of the Introduction. --- Section 1 s/via physical interface/via a physical interface/ --- Throughout the doc s/point to point/point-to-point/ s/point to multipoint/point-to-multipoint/ s/multipoint to multipoint/multipoint-to-multipoint/ --- Section 2 s/network is shown/network as shown/ --- Figure 1 is missing a title --- Section 2 It is not necessary to expand PSN, but if you want to, you should do it on first use (in section 1) --- Section 3 s/layer two/layer 2/ for consistency with the rest of the doc -- Section 7 congestion considerations being developed for PWs apply [RFC3985], [RFC5659]. I think you can delete "being" --- Section 9 I found what you have written a little open to (wilful) misinterpretation. Which code point has which name? Couldn't you have written: Dotted Decimal Description Reference ----------------------- -------------------------------- --------- 000.00x.000 PacketPWEthA [This RFC] 000.00x.001 PacketPWEthB [This RFC] Do you want to make it clear that x is open for IANA to choose? --- Appendix A I can see some good reasons to preserve the history of discussion, although this is not normally done with IETF documents that are concerned with setting out a specification on which consensus has been reached. If you want to carry on including the Appendix, you need to do several things: 1. Refer to it in the body of the text. I think this is most easily done from the Introduction. 2. State in the Appendix why it is included. You do a good job of saying what is in the Appendix, but not why the Appendix is there and what the reader is supposed to gain from it. 3. Make it clear (in the Appendix) that it is non-normative. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_CB44381721DC6matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adrian,

Progressing this as a BCP or informational draft was an outcome of= the consensus call that enabled us to progress this draft  vs. draft-= kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt. However, I agree that it make= s sense to change it to standards track because of the IANA request for a c= ode point from an IETF consensus space.

Working Gr= oup: please be aware of this proposed change and send any comments to the P= WE3 list.

Regards

Matthew=

On 22/01/2= 012 13:44, "Andrew G. Malis" <amalis= @gmail.com> wrote:

Adrian,

I meant suggesting just 3 as X.=

Cheers,
Andy

On Sat, Jan 21, 2= 012 at 12:39 PM, Andrew G. Malis <amalis@gmail.com> wrote:
Adrian,

(speaking a co-author)

Thanks for your = review and comments.

The code points were a relatively recent additi= on that came out of a discussion of what to put into the MAC address fields= . But you're right, the IANA allocation probably does take it away from bei= ng a BCP.

So I guess we're on the standards track now and will make = the appropriate changes to the draft.

The other comments look fine, = including the IANA code points. We could suggest 3 and 4 as the two "X" val= ues to make IANA's life easier.

Appendix A was very useful during th= e development of the draft because it kept us from endlessly iterating on d= esign choices, but I personally wouldn't have a problem with removing it at= this point.

Cheers,
Andy


On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:
Hi,

In addition to a question about the shepherd write-up which I sent to Matth= ew
separately, I have a collection of small questions and nits for the authors= . I
think the nits are many enough to warrant a revision, and the questions mig= ht
require a revision depending on the answers.

Thanks,
Adrian

---

I started reading this in the belief that this is truly a BCP and I
wrote the following:

I think it would be helpful if both the Abstract and the Introduction
(to a lesser and greater extent, respectively) noted that:
- this document does not define any new procedures or protocol elements
= - this document indicates how a specific function is provided using
 existing tools and mechanisms
- this document advises the Internet community on the best current
 practice for providing a packet service over an MPLS network

= However, when it comes to it, you are making to code point requests to
IANA. This isn't a BCP is it? Shouldn't it be Standards Track?

---

LSR needs to be expanded in the Abstract and para 3 of the Introduction.
---

Section 1

s/via physical interface/via a physical interface/

---

Throughout the doc

s/point to point/point-to-point/
s/point to multipoint/point-to-multipoint/
s/multipoint to multipoint/multipoint-to-multipoint/

---

Section 2

s/network is shown/network as shown/

---

Figure 1 is missing a title

---

Section 2
It is not necessary to expand PSN, but if you want to, you should do it
= on first use (in section 1)

---

Section 3

s/layer two/layer 2/   for consistency with the rest of the doc
--

Section 7

  congestion considerations being developed for PWs apply [RFC3985],<= br>   [RFC5659].

I think you can delete "being"

---

Section 9

I found what you have written a little open to (wilful)
misinterpretation. Which code point has which name? Couldn't you have
written:


  Dotted Decimal           Description  = ;                     Ref= erence
  -----------------------  -------------------------------- &nbs= p;---------

  000.00x.000              PacketP= WEthA                    =  [This RFC]
  000.00x.001              PacketP= WEthB                    =  [This RFC]


Do you want to make it clear that x is open for IANA to choose?

---

Appendix A

I can see some good reasons to preserve the history of discussion,
although this is not normally done with IETF documents that are
concerned with setting out a specification on which consensus has been
reached. If you want to carry on including the Appendix, you need to do
= several things:

1. Refer to it in the body of the text. I think this is most easily done   from the Introduction.

2. State in the Appendix why it is included. You do a good job of saying   what is in the Appendix, but not why the Appendix is there and what=
  the reader is supposed to gain from it.

3. Make it clear (in the Appendix) that it is non-normative.

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


 --_000_CB44381721DC6matthewboccialcatellucentcom_-- From DanielC@orckit.com Tue Jan 24 06:53:20 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105E921F85B6; Tue, 24 Jan 2012 06:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDAEB6Ji3I0n; Tue, 24 Jan 2012 06:53:19 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id B099321F85B5; Tue, 24 Jan 2012 06:53:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2012 16:53:13 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130753B985@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt Thread-Index: AczPQT1sBsYZBv6vSOGAt57bNBAjSAGogWvgASMi+YA= References: <20120110023647.14526.74383.idtracker@ietfa.amsl.com> From: "Daniel Cohn" To: , , , Cc: l2vpn@ietf.org Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:53:20 -0000 Hi authors, IIUC, the use of the FEC wildcard in your draft is limited to label withdrawal and status notification messages (actually the limitation comes from RFC 5918).=20 It seems to me that it would be useful to extend the use of the wildcard also to MAC address withdrawal messages, with a view to supporting MAC flush operations for a group of PWs. A scenario where this comes useful is LSP failure, where the PE would want to signal MAC flush over all PWs in the LSP in a single message.=20 What do you think?=20 Thanks, Daniel -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, January 10, 2012 4:37 AM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt 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 : LDP Typed Wildcard FEC for the PW FEC Elements Author(s) : Kamran Raza Sami Boutros Carlos Pignataro Filename : draft-ietf-pwe3-pw-typed-wc-fec-01.txt Pages : 8 Date : 2012-01-09 The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW (0x82) FEC element types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.tx t _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Tue Jan 24 10:01:52 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1004D21F84B5 for ; Tue, 24 Jan 2012 10:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.653 X-Spam-Level: X-Spam-Status: No, score=-110.653 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x1EYzP68NDZ for ; Tue, 24 Jan 2012 10:01:50 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38921F864D for ; Tue, 24 Jan 2012 10:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=12043; q=dns/txt; s=iport; t=1327428110; x=1328637710; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=wFum9nFiRJMAYf20Ym59RL8tNLxkXAbuVOu3u5bziJ0=; b=Sv+6XsXL9dDYPIK9pzDFmGj/OkoiDNn0Fvqmenp/TGw+2DfXas9+uC3/ 2Gkgt73nTnkQm/x86TbyyiDpLciA3hSqfvEdRQvisquSo6aaVdHutcc6t gNLs5Tt1YHUfjMhqffIohx60zirk82CST0Sgj+VdloDVxn0AKpn3ldP6v k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQJAEDxHk+Q/khM/2dsb2JhbABChQmmeIEmgQqBBYFyAQEBBBIBAgENSQoCARAJAhgJFgsCAgkDAgECAUUTAQcBARAOoT4BgzMPAYkgkUGJKQMHAmuCExcIBQQBFkcMAQEBAQEBAQGCLIEWBJUdkk4 X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208,217";a="64522129" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 24 Jan 2012 18:01:49 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0OI1mDY013247; Tue, 24 Jan 2012 18:01:49 GMT Received: from dhcp-gpk02-vlan300-64-103-65-177.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q0OI1m2f013152; Tue, 24 Jan 2012 18:01:48 GMT Message-ID: <4F1EF20C.1010308@cisco.com> Date: Tue, 24 Jan 2012 18:01:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <000e01ccd85f$8f00aa60$ad01ff20$@olddog.co.uk> In-Reply-To: <000e01ccd85f$8f00aa60$ad01ff20$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------090403040308060901020200" Cc: draft-ietf-pwe3-packet-pw.all@tools.ietf.org, pwe3@ietf.org Subject: Re: [PWE3] AD review of draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 18:01:52 -0000 This is a multi-part message in MIME format. --------------090403040308060901020200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21/01/2012 17:10, Adrian Farrel wrote: > Hi, > > In addition to a question about the shepherd write-up which I sent to Matthew > separately, I have a collection of small questions and nits for the authors. I > think the nits are many enough to warrant a revision, and the questions might > require a revision depending on the answers. > > Thanks, > Adrian > > --- > > I started reading this in the belief that this is truly a BCP and I > wrote the following: > > I think it would be helpful if both the Abstract and the Introduction > (to a lesser and greater extent, respectively) noted that: > - this document does not define any new procedures or protocol elements > - this document indicates how a specific function is provided using > existing tools and mechanisms > - this document advises the Internet community on the best current > practice for providing a packet service over an MPLS network > > However, when it comes to it, you are making to code point requests to > IANA. This isn't a BCP is it? Shouldn't it be Standards Track? Done the edit, but await consensus of WG before uploading. > > --- > > LSR needs to be expanded in the Abstract and para 3 of the Introduction. Done > --- > > Section 1 > > s/via physical interface/via a physical interface/ Done > --- > > Throughout the doc > > s/point to point/point-to-point/ > s/point to multipoint/point-to-multipoint/ > s/multipoint to multipoint/multipoint-to-multipoint/ Done and s/multi-point/multipoint/ > > --- > > Section 2 > > s/network is shown/network as shown/ "The network reference model for the packet pseudowire operating in an MPLS network is shown in " The original looks correct > --- > > Figure 1 is missing a title Done > --- > > Section 2 > It is not necessary to expand PSN, but if you want to, you should do it > on first use (in section 1) Deleted expansion > --- > > Section 3 > > s/layer two/layer 2/ for consistency with the rest of the doc Done (in section 4) > -- > > Section 7 > > congestion considerations being developed for PWs apply [RFC3985], > [RFC5659]. > > I think you can delete "being" Done > > --- > > Section 9 > > I found what you have written a little open to (wilful) > misinterpretation. Which code point has which name? Couldn't you have > written: > > > Dotted Decimal Description Reference > ----------------------- -------------------------------- --------- > > 000.00x.000 PacketPWEthA [This RFC] > 000.00x.001 PacketPWEthB [This RFC] > > Do you want to make it clear that x is open for IANA to choose? Both of the above done: Dotted Decimal Description Reference ------------------- ---------------- --------- 000.00x.000 PacketPWEthA [This RFC] 000.00x.001 PacketPWEthB [This RFC] The value of x is open for IANA to choose. A value of 3 is suggested. > --- > > Appendix A > > I can see some good reasons to preserve the history of discussion, > although this is not normally done with IETF documents that are > concerned with setting out a specification on which consensus has been > reached. If you want to carry on including the Appendix, you need to do > several things: > > 1. Refer to it in the body of the text. I think this is most easily done > from the Introduction. > > 2. State in the Appendix why it is included. You do a good job of saying > what is in the Appendix, but not why the Appendix is there and what > the reader is supposed to gain from it. > > 3. Make it clear (in the Appendix) that it is non-normative. In the appendix: This appendix is non-normative. A number of approaches to the design of a packet pseudowire (PW) were investigated by the PWE3 Working Group and were discussed in IETF meetings and on the PWE3 list. This section describes the approaches that were analyzed and the technical issues that the authors took into consideration in arriving at the approach described in the main body of this document. This appendix is provided so that engineers considering alternative optimizations can have access to the rational for the selection of the approach described above. ... and at the end of the introduction: Non-normative Appendix A provides information on alternative approaches to providing a packet PW that were considered by PWE3 Working Group and the reasons for using the method defined in this specification. ==== Plus added title to Fig3 Figure 3: Packet PW Encapsulation -Stewart --------------090403040308060901020200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 21/01/2012 17:10, Adrian Farrel wrote: 
Hi,

In addition to a question about the shepherd write-up which I sent to Matthew
separately, I have a collection of small questions and nits for the authors. I
think the nits are many enough to warrant a revision, and the questions might
require a revision depending on the answers.

Thanks,
Adrian

---

I started reading this in the belief that this is truly a BCP and I 
wrote the following:

I think it would be helpful if both the Abstract and the Introduction
(to a lesser and greater extent, respectively) noted that:
- this document does not define any new procedures or protocol elements
- this document indicates how a specific function is provided using
  existing tools and mechanisms
- this document advises the Internet community on the best current
  practice for providing a packet service over an MPLS network

However, when it comes to it, you are making to code point requests to
IANA. This isn't a BCP is it? Shouldn't it be Standards Track?
Done the edit, but await consensus of WG before uploading.


---

LSR needs to be expanded in the Abstract and para 3 of the Introduction.
Done
---

Section 1

s/via physical interface/via a physical interface/
Done
---

Throughout the doc

s/point to point/point-to-point/
s/point to multipoint/point-to-multipoint/
s/multipoint to multipoint/multipoint-to-multipoint/
Done and s/multi-point/multipoint/

---

Section 2

s/network is shown/network as shown/
"The network reference model for the packet pseudowire operating in an MPLS network is shown in <ref>"

The original looks correct
---

Figure 1 is missing a title
Done
---

Section 2
It is not necessary to expand PSN, but if you want to, you should do it
on first use (in section 1)
Deleted expansion
---

Section 3
                                                                    
s/layer two/layer 2/   for consistency with the rest of the doc
Done (in section 4)
--

Section 7

   congestion considerations being developed for PWs apply [RFC3985],
   [RFC5659].

I think you can delete "being"
Done

---

Section 9

I found what you have written a little open to (wilful)
misinterpretation. Which code point has which name? Couldn't you have
written:


   Dotted Decimal           Description                       Reference
   -----------------------  --------------------------------  ---------

   000.00x.000              PacketPWEthA                      [This RFC]
   000.00x.001              PacketPWEthB                      [This RFC]


Do you want to make it clear that x is open for IANA to choose?
Both of the above done:

Dotted Decimal       Description       Reference
-------------------  ----------------  ---------

000.00x.000          PacketPWEthA      [This RFC]
000.00x.001          PacketPWEthB      [This RFC]

The value of x is open for IANA to choose. A value of 3 is suggested.

---

Appendix A

I can see some good reasons to preserve the history of discussion, 
although this is not normally done with IETF documents that are 
concerned with setting out a specification on which consensus has been
reached. If you want to carry on including the Appendix, you need to do
several things:

1. Refer to it in the body of the text. I think this is most easily done
   from the Introduction.

2. State in the Appendix why it is included. You do a good job of saying
   what is in the Appendix, but not why the Appendix is there and what
   the reader is supposed to gain from it.

3. Make it clear (in the Appendix) that it is non-normative.
In the appendix:

This appendix is non-normative.

A number of approaches to the design of a packet pseudowire (PW) were investigated by the PWE3 Working Group and were discussed in IETF meetings and on the PWE3 list. This section describes the approaches that were analyzed and the technical issues that the authors took into consideration in arriving at the approach described in the main body of this document. This appendix is provided so that engineers considering alternative optimizations can have access to the rational for the selection of the approach described above.

... and at the end of the introduction:

Non-normative Appendix A provides information on alternative approaches to providing a packet PW that were considered by PWE3 Working Group and the reasons for using the method defined in this specification.

====

Plus added title to Fig3

Figure 3: Packet PW Encapsulation
-Stewart


--------------090403040308060901020200-- From tinalam@cisco.com Tue Jan 24 13:14:26 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887ED21F85C2 for ; Tue, 24 Jan 2012 13:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juTVPmOCvETW for ; Tue, 24 Jan 2012 13:14:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1E21F85A2 for ; Tue, 24 Jan 2012 13:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tinalam@cisco.com; l=7859; q=dns/txt; s=iport; t=1327439663; x=1328649263; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Nil9e22olSpDewomvtwlr5VF1cyuqXqJnTjWsiNPn9E=; b=Ngx8WMgd7StlIDR0sdHWmRqJeukHWci+eET1TuF1R7TqF1GY2HUsG+BG PeCxR8iXS1OHgYr+pypkZ1QmXVEUqohksXqjqkO9zyY4FHLsF1NmwsKWs a7hXO+gZsHdndJzJ403x+qXeHis0oAx8c1tSvSzEZjg9zRWD4G8K0e08N g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPAeH0+rRDoH/2dsb2JhbABCgk2rZ4EFgXIBAQEEEgEJARADWQIBCBEEAQELBhcBBgFFCQgBAQQTCBqHYpoDAZ4PBIkmAgEXBAYNBYJoBQQGCw4aEQcPBQ4RBAMEF4I5YwSIP59N X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208,217";a="26957670" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 24 Jan 2012 21:14:23 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0OLEMhR017620 for ; Tue, 24 Jan 2012 21:14:22 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 13:14:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCDADD.251D10C8" Date: Tue, 24 Jan 2012 13:14:22 -0800 Message-ID: <38C76C4CBEC69F4C9971F08D00FA099211440F51@xmb-sjc-22b.amer.cisco.com> In-Reply-To: <4F1F0CAE.40304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Starting WG adoption call fordraft-boutros-pwe3-mpls-tp-mac-wd-02 Thread-Index: Acza0fyGxDHQKU13QYyZtcp7Qqrt1wACw1IA References: <45FC0B0A070BF345870B2710BADC670A08250CA8@XMB-RCD-104.cisco.com> <4F1F0CAE.40304@cisco.com> From: "Tina Lam (tinalam)" To: X-OriginalArrivalTime: 24 Jan 2012 21:14:22.0757 (UTC) FILETIME=[24D68D50:01CCDADD] Subject: Re: [PWE3] Starting WG adoption call fordraft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:22:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCDADD.251D10C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Monday, January 23, 2012 3:19 PM To: pwe3@ietf.org Subject: [PWE3] Starting WG adoption call fordraft-boutros-pwe3-mpls-tp-mac-wd-02 =20 This begins a two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and other comments to the PWE3 list. If you don't support the adoption, providing a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also welcome, but also optional. This request will be a part of PWE3 WG adoption calls going forward. Thanks, Andy and Matthew ------_=_NextPart_001_01CCDADD.251D10C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = On Behalf Of Andrew G. Malis
Sent: Monday, January 23, 2012 3:19 PM
To: pwe3@ietf.org
Subject: [PWE3] Starting WG adoption call fordraft-boutros-pwe3-mpls-tp-mac-wd-02

 

This begins a = two-week PWE3 WG adoption call for https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-= mac-wd-02 , ending February 6. Please respond with your approval, disapproval, and = other comments to the PWE3 list. If you don't support the adoption, providing = a reason would be useful to the authors and the working group, but is not required. Of course, the reason why you support the draft is also = welcome, but also optional. This request will be a part of PWE3 WG adoption calls = going forward.

Thanks,
Andy and Matthew

------_=_NextPart_001_01CCDADD.251D10C8-- From lizho.jin@gmail.com Wed Jan 25 06:24:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293AF21F86C8 for ; Wed, 25 Jan 2012 06:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNF7Ou8yMrlr for ; Wed, 25 Jan 2012 06:24:41 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5411321F86BA for ; Wed, 25 Jan 2012 06:24:41 -0800 (PST) Received: by qcsf16 with SMTP id f16so2147719qcs.31 for ; Wed, 25 Jan 2012 06:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=am/m25zRvhZZxdxloMXKBbtgqdVjbL/6jN2/t2xzxxU=; b=pZkfRTliBggx6qBV+w9MBHL3GMZaDC0taqihYB9Y5Z4ReWMR3iJ0mcHf3E1m4yfiX6 BAGYZ5zINrm6CWbzJHx/iMccwiviwyNM8fCKdmLWhmbmBlL127D+aAQjO59vGIanBRh1 /Bciaa0xjrYCPvZQNi29meJl4SlgFT9qF3COU= MIME-Version: 1.0 Received: by 10.229.76.29 with SMTP id a29mr6094858qck.117.1327501480756; Wed, 25 Jan 2012 06:24:40 -0800 (PST) Received: by 10.224.1.7 with HTTP; Wed, 25 Jan 2012 06:24:40 -0800 (PST) Date: Wed, 25 Jan 2012 22:24:40 +0800 Message-ID: From: Lizhong Jin To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=00235429cd0833052b04b75b06ba Subject: Re: [PWE3] Starting WG adoption call for draft-boutros-pwe3-mpls-tp-mac-wd-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:24:48 -0000 --00235429cd0833052b04b75b06ba Content-Type: text/plain; charset=ISO-8859-1 Support. Lizhong > Message: 1 > Date: Mon, 23 Jan 2012 15:19:19 -0500 > From: "Andrew G. Malis" > To: pwe3@ietf.org > Subject: [PWE3] Starting WG adoption call for > draft-boutros-pwe3-mpls-tp-mac-wd-02 > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > This begins a two-week PWE3 WG adoption call for > https://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending > February 6. Please respond with your approval, disapproval, and other > comments to the PWE3 list. If you don't support the adoption, providing a > reason would be useful to the authors and the working group, but is not > required. Of course, the reason why you support the draft is also welcome, > but also optional. This request will be a part of PWE3 WG adoption calls > going forward. > > Thanks, > Andy and Matthew > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/pwe3/attachments/20120123/7fcc51fa/attachment.htm > > > > ------------------------------ > --00235429cd0833052b04b75b06ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.
=A0
Lizhong
=A0
=A0
Message: 1
Date: Mon, 23 Jan 2012 = 15:19:19 -0500
From: "Andrew G. Malis" <amalis@gmail.com>
To: pwe3@ietf.org
Subject: [PWE3] S= tarting WG adoption call for
=A0 =A0 =A0 =A0draft-boutros-pwe3-mpls-tp-m= ac-wd-02
Message-ID:
=A0 =A0 =A0 =A0<CAK+d4xsSRN-t6Rc= 0Ea-UeoJwouaDbNGtxWAfqx5eyr6pobT7xQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

This begi= ns a two-week PWE3 WG adoption call for
https://tool= s.ietf.org/html/draft-boutros-pwe3-mpls-tp-mac-wd-02 , ending
February 6. Please respond with your approval, disapproval, and other
co= mments to the PWE3 list. If you don't support the adoption, providing a=
reason would be useful to the authors and the working group, but is not=
required. Of course, the reason why you support the draft is also welcome,<= br>but also optional. This request will be a part of PWE3 WG adoption calls=
going forward.

Thanks,
Andy and Matthew
-------------- nex= t part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/pwe3/attachments/2012012= 3/7fcc51fa/attachment.htm>

------------------------------
--00235429cd0833052b04b75b06ba-- From amalis@gmail.com Fri Jan 27 07:59:17 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDAB21F85C7 for ; Fri, 27 Jan 2012 07:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4WHLiwW9IcZ for ; Fri, 27 Jan 2012 07:59:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86D9121F84F7 for ; Fri, 27 Jan 2012 07:59:16 -0800 (PST) Received: by iagf6 with SMTP id f6so2798194iag.31 for ; Fri, 27 Jan 2012 07:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ztPoycz94wAQMbOiD7YtxGO7zjjuqnfFF2KhsaCs/rA=; b=LlTdQxfMFZ/agCfYezYJuxbYwvpJGxDfVoNOowxzK6MOz/FDCf5RJfSa76t1Q1QoNn KXfKNfOjb69poHgt45xhwXk/kdGOZ313j7CJEYscxzwwDA01fvqRg9wWlEiBfTWL+KL7 h+Fcc0U9uMc4Li0fMyyhg7fPda2UBtNY6KOXk= Received: by 10.50.154.200 with SMTP id vq8mr7015512igb.14.1327679956252; Fri, 27 Jan 2012 07:59:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.214.73 with HTTP; Fri, 27 Jan 2012 07:58:56 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 27 Jan 2012 10:58:56 -0500 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=14dae93408212af7a204b78494c2 Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 15:59:17 -0000 --14dae93408212af7a204b78494c2 Content-Type: text/plain; charset=ISO-8859-1 This ends the WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02. There was one unanswered email on the list regarding the draft, from Daniel Cohn. It was on a different thread and actually referred to the -01 revision of the draft, which is why the authors may not have noticed it. Matthew and I would appreciate it if this email could be addressed, and once we have resolution, the draft will be forwarded to the IESG for publication. Thanks, Andy and Matthew On Thu, Jan 12, 2012 at 2:48 PM, Andrew G. Malis wrote: > This email begins a two week working group last call for > draft-ietf-pwe3-pw-typed-wc-fec-02. > > Please post any comments to the PWE3 mailing list. > > This working group last call will end on Thursday 26 January 2012. > > Regards, > Andy & Matthew > > --14dae93408212af7a204b78494c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This ends the WG last call for draft-ietf-pwe3-pw-typed-wc-fec-02.

T= here was one unanswered email on the list regarding the draft, from Daniel = Cohn. It was on a different thread and actually referred to the -01 revisio= n of the draft, which is why the authors may not have noticed it.=A0 Matthe= w and I would appreciate it if this email could be addressed, and once we h= ave resolution, the draft will be forwarded to the IESG for publication.
Thanks,
Andy and Matthew

On Thu, J= an 12, 2012 at 2:48 PM, Andrew G. Malis <amalis@gmail.com> wrote:
This email begins a two week working group last call for draft-ietf-pwe3-pw-typed-wc-fec-02.

Please post any comments to the PWE3 mailing list.

This working group last call= will end on Thursday 26 January 2012.

Regards,
Andy & Matthew


--14dae93408212af7a204b78494c2-- From amalis@gmail.com Fri Jan 27 08:09:45 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7714321F85F4 for ; Fri, 27 Jan 2012 08:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9EN9rSVG0-M for ; Fri, 27 Jan 2012 08:09:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF46521F85F0 for ; Fri, 27 Jan 2012 08:09:44 -0800 (PST) Received: by iagf6 with SMTP id f6so2810036iag.31 for ; Fri, 27 Jan 2012 08:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=fCF9jTeaYho3frYfJr5VjSV1r/ZgaVyQzfc4zAgXEkE=; b=b7OXWUjp9dvyj6wqycmw724N/pFpvfVNd4SDhmpSRpBUnkC1eXBswwAnt8yUFzmZYp dzNXiuyQU59JbJLN5TRYMN4POMygld35DwYFc5Kn1jE0qU1awBAahGaVcYF4zkz+oz2r oNhxYMndhv45mS7F7nUBOrN3FJ5fIAL18o6Ns= Received: by 10.50.155.193 with SMTP id vy1mr7043345igb.14.1327680584242; Fri, 27 Jan 2012 08:09:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.214.73 with HTTP; Fri, 27 Jan 2012 08:09:23 -0800 (PST) From: "Andrew G. Malis" Date: Fri, 27 Jan 2012 11:09:23 -0500 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3bafe599564704b784b9ed Subject: [PWE3] Reminder to the PWE3 working group on IETF IPR policy X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:09:45 -0000 --e89a8f3bafe599564704b784b9ed Content-Type: text/plain; charset=ISO-8859-1 Those of you who following the IETF list and several of the other WG lists may have noticed some recent incidents regarding the policy. The purpose of this email is simply to remind working group participants of the IETF's IPR policy, which can be found at https://www.ietf.org/ipr/policy.html . We encourage all WG participants to read that page and the underlying RFCs 3979 and 4879. Any discussion of the IETF's IPR policy should take place on the IETF list, ietf@ietf.org. Thanks, Andy and Matthew --e89a8f3bafe599564704b784b9ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Those of you who following the IETF list and several of the other WG lists = may have noticed some recent incidents regarding the policy.

The pur= pose of this email is simply to remind working group participants of the IE= TF's IPR policy, which can be found at https://www.ietf.org/ipr/policy.html . We encourage al= l WG participants to read that page and the underlying RFCs 3979 and 4879.<= br>
Any discussion of the IETF's IPR policy should take place on the IE= TF list, ietf@ietf.org.

Thanks,=
Andy and Matthew

--e89a8f3bafe599564704b784b9ed-- From matthew.bocci@alcatel-lucent.com Fri Jan 27 08:27:57 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC0D21F85BD for ; Fri, 27 Jan 2012 08:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.7 X-Spam-Level: X-Spam-Status: No, score=-108.7 tagged_above=-999 required=5 tests=[AWL=1.548, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjsXVEoBCHgr for ; Fri, 27 Jan 2012 08:27:56 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1FF21F859E for ; Fri, 27 Jan 2012 08:27:56 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0RGRsDE005078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 27 Jan 2012 17:27:54 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 27 Jan 2012 17:27:54 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Fri, 27 Jan 2012 17:27:52 +0100 Thread-Topic: Moving forward with VCCV v2 Thread-Index: AczdEJ7pCdN+cD+uTbaZ6nOu/O5ZQw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB488108222FDmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [PWE3] Moving forward with VCCV v2 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:27:57 -0000 --_000_CB488108222FDmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, Some time ago we polled the working group to see if we could adopt draft-na= deau-pwe3-vccv-2-02.txt as a PWE3 WG draft. The chairs have now considered the discussion on the list and the subsequen= t discussion on VCCV support for the GAL. There appear to be two separate issues on the table: * VCCV support for a PW associated channel that uses the GAL as an alert= mechanisms (VCCV Type 4). This is really the subject of the draft. * What to do about legacy modes, particularly router alert and TTL expi= ry. This is a separate issue regarding the progress of RFC5085 (or some fut= ure RFC) to Internet Standard status. There seems to be consensus that there is a need for VCCV to support the GA= L and there is interest in the WG. Please could the authors of the VCCV 2 d= raft therefore resubmit the draft as a PWE3 working group draft, but removi= ng the text in the draft claiming that it simplifies the number of modes av= ailable and also updating its intended status to standards track. Regards Matthew and Andy --_000_CB488108222FDmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG,

=
Some time ago we polled the working group to see if we could adopt dra= ft-nadeau-pwe3-vccv-2-02.txt as a PWE3 WG draft.

T= he chairs have now considered the discussion on the list and the subsequent= discussion on VCCV support for the GAL.

There app= ear to be two separate issues on the table:
  • VCCV support for a= PW associated channel that uses the GAL as an alert mechanisms (VCCV Type = 4). This is really the subject of the draft.
  •  What to do about= legacy modes, particularly router alert and TTL expiry. This is a separate= issue regarding the progress of RFC5085 (or some future RFC) to Internet S= tandard status.
There seems to be consensus that there is a n= eed for VCCV to support the GAL and there is interest in the WG. Please cou= ld the authors of the VCCV 2 draft therefore resubmit the draft as a PWE3 w= orking group draft, but removing the text in the draft claiming that it sim= plifies the number of modes available and also updating its intended status= to standards track.

Regards

<= div>Matthew and Andy
--_000_CB488108222FDmatthewboccialcatellucentcom_-- From tnadeau@lucidvision.com Fri Jan 27 08:38:19 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642FB21F8537 for ; Fri, 27 Jan 2012 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzbDSq9yecwA for ; Fri, 27 Jan 2012 08:38:18 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 733A221F8526 for ; Fri, 27 Jan 2012 08:38:18 -0800 (PST) Received: from [10.100.69.22] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 8E114206545E; Fri, 27 Jan 2012 11:38:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_B192C570-D107-4FF6-99CA-B0EEA3BFFA08" From: Thomas Nadeau In-Reply-To: Date: Fri, 27 Jan 2012 11:38:16 -0500 Message-Id: <92330B63-D007-4F77-B4C8-14EE90AA26CF@lucidvision.com> References: To: "Bocci, Matthew (Matthew)" X-Mailer: Apple Mail (2.1251.1) Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Moving forward with VCCV v2 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:38:19 -0000 --Apple-Mail=_B192C570-D107-4FF6-99CA-B0EEA3BFFA08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 27, 2012, at 11:27 AM, Bocci, Matthew (Matthew) wrote: > WG, >=20 > Some time ago we polled the working group to see if we could adopt = draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 WG draft. >=20 > The chairs have now considered the discussion on the list and the = subsequent discussion on VCCV support for the GAL. >=20 > There appear to be two separate issues on the table: > VCCV support for a PW associated channel that uses the GAL as an alert = mechanisms (VCCV Type 4). This is really the subject of the draft. > What to do about legacy modes, particularly router alert and TTL = expiry. This is a separate issue regarding the progress of RFC5085 (or = some future RFC) to Internet Standard status. > There seems to be consensus that there is a need for VCCV to support = the GAL and there is interest in the WG. Please could the authors of the = VCCV 2 draft therefore resubmit the draft as a PWE3 working group draft, = but removing the text in the draft claiming that it simplifies the = number of modes available and also updating its intended status to = standards track. Will do. --Tom >=20 > Regards >=20 > Matthew and Andy > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_B192C570-D107-4FF6-99CA-B0EEA3BFFA08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Will = do.

= --Tom


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

= --Apple-Mail=_B192C570-D107-4FF6-99CA-B0EEA3BFFA08-- From cpignata@cisco.com Fri Jan 27 09:31:25 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7EC21F85E0 for ; Fri, 27 Jan 2012 09:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.235 X-Spam-Level: X-Spam-Status: No, score=-110.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDeqUOgLNYbi for ; Fri, 27 Jan 2012 09:31:25 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3D92021F8518 for ; Fri, 27 Jan 2012 09:31:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0RHVO7k006636 for ; Fri, 27 Jan 2012 12:31:24 -0500 (EST) Received: from [10.117.115.58] (rtp-cpignata-8919.cisco.com [10.117.115.58]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0RHVKLH017664; Fri, 27 Jan 2012 12:31:20 -0500 (EST) Message-ID: <4F22DF66.5020509@cisco.com> Date: Fri, 27 Jan 2012 12:31:18 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Daniel Cohn References: <20120110023647.14526.74383.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA08130753B985@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130753B985@tlvmail1> X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:31:26 -0000 Hi, Daniel, Thank you for the input! Yes, this sounds like a good suggestion and useful addition, as the FEC TLV is a parameter in the context of the MAC Address Withdraw. So a MAC Address Withdraw can be scoped beyond a single VPLS instance to all, or to all given a PW. We are working on some text to post an updated revision -03. Thanks, -- Carlos. On 1/24/2012 9:53 AM, Daniel Cohn wrote: > Hi authors, > > IIUC, the use of the FEC wildcard in your draft is limited to label > withdrawal and status notification messages (actually the limitation > comes from RFC 5918). > > It seems to me that it would be useful to extend the use of the wildcard > also to MAC address withdrawal messages, with a view to supporting MAC > flush operations for a group of PWs. A scenario where this comes useful > is LSP failure, where the PE would want to signal MAC flush over all PWs > in the LSP in a single message. > > What do you think? > > Thanks, > > Daniel > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, January 10, 2012 4:37 AM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt > > > 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 : LDP Typed Wildcard FEC for the PW FEC Elements > Author(s) : Kamran Raza > Sami Boutros > Carlos Pignataro > Filename : draft-ietf-pwe3-pw-typed-wc-fec-01.txt > Pages : 8 > Date : 2012-01-09 > > The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" > defines an extension to the Label Distribution Protocol (LDP) that > can be used when it is desired to request or withdraw or release all > label bindings for a given FEC Element type. However, a typed > wildcard FEC element must be individually defined for each FEC > element type. This specification defines the typed wildcard FEC > elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW > (0x82) FEC element types. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.t > xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.tx > t > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From amalis@gmail.com Fri Jan 27 10:08:34 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9139621F85F7 for ; Fri, 27 Jan 2012 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0zIDyr4GoQI for ; Fri, 27 Jan 2012 10:08:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F221F8592 for ; Fri, 27 Jan 2012 10:08:28 -0800 (PST) Received: by iagf6 with SMTP id f6so2950978iag.31 for ; Fri, 27 Jan 2012 10:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xsaEsCUpVaWMcGRpdPeZXYGxg48L/pg2XZSCpOk71c4=; b=HzKGkvbmES2ECcJo0DZpK4pQcLl770xaXWOBHWU2T32PNCDw69cI7OFAGjeNDIghuF IR735b7R4U2T6DWW+89M83pBOJmGD4MQBybCNK6Sai4cr5AvnjoGlKTYEo2LnlYUIFHl ZgeEe4l2r64QoPTefiyL5Ts0VPpB2gXNLHfBM= Received: by 10.50.155.193 with SMTP id vy1mr7467827igb.14.1327687708238; Fri, 27 Jan 2012 10:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.214.73 with HTTP; Fri, 27 Jan 2012 10:08:08 -0800 (PST) In-Reply-To: <4F22DF66.5020509@cisco.com> References: <20120110023647.14526.74383.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA08130753B985@tlvmail1> <4F22DF66.5020509@cisco.com> From: "Andrew G. Malis" Date: Fri, 27 Jan 2012 13:08:08 -0500 Message-ID: To: Carlos Pignataro Content-Type: multipart/alternative; boundary=e89a8f3bafe538e4c604b78662d2 Cc: pwe3@ietf.org Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:08:34 -0000 --e89a8f3bafe538e4c604b78662d2 Content-Type: text/plain; charset=ISO-8859-1 Carlos, When you post -03, please send a separate email to the pwe3 list summarizing the changes from -02 to -03 to make it easy for the WG to review the changes. Thanks much, Andy On Fri, Jan 27, 2012 at 12:31 PM, Carlos Pignataro wrote: > Hi, Daniel, > > Thank you for the input! > > Yes, this sounds like a good suggestion and useful addition, as the FEC > TLV is a parameter in the context of the MAC Address Withdraw. So a MAC > Address Withdraw can be scoped beyond a single VPLS instance to all, or > to all given a PW. > > We are working on some text to post an updated revision -03. > > Thanks, > > -- Carlos. > > On 1/24/2012 9:53 AM, Daniel Cohn wrote: > > Hi authors, > > > > IIUC, the use of the FEC wildcard in your draft is limited to label > > withdrawal and status notification messages (actually the limitation > > comes from RFC 5918). > > > > It seems to me that it would be useful to extend the use of the wildcard > > also to MAC address withdrawal messages, with a view to supporting MAC > > flush operations for a group of PWs. A scenario where this comes useful > > is LSP failure, where the PE would want to signal MAC flush over all PWs > > in the LSP in a single message. > > > > What do you think? > > > > Thanks, > > > > Daniel > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Tuesday, January 10, 2012 4:37 AM > > To: i-d-announce@ietf.org > > Cc: pwe3@ietf.org > > Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt > > > > > > 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 : LDP Typed Wildcard FEC for the PW FEC Elements > > Author(s) : Kamran Raza > > Sami Boutros > > Carlos Pignataro > > Filename : draft-ietf-pwe3-pw-typed-wc-fec-01.txt > > Pages : 8 > > Date : 2012-01-09 > > > > The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" > > defines an extension to the Label Distribution Protocol (LDP) that > > can be used when it is desired to request or withdraw or release all > > label bindings for a given FEC Element type. However, a typed > > wildcard FEC element must be individually defined for each FEC > > element type. This specification defines the typed wildcard FEC > > elements for the PWid (0x80), Generalized PWid (0x81), and P2MP PW > > (0x82) FEC element types. > > > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.t > > xt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-pw-typed-wc-fec-01.tx > > t > > > > _______________________________________________ > > 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 > --e89a8f3bafe538e4c604b78662d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlos,

When you post -03, please send a separate email to the pwe3 = list summarizing the changes from -02 to -03 to make it easy for the WG to = review the changes.

Thanks much,
Andy

On Fri, Jan 27, 2012 at 12:31 PM, Carlos Pignataro <cpignata@cisco.com> wrote= :
Hi, Daniel,

Thank you for the input!

Yes, this sounds like a good suggestion and useful addition, as the FEC
TLV is a parameter in the context of the MAC Address Withdraw. So a MAC
Address Withdraw can be scoped beyond a single VPLS instance to all, or
to all given a PW.

We are working on some text to post an updated revision -03.

Thanks,

-- Carlos.

On 1/24/2012 9:53 AM, Daniel Cohn wrote:
> Hi authors,
>
> IIUC, the use of the FEC wildcard in your draft is limited to label > withdrawal and status notification messages (actually the limitation > comes from RFC 5918).
>
> It seems to me that it would be useful to extend the use of the wildca= rd
> also to MAC address withdrawal messages, with a view to supporting MAC=
> flush operations for a group of PWs. A scenario where this comes usefu= l
> is LSP failure, where the PE would want to signal MAC flush over all P= Ws
> in the LSP in a single message.
>
> What do you think?
>
> Thanks,
>
> Daniel
>
> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Tuesday, January 10, 2012 4:37 AM
> To: i-d-announce@ietf.org=
> Cc: pwe3@ietf.org
> Subject: [PWE3] I-D Action: draft-ietf-pwe3-pw-typed-wc-fec-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Pseudowire Emulation Edg= e
> to Edge Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : LDP Typed Wildcard FEC for the= PW FEC Elements
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Kamran Raza
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sami Boutros
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Carlos Pignataro > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-pwe3-pw-typed-wc-fec-= 01.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-09
>
> =A0 =A0The "Typed Wildcard Forwarding Equivalence Class (FEC) Ele= ment"
> =A0 =A0defines an extension to the Label Distribution Protocol (LDP) t= hat
> =A0 =A0can be used when it is desired to request or withdraw or releas= e all
> =A0 =A0label bindings for a given FEC Element type. =A0However, a type= d
> =A0 =A0wildcard FEC element must be individually defined for each FEC<= br> > =A0 =A0element type. =A0This specification defines the typed wildcard = FEC
> =A0 =A0elements for the PWid (0x80), Generalized PWid (0x81), and P2MP= PW
> =A0 =A0(0x82) FEC element types.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-= ietf-pwe3-pw-typed-wc-fec-01.t
> xt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-i= etf-pwe3-pw-typed-wc-fec-01.tx
> t
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--e89a8f3bafe538e4c604b78662d2-- From internet-drafts@ietf.org Fri Jan 27 13:18:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57BC21F84CE; Fri, 27 Jan 2012 13:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6mP00-2F7H8; Fri, 27 Jan 2012 13:18:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6641B21F84BF; Fri, 27 Jan 2012 13:18:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120127211822.21214.26519.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 13:18:22 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-vccv-for-gal-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:18:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : A Unified Control Channel for Pseudowires Author(s) : Thomas D. Nadeau Luca Martini Filename : draft-ietf-pwe3-vccv-for-gal-00.txt Pages : 9 Date : 2012-01-27 This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW). VCCV applies to all supported access circuit and transport types currently defined for PWs, as well as those being transported by The MPLS Transport Profile. This new mode is intended to augment those described in RFC5085, but this document describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV. The older types will remain optional. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-for-gal-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-for-gal-00.txt From internet-drafts@ietf.org Sat Jan 28 02:38:33 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3D21F8552; Sat, 28 Jan 2012 02:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B00Fxl9P8t4M; Sat, 28 Jan 2012 02:38:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1670B21F8508; Sat, 28 Jan 2012 02:38:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120128103827.7951.62703.idtracker@ietfa.amsl.com> Date: Sat, 28 Jan 2012 02:38:27 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-packet-pw-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 10:38:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Packet Pseudowire Encapsulation over an MPLS PSN Author(s) : Stewart Bryant Luca Martini George Swallow Andy Malis Filename : draft-ietf-pwe3-packet-pw-03.txt Pages : 15 Date : 2012-01-28 This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-packet-pw-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-packet-pw-03.txt From internet-drafts@ietf.org Sun Jan 29 08:46:34 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2067B21F85F6; Sun, 29 Jan 2012 08:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Wr-+1hf8Sf; Sun, 29 Jan 2012 08:46:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F87B21F85E6; Sun, 29 Jan 2012 08:46:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120129164633.28675.24783.idtracker@ietfa.amsl.com> Date: Sun, 29 Jan 2012 08:46:33 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-mpls-tp-oam-config-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 16:46:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Label Distribution Protocol Extensions for Proactive Ope= rations, Administration and Maintenance Configuration of Dynamic MPLS Trans= port Profile PseudoWire Author(s) : Fei Zhang Bo Wu Elisa Bellagamba Filename : draft-ietf-pwe3-mpls-tp-oam-config-00.txt Pages : 28 Date : 2012-01-28 This document specifies extensions to the Label Distribution Protocol (LDP) to configure and control proactive Operations, Adminstration and Maintenance (OAM) functions, suitable for dynamic Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-tp-oam-config-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-tp-oam-config-00.txt From amalis@gmail.com Sun Jan 29 08:53:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F64821F84FC for ; Sun, 29 Jan 2012 08:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtrR95m3lKLp for ; Sun, 29 Jan 2012 08:53:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3D8221F84FB for ; Sun, 29 Jan 2012 08:53:53 -0800 (PST) Received: by iagf6 with SMTP id f6so5139292iag.31 for ; Sun, 29 Jan 2012 08:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=N9bsrgLeIwatJgBSiqshhYlJAtlSXpzLoSoudqgS56A=; b=JcDYi1dr2TIh6pwlpAPpw1W2/zjhaBMOlRqiKL2l9i3s0hVtayOuxuc36i32/+ATFw 5/2u8xOQQnPSN8WQDJObgROyY+Zxz/zFXF/U26BgY4nR/p6AX9SVkHyhXZ3pWCnbpKfp x3bi2L2eops24jNvB54ut7csbelvQnRgIRLnQ= Received: by 10.50.196.228 with SMTP id ip4mr14569878igc.28.1327856033270; Sun, 29 Jan 2012 08:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.100.198 with HTTP; Sun, 29 Jan 2012 08:53:33 -0800 (PST) In-Reply-To: <20120129164633.28675.24783.idtracker@ietfa.amsl.com> References: <20120129164633.28675.24783.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Sun, 29 Jan 2012 11:53:33 -0500 Message-ID: To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=bcaec554da6a2d0cf504b7ad930e Subject: [PWE3] Fwd: I-D Action: draft-ietf-pwe3-mpls-tp-oam-config-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 16:53:55 -0000 --bcaec554da6a2d0cf504b7ad930e Content-Type: text/plain; charset=ISO-8859-1 PWE3 WG, Please note that draft-ietf-pwe3-mpls-tp-oam-config replaces draft-ietf-pwe3-oam-config. The name was changed to make the draft easier to find for people searching for MPLS-TP related drafts in progress. Cheers, Andy ---------- Forwarded message ---------- From: Date: Sun, Jan 29, 2012 at 11:46 AM Subject: [PWE3] I-D Action: draft-ietf-pwe3-mpls-tp-oam-config-00.txt To: i-d-announce@ietf.org Cc: pwe3@ietf.org 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 : Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire Author(s) : Fei Zhang Bo Wu Elisa Bellagamba Filename : draft-ietf-pwe3-mpls-tp-oam-config-00.txt Pages : 28 Date : 2012-01-28 This document specifies extensions to the Label Distribution Protocol (LDP) to configure and control proactive Operations, Adminstration and Maintenance (OAM) functions, suitable for dynamic Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-tp-oam-config-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-tp-oam-config-00.txt _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --bcaec554da6a2d0cf504b7ad930e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PWE3 WG,

Please note that draft-ietf-pwe3-mpls-tp-oam-config replace= s draft-ietf-pwe3-oam-config.

The name was changed to make the draft easier to find for people search= ing for MPLS-TP related drafts in progress.

Cheers,
Andy

<= div class=3D"gmail_quote">---------- Forwarded message ----------
From: = <internet-drafts@ietf.org>
Date: Sun, Jan 29, 2012 at 11:46 AM
Subject: [PWE3] I-D Action: draft-ie= tf-pwe3-mpls-tp-oam-config-00.txt
To: i-d-announce@ietf.org
Cc: pw= e3@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Label Distribution Protocol Ext= ensions for Proactive Operations, Administration and Maintenance Configurat= ion of Dynamic MPLS Transport Profile PseudoWire
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Fei Zhang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bo Wu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Elisa Bellagamba
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-pwe3-mpls-tp-oam-confi= g-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-28

=A0 This document specifies extensions to the Label Distribution Protocol<= br> =A0 (LDP) to configure and control proactive Operations, Adminstration
=A0 and Maintenance (OAM) functions, suitable for dynamic Single-Segment =A0 PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-= ietf-pwe3-mpls-tp-oam-config-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ie= tf-pwe3-mpls-tp-oam-config-00.txt

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

--bcaec554da6a2d0cf504b7ad930e--