From internet-drafts@ietf.org Sat Jul 2 06:13:27 2011 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 4D2B321F8610; Sat, 2 Jul 2011 06:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoesuTM4i46F; Sat, 2 Jul 2011 06:13:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825F21F85E2; Sat, 2 Jul 2011 06:13:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110702131326.10776.62344.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2011 06:13:26 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-mpls-tp-ms-pw-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: Sat, 02 Jul 2011 13:13:27 -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 : Stitching Procedures for Static PW in MPLS-TP Environment Author(s) : Siva Sivabalan Sami Boutros Luca Martini Filename : draft-ietf-pwe3-mpls-tp-ms-pw-00.txt Pages : 11 Date : 2011-07-02 The existing procedures for concatenating static and dynamic pseudowires (PWs) do not take into account the PW status Operation, Administration, and Maintenance (OAM) messages defined for static PW. Also, these procedures do not take into account operator functions such Lock Instruct and Loopback introduced as part of MPLS Transport Profile (MPLS-TP). This informational document reiterates stitching procedures for static PW taking into account all the new proposed extensions. This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-tp-ms-pw-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-ms-pw-00.txt From matthew.bocci@alcatel-lucent.com Mon Jul 4 02:49:51 2011 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 4D35D21F8607 for ; Mon, 4 Jul 2011 02:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.962 X-Spam-Level: X-Spam-Status: No, score=-105.962 tagged_above=-999 required=5 tests=[AWL=0.286, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLlCKerx47aP for ; Mon, 4 Jul 2011 02:49:50 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4E77D21F8608 for ; Mon, 4 Jul 2011 02:49:50 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p649ngpp023093 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 4 Jul 2011 11:49:46 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 4 Jul 2011 11:49:15 +0200 From: "Bocci, Matthew (Matthew)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Mon, 4 Jul 2011 11:49:12 +0200 Thread-Topic: [PWE3] Poll for adoption of draft-delregno-pwe3-pw-vccv-impl-survey-results-00 Thread-Index: Acw6L6Iv84pLNUjjTfiCasc0k4gTHQ== 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.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA374AAD12938matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [PWE3] Poll for adoption of draft-delregno-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: Mon, 04 Jul 2011 09:49:51 -0000 --_000_CA374AAD12938matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It looks like there is consensus to adopt this. Could the authors please resubmit the draft as a PWE3 WG draft. Best regards Matthew On 10/06/2011 15:20, "Bocci, Matthew (Matthew)" > wrote: This email begins a two week poll of the PWE3 list for WG adoption of draft= -delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational document. Please reply to this thread indicating whether or not you support this. The poll closes on Friday 24th June 2011. Regards, Matthew & Andy --_000_CA374AAD12938matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It looks like there is c= onsensus to adopt this.

Could the authors please r= esubmit the draft as a PWE3 WG draft.

Best regards=

Matthew

On 10/06/2011 15:20, "Bocci, Matthew (Matthew)" <= matthew.bocci@alcatel-l= ucent.com> wrote:

This email = begins a two week poll of the PWE3 list for WG adoption of dr= aft-delregno-pwe3-pw-vccv-impl-survey-results-00 as in Informational docume= nt.

Please reply t= o this thread indicating whether or not you support this.
=
The poll closes on Friday 24th June= 2011.

Regards,

Matthew & Andy

<= /body> --_000_CA374AAD12938matthewboccialcatellucentcom_-- From hao.hongjie@zte.com.cn Mon Jul 4 04:54:54 2011 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 D2E2411E8080 for ; Mon, 4 Jul 2011 04:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVsennRzpaC5 for ; Mon, 4 Jul 2011 04:54:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 888E111E807B for ; Mon, 4 Jul 2011 04:54:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Mon, 4 Jul 2011 19:53:24 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.1397396305; Mon, 4 Jul 2011 19:54:49 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p64BsjeE080851 for ; Mon, 4 Jul 2011 19:54:45 +0800 (GMT-8) (envelope-from hao.hongjie@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p64BGkvj051872 for ; Mon, 4 Jul 2011 19:16:46 +0800 (GMT-8) (envelope-from hao.hongjie@zte.com.cn) Message-Id: <201107041154.p64BsjeE080851@mse02.zte.com.cn> To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: hao.hongjie@zte.com.cn Date: Mon, 4 Jul 2011 19:16:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-04 19:16:49, Serialize complete at 2011-07-04 19:16:49 Content-Type: multipart/alternative; boundary="=_alternative 003DCCDA482578C3_=" X-MAIL: mse02.zte.com.cn p64BsjeE080851 X-MSS: AUDITRELEASE@mse02.zte.com.cn Subject: [PWE3] draft-hao-pwe3-iccp-extension-for-msp-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: Mon, 04 Jul 2011 11:54:54 -0000 This is a multipart message in MIME format. --=_alternative 003DCCDA482578C3_= Content-Type: text/plain; charset="US-ASCII" Dear all, We meet a problem to deploy ICCP in SDH network. The figure below described it. The PE1 and PE2 run the linear multiplex section protection(MSP) desceibed in the G.841 to protect the SDH network. But they are not in the same location. So they need a machanism to synchronize the state and configuration data between the PEs. +----+ <---Pseudowire--->|PE1 | | |\ +----+ \ ------>Access Network | \ | \+----+ | | CE | | | | | /+----+ | / +----+ / |PE2 |/ <---Pseudowire--->| | +----+ We submit a draft to slove the problem. It describes the extention of ICCP's application TLVs to support the MSP application. I would be greatful if you could review the draft "draft-hao-pwe3-iccp-extension-for-msp-00" and post comments on the mailing list. Best regards, Hongjie Hao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003DCCDA482578C3_= Content-Type: text/html; charset="US-ASCII"
Dear all,


We meet a problem to deploy ICCP in SDH network. The figure below described it. The PE1 and PE2 run the linear multiplex section protection(MSP) desceibed in the G.841 to protect the SDH network. But they are not in the same location. So they need a machanism to synchronize the state and configuration data between the PEs.

                                      +----+
                    <---Pseudowire--->|PE1 |
                                      |    |\
                                      +----+  \ ------>Access Network
                                        |       \
                                        |         \+----+
                                        |          | CE |
                                        |          |    |
                                        |         /+----+
                                        |       /
                                      +----+  /
                                      |PE2 |/
                    <---Pseudowire--->|    |
                                      +----+

We submit a draft to slove the problem. It describes the extention of ICCP's application TLVs to support the MSP application.

I would be greatful if you could review the draft "draft-hao-pwe3-iccp-extension-for-msp-00" and post comments on the mailing list.


Best regards,
Hongjie Hao
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003DCCDA482578C3_=-- From stbryant@cisco.com Mon Jul 4 13:40:44 2011 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 9B14011E80E8 for ; Mon, 4 Jul 2011 13:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duMCLUjzp+kl for ; Mon, 4 Jul 2011 13:40:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 607B611E80DC for ; Mon, 4 Jul 2011 13:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=7376; q=dns/txt; s=iport; t=1309812043; x=1311021643; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=s6gbCDPCi+6W5JvKkRVwYqQfLMNjFZMlqsOP/RIvLa0=; b=QiymDktcXeEmwvhLNa3sf0Gqei+kJ1vvmOWfjHvXNVP67tNhr2FMQF0w KLdxga39C119Vo8/WSrk6ApD1wyPm7d2OdL0si3d+MjjUjOIZNM88p68m TE3tQzm5SWDjDfWPRC2le39iCFit7Wah+nqrtoSa8zF5s+9BGFCV4ZKZt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHABEkEk6Q/khN/2dsb2JhbABTmQmOc3esQoMVDwGaOYY2BJI2kDc X-IronPort-AV: E=Sophos;i="4.65,475,1304294400"; d="scan'208,217";a="99594579" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2011 20:40:42 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p64KegRt025760 for ; Mon, 4 Jul 2011 20:40:42 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p64KefF8008329; Mon, 4 Jul 2011 21:40:41 +0100 (BST) Message-ID: <4E12259E.4070902@cisco.com> Date: Mon, 04 Jul 2011 21:42:06 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: pwe3@ietf.org References: <201107041154.p64BsjeE080851@mse02.zte.com.cn> In-Reply-To: <201107041154.p64BsjeE080851@mse02.zte.com.cn> Content-Type: multipart/alternative; boundary="------------060504080206020800040107" Subject: Re: [PWE3] draft-hao-pwe3-iccp-extension-for-msp-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 20:40:44 -0000 This is a multi-part message in MIME format. --------------060504080206020800040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/07/2011 12:16, hao.hongjie@zte.com.cn wrote: > > Dear all, > > > We meet a problem to deploy ICCP in SDH network. The figure below > described it. The PE1 and PE2 run the linear multiplex section > protection(MSP) desceibed in the G.841 to protect the SDH network. But > they are not in the same location. So they need a machanism ?to > synchronize the state and configuration data between the PEs. > > +----+ > <---Pseudowire--->|PE1 | > | |\ > +----+ \ ------>Access Network > | \ > | \+----+ > | | CE | > | | | > | /+----+ > | / > +----+ / > |PE2 |/ > <---Pseudowire--->| | > +----+ > > We submit a draft to slove the problem. It describes the extention of > ICCP's application TLVs to support the MSP application. > > I would be greatful if you could review the draft > "draft-hao-pwe3-iccp-extension-for-msp-00" and post comments on the > mailing list. > > > Best regards, > Hongjie Hao > > > This scenario looks similar to Figure1 in the ICCP draft. Please can you clarify the problem in the ICCP draft that you are addressing. Thanks Stewart --------------060504080206020800040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/07/2011 12:16, hao.hongjie@zte.com.cn wrote:

Dear all,


We meet a problem to deploy ICCP in SDH network. The figure below described it. The PE1 and PE2 run the linear multiplex section protection(MSP) desceibed in the G.841 to protect the SDH network. But they are not in the same location. So they need a machanism to synchronize the state and configuration data between the PEs.

                                      +----+
                    <---Pseudowire--->|PE1 |
                                      |    |\
                                      +----+  \ ------>Access Network
                                        |       \
                                        |         \+----+
                                        |          | CE |
                                        |          |    |
                                        |         /+----+
                                        |       /
                                      +----+  /
                                      |PE2 |/
                    <---Pseudowire--->|    |
                                      +----+

We submit a draft to slove the problem. It describes the extention of ICCP's application TLVs to support the MSP application.

I would be greatful if you could review the draft "draft-hao-pwe3-iccp-extension-for-msp-00" and post comments on the mailing list.


Best regards,
Hongjie Hao



This scenario looks similar to Figure1 in the ICCP draft.

Please can you clarify the problem in the ICCP draft that you are addressing.

Thanks

Stewart


--------------060504080206020800040107-- From mach.chen@huawei.com Mon Jul 4 18:41:13 2011 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 5D1DB21F8541 for ; Mon, 4 Jul 2011 18:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB++KUnvGEkH for ; Mon, 4 Jul 2011 18:41:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 518CC21F8527 for ; Mon, 4 Jul 2011 18:41:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNU009717CK81@szxga03-in.huawei.com> for pwe3@ietf.org; Tue, 05 Jul 2011 09:41:08 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNU00H0G7CKDH@szxga03-in.huawei.com> for pwe3@ietf.org; Tue, 05 Jul 2011 09:41:08 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACG67946; Tue, 05 Jul 2011 09:41:08 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 05 Jul 2011 09:41:06 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.87]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 05 Jul 2011 09:41:02 +0800 Date: Tue, 05 Jul 2011 01:41:02 +0000 From: Mach Chen In-reply-to: <20110628094907.2326.68433.idtracker@ietfa.amsl.com> X-Originating-IP: [10.110.98.37] To: "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt Thread-index: AQHMNXkyivHsZfMQlUOywX9JUaqgoZTc+e7w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110628094907.2326.68433.idtracker@ietfa.amsl.com> Cc: "ppan@infinera.com" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-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: Tue, 05 Jul 2011 01:41:13 -0000 Hi, We submitted an update for the explicit PW to PSN binding draft( http://tools.ietf.org/id/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt ), which is mainly based on the comments received during the polling. We'd appreciate that you could review the draft and give your comments! Many thanks, Mach > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, June 28, 2011 5:49 PM > To: Mach Chen > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; Wayne > Cao(wei) > Subject: New Version Notification for > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has been > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > Revision: 03 > Title: LDP extensions for Explicit Pseudowire to transport LSP > mapping > Creation date: 2011-06-28 > WG ID: Individual Submission > Number of pages: 16 > > Abstract: > A bidirectional Pseudowire (PW) service currently uses two > unidirectional PWs each carried over a unidirectional LSP. Each end > point of a PW or segment of multi-segment PW (MS-PW) independently > selects the LSP to use to carry the PW for which it is the head end. > > Some transport services may require that bidirectional PW traffic > follows the same paths through the network in both directions. > Therefore, PWs may be required to use LSP with congruent paths. > Bidirectional LSPs or co-routed associated unidirectional LSPs allow > this service to be provided. > > This document specifies an optional extension to LDP that allows both > ends of a PW (or segment of a MS-PW) to select and bind to the same > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > The IETF Secretariat From hao.hongjie@zte.com.cn Mon Jul 4 22:37:50 2011 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 BCC631F0C3F for ; Mon, 4 Jul 2011 22:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8orIbnD6d30O for ; Mon, 4 Jul 2011 22:37:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1491F0C39 for ; Mon, 4 Jul 2011 22:37:49 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Tue, 5 Jul 2011 13:36:31 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.1397396305; Tue, 5 Jul 2011 13:37:42 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id p655bfJr059128 for ; Tue, 5 Jul 2011 13:37:41 +0800 (GMT-8) (envelope-from hao.hongjie@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p655XNHc055626; Tue, 5 Jul 2011 13:33:23 +0800 (GMT-8) (envelope-from hao.hongjie@zte.com.cn) Message-Id: <201107050537.p655bfJr059128@mse01.zte.com.cn> In-Reply-To: <4E12259E.4070902@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: hao.hongjie@zte.com.cn Date: Tue, 5 Jul 2011 13:33:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-05 13:33:24, Serialize complete at 2011-07-05 13:33:24 Content-Type: multipart/alternative; boundary="=_alternative 001E59A3482578C4_=" X-MAIL: mse01.zte.com.cn p655bfJr059128 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: pwe3-bounces@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] draft-hao-pwe3-iccp-extension-for-msp-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: Tue, 05 Jul 2011 05:37:50 -0000 This is a multipart message in MIME format. --=_alternative 001E59A3482578C4_= Content-Type: text/plain; charset="US-ASCII" Hi Stewart, Thank for your attention. Figure 1 in ICCP draft described the generic multi-chassis redundancy model. When the network is SDH network, it is just the situation we talked. ICCP draft specified the pseudowire redundancy application TLVs and multi-chassis LACP application TLVs. But we need MSP application TLVs to synchronize the state and configuration data of MSP group between PE1 and PE2. So we extended the TLVs to support the situation in the draft "draft-hao-pwe3-iccp-extension-for-msp-00" Best regards, Hongjie Hao On 04/07/2011 12:16, hao.hongjie@zte.com.cn wrote: Dear all, We meet a problem to deploy ICCP in SDH network. The figure below described it. The PE1 and PE2 run the linear multiplex section protection(MSP) desceibed in the G.841 to protect the SDH network. But they are not in the same location. So they need a machanism to synchronize the state and configuration data between the PEs. +----+ <---Pseudowire--->|PE1 | | |\ +----+ \ ------>Access Network | \ | \+----+ | | CE | | | | | /+----+ | / +----+ / |PE2 |/ <---Pseudowire--->| | +----+ We submit a draft to slove the problem. It describes the extention of ICCP's application TLVs to support the MSP application. I would be greatful if you could review the draft "draft-hao-pwe3-iccp-extension-for-msp-00" and post comments on the mailing list. Best regards, Hongjie Hao This scenario looks similar to Figure1 in the ICCP draft. Please can you clarify the problem in the ICCP draft that you are addressing. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001E59A3482578C4_= Content-Type: text/html; charset="US-ASCII"
Hi Stewart,

Thank for your attention.

Figure 1 in ICCP draft described the generic multi-chassis redundancy model. When the network is SDH network, it is just the situation we talked.
ICCP draft specified the pseudowire redundancy application TLVs and multi-chassis LACP application TLVs. But we need MSP application TLVs to
synchronize the state and configuration data of MSP group between PE1 and PE2. So we extended the TLVs to support the situation in the draft "draft-hao-pwe3-iccp-extension-for-msp-00"

Best regards,
Hongjie Hao





On 04/07/2011 12:16, hao.hongjie@zte.com.cn wrote:

Dear all,


We meet a problem to deploy ICCP in SDH network. The figure below described it. The PE1 and PE2 run the linear multiplex section protection(MSP) desceibed in the G.841 to protect the SDH network. But they are not in the same location. So they need a machanism to synchronize the state and configuration data between the PEs.

                                     +----+
                   <---Pseudowire--->|PE1 |
                                     |    |\
                                     +----+  \ ------>Access Network
                                       |       \
                                       |         \+----+
                                       |          | CE |
                                       |          |    |
                                       |         /+----+
                                       |       /
                                     +----+  /
                                     |PE2 |/
                   <---Pseudowire--->|    |
                                     +----+

We submit a draft to slove the problem. It describes the extention of ICCP's application TLVs to support the MSP application.

I would be greatful if you could review the draft "draft-hao-pwe3-iccp-extension-for-msp-00" and post comments on the mailing list.


Best regards,
Hongjie Hao


This scenario looks similar to Figure1 in the ICCP draft.

Please can you clarify the problem in the ICCP draft that you are addressing.

Thanks

Stewart

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001E59A3482578C4_=-- From internet-drafts@ietf.org Tue Jul 5 17:49:47 2011 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 72B1F21F8626; Tue, 5 Jul 2011 17:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKBXpJGJp2Gl; Tue, 5 Jul 2011 17:49:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F9521F8616; Tue, 5 Jul 2011 17:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706004947.17402.49323.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 17:49:47 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-cbit-negotiation-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:49: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 : Pseudowire Control Word Negotiation Mechanism Update Author(s) : Lizhong Jin Raymond Key Simon Delord Thomas Nadeau Vishwas Manral Sami Boutros Reshad Rahman Filename : draft-ietf-pwe3-cbit-negotiation-01.txt Pages : 10 Date : 2011-07-05 This document describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This document is to update [RFC4447] control word negotiation mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cbit-negotiation-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-cbit-negotiation-01.txt From internet-drafts@ietf.org Wed Jul 6 07:45:22 2011 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 AC50821F8762; Wed, 6 Jul 2011 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0gZH49j1Jpb; Wed, 6 Jul 2011 07:45:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2CB21F8751; Wed, 6 Jul 2011 07:45:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706144522.29642.61144.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 07:45:22 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-fat-pw-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:45: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 : Flow Aware Transport of Pseudowires over an MPLS Packet = Switched Network Author(s) : Stewart Bryant Clarence Filsfils Ulrich Drafz Vach Kompella Joe Regan Shane Amante Filename : draft-ietf-pwe3-fat-pw-07.txt Pages : 20 Date : 2011-07-06 Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-07.txt From internet-drafts@ietf.org Thu Jul 7 14:52:19 2011 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 AC72D9E8035; Thu, 7 Jul 2011 14:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDBejKG0b-l9; Thu, 7 Jul 2011 14:52:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224299E8013; Thu, 7 Jul 2011 14:52:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110707215219.1911.64138.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 14:52:19 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-dynamic-ms-pw-14.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, 07 Jul 2011 21:52:19 -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 : Dynamic Placement of Multi Segment Pseudowires Author(s) : Luca Martini Matthew Bocci Florin Balus Filename : draft-ietf-pwe3-dynamic-ms-pw-14.txt Pages : 22 Date : 2011-07-07 There is a requirement for service providers to be able to extend the reach of pseudowires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudowire among a set of Provider Edge (PE) routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-14.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-dynamic-ms-pw-14.txt From internet-drafts@ietf.org Fri Jul 8 05:44:22 2011 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 6F3B021F89BB; Fri, 8 Jul 2011 05:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUc9W-gdMsU0; Fri, 8 Jul 2011 05:44:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDBD21F88C3; Fri, 8 Jul 2011 05:44:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708124422.7813.29877.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 05:44:22 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 12:44:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Redundancy Author(s) : Praveen Muley Mustapha Aissaoui Matthew Bocci Filename : draft-ietf-pwe3-redundancy-04.txt Pages : 17 Date : 2011-07-08 This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single segment PW applications, or between Terminating PE nodes in Multi-Segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pwe3-redundancy-04.txt From internet-drafts@ietf.org Fri Jul 8 10:57:23 2011 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 1F12F21F8B11; Fri, 8 Jul 2011 10:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hViyQIQPujkL; Fri, 8 Jul 2011 10:57:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814B121F8A68; Fri, 8 Jul 2011 10:57:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708175722.30361.54266.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 10:57:22 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-packet-pw-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, 08 Jul 2011 17:57:23 -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-01.txt Pages : 14 Date : 2011-07-08 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-packet-pw-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-packet-pw-01.txt From Internet-Drafts@ietf.org Fri Jul 8 14:30:02 2011 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 32F8121F8D2A; Fri, 8 Jul 2011 14:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiGG6TjSC0RG; Fri, 8 Jul 2011 14:30:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA321F8D31; Fri, 8 Jul 2011 14:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708213001.32754.41193.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 14:30:01 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 21:30:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Requirements and Framework for Point-to-Multipoint Pseudowire Author(s) : G. Heron, et al Filename : draft-ietf-pwe3-p2mp-pw-requirements-04.txt Pages : 21 Date : 2011-07-08 This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW). The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service) as defined in the Layer 2 Virtual Private Network Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-requirements-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-p2mp-pw-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-08142528.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Sat Jul 9 16:45:23 2011 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 3AA9E21F8AC9; Sat, 9 Jul 2011 16:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYwr3lORf1Zf; Sat, 9 Jul 2011 16:45:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D601721F8A97; Sat, 9 Jul 2011 16:45:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709234522.4639.12444.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 16:45:22 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-static-pw-status-06.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, 09 Jul 2011 23:45:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Wor= king Group of the IETF. Title : Pseudowire Status for Static Pseudowires Author(s) : Luca Martini George Swallow Giles Heron Matthew Bocci Filename : draft-ietf-pwe3-static-pw-status-06.txt Pages : 13 Date : 2011-07-09 This document specifies a mechanism to signal Pseudowire (PW) status messages using an PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far end T-PE. The mechanism allows PW OAM message mapping and PW redundancy to operate on static PWs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-static-pw-status-06.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-static-pw-status-06.txt From lmartini@cisco.com Sat Jul 9 16:56:22 2011 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 1668721F86DB for ; Sat, 9 Jul 2011 16:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBK0mta7znEz for ; Sat, 9 Jul 2011 16:56:21 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6F91721F86C7 for ; Sat, 9 Jul 2011 16:56:21 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p69NuHhi021936 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jul 2011 17:56:19 -0600 (MDT) Message-ID: <4E18EAA1.2090801@cisco.com> Date: Sat, 09 Jul 2011 17:56:17 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: pwe3@ietf.org References: <20110707215219.1911.64138.idtracker@ietfa.amsl.com> In-Reply-To: <20110707215219.1911.64138.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-dynamic-ms-pw-14.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, 09 Jul 2011 23:56:22 -0000 Wg, After a discussion among the authors we realized that the ER TLV and associated procedures represent a significant amount of work, and it would be better if it was in a separate document. Initially we wanted to include just the TLV specification text , and have the procedures in a separate document, but we realized that this made the document difficult to follow. So I have pulled out the ER TLV text, and asked the WG chair how we can create another WG document containing the text we have removed from the Dynamic Placement of Multi Segment Pseudowires document. This strategy will allow us to progress the Dynamic Placement of Multi Segment Pseudowires quicker, and gives up more time to work on the explicit route technology. I'm waiting for an answer from the WG chairs on how to proceed with the ER TLV text. Thanks. Luca On 07/07/11 15:52, internet-drafts@ietf.org wrote: > 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 : Dynamic Placement of Multi Segment Pseudowires > Author(s) : Luca Martini > Matthew Bocci > Florin Balus > Filename : draft-ietf-pwe3-dynamic-ms-pw-14.txt > Pages : 22 > Date : 2011-07-07 > > There is a requirement for service providers to be able to extend the > reach of pseudowires (PW) across multiple Packet Switched Network > domains. A Multi-Segment PW is defined as a set of two or more > contiguous PW segments that behave and function as a single point- > to-point PW. This document describes extensions to the PW control > protocol to dynamically place the segments of the multi segment > pseudowire among a set of Provider Edge (PE) routers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-14.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-dynamic-ms-pw-14.txt > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Sat Jul 9 17:03:20 2011 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 9637D21F88EC for ; Sat, 9 Jul 2011 17:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzFcyJE98pX5 for ; Sat, 9 Jul 2011 17:03:20 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1210221F88DC for ; Sat, 9 Jul 2011 17:03:20 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p6A03J0K022580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jul 2011 18:03:19 -0600 (MDT) Message-ID: <4E18EC47.60007@cisco.com> Date: Sat, 09 Jul 2011 18:03:19 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [PWE3] draft-ietf-pwe3-static-pw-status-06.txt updates. 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, 10 Jul 2011 00:03:20 -0000 Wg, The editors of this document received some last call comments in private e-mails. I am a bit disappointed that these excellent review comments were not sent to the pwe3 list. However I have processed all those e-mails , and generated a -06 version of the document that includes all the LC comments. Here is an abbreviated list of the changes: - fix negotiation procedures, remove section and add text above it - in the applicability , mention BFD. concatenated path down. - if you receive a malformed TLV . what happens ? - remove and fix "This mode SHOULD NOT be used other then when specified in this document." text - clean up PW OAM status message transmit and receive - add text to clarify how the clear status TLV is sent (send immediately + 2 time only) with refresh timer of 0 - sec 5.3.1 say that if PE does not want to move to new timer value, what can S-PE do ? - need to also send status in LDP , if we send s-pe bypass This document should be now ready to progress. Luca From internet-drafts@ietf.org Sat Jul 9 17:52:03 2011 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 DCC2321F877B; Sat, 9 Jul 2011 17:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owntl1cNz5f9; Sat, 9 Jul 2011 17:52:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6982721F876E; Sat, 9 Jul 2011 17:52:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110710005203.21834.13033.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 17:52:03 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-iccp-06.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, 10 Jul 2011 00:52:04 -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 : Inter-Chassis Communication Protocol for L2VPN PE Redund= ancy Author(s) : Luca Martini Samer Salam Ali Sajassi Satoru Matsushima Filename : draft-ietf-pwe3-iccp-06.txt Pages : 78 Date : 2011-07-09 This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iccp-06.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-iccp-06.txt From david.sinicrope@ericsson.com Mon Jul 11 11:23:43 2011 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 02B0011E814B for ; Mon, 11 Jul 2011 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd4kVzuxqiyA for ; Mon, 11 Jul 2011 11:23:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id F3BCE11E8147 for ; Mon, 11 Jul 2011 11:23:35 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6BINYLt006889 for ; Mon, 11 Jul 2011 13:23:35 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 11 Jul 2011 14:23:29 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Mon, 11 Jul 2011 14:23:26 -0400 Thread-Topic: PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-Index: Acw/96Fp+IpFuoHOT5m0NMAM8iijcw== 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.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 11 Jul 2011 18:23:43 -0000 Hi All, The first pass at the PWE3 Agenda for Quebec City can be found at: http://= www.ietf.org/proceedings/81/agenda/pwe3.txt Please let me know if I missed your request or you need a slot. As always please specify desired duration, topic/draft title, and presenter= for each slot requested in response to this email. Thanks, Dave From: David A Sinicrope > Date: Mon, 27 Jun 2011 16:03:43 -0400 To: "IETF.PWE3" > Subject: PWE3 Agenda Slot call for IETF 81 - Quebec City Hi All, Please let me know if you would like a time slot for the IETF 81 PWE3 sessi= on by replying to this email with the desired duration, topic/draft title, = and presenter for each slot requested. Thanks, Dave From mach.chen@huawei.com Mon Jul 11 18:18:22 2011 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 3364511E817F for ; Mon, 11 Jul 2011 18:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm2Tb8EHel0C for ; Mon, 11 Jul 2011 18:18:21 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 94B7011E80D2 for ; Mon, 11 Jul 2011 18:18:21 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO700EHK4YK0W@szxga03-in.huawei.com> for pwe3@ietf.org; Tue, 12 Jul 2011 09:18:20 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO700EAN4YK5H@szxga03-in.huawei.com> for pwe3@ietf.org; Tue, 12 Jul 2011 09:18:20 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACB50104; Tue, 12 Jul 2011 09:18:20 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 12 Jul 2011 09:18:17 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.35]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Tue, 12 Jul 2011 09:18:19 +0800 Date: Tue, 12 Jul 2011 01:18:19 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.37] To: David Sinicrope , "IETF.PWE3" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-index: Acw1BVIP3RjFO5J6TqOdF4a+6wbr8ALK8ArA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 12 Jul 2011 01:18:22 -0000 Hi Dave, I'd like to ask for a 10 minutes slot to present the update of http://tools.ietf.org/html/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03 , Ping Pan or Mach Chen will be the presenter. Much thanks, Mach > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > David Sinicrope > Sent: Tuesday, June 28, 2011 4:04 AM > To: IETF.PWE3 > Subject: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City > > Hi All, > > Please let me know if you would like a time slot for the IETF 81 PWE3 session by > replying to this email with the desired duration, topic/draft title, and presenter > for each slot requested. > > Thanks, > Dave > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From yshen@juniper.net Tue Jul 12 05:46:55 2011 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 6D34621F8C92 for ; Tue, 12 Jul 2011 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMxQ2UG24+dw for ; Tue, 12 Jul 2011 05:46:55 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 33FCF21F8C8A for ; Tue, 12 Jul 2011 05:46:53 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKThxCPHkQPpbP0QYPTvTNfErq49Z0f7er@postini.com; Tue, 12 Jul 2011 05:46:54 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Jul 2011 05:41:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 12 Jul 2011 08:41:38 -0400 From: Yimin Shen To: David Sinicrope , IETF.PWE3 Date: Tue, 12 Jul 2011 08:41:35 -0400 Thread-Topic: PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-Index: Acw/96Fp+IpFuoHOT5m0NMAM8iijcwAmElbA 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] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 12 Jul 2011 12:46:55 -0000 Hi, Please note the updated link to the following draft, as a new revision has = been submitted. x15 min - PW Endpoint Fast Failure Protection - Yimin Shen http://tools.ietf.org/html/draft-shen-pwe3-endpoint-fast-protection Thanks, -Yimin > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > David Sinicrope > Sent: Monday, July 11, 2011 2:23 PM > To: IETF.PWE3 > Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City >=20 > Hi All, > The first pass at the PWE3 Agenda for Quebec City can be found at: > http://www.ietf.org/proceedings/81/agenda/pwe3.txt > Please let me know if I missed your request or you need a slot. > As always please specify desired duration, topic/draft title, and > presenter for each slot requested in response to this email. > Thanks, > Dave >=20 > From: David A Sinicrope > > > Date: Mon, 27 Jun 2011 16:03:43 -0400 > To: "IETF.PWE3" > > Subject: PWE3 Agenda Slot call for IETF 81 - Quebec City >=20 > Hi All, >=20 > Please let me know if you would like a time slot for the IETF 81 PWE3 > session by replying to this email with the desired duration, > topic/draft title, and presenter for each slot requested. >=20 > Thanks, > Dave > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Thu Jul 14 05:45:04 2011 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 3C26F21F877E for ; Thu, 14 Jul 2011 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUo3c98-p6HY for ; Thu, 14 Jul 2011 05:45:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61821F877B for ; Thu, 14 Jul 2011 05:45:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6ECit8l037498; Thu, 14 Jul 2011 08:44:56 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141244.p6ECit8l037498@harbor.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Tue, 05 Jul 2011 01:41:02 -0000." Date: Thu, 14 Jul 2011 08:44:55 -0400 Sender: curtis@occnc.com Cc: "ppan@infinera.com" , "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 12:45:04 -0000 In message Mach Chen writes: > > Hi, > > We submitted an update for the explicit PW to PSN binding draft( > http://tools.ietf.org/id/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > ), which is mainly based on the comments received during the > polling. We'd appreciate that you could review the draft and give your > comments! > > Many thanks, > Mach Mach, This draft has more information but it has the same problem I pointed out in the -02 version. The LSP is identified, not the tunnel. The tunnel should be identified. In a make-before-break reroute the tunnel remains constant but the LSP changes. When an LSP reroutes for whatever reason, it may be carrying a large number of PW. After the make-before-break reroute completes, the old LSP no longer exists. It should not be necessary to resignal the PW to reroute the LSP. With the text you have, using the LSP numbers, that reroute of all the carried PW would be necessary. There is only one active LSP for any given tunnel. How the active LSP is identified, relative to any other LSP is out of scope for this document. There may be a working and protect or a working and protect and new working and a new protect during a make-before-break transition. The IP traffic on an LSP and all LSP carried by a hierarchical LSP automatically move during a make-before-break reroute. The PW should also move without any additional and totally unecessare signaling. Curtis > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, June 28, 2011 5:49 PM > > To: Mach Chen > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; Wayne > > Cao(wei) > > Subject: New Version Notification for > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has been > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > Revision: 03 > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > mapping > > Creation date: 2011-06-28 > > WG ID: Individual Submission > > Number of pages: 16 > > > > Abstract: > > A bidirectional Pseudowire (PW) service currently uses two > > unidirectional PWs each carried over a unidirectional LSP. Each end > > point of a PW or segment of multi-segment PW (MS-PW) independently > > selects the LSP to use to carry the PW for which it is the head end. > > > > Some transport services may require that bidirectional PW traffic > > follows the same paths through the network in both directions. > > Therefore, PWs may be required to use LSP with congruent paths. > > Bidirectional LSPs or co-routed associated unidirectional LSPs allow > > this service to be provided. > > > > This document specifies an optional extension to LDP that allows both > > ends of a PW (or segment of a MS-PW) to select and bind to the same > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > The IETF Secretariat > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Thu Jul 14 05:59:59 2011 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 93C7521F877B for ; Thu, 14 Jul 2011 05:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BOmv9HadzKw for ; Thu, 14 Jul 2011 05:59:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id EB77321F8772 for ; Thu, 14 Jul 2011 05:59:58 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6ECxwpM044640; Thu, 14 Jul 2011 08:59:58 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141259.p6ECxwpM044640@harbor.orleans.occnc.com> To: pwe3@ietf.org From: Curtis Villamizar Date: Thu, 14 Jul 2011 08:59:58 -0400 Sender: curtis@occnc.com Subject: [PWE3] (no subject) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 12:59:59 -0000 Authors, I still don't like the idean of carrying a full Ethernet header with fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is needed it the Ethertype. I would like to see this format, along with the PW type 5 for Ethernet Raw Mode, used for backwards compatibility for the purpose of supporting old hardware only. This can then be a fallback for an LSR that cannot support just putting the EtherType above (in the PW sense, below in the MPLS sense) the optional control word. So a type 5 PW would have: +-------------------------------+ | Client | | Network Layer | | packet | n octets | | +-------------------------------+ | | | Ethernet | 14 octets | Header | | +---------------+ | | +---------------+---------------+ | Optional Control Word | 4 octets +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label +-------------------------------+ and a type IANA-TBD PW would have: +-------------------------------+ | Client | | Network Layer | | packet | n octets | | +-------------------------------+ | EtherType | 2 octets +---------------+---------------+ | Optional Control Word | 4 octets +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label +-------------------------------+ I know that this has been discussed and I'm not sure why there are such objections to offering such an option. I do know of hardware that could handle this today, but I don't doubt that there is hardware that could not handle it. Going forward if the more efficient encapaulation is the preferred one, then new hardware will support it. Curtis ------- Forwarded Message (trimmed) 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 : Packet Pseudowire Encapsulation over an MPLS PSN Author(s) : Stewart Bryant Luca Martini George Swallow Andy Malis Filename : draft-ietf-pwe3-packet-pw-01.txt Pages : 14 Date : 2011-07-08 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. ------- End of Forwarded Message From david.sinicrope@ericsson.com Thu Jul 14 06:10:19 2011 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 3E99721F891F for ; Thu, 14 Jul 2011 06:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNxG7QRIH7e5 for ; Thu, 14 Jul 2011 06:10:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8410D21F88A0 for ; Thu, 14 Jul 2011 06:10:18 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6EDA0Fb002703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Jul 2011 08:10:00 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 14 Jul 2011 09:10:00 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Thu, 14 Jul 2011 09:10:02 -0400 Thread-Topic: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-Index: AcxCJ1VoD28yTzduRdCTghJZLs+wTg== 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.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 14 Jul 2011 13:10:19 -0000 Hi All, The PWE3 agenda can be found at http://www.ietf.org/proceedings/81/agenda/p= we3.txt If you have a slot, please reply to this email and send me your presentatio= n as soon as possible for upload to the meeting materials. Thanks, Dave -----Original Message----- From: David A Sinicrope > Date: Mon, 11 Jul 2011 14:23:26 -0400 To: "IETF.PWE3" > Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City Hi All, The first pass at the PWE3 Agenda for Quebec City can be found at: http://= www.ietf.org/proceedings/81/agenda/pwe3.txt Please let me know if I missed your request or you need a slot. As always please specify desired duration, topic/draft title, and presenter= for each slot requested in response to this email. Thanks, Dave From: David A Sinicrope > Date: Mon, 27 Jun 2011 16:03:43 -0400 To: "IETF.PWE3" > Subject: PWE3 Agenda Slot call for IETF 81 - Quebec City Hi All, Please let me know if you would like a time slot for the IETF 81 PWE3 sessi= on by replying to this email with the desired duration, topic/draft title, = and presenter for each slot requested. Thanks, Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Thu Jul 14 06:34:38 2011 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 DFD6A21F85A3 for ; Thu, 14 Jul 2011 06:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aho23W6wx7jg for ; Thu, 14 Jul 2011 06:34:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE621F86E9 for ; Thu, 14 Jul 2011 06:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4177; q=dns/txt; s=iport; t=1310650473; x=1311860073; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6tLVThNE7seLw2e8lh9YjRknSZlL/BJ6KehZrtxhO+k=; b=i1cyOfLbtH1rkg5DJ2yEx4ivx6BTOmuofK4h46nQTLNNeD0MOQa5ApZS 6x89n5WcVzEGML1/LcMHTgFgAzNDnrtg671Rmp0v1MrrWre3xdqXD2IGo Kn/QSoM45aDQ9cylYlXUna3u+Ke3Nu0qkytPMB8YYvaaOdIcxsxlk+yCR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAODvHk6Q/khM/2dsb2JhbABTp1J3rCiDFQ8BmnGGOgSSZJBS X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208";a="102155368" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 13:34:31 +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 p6EDYVZY009367; Thu, 14 Jul 2011 13:34:31 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6EDYUMQ015021; Thu, 14 Jul 2011 14:34:30 +0100 (BST) Message-ID: <4E1EF066.9060605@cisco.com> Date: Thu, 14 Jul 2011 14:34:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pwe3@ietf.org References: <201107141259.p6ECxwpM044640@harbor.orleans.occnc.com> In-Reply-To: <201107141259.p6ECxwpM044640@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] (no subject) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 13:34:38 -0000 Curtis One concern that I have is with the need to "reconstruct" the MAC addresses. For example I understand that ISIS when running over a pt-pt Ethernet still sends some packets with the multicast destination addresses. As soon as we compress the Ethernet header we have to understand the protocols we are carrying. If we leave them untouched we can punt the problem to the specification of the protocols that are being carried. - Stewart On 14/07/2011 13:59, Curtis Villamizar wrote: > Authors, > > I still don't like the idean of carrying a full Ethernet header with > fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is > needed it the Ethertype. > > I would like to see this format, along with the PW type 5 for Ethernet > Raw Mode, used for backwards compatibility for the purpose of > supporting old hardware only. This can then be a fallback for an LSR > that cannot support just putting the EtherType above (in the PW sense, > below in the MPLS sense) the optional control word. > > So a type 5 PW would have: > > +-------------------------------+ > | Client | > | Network Layer | > | packet | n octets > | | > +-------------------------------+ > | | > | Ethernet | 14 octets > | Header | > | +---------------+ > | | > +---------------+---------------+ > | Optional Control Word | 4 octets > +-------------------------------+ > | PW label | 4 octets > +-------------------------------+ > | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label > +-------------------------------+ > > and a type IANA-TBD PW would have: > > +-------------------------------+ > | Client | > | Network Layer | > | packet | n octets > | | > +-------------------------------+ > | EtherType | 2 octets > +---------------+---------------+ > | Optional Control Word | 4 octets > +-------------------------------+ > | PW label | 4 octets > +-------------------------------+ > | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label > +-------------------------------+ > > I know that this has been discussed and I'm not sure why there are > such objections to offering such an option. I do know of hardware > that could handle this today, but I don't doubt that there is hardware > that could not handle it. Going forward if the more efficient > encapaulation is the preferred one, then new hardware will support it. > > Curtis > > > ------- Forwarded Message (trimmed) > > 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 : Packet Pseudowire Encapsulation over an MPLS PSN > Author(s) : Stewart Bryant > Luca Martini > George Swallow > Andy Malis > Filename : draft-ietf-pwe3-packet-pw-01.txt > Pages : 14 > Date : 2011-07-08 > > 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. > > ------- End of Forwarded Message > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From ping@pingpan.org Thu Jul 14 06:39:11 2011 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 1BEAE21F8726 for ; Thu, 14 Jul 2011 06:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpONq5vkJ0na for ; Thu, 14 Jul 2011 06:39:09 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with SMTP id 62BEE21F86EC for ; Thu, 14 Jul 2011 06:39:08 -0700 (PDT) Received: from mail-gy0-f173.google.com ([209.85.160.173]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTh7xfNU+EmdOjsq/bot+c2eBVCdur6O6@postini.com; Thu, 14 Jul 2011 06:39:09 PDT Received: by gyf2 with SMTP id 2so148308gyf.18 for ; Thu, 14 Jul 2011 06:39:07 -0700 (PDT) Received: by 10.236.192.228 with SMTP id i64mr3343617yhn.111.1310650746069; Thu, 14 Jul 2011 06:39:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Thu, 14 Jul 2011 06:38:25 -0700 (PDT) In-Reply-To: <201107141244.p6ECit8l037498@harbor.orleans.occnc.com> References: <201107141244.p6ECit8l037498@harbor.orleans.occnc.com> From: Ping Pan Date: Thu, 14 Jul 2011 06:38:25 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf30563ed724e25a04a807a8c6 Cc: "ppan@infinera.com" , "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-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: Thu, 14 Jul 2011 13:39:11 -0000 --20cf30563ed724e25a04a807a8c6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 14, 2011 at 5:44 AM, Curtis Villamizar wrote: > > In message < > F73A3CB31E8BE34FA1BBE3C8F0CB2AE201002B78@SZXEML502-MBS.china.huawei.com> > Mach Chen writes: > > > > Hi, > > > > We submitted an update for the explicit PW to PSN binding draft( > > http://tools.ietf.org/id/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > ), which is mainly based on the comments received during the > > polling. We'd appreciate that you could review the draft and give your > > comments! > > > > Many thanks, > > Mach > > > Mach, > > This draft has more information but it has the same problem I pointed > out in the -02 version. > > In this version, we have explicitly made changes on all the issues being brought up since last time, specifically, in signaling MHOP PW's, and passing information on mapping PW's to co-routed LSP's. The consideration for signaling Tunnel vs. LSP has also been considered in Section 2.1.1. The idea is to enable a PE informing anther PE on PW-LSP mapping in terms of: 1. if they are co-routed 2. if the mapping is mandatory or requires further negotiation 3. the identification of the underlying LSP's, (could be a tunnel or an explicit LSP) > The LSP is identified, not the tunnel. The tunnel should be > identified. In a make-before-break reroute the tunnel remains > constant but the LSP changes. > > When an LSP reroutes for whatever reason, it may be carrying a large > number of PW. After the make-before-break reroute completes, the old > LSP no longer exists. It should not be necessary to resignal the PW > to reroute the LSP. With the text you have, using the LSP numbers, > that reroute of all the carried PW would be necessary. > > If reroute is a frequent event in a network, the operator can use T-flag (Section 2.1) to negotiate LSP's on TunnelID only. > There is only one active LSP for any given tunnel. How the active LSP > is identified, relative to any other LSP is out of scope for this > document. There may be a working and protect or a working and protect > and new working and a new protect during a make-before-break > transition. The IP traffic on an LSP and all LSP carried by a > hierarchical LSP automatically move during a make-before-break > reroute. The PW should also move without any additional and totally > unecessare signaling. > > In case of FRR, traffic is only going over ONE tunnel at any give time, may that be active or protection. So there is no need to identify active vs. protection for the purpose of PW-LSP binding at negotiation time. Please elaborate your question. Thanks! Ping > Curtis > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > To: Mach Chen > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; Wayne > > > Cao(wei) > > > Subject: New Version Notification for > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > has been > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > repository. > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > Revision: 03 > > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > > mapping > > > Creation date: 2011-06-28 > > > WG ID: Individual Submission > > > Number of pages: 16 > > > > > > Abstract: > > > A bidirectional Pseudowire (PW) service currently uses two > > > unidirectional PWs each carried over a unidirectional LSP. Each end > > > point of a PW or segment of multi-segment PW (MS-PW) independently > > > selects the LSP to use to carry the PW for which it is the head end. > > > > > > Some transport services may require that bidirectional PW traffic > > > follows the same paths through the network in both directions. > > > Therefore, PWs may be required to use LSP with congruent paths. > > > Bidirectional LSPs or co-routed associated unidirectional LSPs allow > > > this service to be provided. > > > > > > This document specifies an optional extension to LDP that allows > both > > > ends of a PW (or segment of a MS-PW) to select and bind to the same > > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > 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 > --20cf30563ed724e25a04a807a8c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 14, 2011 at 5:44 AM, Cu= rtis Villamizar <c= urtis@occnc.com> wrote:

In message <F73A3CB31E8BE34FA1BBE3C8F0CB2AE201002B78@SZX= EML502-MBS.china.huawei.com>
Mach Chen writes:
>
> Hi,
>
> We submitted an update for the explicit PW to PSN binding draft(
> http://tools.ietf.org/id/draft-cao-pwe3-mp= ls-tp-pw-over-bidir-lsp-03.txt
> ), which is mainly based on the comments received during the
> polling. We'd appreciate that you could review the draft and give = your
> comments!
>
> Many thanks,
> Mach


Mach,

This draft has more information but it has the same problem I pointed
out in the -02 version.


In this version, we have explicitly ma= de changes on all the issues being brought up since last time, specifically= , in signaling MHOP PW's, and passing information on mapping PW's t= o co-routed LSP's.=A0The consideration for signaling Tunnel vs. LSP has= also been considered in Section 2.1.1.

The idea is to enable a PE informing anther PE on PW-LS= P mapping in terms of:

1. if they are co-routed
2. if the mapping is mandatory or requires further negotiation
3. the identification of the underlying LSP's, (could be a tunnel = or an explicit LSP)

=A0
The LSP is identified, not the tunnel. =A0The tunnel should be
identified. =A0In a make-before-break reroute the tunnel remains
constant but the LSP changes.

When an LSP reroutes for w= hatever reason, it may be carrying a large
number of PW. =A0After the make-before-break reroute completes, the old
LSP no longer exists. =A0It should not be necessary to resignal the PW
to reroute the LSP. =A0With the text you have, using the LSP numbers,
that reroute of all the carried PW would be necessary.


If reroute is a frequent event in a ne= twork, the operator can use T-flag (Section 2.1) to negotiate LSP's on = TunnelID only.
=A0
There is only one active LSP for any given tunnel. =A0How the active LSP is identified, relative to any other LSP is out of scope for this
document. =A0There may be a working and protect or a working and protect and new working and a new protect during a make-before-break
transition. =A0The IP traffic on an LSP and all LSP carried by a
hierarchical LSP automatically move during a make-before-break
reroute. =A0The PW should also move without any additional and totally
unecessare signaling.


In case= of FRR, traffic is only going over ONE tunnel at any give time, may that b= e active or protection. So there is no need to identify active vs. protecti= on for the purpose of PW-LSP binding at negotiation time.

Please elaborate your question.

Thanks!

Ping
=A0
Curtis


> > -----Original Message-----
> > From: internet-drafts= @ietf.org [mailto:internet-= drafts@ietf.org]
> > Sent: Tuesday, June 28, 2011 5:49 PM
> > To: Mach Chen
> > Cc: ppan@infinera.com; <= a href=3D"mailto:attila.takacs@ericsson.com">attila.takacs@ericsson.com= ; Mach Chen; Wayne
> > Cao(wei)
> > Subject: New Version Notification for
> > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
> >
> > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03= .txt has been
> > successfully submitted by Mach(Guoyi) Chen and posted to the IETF= repository.
> >
> > Filename: =A0 =A0draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp
> > Revision: =A0 =A003
> > Title: =A0 =A0 =A0 LDP extensions for Explicit Pseudowire to tran= sport LSP
> > mapping
> > Creation date: =A0 =A0 =A0 2011-06-28
> > WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> > Number of pages: 16
> >
> > Abstract:
> > =A0 =A0A bidirectional Pseudowire (PW) service currently uses two=
> > =A0 =A0unidirectional PWs each carried over a unidirectional LSP.= =A0Each end
> > =A0 =A0point of a PW or segment of multi-segment PW (MS-PW) indep= endently
> > =A0 =A0selects the LSP to use to carry the PW for which it is the= head end.
> >
> > =A0 =A0Some transport services may require that bidirectional PW = traffic
> > =A0 =A0follows the same paths through the network in both directi= ons.
> > =A0 =A0Therefore, PWs may be required to use LSP with congruent p= aths.
> > =A0 =A0Bidirectional LSPs or co-routed associated unidirectional = LSPs allow
> > =A0 =A0this service to be provided.
> >
> > =A0 =A0This document specifies an optional extension to LDP that = allows both
> > =A0 =A0ends of a PW (or segment of a MS-PW) to select and bind to= the same
> > =A0 =A0bidirectional LSP (or co-routed unidirectional LSPs).
> >
> >
> >
> >
> >
> > The IETF Secretariat
> _______________________________________________
> 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

--20cf30563ed724e25a04a807a8c6-- From david.sinicrope@ericsson.com Thu Jul 14 06:54:27 2011 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 548DE21F8911 for ; Thu, 14 Jul 2011 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Popq18xjpOjp for ; Thu, 14 Jul 2011 06:54:26 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74E21F889F for ; Thu, 14 Jul 2011 06:54:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6EDrtIu006092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Jul 2011 08:54:20 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 14 Jul 2011 09:54:13 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Thu, 14 Jul 2011 09:54:10 -0400 Thread-Topic: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-Index: AcxCLYNN1+6NSkTqT/6DgHg7ZclxBA== 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.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 14 Jul 2011 13:54:27 -0000 Also: - If you still need a slot and haven't requested one you have until midnight UTC-12 Friday July 15 to get me your request. Requests are given on a first come, first served basis. - If you have a slot and are planning to send in a presentation, please send it to me via reply to this email by midnight EDT Friday July 22. (If you aren't planning to use slides for your slot, please let me know that as well.) As in previous IETFs, you risk getting removed from the agenda if your slides aren't in by the deadline. The Chairs and I need time to upload, convert and load the slides together on a single laptop for the meeting and Webex. Thanks! Dave -----Original Message----- From: David A Sinicrope Date: Thu, 14 Jul 2011 09:10:02 -0400 To: "IETF.PWE3" Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City >Hi All, >The PWE3 agenda can be found at >http://www.ietf.org/proceedings/81/agenda/pwe3.txt >If you have a slot, please reply to this email and send me your >presentation as soon as possible for upload to the meeting materials. >Thanks, >Dave > > >-----Original Message----- >From: David A Sinicrope >> >Date: Mon, 11 Jul 2011 14:23:26 -0400 >To: "IETF.PWE3" > >Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City > >Hi All, >The first pass at the PWE3 Agenda for Quebec City can be found at: >http://www.ietf.org/proceedings/81/agenda/pwe3.txt >Please let me know if I missed your request or you need a slot. >As always please specify desired duration, topic/draft title, and >presenter for each slot requested in response to this email. >Thanks, >Dave > >From: David A Sinicrope >david.sinicrope@ericsson.com>> >Date: Mon, 27 Jun 2011 16:03:43 -0400 >To: "IETF.PWE3"=20 >> >Subject: PWE3 Agenda Slot call for IETF 81 - Quebec City > >Hi All, > >Please let me know if you would like a time slot for the IETF 81 PWE3 >session by replying to this email with the desired duration, topic/draft >title, and presenter for each slot requested. > >Thanks, >Dave >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Thu Jul 14 07:46:18 2011 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 CF1D621F87A9 for ; Thu, 14 Jul 2011 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8pyvDd8+y1H for ; Thu, 14 Jul 2011 07:46:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 121CF21F8797 for ; Thu, 14 Jul 2011 07:46:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6EEkFYb071145; Thu, 14 Jul 2011 10:46:15 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141446.p6EEkFYb071145@harbor.orleans.occnc.com> To: stbryant@cisco.com From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Jul 2011 14:34:30 BST." <4E1EF066.9060605@cisco.com> Date: Thu, 14 Jul 2011 10:46:15 -0400 Sender: curtis@occnc.com Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:46:18 -0000 Stewart, If the point is to carry Etherent, we use RFC4448. If the purpose is to carry IP, ICMP and ISIS (probably the only non-IP traffic anyone cares about today) across a point to point PW, the we only need the EtherType. There is no purpose to the layer-2 unicast, multicast, or broadcat address on a point to point link. There is no purpose to any layer-2 address on a point to point link that is not doing layer-2 switching. ISIS is never forwarded. Any ISIS traffic is delivered directly to the other end of the point to point link. The purpose of a packet PW is a layer-3 PW. Both ends have to be able to understand the layer-3 protocol that corresponds to the EtherType. The L2 addressing in this cases adds nothing, except backwards compatibility with old silicon. BTW- ISIS is defined over GFP with no MAC addresses so it should work over PW with no MAC addresses. Curtis In message <4E1EF066.9060605@cisco.com> Stewart Bryant writes: > > Curtis > > One concern that I have is with the need to "reconstruct" > the MAC addresses. For example I understand that > ISIS when running over a pt-pt Ethernet still sends > some packets with the multicast destination addresses. > > As soon as we compress the Ethernet header we have to > understand the protocols we are carrying. If we leave them > untouched we can punt the problem to the specification > of the protocols that are being carried. > > - Stewart > > > > On 14/07/2011 13:59, Curtis Villamizar wrote: > > Authors, > > > > I still don't like the idean of carrying a full Ethernet header with > > fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is > > needed it the Ethertype. > > > > I would like to see this format, along with the PW type 5 for Ethernet > > Raw Mode, used for backwards compatibility for the purpose of > > supporting old hardware only. This can then be a fallback for an LSR > > that cannot support just putting the EtherType above (in the PW sense, > > below in the MPLS sense) the optional control word. > > > > So a type 5 PW would have: > > > > +-------------------------------+ > > | Client | > > | Network Layer | > > | packet | n octets > > | | > > +-------------------------------+ > > | | > > | Ethernet | 14 octets > > | Header | > > | +---------------+ > > | | > > +---------------+---------------+ > > | Optional Control Word | 4 octets > > +-------------------------------+ > > | PW label | 4 octets > > +-------------------------------+ > > | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label > > +-------------------------------+ > > > > and a type IANA-TBD PW would have: > > > > +-------------------------------+ > > | Client | > > | Network Layer | > > | packet | n octets > > | | > > +-------------------------------+ > > | EtherType | 2 octets > > +---------------+---------------+ > > | Optional Control Word | 4 octets > > +-------------------------------+ > > | PW label | 4 octets > > +-------------------------------+ > > | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label > > +-------------------------------+ > > > > I know that this has been discussed and I'm not sure why there are > > such objections to offering such an option. I do know of hardware > > that could handle this today, but I don't doubt that there is hardware > > that could not handle it. Going forward if the more efficient > > encapaulation is the preferred one, then new hardware will support it. > > > > Curtis > > > > > > ------- Forwarded Message (trimmed) > > > > 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 : Packet Pseudowire Encapsulation over an MPLS PSN > > Author(s) : Stewart Bryant > > Luca Martini > > George Swallow > > Andy Malis > > Filename : draft-ietf-pwe3-packet-pw-01.txt > > Pages : 14 > > Date : 2011-07-08 > > > > 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. > > > > ------- End of Forwarded Message From amalis@gmail.com Thu Jul 14 08:14:05 2011 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 08E9921F8B5F for ; Thu, 14 Jul 2011 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCsF6Ut7URoy for ; Thu, 14 Jul 2011 08:14:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2E21F8B5A for ; Thu, 14 Jul 2011 08:14:00 -0700 (PDT) Received: by eye13 with SMTP id 13so243209eye.31 for ; Thu, 14 Jul 2011 08:13:59 -0700 (PDT) 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=7BQ1uqJHVF/6wOoLSXuqT3qRYccj4LbkMtYTQzqpIyU=; b=s0OfW3AGPxPv0VS/9XfpmnP8zD8Kui+IVmMwpM8cJv8osk+P/c46512m/MZLnhL/nm QBeR/poGo46Rc7hUto5z1tyQQ9e5lIA2F5T0RLLHGCcGpMAGXalNzKrWSUVLH3HWZQmS STxD2EFUPTZlI38M9/1mUoEnQDcLwauNWW9KQ= Received: by 10.204.33.70 with SMTP id g6mr972893bkd.123.1310656439289; Thu, 14 Jul 2011 08:13:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.152.216 with HTTP; Thu, 14 Jul 2011 08:13:39 -0700 (PDT) In-Reply-To: <201107141446.p6EEkFYb071145@harbor.orleans.occnc.com> References: <4E1EF066.9060605@cisco.com> <201107141446.p6EEkFYb071145@harbor.orleans.occnc.com> From: "Andrew G. Malis" Date: Thu, 14 Jul 2011 11:13:39 -0400 Message-ID: To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] 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: Thu, 14 Jul 2011 15:14:05 -0000 Curtis, This is the approach that we proposed way back in the -00 version of our individual draft. We got a lot of flack from HW vendors that they couldn't implement it on current chipsets. Cheers, Andy On Thu, Jul 14, 2011 at 10:46 AM, Curtis Villamizar wrot= e: > > Stewart, > > If the point is to carry Etherent, we use RFC4448. =A0If the purpose is > to carry IP, ICMP and ISIS (probably the only non-IP traffic anyone > cares about today) across a point to point PW, the we only need the > EtherType. =A0There is no purpose to the layer-2 unicast, multicast, or > broadcat address on a point to point link. =A0There is no purpose to any > layer-2 address on a point to point link that is not doing layer-2 > switching. =A0ISIS is never forwarded. =A0Any ISIS traffic is delivered > directly to the other end of the point to point link. > > The purpose of a packet PW is a layer-3 PW. =A0Both ends have to be able > to understand the layer-3 protocol that corresponds to the EtherType. > The L2 addressing in this cases adds nothing, except backwards > compatibility with old silicon. =A0BTW- ISIS is defined over GFP with no > MAC addresses so it should work over PW with no MAC addresses. > > Curtis > > > In message <4E1EF066.9060605@cisco.com> > Stewart Bryant writes: >> >> Curtis >> >> One concern that I have is with the need to "reconstruct" >> the MAC addresses. For example I understand that >> ISIS when running over a pt-pt Ethernet still sends >> some packets with the multicast destination addresses. >> >> As soon as we compress the Ethernet header we have to >> understand the protocols we are carrying. If we leave them >> untouched we can punt the problem to the specification >> of the protocols that are being carried. >> >> - Stewart >> >> >> >> On 14/07/2011 13:59, Curtis Villamizar wrote: >> > Authors, >> > >> > I still don't like the idean of carrying a full Ethernet header with >> > fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is >> > needed it the Ethertype. >> > >> > I would like to see this format, along with the PW type 5 for Ethernet >> > Raw Mode, used for backwards compatibility for the purpose of >> > supporting old hardware only. =A0This can then be a fallback for an LS= R >> > that cannot support just putting the EtherType above (in the PW sense, >> > below in the MPLS sense) the optional control word. >> > >> > So a type 5 PW would have: >> > >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0Network Layer =A0 =A0 =A0 =A0| >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0packet =A0 =A0 =A0 =A0 =A0 =A0 | =A0n= octets >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0Ethernet =A0 =A0 =A0 =A0 =A0 =A0 | 14 oct= ets >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 Header =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------+ >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 +---------------+---------------+ >> > =A0 =A0 | =A0 =A0Optional Control Word =A0 =A0 =A0| =A04 octets >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0PW label =A0 =A0 =A0 =A0 =A0 =A0 | =A04 o= ctets >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 Server MPLS Tunnel Label(s) | =A0n*4 octets (four octets= per label >> > =A0 =A0 +-------------------------------+ >> > >> > and a type IANA-TBD PW would have: >> > >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0Network Layer =A0 =A0 =A0 =A0| >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0packet =A0 =A0 =A0 =A0 =A0 =A0 | =A0n= octets >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0EtherType =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 o= ctets >> > =A0 =A0 +---------------+---------------+ >> > =A0 =A0 | =A0 =A0Optional Control Word =A0 =A0 =A0| =A04 octets >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 =A0 =A0 =A0 =A0PW label =A0 =A0 =A0 =A0 =A0 =A0 | =A04 o= ctets >> > =A0 =A0 +-------------------------------+ >> > =A0 =A0 | =A0 Server MPLS Tunnel Label(s) | =A0n*4 octets (four octets= per label >> > =A0 =A0 +-------------------------------+ >> > >> > I know that this has been discussed and I'm not sure why there are >> > such objections to offering such an option. =A0I do know of hardware >> > that could handle this today, but I don't doubt that there is hardware >> > that could not handle it. =A0Going forward if the more efficient >> > encapaulation is the preferred one, then new hardware will support it. >> > >> > Curtis >> > >> > >> > ------- Forwarded Message (trimmed) >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Pseudowire Emulation Edge to Edg= e Working Group of the IETF. >> > >> > =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Packet Pseudowire Encapsulation ov= er an MPLS PSN >> > =A0 =A0 Author(s) =A0 =A0 =A0 : Stewart Bryant >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Luca Martini >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0George Swallow >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Andy Malis >> > =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-pwe3-packet-pw-01.txt >> > =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14 >> > =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-07-08 >> > >> > =A0 =A0 This document describes a pseudowire mechanism that is used to >> > =A0 =A0 transport a packet service over an MPLS PSN is the case where = the >> > =A0 =A0 client LSR and the server PE are co-resident in the same equip= ment. >> > =A0 =A0 This pseudowire mechanism may be used to carry all of the requ= ired >> > =A0 =A0 layer 2 and layer 3 protocols between the pair of client LSRs. >> > >> > ------- End of Forwarded Message > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From Alexander.Vainshtein@ecitele.com Thu Jul 14 09:27:00 2011 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 E7ED721F8920 for ; Thu, 14 Jul 2011 09:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+hFTQMCk5Mt for ; Thu, 14 Jul 2011 09:26:57 -0700 (PDT) Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFF421F864A for ; Thu, 14 Jul 2011 09:26:56 -0700 (PDT) X-AuditID: 93eaf2e7-b7ba6ae0000066c3-bf-4e1f18c57bbb Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id A9.CC.26307.5C81F1E4; Thu, 14 Jul 2011 19:26:45 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 14 Jul 2011 19:26:52 +0300 From: Alexander Vainshtein To: "curtis@occnc.com" , "stbryant@cisco.com" Date: Thu, 14 Jul 2011 19:26:50 +0300 Thread-Topic: [PWE3] draft-ietf-pwe3-packet-pw Thread-Index: AcxCNM5ABRqw28FZRJC+cmxD3Ovv9QADVd5A Message-ID: References: Your message of "Thu, 14 Jul 2011 14:34:30 BST." <4E1EF066.9060605@cisco.com> <201107141446.p6EEkFYb071145@harbor.orleans.occnc.com> In-Reply-To: <201107141446.p6EEkFYb071145@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRzu3Z3rNK/Ole1NUq9To6/ZpkXLmkRBGJHal3+UYOf2tl1ut7E7 wwmVoVEJSmYRm5JFUmIfI0taaWj2YQVlRURECZlSuQhalpSg3e3KjO6v532f5/k9v/f4/QhM 06eOIzheRG6etTPqKLx2MDSkuwsTs/Uj1fOMtztPTDZWh67ixscD9WAVlnVs5HJEVmPjD1XW maHsXGxbGVjJ8rxTZEVEW5BgNjG5bm43a/YwNGcxMQaGdtlZM3IgXjQxrMuFeAuTGUX/962U ZBxPI97stHC81cSs25yjMxqXLtcZmMy5SYb0FVFbbJxAI52D5ey0AwkCa0W0dLPjKmbrO94D XGcMJR3fm0AZ8DKVIJKA1BJ4sTYQoeCZ8EmvX10JoggNdRPAnitfIpTDMQCHvFWYrFJTJthy /o1axjOoPHj0+f6wG6OS4LW68vA9TqXA0W6vSsbTKR0M1V7BFX0qrK+78dubBh/5+0ElIAiS yoHdZ3cpWccBPNz7IqyPpNZA/w9vuD6Quht+eEGlZGnhq/4GldI1BRvbezAFx8KP70Z/62Ph 64N+oOgXwVNtIbWCF8Kzp4NhPUnFwAfeflzxzoK3ml7iR4DWNyHCN8Hum2D3TbCfAngziOXs LrHQYdUbUpGZE5EdpZqdjhagTMv7APjZkNwFKAIw0eT9lIRsTQS7W/A4usAsQsXEkhdnJmZr phY6LR4bK9gK3MV2JHQBSGDMDDKhQ5KTFtZTitzOP5RR+ss1WNwUs1OaS14sSNfr/zkwWnLA /GmDhrJKU1eEkAu5/1hnEwQDyRhpfDUxbmRFJTs5u/iXVhGRcnK0lLxL7ooUXKxD4KwK/xDM idOSI1qJoGTCVsyPe+XV2Dc2NjYItNI7p5PJsipaWpxx96BUWCUVvpQRLxeWNmKciisDeZoK r88krLdsFKqSOuxrlwVXQ/emeP898YN+yr73QfrxQHt7Y73x8PynBXfyTYXX85811Fgit/mb PXiLujzYkpj26IAxfk/g26LtSfuFc9/Xn24LWLdmtB7a2MUWv+2reTWClYZOfm0tDwQr2ouW DI9+3tubPDxn0s7OxdOKtncyuGBjDQswt8D+AtZJruD1AwAA Cc: "pwe3@ietf.org" Subject: Re: [PWE3] 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: Thu, 14 Jul 2011 16:27:01 -0000 Curtis, and all, I also do not see any sense in inventing fictional MAC addresses just so tha= t we can push them on the PW packet on Tx and ignore them on Rx. A minor comment: If you extend EtherType (2 octets) to 4 octets with all zeroes padding, you= have your GRE header. AFAIK IS-IS runs over GRE quite well. And I do not think adding 16 bits real= ly matters here. I've proposed this at the face-to-face PWE3 Session some time ago, but it w= as not accepted by the authors. Regards, Sasha > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Cu= rtis > Villamizar > Sent: Thursday, July 14, 2011 5:46 PM > To: stbryant@cisco.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-ietf-pwe3-packet-pw > > > Stewart, > > If the point is to carry Etherent, we use RFC4448. If the purpose is > to carry IP, ICMP and ISIS (probably the only non-IP traffic anyone > cares about today) across a point to point PW, the we only need the > EtherType. There is no purpose to the layer-2 unicast, multicast, or > broadcat address on a point to point link. There is no purpose to any > layer-2 address on a point to point link that is not doing layer-2 > switching. ISIS is never forwarded. Any ISIS traffic is delivered > directly to the other end of the point to point link. > > The purpose of a packet PW is a layer-3 PW. Both ends have to be able > to understand the layer-3 protocol that corresponds to the EtherType. > The L2 addressing in this cases adds nothing, except backwards > compatibility with old silicon. BTW- ISIS is defined over GFP with no > MAC addresses so it should work over PW with no MAC addresses. > > Curtis > > > In message <4E1EF066.9060605@cisco.com> > Stewart Bryant writes: > > > > Curtis > > > > One concern that I have is with the need to "reconstruct" > > the MAC addresses. For example I understand that > > ISIS when running over a pt-pt Ethernet still sends > > some packets with the multicast destination addresses. > > > > As soon as we compress the Ethernet header we have to > > understand the protocols we are carrying. If we leave them > > untouched we can punt the problem to the specification > > of the protocols that are being carried. > > > > - Stewart > > > > > > > > On 14/07/2011 13:59, Curtis Villamizar wrote: > > > Authors, > > > > > > I still don't like the idean of carrying a full Ethernet header with > > > fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is > > > needed it the Ethertype. > > > > > > I would like to see this format, along with the PW type 5 for Ethernet > > > Raw Mode, used for backwards compatibility for the purpose of > > > supporting old hardware only. This can then be a fallback for an LSR > > > that cannot support just putting the EtherType above (in the PW sense, > > > below in the MPLS sense) the optional control word. > > > > > > So a type 5 PW would have: > > > > > > +-------------------------------+ > > > | Client | > > > | Network Layer | > > > | packet | n octets > > > | | > > > +-------------------------------+ > > > | | > > > | Ethernet | 14 octets > > > | Header | > > > | +---------------+ > > > | | > > > +---------------+---------------+ > > > | Optional Control Word | 4 octets > > > +-------------------------------+ > > > | PW label | 4 octets > > > +-------------------------------+ > > > | Server MPLS Tunnel Label(s) | n*4 octets (four octets per lab= el > > > +-------------------------------+ > > > > > > and a type IANA-TBD PW would have: > > > > > > +-------------------------------+ > > > | Client | > > > | Network Layer | > > > | packet | n octets > > > | | > > > +-------------------------------+ > > > | EtherType | 2 octets > > > +---------------+---------------+ > > > | Optional Control Word | 4 octets > > > +-------------------------------+ > > > | PW label | 4 octets > > > +-------------------------------+ > > > | Server MPLS Tunnel Label(s) | n*4 octets (four octets per lab= el > > > +-------------------------------+ > > > > > > I know that this has been discussed and I'm not sure why there are > > > such objections to offering such an option. I do know of hardware > > > that could handle this today, but I don't doubt that there is hardware > > > that could not handle it. Going forward if the more efficient > > > encapaulation is the preferred one, then new hardware will support it. > > > > > > Curtis > > > > > > > > > ------- Forwarded Message (trimmed) > > > > > > 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 : Packet Pseudowire Encapsulation over an MPLS PSN > > > Author(s) : Stewart Bryant > > > Luca Martini > > > George Swallow > > > Andy Malis > > > Filename : draft-ietf-pwe3-packet-pw-01.txt > > > Pages : 14 > > > Date : 2011-07-08 > > > > > > 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. > > > > > > ------- End of Forwarded Message > _______________________________________________ > 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 curtis@occnc.com Thu Jul 14 11:38:26 2011 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 AECDA21F85C5 for ; Thu, 14 Jul 2011 11:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZn9PT53FHtg for ; Thu, 14 Jul 2011 11:38:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF9AE21F85A0 for ; Thu, 14 Jul 2011 11:38:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6EIc7fB051391; Thu, 14 Jul 2011 14:38:07 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141838.p6EIc7fB051391@harbor.orleans.occnc.com> To: Ping Pan From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Jul 2011 06:38:25 PDT." Date: Thu, 14 Jul 2011 14:38:07 -0400 Sender: curtis@occnc.com Cc: "ppan@infinera.com" , "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 18:38:26 -0000 In message Ping Pan writes: > > On Thu, Jul 14, 2011 at 5:44 AM, Curtis Villamizar wrote: > > > > > In message < > > F73A3CB31E8BE34FA1BBE3C8F0CB2AE201002B78@SZXEML502-MBS.china.huawei.com> > > Mach Chen writes: > > > > > > Hi, > > > > > > We submitted an update for the explicit PW to PSN binding draft( > > > http://tools.ietf.org/id/draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > ), which is mainly based on the comments received during the > > > polling. We'd appreciate that you could review the draft and give your > > > comments! > > > > > > Many thanks, > > > Mach > > > > > > Mach, > > > > This draft has more information but it has the same problem I pointed > > out in the -02 version. > > > > In this version, we have explicitly made changes on all the issues > being brought up since last time, specifically, in signaling MHOP > PW's, and passing information on mapping PW's to co-routed LSP's. The > consideration for signaling Tunnel vs. LSP has also been considered in > Section 2.1.1. > > The idea is to enable a PE informing anther PE on PW-LSP mapping in > terms of: > > 1. if they are co-routed > 2. if the mapping is mandatory or requires further negotiation > 3. the identification of the underlying LSP's, (could be a tunnel or > an explicit LSP) > > > The LSP is identified, not the tunnel. The tunnel should be > > identified. In a make-before-break reroute the tunnel remains > > constant but the LSP changes. > > > > When an LSP reroutes for whatever reason, it may be carrying a large > > number of PW. After the make-before-break reroute completes, the old > > LSP no longer exists. It should not be necessary to resignal the PW > > to reroute the LSP. With the text you have, using the LSP numbers, > > that reroute of all the carried PW would be necessary. > > > > If reroute is a frequent event in a network, the operator can use > T-flag (Section 2.1) to negotiate LSP's on TunnelID only. I understand the T-bit. I think you should get rid of the T=0 case. > > There is only one active LSP for any given tunnel. How the active LSP > > is identified, relative to any other LSP is out of scope for this > > document. There may be a working and protect or a working and protect > > and new working and a new protect during a make-before-break > > transition. The IP traffic on an LSP and all LSP carried by a > > hierarchical LSP automatically move during a make-before-break > > reroute. The PW should also move without any additional and totally > > unecessare signaling. > > > > In case of FRR, traffic is only going over ONE tunnel at any give > time, may that be active or protection. So there is no need to > identify active vs. protection for the purpose of PW-LSP binding at > negotiation time. > > Please elaborate your question. In FRR the PLR and merge need not be at the ingress or egress. The indication the FRR protection has occurred is the Local protection in use bit is set [RFC3209]. For FRR neither the tunnel or LSP change during the protection in use state. The IGP will at some point (slight flooding delay) propogate a change in topology (the link or FA down) to the ingress. A new working LSP is created. Usually all the facilities LSPs needed are already available and so the new LSP comes up with Local protection available bit set and Local protection in use bit clear. The protected LSP is preferred and that triggers the switch. During all this time the tunnel ID does not change but the LSP_ID changes. Identifying the LSP is harmful in the FRR case. Every PW carried by the old LSP has to be resignaled before the new LSP is put into use. Currently this is not the case. In the case of GMPLS path protection a different LSP is used when protection is in use. It would not be a good idea to require the PW to be resignaled before protection takes effect. Identifying the LSP is even more harmful in the GMPLS protection case. The large number of PW carried by the LSP have to be resignaled before the LSP protection takes effect. > Thanks! > > Ping > > > > Curtis > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > To: Mach Chen > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; Wayne > > > > Cao(wei) > > > > Subject: New Version Notification for > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > has been > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > repository. > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > Revision: 03 > > > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > > > mapping > > > > Creation date: 2011-06-28 > > > > WG ID: Individual Submission > > > > Number of pages: 16 > > > > > > > > Abstract: > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > unidirectional PWs each carried over a unidirectional LSP. Each end > > > > point of a PW or segment of multi-segment PW (MS-PW) independently > > > > selects the LSP to use to carry the PW for which it is the head end. > > > > > > > > Some transport services may require that bidirectional PW traffic > > > > follows the same paths through the network in both directions. > > > > Therefore, PWs may be required to use LSP with congruent paths. > > > > Bidirectional LSPs or co-routed associated unidirectional LSPs allow > > > > this service to be provided. > > > > > > > > This document specifies an optional extension to LDP that allows > > both > > > > ends of a PW (or segment of a MS-PW) to select and bind to the same > > > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat From curtis@occnc.com Thu Jul 14 11:54:31 2011 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 AB4DB21F8B7A for ; Thu, 14 Jul 2011 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpS6MMSc4+CC for ; Thu, 14 Jul 2011 11:54:31 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id AE3D821F8B75 for ; Thu, 14 Jul 2011 11:54:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6EIsPsr052084; Thu, 14 Jul 2011 14:54:25 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141854.p6EIsPsr052084@harbor.orleans.occnc.com> To: "Andrew G. Malis" From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Jul 2011 11:13:39 EDT." Date: Thu, 14 Jul 2011 14:54:25 -0400 Sender: curtis@occnc.com Cc: stbryant@cisco.com, pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-packet-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 18:54:31 -0000 In message "Andrew G. Malis" writes: > > Curtis, > > This is the approach that we proposed way back in the -00 version of > our individual draft. We got a lot of flack from HW vendors that they > couldn't implement it on current chipsets. > > Cheers, > Andy Andy, That is the point of making it optional. Rather than taking a limitation of a subset of current chips and carrying an inefficiency forever. The default behavior is what most chips can do today. Some chips can't do any MPLS and some can't do any PW. Some low end Ethernet chips of a decade ago couldn't even do IPv4. We can't limit IETF work forever based on low end chips of the past. If we did we would never have moved forward with MPLS in the late 1990s. Curtis > On Thu, Jul 14, 2011 at 10:46 AM, Curtis Villamizar wrote: > > > > Stewart, > > > > If the point is to carry Etherent, we use RFC4448.  If the purpose is > > to carry IP, ICMP and ISIS (probably the only non-IP traffic anyone > > cares about today) across a point to point PW, the we only need the > > EtherType.  There is no purpose to the layer-2 unicast, multicast, or > > broadcat address on a point to point link.  There is no purpose to any > > layer-2 address on a point to point link that is not doing layer-2 > > switching.  ISIS is never forwarded.  Any ISIS traffic is delivered > > directly to the other end of the point to point link. > > > > The purpose of a packet PW is a layer-3 PW.  Both ends have to be able > > to understand the layer-3 protocol that corresponds to the EtherType. > > The L2 addressing in this cases adds nothing, except backwards > > compatibility with old silicon.  BTW- ISIS is defined over GFP with no > > MAC addresses so it should work over PW with no MAC addresses. > > > > Curtis > > > > > > In message <4E1EF066.9060605@cisco.com> > > Stewart Bryant writes: > >> > >> Curtis > >> > >> One concern that I have is with the need to "reconstruct" > >> the MAC addresses. For example I understand that > >> ISIS when running over a pt-pt Ethernet still sends > >> some packets with the multicast destination addresses. > >> > >> As soon as we compress the Ethernet header we have to > >> understand the protocols we are carrying. If we leave them > >> untouched we can punt the problem to the specification > >> of the protocols that are being carried. > >> > >> - Stewart > >> > >> > >> > >> On 14/07/2011 13:59, Curtis Villamizar wrote: > >> > Authors, > >> > > >> > I still don't like the idean of carrying a full Ethernet header with > >> > fixed 12 bytes of PacketPWEthA PacketPWEthB when really all that is > >> > needed it the Ethertype. > >> > > >> > I would like to see this format, along with the PW type 5 for Ethernet > >> > Raw Mode, used for backwards compatibility for the purpose of > >> > supporting old hardware only.  This can then be a fallback for an LSR > >> > that cannot support just putting the EtherType above (in the PW sense, > >> > below in the MPLS sense) the optional control word. > >> > > >> > So a type 5 PW would have: > >> > > >> >     +-------------------------------+ > >> >     |            Client             | > >> >     |          Network Layer        | > >> >     |            packet             |  n octets > >> >     |                               | > >> >     +-------------------------------+ > >> >     |                               | > >> >     |          Ethernet             | 14 octets > >> >     |           Header              | > >> >     |               +---------------+ > >> >     |               | > >> >     +---------------+---------------+ > >> >     |    Optional Control Word      |  4 octets > >> >     +-------------------------------+ > >> >     |          PW label             |  4 octets > >> >     +-------------------------------+ > >> >     |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label > >> >     +-------------------------------+ > >> > > >> > and a type IANA-TBD PW would have: > >> > > >> >     +-------------------------------+ > >> >     |            Client             | > >> >     |          Network Layer        | > >> >     |            packet             |  n octets > >> >     |                               | > >> >     +-------------------------------+ > >> >     |  EtherType    |                  2 octets > >> >     +---------------+---------------+ > >> >     |    Optional Control Word      |  4 octets > >> >     +-------------------------------+ > >> >     |          PW label             |  4 octets > >> >     +-------------------------------+ > >> >     |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label > >> >     +-------------------------------+ > >> > > >> > I know that this has been discussed and I'm not sure why there are > >> > such objections to offering such an option.  I do know of hardware > >> > that could handle this today, but I don't doubt that there is hardware > >> > that could not handle it.  Going forward if the more efficient > >> > encapaulation is the preferred one, then new hardware will support it. > >> > > >> > Curtis > >> > > >> > > >> > ------- Forwarded Message (trimmed) > >> > > >> > 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           : Packet Pseudowire Encapsulation over an MPLS PSN > >> >     Author(s)       : Stewart Bryant > >> >                            Luca Martini > >> >                            George Swallow > >> >                            Andy Malis > >> >     Filename        : draft-ietf-pwe3-packet-pw-01.txt > >> >     Pages           : 14 > >> >     Date            : 2011-07-08 > >> > > >> >     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. > >> > > >> > ------- End of Forwarded Message > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 From ping@pingpan.org Thu Jul 14 13:59:43 2011 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 4856B11E80D7 for ; Thu, 14 Jul 2011 13:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojMe4EUlu5j2 for ; Thu, 14 Jul 2011 13:59:42 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with SMTP id A0FE411E80CE for ; Thu, 14 Jul 2011 13:59:41 -0700 (PDT) Received: from mail-yi0-f47.google.com ([209.85.218.47]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTh9YvLDUCgQMbmOhbZ9Tb3qxPOT0iiSq@postini.com; Thu, 14 Jul 2011 13:59:41 PDT Received: by yib18 with SMTP id 18so320903yib.20 for ; Thu, 14 Jul 2011 13:59:40 -0700 (PDT) Received: by 10.236.182.36 with SMTP id n24mr96055yhm.513.1310677180194; Thu, 14 Jul 2011 13:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Thu, 14 Jul 2011 13:59:00 -0700 (PDT) In-Reply-To: <201107141838.p6EIc7fB051391@harbor.orleans.occnc.com> References: <201107141838.p6EIc7fB051391@harbor.orleans.occnc.com> From: Ping Pan Date: Thu, 14 Jul 2011 13:59:00 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf30563a01bd9fd504a80dcfa2 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-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: Thu, 14 Jul 2011 20:59:43 -0000 --20cf30563a01bd9fd504a80dcfa2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 14, 2011 at 11:38 AM, Curtis Villamizar wrote: > > > > The LSP is identified, not the tunnel. The tunnel should be > > > identified. In a make-before-break reroute the tunnel remains > > > constant but the LSP changes. > > > > > > When an LSP reroutes for whatever reason, it may be carrying a large > > > number of PW. After the make-before-break reroute completes, the old > > > LSP no longer exists. It should not be necessary to resignal the PW > > > to reroute the LSP. With the text you have, using the LSP numbers, > > > that reroute of all the carried PW would be necessary. > > > > > > > If reroute is a frequent event in a network, the operator can use > > T-flag (Section 2.1) to negotiate LSP's on TunnelID only. > > I understand the T-bit. I think you should get rid of the T=0 case. > > Curtis, Actually, we have checked with some customers. Some don't subscribe the notion that they will change the LSP from the headend, and want to have the explicit control on binding PW's to a fixed LSP. This is why we use a bit. > > There is only one active LSP for any given tunnel. How the active LSP > > > is identified, relative to any other LSP is out of scope for this > > > document. There may be a working and protect or a working and protect > > > and new working and a new protect during a make-before-break > > > transition. The IP traffic on an LSP and all LSP carried by a > > > hierarchical LSP automatically move during a make-before-break > > > reroute. The PW should also move without any additional and totally > > > unecessare signaling. > > > > > > > In case of FRR, traffic is only going over ONE tunnel at any give > > time, may that be active or protection. So there is no need to > > identify active vs. protection for the purpose of PW-LSP binding at > > negotiation time. > > > > Please elaborate your question. > > In FRR the PLR and merge need not be at the ingress or egress. The > indication the FRR protection has occurred is the Local protection in > use bit is set [RFC3209]. For FRR neither the tunnel or LSP change > during the protection in use state. The IGP will at some point > (slight flooding delay) propogate a change in topology (the link or FA > down) to the ingress. A new working LSP is created. Usually all the > facilities LSPs needed are already available and so the new LSP comes > up with Local protection available bit set and Local protection in use > bit clear. The protected LSP is preferred and that triggers the > switch. During all this time the tunnel ID does not change but the > LSP_ID changes. > > Identifying the LSP is harmful in the FRR case. Every PW carried by the > old LSP has to be resignaled before the new LSP is put into use. > Currently this is not the case. > > In the case of GMPLS path protection a different LSP is used when > protection is in use. It would not be a good idea to require the PW > to be resignaled before protection takes effect. > > Identifying the LSP is even more harmful in the GMPLS protection case. > The large number of PW carried by the LSP have to be resignaled before > the LSP protection takes effect. > > Wait. First, if a network is in constant use of FRR, we have more serious issues. In which case, the PW-LSP binding overhead should be last thing the operators care about. :-) In transport networks, especially that of GMPLS-enabled optical core, the network is relatively stable. The configuration needs to be accurate, but does not need to screaming fast. However, you are right, in case of FRR, if a LSP is rerouted at the headend, the PW-LSP binding should be seamless. This is why we have defined the T-bit to signal Tunnel-id only. As for MPLS path protection case, T-bit is also sufficient. The rule of thrum is: the protecting connections in FRR use the same Session Object, same source IP, but different LSP-id. The protecting connections in Path Protection use the same Session Object, same LSP-id but different source IP address. The way we define T-bit is that, map a PW to a LSP's tunnel (a.k.a. Session) only. It works! ;-) Thanks! Ping > Thanks! > > > > Ping > > > > > > > Curtis > > > > > > > > > > > -----Original Message----- > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > > To: Mach Chen > > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; > Wayne > > > > > Cao(wei) > > > > > Subject: New Version Notification for > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > > > A new version of I-D, > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > has been > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > > repository. > > > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > > Revision: 03 > > > > > Title: LDP extensions for Explicit Pseudowire to transport > LSP > > > > > mapping > > > > > Creation date: 2011-06-28 > > > > > WG ID: Individual Submission > > > > > Number of pages: 16 > > > > > > > > > > Abstract: > > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > > unidirectional PWs each carried over a unidirectional LSP. Each > end > > > > > point of a PW or segment of multi-segment PW (MS-PW) > independently > > > > > selects the LSP to use to carry the PW for which it is the head > end. > > > > > > > > > > Some transport services may require that bidirectional PW > traffic > > > > > follows the same paths through the network in both directions. > > > > > Therefore, PWs may be required to use LSP with congruent paths. > > > > > Bidirectional LSPs or co-routed associated unidirectional LSPs > allow > > > > > this service to be provided. > > > > > > > > > > This document specifies an optional extension to LDP that allows > > > both > > > > > ends of a PW (or segment of a MS-PW) to select and bind to the > same > > > > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --20cf30563a01bd9fd504a80dcfa2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 14, 2011 at 11:38 AM, Curtis Villami= zar <curtis@occnc.= com> wrote:

> > The LSP is identified, not the tunnel.= =A0The tunnel should be
> > identified. =A0In a make-before-break reroute the tunnel remains<= br> > > constant but the LSP changes.
> >
> > When an LSP reroutes for whatever reason, it may be carrying a la= rge
> > number of PW. =A0After the make-before-break reroute completes, t= he old
> > LSP no longer exists. =A0It should not be necessary to resignal t= he PW
> > to reroute the LSP. =A0With the text you have, using the LSP numb= ers,
> > that reroute of all the carried PW would be necessary.
> >
>
> If reroute is a frequent event in a network, the operator can use
> T-flag (Section 2.1) to negotiate LSP's on TunnelID only.

I understand the T-bit. =A0I think you should get rid of the T= =3D0 case.


Curtis,
<= div>
Actually, we have checked with some customers. Some don&= #39;t subscribe the notion that they will change the LSP from the headend, = and want to have the explicit control on binding PW's to a fixed LSP. T= his is why we use a bit.

> > = There is only one active LSP for any given tunnel. =A0How the active LSP > > is identified, relative to any other LSP is out of scope for this=
> > document. =A0There may be a working and protect or a working and = protect
> > and new working and a new protect during a make-before-break
> > transition. =A0The IP traffic on an LSP and all LSP carried by a<= br> > > hierarchical LSP automatically move during a make-before-break > > reroute. =A0The PW should also move without any additional and to= tally
> > unecessare signaling.
> >
>
> In case of FRR, traffic is only going over ONE tunnel at any give
> time, may that be active or protection. So there is no need to
> identify active vs. =A0protection for the purpose of PW-LSP binding at=
> negotiation time.
>
> Please elaborate your question.

In FRR the PLR and merge need not be at the ingress or egress. =A0The=
indication the FRR protection has occurred is the Local protection in
use bit is set [RFC3209]. =A0For FRR neither the tunnel or LSP change
during the protection in use state. =A0The IGP will at some point
(slight flooding delay) propogate a change in topology (the link or FA
down) to the ingress. =A0A new working LSP is created. =A0Usually all the facilities LSPs needed are already available and so the new LSP comes
up with Local protection available bit set and Local protection in use
bit clear. =A0The protected LSP is preferred and that triggers the
switch. =A0During all this time the tunnel ID does not change but the
LSP_ID changes.

Identifying the LSP is har= mful in the FRR case. =A0Every PW carried by the
old LSP has to be resignaled before the new LSP is put into use.
Currently this is not the case.

In the case of GMPLS path protection a different LSP is used when
protection is in use. =A0It would not be a good idea to require the PW
to be resignaled before protection takes effect.

Identifying the LSP is even more harmful in the GMPLS protection case.
The large number of PW carried by the LSP have to be resignaled before
the LSP protection takes effect.


Wait. First, if a network is in constant use of FRR, we have more s= erious issues. In which case, the PW-LSP binding overhead should be last th= ing the operators =A0care about. :-)

In transport networks, especially that of GMPLS-enabled= optical core, the network is relatively stable. The configuration needs to= be accurate, but does not need to screaming fast.

However, you are right, in case of FRR, if a LSP is rerouted at the he= adend, the PW-LSP binding should be seamless. This is why we have defined t= he T-bit to signal Tunnel-id only.=A0

As for MPLS = path protection case, T-bit is also sufficient. The rule of thrum is: the p= rotecting connections in FRR use the same Session Object, same source IP, b= ut different LSP-id. The protecting connections in Path Protection use the = same Session Object, same LSP-id but different source IP address. The way w= e define T-bit is that, map a PW to a LSP's tunnel (a.k.a. Session) onl= y. It works! ;-)

Thanks!

Ping

> Thanks!
>
> Ping
>
>
> > =A0Curtis
> >
> >
> > > > -----Original Message-----
> > > > From: inter= net-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Tuesday, June 28, 2011 5:49 PM
> > > > To: Mach Chen
> > > > Cc: ppan@infinera.= com; attila.takacs@ericss= on.com; Mach Chen; Wayne
> > > > Cao(wei)
> > > > Subject: New Version Notification for
> > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
> > > >
> > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bi= dir-lsp-03.txt
> > has been
> > > > successfully submitted by Mach(Guoyi) Chen and posted t= o the IETF
> > repository.
> > > >
> > > > Filename: =A0 =A0draft-cao-pwe3-mpls-tp-pw-over-bidir-l= sp
> > > > Revision: =A0 =A003
> > > > Title: =A0 =A0 =A0 LDP extensions for Explicit Pseudowi= re to transport LSP
> > > > mapping
> > > > Creation date: =A0 =A0 =A0 2011-06-28
> > > > WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submissio= n
> > > > Number of pages: 16
> > > >
> > > > Abstract:
> > > > =A0 =A0A bidirectional Pseudowire (PW) service currentl= y uses two
> > > > =A0 =A0unidirectional PWs each carried over a unidirect= ional LSP. =A0Each end
> > > > =A0 =A0point of a PW or segment of multi-segment PW (MS= -PW) independently
> > > > =A0 =A0selects the LSP to use to carry the PW for which= it is the head end.
> > > >
> > > > =A0 =A0Some transport services may require that bidirec= tional PW traffic
> > > > =A0 =A0follows the same paths through the network in bo= th directions.
> > > > =A0 =A0Therefore, PWs may be required to use LSP with c= ongruent paths.
> > > > =A0 =A0Bidirectional LSPs or co-routed associated unidi= rectional LSPs allow
> > > > =A0 =A0this service to be provided.
> > > >
> > > > =A0 =A0This document specifies an optional extension to= LDP that allows
> > both
> > > > =A0 =A0ends of a PW (or segment of a MS-PW) to select a= nd bind to the same
> > > > =A0 =A0bidirectional LSP (or co-routed unidirectional L= SPs).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat

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

--20cf30563a01bd9fd504a80dcfa2-- From curtis@occnc.com Thu Jul 14 14:31:30 2011 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 34E8221F89A3 for ; Thu, 14 Jul 2011 14:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeLbWEGXZ9Sq for ; Thu, 14 Jul 2011 14:31:29 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2121F899F for ; Thu, 14 Jul 2011 14:31:29 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6ELVSSe056072; Thu, 14 Jul 2011 17:31:28 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107142131.p6ELVSSe056072@harbor.orleans.occnc.com> To: Ping Pan From: Curtis Villamizar In-reply-to: Your message of "Thu, 14 Jul 2011 13:59:00 PDT." Date: Thu, 14 Jul 2011 17:31:28 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 21:31:30 -0000 In message Ping Pan writes: > > --20cf30563a01bd9fd504a80dcfa2 > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Jul 14, 2011 at 11:38 AM, Curtis Villamizar wrote: > > > > > > > The LSP is identified, not the tunnel. The tunnel should be > > > > identified. In a make-before-break reroute the tunnel remains > > > > constant but the LSP changes. > > > > > > > > When an LSP reroutes for whatever reason, it may be carrying a large > > > > number of PW. After the make-before-break reroute completes, the old > > > > LSP no longer exists. It should not be necessary to resignal the PW > > > > to reroute the LSP. With the text you have, using the LSP numbers, > > > > that reroute of all the carried PW would be necessary. > > > > > > > > > > If reroute is a frequent event in a network, the operator can use > > > T-flag (Section 2.1) to negotiate LSP's on TunnelID only. > > > > I understand the T-bit. I think you should get rid of the T=0 case. > > > > > Curtis, > > Actually, we have checked with some customers. Some don't subscribe the > notion that they will change the LSP from the headend, and want to have the > explicit control on binding PW's to a fixed LSP. This is why we use a bit. Unless you are talking about statis LSPs, they always "change at the headend". I'm not sure which customers you are talking about but we can take that offline. > > > There is only one active LSP for any given tunnel. How the active LSP > > > > is identified, relative to any other LSP is out of scope for this > > > > document. There may be a working and protect or a working and protect > > > > and new working and a new protect during a make-before-break > > > > transition. The IP traffic on an LSP and all LSP carried by a > > > > hierarchical LSP automatically move during a make-before-break > > > > reroute. The PW should also move without any additional and totally > > > > unecessare signaling. > > > > > > > > > > In case of FRR, traffic is only going over ONE tunnel at any give > > > time, may that be active or protection. So there is no need to > > > identify active vs. protection for the purpose of PW-LSP binding at > > > negotiation time. > > > > > > Please elaborate your question. > > > > In FRR the PLR and merge need not be at the ingress or egress. The > > indication the FRR protection has occurred is the Local protection in > > use bit is set [RFC3209]. For FRR neither the tunnel or LSP change > > during the protection in use state. The IGP will at some point > > (slight flooding delay) propogate a change in topology (the link or FA > > down) to the ingress. A new working LSP is created. Usually all the > > facilities LSPs needed are already available and so the new LSP comes > > up with Local protection available bit set and Local protection in use > > bit clear. The protected LSP is preferred and that triggers the > > switch. During all this time the tunnel ID does not change but the > > LSP_ID changes. > > > > Identifying the LSP is harmful in the FRR case. Every PW carried by the > > old LSP has to be resignaled before the new LSP is put into use. > > Currently this is not the case. > > > > In the case of GMPLS path protection a different LSP is used when > > protection is in use. It would not be a good idea to require the PW > > to be resignaled before protection takes effect. > > > > Identifying the LSP is even more harmful in the GMPLS protection case. > > The large number of PW carried by the LSP have to be resignaled before > > the LSP protection takes effect. > > > > > Wait. First, if a network is in constant use of FRR, we have more serious > issues. In which case, the PW-LSP binding overhead should be last thing the > operators care about. :-) > > In transport networks, especially that of GMPLS-enabled optical core, the > network is relatively stable. The configuration needs to be accurate, but > does not need to screaming fast. This is not about "constant use of FRR" it is about a single event in which more than one fault occurs. This happens quite often. There may be a large number of LSP affected and a much larger number of PW affected. The statement "In transport networks, especially that of GMPLS-enabled optical core, the network is relatively stable" is really nonsense in that context. Hurricane Katrina was the classis "network outage" but floods, earthquakes, bridge collapses, train wrecks taking out fiber on both side of tracks, and even errant backhoe operators removing the wrong unused gas lines, are all among the more dramatic causes, not to mention the many mundane outages of the same sort. Transport is no more reliable (due to lack of restoration in transport gear with no control place or slow restoration in some gear, it is generally provably less relaibel) than the same network with protection and restoration in the IP/MPLS layers. Anyway, it doesn't matter. See below. > However, you are right, in case of FRR, if a LSP is rerouted at the headend, > the PW-LSP binding should be seamless. This is why we have defined the T-bit > to signal Tunnel-id only. > > As for MPLS path protection case, T-bit is also sufficient. The rule of > thrum is: the protecting connections in FRR use the same Session Object, > same source IP, but different LSP-id. The protecting connections in Path > Protection use the same Session Object, same LSP-id but different source IP > address. The way we define T-bit is that, map a PW to a LSP's tunnel (a.k.a. > Session) only. It works! ;-) I feel that the T=0 is a misfeature but as long as the T=1 is there, it becomes a "let the market decide" situation. > Thanks! > > Ping I'd like to point out another topic on a separate thread. Curtis [ trimmed original draft announcement. ] From mach.chen@huawei.com Fri Jul 15 01:55:07 2011 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 D47E821F8828 for ; Fri, 15 Jul 2011 01:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obL0paW3-v1R for ; Fri, 15 Jul 2011 01:55:07 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 158DF21F8794 for ; Fri, 15 Jul 2011 01:55:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOD002SJA1U0L@szxga04-in.huawei.com> for pwe3@ietf.org; Fri, 15 Jul 2011 16:53:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOD00ER1A1SXS@szxga04-in.huawei.com> for pwe3@ietf.org; Fri, 15 Jul 2011 16:53:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACG49446; Fri, 15 Jul 2011 16:53:53 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 16:53:46 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.35]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Fri, 15 Jul 2011 16:53:48 +0800 Date: Fri, 15 Jul 2011 08:53:47 +0000 From: Mach Chen In-reply-to: <201107141244.p6ECit8l037498@harbor.orleans.occnc.com> X-Originating-IP: [10.110.98.37] To: "curtis@occnc.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt Thread-index: AQHMQiPaGSHl1xn1qk2M0xKdlB3eo5TtA6kQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: "Your message of Tue, 05 Jul 2011 01:41:02 -0000." <201107141244.p6ECit8l037498@harbor.orleans.occnc.com> Cc: "ppan@infinera.com" , "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 08:55:07 -0000 Hi Curtis, Thanks for your comments! As Ping said, we have changed the draft to include tunnel option and make it as the default, and at the same time, keeps the LSP option (OPTINAL) hence to give the capability for explicit binding/moving a PW to a specific LSP when needed. Best regards, Mach > > Mach, > > This draft has more information but it has the same problem I pointed > out in the -02 version. > > The LSP is identified, not the tunnel. The tunnel should be > identified. In a make-before-break reroute the tunnel remains > constant but the LSP changes. > > When an LSP reroutes for whatever reason, it may be carrying a large > number of PW. After the make-before-break reroute completes, the old > LSP no longer exists. It should not be necessary to resignal the PW > to reroute the LSP. With the text you have, using the LSP numbers, > that reroute of all the carried PW would be necessary. > > There is only one active LSP for any given tunnel. How the active LSP > is identified, relative to any other LSP is out of scope for this > document. There may be a working and protect or a working and protect > and new working and a new protect during a make-before-break > transition. The IP traffic on an LSP and all LSP carried by a > hierarchical LSP automatically move during a make-before-break > reroute. The PW should also move without any additional and totally > unecessare signaling. There may be requirement for doing PW Best regards, Mach > > Curtis > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > To: Mach Chen > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; Wayne > > > Cao(wei) > > > Subject: New Version Notification for > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > been > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > repository. > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > Revision: 03 > > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > > mapping > > > Creation date: 2011-06-28 > > > WG ID: Individual Submission > > > Number of pages: 16 > > > > > > Abstract: > > > A bidirectional Pseudowire (PW) service currently uses two > > > unidirectional PWs each carried over a unidirectional LSP. Each end > > > point of a PW or segment of multi-segment PW (MS-PW) independently > > > selects the LSP to use to carry the PW for which it is the head end. > > > > > > Some transport services may require that bidirectional PW traffic > > > follows the same paths through the network in both directions. > > > Therefore, PWs may be required to use LSP with congruent paths. > > > Bidirectional LSPs or co-routed associated unidirectional LSPs allow > > > this service to be provided. > > > > > > This document specifies an optional extension to LDP that allows both > > > ends of a PW (or segment of a MS-PW) to select and bind to the same > > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 From zhang.fei3@zte.com.cn Fri Jul 15 02:13:41 2011 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 B622021F86A2; Fri, 15 Jul 2011 02:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.219 X-Spam-Level: X-Spam-Status: No, score=-100.219 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZU7a9CGPHXx; Fri, 15 Jul 2011 02:13:41 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2EE21F86A0; Fri, 15 Jul 2011 02:13:39 -0700 (PDT) Received: from [10.30.18.203] by mx5.zte.com.cn with surfront esmtp id 131322203882679; Fri, 15 Jul 2011 17:07:23 +0800 (CST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48642203882679; Fri, 15 Jul 2011 17:10:06 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2203882679; Fri, 15 Jul 2011 16:22:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6F8Mg8O005421; Fri, 15 Jul 2011 16:22:42 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: "pwe3@ietf.org" , MIME-Version: 1.0 X-KeepSent: C7F96C5D:251C819B-482578CE:002B6A4D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 15 Jul 2011 16:22:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-15 16:22:43, Serialize complete at 2011-07-15 16:22:43 Content-Type: multipart/alternative; boundary="=_alternative 002DFF46482578CE_=" X-MAIL: mse01.zte.com.cn p6F8Mg8O005421 Subject: [PWE3] Changes to draft: http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 09:13:41 -0000 This is a multipart message in MIME format. --=_alternative 002DFF46482578CE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCldlIGhhdmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQgYWJvdXQgdGhlIE1QTFMtVFAg UFcgT0FNIGNvbmZpZ3VyYXRpb25zLCANCmJlbG93IGlzIHRoZSBsaW5rOg0KDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25maWctMDUgDQoN CkNvbXBhcmVkIHRvIGxhc3QgdmVyc2lvbiwgd2UgYWRkIG9uZSBzdWJzZWN0aW9uIDcuMS4xIHRv IGFkZHJlc3MgdGhlIA0KYmFja3dhcmQgY29tcGF0aWJpbGl0eSAodGhhbmsgR3JlZ6GiTHVjYSBh bmQgTWF0dGhldyBmb3IgdGhlIGNvbW1lbnRzKS4NCg0KSWYgYm90aCBvZiB0aGUgVC1QRXMgc3Vw cG9ydCB0aGUgQ0MtQ1YtUkRJIGZ1bmN0aW9uLCB0aGUgQkZEIGNvbmZpZ3VyYWl0b24gDQpwcm9k ZWN1cmUgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZDsgb3RoZXJ3aXNlIGlm IGF0IGxlYXN0IG5vdCANCm9mDQoNCnRoZW0gZG8gbm90IHN1cHBvcnQgdGhlIENDLUNWLVJESSBm dW50aW9uLCB0aGUgb2xkIFZDQ1YgQkZEIHdpbGwgYmUgDQpwZXJmb3JtZWQuDQoNCg0KVGhlIG90 aGVyIHJldmlzaW9ucyBhcmUgZWRpdG9yaWFsIGluIG5hdHVyZSwgcGxlYXNlIGNoZWNrIHRoZW0g Zm9yIG1vcmUgDQpkZXRhaWxzLg0KDQoNCkFueSBvdGhlciBjb21tZW50cyBhcmUgd2VsY29tZS4g Oi0pDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg== --=_alternative 002DFF46482578CE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSB1cGRhdGVkIHRoZSBk b2N1bWVudCBhYm91dCB0aGUNCk1QTFMtVFAgUFcgT0FNIGNvbmZpZ3VyYXRpb25zLCBiZWxvdyBp cyB0aGUgbGluazo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLW1wbHMtdHAtcHctb2Ft LWNvbmZpZy0wNQ0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5Db21wYXJlZCB0byBsYXN0IHZlcnNpb24sIHdlIGFkZCBvbmUNCnN1YnNlY3Rpb24gNy4x LjEgdG8gYWRkcmVzcyB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSAodGhhbmsgR3JlZ6GiTHVj YQ0KYW5kIE1hdHRoZXcgZm9yIHRoZSBjb21tZW50cykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBib3RoIG9mIHRoZSBULVBFcyBzdXBwb3J0IHRo ZSBDQy1DVi1SREkNCmZ1bmN0aW9uLCB0aGUgQkZEIGNvbmZpZ3VyYWl0b24gcHJvZGVjdXJlIGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGlzDQphZG9wdGVkOyBvdGhlcndpc2UgaWYgYXQgbGVh c3Qgbm90IG9mPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij50aGVtIGRvIG5vdCBzdXBwb3J0IHRoZSBDQy1DVi1SREkgZnVudGlvbiwNCnRoZSBvbGQgVkND ViBCRkQgd2lsbCBiZSBwZXJmb3JtZWQuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgb3RoZXIgcmV2aXNpb25zIGFyZSBlZGl0b3JpYWwg aW4NCm5hdHVyZSwgcGxlYXNlIGNoZWNrIHRoZW0gZm9yIG1vcmUgZGV0YWlscy48L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFueSBvdGhlciBj b21tZW50cyBhcmUgd2VsY29tZS4gOi0pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCg== --=_alternative 002DFF46482578CE_=-- From liu.guoman@zte.com.cn Fri Jul 15 02:32:43 2011 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 C222F21F8631 for ; Fri, 15 Jul 2011 02:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzRSvbMBd-XP for ; Fri, 15 Jul 2011 02:32:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 47C0F21F875E for ; Fri, 15 Jul 2011 02:32:31 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321397396305; Fri, 15 Jul 2011 17:26:23 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.1397396305; Fri, 15 Jul 2011 15:51:30 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id p6F7pTMm061864 for ; Fri, 15 Jul 2011 15:51:29 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6EAn49t059903 for ; Thu, 14 Jul 2011 18:49:04 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201107150751.p6F7pTMm061864@mse01.zte.com.cn> In-Reply-To: <20110708213001.32754.41193.idtracker@ietfa.amsl.com> To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Thu, 14 Jul 2011 18:49:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-14 18:49:06, Serialize complete at 2011-07-14 18:49:06 Content-Type: multipart/alternative; boundary="=_alternative 003B9723482578CD_=" X-MAIL: mse01.zte.com.cn p6F7pTMm061864 X-MSS: AUDITRELEASE@mse01.zte.com.cn Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 09:32:43 -0000 This is a multipart message in MIME format. --=_alternative 003B9723482578CD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksYXV0aG9ycw0KaSByZXZpZXcgdGhpcyBkcmFmdCB0b2RheS4gaSBoYXZlIGEgZmV3IHF1ZXN0 aW9uIGZvciBzZWN0aW9uIDMuMiBQMk1QIA0KU1MtUFcgVW5kZXJseWluZyBMYXllciAuDQppbiB0 aGUgc2VjdGlvbiwgdGhlcmUgaXMgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggY29udGV4dDoNCiIg ICBBcyBhbiBleGFtcGxlIGFuIGV4aXN0aW5nIFAyTVAgTFNQIG1heSBhdHRhY2ggDQogICBtb3Jl IGxlYXZlcyB0aGFuIHRoZSBvbmVzIGRlZmluZWQgYXMgTGVhZiBQRXMgZm9yIGEgZ2l2ZW4gUDJN UCBQVy4gSXQgDQogICBtYXkgYmUgaW50ZXJlc3RpbmcgdG8gcmV1c2UgaXQgdG8gbWluaW1pemUg bmV3IGNvbmZpZ3VyYXRpb24sIGJ1dCANCiAgIHVzaW5nIHRoaXMgUDJNUCBMU1Agd291bGQgaW1w bHkgbm9uLUxlYWYgUEVzIHJlY2VpdmUgdW53YW50ZWQgDQogICB0cmFmZmljLCBub3QgZGVzdGlu ZWQgdG8gTGVhZiBQRSBhdCB0aGUgc2VydmljZSBsYXllciINCg0KICAgICAgICAgUTE6IGhvdyBk byBub24tbGVhZiBQRXMgaWRlbnRpZnkgd2hpY2ggdHJhZmZpYyBpcyB1bndhbnRlZCANCnRyYWZm aWMgYnkgYSBjb21tb24gcDJtcCBMU1A/DQogICAgICAgICAgZG8gdGhleSBvbmx5IGJlIGJhc2Vk IG9uIHB3IGxhYmVsIHRvIGp1ZGdlIHRoZSB0cmFmZmljPyBpZiBzbywgDQptYXliZSB0aGUgdmFs dWUgb2YgdGhlIHB3IGxhYmVsIGhhdmUgYWxyZWFkeSBiZWVuIGFzc2lnbmVkIGZvciBhbm90aGVy IA0Kd2FudGVkIHRyYWZmaWMsDQogICAgICAgICAgIGhvdyBkbyB0aGUgbm9uLWxlYWZzIFBFcyBp ZGVudGlmeSB3aGljaCB0cmFmZmljIGlzIHVud2FudGVkIG9yIA0Kd2FudGVkIHRyYWZmaWMgZm9y IGl0c2VsZj8NCiAgICAgICAgIFEyOiBpZiBub24tbGVhZiBQRXMga25vdyB0aGlzIHRyYWZmaWMg aXMgdW53YW50ZWQgdHJhZmZpYyAsIGRvIA0KdGhleSBkaXJlY3RseSBhYmFuZG9uIHRoZXNlIHRy YWZmaWM/IGkgdGhpbmsgaXQgbmVjZXNzYXJ5IHRvIGNsYXJpZnkgaXQgaW4gDQp0aGlzIGRyYWZ0 Lg0KIA0KDQp0aGFuayB5b3UhDQoNCg0KQi5SLg0KbGl1DQogDQoNCg0KDQoNCg0KDQoNCkludGVy bmV0LURyYWZ0c0BpZXRmLm9yZyANCreivP7IyzogIHB3ZTMtYm91bmNlc0BpZXRmLm9yZw0KMjAx MS0wNy0wOSAwNTozMA0KDQrK1bz+yMsNCmktZC1hbm5vdW5jZUBpZXRmLm9yZw0Ks63LzQ0KcHdl M0BpZXRmLm9yZw0K1vfM4g0KW1BXRTNdIEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1wd2UzLXAybXAt cHctcmVxdWlyZW1lbnRzLTA0LnR4dA0KDQoNCg0KDQoNCg0KQSBuZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3Jp ZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBQc2V1ZG93aXJlIEVtdWxhdGlv biBFZGdlIHRvIEVkZ2UgV29ya2luZyANCkdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgVGl0bGUg ICAgICAgICA6IFJlcXVpcmVtZW50cyBhbmQgRnJhbWV3b3JrIGZvciBQb2ludC10by1NdWx0aXBv aW50IA0KUHNldWRvd2lyZQ0KICAgIEF1dGhvcihzKSAgICAgOiBHLiBIZXJvbiwgZXQgYWwNCiAg ICBGaWxlbmFtZSAgICAgIDogZHJhZnQtaWV0Zi1wd2UzLXAybXAtcHctcmVxdWlyZW1lbnRzLTA0 LnR4dA0KICAgIFBhZ2VzICAgICAgICAgOiAyMQ0KICAgIERhdGUgICAgICAgICAgOiAyMDExLTA3 LTA4DQogDQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2V0IG9mIHJlcXVpcmVtZW50cyBh bmQgYSBmcmFtZXdvcmsgZm9yIA0KICAgcHJvdmlkaW5nIGEgUG9pbnQtdG8tTXVsdGlwb2ludCBQ c2V1ZG93aXJlIChQVykuIFRoZSByZXF1aXJlbWVudHMgDQogICBpZGVudGlmaWVkIGluIHRoaXMg ZG9jdW1lbnQgYXJlIHJlbGF0ZWQgdG8gYXJjaGl0ZWN0dXJlLCBzaWduYWxpbmcgDQogICBhbmQg bWFpbnRlbmFuY2UgYXNwZWN0cyBvZiBQb2ludC10by1NdWx0aXBvaW50IFBXIG9wZXJhdGlvbi4g VGhleSBhcmUgDQogICBwcm9wb3NlZCBhcyBndWlkZWxpbmVzIGZvciB0aGUgc3RhbmRhcmRpemF0 aW9uIG9mIHN1Y2ggbWVjaGFuaXNtcy4gDQogICBBbW9uZyBvdGhlciBwb3RlbnRpYWwgYXBwbGlj YXRpb25zIFBvaW50LXRvLU11bHRpcG9pbnQgUFdzIFNIT1VMRCBiZSANCiAgIHVzZWQgdG8gb3B0 aW1pemUgdGhlIHN1cHBvcnQgb2YgbXVsdGljYXN0IGxheWVyIDIgc2VydmljZXMgKFZpcnR1YWwg DQogICBQcml2YXRlIExBTiBTZXJ2aWNlIGFuZCBWaXJ0dWFsIFByaXZhdGUgTXVsdGljYXN0IFNl cnZpY2UpIGFzIGRlZmluZWQgDQogICBpbiB0aGUgTGF5ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0 d29yayBXb3JraW5nIEdyb3VwLg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcHdlMy1wMm1w LXB3LXJlcXVpcmVtZW50cy0wNC50eHQNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29t cGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJp ZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50ZXJuZXQtRHJhZnQuDQpmdHA6Ly9hbm9u eW1vdXNAZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXB3ZTMtcDJtcC1w dy1yZXF1aXJlbWVudHMtMDQudHh0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5nIGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMg bWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92 ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJz Lg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 003B9723482578CD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLGF1dGhvcnM8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmkgcmV2aWV3IHRoaXMgZHJhZnQgdG9k YXkuIGkgaGF2ZSBhDQpmZXcgcXVlc3Rpb24gZm9yIHNlY3Rpb24gMy4yIDwvZm9udD48Zm9udCBz aXplPTM+PHR0PlAyTVAgU1MtUFcgVW5kZXJseWluZw0KTGF5ZXIgLjwvdHQ+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz48dHQ+aW4gdGhlIHNlY3Rpb24sIHRoZXJlIGlzIHRoZSBmb2xsb3dpbmcg cGFyYWdyYXBoIGNvbnRleHQ6PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4mcXVv dDsgJm5ic3A7PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPXJlZD48dHQ+DQpBcyBhbiBl eGFtcGxlIGFuIGV4aXN0aW5nIFAyTVAgTFNQIG1heSBhdHRhY2ggPGJyPg0KICZuYnNwOyBtb3Jl IGxlYXZlcyB0aGFuIHRoZSBvbmVzIGRlZmluZWQgYXMgTGVhZiBQRXMgZm9yIGEgZ2l2ZW4gUDJN UA0KUFcuIEl0IDxicj4NCiAmbmJzcDsgbWF5IGJlIGludGVyZXN0aW5nIHRvIHJldXNlIGl0IHRv IG1pbmltaXplIG5ldyBjb25maWd1cmF0aW9uLCBidXQNCjxicj4NCiAmbmJzcDsgdXNpbmcgdGhp cyBQMk1QIExTUCB3b3VsZCBpbXBseSBub24tTGVhZiBQRXMgcmVjZWl2ZSB1bndhbnRlZCA8YnI+ DQogJm5ic3A7IHRyYWZmaWMsIG5vdCBkZXN0aW5lZCB0byBMZWFmIFBFIGF0IHRoZSBzZXJ2aWNl IGxheWVyPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPjx0dD4mcXVvdDs8L3R0PjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1ExOg0KaG93IGRvIG5vbi1sZWFmIFBFcyBpZGVudGlmeSB3aGljaCB0 cmFmZmljIGlzIHVud2FudGVkIHRyYWZmaWMgYnkgYSBjb21tb24NCnAybXAgTFNQPzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBkbw0KdGhleSBvbmx5IGJlIGJhc2VkIG9uIHB3IGxhYmVsIHRvIGp1ZGdl IHRoZSB0cmFmZmljPyBpZiBzbywgbWF5YmUgdGhlIHZhbHVlDQpvZiB0aGUgcHcgbGFiZWwgaGF2 ZSBhbHJlYWR5IGJlZW4gYXNzaWduZWQgZm9yIGFub3RoZXIgd2FudGVkIHRyYWZmaWMsPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hvdw0KZG8gdGhlIG5vbi1sZWFmcyBQRXMgaWRlbnRpZnkg d2hpY2ggdHJhZmZpYyBpcyB1bndhbnRlZCBvciB3YW50ZWQgdHJhZmZpYw0KZm9yIGl0c2VsZj88 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtRMjoNCmlmIG5vbi1sZWFmIFBFcyBrbm93IHRoaXMgdHJhZmZp YyBpcyB1bndhbnRlZCB0cmFmZmljICwgZG8gdGhleSBkaXJlY3RseQ0KYWJhbmRvbiB0aGVzZSB0 cmFmZmljPyBpIHRoaW5rIGl0IG5lY2Vzc2FyeSB0byBjbGFyaWZ5IGl0IGluIHRoaXMgZHJhZnQu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj50aGFuayB5b3UhPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CLlIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5saXU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPC9mb250 Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5JbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cHdlMy1ib3VuY2VzQGlldGYub3JnPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDctMDkgMDU6MzA8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ aS1kLWFubm91bmNlQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wd2UzQGlldGYub3JnPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5bUFdFM10gSS1EIEFDVElPTjpkcmFmdC1pZXRmLXB3ZTMtcDJtcC1w dy1yZXF1aXJlbWVudHMtMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5BIG5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZQ0KSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFBzZXVkb3dpcmUgRW11bGF0aW9uIEVkZ2UgdG8g RWRnZSBXb3JraW5nDQpHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw O1RpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFJlcXVpcmVtZW50cyBhbmQgRnJh bWV3b3JrDQpmb3IgUG9pbnQtdG8tTXVsdGlwb2ludCBQc2V1ZG93aXJlPGJyPg0KICZuYnNwOyAm bmJzcDtBdXRob3IocykgJm5ic3A7ICZuYnNwOyA6IEcuIEhlcm9uLCBldCBhbDxicj4NCiAmbmJz cDsgJm5ic3A7RmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtcHdlMy1w Mm1wLXB3LXJlcXVpcmVtZW50cy0wNC50eHQ8YnI+DQogJm5ic3A7ICZuYnNwO1BhZ2VzICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIxPGJyPg0KICZuYnNwOyAmbmJzcDtEYXRlICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTEtMDctMDg8YnI+DQogJm5ic3A7ICZu YnNwOzxicj4NCiAmbmJzcDsgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNldCBvZiByZXF1aXJl bWVudHMgYW5kIGEgZnJhbWV3b3JrIGZvcg0KPGJyPg0KICZuYnNwOyBwcm92aWRpbmcgYSBQb2lu dC10by1NdWx0aXBvaW50IFBzZXVkb3dpcmUgKFBXKS4gVGhlIHJlcXVpcmVtZW50cw0KPGJyPg0K ICZuYnNwOyBpZGVudGlmaWVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIHJlbGF0ZWQgdG8gYXJjaGl0 ZWN0dXJlLCBzaWduYWxpbmcNCjxicj4NCiAmbmJzcDsgYW5kIG1haW50ZW5hbmNlIGFzcGVjdHMg b2YgUG9pbnQtdG8tTXVsdGlwb2ludCBQVyBvcGVyYXRpb24uIFRoZXkNCmFyZSA8YnI+DQogJm5i c3A7IHByb3Bvc2VkIGFzIGd1aWRlbGluZXMgZm9yIHRoZSBzdGFuZGFyZGl6YXRpb24gb2Ygc3Vj aCBtZWNoYW5pc21zLg0KPGJyPg0KICZuYnNwOyBBbW9uZyBvdGhlciBwb3RlbnRpYWwgYXBwbGlj YXRpb25zIFBvaW50LXRvLU11bHRpcG9pbnQgUFdzIFNIT1VMRA0KYmUgPGJyPg0KICZuYnNwOyB1 c2VkIHRvIG9wdGltaXplIHRoZSBzdXBwb3J0IG9mIG11bHRpY2FzdCBsYXllciAyIHNlcnZpY2Vz IChWaXJ0dWFsDQo8YnI+DQogJm5ic3A7IFByaXZhdGUgTEFOIFNlcnZpY2UgYW5kIFZpcnR1YWwg UHJpdmF0ZSBNdWx0aWNhc3QgU2VydmljZSkgYXMgZGVmaW5lZA0KPGJyPg0KICZuYnNwOyBpbiB0 aGUgTGF5ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayBXb3JraW5nIEdyb3VwLjxicj4NCjxi cj4NCkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4NCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcHdlMy1wMm1wLXB3LXJlcXVpcmVtZW50 cy0wNC50eHQ8YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6PGJyPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy88YnI+DQo8YnI+DQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUg Y29tcGxpYW50IG1haWwgcmVhZGVyPGJyPg0KaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxs eSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+DQpJbnRlcm5ldC1EcmFmdC48 YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZnRwOi8vYW5v bnltb3VzQGZ0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wd2UzLXAybXAt cHctcmVxdWlyZW1lbnRzLTA0LnR4dDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcHdlMyBtYWlsaW5nIGxp c3Q8YnI+DQpwd2UzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wd2UzPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 003B9723482578CD_=-- From curtis@occnc.com Fri Jul 15 07:22:24 2011 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 41A8021F8761 for ; Fri, 15 Jul 2011 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+YTeZKPAYol for ; Fri, 15 Jul 2011 07:22:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 63A5521F85F7 for ; Fri, 15 Jul 2011 07:22:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FELmwx089394; Fri, 15 Jul 2011 10:21:48 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151421.p6FELmwx089394@harbor.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 08:53:47 -0000." Date: Fri, 15 Jul 2011 10:21:48 -0400 Sender: curtis@occnc.com Cc: "ppan@infinera.com" , "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:22:24 -0000 In message Mach Chen writes: > > Hi Curtis, > > Thanks for your comments! > > As Ping said, we have changed the draft to include tunnel option and > make it as the default, and at the same time, keeps the LSP option > (OPTINAL) hence to give the capability for explicit binding/moving a > PW to a specific LSP when needed. > > Best regards, > Mach Mach, Can you cite any case where it is needed, where more than one LSP is bound to a tunnel and it is not otherwise obvious which LSP to use. In both the make-before-break reroute case and the GMPLS protection case it is possible to determine which LSP to bind to. If there is another case where this is not true, please point it out. Curtis > > Mach, > > > > This draft has more information but it has the same problem I pointed > > out in the -02 version. > > > > The LSP is identified, not the tunnel. The tunnel should be > > identified. In a make-before-break reroute the tunnel remains > > constant but the LSP changes. > > > > When an LSP reroutes for whatever reason, it may be carrying a large > > number of PW. After the make-before-break reroute completes, the old > > LSP no longer exists. It should not be necessary to resignal the PW > > to reroute the LSP. With the text you have, using the LSP numbers, > > that reroute of all the carried PW would be necessary. > > > > There is only one active LSP for any given tunnel. How the active LSP > > is identified, relative to any other LSP is out of scope for this > > document. There may be a working and protect or a working and protect > > and new working and a new protect during a make-before-break > > transition. The IP traffic on an LSP and all LSP carried by a > > hierarchical LSP automatically move during a make-before-break > > reroute. The PW should also move without any additional and totally > > unecessare signaling. > > There may be requirement for doing PW > > Best regards, > Mach > > > > > Curtis > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > To: Mach Chen > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; Wayne > > > > Cao(wei) > > > > Subject: New Version Notification for > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > > been > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > repository. > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > Revision: 03 > > > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > > > mapping > > > > Creation date: 2011-06-28 > > > > WG ID: Individual Submission > > > > Number of pages: 16 > > > > > > > > Abstract: > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > unidirectional PWs each carried over a unidirectional LSP. Each end > > > > point of a PW or segment of multi-segment PW (MS-PW) independently > > > > selects the LSP to use to carry the PW for which it is the head end. > > > > > > > > Some transport services may require that bidirectional PW traffic > > > > follows the same paths through the network in both directions. > > > > Therefore, PWs may be required to use LSP with congruent paths. > > > > Bidirectional LSPs or co-routed associated unidirectional LSPs allow > > > > this service to be provided. > > > > > > > > This document specifies an optional extension to LDP that allows both > > > > ends of a PW (or segment of a MS-PW) to select and bind to the same > > > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 From ping@pingpan.org Fri Jul 15 07:58:13 2011 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 3419B21F888A for ; Fri, 15 Jul 2011 07:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgq-fcBCka+K for ; Fri, 15 Jul 2011 07:58:12 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with SMTP id A155F21F8888 for ; Fri, 15 Jul 2011 07:58:11 -0700 (PDT) Received: from mail-gx0-f173.google.com ([209.85.161.173]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTiBVg6nyq6pj0bzXTAq0eQ0msYQpvU3X@postini.com; Fri, 15 Jul 2011 07:58:11 PDT Received: by mail-gx0-f173.google.com with SMTP id 26so757814gxk.18 for ; Fri, 15 Jul 2011 07:58:11 -0700 (PDT) Received: by 10.236.192.228 with SMTP id i64mr5045237yhn.111.1310741890722; Fri, 15 Jul 2011 07:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Fri, 15 Jul 2011 07:57:30 -0700 (PDT) In-Reply-To: <201107151421.p6FELmwx089394@harbor.orleans.occnc.com> References: <201107151421.p6FELmwx089394@harbor.orleans.occnc.com> From: Ping Pan Date: Fri, 15 Jul 2011 07:57:30 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf30563ed7c9eb0904a81ce098 Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:58:13 -0000 --20cf30563ed7c9eb0904a81ce098 Content-Type: text/plain; charset=ISO-8859-1 Curtis, Today, there are multiple options in binding PW's to the underlying LSP's on a local PE. Some of the policies I have seen include: random (binding PW's to one of the multiple LSP tunnels randomly), least-fill (binding PW's to the ones with most available BW), most-fill... etc. (I know, copying a similar feature from Juniper). Given the current binding does not involve any protocol change, don't think most people would notice. Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or extend the binding policy in multi-hop PW scenarios, we'd have to make the binding request as a part of the PW negotiation. This is the intent of the draft. - Ping On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar wrote: > > In message < > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> > Mach Chen writes: > > > > Hi Curtis, > > > > Thanks for your comments! > > > > As Ping said, we have changed the draft to include tunnel option and > > make it as the default, and at the same time, keeps the LSP option > > (OPTINAL) hence to give the capability for explicit binding/moving a > > PW to a specific LSP when needed. > > > > Best regards, > > Mach > > > Mach, > > Can you cite any case where it is needed, where more than one LSP is > bound to a tunnel and it is not otherwise obvious which LSP to use. > In both the make-before-break reroute case and the GMPLS protection > case it is possible to determine which LSP to bind to. If there is > another case where this is not true, please point it out. > > Curtis > > > > > Mach, > > > > > > This draft has more information but it has the same problem I pointed > > > out in the -02 version. > > > > > > The LSP is identified, not the tunnel. The tunnel should be > > > identified. In a make-before-break reroute the tunnel remains > > > constant but the LSP changes. > > > > > > When an LSP reroutes for whatever reason, it may be carrying a large > > > number of PW. After the make-before-break reroute completes, the old > > > LSP no longer exists. It should not be necessary to resignal the PW > > > to reroute the LSP. With the text you have, using the LSP numbers, > > > that reroute of all the carried PW would be necessary. > > > > > > There is only one active LSP for any given tunnel. How the active LSP > > > is identified, relative to any other LSP is out of scope for this > > > document. There may be a working and protect or a working and protect > > > and new working and a new protect during a make-before-break > > > transition. The IP traffic on an LSP and all LSP carried by a > > > hierarchical LSP automatically move during a make-before-break > > > reroute. The PW should also move without any additional and totally > > > unecessare signaling. > > > > There may be requirement for doing PW > > > > Best regards, > > Mach > > > > > > > > Curtis > > > > > > > > > > > -----Original Message----- > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > > To: Mach Chen > > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; > Wayne > > > > > Cao(wei) > > > > > Subject: New Version Notification for > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > > > A new version of I-D, > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > > > been > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > > repository. > > > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > > Revision: 03 > > > > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > > > > mapping > > > > > Creation date: 2011-06-28 > > > > > WG ID: Individual Submission > > > > > Number of pages: 16 > > > > > > > > > > Abstract: > > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > > unidirectional PWs each carried over a unidirectional LSP. Each > end > > > > > point of a PW or segment of multi-segment PW (MS-PW) > independently > > > > > selects the LSP to use to carry the PW for which it is the head > end. > > > > > > > > > > Some transport services may require that bidirectional PW > traffic > > > > > follows the same paths through the network in both directions. > > > > > Therefore, PWs may be required to use LSP with congruent paths. > > > > > Bidirectional LSPs or co-routed associated unidirectional LSPs > allow > > > > > this service to be provided. > > > > > > > > > > This document specifies an optional extension to LDP that allows > both > > > > > ends of a PW (or segment of a MS-PW) to select and bind to the > same > > > > > bidirectional LSP (or co-routed unidirectional LSPs). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > > > 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 > --20cf30563ed7c9eb0904a81ce098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Curtis,

Today,=A0there are multiple options in binding P= W's to the underlying LSP's on a local PE. Some of the policies I h= ave seen include: random (binding PW's to one of the multiple LSP tunne= ls randomly), least-fill (binding PW's to the ones with most available = BW), most-fill... etc. (I know, copying a similar feature from Juniper). Gi= ven the current binding does not involve any protocol change, don't thi= nk most people would notice.

Now, if we are to bind the PW's to co-routed/bi-dir= ectional LSP's, or extend the binding policy in multi-hop PW=A0scenario= s, we'd have to make the binding request as a part of the PW negotiatio= n. This is the intent of the draft.

- Ping


On Fri, Jul 15, 2011 at 7:21 AM, Curtis = Villamizar <curtis= @occnc.com> wrote:

In message <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZX= EML511-MBX.china.huawei.com>
Mach Chen writes:
>
> Hi Curtis,
>
> Thanks for your comments!
>
> As Ping said, we have changed the draft to include tunnel option and > make it as the default, and at the same time, keeps the LSP option
> (OPTINAL) hence to give the capability for explicit binding/moving a > PW to a specific LSP when needed.
>
> Best regards,
> Mach


Mach,

Can you cite any case where it is needed, where more than one LSP is<= br> bound to a tunnel and it is not otherwise obvious which LSP to use.
In both the make-before-break reroute case and the GMPLS protection
case it is possible to determine which LSP to bind to. =A0If there is
another case where this is not true, please point it out.

Curtis


> > Mach,
> >
> > This draft has more information but it has the same problem I poi= nted
> > out in the -02 version.
> >
> > The LSP is identified, not the tunnel. =A0The tunnel should be > > identified. =A0In a make-before-break reroute the tunnel remains<= br> > > constant but the LSP changes.
> >
> > When an LSP reroutes for whatever reason, it may be carrying a la= rge
> > number of PW. =A0After the make-before-break reroute completes, t= he old
> > LSP no longer exists. =A0It should not be necessary to resignal t= he PW
> > to reroute the LSP. =A0With the text you have, using the LSP numb= ers,
> > that reroute of all the carried PW would be necessary.
> >
> > There is only one active LSP for any given tunnel. =A0How the act= ive LSP
> > is identified, relative to any other LSP is out of scope for this=
> > document. =A0There may be a working and protect or a working and = protect
> > and new working and a new protect during a make-before-break
> > transition. =A0The IP traffic on an LSP and all LSP carried by a<= br> > > hierarchical LSP automatically move during a make-before-break > > reroute. =A0The PW should also move without any additional and to= tally
> > unecessare signaling.
>
> There may be requirement for doing PW
>
> Best regards,
> Mach
>
> >
> > Curtis
> >
> >
> > > > -----Original Message-----
> > > > From: inter= net-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Tuesday, June 28, 2011 5:49 PM
> > > > To: Mach Chen
> > > > Cc: ppan@infinera.= com; attila.takacs@ericss= on.com; Mach Chen; Wayne
> > > > Cao(wei)
> > > > Subject: New Version Notification for
> > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
> > > >
> > > > A new version of I-D, draft-cao-pwe3-mpls-tp-pw-over-bi= dir-lsp-03.txt has
> > been
> > > > successfully submitted by Mach(Guoyi) Chen and posted t= o the IETF
> > repository.
> > > >
> > > > Filename: =A0 =A0 =A0 =A0draft-cao-pwe3-mpls-tp-pw-over= -bidir-lsp
> > > > Revision: =A0 =A0 =A0 =A003
> > > > Title: =A0 LDP extensions for Explicit Pseudowire to tr= ansport LSP
> > > > mapping
> > > > Creation date: =A0 2011-06-28
> > > > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
> > > > Number of pages: 16
> > > >
> > > > Abstract:
> > > > =A0 =A0A bidirectional Pseudowire (PW) service currentl= y uses two
> > > > =A0 =A0unidirectional PWs each carried over a unidirect= ional LSP. =A0Each end
> > > > =A0 =A0point of a PW or segment of multi-segment PW (MS= -PW) independently
> > > > =A0 =A0selects the LSP to use to carry the PW for which= it is the head end.
> > > >
> > > > =A0 =A0Some transport services may require that bidirec= tional PW traffic
> > > > =A0 =A0follows the same paths through the network in bo= th directions.
> > > > =A0 =A0Therefore, PWs may be required to use LSP with c= ongruent paths.
> > > > =A0 =A0Bidirectional LSPs or co-routed associated unidi= rectional LSPs allow
> > > > =A0 =A0this service to be provided.
> > > >
> > > > =A0 =A0This document specifies an optional extension to= LDP that allows both
> > > > =A0 =A0ends of a PW (or segment of a MS-PW) to select a= nd bind to the same
> > > > =A0 =A0bidirectional LSP (or co-routed unidirectional L= SPs).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > _______________________________________________
> > > 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

--20cf30563ed7c9eb0904a81ce098-- From giles.heron@gmail.com Fri Jul 15 08:29:37 2011 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 6EA8221F874A for ; Fri, 15 Jul 2011 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_27=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj7FYezazh+k for ; Fri, 15 Jul 2011 08:29:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2549A21F86EA for ; Fri, 15 Jul 2011 08:29:35 -0700 (PDT) Received: by wwe5 with SMTP id 5so949025wwe.13 for ; Fri, 15 Jul 2011 08:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=wIyAnz/w7vb81u6ufVSBcrdzVHMNyf0EikJIHn/JTbc=; b=wNXj2cWeV4lNpdaCBsJ9v5516FQTGggAd6sbVCMdPczzOjDwfW0vtAT6Hx4AwSjZby tJEQs0GVU37IHKwK/x+q3dN9kr6vjScOFMAdzAQjw9RbOFlNPUEgfk/le2S4ZxAObz1k mQUYCJQg870pHxFqS9v6+2X5l6xtNoSnji1sc= Received: by 10.216.141.155 with SMTP id g27mr612063wej.76.1310743774930; Fri, 15 Jul 2011 08:29:34 -0700 (PDT) Received: from [144.254.149.250] (dhcp-144-254-149-250.cisco.com [144.254.149.250]) by mx.google.com with ESMTPS id v11sm808714weq.33.2011.07.15.08.29.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 08:29:33 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 15 Jul 2011 16:31:05 +0100 From: Giles Heron To: , Message-ID: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-04.txt Thread-Index: AcxDBDXkflLddjXMAEOSIiArf/r29Q== In-Reply-To: <201107150751.p6F7pTMm061864@mse01.zte.com.cn> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:29:37 -0000 Hi Liu, 1) In the case of a non-leaf PE it would receive traffic on the P2MP LSP bu= t wouldn't have a valid PW label to demultiplex the traffic. In the P2MP LSP case the PW label is valid within the context of the P2MP LSP so the non-leaf PE won't have the label assigned for other traffic. 2) Yes the non-leaf PE would just discard the unwanted traffic. But sure, might be worth clarifying this in the draft... Giles On 14/07/2011 11:49, "liu.guoman@zte.com.cn" wrote: > hi,authors > i review this draft today. i have a few question for section 3.2 P2MP > SS-PW Underlying Layer . > in the section, there is the following paragraph context: > " As an example an existing P2MP LSP may attach > more leaves than the ones defined as Leaf PEs for a given P2MP PW. It > may be interesting to reuse it to minimize new configuration, but > using this P2MP LSP would imply non-Leaf PEs receive unwanted > traffic, not destined to Leaf PE at the service layer" >=20 > Q1: how do non-leaf PEs identify which traffic is unwanted > traffic by a common p2mp LSP? > do they only be based on pw label to judge the traffic? if so, > maybe the value of the pw label have already been assigned for another > wanted traffic, > how do the non-leafs PEs identify which traffic is unwanted or > wanted traffic for itself? > Q2: if non-leaf PEs know this traffic is unwanted traffic , do > they directly abandon these traffic? i think it necessary to clarify it i= n > this draft. > =20 >=20 > thank you! >=20 >=20 > B.R. > liu > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Internet-Drafts@ietf.org > =B7=A2=BC=FE=C8=CB: pwe3-bounces@ietf.org > 2011-07-09 05:30 >=20 > =CA=D5=BC=FE=C8=CB > i-d-announce@ietf.org > =B3=AD=CB=CD > pwe3@ietf.org > =D6=F7=CC=E2 > [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-04.txt >=20 >=20 >=20 >=20 >=20 >=20 > 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 Workin= g > Group of the IETF. >=20 > Title : Requirements and Framework for Point-to-Multipoint > Pseudowire > Author(s) : G. Heron, et al > Filename : draft-ietf-pwe3-p2mp-pw-requirements-04.txt > Pages : 21 > Date : 2011-07-08 > =20 > This document presents a set of requirements and a framework for > providing a Point-to-Multipoint Pseudowire (PW). The requirements > identified in this document are related to architecture, signaling > and maintenance aspects of Point-to-Multipoint PW operation. They are > proposed as guidelines for the standardization of such mechanisms. > Among other potential applications Point-to-Multipoint PWs SHOULD be > used to optimize the support of multicast layer 2 services (Virtual > Private LAN Service and Virtual Private Multicast Service) as defined > in the Layer 2 Virtual Private Network Working Group. >=20 > A URL for this Internet-Draft is: >=20 http://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-requirements-04= .tx> t >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-requ= ireme > nts-04.txt > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d are > not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From curtis@occnc.com Fri Jul 15 10:08:50 2011 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 4831021F8AEA for ; Fri, 15 Jul 2011 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2oplrPPwRhG for ; Fri, 15 Jul 2011 10:08:49 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 60DE521F8A56 for ; Fri, 15 Jul 2011 10:08:46 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FH8fLD094701; Fri, 15 Jul 2011 13:08:41 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151708.p6FH8fLD094701@harbor.orleans.occnc.com> To: Ping Pan From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 07:57:30 PDT." Date: Fri, 15 Jul 2011 13:08:41 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:08:50 -0000 In message Ping Pan writes: > > > > > Curtis, > > > > Today, there are multiple options in binding PW's to the underlying > > LSP's on a local PE. Some of the policies I have seen include: random > > (binding PW's to one of the multiple LSP tunnels randomly), least-fill > > (binding PW's to the ones with most available BW), > > most-fill... etc. (I know, copying a similar feature from > > Juniper). Given the current binding does not involve any protocol > > change, don't think most people would notice. > > > > Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or > > extend the binding policy in multi-hop PW scenarios, we'd have to make > > the binding request as a part of the PW negotiation. This is the > > intent of the draft. > > > > - Ping If there is only one LSP per tunnel, then you still didn't answer the question as to why the LSP_ID is needed. I've stated very clearly why the LSP_ID is bad. If you do make-before-break, or swithc from working to protect in GMPLS protection, you have to resignal all of the affected PW, where without using LSP-ID you don't have to do that. If you don't have a reason for more than one LSP per tunnel, then there is no need for the LSP_ID. The 16 bit tunnel_num is there for a reason. It allows 64K tunnels between any two LSR. The LSP_ID allows more than one LSP per tunnel, but generally it is one except during a brief transition period that occurs in make-before-break reroute. Curtis > > On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar wrote: > > > > > > > > In message < > > > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> > > > Mach Chen writes: > > > > > > > > Hi Curtis, > > > > > > > > Thanks for your comments! > > > > > > > > As Ping said, we have changed the draft to include tunnel option and > > > > make it as the default, and at the same time, keeps the LSP option > > > > (OPTINAL) hence to give the capability for explicit binding/moving a > > > > PW to a specific LSP when needed. > > > > > > > > Best regards, > > > > Mach > > > > > > > > > Mach, > > > > > > Can you cite any case where it is needed, where more than one LSP is > > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > > In both the make-before-break reroute case and the GMPLS protection > > > case it is possible to determine which LSP to bind to. If there is > > > another case where this is not true, please point it out. > > > > > > Curtis > > > > > > > > > > > Mach, > > > > > > > > > > This draft has more information but it has the same problem I pointed > > > > > out in the -02 version. > > > > > > > > > > The LSP is identified, not the tunnel. The tunnel should be > > > > > identified. In a make-before-break reroute the tunnel remains > > > > > constant but the LSP changes. > > > > > > > > > > When an LSP reroutes for whatever reason, it may be carrying a large > > > > > number of PW. After the make-before-break reroute completes, the old > > > > > LSP no longer exists. It should not be necessary to resignal the PW > > > > > to reroute the LSP. With the text you have, using the LSP numbers, > > > > > that reroute of all the carried PW would be necessary. > > > > > > > > > > There is only one active LSP for any given tunnel. How the active LSP > > > > > is identified, relative to any other LSP is out of scope for this > > > > > document. There may be a working and protect or a working and protect > > > > > and new working and a new protect during a make-before-break > > > > > transition. The IP traffic on an LSP and all LSP carried by a > > > > > hierarchical LSP automatically move during a make-before-break > > > > > reroute. The PW should also move without any additional and totally > > > > > unecessare signaling. > > > > > > > > There may be requirement for doing PW > > > > > > > > Best regards, > > > > Mach > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > > > > To: Mach Chen > > > > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; > > > Wayne > > > > > > > Cao(wei) > > > > > > > Subject: New Version Notification for > > > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > > > > > > > A new version of I-D, > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > > > > > been > > > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > > > > repository. > > > > > > > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > > > > Revision: 03 > > > > > > > Title: LDP extensions for Explicit Pseudowire to transport LSP > > > > > > > mapping > > > > > > > Creation date: 2011-06-28 > > > > > > > WG ID: Individual Submission > > > > > > > Number of pages: 16 > > > > > > > > > > > > > > Abstract: > > > > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > > > > unidirectional PWs each carried over a unidirectional LSP. Each > > > end > > > > > > > point of a PW or segment of multi-segment PW (MS-PW) > > > independently > > > > > > > selects the LSP to use to carry the PW for which it is the head > > > end. > > > > > > > > > > > > > > Some transport services may require that bidirectional PW > > > traffic > > > > > > > follows the same paths through the network in both directions. > > > > > > > Therefore, PWs may be required to use LSP with congruent paths. > > > > > > > Bidirectional LSPs or co-routed associated unidirectional LSPs > > > allow > > > > > > > this service to be provided. > > > > > > > > > > > > > > This document specifies an optional extension to LDP that allows > > > both > > > > > > > ends of a PW (or segment of a MS-PW) to select and bind to the > > > same > > > > > > > bidirectional LSP (or co-routed unidirectional LSPs). From tnadeau@lucidvision.com Fri Jul 15 10:15:30 2011 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 52A0F21F8B45 for ; Fri, 15 Jul 2011 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDQa025qvN9E for ; Fri, 15 Jul 2011 10:15:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1F69821F8B2A for ; Fri, 15 Jul 2011 10:15:29 -0700 (PDT) Received: from [192.168.1.133] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9DDFB1CF8EBD; Fri, 15 Jul 2011 13:15:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <201107151708.p6FH8fLD094701@harbor.orleans.occnc.com> Date: Fri, 15 Jul 2011 13:15:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107151708.p6FH8fLD094701@harbor.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1084) Cc: "pwe3@ietf.org" , Ping Pan , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:15:30 -0000 On Jul 15, 2011, at 1:08 PM, Curtis Villamizar wrote: >=20 > In message = > Ping Pan writes: >>=20 >>>=20 >>> Curtis, >>>=20 >>> Today, there are multiple options in binding PW's to the underlying >>> LSP's on a local PE. Some of the policies I have seen include: = random >>> (binding PW's to one of the multiple LSP tunnels randomly), = least-fill >>> (binding PW's to the ones with most available BW), >>> most-fill... etc. (I know, copying a similar feature from >>> Juniper). Given the current binding does not involve any protocol >>> change, don't think most people would notice. >>>=20 >>> Now, if we are to bind the PW's to co-routed/bi-directional LSP's, = or >>> extend the binding policy in multi-hop PW scenarios, we'd have to = make >>> the binding request as a part of the PW negotiation. This is the >>> intent of the draft. >>>=20 >>> - Ping >=20 >=20 > If there is only one LSP per tunnel, then you still didn't answer the > question as to why the LSP_ID is needed. >=20 > I've stated very clearly why the LSP_ID is bad. If you do > make-before-break, or swithc from working to protect in GMPLS > protection, you have to resignal all of the affected PW, where without > using LSP-ID you don't have to do that. >=20 > If you don't have a reason for more than one LSP per tunnel, then > there is no need for the LSP_ID. >=20 > The 16 bit tunnel_num is there for a reason. It allows 64K tunnels > between any two LSR. The LSP_ID allows more than one LSP per tunnel, > but generally it is one except during a brief transition period that > occurs in make-before-break reroute. I agree with you Curtis. There are already mechanisms in place for choosing paths for PWs in the various popular implementations that let you nail down which path (or paths) are allowed to be chosen. This is available for all of the applications (l3VPN, l2VPN, PWs, static) as far as I can tell BTW. --Tom >=20 > Curtis >=20 >=20 >>> On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar = wrote: >>>=20 >>>>=20 >>>> In message < >>>> = F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> >>>> Mach Chen writes: >>>>>=20 >>>>> Hi Curtis, >>>>>=20 >>>>> Thanks for your comments! >>>>>=20 >>>>> As Ping said, we have changed the draft to include tunnel option = and >>>>> make it as the default, and at the same time, keeps the LSP option >>>>> (OPTINAL) hence to give the capability for explicit binding/moving = a >>>>> PW to a specific LSP when needed. >>>>>=20 >>>>> Best regards, >>>>> Mach >>>>=20 >>>>=20 >>>> Mach, >>>>=20 >>>> Can you cite any case where it is needed, where more than one LSP = is >>>> bound to a tunnel and it is not otherwise obvious which LSP to use. >>>> In both the make-before-break reroute case and the GMPLS protection >>>> case it is possible to determine which LSP to bind to. If there is >>>> another case where this is not true, please point it out. >>>>=20 >>>> Curtis >>>>=20 >>>>=20 >>>>>> Mach, >>>>>>=20 >>>>>> This draft has more information but it has the same problem I = pointed >>>>>> out in the -02 version. >>>>>>=20 >>>>>> The LSP is identified, not the tunnel. The tunnel should be >>>>>> identified. In a make-before-break reroute the tunnel remains >>>>>> constant but the LSP changes. >>>>>>=20 >>>>>> When an LSP reroutes for whatever reason, it may be carrying a = large >>>>>> number of PW. After the make-before-break reroute completes, the = old >>>>>> LSP no longer exists. It should not be necessary to resignal the = PW >>>>>> to reroute the LSP. With the text you have, using the LSP = numbers, >>>>>> that reroute of all the carried PW would be necessary. >>>>>>=20 >>>>>> There is only one active LSP for any given tunnel. How the = active LSP >>>>>> is identified, relative to any other LSP is out of scope for this >>>>>> document. There may be a working and protect or a working and = protect >>>>>> and new working and a new protect during a make-before-break >>>>>> transition. The IP traffic on an LSP and all LSP carried by a >>>>>> hierarchical LSP automatically move during a make-before-break >>>>>> reroute. The PW should also move without any additional and = totally >>>>>> unecessare signaling. >>>>>=20 >>>>> There may be requirement for doing PW >>>>>=20 >>>>> Best regards, >>>>> Mach >>>>>=20 >>>>>>=20 >>>>>> Curtis >>>>>>=20 >>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] >>>>>>>> Sent: Tuesday, June 28, 2011 5:49 PM >>>>>>>> To: Mach Chen >>>>>>>> Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; >>>> Wayne >>>>>>>> Cao(wei) >>>>>>>> Subject: New Version Notification for >>>>>>>> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt >>>>>>>>=20 >>>>>>>> A new version of I-D, >>>> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has >>>>>> been >>>>>>>> successfully submitted by Mach(Guoyi) Chen and posted to the = IETF >>>>>> repository. >>>>>>>>=20 >>>>>>>> Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp >>>>>>>> Revision: 03 >>>>>>>> Title: LDP extensions for Explicit Pseudowire to transport = LSP >>>>>>>> mapping >>>>>>>> Creation date: 2011-06-28 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 16 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> A bidirectional Pseudowire (PW) service currently uses two >>>>>>>> unidirectional PWs each carried over a unidirectional LSP. = Each >>>> end >>>>>>>> point of a PW or segment of multi-segment PW (MS-PW) >>>> independently >>>>>>>> selects the LSP to use to carry the PW for which it is the = head >>>> end. >>>>>>>>=20 >>>>>>>> Some transport services may require that bidirectional PW >>>> traffic >>>>>>>> follows the same paths through the network in both = directions. >>>>>>>> Therefore, PWs may be required to use LSP with congruent = paths. >>>>>>>> Bidirectional LSPs or co-routed associated unidirectional = LSPs >>>> allow >>>>>>>> this service to be provided. >>>>>>>>=20 >>>>>>>> This document specifies an optional extension to LDP that = allows >>>> both >>>>>>>> ends of a PW (or segment of a MS-PW) to select and bind to = the >>>> same >>>>>>>> bidirectional LSP (or co-routed unidirectional LSPs). > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From ping@pingpan.org Fri Jul 15 10:41:15 2011 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 A523021F8B94 for ; Fri, 15 Jul 2011 10:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLnsp75O5Tye for ; Fri, 15 Jul 2011 10:41:14 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with SMTP id B909921F8B91 for ; Fri, 15 Jul 2011 10:41:06 -0700 (PDT) Received: from mail-gw0-f42.google.com ([74.125.83.42]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTiB7salNhmeEgNsbi5M0fZxuoGLKsR6d@postini.com; Fri, 15 Jul 2011 10:41:06 PDT Received: by gwb17 with SMTP id 17so702853gwb.15 for ; Fri, 15 Jul 2011 10:41:05 -0700 (PDT) Received: by 10.236.183.131 with SMTP id q3mr4687915yhm.312.1310751665152; Fri, 15 Jul 2011 10:41:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Fri, 15 Jul 2011 10:40:25 -0700 (PDT) In-Reply-To: <201107151708.p6FH8fLD094701@harbor.orleans.occnc.com> References: <201107151708.p6FH8fLD094701@harbor.orleans.occnc.com> From: Ping Pan Date: Fri, 15 Jul 2011 10:40:25 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf305b122c63e3e704a81f27d5 Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:41:15 -0000 --20cf305b122c63e3e704a81f27d5 Content-Type: text/plain; charset=ISO-8859-1 > > > > > Curtis, > > > > > > Today, there are multiple options in binding PW's to the underlying > > > LSP's on a local PE. Some of the policies I have seen include: random > > > (binding PW's to one of the multiple LSP tunnels randomly), least-fill > > > (binding PW's to the ones with most available BW), > > > most-fill... etc. (I know, copying a similar feature from > > > Juniper). Given the current binding does not involve any protocol > > > change, don't think most people would notice. > > > > > > Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or > > > extend the binding policy in multi-hop PW scenarios, we'd have to make > > > the binding request as a part of the PW negotiation. This is the > > > intent of the draft. > > > > > > - Ping > > > If there is only one LSP per tunnel, then you still didn't answer the > question as to why the LSP_ID is needed. > > I've stated very clearly why the LSP_ID is bad. If you do > make-before-break, or swithc from working to protect in GMPLS > protection, you have to resignal all of the affected PW, where without > using LSP-ID you don't have to do that. > > Then turn-on the T-flag, and get on with it. > If you don't have a reason for more than one LSP per tunnel, then > there is no need for the LSP_ID. > > The 16 bit tunnel_num is there for a reason. It allows 64K tunnels > between any two LSR. The LSP_ID allows more than one LSP per tunnel, > but generally it is one except during a brief transition period that > occurs in make-before-break reroute. > > Curtis > > > > > On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar > wrote: > > > > > > > > > > > In message < > > > > > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> > > > > Mach Chen writes: > > > > > > > > > > Hi Curtis, > > > > > > > > > > Thanks for your comments! > > > > > > > > > > As Ping said, we have changed the draft to include tunnel option > and > > > > > make it as the default, and at the same time, keeps the LSP option > > > > > (OPTINAL) hence to give the capability for explicit binding/moving > a > > > > > PW to a specific LSP when needed. > > > > > > > > > > Best regards, > > > > > Mach > > > > > > > > > > > > Mach, > > > > > > > > Can you cite any case where it is needed, where more than one LSP is > > > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > > > In both the make-before-break reroute case and the GMPLS protection > > > > case it is possible to determine which LSP to bind to. If there is > > > > another case where this is not true, please point it out. > > > > > > > > Curtis > > > > > > > > > > > > > > Mach, > > > > > > > > > > > > This draft has more information but it has the same problem I > pointed > > > > > > out in the -02 version. > > > > > > > > > > > > The LSP is identified, not the tunnel. The tunnel should be > > > > > > identified. In a make-before-break reroute the tunnel remains > > > > > > constant but the LSP changes. > > > > > > > > > > > > When an LSP reroutes for whatever reason, it may be carrying a > large > > > > > > number of PW. After the make-before-break reroute completes, the > old > > > > > > LSP no longer exists. It should not be necessary to resignal the > PW > > > > > > to reroute the LSP. With the text you have, using the LSP > numbers, > > > > > > that reroute of all the carried PW would be necessary. > > > > > > > > > > > > There is only one active LSP for any given tunnel. How the > active LSP > > > > > > is identified, relative to any other LSP is out of scope for this > > > > > > document. There may be a working and protect or a working and > protect > > > > > > and new working and a new protect during a make-before-break > > > > > > transition. The IP traffic on an LSP and all LSP carried by a > > > > > > hierarchical LSP automatically move during a make-before-break > > > > > > reroute. The PW should also move without any additional and > totally > > > > > > unecessare signaling. > > > > > > > > > > There may be requirement for doing PW > > > > > > > > > > Best regards, > > > > > Mach > > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: internet-drafts@ietf.org [mailto: > internet-drafts@ietf.org] > > > > > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > > > > > To: Mach Chen > > > > > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach > Chen; > > > > Wayne > > > > > > > > Cao(wei) > > > > > > > > Subject: New Version Notification for > > > > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > > > > > > > > > A new version of I-D, > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > > > > > > been > > > > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the > IETF > > > > > > repository. > > > > > > > > > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > > > > > Revision: 03 > > > > > > > > Title: LDP extensions for Explicit Pseudowire to transport > LSP > > > > > > > > mapping > > > > > > > > Creation date: 2011-06-28 > > > > > > > > WG ID: Individual Submission > > > > > > > > Number of pages: 16 > > > > > > > > > > > > > > > > Abstract: > > > > > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > > > > > unidirectional PWs each carried over a unidirectional LSP. > Each > > > > end > > > > > > > > point of a PW or segment of multi-segment PW (MS-PW) > > > > independently > > > > > > > > selects the LSP to use to carry the PW for which it is the > head > > > > end. > > > > > > > > > > > > > > > > Some transport services may require that bidirectional PW > > > > traffic > > > > > > > > follows the same paths through the network in both > directions. > > > > > > > > Therefore, PWs may be required to use LSP with congruent > paths. > > > > > > > > Bidirectional LSPs or co-routed associated unidirectional > LSPs > > > > allow > > > > > > > > this service to be provided. > > > > > > > > > > > > > > > > This document specifies an optional extension to LDP that > allows > > > > both > > > > > > > > ends of a PW (or segment of a MS-PW) to select and bind to > the > > > > same > > > > > > > > bidirectional LSP (or co-routed unidirectional LSPs). > --20cf305b122c63e3e704a81f27d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> > Curtis,
> >
> > Today, there are multiple options in binding PW's to the unde= rlying
> > LSP's on a local PE. Some of the policies I have seen include= : random
> > (binding PW's to one of the multiple LSP tunnels randomly), l= east-fill
> > (binding PW's to the ones with most available BW),
> > most-fill... etc. (I know, copying a similar feature from
> > Juniper). Given the current binding does not involve any protocol=
> > change, don't think most people would notice.
> >
> > Now, if we are to bind the PW's to co-routed/bi-directional L= SP's, or
> > extend the binding policy in multi-hop PW scenarios, we'd hav= e to make
> > the binding request as a part of the PW negotiation. This is the<= br> > > intent of the draft.
> >
> > - Ping


If there is only one LSP per tunnel, then you still didn't answer= the
question as to why the LSP_ID is needed.

I've stated very clearly why the LSP_ID is bad. =A0If you do
make-before-break, or swithc from working to protect in GMPLS
protection, you have to resignal all of the affected PW, where without
using LSP-ID you don't have to do that.


Then turn-on the T-flag, and get on wi= th it.
=A0
If you don't have a reason for more than one LSP per tunnel, then
there is no need for the LSP_ID.

The 16 bit tunnel_num is there for a reason. =A0It allows 64K tunnels
between any two LSR. =A0The LSP_ID allows more than one LSP per tunnel,
but generally it is one except during a brief transition period that
occurs in make-before-break reroute.

Curtis


> > On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar <curtis@occnc.com> wrote:
> >
> > >
> > > In message <
> > > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZX= EML511-MBX.china.huawei.com>
> > > Mach Chen writes:
> > > >
> > > > Hi Curtis,
> > > >
> > > > Thanks for your comments!
> > > >
> > > > As Ping said, we have changed the draft to include tunn= el option and
> > > > make it as the default, and at the same time, keeps the= LSP option
> > > > (OPTINAL) hence to give the capability for explicit bin= ding/moving a
> > > > PW to a specific LSP when needed.
> > > >
> > > > Best regards,
> > > > Mach
> > >
> > >
> > > Mach,
> > >
> > > Can you cite any case where it is needed, where more than on= e LSP is
> > > bound to a tunnel and it is not otherwise obvious which LSP = to use.
> > > In both the make-before-break reroute case and the GMPLS pro= tection
> > > case it is possible to determine which LSP to bind to. =A0If= there is
> > > another case where this is not true, please point it out. > > >
> > > Curtis
> > >
> > >
> > > > > Mach,
> > > > >
> > > > > This draft has more information but it has the sam= e problem I pointed
> > > > > out in the -02 version.
> > > > >
> > > > > The LSP is identified, not the tunnel. =A0The tunn= el should be
> > > > > identified. =A0In a make-before-break reroute the = tunnel remains
> > > > > constant but the LSP changes.
> > > > >
> > > > > When an LSP reroutes for whatever reason, it may b= e carrying a large
> > > > > number of PW. =A0After the make-before-break rerou= te completes, the old
> > > > > LSP no longer exists. =A0It should not be necessar= y to resignal the PW
> > > > > to reroute the LSP. =A0With the text you have, usi= ng the LSP numbers,
> > > > > that reroute of all the carried PW would be necess= ary.
> > > > >
> > > > > There is only one active LSP for any given tunnel.= =A0How the active LSP
> > > > > is identified, relative to any other LSP is out of= scope for this
> > > > > document. =A0There may be a working and protect or= a working and protect
> > > > > and new working and a new protect during a make-be= fore-break
> > > > > transition. =A0The IP traffic on an LSP and all LS= P carried by a
> > > > > hierarchical LSP automatically move during a make-= before-break
> > > > > reroute. =A0The PW should also move without any ad= ditional and totally
> > > > > unecessare signaling.
> > > >
> > > > There may be requirement for doing PW
> > > >
> > > > Best regards,
> > > > Mach
> > > >
> > > > >
> > > > > Curtis
> > > > >
> > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > > > > Sent: Tuesday, June 28, 2011 5:49 PM
> > > > > > > To: Mach Chen
> > > > > > > Cc: ppan@infinera.com; attil= a.takacs@ericsson.com; Mach Chen;
> > > Wayne
> > > > > > > Cao(wei)
> > > > > > > Subject: New Version Notification for > > > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp= -03.txt
> > > > > > >
> > > > > > > A new version of I-D,
> > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has
> > > > > been
> > > > > > > successfully submitted by Mach(Guoyi) Ch= en and posted to the IETF
> > > > > repository.
> > > > > > >
> > > > > > > Filename: =A0 =A0 =A0 =A0draft-cao-pwe3-= mpls-tp-pw-over-bidir-lsp
> > > > > > > Revision: =A0 =A0 =A0 =A003
> > > > > > > Title: =A0 LDP extensions for Explicit P= seudowire to transport LSP
> > > > > > > mapping
> > > > > > > Creation date: =A0 2011-06-28
> > > > > > > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Su= bmission
> > > > > > > Number of pages: 16
> > > > > > >
> > > > > > > Abstract:
> > > > > > > =A0 =A0A bidirectional Pseudowire (PW) s= ervice currently uses two
> > > > > > > =A0 =A0unidirectional PWs each carried o= ver a unidirectional LSP. =A0Each
> > > end
> > > > > > > =A0 =A0point of a PW or segment of multi= -segment PW (MS-PW)
> > > independently
> > > > > > > =A0 =A0selects the LSP to use to carry t= he PW for which it is the head
> > > end.
> > > > > > >
> > > > > > > =A0 =A0Some transport services may requi= re that bidirectional PW
> > > traffic
> > > > > > > =A0 =A0follows the same paths through th= e network in both directions.
> > > > > > > =A0 =A0Therefore, PWs may be required to= use LSP with congruent paths.
> > > > > > > =A0 =A0Bidirectional LSPs or co-routed a= ssociated unidirectional LSPs
> > > allow
> > > > > > > =A0 =A0this service to be provided.
> > > > > > >
> > > > > > > =A0 =A0This document specifies an option= al extension to LDP that allows
> > > both
> > > > > > > =A0 =A0ends of a PW (or segment of a MS-= PW) to select and bind to the
> > > same
> > > > > > > =A0 =A0bidirectional LSP (or co-routed u= nidirectional LSPs).

--20cf305b122c63e3e704a81f27d5-- From ping@pingpan.org Fri Jul 15 10:57:50 2011 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 1121F21F8BFB for ; Fri, 15 Jul 2011 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYIhTP5LcM-m for ; Fri, 15 Jul 2011 10:57:48 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with SMTP id 3C04521F8BD4 for ; Fri, 15 Jul 2011 10:57:48 -0700 (PDT) Received: from mail-gx0-f182.google.com ([209.85.161.182]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTiB/m7cDzq14w89mn487tvbFvxH2bqHI@postini.com; Fri, 15 Jul 2011 10:57:48 PDT Received: by gxk28 with SMTP id 28so757466gxk.41 for ; Fri, 15 Jul 2011 10:57:47 -0700 (PDT) Received: by 10.236.192.228 with SMTP id i64mr5323643yhn.111.1310752667119; Fri, 15 Jul 2011 10:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Fri, 15 Jul 2011 10:57:07 -0700 (PDT) In-Reply-To: References: <201107151708.p6FH8fLD094701@harbor.orleans.occnc.com> From: Ping Pan Date: Fri, 15 Jul 2011 10:57:07 -0700 Message-ID: To: Thomas Nadeau Content-Type: multipart/alternative; boundary=20cf30563ed71cb01b04a81f63ae Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:57:50 -0000 --20cf30563ed71cb01b04a81f63ae Content-Type: text/plain; charset=ISO-8859-1 Hi, I think we are talking over each other. ;-) Let me try to describe an example here: A --- B ---- C ---- D A and D and Ethernet CE's. B and C are PE's. Between B and C, we have a transport network, say, GMPLS-enabled optical transport network. There are tons of VLAN circuits between A and D, and there are multiple optical connections (as in GMPLS LSP's) between B and C. The connections take different path onto different fiber etc. On B and C, each uni-directional Ethernet VLAN is mapped to a PW. And we need to make sure of the mapping for each bi-directional Ethernet circuit onto a bi-directional LSP. There are two ways to go about: 1. Configure both ends 2. Do something intelligent during the setup time (as described in this draft). There is no make-before-break in optical network. Now, extending it further, this apply to co-routed MPLS LSP's, And MHOP PW needs to be addressed. Hope this helps. - Ping On Fri, Jul 15, 2011 at 10:15 AM, Thomas Nadeau wrote: > > On Jul 15, 2011, at 1:08 PM, Curtis Villamizar wrote: > > > > > In message < > CAHEV9L2TxfK86qCN7410aC8xpcTQ71XLm-p1dm49QLEF2nxOSg@mail.gmail.com> > > Ping Pan writes: > >> > >>> > >>> Curtis, > >>> > >>> Today, there are multiple options in binding PW's to the underlying > >>> LSP's on a local PE. Some of the policies I have seen include: random > >>> (binding PW's to one of the multiple LSP tunnels randomly), least-fill > >>> (binding PW's to the ones with most available BW), > >>> most-fill... etc. (I know, copying a similar feature from > >>> Juniper). Given the current binding does not involve any protocol > >>> change, don't think most people would notice. > >>> > >>> Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or > >>> extend the binding policy in multi-hop PW scenarios, we'd have to make > >>> the binding request as a part of the PW negotiation. This is the > >>> intent of the draft. > >>> > >>> - Ping > > > > > > If there is only one LSP per tunnel, then you still didn't answer the > > question as to why the LSP_ID is needed. > > > > I've stated very clearly why the LSP_ID is bad. If you do > > make-before-break, or swithc from working to protect in GMPLS > > protection, you have to resignal all of the affected PW, where without > > using LSP-ID you don't have to do that. > > > > If you don't have a reason for more than one LSP per tunnel, then > > there is no need for the LSP_ID. > > > > The 16 bit tunnel_num is there for a reason. It allows 64K tunnels > > between any two LSR. The LSP_ID allows more than one LSP per tunnel, > > but generally it is one except during a brief transition period that > > occurs in make-before-break reroute. > > I agree with you Curtis. There are already mechanisms in place > for choosing paths for PWs in the various popular implementations that > let you nail down which path (or paths) are allowed to be chosen. This > is available for all of the applications (l3VPN, l2VPN, PWs, static) > as far as I can tell BTW. > > --Tom > > > > > > Curtis > > > > > >>> On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar > wrote: > >>> > >>>> > >>>> In message < > >>>> > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> > >>>> Mach Chen writes: > >>>>> > >>>>> Hi Curtis, > >>>>> > >>>>> Thanks for your comments! > >>>>> > >>>>> As Ping said, we have changed the draft to include tunnel option and > >>>>> make it as the default, and at the same time, keeps the LSP option > >>>>> (OPTINAL) hence to give the capability for explicit binding/moving a > >>>>> PW to a specific LSP when needed. > >>>>> > >>>>> Best regards, > >>>>> Mach > >>>> > >>>> > >>>> Mach, > >>>> > >>>> Can you cite any case where it is needed, where more than one LSP is > >>>> bound to a tunnel and it is not otherwise obvious which LSP to use. > >>>> In both the make-before-break reroute case and the GMPLS protection > >>>> case it is possible to determine which LSP to bind to. If there is > >>>> another case where this is not true, please point it out. > >>>> > >>>> Curtis > >>>> > >>>> > >>>>>> Mach, > >>>>>> > >>>>>> This draft has more information but it has the same problem I > pointed > >>>>>> out in the -02 version. > >>>>>> > >>>>>> The LSP is identified, not the tunnel. The tunnel should be > >>>>>> identified. In a make-before-break reroute the tunnel remains > >>>>>> constant but the LSP changes. > >>>>>> > >>>>>> When an LSP reroutes for whatever reason, it may be carrying a large > >>>>>> number of PW. After the make-before-break reroute completes, the > old > >>>>>> LSP no longer exists. It should not be necessary to resignal the PW > >>>>>> to reroute the LSP. With the text you have, using the LSP numbers, > >>>>>> that reroute of all the carried PW would be necessary. > >>>>>> > >>>>>> There is only one active LSP for any given tunnel. How the active > LSP > >>>>>> is identified, relative to any other LSP is out of scope for this > >>>>>> document. There may be a working and protect or a working and > protect > >>>>>> and new working and a new protect during a make-before-break > >>>>>> transition. The IP traffic on an LSP and all LSP carried by a > >>>>>> hierarchical LSP automatically move during a make-before-break > >>>>>> reroute. The PW should also move without any additional and totally > >>>>>> unecessare signaling. > >>>>> > >>>>> There may be requirement for doing PW > >>>>> > >>>>> Best regards, > >>>>> Mach > >>>>> > >>>>>> > >>>>>> Curtis > >>>>>> > >>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>>>>>>> Sent: Tuesday, June 28, 2011 5:49 PM > >>>>>>>> To: Mach Chen > >>>>>>>> Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach Chen; > >>>> Wayne > >>>>>>>> Cao(wei) > >>>>>>>> Subject: New Version Notification for > >>>>>>>> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > >>>>>>>> > >>>>>>>> A new version of I-D, > >>>> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > >>>>>> been > >>>>>>>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF > >>>>>> repository. > >>>>>>>> > >>>>>>>> Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > >>>>>>>> Revision: 03 > >>>>>>>> Title: LDP extensions for Explicit Pseudowire to transport LSP > >>>>>>>> mapping > >>>>>>>> Creation date: 2011-06-28 > >>>>>>>> WG ID: Individual Submission > >>>>>>>> Number of pages: 16 > >>>>>>>> > >>>>>>>> Abstract: > >>>>>>>> A bidirectional Pseudowire (PW) service currently uses two > >>>>>>>> unidirectional PWs each carried over a unidirectional LSP. Each > >>>> end > >>>>>>>> point of a PW or segment of multi-segment PW (MS-PW) > >>>> independently > >>>>>>>> selects the LSP to use to carry the PW for which it is the head > >>>> end. > >>>>>>>> > >>>>>>>> Some transport services may require that bidirectional PW > >>>> traffic > >>>>>>>> follows the same paths through the network in both directions. > >>>>>>>> Therefore, PWs may be required to use LSP with congruent paths. > >>>>>>>> Bidirectional LSPs or co-routed associated unidirectional LSPs > >>>> allow > >>>>>>>> this service to be provided. > >>>>>>>> > >>>>>>>> This document specifies an optional extension to LDP that allows > >>>> both > >>>>>>>> ends of a PW (or segment of a MS-PW) to select and bind to the > >>>> same > >>>>>>>> bidirectional LSP (or co-routed unidirectional LSPs). > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > --20cf30563ed71cb01b04a81f63ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I think we are talking over each other. ;-) Let me t= ry to describe an example here:

=A0=A0A --- B ---= - C ---- D

A and D and Ethernet CE's. B and C are PE's. Be= tween B and C, we have a transport network, say, GMPLS-enabled optical tran= sport network.=A0

There are tons of VLAN circuits = between A and D, and there are multiple optical connections (as in GMPLS LS= P's) between B and C. The connections take different path onto differen= t fiber etc.

On B and C, each uni-directional Ethernet VLAN is mappe= d to a PW. And we need to make sure of the mapping for each bi-directional = Ethernet circuit onto a bi-directional LSP.=A0

There are two ways to go about:

1. Configure both ends
2. Do something intell= igent during the setup time (as described in this draft).

There is no make-before-break in optical network.

Now, extending it further, this apply to co-routed MPLS LSP'= s, And MHOP PW needs to be addressed.=A0

Hope this= helps.

- Ping


On Fri, Jul 15, 2011 at 10:15 AM, Thomas= Nadeau <tn= adeau@lucidvision.com> wrote:

On Jul 15, 2011, at 1:08 PM, Curtis Villamizar wrote:

>
> In message <CAHEV9L2TxfK86qCN7410aC8xpcTQ71XLm-p1dm49QLE= F2nxOSg@mail.gmail.com>
> Ping Pan writes:
>>
>>>
>>> Curtis,
>>>
>>> Today, there are multiple options in binding PW's to the u= nderlying
>>> LSP's on a local PE. Some of the policies I have seen incl= ude: random
>>> (binding PW's to one of the multiple LSP tunnels randomly)= , least-fill
>>> (binding PW's to the ones with most available BW),
>>> most-fill... etc. (I know, copying a similar feature from
>>> Juniper). Given the current binding does not involve any proto= col
>>> change, don't think most people would notice.
>>>
>>> Now, if we are to bind the PW's to co-routed/bi-directiona= l LSP's, or
>>> extend the binding policy in multi-hop PW scenarios, we'd = have to make
>>> the binding request as a part of the PW negotiation. This is t= he
>>> intent of the draft.
>>>
>>> - Ping
>
>
> If there is only one LSP per tunnel, then you still didn't answer = the
> question as to why the LSP_ID is needed.
>
> I've stated very clearly why the LSP_ID is bad. =A0If you do
> make-before-break, or swithc from working to protect in GMPLS
> protection, you have to resignal all of the affected PW, where without=
> using LSP-ID you don't have to do that.
>
> If you don't have a reason for more than one LSP per tunnel, then<= br> > there is no need for the LSP_ID.
>
> The 16 bit tunnel_num is there for a reason. =A0It allows 64K tunnels<= br> > between any two LSR. =A0The LSP_ID allows more than one LSP per tunnel= ,
> but generally it is one except during a brief transition period that > occurs in make-before-break reroute.

=A0 =A0 =A0 =A0I agree with you Curtis. There are already mech= anisms in place
for choosing paths for PWs in the various popular implementations that
let you nail down which path (or paths) are allowed to be chosen. This
is available for all of the applications (l3VPN, l2VPN, PWs, static)
as far as I can tell BTW.

=A0 =A0 =A0 =A0--Tom


>
> Curtis
>
>
>>> On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar <curtis@occnc.com> wrote:
>>>
>>>>
>>>> In message <
>>>> F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@S= ZXEML511-MBX.china.huawei.com>
>>>> Mach Chen writes:
>>>>>
>>>>> Hi Curtis,
>>>>>
>>>>> Thanks for your comments!
>>>>>
>>>>> As Ping said, we have changed the draft to include tun= nel option and
>>>>> make it as the default, and at the same time, keeps th= e LSP option
>>>>> (OPTINAL) hence to give the capability for explicit bi= nding/moving a
>>>>> PW to a specific LSP when needed.
>>>>>
>>>>> Best regards,
>>>>> Mach
>>>>
>>>>
>>>> Mach,
>>>>
>>>> Can you cite any case where it is needed, where more than = one LSP is
>>>> bound to a tunnel and it is not otherwise obvious which LS= P to use.
>>>> In both the make-before-break reroute case and the GMPLS p= rotection
>>>> case it is possible to determine which LSP to bind to. =A0= If there is
>>>> another case where this is not true, please point it out.<= br> >>>>
>>>> Curtis
>>>>
>>>>
>>>>>> Mach,
>>>>>>
>>>>>> This draft has more information but it has the sam= e problem I pointed
>>>>>> out in the -02 version.
>>>>>>
>>>>>> The LSP is identified, not the tunnel. =A0The tunn= el should be
>>>>>> identified. =A0In a make-before-break reroute the = tunnel remains
>>>>>> constant but the LSP changes.
>>>>>>
>>>>>> When an LSP reroutes for whatever reason, it may b= e carrying a large
>>>>>> number of PW. =A0After the make-before-break rerou= te completes, the old
>>>>>> LSP no longer exists. =A0It should not be necessar= y to resignal the PW
>>>>>> to reroute the LSP. =A0With the text you have, usi= ng the LSP numbers,
>>>>>> that reroute of all the carried PW would be necess= ary.
>>>>>>
>>>>>> There is only one active LSP for any given tunnel.= =A0How the active LSP
>>>>>> is identified, relative to any other LSP is out of= scope for this
>>>>>> document. =A0There may be a working and protect or= a working and protect
>>>>>> and new working and a new protect during a make-be= fore-break
>>>>>> transition. =A0The IP traffic on an LSP and all LS= P carried by a
>>>>>> hierarchical LSP automatically move during a make-= before-break
>>>>>> reroute. =A0The PW should also move without any ad= ditional and totally
>>>>>> unecessare signaling.
>>>>>
>>>>> There may be requirement for doing PW
>>>>>
>>>>> Best regards,
>>>>> Mach
>>>>>
>>>>>>
>>>>>> Curtis
>>>>>>
>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>>>>>> Sent: Tuesday, June 28, 2011 5:49 PM
>>>>>>>> To: Mach Chen
>>>>>>>> Cc: p= pan@infinera.com; attila.= takacs@ericsson.com; Mach Chen;
>>>> Wayne
>>>>>>>> Cao(wei)
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-0= 3.txt
>>>>>>>>
>>>>>>>> A new version of I-D,
>>>> draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has
>>>>>> been
>>>>>>>> successfully submitted by Mach(Guoyi) Chen= and posted to the IETF
>>>>>> repository.
>>>>>>>>
>>>>>>>> Filename: =A0 =A0 =A0 =A0draft-cao-pwe3-mp= ls-tp-pw-over-bidir-lsp
>>>>>>>> Revision: =A0 =A0 =A0 =A003
>>>>>>>> Title: =A0 LDP extensions for Explicit Pse= udowire to transport LSP
>>>>>>>> mapping
>>>>>>>> Creation date: =A0 2011-06-28
>>>>>>>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Subm= ission
>>>>>>>> Number of pages: 16
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>> =A0 A bidirectional Pseudowire (PW) servic= e currently uses two
>>>>>>>> =A0 unidirectional PWs each carried over a= unidirectional LSP. =A0Each
>>>> end
>>>>>>>> =A0 point of a PW or segment of multi-segm= ent PW (MS-PW)
>>>> independently
>>>>>>>> =A0 selects the LSP to use to carry the PW= for which it is the head
>>>> end.
>>>>>>>>
>>>>>>>> =A0 Some transport services may require th= at bidirectional PW
>>>> traffic
>>>>>>>> =A0 follows the same paths through the net= work in both directions.
>>>>>>>> =A0 Therefore, PWs may be required to use = LSP with congruent paths.
>>>>>>>> =A0 Bidirectional LSPs or co-routed associ= ated unidirectional LSPs
>>>> allow
>>>>>>>> =A0 this service to be provided.
>>>>>>>>
>>>>>>>> =A0 This document specifies an optional ex= tension to LDP that allows
>>>> both
>>>>>>>> =A0 ends of a PW (or segment of a MS-PW) t= o select and bind to the
>>>> same
>>>>>>>> =A0 bidirectional LSP (or co-routed unidir= ectional LSPs).
> ________________________= _______________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>


--20cf30563ed71cb01b04a81f63ae-- From curtis@occnc.com Fri Jul 15 10:59:00 2011 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 E7A8A21F8BFC for ; Fri, 15 Jul 2011 10:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR0TAQhfUVvf for ; Fri, 15 Jul 2011 10:59:00 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D76B721F8BB5 for ; Fri, 15 Jul 2011 10:58:59 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FHwsWp096390; Fri, 15 Jul 2011 13:58:54 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151758.p6FHwsWp096390@harbor.orleans.occnc.com> To: Ping Pan From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 10:40:25 PDT." Date: Fri, 15 Jul 2011 13:58:54 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:59:01 -0000 In message Ping Pan writes: > > > > > Curtis, > > > > > > > > Today, there are multiple options in binding PW's to the underlying > > > > LSP's on a local PE. Some of the policies I have seen include: random > > > > (binding PW's to one of the multiple LSP tunnels randomly), least-fill > > > > (binding PW's to the ones with most available BW), > > > > most-fill... etc. (I know, copying a similar feature from > > > > Juniper). Given the current binding does not involve any protocol > > > > change, don't think most people would notice. > > > > > > > > Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or > > > > extend the binding policy in multi-hop PW scenarios, we'd have to make > > > > the binding request as a part of the PW negotiation. This is the > > > > intent of the draft. > > > > > > > > - Ping > > > > > > If there is only one LSP per tunnel, then you still didn't answer the > > question as to why the LSP_ID is needed. > > > > I've stated very clearly why the LSP_ID is bad. If you do > > make-before-break, or swithc from working to protect in GMPLS > > protection, you have to resignal all of the affected PW, where without > > using LSP-ID you don't have to do that. > > > > > Then turn-on the T-flag, and get on with it. So the answer is that there is no use for the T=0 case, just use the T=1 case and ignore it? The question, which was lost in all the top posting was: > Can you cite any case where it is needed, where more than one LSP is > bound to a tunnel and it is not otherwise obvious which LSP to use. > In both the make-before-break reroute case and the GMPLS protection > case it is possible to determine which LSP to bind to. If there is > another case where this is not true, please point it out. Care to answer? So far your only answer is "Then turn-on the T-flag, and get on with it." Curtis > > If you don't have a reason for more than one LSP per tunnel, then > > there is no need for the LSP_ID. > > > > The 16 bit tunnel_num is there for a reason. It allows 64K tunnels > > between any two LSR. The LSP_ID allows more than one LSP per tunnel, > > but generally it is one except during a brief transition period that > > occurs in make-before-break reroute. > > > > Curtis > > > > > > > > On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar > > wrote: > > > > > > > > > > > > > > In message < > > > > > > > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> > > > > > Mach Chen writes: > > > > > > > > > > > > Hi Curtis, > > > > > > > > > > > > Thanks for your comments! > > > > > > > > > > > > As Ping said, we have changed the draft to include tunnel option > > and > > > > > > make it as the default, and at the same time, keeps the LSP option > > > > > > (OPTINAL) hence to give the capability for explicit binding/moving > > a > > > > > > PW to a specific LSP when needed. > > > > > > > > > > > > Best regards, > > > > > > Mach > > > > > > > > > > > > > > > Mach, > > > > > > > > > > Can you cite any case where it is needed, where more than one LSP is > > > > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > > > > In both the make-before-break reroute case and the GMPLS protection > > > > > case it is possible to determine which LSP to bind to. If there is > > > > > another case where this is not true, please point it out. > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > Mach, > > > > > > > > > > > > > > This draft has more information but it has the same problem I > > pointed > > > > > > > out in the -02 version. > > > > > > > > > > > > > > The LSP is identified, not the tunnel. The tunnel should be > > > > > > > identified. In a make-before-break reroute the tunnel remains > > > > > > > constant but the LSP changes. > > > > > > > > > > > > > > When an LSP reroutes for whatever reason, it may be carrying a > > large > > > > > > > number of PW. After the make-before-break reroute completes, the > > old > > > > > > > LSP no longer exists. It should not be necessary to resignal the > > PW > > > > > > > to reroute the LSP. With the text you have, using the LSP > > numbers, > > > > > > > that reroute of all the carried PW would be necessary. > > > > > > > > > > > > > > There is only one active LSP for any given tunnel. How the > > active LSP > > > > > > > is identified, relative to any other LSP is out of scope for this > > > > > > > document. There may be a working and protect or a working and > > protect > > > > > > > and new working and a new protect during a make-before-break > > > > > > > transition. The IP traffic on an LSP and all LSP carried by a > > > > > > > hierarchical LSP automatically move during a make-before-break > > > > > > > reroute. The PW should also move without any additional and > > totally > > > > > > > unecessare signaling. > > > > > > > > > > > > There may be requirement for doing PW > > > > > > > > > > > > Best regards, > > > > > > Mach > > > > > > > > > > > > > > > > > > > > Curtis > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: internet-drafts@ietf.org [mailto: > > internet-drafts@ietf.org] > > > > > > > > > Sent: Tuesday, June 28, 2011 5:49 PM > > > > > > > > > To: Mach Chen > > > > > > > > > Cc: ppan@infinera.com; attila.takacs@ericsson.com; Mach > > Chen; > > > > > Wayne > > > > > > > > > Cao(wei) > > > > > > > > > Subject: New Version Notification for > > > > > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > > > > > > > > > > > > > > > A new version of I-D, > > > > > draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt has > > > > > > > been > > > > > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the > > IETF > > > > > > > repository. > > > > > > > > > > > > > > > > > > Filename: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp > > > > > > > > > Revision: 03 > > > > > > > > > Title: LDP extensions for Explicit Pseudowire to transport > > LSP > > > > > > > > > mapping > > > > > > > > > Creation date: 2011-06-28 > > > > > > > > > WG ID: Individual Submission > > > > > > > > > Number of pages: 16 > > > > > > > > > > > > > > > > > > Abstract: > > > > > > > > > A bidirectional Pseudowire (PW) service currently uses two > > > > > > > > > unidirectional PWs each carried over a unidirectional LSP. > > Each > > > > > end > > > > > > > > > point of a PW or segment of multi-segment PW (MS-PW) > > > > > independently > > > > > > > > > selects the LSP to use to carry the PW for which it is the > > head > > > > > end. > > > > > > > > > > > > > > > > > > Some transport services may require that bidirectional PW > > > > > traffic > > > > > > > > > follows the same paths through the network in both > > directions. > > > > > > > > > Therefore, PWs may be required to use LSP with congruent > > paths. > > > > > > > > > Bidirectional LSPs or co-routed associated unidirectional > > LSPs > > > > > allow > > > > > > > > > this service to be provided. > > > > > > > > > > > > > > > > > > This document specifies an optional extension to LDP that > > allows > > > > > both > > > > > > > > > ends of a PW (or segment of a MS-PW) to select and bind to > > the > > > > > same > > > > > > > > > bidirectional LSP (or co-routed unidirectional LSPs). From ping@pingpan.org Fri Jul 15 11:04:02 2011 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 60ED821F8BE2 for ; Fri, 15 Jul 2011 11:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDONM2GkJVos for ; Fri, 15 Jul 2011 11:04:01 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with SMTP id 1B2E321F8BE1 for ; Fri, 15 Jul 2011 11:04:01 -0700 (PDT) Received: from mail-gy0-f173.google.com ([209.85.160.173]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTiCBEHrnTPuddwxxeQcbTddNeDUfznJE@postini.com; Fri, 15 Jul 2011 11:04:01 PDT Received: by mail-gy0-f173.google.com with SMTP id 2so716215gyf.4 for ; Fri, 15 Jul 2011 11:04:00 -0700 (PDT) Received: by 10.236.182.36 with SMTP id n24mr1382319yhm.513.1310753040293; Fri, 15 Jul 2011 11:04:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Fri, 15 Jul 2011 11:03:20 -0700 (PDT) In-Reply-To: <201107151758.p6FHwsWp096390@harbor.orleans.occnc.com> References: <201107151758.p6FHwsWp096390@harbor.orleans.occnc.com> From: Ping Pan Date: Fri, 15 Jul 2011 11:03:20 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf30563a015addd104a81f79e5 Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 18:04:02 -0000 --20cf30563a015addd104a81f79e5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 15, 2011 at 10:58 AM, Curtis Villamizar wrote: > > In message 6BQuZdxxqvPTJM3Vd4yLm-AjKrf2qVSNOx+m1azw@mail.gmail.com> > Ping Pan writes: > > > > > > > Curtis, > > > > > > > > > > Today, there are multiple options in binding PW's to the underlying > > > > > LSP's on a local PE. Some of the policies I have seen include: > random > > > > > (binding PW's to one of the multiple LSP tunnels randomly), > least-fill > > > > > (binding PW's to the ones with most available BW), > > > > > most-fill... etc. (I know, copying a similar feature from > > > > > Juniper). Given the current binding does not involve any protocol > > > > > change, don't think most people would notice. > > > > > > > > > > Now, if we are to bind the PW's to co-routed/bi-directional LSP's, > or > > > > > extend the binding policy in multi-hop PW scenarios, we'd have to > make > > > > > the binding request as a part of the PW negotiation. This is the > > > > > intent of the draft. > > > > > > > > > > - Ping > > > > > > > > > If there is only one LSP per tunnel, then you still didn't answer the > > > question as to why the LSP_ID is needed. > > > > > > I've stated very clearly why the LSP_ID is bad. If you do > > > make-before-break, or swithc from working to protect in GMPLS > > > protection, you have to resignal all of the affected PW, where without > > > using LSP-ID you don't have to do that. > > > > > > > > Then turn-on the T-flag, and get on with it. > > > So the answer is that there is no use for the T=0 case, just use the > T=1 case and ignore it? > > The question, which was lost in all the top posting was: > > > Can you cite any case where it is needed, where more than one LSP is > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > In both the make-before-break reroute case and the GMPLS protection > > case it is possible to determine which LSP to bind to. If there is > > another case where this is not true, please point it out. > > Care to answer? So far your only answer is "Then turn-on the T-flag, > and get on with it." > > Curtis > > > Curtis, For those who have other means to protect user traffic other than FRR, they have the option to turn T-flag off. Is this better? ;-) - Ping --20cf30563a015addd104a81f79e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 15, 2011 at 10:58 AM, Curtis Vi= llamizar <curtis@o= ccnc.com> wrote:

In message <CAHEV9L1W8=3D6BQuZdxxqvPTJM3Vd4yLm-AjKrf2qVSNOx+m1azw@mail= .gmail.com>
Ping Pan writes:
>
> > > > Curtis,
> > > >
> > > > Today, there are multiple options in binding PW's t= o the underlying
> > > > LSP's on a local PE. Some of the policies I have se= en include: random
> > > > (binding PW's to one of the multiple LSP tunnels ra= ndomly), least-fill
> > > > (binding PW's to the ones with most available BW),<= br> > > > > most-fill... etc. (I know, copying a similar feature fr= om
> > > > Juniper). Given the current binding does not involve an= y protocol
> > > > change, don't think most people would notice.
> > > >
> > > > Now, if we are to bind the PW's to co-routed/bi-dir= ectional LSP's, or
> > > > extend the binding policy in multi-hop PW scenarios, we= 'd have to make
> > > > the binding request as a part of the PW negotiation. Th= is is the
> > > > intent of the draft.
> > > >
> > > > - Ping
> >
> >
> > If there is only one LSP per tunnel, then you still didn't an= swer the
> > question as to why the LSP_ID is needed.
> >
> > I've stated very clearly why the LSP_ID is bad. =A0If you do<= br> > > make-before-break, or swithc from working to protect in GMPLS
> > protection, you have to resignal all of the affected PW, where wi= thout
> > using LSP-ID you don't have to do that.
> >
> >
> Then turn-on the T-flag, and get on with it.


So the answer is that there is no use for the T=3D0 case, just use th= e
T=3D1 case and ignore it?

The question, which was lost in all the top posting was:

=A0> Can you cite any case where it is needed, where more than one LSP i= s
=A0> bound to a tunnel and it is not otherwise obvious which LSP to use.=
=A0> In both the make-before-break reroute case and the GMPLS protection=
=A0> case it is possible to determine which LSP to bind to. =A0If there = is
=A0> another case where this is not true, please point it out.

Care to answer? =A0So far your only answer is "Then turn-on the = T-flag,
and get on with it."

Curtis



Curtis,=A0

<= div>For those who have other means to protect user traffic other than FRR, = they have the option to turn T-flag off.

Is this b= etter? ;-)

- Ping

--20cf30563a015addd104a81f79e5-- From curtis@occnc.com Fri Jul 15 11:53:49 2011 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 50C0A21F8C2A for ; Fri, 15 Jul 2011 11:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9ndjmLHt+X9 for ; Fri, 15 Jul 2011 11:53:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5157F21F8C01 for ; Fri, 15 Jul 2011 11:53:48 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FIriH7098315; Fri, 15 Jul 2011 14:53:44 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151853.p6FIriH7098315@harbor.orleans.occnc.com> To: Ping Pan From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 10:57:07 PDT." Date: Fri, 15 Jul 2011 14:53:44 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 18:53:49 -0000 In message Ping Pan writes: > > Hi, > > I think we are talking over each other. ;-) Let me try to describe an > example here: > > A --- B ---- C ---- D > > A and D and Ethernet CE's. B and C are PE's. Between B and C, we have > a transport network, say, GMPLS-enabled optical transport network. > > There are tons of VLAN circuits between A and D, and there are > multiple optical connections (as in GMPLS LSP's) between B and C. The > connections take different path onto different fiber etc. > > On B and C, each uni-directional Ethernet VLAN is mapped to a PW. And > we need to make sure of the mapping for each bi-directional Ethernet > circuit onto a bi-directional LSP. > > There are two ways to go about: > > 1. Configure both ends > 2. Do something intelligent during the setup time (as described in > this draft). > > There is no make-before-break in optical network. > > Now, extending it further, this apply to co-routed MPLS LSP's, And > MHOP PW needs to be addressed. > > Hope this helps. Yes. it helps underscore that fact that you don't get it. There is no need for one LSP per PW from B to C. All of the PW can ride within one LSP (and that is the typical case). If there is one LSP per PW, then there is still one LSP per tunnel. If there is a make-before-break reroute of B-C (assuming these are T-PE and there are other nodes between these two) the the PW don't need to be resignaled. The tunnel_ID is sufficient to identify the thing that the PW needs to map to. That is the point that you are still not getting. Maybe if you didn't top post without thoroughly reading the question you are top posting over, you maight see the original question and see what it was that Tom was agreeing with. They are still part of this email, though I trimmed beyond that. > - Ping Curtis > On Fri, Jul 15, 2011 at 10:15 AM, Thomas Nadeau wrote: > > > > > On Jul 15, 2011, at 1:08 PM, Curtis Villamizar wrote: > > > > > > > > In message < > > CAHEV9L2TxfK86qCN7410aC8xpcTQ71XLm-p1dm49QLEF2nxOSg@mail.gmail.com> > > > Ping Pan writes: > > >> > > >>> > > >>> Curtis, > > >>> > > >>> Today, there are multiple options in binding PW's to the underlying > > >>> LSP's on a local PE. Some of the policies I have seen include: random > > >>> (binding PW's to one of the multiple LSP tunnels randomly), least-fill > > >>> (binding PW's to the ones with most available BW), > > >>> most-fill... etc. (I know, copying a similar feature from > > >>> Juniper). Given the current binding does not involve any protocol > > >>> change, don't think most people would notice. > > >>> > > >>> Now, if we are to bind the PW's to co-routed/bi-directional LSP's, or > > >>> extend the binding policy in multi-hop PW scenarios, we'd have to make > > >>> the binding request as a part of the PW negotiation. This is the > > >>> intent of the draft. > > >>> > > >>> - Ping > > > > > > > > > If there is only one LSP per tunnel, then you still didn't answer the > > > question as to why the LSP_ID is needed. > > > > > > I've stated very clearly why the LSP_ID is bad. If you do > > > make-before-break, or swithc from working to protect in GMPLS > > > protection, you have to resignal all of the affected PW, where without > > > using LSP-ID you don't have to do that. > > > > > > If you don't have a reason for more than one LSP per tunnel, then > > > there is no need for the LSP_ID. > > > > > > The 16 bit tunnel_num is there for a reason. It allows 64K tunnels > > > between any two LSR. The LSP_ID allows more than one LSP per tunnel, > > > but generally it is one except during a brief transition period that > > > occurs in make-before-break reroute. > > > > I agree with you Curtis. There are already mechanisms in place > > for choosing paths for PWs in the various popular implementations that > > let you nail down which path (or paths) are allowed to be chosen. This > > is available for all of the applications (l3VPN, l2VPN, PWs, static) > > as far as I can tell BTW. > > > > --Tom > > > > > > > > > > Curtis > > > > > > > > >>> On Fri, Jul 15, 2011 at 7:21 AM, Curtis Villamizar > > wrote: > > >>> > > >>>> > > >>>> In message < > > >>>> > > F73A3CB31E8BE34FA1BBE3C8F0CB2AE2019C4E4E@SZXEML511-MBX.china.huawei.com> > > >>>> Mach Chen writes: > > >>>>> > > >>>>> Hi Curtis, > > >>>>> > > >>>>> Thanks for your comments! > > >>>>> > > >>>>> As Ping said, we have changed the draft to include tunnel option and > > >>>>> make it as the default, and at the same time, keeps the LSP option > > >>>>> (OPTINAL) hence to give the capability for explicit binding/moving a > > >>>>> PW to a specific LSP when needed. > > >>>>> > > >>>>> Best regards, > > >>>>> Mach > > >>>> > > >>>> > > >>>> Mach, > > >>>> > > >>>> Can you cite any case where it is needed, where more than one LSP is > > >>>> bound to a tunnel and it is not otherwise obvious which LSP to use. > > >>>> In both the make-before-break reroute case and the GMPLS protection > > >>>> case it is possible to determine which LSP to bind to. If there is > > >>>> another case where this is not true, please point it out. > > >>>> > > >>>> Curtis > [ ... trim ... ] From curtis@occnc.com Fri Jul 15 12:16:04 2011 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 CA67B21F8BF1 for ; Fri, 15 Jul 2011 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeLU8s1nSN4O for ; Fri, 15 Jul 2011 12:16:04 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD221F8426 for ; Fri, 15 Jul 2011 12:16:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6FJG01H099037; Fri, 15 Jul 2011 15:16:00 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107151916.p6FJG01H099037@harbor.orleans.occnc.com> To: Ping Pan From: Curtis Villamizar In-reply-to: Your message of "Fri, 15 Jul 2011 11:03:20 PDT." Date: Fri, 15 Jul 2011 15:16:00 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 19:16:04 -0000 In message Ping Pan writes: > > On Fri, Jul 15, 2011 at 10:58 AM, Curtis Villamizar wrote: > > > > > In message > 6BQuZdxxqvPTJM3Vd4yLm-AjKrf2qVSNOx+m1azw@mail.gmail.com> > > Ping Pan writes: > > > > > > > > > Curtis, > > > > > > > > > > > > Today, there are multiple options in binding PW's to the underlying > > > > > > LSP's on a local PE. Some of the policies I have seen include: > > random > > > > > > (binding PW's to one of the multiple LSP tunnels randomly), > > least-fill > > > > > > (binding PW's to the ones with most available BW), > > > > > > most-fill... etc. (I know, copying a similar feature from > > > > > > Juniper). Given the current binding does not involve any protocol > > > > > > change, don't think most people would notice. > > > > > > > > > > > > Now, if we are to bind the PW's to co-routed/bi-directional LSP's, > > or > > > > > > extend the binding policy in multi-hop PW scenarios, we'd have to > > make > > > > > > the binding request as a part of the PW negotiation. This is the > > > > > > intent of the draft. > > > > > > > > > > > > - Ping > > > > > > > > > > > > If there is only one LSP per tunnel, then you still didn't answer the > > > > question as to why the LSP_ID is needed. > > > > > > > > I've stated very clearly why the LSP_ID is bad. If you do > > > > make-before-break, or swithc from working to protect in GMPLS > > > > protection, you have to resignal all of the affected PW, where without > > > > using LSP-ID you don't have to do that. > > > > > > > > > > > Then turn-on the T-flag, and get on with it. > > > > > > So the answer is that there is no use for the T=0 case, just use the > > T=1 case and ignore it? > > > > The question, which was lost in all the top posting was: > > > > > Can you cite any case where it is needed, where more than one LSP is > > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > > In both the make-before-break reroute case and the GMPLS protection > > > case it is possible to determine which LSP to bind to. If there is > > > another case where this is not true, please point it out. > > > > Care to answer? So far your only answer is "Then turn-on the T-flag, > > and get on with it." > > > > Curtis > > > > > > > Curtis, > > For those who have other means to protect user traffic other than FRR, > they have the option to turn T-flag off. > > Is this better? ;-) > > - Ping Please refer to RFC 4872 section 14, PROTECTION Object. Secondary (S): 1 bit When set to 1, this bit indicates that the requested LSP is a secondary LSP. When set to 0 (default), it indicates that the requested LSP is a primary LSP. Protecting (P): 1 bit When set to 1, this bit indicates that the requested LSP is a protecting LSP. When set to 0 (default), it indicates that the requested LSP is a working LSP. The combination, S set to 1 with P set to 0 is not valid. [ ... ] Operational (O): 1 bit When set to 1, this bit indicates that the protecting LSP is carrying the normal traffic after protection switching. The O bit is only applicable when the P bit is set to 1, and the LSP Protection Type Flag is set to either 0x04 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10 (1+1 Bidirectional Protection). The O bit MUST be set to 0 in any other case. If there is a working and protect LSP it is possible to determine which LSP is the working LSP. It is also possible to tell when the other end has switched over to the protect for some reason. Do you know of a protection mechansism besides FRR and GMPLS protection where this would not work? If the LSPs are static, with no control plane at all, then there is nothing to signal through and this draft has no purpose. If there is a control plane it is easy to determine which LSPs are working LSP and which LSPs are used for protection. So again: > > > Can you cite any case where it is needed, where more than one LSP is > > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > > In both the make-before-break reroute case and the GMPLS protection > > > case it is possible to determine which LSP to bind to. If there is > > > another case where this is not true, please point it out. Thanks for the continued replies. If you can't answer this question, you need to take out the T bit and only support the T=1 functionality. Curtis From ping@pingpan.org Fri Jul 15 14:28:37 2011 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 0297121F8B04 for ; Fri, 15 Jul 2011 14:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtjwr9KJbgPq for ; Fri, 15 Jul 2011 14:28:36 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with SMTP id 21E3121F8B05 for ; Fri, 15 Jul 2011 14:28:36 -0700 (PDT) Received: from mail-yi0-f52.google.com ([209.85.218.52]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTiCxA9I4Igv4zorh2vNygUudZXTSStHv@postini.com; Fri, 15 Jul 2011 14:28:36 PDT Received: by mail-yi0-f52.google.com with SMTP id 19so1119836yie.11 for ; Fri, 15 Jul 2011 14:28:35 -0700 (PDT) Received: by 10.236.154.194 with SMTP id h42mr1514060yhk.379.1310765315383; Fri, 15 Jul 2011 14:28:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.105.242 with HTTP; Fri, 15 Jul 2011 14:27:55 -0700 (PDT) In-Reply-To: <201107151916.p6FJG01H099037@harbor.orleans.occnc.com> References: <201107151916.p6FJG01H099037@harbor.orleans.occnc.com> From: Ping Pan Date: Fri, 15 Jul 2011 14:27:55 -0700 Message-ID: To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf303f661e01e26204a822557c Cc: "pwe3@ietf.org" , "Wayne Cao\(wei\)" Subject: Re: [PWE3] New Version Notification for draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 21:28:37 -0000 --20cf303f661e01e26204a822557c Content-Type: text/plain; charset=ISO-8859-1 > > > If there is a working and protect LSP it is possible to determine > which LSP is the working LSP. It is also possible to tell when the > other end has switched over to the protect for some reason. > > Do you know of a protection mechansism besides FRR and GMPLS > protection where this would not work? > > Curtis, Yes. The center of the debate is if we should only represent PW's LSP with the Tunnel-id, given information could be gathered in FRR etc. Correct? I prefer to leave the flexibility in at this point, as there are other protecting schemes and deployment scenarios that are not bounded to the constraints as defined in FRR. If you prefer, we can chat directly offline. Ping > If the LSPs are static, with no control plane at all, then there is > nothing to signal through and this draft has no purpose. If there is > a control plane it is easy to determine which LSPs are working LSP and > which LSPs are used for protection. > > So again: > > > > > Can you cite any case where it is needed, where more than one LSP is > > > > bound to a tunnel and it is not otherwise obvious which LSP to use. > > > > In both the make-before-break reroute case and the GMPLS protection > > > > case it is possible to determine which LSP to bind to. If there is > > > > another case where this is not true, please point it out. > > Thanks for the continued replies. If you can't answer this question, > you need to take out the T bit and only support the T=1 functionality. > > Curtis > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --20cf303f661e01e26204a822557c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If there is a working and protect LSP it is possible to determine
which LSP is the working LSP. =A0It is also possible to tell when the
other end has switched over to the protect for some reason.

Do you know of a protection mechansism besides FRR and GMPLS
protection where this would not work?


Curtis,

Yes. = The center of the debate is if we should only represent PW's LSP with t= he Tunnel-id, given information could be gathered in FRR etc. Correct?

I prefer to leave the flexibility in at this point, as = there are other protecting schemes and deployment=A0scenarios=A0that are no= t bounded to the constraints as defined in FRR.

If= you prefer, we can chat directly offline.=A0

Ping

=A0
If the LSPs are static, with no control plane at all, then there is
nothing to signal through and this draft has no purpose. =A0If there is
a control plane it is easy to determine which LSPs are working LSP and
which LSPs are used for protection.

So again:

> > =A0> Can you cite any case where it is needed, where more than= one LSP is
> > =A0> bound to a tunnel and it is not otherwise obvious which L= SP to use.
> > =A0> In both the make-before-break reroute case and the GMPLS = protection
> > =A0> case it is possible to determine which LSP to bind to. = =A0If there is
> > =A0> another case where this is not true, please point it out.=

Thanks for the continued replies. =A0If you can't answer this que= stion,
you need to take out the T bit and only support the T=3D1 functionality.
Curtis
__________________________________= _____________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--20cf303f661e01e26204a822557c-- From liu.guoman@zte.com.cn Sun Jul 17 18:11:12 2011 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 0EE0121F84ED for ; Sun, 17 Jul 2011 18:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChgW5eUanRS7 for ; Sun, 17 Jul 2011 18:11:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 32D0621F84CB for ; Sun, 17 Jul 2011 18:11:10 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Mon, 18 Jul 2011 09:05:45 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 52304.1397396305; Mon, 18 Jul 2011 09:10:59 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p6I1B0fH064676 for ; Mon, 18 Jul 2011 09:11:00 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6I158Qj058382; Mon, 18 Jul 2011 09:05:08 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201107180111.p6I1B0fH064676@mse02.zte.com.cn> In-Reply-To: To: Giles Heron MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Mon, 18 Jul 2011 09:05:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-18 09:05:09, Serialize complete at 2011-07-18 09:05:09 Content-Type: multipart/alternative; boundary="=_alternative 00062212482578D1_=" X-MAIL: mse02.zte.com.cn p6I1B0fH064676 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: pwe3@ietf.org Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-04.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:11:12 -0000 This is a multipart message in MIME format. --=_alternative 00062212482578D1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksR2lsZXMNCmknbSB2ZXJ5IHRoYW5rZnVsIHRvICB5b3UgZm9yIGFuc3dlcmluZyB0aGUgcXVl c3Rpb25zLiANCmFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nLCBmb3IgYWxsIGxlYWYgbm9k ZXMgb2YgdGhlIHAybXAgTFNQLA0KdGhleSBtdXN0IGJlIGJhc2VkIG9uIGJvdGggUDJNUCBMU1Ag bGFiZWwgYW5kIFBXIGxhYmVsIHRvIGlkZW50aWZ5IA0Kd2hldGhlciB0aGUgdHJhZmZpYyBpcyB0 aGVpciB3YW50ZWQgb3IgdW53YW50ZWQgdHJhZmZpYy4NCml0IGNhbid0IGlkZW50aWZ5IHRoZSB0 cmFmZmljIGlzIHRoZWlyIHdhbnRlZCB0cmFmZmljIG9ubHkgYmFzZWQgb24NCnB3IGxhYmVsLg0K aXMgbXkgdW5kZXJzdGFuZGluZyBmYWxzZT8gDQppbiBhZGR0aW9uLCBJbiBteSBtaW5kLCBpdCBp cyBiZXR0ZXIgdG8gY2xhcmlmeSB0aGlzIHNlY3Rpb24gcGFydCANCmZ1cnRoZXJseSBjbGVhcmx5 Lg0KDQpCLlIuDQpsaXUNCg0KDQoNCg0KDQoNCg0KR2lsZXMgSGVyb24gPGdpbGVzLmhlcm9uQGdt YWlsLmNvbT4gDQoyMDExLTA3LTE1IDIzOjMxDQoNCsrVvP7Iyw0KPGxpdS5ndW9tYW5AenRlLmNv bS5jbj4sIDxwd2UzQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpSZTogW1BXRTNdIEktRCBBQ1RJ T046ZHJhZnQtaWV0Zi1wd2UzLXAybXAtcHctcmVxdWlyZW1lbnRzLTA0LnR4dA0KDQoNCg0KDQoN Cg0KSGkgTGl1LA0KDQoxKSBJbiB0aGUgY2FzZSBvZiBhIG5vbi1sZWFmIFBFIGl0IHdvdWxkIHJl Y2VpdmUgdHJhZmZpYyBvbiB0aGUgUDJNUCBMU1AgDQpidXQNCndvdWxkbid0IGhhdmUgYSB2YWxp ZCBQVyBsYWJlbCB0byBkZW11bHRpcGxleCB0aGUgdHJhZmZpYy4gIEluIHRoZSBQMk1QIA0KTFNQ DQpjYXNlIHRoZSBQVyBsYWJlbCBpcyB2YWxpZCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIFAy TVAgTFNQIHNvIHRoZQ0Kbm9uLWxlYWYgUEUgd29uJ3QgaGF2ZSB0aGUgbGFiZWwgYXNzaWduZWQg Zm9yIG90aGVyIHRyYWZmaWMuDQoNCjIpIFllcyB0aGUgbm9uLWxlYWYgUEUgd291bGQganVzdCBk aXNjYXJkIHRoZSB1bndhbnRlZCB0cmFmZmljLg0KDQpCdXQgc3VyZSwgbWlnaHQgYmUgd29ydGgg Y2xhcmlmeWluZyB0aGlzIGluIHRoZSBkcmFmdC4uLg0KDQpHaWxlcw0KDQpPbiAxNC8wNy8yMDEx IDExOjQ5LCAibGl1Lmd1b21hbkB6dGUuY29tLmNuIiA8bGl1Lmd1b21hbkB6dGUuY29tLmNuPiAN Cndyb3RlOg0KDQo+IGhpLGF1dGhvcnMNCj4gaSByZXZpZXcgdGhpcyBkcmFmdCB0b2RheS4gaSBo YXZlIGEgZmV3IHF1ZXN0aW9uIGZvciBzZWN0aW9uIDMuMiBQMk1QDQo+IFNTLVBXIFVuZGVybHlp bmcgTGF5ZXIgLg0KPiBpbiB0aGUgc2VjdGlvbiwgdGhlcmUgaXMgdGhlIGZvbGxvd2luZyBwYXJh Z3JhcGggY29udGV4dDoNCj4gIiAgIEFzIGFuIGV4YW1wbGUgYW4gZXhpc3RpbmcgUDJNUCBMU1Ag bWF5IGF0dGFjaA0KPiAgICBtb3JlIGxlYXZlcyB0aGFuIHRoZSBvbmVzIGRlZmluZWQgYXMgTGVh ZiBQRXMgZm9yIGEgZ2l2ZW4gUDJNUCBQVy4gSXQNCj4gICAgbWF5IGJlIGludGVyZXN0aW5nIHRv IHJldXNlIGl0IHRvIG1pbmltaXplIG5ldyBjb25maWd1cmF0aW9uLCBidXQNCj4gICAgdXNpbmcg dGhpcyBQMk1QIExTUCB3b3VsZCBpbXBseSBub24tTGVhZiBQRXMgcmVjZWl2ZSB1bndhbnRlZA0K PiAgICB0cmFmZmljLCBub3QgZGVzdGluZWQgdG8gTGVhZiBQRSBhdCB0aGUgc2VydmljZSBsYXll ciINCj4gDQo+ICAgICAgICAgIFExOiBob3cgZG8gbm9uLWxlYWYgUEVzIGlkZW50aWZ5IHdoaWNo IHRyYWZmaWMgaXMgdW53YW50ZWQNCj4gdHJhZmZpYyBieSBhIGNvbW1vbiBwMm1wIExTUD8NCj4g ICAgICAgICAgIGRvIHRoZXkgb25seSBiZSBiYXNlZCBvbiBwdyBsYWJlbCB0byBqdWRnZSB0aGUg dHJhZmZpYz8gaWYgc28sDQo+IG1heWJlIHRoZSB2YWx1ZSBvZiB0aGUgcHcgbGFiZWwgaGF2ZSBh bHJlYWR5IGJlZW4gYXNzaWduZWQgZm9yIGFub3RoZXINCj4gd2FudGVkIHRyYWZmaWMsDQo+ICAg ICAgICAgICAgaG93IGRvIHRoZSBub24tbGVhZnMgUEVzIGlkZW50aWZ5IHdoaWNoIHRyYWZmaWMg aXMgdW53YW50ZWQgDQpvcg0KPiB3YW50ZWQgdHJhZmZpYyBmb3IgaXRzZWxmPw0KPiAgICAgICAg ICBRMjogaWYgbm9uLWxlYWYgUEVzIGtub3cgdGhpcyB0cmFmZmljIGlzIHVud2FudGVkIHRyYWZm aWMgLCBkbw0KPiB0aGV5IGRpcmVjdGx5IGFiYW5kb24gdGhlc2UgdHJhZmZpYz8gaSB0aGluayBp dCBuZWNlc3NhcnkgdG8gY2xhcmlmeSBpdCANCmluDQo+IHRoaXMgZHJhZnQuDQo+IA0KPiANCj4g dGhhbmsgeW91IQ0KPiANCj4gDQo+IEIuUi4NCj4gbGl1DQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnDQo+ILeivP7IyzogIHB3ZTMtYm91 bmNlc0BpZXRmLm9yZw0KPiAyMDExLTA3LTA5IDA1OjMwDQo+IA0KPiDK1bz+yMsNCj4gaS1kLWFu bm91bmNlQGlldGYub3JnDQo+ILOty80NCj4gcHdlM0BpZXRmLm9yZw0KPiDW98ziDQo+IFtQV0Uz XSBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtcHdlMy1wMm1wLXB3LXJlcXVpcmVtZW50cy0wNC50eHQN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gQSBuZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVzLg0KPiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBQc2V1ZG93aXJlIEVtdWxhdGlvbiBFZGdl IHRvIEVkZ2UgDQpXb3JraW5nDQo+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgIFRpdGxl ICAgICAgICAgOiBSZXF1aXJlbWVudHMgYW5kIEZyYW1ld29yayBmb3IgUG9pbnQtdG8tTXVsdGlw b2ludA0KPiBQc2V1ZG93aXJlDQo+ICAgICBBdXRob3IocykgICAgIDogRy4gSGVyb24sIGV0IGFs DQo+ICAgICBGaWxlbmFtZSAgICAgIDogZHJhZnQtaWV0Zi1wd2UzLXAybXAtcHctcmVxdWlyZW1l bnRzLTA0LnR4dA0KPiAgICAgUGFnZXMgICAgICAgICA6IDIxDQo+ICAgICBEYXRlICAgICAgICAg IDogMjAxMS0wNy0wOA0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNldCBvZiBy ZXF1aXJlbWVudHMgYW5kIGEgZnJhbWV3b3JrIGZvcg0KPiAgICBwcm92aWRpbmcgYSBQb2ludC10 by1NdWx0aXBvaW50IFBzZXVkb3dpcmUgKFBXKS4gVGhlIHJlcXVpcmVtZW50cw0KPiAgICBpZGVu dGlmaWVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIHJlbGF0ZWQgdG8gYXJjaGl0ZWN0dXJlLCBzaWdu YWxpbmcNCj4gICAgYW5kIG1haW50ZW5hbmNlIGFzcGVjdHMgb2YgUG9pbnQtdG8tTXVsdGlwb2lu dCBQVyBvcGVyYXRpb24uIFRoZXkgYXJlDQo+ICAgIHByb3Bvc2VkIGFzIGd1aWRlbGluZXMgZm9y IHRoZSBzdGFuZGFyZGl6YXRpb24gb2Ygc3VjaCBtZWNoYW5pc21zLg0KPiAgICBBbW9uZyBvdGhl ciBwb3RlbnRpYWwgYXBwbGljYXRpb25zIFBvaW50LXRvLU11bHRpcG9pbnQgUFdzIFNIT1VMRCBi ZQ0KPiAgICB1c2VkIHRvIG9wdGltaXplIHRoZSBzdXBwb3J0IG9mIG11bHRpY2FzdCBsYXllciAy IHNlcnZpY2VzIChWaXJ0dWFsDQo+ICAgIFByaXZhdGUgTEFOIFNlcnZpY2UgYW5kIFZpcnR1YWwg UHJpdmF0ZSBNdWx0aWNhc3QgU2VydmljZSkgYXMgZGVmaW5lZA0KPiAgICBpbiB0aGUgTGF5ZXIg MiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayBXb3JraW5nIEdyb3VwLg0KPiANCj4gQSBVUkwgZm9y IHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1wd2UzLXAybXAtcHctcmVxdWlyZW1lbnRzLTA0LnR4DQo+DQp0 DQo+IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4g QmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWls IHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBB U0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRlcm5ldC1EcmFmdC4NCj4gDQpmdHA6Ly9hbm9ueW1v dXNAZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXB3ZTMtcDJtcC1wdy1y ZXF1aXJlbWUNCg0KPiBudHMtMDQudHh0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHB3ZTMgbWFpbGluZyBsaXN0DQo+IHB3ZTNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+IA0KPiANCj4g DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCmlzDQo+IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcw0KPiBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IA0KYW5kIGFyZQ0KPiBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVu ZGVkDQo+IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYNCj4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlDQo+IG1l c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0 aGUgaW5kaXZpZHVhbA0KPiBzZW5kZXIuDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHB3ZTMgbWFpbGlu ZyBsaXN0DQo+IHB3ZTNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wd2UzDQoNCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00062212482578D1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLEdpbGVzPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pJ20gdmVyeSB0aGFua2Z1bCB0byAmbmJz cDt5b3UgZm9yIGFuc3dlcmluZw0KdGhlIHF1ZXN0aW9ucy4gPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hY2NvcmRpbmcgdG8gbXkgdW5kZXJzdGFuZGluZywgZm9y IGFsbA0KbGVhZiBub2RlcyBvZiB0aGUgcDJtcCBMU1AsPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj50aGV5IG11c3QgYmUgYmFzZWQgb24gYm90aCBQMk1QIExTUA0K bGFiZWwgYW5kIFBXIGxhYmVsIHRvIGlkZW50aWZ5IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+d2hldGhlciB0aGUgdHJhZmZpYyBpcyB0aGVpciB3YW50ZWQNCm9y IHVud2FudGVkIHRyYWZmaWMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5pdCBjYW4ndCBpZGVudGlmeSB0aGUgdHJhZmZpYyBpcyB0aGVpcg0Kd2FudGVkIHRyYWZm aWMgb25seSBiYXNlZCBvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+cHcgbGFiZWwuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5p cyBteSB1bmRlcnN0YW5kaW5nIGZhbHNlPyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPmluIGFkZHRpb24sIEluIG15IG1pbmQsIGl0IGlzIGJldHRlcg0KdG8gY2xh cmlmeSB0aGlzIHNlY3Rpb24gcGFydCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPmZ1cnRoZXJseSBjbGVhcmx5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Qi5SLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+bGl1PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBh bGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HaWxlcyBIZXJvbiAmbHQ7Z2lsZXMuaGVyb25A Z21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDExLTA3LTE1IDIzOjMxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtsaXUuZ3VvbWFuQHp0ZS5jb20uY24mZ3Q7LCAmbHQ7 cHdlM0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUFdFM10gSS1EIEFDVElPTjpkcmFmdC1pZXRmLXB3ZTMt cDJtcC1wdy1yZXF1aXJlbWVudHMtMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBMaXUsPGJyPg0KPGJyPg0KMSkgSW4gdGhl IGNhc2Ugb2YgYSBub24tbGVhZiBQRSBpdCB3b3VsZCByZWNlaXZlIHRyYWZmaWMgb24gdGhlIFAy TVAgTFNQDQpidXQ8YnI+DQp3b3VsZG4ndCBoYXZlIGEgdmFsaWQgUFcgbGFiZWwgdG8gZGVtdWx0 aXBsZXggdGhlIHRyYWZmaWMuICZuYnNwO0luIHRoZQ0KUDJNUCBMU1A8YnI+DQpjYXNlIHRoZSBQ VyBsYWJlbCBpcyB2YWxpZCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIFAyTVAgTFNQIHNvIHRo ZTxicj4NCm5vbi1sZWFmIFBFIHdvbid0IGhhdmUgdGhlIGxhYmVsIGFzc2lnbmVkIGZvciBvdGhl ciB0cmFmZmljLjxicj4NCjxicj4NCjIpIFllcyB0aGUgbm9uLWxlYWYgUEUgd291bGQganVzdCBk aXNjYXJkIHRoZSB1bndhbnRlZCB0cmFmZmljLjxicj4NCjxicj4NCkJ1dCBzdXJlLCBtaWdodCBi ZSB3b3J0aCBjbGFyaWZ5aW5nIHRoaXMgaW4gdGhlIGRyYWZ0Li4uPGJyPg0KPGJyPg0KR2lsZXM8 YnI+DQo8YnI+DQpPbiAxNC8wNy8yMDExIDExOjQ5LCAmcXVvdDtsaXUuZ3VvbWFuQHp0ZS5jb20u Y24mcXVvdDsgJmx0O2xpdS5ndW9tYW5AenRlLmNvbS5jbiZndDsNCndyb3RlOjxicj4NCjxicj4N CiZndDsgaGksYXV0aG9yczxicj4NCiZndDsgaSByZXZpZXcgdGhpcyBkcmFmdCB0b2RheS4gaSBo YXZlIGEgZmV3IHF1ZXN0aW9uIGZvciBzZWN0aW9uIDMuMiBQMk1QPGJyPg0KJmd0OyBTUy1QVyBV bmRlcmx5aW5nIExheWVyIC48YnI+DQomZ3Q7IGluIHRoZSBzZWN0aW9uLCB0aGVyZSBpcyB0aGUg Zm9sbG93aW5nIHBhcmFncmFwaCBjb250ZXh0Ojxicj4NCiZndDsgJnF1b3Q7ICZuYnNwOyBBcyBh biBleGFtcGxlIGFuIGV4aXN0aW5nIFAyTVAgTFNQIG1heSBhdHRhY2g8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDttb3JlIGxlYXZlcyB0aGFuIHRoZSBvbmVzIGRlZmluZWQgYXMgTGVhZiBQRXMgZm9y IGEgZ2l2ZW4NClAyTVAgUFcuIEl0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bWF5IGJlIGludGVy ZXN0aW5nIHRvIHJldXNlIGl0IHRvIG1pbmltaXplIG5ldyBjb25maWd1cmF0aW9uLA0KYnV0PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7dXNpbmcgdGhpcyBQMk1QIExTUCB3b3VsZCBpbXBseSBub24t TGVhZiBQRXMgcmVjZWl2ZQ0KdW53YW50ZWQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0cmFmZmlj LCBub3QgZGVzdGluZWQgdG8gTGVhZiBQRSBhdCB0aGUgc2VydmljZSBsYXllciZxdW90Ozxicj4N CiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UTE6IGhv dyBkbyBub24tbGVhZiBQRXMgaWRlbnRpZnkNCndoaWNoIHRyYWZmaWMgaXMgdW53YW50ZWQ8YnI+ DQomZ3Q7IHRyYWZmaWMgYnkgYSBjb21tb24gcDJtcCBMU1A/PGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRvIHRoZXkgb25seSBiZSBiYXNlZCBvbiBwdyBsYWJl bA0KdG8ganVkZ2UgdGhlIHRyYWZmaWM/IGlmIHNvLDxicj4NCiZndDsgbWF5YmUgdGhlIHZhbHVl IG9mIHRoZSBwdyBsYWJlbCBoYXZlIGFscmVhZHkgYmVlbiBhc3NpZ25lZCBmb3IgYW5vdGhlcjxi cj4NCiZndDsgd2FudGVkIHRyYWZmaWMsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2hvdyBkbyB0aGUgbm9uLWxlYWZzIFBFcw0KaWRlbnRpZnkgd2hp Y2ggdHJhZmZpYyBpcyB1bndhbnRlZCBvcjxicj4NCiZndDsgd2FudGVkIHRyYWZmaWMgZm9yIGl0 c2VsZj88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtRMjogaWYg bm9uLWxlYWYgUEVzIGtub3cgdGhpcyB0cmFmZmljDQppcyB1bndhbnRlZCB0cmFmZmljICwgZG88 YnI+DQomZ3Q7IHRoZXkgZGlyZWN0bHkgYWJhbmRvbiB0aGVzZSB0cmFmZmljPyBpIHRoaW5rIGl0 IG5lY2Vzc2FyeSB0byBjbGFyaWZ5DQppdCBpbjxicj4NCiZndDsgdGhpcyBkcmFmdC48YnI+DQom Z3Q7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyB0aGFuayB5b3UhPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgQi5SLjxicj4NCiZndDsgbGl1PGJyPg0KJmd0OyAmbmJzcDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPGJyPg0K Jmd0OyC3orz+yMs6ICZuYnNwO3B3ZTMtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgMjAxMS0w Ny0wOSAwNTozMDxicj4NCiZndDsgPGJyPg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7IGktZC1hbm5v dW5jZUBpZXRmLm9yZzxicj4NCiZndDsgs63LzTxicj4NCiZndDsgcHdlM0BpZXRmLm9yZzxicj4N CiZndDsg1vfM4jxicj4NCiZndDsgW1BXRTNdIEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1wd2UzLXAy bXAtcHctcmVxdWlyZW1lbnRzLTA0LnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBuZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJy Pg0KJmd0OyBkaXJlY3Rvcmllcy48YnI+DQomZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIFBzZXVkb3dpcmUgRW11bGF0aW9uIEVkZ2UgdG8gRWRnZQ0KV29ya2luZzxicj4NCiZn dDsgR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg VGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogUmVxdWlyZW1lbnRzIGFuZA0KRnJh bWV3b3JrIGZvciBQb2ludC10by1NdWx0aXBvaW50PGJyPg0KJmd0OyBQc2V1ZG93aXJlPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IEF1dGhvcihzKSAmbmJzcDsgJm5ic3A7IDogRy4gSGVyb24sIGV0 IGFsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiBkcmFmdC1pZXRmLXB3ZTMtcDJtcC1wdy1yZXF1aXJlbWVudHMtMDQudHh0PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IFBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIxPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IERhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzogMjAxMS0wNy0wODxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhp cyBkb2N1bWVudCBwcmVzZW50cyBhIHNldCBvZiByZXF1aXJlbWVudHMgYW5kIGEgZnJhbWV3b3Jr DQpmb3I8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtwcm92aWRpbmcgYSBQb2ludC10by1NdWx0aXBv aW50IFBzZXVkb3dpcmUgKFBXKS4gVGhlDQpyZXF1aXJlbWVudHM8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDtpZGVudGlmaWVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIHJlbGF0ZWQgdG8gYXJjaGl0ZWN0 dXJlLA0Kc2lnbmFsaW5nPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YW5kIG1haW50ZW5hbmNlIGFz cGVjdHMgb2YgUG9pbnQtdG8tTXVsdGlwb2ludCBQVyBvcGVyYXRpb24uDQpUaGV5IGFyZTxicj4N CiZndDsgJm5ic3A7ICZuYnNwO3Byb3Bvc2VkIGFzIGd1aWRlbGluZXMgZm9yIHRoZSBzdGFuZGFy ZGl6YXRpb24gb2Ygc3VjaA0KbWVjaGFuaXNtcy48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtBbW9u ZyBvdGhlciBwb3RlbnRpYWwgYXBwbGljYXRpb25zIFBvaW50LXRvLU11bHRpcG9pbnQNClBXcyBT SE9VTEQgYmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt1c2VkIHRvIG9wdGltaXplIHRoZSBzdXBw b3J0IG9mIG11bHRpY2FzdCBsYXllciAyIHNlcnZpY2VzDQooVmlydHVhbDxicj4NCiZndDsgJm5i c3A7ICZuYnNwO1ByaXZhdGUgTEFOIFNlcnZpY2UgYW5kIFZpcnR1YWwgUHJpdmF0ZSBNdWx0aWNh c3QgU2VydmljZSkNCmFzIGRlZmluZWQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtpbiB0aGUgTGF5 ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayBXb3JraW5nIEdyb3VwLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8YnI+DQomZ3Q7IDxicj4N Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcHdlMy1wMm1w LXB3LXJlcXVpcmVtZW50cy0wNC50eCZndDs8YnI+DQp0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Ojxicj4NCiZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+ DQomZ3Q7IDxicj4NCiZndDsgQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBN SU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcjxicj4NCiZndDsgaW1wbGVtZW50YXRpb24gdG8gYXV0 b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+DQomZ3Q7IElu dGVybmV0LURyYWZ0Ljxicj4NCiZndDsgZnRwOi8vYW5vbnltb3VzQGZ0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wd2UzLXAybXAtcHctcmVxdWlyZW1lPGJyPg0KJmd0OyBu dHMtMDQudHh0PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHB3ZTNAaWV0 Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdl Mzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzDQptYWlsIGlzPGJyPg0KJmd0OyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzPGJy Pg0KJmd0OyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlPGJyPg0KJmd0OyBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLjxi cj4NCiZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQNCmludGVuZGVkPGJyPg0KJmd0OyBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0K SWY8YnI+DQomZ3Q7IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvcg0Kb2YgdGhlPGJyPg0KJmd0OyBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWw8 YnI+DQomZ3Q7IHNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48YnI+DQomZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyBwd2UzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgcHdlM0BpZXRmLm9yZzxicj4NCiZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlv biZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5i c3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29s ZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3Jn YW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lz Jm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3Zl Jm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3Jl Y3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNw O2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDth bmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0 Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtz b2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2lu ZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkm bmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7 cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxl YXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7 aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5k Jm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0K PC9wcmU+ --=_alternative 00062212482578D1_=-- From mach.chen@huawei.com Sun Jul 17 20:54:38 2011 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 E679E21F8B12; Sun, 17 Jul 2011 20:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH-ArE8nGW42; Sun, 17 Jul 2011 20:54:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4177B21F8B08; Sun, 17 Jul 2011 20:54:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOI00BD8G70RD@szxga04-in.huawei.com>; Mon, 18 Jul 2011 11:54:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOI00ACUG6Z2O@szxga04-in.huawei.com>; Mon, 18 Jul 2011 11:54:36 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACH79664; Mon, 18 Jul 2011 11:54:35 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Jul 2011 11:54:33 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.170]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Mon, 18 Jul 2011 11:54:26 +0800 Date: Mon, 18 Jul 2011 03:54:24 +0000 From: Mach Chen In-reply-to: <201107151751.p6FHp3WE095797@harbor.orleans.occnc.com> X-Originating-IP: [10.110.98.37] To: "curtis@occnc.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue Thread-index: AQHMQxfO+dvJGiMscE+yyQjr2dKmnJTxZ/ng X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201107151751.p6FHp3WE095797@harbor.orleans.occnc.com> Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue 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, 18 Jul 2011 03:54:39 -0000 Hi Curtis, Thanks for your comments! The original purpose of this draft was for binding a PW to a co-routed PSN Tunnel, this is a requirement of MPLS-TP network. So "co-routed" is the major characteristic. In the draft, this is archived by setting the "C" bit of the PSN Tunnel TLV. As for other characteristics, I am not sure whether we need carry all those characteristics(at least for now), and as you said, if we do that, it may eventually reinvent another CR-LDP. So, IMHO, it may be better to limit the scope of the draft to the current form and leave others for future study. If there are requirements for adding new characteristic, we could incorporate it then. BTW, draft-ietf-pwe3-dynamic-ms-pw(Section 6.2.1 MS-PW Bandwidth Signaling) has already defined a PW Bandwidth TLV to indicate bandwidth characteristic, it also can apply in this draft. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Saturday, July 16, 2011 1:51 AM > To: mpls@ietf.org > Subject: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue > > > Regarding: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > Mach, Ping, et al, > > The second issue which I pointed out in the last revision is that > there is no way to indicate the characteristics required of a > mid-segment of a MS-PW. The ingress (a T-PE) can specify the nodes, > but it cannot specify which tunnel from S-PE to S-PE to use. It must > specify the required characteristics of the tunnel to allow the S-PE > to pick an appropriate tunnel. > > For example, an LSP contains sufficient information, such as > bandwidth, holding and setup priority, resource affinitiy expressed as > include-any, include-all, and exclude to be applied over the 32 bit > administrative atrribute bit map. This allows simple things such as > loose hops and not so simple things such as BRPC. > > It might be best to cite the RSVP-TE work and encapsulate the TLVs > defined there into the PW. This is a bit like reinventing CR-LDP and > if it becomes too much like CRLDP, maybe RSVP-TE signaling of PW > should be defined instead. I'm not really sure what the best way is > to solve this. > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Mon Jul 18 08:55:06 2011 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 C703621F8C83; Mon, 18 Jul 2011 08:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2RioLhRf-9y; Mon, 18 Jul 2011 08:55:06 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id D203E21F8CA1; Mon, 18 Jul 2011 08:55:05 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6IFsw0P067519; Mon, 18 Jul 2011 11:54:58 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107181554.p6IFsw0P067519@harbor.orleans.occnc.com> To: Mach Chen From: Curtis Villamizar In-reply-to: Your message of "Mon, 18 Jul 2011 03:54:24 -0000." Date: Mon, 18 Jul 2011 11:54:58 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:55:06 -0000 In message Mach Chen writes: > > Hi Curtis, > > Thanks for your comments! > > The original purpose of this draft was for binding a PW to a co-routed > PSN Tunnel, this is a requirement of MPLS-TP network. So "co-routed" > is the major characteristic. In the draft, this is archived by setting > the "C" bit of the PSN Tunnel TLV. There is generally only one LSP between any A-Z in a provider core with PW carried inside the one LSP. Where there are multiple LSP it is generally because there are different QoS requirements, with more recent dicsussion focusing on delay requirements. > As for other characteristics, I am not sure whether we need carry all > those characteristics(at least for now), and as you said, if we do > that, it may eventually reinvent another CR-LDP. So, IMHO, it may be > better to limit the scope of the draft to the current form and leave > others for future study. If there are requirements for adding new > characteristic, we could incorporate it then. We would not reinvent CR-LDP if there was one loose hop specifying QoS requirments. The shortest path is followed, stopping at S-PE along the way. RSVP-TE is providing the ERO between PE and therefore handling the traffic engineering. > BTW, draft-ietf-pwe3-dynamic-ms-pw(Section 6.2.1 MS-PW Bandwidth > Signaling) has already defined a PW Bandwidth TLV to indicate > bandwidth characteristic, it also can apply in this draft. Yes. Bandwidth is covered. Resource affinity, holding priority. RFC4124 class type, etc is not covered. > Best regards, > Mach Thanks for the prompt reply. Best regards, Curtis > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Curtis Villamizar > > Sent: Saturday, July 16, 2011 1:51 AM > > To: mpls@ietf.org > > Subject: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue > > > > > > Regarding: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt > > > > Mach, Ping, et al, > > > > The second issue which I pointed out in the last revision is that > > there is no way to indicate the characteristics required of a > > mid-segment of a MS-PW. The ingress (a T-PE) can specify the nodes, > > but it cannot specify which tunnel from S-PE to S-PE to use. It must > > specify the required characteristics of the tunnel to allow the S-PE > > to pick an appropriate tunnel. > > > > For example, an LSP contains sufficient information, such as > > bandwidth, holding and setup priority, resource affinitiy expressed as > > include-any, include-all, and exclude to be applied over the 32 bit > > administrative atrribute bit map. This allows simple things such as > > loose hops and not so simple things such as BRPC. > > > > It might be best to cite the RSVP-TE work and encapsulate the TLVs > > defined there into the PW. This is a bit like reinventing CR-LDP and > > if it becomes too much like CRLDP, maybe RSVP-TE signaling of PW > > should be defined instead. I'm not really sure what the best way is > > to solve this. > > > > Curtis > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From amalis@gmail.com Mon Jul 18 17:43:18 2011 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 764FF21F8797; Mon, 18 Jul 2011 17:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhpfyWlK-8Gr; Mon, 18 Jul 2011 17:43:17 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 22B1221F8794; Mon, 18 Jul 2011 17:43:16 -0700 (PDT) Received: by fxe4 with SMTP id 4so8718539fxe.27 for ; Mon, 18 Jul 2011 17:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=I9JdccYxQ9uTZ/Jij7aX0cOpSi9qTicJsP5vdDY2bK0=; b=f9EEQRf6KVWPfZ6Easf8BgLHi0JLwaZ+FNRpUgqMYpyETSKPvjayMiIXM7y0z0DhEo 1W8L4PdTiSVHCDpEOQD01azJ8IEwogbc0cNiD31KsQW8cpp5YtUwP5URdyNspYXgfGW9 xN7GQ+nx4fkR66JYXP/QO+sOQRVkwIhdwy+4w= Received: by 10.204.20.147 with SMTP id f19mr1897090bkb.163.1311036194087; Mon, 18 Jul 2011 17:43:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.10.76 with HTTP; Mon, 18 Jul 2011 17:42:46 -0700 (PDT) From: "Andrew G. Malis" Date: Mon, 18 Jul 2011 17:42:46 -0700 Message-ID: To: "Stewart Bryant (stbryant)" , Adrian Farrel , The IESG Content-Type: text/plain; charset=ISO-8859-1 Cc: pwe3@ietf.org Subject: [PWE3] Request to publish draft-ietf-pwe3-static-pw-status-06.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, 19 Jul 2011 00:43:18 -0000 Document Writeup for draft-ietf-pwe3-static-pw-status-06.txt (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? Andy Malis Yes, I have reviewed this revision and believe it is ready for publication. (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, it has been well reviewed and received good last-call comments. In addition, it has received a lot of discussion through its iterations on the pwe3 email list. (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, no concerns or issues. I noticed at least one typo, such as a space before a comma. This can be corrected by the RFC Editor. No IPR has been filed. (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? There is strong consensus for the document. (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.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist 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, it passes id-nits. (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]. The references are split. There are two normative references that are still working group drafts. We expect these drafts to be completing soon. (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 requests the allocation of three new codepoints in existing registries that belong to the working group. (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? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a mechanism to signal Pseudowire (PW) status messages using an PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far end T-PE. The mechanism allows PW OAM message mapping and PW redundancy to operate on static PWs. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary This document represents the consensus of the working group. It is a part of the MPLS-TP project in the IETF. Document Quality It is required for the use of pseudowires for statically provisioned MPLS-TP, and thus is expected to be widely implemented and deployed. There are no concerns regarding the document's quality. Personnel Who is the Document Shepherd for this document? Andy Malis Who is the Responsible Area Director? Stewart Bryant From matthew.bocci@alcatel-lucent.com Tue Jul 19 06:37:16 2011 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 3598D21F8579 for ; Tue, 19 Jul 2011 06:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.848 X-Spam-Level: X-Spam-Status: No, score=-105.848 tagged_above=-999 required=5 tests=[AWL=0.400, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSM5BklvbIeR for ; Tue, 19 Jul 2011 06:37:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9B21F8569 for ; Tue, 19 Jul 2011 06:37:14 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6JDMvA2012847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Jul 2011 15:37:12 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Jul 2011 15:36:58 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Tue, 19 Jul 2011 15:36:55 +0200 Thread-Topic: WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGO4Vr5zkZH55TBaz4sxdeixrRw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA4B47071435Dmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-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: Tue, 19 Jul 2011 13:37:16 -0000 --_000_CA4B47071435Dmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a poll of the list to see if there is consensus to adopt = draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working gro= up draft. Please indicate whether or not you support adoption of this draft, and send= any comments to the PWE3 list. This poll ends on Tuesday 9th August. Regards, Matthew and Andy. --_000_CA4B47071435Dmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This email begins a poll= of the list to see if there is consensus to adopt draft-martini-pwe3-= status-aggregation-protocol-03.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this= draft, and send any comments to the PWE3 list.

Th= is poll ends on Tuesday 9th August.

Regards,
=

Matthew and Andy.
--_000_CA4B47071435Dmatthewboccialcatellucentcom_-- From rajiva@cisco.com Tue Jul 19 06:43:49 2011 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 A62C921F88A1 for ; Tue, 19 Jul 2011 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDJ-t4+9csxo for ; Tue, 19 Jul 2011 06:43:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 92EA521F855D for ; Tue, 19 Jul 2011 06:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=701; q=dns/txt; s=iport; t=1311083025; x=1312292625; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9M6r2LW/aBdVvjgs1eM3JX7hSJ4rPJHf4VHa8nhm+F8=; b=PuUdhKfdyr9BhNwFJ8QPr4/ABCy+09rdyamwtfBLq/DVfDnnk5oMJA5l Fkn9M3oITwxaWy8WhPydosZnLFy4IyynfxBLDCo/ZJwq+yRpet6vS1DBx FXEbW3RfCE+lIGYw6IRoLJecux/2LF60elBZG1K7ol86DNRgiHoT+eQiz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAMmIJU6tJXHB/2dsb2JhbABUmAePRXetKZ5MhV1fBIdUkCCLaw X-IronPort-AV: E=Sophos;i="4.67,228,1309737600"; d="scan'208";a="4338517" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2011 13:43:45 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6JDhjhN010100; Tue, 19 Jul 2011 13:43:45 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 08:43:44 -0500 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, 19 Jul 2011 08:43:43 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0575F5DB@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG Poll fordraft-martini-pwe3-status-aggregation-protocol-03.txt Thread-Index: AcxGGO4Vr5zkZH55TBaz4sxdeixrRwAAO8Dw References: From: "Rajiv Asati (rajiva)" To: "Bocci, Matthew (Matthew)" , X-OriginalArrivalTime: 19 Jul 2011 13:43:44.0814 (UTC) FILETIME=[E0E51CE0:01CC4619] Subject: Re: [PWE3] WG Poll fordraft-martini-pwe3-status-aggregation-protocol-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: Tue, 19 Jul 2011 13:43:49 -0000 Yes. Cheers, Rajiv > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, > Matthew (Matthew) > Sent: Tuesday, July 19, 2011 9:37 AM > To: pwe3@ietf.org > Subject: [PWE3] WG Poll fordraft-martini-pwe3-status-aggregation-protocol- > 03.txt >=20 > This email begins a poll of the list to see if there is consensus to adopt > draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group > draft. >=20 > Please indicate whether or not you support adoption of this draft, and send > any comments to the PWE3 list. >=20 > This poll ends on Tuesday 9th August. >=20 > Regards, >=20 > Matthew and Andy. From bedard.phil@gmail.com Tue Jul 19 06:58:58 2011 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 EC63321F8797 for ; Tue, 19 Jul 2011 06:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEzDypbbRZnN for ; Tue, 19 Jul 2011 06:58:58 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 737C121F86AB for ; Tue, 19 Jul 2011 06:58:58 -0700 (PDT) Received: by yie30 with SMTP id 30so2043116yie.31 for ; Tue, 19 Jul 2011 06:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; bh=xx/P1MqVH6vMhb+JqaYEUFit9p8CcVF/7MjnBE6pa24=; b=V7nW1W4x1YQe+/UWtK3GMTmNQ663mO76G1b37yaKXbu9VFyTTIWO60UZTyFp4NTzpv 4iE1bbpbpa1lZzngm5yOzHLG0jIB/7XXiw34tmWQeVlHCF85PZKWivo6pV66josyRa+n 1XwBO3+WCF8ILJC3taBbwJcN9tNzeWbbKel/4= Received: by 10.150.237.17 with SMTP id k17mr7052911ybh.195.1311083937933; Tue, 19 Jul 2011 06:58:57 -0700 (PDT) Received: from [10.63.85.55] (gw1.cox.com [24.248.74.254]) by mx.google.com with ESMTPS id v13sm2148194ybb.13.2011.07.19.06.58.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 06:58:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 19 Jul 2011 09:58:52 -0400 From: Phil Bedard To: "pwe3@ietf.org" Message-ID: Thread-Topic: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393914335_9189853" Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-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: Tue, 19 Jul 2011 13:58:59 -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_3393914335_9189853 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Support. Phil From: "Bocci, Matthew (Matthew)" Date: Tue, 19 Jul 2011 15:36:55 +0200 To: "pwe3@ietf.org" Subject: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt This email begins a poll of the list to see if there is consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and send any comments to the PWE3 list. This poll ends on Tuesday 9th August. Regards, Matthew and Andy. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --B_3393914335_9189853 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Support.  

Phil 


This email begins a poll of the list to = see if there is consensus to adopt draft-martini-pwe3-status-aggregatio= n-protocol-03.txt as a PWE3 working group draft.

Pl= ease indicate whether or not you support adoption of this draft, and send an= y comments to the PWE3 list.

This poll ends on Tues= day 9th August.

Regards,

M= atthew and Andy.
_______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/m= ailman/listinfo/pwe3 --B_3393914335_9189853-- From iesg-secretary@ietf.org Tue Jul 19 15:18:22 2011 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 D339611E809A; Tue, 19 Jul 2011 15:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y8FTyRv6BgB; Tue, 19 Jul 2011 15:18:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592AA11E8071; Tue, 19 Jul 2011 15:18:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110719221822.17604.57303.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2011 15:18:22 -0700 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:18:23 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' as a Proposed Standard This is a second last call. The last call is only necessary because of a further late-received IPR disclosure The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1595/ From lizhong.jin@zte.com.cn Wed Jul 20 06:13:16 2011 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 8EAAC21F877D for ; Wed, 20 Jul 2011 06:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.619 X-Spam-Level: X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGfMwteadgr9 for ; Wed, 20 Jul 2011 06:13:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8062021F8751 for ; Wed, 20 Jul 2011 06:13:15 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321397396305; Wed, 20 Jul 2011 21:06:06 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.2368962204; Wed, 20 Jul 2011 21:13:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6KDCxO3059342; Wed, 20 Jul 2011 21:12:59 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 20 Jul 2011 21:12:47 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-20 21:13:01, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-20 21:13:01, Serialize complete at 2011-07-20 21:13:01, S/MIME Sign failed at 2011-07-20 21:13:01: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-20 21:13:02, Serialize complete at 2011-07-20 21:13:02 Content-Type: multipart/alternative; boundary="=_alternative 00489A94482578D3_=" X-MAIL: mse02.zte.com.cn p6KDCxO3059342 Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-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: Wed, 20 Jul 2011 13:13:16 -0000 This is a multipart message in MIME format. --=_alternative 00489A94482578D3_= Content-Type: text/plain; charset="US-ASCII" Yes, support. Lizhong > > ------------------------------ > > Message: 2 > Date: Tue, 19 Jul 2011 15:36:55 +0200 > From: "Bocci, Matthew (Matthew)" > To: "pwe3@ietf.org" > Subject: [PWE3] WG Poll for > draft-martini-pwe3-status-aggregation-protocol-03.txt > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > This email begins a poll of the list to see if there is consensus to > adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a > PWE3 working group draft. > > Please indicate whether or not you support adoption of this draft, > and send any comments to the PWE3 list. > > This poll ends on Tuesday 9th August. > > Regards, > > Matthew and Andy. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/pwe3/attachments/20110719/cda05228/attachment.htm> > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00489A94482578D3_= Content-Type: text/html; charset="US-ASCII"
Yes, support.

Lizhong

>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 Jul 2011 15:36:55 +0200
> From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] WG Poll for
>    draft-martini-pwe3-status-aggregation-protocol-03.txt
> Message-ID: <CA4B4707.1435D%matthew.bocci@alcatel-lucent.com>
> Content-Type: text/plain; charset="us-ascii"
>
> This email begins a poll of the list to see if there is consensus to
> adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a
> PWE3 working group draft.
>
> Please indicate whether or not you support adoption of this draft,
> and send any comments to the PWE3 list.
>
> This poll ends on Tuesday 9th August.
>
> Regards,
>
> Matthew and Andy.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20110719/cda05228/attachment.htm>
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00489A94482578D3_=-- From ietf-ipr@ietf.org Tue Jul 19 15:00:30 2011 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 7B4A421F8634; Tue, 19 Jul 2011 15:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ACsH4x2mZiX; Tue, 19 Jul 2011 15:00:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB50421F85EA; Tue, 19 Jul 2011 15:00:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: stbryant@cisco.com, cfilsfil@cisco.com, Ulrich.Drafz@t-com.net, vach.kompella@alcatel-lucent.com, joe.regan@alcatel-lucent.com, shane@castlepoint.net X-Test-IDTracker: no Message-ID: <20110719220029.10954.11902.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2011 15:00:29 -0700 X-Mailman-Approved-At: Wed, 20 Jul 2011 08:12:15 -0700 Cc: pwe3@ietf.org, andrew.g.malis@verizon.com, ipr-announce@ietf.org, stbryant@cisco.com Subject: [PWE3] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-fat-pw-07 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:00:30 -0000 Dear Stewart Bryant, Clarence Filsfils, Ulrich Drafz, Vach Kompella, Joe Re= gan, Shane Amante: An IPR disclosure that pertains to your Internet-Draft entitled "Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network" (draft-ietf-= pwe3 -fat-pw) was submitted to the IETF Secretariat on 2011-07-19 and has been p= osted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1595/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-pwe3-fat-pw-07.""); The IETF Secretariat From DanielC@orckit.com Thu Jul 21 02:47:05 2011 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 A2AD121F851A for ; Thu, 21 Jul 2011 02:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQMN8E3+gTjf for ; Thu, 21 Jul 2011 02:47:04 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8221F853A for ; Thu, 21 Jul 2011 02:47:03 -0700 (PDT) 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_01CC478B.64DC10B8" Date: Thu, 21 Jul 2011 12:46:57 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306E5808B@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operational status definition in draft-ietf-pwe3-redundancy-bit Thread-Index: Acw9bVVwOzO2AWTrS0SXJI64diPnrwH1rU8AAJGU6JA= References: <20110708124422.7813.29877.idtracker@ietfa.amsl.com> From: "Daniel Cohn" To: Subject: [PWE3] Operational status definition in draft-ietf-pwe3-redundancy-bit 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, 21 Jul 2011 09:47:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC478B.64DC10B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, =20 draft-ietf-pwe3-redundancy-bit uses the PW operational status as an input to the active PW selection logic. In this draft, the operational status is taken from the (local and remote) PW status bits. The draft defines "UP PW" (eligible to become active PW) as "PW which ... and is not in any of the PW defect states specified in [2]". So the PW operational status, in the context of this draft, takes into account local/remote AC statuses. =20 On the other hand, the standard PW MIB (RFC 5601) explicitly defines the PW operational status as not considering the AC statuses - "This object indicates the operational status of the PW; it does not reflect the status of the Customer Edge (CE) bound interface...".=20 =20 If my understanding is correct, then I believe there is a terminology conflict that should be resolved. =20 Am I missing something? Please comment. =20 Regards, =20 Daniel =20 ------_=_NextPart_001_01CC478B.64DC10B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = authors,

 

draft-ietf-pwe3-redundancy-bit uses the PW = operational status as an input to the active PW selection logic. In this = draft, the operational status is taken from the (local and remote) PW = status bits.

The draft defines = “UP PW” (eligible to become active PW) as “PW which = … and is not in any of the PW defect states specified in = [2]”. So the PW operational status, in the context of this draft, = takes into account local/remote AC statuses.

 =

On the other hand, the standard = PW MIB (RFC 5601) explicitly defines the PW operational status as not = considering the AC statuses – “This object indicates the = operational status of the PW; it does not reflect the status of the = Customer Edge (CE) bound interface…”.

 

If my = understanding is correct, then I believe there is a terminology conflict = that should be resolved.

 

Am I = missing something? Please comment.

 

Regards,

 

Daniel

 

------_=_NextPart_001_01CC478B.64DC10B8-- From curtis@occnc.com Thu Jul 21 12:41:22 2011 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 DC6F121F852C for ; Thu, 21 Jul 2011 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAYHdr77TRP3 for ; Thu, 21 Jul 2011 12:41:22 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 13C7821F8520 for ; Thu, 21 Jul 2011 12:41:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6LJdsG7001449; Thu, 21 Jul 2011 15:39:54 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107211939.p6LJdsG7001449@harbor.orleans.occnc.com> To: "Bocci, Matthew (Matthew)" From: Curtis Villamizar In-reply-to: Your message of "Tue, 19 Jul 2011 15:36:55 +0200." Date: Thu, 21 Jul 2011 15:39:54 -0400 Sender: curtis@occnc.com Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 19:41:23 -0000 In message "Bocci, Matthew (Matthew)" writes: > > This email begins a poll of the list to see if there is consensus to > adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 > working group draft. > > Please indicate whether or not you support adoption of this draft, and > send any comments to the PWE3 list. > > This poll ends on Tuesday 9th August. > > Regards, > > Matthew and Andy. +1 support/yes (note: already replied to the forward to the mpls list) From renwei.li@huawei.com Thu Jul 21 12:49:02 2011 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 63DE721F869E for ; Thu, 21 Jul 2011 12:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du1jPUE5+DF0 for ; Thu, 21 Jul 2011 12:49:01 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 651D221F8696 for ; Thu, 21 Jul 2011 12:49:01 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOP00IE28DOU3@usaga02-in.huawei.com> for pwe3@ietf.org; Thu, 21 Jul 2011 14:49:01 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LOP00I668DJ01@usaga02-in.huawei.com> for pwe3@ietf.org; Thu, 21 Jul 2011 14:49:00 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Jul 2011 12:49:00 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.159]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 21 Jul 2011 12:48:58 -0700 Date: Thu, 21 Jul 2011 19:49:29 +0000 From: Renwei Li In-reply-to: X-Originating-IP: [10.193.34.92] To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_SViLPEZexMFkJuNnxGQr+A)" Content-language: en-US Accept-Language: en-US Thread-topic: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt Thread-index: AcxGGO4Vr5zkZH55TBaz4sxdeixrRwBxI5eQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-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: Thu, 21 Jul 2011 19:49:02 -0000 --Boundary_(ID_SViLPEZexMFkJuNnxGQr+A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Support. ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Tuesday, July 19, 2011 6:37 AM To: pwe3@ietf.org Subject: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt This email begins a poll of the list to see if there is consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and send any comments to the PWE3 list. This poll ends on Tuesday 9th August. Regards, Matthew and Andy. --Boundary_(ID_SViLPEZexMFkJuNnxGQr+A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Support.

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Tuesday, July 19, 2011 6:37 AM
To: pwe3@ietf.org
Subject: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt

 

This email begins a poll of the list to see if there is consensus to adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 working group draft.

 

Please indicate whether or not you support adoption of this draft, and send any comments to the PWE3 list.

 

This poll ends on Tuesday 9th August.

 

Regards,

 

Matthew and Andy.

--Boundary_(ID_SViLPEZexMFkJuNnxGQr+A)-- From zhang.fei3@zte.com.cn Fri Jul 22 07:46:54 2011 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 B0BEF21F8AF6; Fri, 22 Jul 2011 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.705 X-Spam-Level: X-Spam-Status: No, score=-96.705 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md7ZiRYBhvI8; Fri, 22 Jul 2011 07:46:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 353B421F8AF4; Fri, 22 Jul 2011 07:46:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643491178658; Fri, 22 Jul 2011 22:45:03 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.4462744557; Fri, 22 Jul 2011 22:46:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6MEkkea094887; Fri, 22 Jul 2011 22:46:46 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Bocci, Matthew (Matthew)" MIME-Version: 1.0 X-KeepSent: BD40158C:4F97875C-482578D5:005034E2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 22 Jul 2011 22:46:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-22 22:46:49, Serialize complete at 2011-07-22 22:46:49 Content-Type: multipart/alternative; boundary="=_alternative 00513065482578D5_=" X-MAIL: mse01.zte.com.cn p6MEkkea094887 Cc: pwe3-bounces@ietf.org, "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:46:54 -0000 This is a multipart message in MIME format. --=_alternative 00513065482578D5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KDQpKdXN0IG9uZSBxdWljayBxdWVzdGlvbiwNCg0KV2h5IG5vdCBjb25z aWRlciB0byBkZWZpbmUgdGhlIHNpbWlsYXIgc2NoZW1lcyBvbiB0aGUgR0FDSCBvZiBQVz8gSXQg d2lsbCANCmJlIHN1aXRhYmxlIHRvIE1TLVBXIGFsc28uDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkN Cg0KDQoNCiJCb2NjaSwgTWF0dGhldyAoTWF0dGhldykiIDxtYXR0aGV3LmJvY2NpQGFsY2F0ZWwt bHVjZW50LmNvbT4gDQq3orz+yMs6ICBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDctMTkg MjE6MzYNCg0KytW8/sjLDQoicHdlM0BpZXRmLm9yZyIgPHB3ZTNAaWV0Zi5vcmc+DQqzrcvNDQoN Ctb3zOINCltQV0UzXSBXRyBQb2xsIGZvciBkcmFmdC1tYXJ0aW5pLXB3ZTMtc3RhdHVzLWFnZ3Jl Z2F0aW9uLXByb3RvY29sLTAzLnR4dA0KDQoNCg0KDQoNCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSBw b2xsIG9mIHRoZSBsaXN0IHRvIHNlZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gYWRvcHQgDQpk cmFmdC1tYXJ0aW5pLXB3ZTMtc3RhdHVzLWFnZ3JlZ2F0aW9uLXByb3RvY29sLTAzLnR4dCBhcyBh IFBXRTMgd29ya2luZyANCmdyb3VwIGRyYWZ0Lg0KDQpQbGVhc2UgaW5kaWNhdGUgd2hldGhlciBv ciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCwgYW5kIA0Kc2VuZCBhbnkg Y29tbWVudHMgdG8gdGhlIFBXRTMgbGlzdC4NCg0KVGhpcyBwb2xsIGVuZHMgb24gVHVlc2RheSA5 dGggQXVndXN0Lg0KDQpSZWdhcmRzLA0KDQpNYXR0aGV3IGFuZCBBbmR5Ll9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdl M0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoN Cg0K --=_alternative 00513065482578D5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9zdXBwb3J0PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5KdXN0IG9uZSBx dWljayBxdWVzdGlvbiw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPldoeSBub3QgY29uc2lkZXIgdG8gZGVmaW5lIHRoZSBzaW1pbGFyDQpzY2hlbWVzIG9u IHRoZSBHQUNIIG9mIFBXPyBJdCB3aWxsIGJlIHN1aXRhYmxlIHRvIE1TLVBXIGFsc28uPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtC b2NjaSwgTWF0dGhldyAoTWF0dGhldykmcXVvdDsNCiZsdDttYXR0aGV3LmJvY2NpQGFsY2F0ZWwt bHVjZW50LmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wNy0xOSAyMTozNjwvZm9udD4NCjx0ZCB3 aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtwd2UzQGll dGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1BXRTNdIFdHIFBvbGwgZm9yICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtkcmFmdC1tYXJ0aW5pLXB3ZTMtc3RhdHVzLWFnZ3Jl Z2F0aW9uLXByb3RvY29sLTAzLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGlzIGVtYWlsIGJlZ2lucyBhIHBv bGwgb2YgdGhlIGxpc3QgdG8NCnNlZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8gYWRvcHQgZHJh ZnQtbWFydGluaS1wd2UzLXN0YXR1cy1hZ2dyZWdhdGlvbi1wcm90b2NvbC0wMy50eHQNCmFzIGEg UFdFMyB3b3JraW5nIGdyb3VwIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+UGxlYXNlIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0 DQphZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LCBhbmQgc2VuZCBhbnkgY29tbWVudHMgdG8gdGhlIFBX RTMgbGlzdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRo aXMgcG9sbCBlbmRzIG9uIFR1ZXNkYXkgOXRoIEF1Z3VzdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJlZ2FyZHMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5NYXR0aGV3IGFuZCBBbmR5LjwvZm9udD48dHQ+PGZvbnQg c2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQpwd2UzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 00513065482578D5_=-- From david.sinicrope@ericsson.com Sun Jul 24 10:33:13 2011 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 BF25E21F8A66 for ; Sun, 24 Jul 2011 10:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aroT+qgkqpDR for ; Sun, 24 Jul 2011 10:33:13 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2280721F8A4D for ; Sun, 24 Jul 2011 10:33:13 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6OHXC8x026575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 24 Jul 2011 12:33:12 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 24 Jul 2011 13:33:11 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Sun, 24 Jul 2011 13:33:10 -0400 Thread-Topic: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City Thread-Index: AcxKJ8IlDCsVWhvlQZeFrTrCr0/mzQ== 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.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 24 Jul 2011 17:33:13 -0000 http://www.ietf.org/proceedings/81/agenda/pwe3.txt The latest agenda and slide status is at the link above. If you have a slot and have not sent me your presentation for upload, please do so right away. Thanks, Dave -----Original Message----- From: David A Sinicrope Date: Thu, 14 Jul 2011 09:54:10 -0400 To: "IETF.PWE3" Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City >Also: > >- If you still need a slot and haven't requested one you have until >midnight UTC-12 Friday July 15 to get me your request. Requests are given >on a first come, first served basis. > >- If you have a slot and are planning to send in a presentation, please >send it to me via reply to this email by midnight EDT Friday July 22. (If >you aren't planning to use slides for your slot, please let me know that >as well.) As in previous IETFs, you risk getting removed from the agenda >if your slides aren't in by the deadline. The Chairs and I need time to >upload, convert and load the slides together on a single laptop for the >meeting and Webex. > >Thanks! >Dave > > >-----Original Message----- >From: David A Sinicrope >Date: Thu, 14 Jul 2011 09:10:02 -0400 >To: "IETF.PWE3" >Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City > >>Hi All, >>The PWE3 agenda can be found at >>http://www.ietf.org/proceedings/81/agenda/pwe3.txt >>If you have a slot, please reply to this email and send me your >>presentation as soon as possible for upload to the meeting materials. >>Thanks, >>Dave >> >> >>-----Original Message----- >>From: David A Sinicrope >>> >>Date: Mon, 11 Jul 2011 14:23:26 -0400 >>To: "IETF.PWE3" > >>Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City >> >>Hi All, >>The first pass at the PWE3 Agenda for Quebec City can be found at: >>http://www.ietf.org/proceedings/81/agenda/pwe3.txt >>Please let me know if I missed your request or you need a slot. >>As always please specify desired duration, topic/draft title, and >>presenter for each slot requested in response to this email. >>Thanks, >>Dave >> >>From: David A Sinicrope >>>: >>david.sinicrope@ericsson.com>> >>Date: Mon, 27 Jun 2011 16:03:43 -0400 >>To: "IETF.PWE3"=20 >>> >>Subject: PWE3 Agenda Slot call for IETF 81 - Quebec City >> >>Hi All, >> >>Please let me know if you would like a time slot for the IETF 81 PWE3 >>session by replying to this email with the desired duration, topic/draft >>title, and presenter for each slot requested. >> >>Thanks, >>Dave >>_______________________________________________ >>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 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From amalis@gmail.com Sun Jul 24 17:19:59 2011 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 0F05921F85AA for ; Sun, 24 Jul 2011 17:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biZbeqyPHxc0 for ; Sun, 24 Jul 2011 17:19:58 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 305E421F856B for ; Sun, 24 Jul 2011 17:19:58 -0700 (PDT) Received: by fxe4 with SMTP id 4so9259231fxe.27 for ; Sun, 24 Jul 2011 17:19:57 -0700 (PDT) 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=EJ8bOe/K/4AhZfBjwrTDCDBFKaqI5GKdv9HeLOuN13M=; b=UqI5xGAaFq+OTyDIy7A69vxKc6CiSddDVcHFeLiJwVm0UGyf7mKfSHutCz8ybQSnZq qOgRJ9ZwBh6Npy2OLj6eT9rvRPNHK2Es+ShjE/ANnOJcmFkRvZaCyC2RAoNJpfISGVJ1 ozgXecTvcAJWGuW0TtKtsqSNbIc1OOf1iD2rk= Received: by 10.204.103.2 with SMTP id i2mr1076400bko.7.1311553197129; Sun, 24 Jul 2011 17:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.121.129 with HTTP; Sun, 24 Jul 2011 17:19:37 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Sun, 24 Jul 2011 20:19:37 -0400 Message-ID: To: David Sinicrope Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "IETF.PWE3" Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City 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, 25 Jul 2011 00:19:59 -0000 To PWE3 presenters: We're still missing a good number of the presentations. Please get them to Dave ASAP or risk being removed from the agenda (more time for everyone else!). Thanks much, Andy On Sun, Jul 24, 2011 at 1:33 PM, David Sinicrope wrote: > http://www.ietf.org/proceedings/81/agenda/pwe3.txt > > The latest agenda and slide status is at the link above. > If you have a slot and have not sent me your presentation for upload, > please do so right away. > > Thanks, > Dave > > -----Original Message----- > From: David A Sinicrope =A0 > Date: Thu, 14 Jul 2011 09:54:10 -0400 > To: "IETF.PWE3" > Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City > >>Also: >> >>- If you still need a slot and haven't requested one you have until >>midnight UTC-12 Friday July 15 to get me your request. =A0Requests are gi= ven >>on a first come, first served basis. >> >>- If you have a slot and are planning to send in a presentation, please >>send it to me via reply to this email by midnight EDT Friday July 22. =A0= (If >>you aren't planning to use slides for your slot, please let me know that >>as well.) =A0As in previous IETFs, you risk getting removed from the agen= da >>if your slides aren't in by the deadline. The Chairs and I need time to >>upload, convert and load the slides together on a single laptop for the >>meeting and Webex. >> >>Thanks! >>Dave >> >> >>-----Original Message----- >>From: David A Sinicrope =A0 >>Date: Thu, 14 Jul 2011 09:10:02 -0400 >>To: "IETF.PWE3" >>Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City >> >>>Hi All, >>>The PWE3 agenda can be found at >>>http://www.ietf.org/proceedings/81/agenda/pwe3.txt >>>If you have a slot, please reply to this email and send me your >>>presentation as soon as possible for upload to the meeting materials. >>>Thanks, >>>Dave >>> >>> >>>-----Original Message----- >>>From: David A Sinicrope >>>> >>>Date: Mon, 11 Jul 2011 14:23:26 -0400 >>>To: "IETF.PWE3" > >>>Subject: Re: [PWE3] PWE3 Agenda Slot call for IETF 81 - Quebec City >>> >>>Hi All, >>>The first pass at the PWE3 Agenda for Quebec City can be found at: >>>http://www.ietf.org/proceedings/81/agenda/pwe3.txt >>>Please let me know if I missed your request or you need a slot. >>>As always please specify desired duration, topic/draft title, and >>>presenter for each slot requested in response to this email. >>>Thanks, >>>Dave >>> >>>From: David A Sinicrope >>>>>: >>>david.sinicrope@ericsson.com>> >>>Date: Mon, 27 Jun 2011 16:03:43 -0400 >>>To: "IETF.PWE3" >>>> >>>Subject: PWE3 Agenda Slot call for IETF 81 - Quebec City >>> >>>Hi All, >>> >>>Please let me know if you would like a time slot for the IETF 81 PWE3 >>>session by replying to this email with the desired duration, topic/draft >>>title, and presenter for each slot requested. >>> >>>Thanks, >>>Dave >>>_______________________________________________ >>>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 >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From yaakov_s@rad.com Tue Jul 26 13:27:06 2011 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 C965A5E800F for ; Tue, 26 Jul 2011 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYq7kd4ONCwl for ; Tue, 26 Jul 2011 13:27:05 -0700 (PDT) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37A5E8008 for ; Tue, 26 Jul 2011 13:27:04 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 26 Jul 2011 23:27:02 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 26 Jul 2011 23:26:50 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0289.001; Tue, 26 Jul 2011 23:26:50 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Thread-Topic: SDH protection documents Thread-Index: AcxL0lZb85yceIQmRAe5fzw6Zt6Qpw== Date: Tue, 26 Jul 2011 20:26:49 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E88868@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903E88868EXRAD5adradcoil_" MIME-Version: 1.0 Subject: [PWE3] SDH protection documents 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, 26 Jul 2011 20:27:06 -0000 --_000_07F7D7DED63154409F13298786A2ADC903E88868EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an answer to Luca's question about where MSP is defined (as Ghani said a= t the mike) Linear protection in general is defined in G.808.1 Ring protection in general is defined in G.808.2 (not yet published) Protection of SDH in particular is given in G.841 All of these documents can be downloaded free of charge from the ITU - http= ://www.itu.int/itu-t/recommendations/index.aspx?ser=3DG Y(J)S --_000_07F7D7DED63154409F13298786A2ADC903E88868EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As an answer to Luca's qu= estion about where MSP is defined (as Ghani said at the mike)

 

Linear protection in gene= ral is defined in G.808.1

Ring protection in genera= l is defined in G.808.2 (not yet published)

Protection of SDH in part= icular is given in G.841

 

All of these documents ca= n be downloaded free of charge from the ITU - htt= p://www.itu.int/itu-t/recommendations/index.aspx?ser=3DG

 

Y(J)S

&nbs= p;

 

--_000_07F7D7DED63154409F13298786A2ADC903E88868EXRAD5adradcoil_-- From wim.henderickx@alcatel-lucent.com Tue Jul 26 13:48:11 2011 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 E131D11E80B7; Tue, 26 Jul 2011 13:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwhZxsJ8MKBD; Tue, 26 Jul 2011 13:48:11 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBEA11E80A1; Tue, 26 Jul 2011 13:48:06 -0700 (PDT) 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 p6QKm4KT008907 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Jul 2011 22:48:04 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 26 Jul 2011 22:48:04 +0200 From: "Henderickx, Wim (Wim)" To: "yshen@juniper.net" , Rahul Aggarwal Date: Tue, 26 Jul 2011 22:48:01 +0200 Thread-Topic: draft-shen-pwe3-endpoint-fast-protection Thread-Index: AcxL1U7fI2okDnOnToe4ryNlXmqCWg== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "mpls@ietf.org" , "pwe3@ietf.org" Subject: [PWE3] draft-shen-pwe3-endpoint-fast-protection X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:48:12 -0000 Regarding the draft I have following remarks/questions/suggestions since we= had no discussion on the mike today. 1. Will this solution support revertive as well as non-revertive behavior a= fter failure recovery. How will it work? 2. Is the goal to make this solution applicable to MS-PW as well as dynamic= MS-PW FEC129. 3. In general we should add some applicability in the draft. In certain cas= es and depending on the applicability you could have un-optimized traffic f= lows. 5. We should discuss the RSVP procedures in this draft in the MPLS WG. Cheers, Wim From prvs=0188ce4536=hshah@ciena.com Tue Jul 26 14:19:45 2011 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 4A4C6228010 for ; Tue, 26 Jul 2011 14:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.936 X-Spam-Level: X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE2bH68iCi26 for ; Tue, 26 Jul 2011 14:19:44 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 695785E8008 for ; Tue, 26 Jul 2011 14:19:44 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p6QLF0Pu001914 for ; Tue, 26 Jul 2011 17:19:43 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id xt30j8duw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 17:19:43 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Tue, 26 Jul 2011 17:19:44 -0400 From: "Shah, Himanshu" To: "pwe3@ietf.org" Content-Class: urn:content-classes:message Date: Tue, 26 Jul 2011 17:19:42 -0400 Thread-Topic: draft-shen-pwe3-endpoint-fast-protection Thread-Index: AcxL2bwGcRIdFPF2To6qN/sR9YKbRQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18286.002 x-tm-as-result: No--51.267900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-26_06:2011-07-26, 2011-07-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107260199 Subject: [PWE3] draft-shen-pwe3-endpoint-fast-protection X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:19:45 -0000 --_004_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_ Content-Type: multipart/alternative; boundary="_000_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_" --_000_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yimin - The draft discusses protection schemes from the network perspective for a d= ual-homed CE. In the case of singled-sided protection failover from the networks (which i= s what is covered in the draft), how does CE handle the failover for the traffic in network d= irection (CE->protect-PE). Do you believe that a protection failover scheme that does not include part= icipation/coordination of dual-homed CE is a complete solution? Thanks, himanshu [cid:image96410a.gif@bf13ad43.84834cf3] --_000_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= meta content=3D"Microsoft Word 12 (filtered medium)" name=3DGenerator>
Yimin –

&n= bsp;

The draft discusses protection schemes f= rom the network perspective for a dual-homed CE.

In the case of singled-sided protection failover from the networks= (which is what is covered

in the draft)= , how does CE handle the failover for the traffic in network direction (CE-= >protect-PE).

 

Do you believe that a protection failover scheme that do= es not include participation/coordination of dual-homed CE

is a complete solution?

 

Thanks,

himanshu


=3D"ciena

= --_000_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_-- --_004_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_ Content-Type: image/gif; name="image96410a.gif@bf13ad43.84834cf3" Content-Description: image96410a.gif@bf13ad43.84834cf3 Content-Disposition: inline; filename="image96410a.gif@bf13ad43.84834cf3"; size=3410; creation-date="Tue, 26 Jul 2011 17:19:44 GMT"; modification-date="Tue, 26 Jul 2011 17:19:44 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --_004_B37E6A2CE5957F4E83C1D9845A0FFE386E35AB03MDWEXGMB02ciena_-- From zhang.fei3@zte.com.cn Tue Jul 26 15:30:52 2011 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 09E4921F86EE for ; Tue, 26 Jul 2011 15:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.029 X-Spam-Level: X-Spam-Status: No, score=-101.029 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaY-C7ievKtg for ; Tue, 26 Jul 2011 15:30:51 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id ADDD221F86C3 for ; Tue, 26 Jul 2011 15:30:50 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321397396305; Wed, 27 Jul 2011 06:22:33 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.1397396305; Wed, 27 Jul 2011 06:30:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6QMUbb3052712 for ; Wed, 27 Jul 2011 06:30:37 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) MIME-Version: 1.0 To: pwe3@ietf.org X-KeepSent: 50C150D7:2BBD3B33-482578D9:007A56E4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 27 Jul 2011 06:30:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-27 06:30:37, Serialize complete at 2011-07-27 06:30:37 Content-Type: multipart/alternative; boundary="=_alternative 007BA492482578D9_=" X-MAIL: mse01.zte.com.cn p6QMUbb3052712 Subject: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:30:52 -0000 This is a multipart message in MIME format. --=_alternative 007BA492482578D9_= Content-Type: text/plain; charset="US-ASCII" Hi PWEers This document is about the MPLS-TP PW proactive OAM capability negotiation and configuration, firstly the two T-PEs negotiate what MPLS-TP OAM function they support, then configure the corresponding OAM parameters. We will be highly appreciated if you can review and give any comments. Below is the link http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05 Thanks and best regards The authors --=_alternative 007BA492482578D9_= Content-Type: text/html; charset="US-ASCII"
Hi PWEers

This document is about the MPLS-TP PW proactive OAM capability negotiation and configuration, firstly the two T-PEs negotiate what MPLS-TP OAM function they support, then configure the corresponding OAM parameters.

We will be highly appreciated if you can review and give any comments.

Below is the link

http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05


Thanks and best regards

The authors --=_alternative 007BA492482578D9_=-- From zhang.fei3@zte.com.cn Tue Jul 26 15:41:37 2011 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 32A0411E80C0; Tue, 26 Jul 2011 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.17 X-Spam-Level: X-Spam-Status: No, score=-97.17 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmt++th2OIx6; Tue, 26 Jul 2011 15:41:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5B611E80BD; Tue, 26 Jul 2011 15:41:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643491178658; Wed, 27 Jul 2011 06:39:36 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.3533176257; Wed, 27 Jul 2011 06:41:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6QMfUnO054194; Wed, 27 Jul 2011 06:41:30 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: thomas.nadeau@ca.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 27 Jul 2011 06:41:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-27 06:41:30, Serialize complete at 2011-07-27 06:41:30 Content-Type: multipart/alternative; boundary="=_alternative 007CA3A6482578D9_=" X-MAIL: mse01.zte.com.cn p6QMfUnO054194 Cc: pwe3-bounces@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:41:37 -0000 This is a multipart message in MIME format. --=_alternative 007CA3A6482578D9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVG9tDQoNClNvcnJ5IEkgZG8gbm90IGNhdGNoIHlvdXIgaW50ZXJwcmV0YXRpb24gY2xlYXJs eSBpbiB0aGUgbWVldGluZy4NCg0KQXMgTWF0dGhldyBzYWlkLCBoZXJlIHRoZSBuZWdvdGlhdGlv biBpcyBhYm91dCB0aGUgQ1YgZnVuY3Rpb25zLCANCmVzcGVjaWFsbHkgZm9yIHRoZSBuZXdseSBk ZXZlbG9wZWQgTVBMUy1UUCBPQU0gZnVuY3Rpb25zLCBhbmQgaXQgaXMgZG9uZSANCmJlZm9yZSB0 aGUgc2V0dGluZyB1cCBvZiBQV3MuDQoNCldoZW4gdGhlIG5lZ290aWF0aW9uIGZpbmlzaGVkLCB0 aGlzIHdpbGwgbm90IGNoYW5nZWQgZHVyaW5nIFBXIGxpZmV0aW1lcyANCnNpbmNlIHRoZSBlcXVp cG1lbnQgd2lsbCBub3QgY2hhbmdlIHRoZSBPQU0gZnVuY3Rpb24gaXQgc3VwcG9ydGVkIA0KZnJl cXVlbnRseS4NCg0KRG8gSSBhbnN3ZXIgeW91ciBxdWVzdGlvbiBvciB0aGVyZSBhcmUgc3RpbGwg c29tZSBtaXN1bmRlcnN0YW5kaW5nPw0KDQpCZXN0IHJlZ2FyZHMNCg0KRmVpDQoNCg0KDQp6aGFu Zy5mZWkzQHp0ZS5jb20uY24gDQq3orz+yMs6ICBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEt MDctMjcgMDY6MzANCg0KytW8/sjLDQpwd2UzQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCltQV0Uz XSBSZXF1ZXN0IGNvbW1lbnRzIG9uIGRyYWZ0LXpoYW5nLW1wbHMtdHAtcHctb2FtLWNvbmZpZy0w NQ0KDQoNCg0KDQoNCg0KDQpIaSBQV0VlcnMgDQoNClRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgdGhl IE1QTFMtVFAgUFcgcHJvYWN0aXZlIE9BTSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIA0KYW5kIGNv bmZpZ3VyYXRpb24sIGZpcnN0bHkgdGhlIHR3byBULVBFcyBuZWdvdGlhdGUgd2hhdCBNUExTLVRQ IE9BTSANCmZ1bmN0aW9uIHRoZXkgc3VwcG9ydCwgdGhlbiBjb25maWd1cmUgdGhlIGNvcnJlc3Bv bmRpbmcgT0FNIHBhcmFtZXRlcnMuIA0KDQpXZSB3aWxsIGJlIGhpZ2hseSBhcHByZWNpYXRlZCBp ZiB5b3UgY2FuIHJldmlldyBhbmQgZ2l2ZSBhbnkgY29tbWVudHMuIA0KDQpCZWxvdyBpcyB0aGUg bGluayANCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctbXBscy10cC1w dy1vYW0tY29uZmlnLTA1IA0KDQoNClRoYW5rcyBhbmQgYmVzdCByZWdhcmRzIA0KDQpUaGUgYXV0 aG9yc19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2Uz IG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wd2UzDQoNCg0K --=_alternative 007CA3A6482578D9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U29ycnkgSSBkbyBub3QgY2F0Y2gg eW91ciBpbnRlcnByZXRhdGlvbg0KY2xlYXJseSBpbiB0aGUgbWVldGluZy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIE1hdHRoZXcgc2FpZCwgaGVy ZSB0aGUgbmVnb3RpYXRpb24NCmlzIGFib3V0IHRoZSBDViBmdW5jdGlvbnMsIGVzcGVjaWFsbHkg Zm9yIHRoZSBuZXdseSBkZXZlbG9wZWQgTVBMUy1UUCBPQU0NCmZ1bmN0aW9ucywgYW5kIGl0IGlz IGRvbmUgYmVmb3JlIHRoZSBzZXR0aW5nIHVwIG9mIFBXcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoZW4gdGhlIG5lZ290aWF0aW9uIGZpbmlzaGVk LCB0aGlzDQp3aWxsIG5vdCBjaGFuZ2VkIGR1cmluZyBQVyBsaWZldGltZXMgc2luY2UgdGhlIGVx dWlwbWVudCB3aWxsIG5vdCBjaGFuZ2UNCnRoZSBPQU0gZnVuY3Rpb24gaXQgc3VwcG9ydGVkIGZy ZXF1ZW50bHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5EbyBJIGFuc3dlciB5b3VyIHF1ZXN0aW9uIG9yIHRoZXJlIGFyZQ0Kc3RpbGwgc29tZSBtaXN1 bmRlcnN0YW5kaW5nPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9iPg0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3B3ZTMtYm91bmNlc0BpZXRm Lm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA3LTI3 IDA2OjMwPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPnB3ZTNAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltQV0UzXSBSZXF1ZXN0IGNvbW1lbnRzIG9uIGRyYWZ0LXpo YW5nLW1wbHMtdHAtcHctb2FtLWNvbmZpZy0wNTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBQV0Vl cnM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NClRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgdGhlIE1QTFMtVFAgUFcgcHJv YWN0aXZlIE9BTSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uDQphbmQgY29uZmlndXJhdGlvbiwgZmly c3RseSB0aGUgdHdvIFQtUEVzIG5lZ290aWF0ZSB3aGF0IE1QTFMtVFAgT0FNIGZ1bmN0aW9uDQp0 aGV5IHN1cHBvcnQsIHRoZW4gY29uZmlndXJlIHRoZSBjb3JyZXNwb25kaW5nIE9BTSBwYXJhbWV0 ZXJzLjwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCldlIHdpbGwgYmUgaGlnaGx5IGFwcHJlY2lhdGVkIGlmIHlvdSBj YW4gcmV2aWV3IGFuZCBnaXZlIGFueSBjb21tZW50cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpCZWxvdyBpcyB0 aGUgbGluazwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctbXBscy10cC1wdy1vYW0tY29uZmlnLTA1PC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtzIGFu ZCBiZXN0IHJlZ2FyZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoZSBhdXRob3JzPC9mb250Pjx0dD48Zm9udCBz aXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpwd2UzIG1haWxpbmcgbGlzdDxicj4NCnB3ZTNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 007CA3A6482578D9_=-- From lizhong.jin@zte.com.cn Tue Jul 26 16:50:23 2011 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 DD01D21F84AE for ; Tue, 26 Jul 2011 16:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6PVP2ZiGhQO for ; Tue, 26 Jul 2011 16:50:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9721F86A5 for ; Tue, 26 Jul 2011 16:50:21 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641397396305; Wed, 27 Jul 2011 07:48:13 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 13796.2201646218; Wed, 27 Jul 2011 07:50:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6QNoC10067840; Wed, 27 Jul 2011 07:50:12 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 27 Jul 2011 07:49:26 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-27 07:50:07, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-27 07:50:07, Serialize complete at 2011-07-27 07:50:07, S/MIME Sign failed at 2011-07-27 07:50:07: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-27 07:50:12, Serialize complete at 2011-07-27 07:50:12 Content-Type: multipart/alternative; boundary="=_alternative 0082EE60482578D9_=" X-MAIL: mse01.zte.com.cn p6QNoC10067840 Cc: rahul@juniper.net Subject: Re: [PWE3] draft-shen-pwe3-endpoint-fast-protection X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:50:24 -0000 This is a multipart message in MIME format. --=_alternative 0082EE60482578D9_= Content-Type: text/plain; charset="US-ASCII" Hi, Because of time limited, I also post the comments here: 1. It would be better to align the same protection concept with draft-ietf-mpls-seamless-mpls. In draft-seamless, it uses BGP anycast protection, and the context ID is the anycast address. The key point of protection method in draft-seamless and your draft are the same, by using anycast address. Maybe we can change the name to PW anycast protection... 2. Need more description of BGP procedure in this draft. The BGP procedure on protection PE is special for such kind fast protection. Thanks Lizhong ------------------------------- > Message: 2 > Date: Tue, 26 Jul 2011 22:48:01 +0200 > From: "Henderickx, Wim (Wim)" > To: "yshen@juniper.net" , Rahul Aggarwal > > Cc: "mpls@ietf.org" , "pwe3@ietf.org" > Subject: [PWE3] draft-shen-pwe3-endpoint-fast-protection > Message-ID: > <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m. > alcatel-lucent.com> > > Content-Type: text/plain; charset="us-ascii" > > Regarding the draft I have following remarks/questions/suggestions > since we had no discussion on the mike today. > > 1. Will this solution support revertive as well as non-revertive > behavior after failure recovery. How will it work? > 2. Is the goal to make this solution applicable to MS-PW as well as > dynamic MS-PW FEC129. > 3. In general we should add some applicability in the draft. In > certain cases and depending on the applicability you could have un- > optimized traffic flows. > 5. We should discuss the RSVP procedures in this draft in the MPLS WG. > > Cheers, > Wim > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0082EE60482578D9_= Content-Type: text/html; charset="US-ASCII"
Hi,
Because of time limited, I also post the comments here:
1. It would be better to align the same protection concept with draft-ietf-mpls-seamless-mpls. In draft-seamless, it uses BGP anycast protection, and the context ID is the anycast address. The key point of protection method in draft-seamless and your draft are the same, by using anycast address. Maybe we can change the name to PW anycast protection...
2. Need more description of BGP procedure in this draft. The BGP procedure on protection PE is special for such kind fast protection.

Thanks
Lizhong


-------------------------------
> Message: 2
> Date: Tue, 26 Jul 2011 22:48:01 +0200
> From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
> To: "yshen@juniper.net" <yshen@juniper.net>, Rahul Aggarwal
>    <rahul@juniper.net>
> Cc: "mpls@ietf.org" <mpls@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
> Subject: [PWE3] draft-shen-pwe3-endpoint-fast-protection
> Message-ID:
>    <14C7F4F06DB5814AB0DE29716C4F6D6719B82E37@FRMRSSXCHMBSB1.dc-m.
> alcatel-lucent.com>
>    
> Content-Type: text/plain; charset="us-ascii"
>
> Regarding the draft I have following remarks/questions/suggestions
> since we had no discussion on the mike today.
>
> 1. Will this solution support revertive as well as non-revertive
> behavior after failure recovery. How will it work?
> 2. Is the goal to make this solution applicable to MS-PW as well as
> dynamic MS-PW FEC129.
> 3. In general we should add some applicability in the draft. In
> certain cases and depending on the applicability you could have un-
> optimized traffic flows.
> 5. We should discuss the RSVP procedures in this draft in the MPLS WG.
>
> Cheers,
> Wim
>
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0082EE60482578D9_=-- From tnadeau@lucidvision.com Wed Jul 27 05:33:04 2011 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 529FE21F87FA; Wed, 27 Jul 2011 05:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgeY9V0kr+7j; Wed, 27 Jul 2011 05:33:03 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABDA21F87ED; Wed, 27 Jul 2011 05:33:03 -0700 (PDT) Received: from dhcp-472f.meeting.ietf.org (dhcp-472f.meeting.ietf.org [130.129.71.47]) by lucidvision.com (Postfix) with ESMTP id 324281D2A997; Wed, 27 Jul 2011 08:33:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_D8227561-FCF7-4CE2-95CC-B3C839C8A6A3" From: Thomas Nadeau In-Reply-To: Date: Wed, 27 Jul 2011 08:33:05 -0400 Message-Id: <84B12E38-FE23-4593-83A6-70F49F9AD459@lucidvision.com> References: To: zhang.fei3@zte.com.cn X-Mailer: Apple Mail (2.1244.3) Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, thomas.nadeau@ca.com Subject: Re: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:33:04 -0000 --Apple-Mail=_D8227561-FCF7-4CE2-95CC-B3C839C8A6A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 My concerns about this document (and the other related = "configuration via control protocols" documents) are the following: 1) Network configuration is a complicated matter. If you take a = quick look at NETCONF or any other configuration/provisioning = apparatus/protocols, you will see that provisioning is no simple matter = requiring all sorts of things to function including security, = synchronization, versioning control, etc... None are covered in your = draft - nor should they. The issue is that your draft is designing a = new means of configuration. 2) Synchronization between different configuration points. = Consider this case: the SP's OSS decides to provision a device and = alters some of the parameters pertaining to MIP/MEP configuration. Then = later, someone goes to the CLI of the same device and changes some of = those same parameters. Suddenly you are out-of-sync with the master = provisioning data base the service provider keeps within the OSS. Then = later, someone from *a different* device decides to make a different = change that suddenly appears at this device via the control plane = signaling. Viola, the configuration is even further out-of-sync.=20 3) You are making the issue of option coordination that Nick = describes in the recent survey that he conducted potentially worse by = opening up a new can of optional configuration types and options that = operators will further have to coordinate and rationalize. This retards = the deployments at best, and in the worst cases, makes them plain not = work. --Tom On Jul 26, 2011, at 6:41 PM, zhang.fei3@zte.com.cn wrote: >=20 > Hi Tom=20 >=20 > Sorry I do not catch your interpretation clearly in the meeting.=20 >=20 > As Matthew said, here the negotiation is about the CV functions, = especially for the newly developed MPLS-TP OAM functions, and it is done = before the setting up of PWs.=20 >=20 > When the negotiation finished, this will not changed during PW = lifetimes since the equipment will not change the OAM function it = supported frequently.=20 >=20 > Do I answer your question or there are still some misunderstanding?=20 >=20 > Best regards=20 >=20 > Fei=20 >=20 >=20 > zhang.fei3@zte.com.cn=20 > =B7=A2=BC=FE=C8=CB: pwe3-bounces@ietf.org > 2011-07-27 06:30 >=20 > =CA=D5=BC=FE=C8=CB > pwe3@ietf.org > =B3=AD=CB=CD > =D6=F7=CC=E2 > [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 >=20 >=20 >=20 >=20 >=20 >=20 > Hi PWEers=20 >=20 > This document is about the MPLS-TP PW proactive OAM capability = negotiation and configuration, firstly the two T-PEs negotiate what = MPLS-TP OAM function they support, then configure the corresponding OAM = parameters.=20 >=20 > We will be highly appreciated if you can review and give any comments.=20= >=20 > Below is the link=20 >=20 > http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05=20 >=20 >=20 > Thanks and best regards=20 >=20 > The authors_______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail=_D8227561-FCF7-4CE2-95CC-B3C839C8A6A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 = My concerns about this document (and the other related = "configuration via control protocols" documents) are the = following:

1) Network configuration is a = complicated matter. If you take a quick look at NETCONF or any other = configuration/provisioning apparatus/protocols, you will see that = provisioning is no simple matter requiring all sorts of things to = function including security, synchronization, versioning control, etc... = None are covered in your draft - nor should they.  The issue is = that your draft is designing a new means of = configuration.

2) Synchronization between = different configuration points. Consider this case: the SP's OSS decides = to provision a device and alters some of the parameters pertaining to = MIP/MEP configuration. Then later, someone goes to the CLI of the same = device and changes some of those same parameters. Suddenly you are = out-of-sync with the master provisioning data base the service provider = keeps within the OSS. Then later, someone from *a different* device = decides to make a different change that suddenly appears at this device = via the control plane signaling. Viola, the configuration is even = further out-of-sync. 

3) You = are making the issue of option coordination that Nick describes in the = recent survey that he conducted potentially worse by opening up a new = can of optional configuration types and options that operators will = further have to coordinate and rationalize. This retards the deployments = at best, and in the worst cases, makes them plain not = work.

= --Tom



On = Jul 26, 2011, at 6:41 PM, zhang.fei3@zte.com.cn = wrote:


Hi Tom

Sorry I do not catch your = interpretation clearly in the meeting.

As Matthew said, here the = negotiation is about the CV functions, especially for the newly developed MPLS-TP = OAM functions, and it is done before the setting up of PWs.

When the negotiation finished, = this will not changed during PW lifetimes since the equipment will not change the OAM function it supported frequently.

Do I answer your question or = there are still some misunderstanding?

Best regards

Fei


zhang.fei3@zte.com.cn
=B7=A2=BC=FE=C8=CB:  pwe3-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">2011-07-27 06:30

=CA=D5=BC=FE=C8=CB
pwe3@ietf.org
=B3=AD=CB=CD
=D6=F7=CC=E2
[PWE3] Request comments on = draft-zhang-mpls-tp-pw-oam-config-05






Hi PWEers

This document is about the MPLS-TP PW proactive OAM capability = negotiation and configuration, firstly the two T-PEs negotiate what MPLS-TP OAM = function they support, then configure the corresponding OAM = parameters.

We will be highly appreciated if you can review and give any = comments.

Below is the link

h= ttp://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05<= font size=3D"3">


Thanks and best regards

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

= --Apple-Mail=_D8227561-FCF7-4CE2-95CC-B3C839C8A6A3-- From david.i.allan@ericsson.com Wed Jul 27 07:09:04 2011 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 65A5721F8B22; Wed, 27 Jul 2011 07:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1-WgWkoxCdM; Wed, 27 Jul 2011 07:09:02 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8421F8B1D; Wed, 27 Jul 2011 07:09:02 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6RE8DIE017563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2011 09:09:01 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 10:08:44 -0400 From: David Allan I To: "pwe3@ietf.org" Date: Wed, 27 Jul 2011 10:08:43 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLw== Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> 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_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:09:04 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI
 
During yesterday's PWE session the subject of GALs and PWs came up.
 
To reiterate my concern, it was that the use of the GAL for a PW in a = network that could employ ECMP rendered the OAM useless. For some strange r= eason this is permitted in RFC 5586, while use of the GAL for a PW in an MP= LS-TP network is not (where the explicit prohibition against ECMP means it COULD be safely used), huh!???
 
My belief is that permitting the use of the GAL for PWs in both domain= s will result in MS-PWs for which the OAM is useless. FM PM, and DM will re= turn false indications due to the lack of fate sharing… so different = latency, out of order delivery of PM loss measurement, and potential false positives, or negatives for FM.
 
My conclusion was that IF steps were being taken such that reserved la= bels (or at least the GAL) were explicitly excluded from ECMP processing TH= EN it would make sense to open Pandora's box. During the meeting it was sug= gested this was the case in work progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion to things continuing on their merry way.
 
So I went and read the current version of the entropy label draft and = unfortunately this is only true in a narrow sense. Fate sharing would only = be preserved for implementations that ONLY hashed the bottom label of a PW = using the entropy label. Not for any generic use of the GAL with PWs.
 
So not only do I now believe the problem not on it’s way to reso= lution, IMO the scenario is actually GETTING WORSE. We are now permitting t= he GAL to be other than bottom label to address a narrow case and only a sm= all portion of RFC 4928. I would now assert that allowing the GAL to be other than the bottom label is a worse and inco= mplete solution vs. excluding label 13 from ECMP processing and is perpetua= ting a bad situation.
 
So t'was my bad for rolling over yesterday without doing my homework, = but there you have it
 
Dave
 
BTW If I could make a suggestion, if we are XORing one or more labels = together prior to doing further processing, also XOR it with 13, and make t= he GAL the ONE label value that has no effect. It would do the world a huge= favor.
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD52215D52A5EUSAACMS0703e_-- From jdrake@juniper.net Wed Jul 27 08:59:24 2011 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 E085611E80BF; Wed, 27 Jul 2011 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMXMUEYMuK5P; Wed, 27 Jul 2011 08:59:22 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 485AD11E80E8; Wed, 27 Jul 2011 08:59:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTjA11i0KJ1n1dYs84A4Mwy9NJUocY7Yj@postini.com; Wed, 27 Jul 2011 08:59:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 27 Jul 2011 08:56:21 -0700 From: John E Drake To: David Allan I , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 08:56:19 -0700 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFg Message-ID: <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> 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_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:59:25 -0000 --_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

<= p class=3DMsoNormal>A previous version of the Entropy Label draft st= ipulated that reserved labels were not to be input to a transit node’= s load balancing function;  this was inadvertently dropped from the cu= rrent version but will be re-added to the next version.  I am thinking= that a bis version of Stewart’s ECMP considerations RFC that also sp= ecifies this behavior would be the appropriate place to codify this once an= d for all.

 

Thanks,

 

John

 

Sent from my iPhone=

 

From: pwe3-bounces@ietf.org [mailto:p= we3-bounces@ietf.org] On Behalf Of David Allan I
Sent: Wed= nesday, July 27, 2011 7:09 AM
To: pwe3@ietf.org
Cc: mpl= s@ietf.org
Subject: [PWE3] Entropy labels and the GAL....

 

HI

 =

During yesterday's PWE session the subjec= t of GALs and PWs came up.

&nbs= p;

To reiterate my concern, it = was that the use of the GAL for a PW in a network that could employ ECMP re= ndered the OAM useless. For some strange reason this is permitted in RFC 55= 86, while use of the GAL for a PW in an MPLS-TP network is not (where the e= xplicit prohibition against ECMP means it COULD be safely used), huh!???

 

My belief is that permitting the use of the GAL for PWs i= n both domains will result in MS-PWs for which the OAM is useless. FM PM, a= nd DM will return false indications due to the lack of fate sharing… = so different latency, out of order delivery of PM loss measurement, and pot= ential false positives, or negatives for FM.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>My conclus= ion was that IF steps were being taken such that reserved labels (or at lea= st the GAL) were explicitly excluded from ECMP processing THEN it would mak= e sense to open Pandora's box. During the meeting it was suggested this was= the case in work progressing in draft-ietf-mpls-entropy-label-00 and so I = withdrew my objection to things continuing on their merry way.

 

So I went and read the current version of the entropy label draft a= nd unfortunately this is only true in a narrow sense. Fate sharing would on= ly be preserved for implementations that ONLY hashed the bottom label of a = PW using the entropy label. Not for any generic use of the GAL with PWs.

 

So not only do I now believe the problem not on it’= s way to resolution, IMO the scenario is actually GETTING WORSE. We are now= permitting the GAL to be other than bottom label to address a narrow case = and only a small portion of RFC 4928. I would now assert that allowing the = GAL to be other than the bottom label is a worse and incomplete solution vs= . excluding label 13 from ECMP processing and is perpetuating a bad situati= on.

 

So t'was my bad for rolling over yesterday without = doing my homework, but there you have it

 

Dave

 

<= p class=3DMsoNormal>BTW If I could make a suggestion, if we are XORing one or more l= abels together prior to doing further processing, also XOR it with 13, and = make the GAL the ONE label value that has no effect. It would do the world = a huge favor.

 =

 

 

= --_000_5E893DB832F57341992548CDBB333163A0AAEABD37EMBX01HQjnprn_-- From david.i.allan@ericsson.com Wed Jul 27 10:51:18 2011 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 5E20A21F8AF3; Wed, 27 Jul 2011 10:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9YXaUgAgLFa; Wed, 27 Jul 2011 10:51:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id B012111E80DF; Wed, 27 Jul 2011 10:51:15 -0700 (PDT) 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 p6RHonBK018840; Wed, 27 Jul 2011 12:51:13 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 13:51:04 -0400 From: David Allan I To: John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 13:51:02 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:51:18 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI John:
 
Thanks for this!
 
Updating 4928 to me is the right way to go but I'd al= so want=20 to see us revert to restricting GAL to bottom label at the same time.=20 It also means that we are saying SOMETHING prescript= ive=20 about ECMP implementations which is "where no MPLS RFC has gone before", bu= t I=20 for one am OK with that, IMO it is long overdue!
 
cheers
Dave

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 11:56 AM
To: David Alla= n I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D552EEUSAACMS0703e_-- From jdrake@juniper.net Wed Jul 27 11:05:07 2011 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 F094B11E80DF; Wed, 27 Jul 2011 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNcoeTi2uoQ4; Wed, 27 Jul 2011 11:05:04 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id D133D11E8075; Wed, 27 Jul 2011 11:05:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTjBTRRpX/nlI6Llpz9i+HZDxt4TpW50A@postini.com; Wed, 27 Jul 2011 11:05:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 27 Jul 2011 11:03:26 -0700 From: John E Drake To: David Allan I , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 11:03:25 -0700 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYA== Message-ID: <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> 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_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:05:07 -0000 --_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

<= p class=3DMsoNormal>Unfortunately that is not possible.   = The GAL effectively functions as an application label, and the logic at the= egress node uses the application label, in which it would normally expect = to see BOS set to 1, with BOS  set to 0 as an indicator of the presenc= e of an entropy label.

 

Thanks,

 

John

 

Sent from my iPhon= e

 <= /span>

From: David Allan I [mai= lto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 2011 1= 0:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.o= rg; Kireeti Kompella
Subject: RE: Entropy labels and the GAL....<= o:p>

 

=

HI John:

&= nbsp;

Thanks for this!

 

Upda= ting 4928 to me is the right way to go but I'd also want to see us revert t= o restricting GAL to bottom label at the same time. It also means that=  we are saying SOMETHING prescriptive about ECMP implementations which= is "where no MPLS RFC has gone before", but I for one am OK with= that, IMO it is long overdue!

&n= bsp;

cheers

Dave

 = ;

From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM
To: David Allan = I; pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subjec= t: RE: Entropy labels and the GAL....

Dave,

 

A previous version of t= he Entropy Label draft stipulated that reserved labels were not to be input= to a transit node’s load balancing function;  this was inadvert= ently dropped from the current version but will be re-added to the next ver= sion.  I am thinking that a bis version of Stewart’s ECMP consid= erations RFC that also specifies this behavior would be the appropriate pla= ce to codify this once and for all.

 

Thanks,

 

John

 

Sent= from my iPhone

 

From: pwe3-= bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of David A= llan I
Sent: Wednesday, July 27, 2011 7:09 AM
To: pwe3@= ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy labe= ls and the GAL....

 

HI

 

During yesterda= y's PWE session the subject of GALs and PWs came up.

<= /div>

 

To= reiterate my concern, it was that the use of the GAL for a PW in a network= that could employ ECMP rendered the OAM useless. For some strange reason t= his is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP n= etwork is not (where the explicit prohibition against ECMP means it COULD b= e safely used), huh!???

 <= o:p>

My belief is that permitting th= e use of the GAL for PWs in both domains will result in MS-PWs for which th= e OAM is useless. FM PM, and DM will return false indications due to the la= ck of fate sharing… so different latency, out of order delivery of PM= loss measurement, and potential false positives, or negatives for FM.=

 

<= div>

My conclusion was that IF steps were being taken such that = reserved labels (or at least the GAL) were explicitly excluded from ECMP pr= ocessing THEN it would make sense to open Pandora's box. During the meeting= it was suggested this was the case in work progressing in draft-ietf-mpls-= entropy-label-00 and so I withdrew my objection to things continuing on the= ir merry way.

 =

So I went and read the current version of= the entropy label draft and unfortunately this is only true in a narrow se= nse. Fate sharing would only be preserved for implementations that ONLY has= hed the bottom label of a PW using the entropy label. Not for any generic u= se of the GAL with PWs.

 <= o:p>

So not only do I now believe th= e problem not on it’s way to resolution, IMO the scenario is actually= GETTING WORSE. We are now permitting the GAL to be other than bottom label= to address a narrow case and only a small portion of RFC 4928. I would now= assert that allowing the GAL to be other than the bottom label is a worse = and incomplete solution vs. excluding label 13 from ECMP processing and is = perpetuating a bad situation.

&= nbsp;

So t'was my bad for rolli= ng over yesterday without doing my homework, but there you have it

 

=

Dave

 

BTW If I could make a suggestion, if w= e are XORing one or more labels together prior to doing further processing,= also XOR it with 13, and make the GAL the ONE label value that has no effe= ct. It would do the world a huge favor.

 

 

 

= --_000_5E893DB832F57341992548CDBB333163A0AAEAC004EMBX01HQjnprn_-- From david.i.allan@ericsson.com Wed Jul 27 11:18:01 2011 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 32DA221F8BB9; Wed, 27 Jul 2011 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqu2lR05-Af3; Wed, 27 Jul 2011 11:17:58 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0715921F8867; Wed, 27 Jul 2011 11:17:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6RIHvsb004739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jul 2011 13:17:57 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Jul 2011 14:17:56 -0400 From: David Allan I To: John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:17:54 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYAAAU2KA Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D557C@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:18:01 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm confused, this suggests that the GAL is an ELI for OAM and somthing els= e is an ELI for payload. IMO that seems broken unless you are only hashing = top label. Presumably an entropy label can alias as a GAL or RA as well..? D ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 2:03 PM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm confused, this suggests that the GAL is an ELI fo= r OAM and=20 somthing else is an ELI for payload. IMO that seems broken unless you are o= nly=20 hashing top label.
 
Presumably an entropy label can alias as a GAL or RA = as=20 well..?
 
D
 
 

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 2:03 PM
To: David Allan= I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

Unfortunately=20 that is not possible.   The GAL effectively functions as an=20 application label, and the logic at the egress node uses the application la= bel,=20 in which it would normally expect to see BOS set to 1, with BOS  set t= o 0=20 as an indicator of the presence of an entropy label.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 20= 11=20 10:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.= org;=20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

 

H= I=20 John:

 

T= hanks=20 for this!

 

U= pdating=20 4928 to me is the right way to go but I'd also want to see us revert to=20 restricting GAL to bottom label at the same time. It also means=20 that we are saying SOMETHING prescriptive about ECMP implementations w= hich=20 is "where no MPLS RFC has gone before", but I for one am OK with that, IMO = it is=20 long overdue!

 

c= heers

D= ave

 

From:<= /B> John E Drake= =20 [mailto:jdrake@juniper.net]
Sent: Wednesday, July 27, 2011 11:56= =20 AM
To: David Allan I; pwe3@ietf.org
Cc: mpls@ietf.org;= =20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D557CEUSAACMS0703e_-- From david.i.allan@ericsson.com Wed Jul 27 11:26:30 2011 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 662E611E809E; Wed, 27 Jul 2011 11:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPVwLSTwavf3; Wed, 27 Jul 2011 11:26:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 238DD11E8125; Wed, 27 Jul 2011 11:26:27 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RIQLcG026776; Wed, 27 Jul 2011 13:26:22 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Jul 2011 14:26:19 -0400 From: David Allan I To: David Allan I , John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:26:17 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYAAAU2KAAACdDtA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D5598@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:26:30 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I withdraw the second comment... D ________________________________ From: David Allan I Sent: Wednesday, July 27, 2011 2:18 PM To: 'John E Drake'; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... I'm confused, this suggests that the GAL is an ELI for OAM and somthing els= e is an ELI for payload. IMO that seems broken unless you are only hashing = top label. Presumably an entropy label can alias as a GAL or RA as well..? D ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 2:03 PM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I withdraw the second comment...
 
D

From: David Allan I
Sent: We= dnesday,=20 July 27, 2011 2:18 PM
To: 'John E Drake'; pwe3@ietf.org
Cc:= =20 mpls@ietf.org; Kireeti Kompella
Subject: RE: Entropy labels and t= he=20 GAL....

I'm confused, this suggests that the GAL is an ELI fo= r OAM and=20 somthing else is an ELI for payload. IMO that seems broken unless you are o= nly=20 hashing top label.
 
Presumably an entropy label can alias as a GAL or RA = as=20 well..?
 
D
 
 

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 2:03 PM
To: David Allan= I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

Unfortunately=20 that is not possible.   The GAL effectively functions as an=20 application label, and the logic at the egress node uses the application la= bel,=20 in which it would normally expect to see BOS set to 1, with BOS  set t= o 0=20 as an indicator of the presence of an entropy label.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 20= 11=20 10:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.= org;=20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

 

H= I=20 John:

 

T= hanks=20 for this!

 

U= pdating=20 4928 to me is the right way to go but I'd also want to see us revert to=20 restricting GAL to bottom label at the same time. It also means=20 that we are saying SOMETHING prescriptive about ECMP implementations w= hich=20 is "where no MPLS RFC has gone before", but I for one am OK with that, IMO = it is=20 long overdue!

 

c= heers

D= ave

 

From:<= /B> John E Drake= =20 [mailto:jdrake@juniper.net]
Sent: Wednesday, July 27, 2011 11:56= =20 AM
To: David Allan I; pwe3@ietf.org
Cc: mpls@ietf.org;= =20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D5598EUSAACMS0703e_-- From david.i.allan@ericsson.com Wed Jul 27 11:36:53 2011 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 62E4621F8B53; Wed, 27 Jul 2011 11:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46Ai8fS1KVgn; Wed, 27 Jul 2011 11:36:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id D900221F8B3C; Wed, 27 Jul 2011 11:36:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RIaiKW029120; Wed, 27 Jul 2011 13:36:49 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 27 Jul 2011 14:36:42 -0400 From: David Allan I To: David Allan I , John E Drake , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:36:40 -0400 Thread-Topic: Entropy labels and the GAL.... Thread-Index: AcxMZrG3kG9l80ypSxWDynB2neJLLwADnhFgAAOEsbAAAOkpYAAAU2KAAADXB+A= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> 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_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_" MIME-Version: 1.0 Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:36:53 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies for repeated messages.... I'm confused as to why the GAL takes the role of the application label. It = does not seem necessary. If I want PW OAM the PW label would need to be the= re, if I were to fate share with the path taken for the flow associated wit= h the entopy label, the TL, AL, ELI etc. all have to be there as the draft = recommends using the whole stack as a key. So IMO there is no apparent justification for overloading the GAL and remov= ing the BOS restriction...There is justification for not hashing reserved l= abels... ? Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 2:03 PM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, Unfortunately that is not possible. The GAL effectively functions as an a= pplication label, and the logic at the egress node uses the application lab= el, in which it would normally expect to see BOS set to 1, with BOS set to= 0 as an indicator of the presence of an entropy label. Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, July 27, 2011 10:51 AM To: John E Drake; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... HI John: Thanks for this! Updating 4928 to me is the right way to go but I'd also want to see us reve= rt to restricting GAL to bottom label at the same time. It also means that = we are saying SOMETHING prescriptive about ECMP implementations which is "w= here no MPLS RFC has gone before", but I for one am OK with that, IMO it is= long overdue! cheers Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Wednesday, July 27, 2011 11:56 AM To: David Allan I; pwe3@ietf.org Cc: mpls@ietf.org; Kireeti Kompella Subject: RE: Entropy labels and the GAL.... Dave, A previous version of the Entropy Label draft stipulated that reserved labe= ls were not to be input to a transit node's load balancing function; this = was inadvertently dropped from the current version but will be re-added to = the next version. I am thinking that a bis version of Stewart's ECMP consi= derations RFC that also specifies this behavior would be the appropriate pl= ace to codify this once and for all. Thanks, John Sent from my iPhone From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Wednesday, July 27, 2011 7:09 AM To: pwe3@ietf.org Cc: mpls@ietf.org Subject: [PWE3] Entropy labels and the GAL.... HI During yesterday's PWE session the subject of GALs and PWs came up. To reiterate my concern, it was that the use of the GAL for a PW in a netwo= rk that could employ ECMP rendered the OAM useless. For some strange reason= this is permitted in RFC 5586, while use of the GAL for a PW in an MPLS-TP= network is not (where the explicit prohibition against ECMP means it COULD= be safely used), huh!??? My belief is that permitting the use of the GAL for PWs in both domains wil= l result in MS-PWs for which the OAM is useless. FM PM, and DM will return = false indications due to the lack of fate sharing... so different latency, = out of order delivery of PM loss measurement, and potential false positives= , or negatives for FM. My conclusion was that IF steps were being taken such that reserved labels = (or at least the GAL) were explicitly excluded from ECMP processing THEN it= would make sense to open Pandora's box. During the meeting it was suggeste= d this was the case in work progressing in draft-ietf-mpls-entropy-label-00= and so I withdrew my objection to things continuing on their merry way. So I went and read the current version of the entropy label draft and unfor= tunately this is only true in a narrow sense. Fate sharing would only be pr= eserved for implementations that ONLY hashed the bottom label of a PW using= the entropy label. Not for any generic use of the GAL with PWs. So not only do I now believe the problem not on it's way to resolution, IMO= the scenario is actually GETTING WORSE. We are now permitting the GAL to b= e other than bottom label to address a narrow case and only a small portion= of RFC 4928. I would now assert that allowing the GAL to be other than the= bottom label is a worse and incomplete solution vs. excluding label 13 fro= m ECMP processing and is perpetuating a bad situation. So t'was my bad for rolling over yesterday without doing my homework, but t= here you have it Dave BTW If I could make a suggestion, if we are XORing one or more labels toget= her prior to doing further processing, also XOR it with 13, and make the GA= L the ONE label value that has no effect. It would do the world a huge favo= r. --_000_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Apologies for repeated messages....
 
I'm=20 confused as to why the GAL takes the role of the application label. It= does=20 not seem necessary. If I want PW OAM the PW label would = ;need=20 to be there, if I were to fate share with the path taken for the flow= =20 associated with the entopy label, the TL, AL, ELI etc. all have to be there= as=20 the draft recommends using the whole stack as a=20 key. 
 
So IMO=20 there is no apparent justification for overloading the GAL and removing the= BOS=20 restriction...There is justification for not hashing reserved=20 labels...
 
?
Dave
 
 
From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Wednesday, July 27, 2011 2:03 PM
To: David Allan= I;=20 pwe3@ietf.org
Cc: mpls@ietf.org; Kireeti Kompella
Subject:<= /B>=20 RE: Entropy labels and the GAL....

Dave,

 

Unfortunately=20 that is not possible.   The GAL effectively functions as an=20 application label, and the logic at the egress node uses the application la= bel,=20 in which it would normally expect to see BOS set to 1, with BOS  set t= o 0=20 as an indicator of the presence of an entropy label.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Wednesday, July 27, 20= 11=20 10:51 AM
To: John E Drake; pwe3@ietf.org
Cc: mpls@ietf.= org;=20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

 

H= I=20 John:

 

T= hanks=20 for this!

 

U= pdating=20 4928 to me is the right way to go but I'd also want to see us revert to=20 restricting GAL to bottom label at the same time. It also means=20 that we are saying SOMETHING prescriptive about ECMP implementations w= hich=20 is "where no MPLS RFC has gone before", but I for one am OK with that, IMO = it is=20 long overdue!

 

c= heers

D= ave

 

From:<= /B> John E Drake= =20 [mailto:jdrake@juniper.net]
Sent: Wednesday, July 27, 2011 11:56= =20 AM
To: David Allan I; pwe3@ietf.org
Cc: mpls@ietf.org;= =20 Kireeti Kompella
Subject: RE: Entropy labels and the=20 GAL....

Dave,

 

A=20 previous version of the Entropy Label draft stipulated that reserved labels= were=20 not to be input to a transit node’s load balancing function;  th= is was=20 inadvertently dropped from the current version but will be re-added to the = next=20 version.  I am thinking that a bis version of Stewart’s ECMP con= siderations=20 RFC that also specifies this behavior would be the appropriate place to cod= ify=20 this once and for all.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B>=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Da= vid=20 Allan I
Sent: Wednesday, July 27, 2011 7:09 AM
To:=20 pwe3@ietf.org
Cc: mpls@ietf.org
Subject: [PWE3] Entropy= =20 labels and the GAL....

 

HI=20

 

During yesterd= ay's=20 PWE session the subject of GALs and PWs came up.

 

To reiterate m= y=20 concern, it was that the use of the GAL for a PW in a network that could em= ploy=20 ECMP rendered the OAM useless. For some strange reason this is permitted in= RFC=20 5586, while use of the GAL for a PW in an MPLS-TP network is not (where the= =20 explicit prohibition against ECMP means it COULD be safely used),=20 huh!???

 

My belief is t= hat=20 permitting the use of the GAL for PWs in both domains will result in MS-PWs= for=20 which the OAM is useless. FM PM, and DM will return false indications due t= o the=20 lack of fate sharing… so different latency, out of order delivery of = PM loss=20 measurement, and potential false positives, or negatives for=20 FM.

 

My conclusion = was=20 that IF steps were being taken such that reserved labels (or at least the G= AL)=20 were explicitly excluded from ECMP processing THEN it would make sense to o= pen=20 Pandora's box. During the meeting it was suggested this was the case in wor= k=20 progressing in draft-ietf-mpls-entropy-label-00 and so I withdrew my object= ion=20 to things continuing on their merry way.

 

So I went and = read=20 the current version of the entropy label draft and unfortunately this is on= ly=20 true in a narrow sense. Fate sharing would only be preserved for implementa= tions=20 that ONLY hashed the bottom label of a PW using the entropy label. Not for = any=20 generic use of the GAL with PWs.

 

So not only do= I now=20 believe the problem not on it’s way to resolution, IMO the scenario i= s actually=20 GETTING WORSE. We are now permitting the GAL to be other than bottom label = to=20 address a narrow case and only a small portion of RFC 4928. I would now ass= ert=20 that allowing the GAL to be other than the bottom label is a worse and=20 incomplete solution vs. excluding label 13 from ECMP processing and is=20 perpetuating a bad situation.

 

So t'was my ba= d for=20 rolling over yesterday without doing my homework, but there you have=20 it

 

Dave

 

BTW If I could= make a=20 suggestion, if we are XORing one or more labels together prior to doing fur= ther=20 processing, also XOR it with 13, and make the GAL the ONE label value that = has=20 no effect. It would do the world a huge favor.

 

 

 

--_000_60C093A41B5E45409A19D42CF7786DFD52215D55B5EUSAACMS0703e_-- From stbryant@cisco.com Wed Jul 27 11:44:52 2011 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 9510911E8137 for ; Wed, 27 Jul 2011 11:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysgb02wEgt0w for ; Wed, 27 Jul 2011 11:44:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5C11E8150 for ; Wed, 27 Jul 2011 11:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2459; q=dns/txt; s=iport; t=1311792289; x=1313001889; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=CXNnYUlldTnSNcLcpZLZqgks5lA1OArRQaFRLu/Jhs8=; b=dBeYeaD+pOb345LKyHXArLHOePuyFFob0hl5GC9BnEKOETfmn5Pt89/t EE457R14uoHCB3HWPaW0W9OY+fMqfNhUKPe7x2jb7uo5d6xRkIiz/e1Np iZFpMOP6n8KE0ukNj/OrpZsu+NqLLQYlNZsxvsYh3Tlj7K/sqN+IgKV42 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFAK1bME6Q/khR/2dsb2JhbAA1AQEBAQIBFAEEAWoGDAwEARwiDwkDAgECAQJRFQ8BAR+YH48Ed4h8o0KDFg8Bm0aGQASSdZBj X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208,217";a="45015705" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:44:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIimWW021528 for ; Wed, 27 Jul 2011 18:44:49 GMT Received: from dhcp-57a9.meeting.ietf.org (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6RIiiMf022996; Wed, 27 Jul 2011 19:44:44 +0100 (BST) Message-ID: <4E305C9C.7010709@cisco.com> Date: Wed, 27 Jul 2011 19:44:44 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pwe3@ietf.org References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D557C@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D557C@EUSAACMS0703.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------040607080803090800000002" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:44:52 -0000 This is a multi-part message in MIME format. --------------040607080803090800000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Presumably an entropy label can alias as a GAL or RA as well..? Dave There may have been some confusion in our discussion at the Mike yesterday. A fat label cannot be a reserved label. If the hash of the flow signature aliases to a reserved label and new hash must be generated, or the hash suitably modified (for example by adding 16 to the output, or forcing a bit, or rehashing ....). If this is not done all mechanisms that use reserved labels will break. You may however have been making a different point that I missed. Stewart --------------040607080803090800000002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Presumably an entropy label can alias as a GAL or RA as well..?
 
Dave

There may have been some confusion in our discussion at the Mike yesterday.

A fat label cannot be a reserved label. If the hash of the flow signature
aliases to a reserved label and new hash must be generated, or the hash
suitably modified (for example by adding 16 to the output, or forcing a bit, or
rehashing ....). If this is not done all  mechanisms that use reserved labels
will break.

You may however have been making a different point that I missed.

Stewart


 --------------040607080803090800000002-- From stbryant@cisco.com Wed Jul 27 11:48:52 2011 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 06C6411E8143; Wed, 27 Jul 2011 11:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6CWmwCco2C7; Wed, 27 Jul 2011 11:48:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F811E8084; Wed, 27 Jul 2011 11:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1290; q=dns/txt; s=iport; t=1311792525; x=1313002125; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=OsnFxgkOspkZaMwY0GAW0Uar1N8QzKrgstJjs5ZpiZw=; b=i8vnzP0Lrwf+aFixD7kXjx9VnzvAdHTZDzdtGjtO8XgCXcDSP4hs8x0+ kYlObipzplcNMMRg1VfZTk2COn2opXHTIGsvJQWTSrcl65o4Ha75rMWve +N+hfmelLbKpqbJuMQfNREhRTmkPTAhMN/mTiIYCNA6ZwQe7SP8Zrlkug A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMZcME6Q/khM/2dsb2JhbAAoDQEBAQECARQBBAFqAQUMDAMBHSIPCQMCAQIBAlEHDgEOAQEfpyN3iHyjKYMWDwGbRoZABJJ1kGM X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208,217";a="45015943" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:48:44 +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 p6RImiU0017608; Wed, 27 Jul 2011 18:48:44 GMT Received: from dhcp-57a9.meeting.ietf.org (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6RImg9r023283; Wed, 27 Jul 2011 19:48:43 +0100 (BST) Message-ID: <4E305D8A.3080600@cisco.com> Date: Wed, 27 Jul 2011 19:48:42 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: David Allan I References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------070300060506000608040003" Cc: Kireeti Kompella , "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:48:52 -0000 This is a multi-part message in MIME format. --------------070300060506000608040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > There /is/ justification for not hashing reserved labels... That would fix a bunch of the OAM problems, but unfortunately would not be backwards compatible with deployed P routers or SPEs Stewart --------------070300060506000608040003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

> There is justification for not hashing reserved labels...

That would fix a bunch of the OAM problems, but unfortunately 
would not be backwards compatible with deployed
P routers or SPEs

Stewart
 --------------070300060506000608040003-- From david.i.allan@ericsson.com Wed Jul 27 11:50:02 2011 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 D838111E8145 for ; Wed, 27 Jul 2011 11:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoNGYGANyDI2 for ; Wed, 27 Jul 2011 11:50:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id BA26E11E8141 for ; Wed, 27 Jul 2011 11:49:56 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6RInsuo032131; Wed, 27 Jul 2011 13:49:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 27 Jul 2011 14:49:51 -0400 From: David Allan I To: "stbryant@cisco.com" , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 14:49:50 -0400 Thread-Topic: [PWE3] Entropy labels and the GAL.... Thread-Index: AcxMjZRaW+om9s6KTD2D4GlBFYbClgAABwPw Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D55D4@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D557C@EUSAACMS0703.eamcs.ericsson.se> <4E305C9C.7010709@cisco.com> In-Reply-To: <4E305C9C.7010709@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52215D55D4EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:50:03 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55D4EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, I had not read the entire document at that point, it is clear on precluding= use of a reserved value for an entropy label....just had not hit that part= hopping around the content... D ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Wednesday, July 27, 2011 2:45 PM To: pwe3@ietf.org Subject: Re: [PWE3] Entropy labels and the GAL.... Presumably an entropy label can alias as a GAL or RA as well..? Dave There may have been some confusion in our discussion at the Mike yesterday. A fat label cannot be a reserved label. If the hash of the flow signature aliases to a reserved label and new hash must be generated, or the hash suitably modified (for example by adding 16 to the output, or forcing a bit= , or rehashing ....). If this is not done all mechanisms that use reserved labe= ls will break. You may however have been making a different point that I missed. Stewart --_000_60C093A41B5E45409A19D42CF7786DFD52215D55D4EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Stewart,
 
I had not read the entire document at that point, it = is=20 clear on precluding use of a reserved value for an entropy label....ju= st=20 had not hit that part hopping around the content...
 
D

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart=20 Bryant
Sent: Wednesday, July 27, 2011 2:45 PM
To:=20 pwe3@ietf.org
Subject: Re: [PWE3] Entropy labels and the=20 GAL....


Presumably an entropy label can alias as a GAL or R= A as=20 well..?
 
Dave

There may hav= e been some=20 confusion in our discussion at the Mike yesterday.

A fat label canno= t be=20 a reserved label. If the hash of the flow signature
aliases to a reserv= ed=20 label and new hash must be generated, or the hash
suitably modified (for= =20 example by adding 16 to the output, or forcing a bit, or
rehashing ....)= . If=20 this is not done all  mechanisms that use reserved labels
will=20 break.

You may however have been making a different point that I=20 missed.

Stewart


 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55D4EUSAACMS0703e_-- From david.i.allan@ericsson.com Wed Jul 27 11:52:43 2011 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 19C1411E8084; Wed, 27 Jul 2011 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMoXKxPB+TFQ; Wed, 27 Jul 2011 11:52:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 68BDD21F8BA4; Wed, 27 Jul 2011 11:52:40 -0700 (PDT) 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 p6RIqc6P000305; Wed, 27 Jul 2011 13:52:39 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jul 2011 14:52:35 -0400 From: David Allan I To: "stbryant@cisco.com" Date: Wed, 27 Jul 2011 14:52:35 -0400 Thread-Topic: [PWE3] Entropy labels and the GAL.... Thread-Index: AcxMjdbi8RLYVFA6SA+OdaTm68h1DgAACn1w Message-ID: <60C093A41B5E45409A19D42CF7786DFD52215D55DD@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD52215D52A5@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEABD37@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D552E@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A0AAEAC004@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD52215D55B5@EUSAACMS0703.eamcs.ericsson.se> <4E305D8A.3080600@cisco.com> In-Reply-To: <4E305D8A.3080600@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_" MIME-Version: 1.0 Cc: Kireeti Kompella , "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] Entropy labels and the GAL.... X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:52:43 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which gets back to my original point, creating an environment where we woul= d use a GAL where existing kit would obstruct fate sharing is IMO a mistake= ... I can't stuff toothpaste back into the tube, but I can avoid squeezing the = tube again.... D ________________________________ From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, July 27, 2011 2:49 PM To: David Allan I Cc: John E Drake; pwe3@ietf.org; Kireeti Kompella; mpls@ietf.org Subject: Re: [PWE3] Entropy labels and the GAL.... > There is justification for not hashing reserved labels... That would fix a bunch of the OAM problems, but unfortunately would not be backwards compatible with deployed P routers or SPEs Stewart --_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Which gets back to my original point, creating an env= ironment=20 where we would use a GAL where existing kit would obstruct fate sharing is = IMO a=20 mistake...
 
I can't stuff toothpaste back into the tube, but I ca= n avoid=20 squeezing the tube again....
 
D

From: Stewart Bryant [mailto:stbryant@c= isco.com]=20
Sent: Wednesday, July 27, 2011 2:49 PM
To: David Allan= =20 I
Cc: John E Drake; pwe3@ietf.org; Kireeti Kompella;=20 mpls@ietf.org
Subject: Re: [PWE3] Entropy labels and the=20 GAL....



> There is justification for not hashing reserved= =20 labels...

That would fix a bunch of the OAM problems, but=20 unfortunately 
would not be backwards compatible with deployed P=20 routers or SPEs

Stewart
 --_000_60C093A41B5E45409A19D42CF7786DFD52215D55DDEUSAACMS0703e_-- From gregimirsky@gmail.com Wed Jul 27 12:34:23 2011 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 515935E802A for ; Wed, 27 Jul 2011 12:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMFOsVliBdM8 for ; Wed, 27 Jul 2011 12:34:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFE35E8016 for ; Wed, 27 Jul 2011 12:34:22 -0700 (PDT) Received: by vxi40 with SMTP id 40so1775044vxi.31 for ; Wed, 27 Jul 2011 12:34:18 -0700 (PDT) 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:content-transfer-encoding; bh=KGLqpHg/TalLfZR/LZk+0dMQqRQj54VdWl6XOq0svrM=; b=biWP5M9RvOrbPMiLpqBNqoY64hUSEVTOuBPuSh4eha3tjSGIc0KSnkIYviwEnMs6sp JCzrM8MZKL+4zsYfTJ9qOv0hdtBNdJIL07sNc/bnhdEQ0YcAmTUIbEvuNA9E+K3qvMqN e7uDc5Dyr/dWpp05S/mKXVwmSCdDv5rsnJNPU= MIME-Version: 1.0 Received: by 10.52.188.68 with SMTP id fy4mr252845vdc.91.1311795258905; Wed, 27 Jul 2011 12:34:18 -0700 (PDT) Received: by 10.52.160.228 with HTTP; Wed, 27 Jul 2011 12:34:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2011 12:34:18 -0700 Message-ID: From: Greg Mirsky To: "Bocci, Matthew (Matthew)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-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: Wed, 27 Jul 2011 19:34:23 -0000 yes/support Regards, Greg On Tue, Jul 19, 2011 at 6:36 AM, Bocci, Matthew (Matthew) wrote: > This email begins a poll of the list to see if there is consensus to > adopt=A0draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 > working group draft. > Please indicate whether or not you support adoption of this draft, and se= nd > any comments to the PWE3 list. > This poll ends on Tuesday 9th August. > Regards, > Matthew and Andy. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From tnadeau@lucidvision.com Wed Jul 27 12:44:56 2011 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 8B8A211E80F2 for ; Wed, 27 Jul 2011 12:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO5YyeEMwMJ4 for ; Wed, 27 Jul 2011 12:44:56 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5311E8073 for ; Wed, 27 Jul 2011 12:44:55 -0700 (PDT) Received: from [130.129.19.44] (dhcp-132c.meeting.ietf.org [130.129.19.44]) by lucidvision.com (Postfix) with ESMTP id A997A1D2D295; Wed, 27 Jul 2011 15:44:54 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <57D06B83-4954-485E-8C48-908DFCA80168@lucidvision.com> X-Mailer: iPad Mail (8J2) From: Thomas Nadeau Date: Wed, 27 Jul 2011 15:45:17 -0400 To: Greg Mirsky Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll for draft-martini-pwe3-status-aggregation-protocol-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: Wed, 27 Jul 2011 19:44:56 -0000 I support as a WG item but I think the solution as proposed I the draft itse= lf needs some work. Tom=20 On Jul 27, 2011, at 3:34 PM, Greg Mirsky wrote: > yes/support >=20 > Regards, > Greg >=20 > On Tue, Jul 19, 2011 at 6:36 AM, Bocci, Matthew (Matthew) > wrote: >> This email begins a poll of the list to see if there is consensus to >> adopt draft-martini-pwe3-status-aggregation-protocol-03.txt as a PWE3 >> working group draft. >> Please indicate whether or not you support adoption of this draft, and se= nd >> any comments to the PWE3 list. >> This poll ends on Tuesday 9th August. >> Regards, >> Matthew and Andy. >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >>=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From mustapha.aissaoui@alcatel-lucent.com Wed Jul 27 15:04:00 2011 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 2CE0011E80B6 for ; Wed, 27 Jul 2011 15:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcuXh9LoPN0l for ; Wed, 27 Jul 2011 15:03:58 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5602B11E816C for ; Wed, 27 Jul 2011 15:03:58 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6RM3umS009290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 17:03:57 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6RM3uJh024425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Jul 2011 17:03:56 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 27 Jul 2011 17:03:56 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: Daniel Cohn , "pwe3@ietf.org" Date: Wed, 27 Jul 2011 17:03:55 -0500 Thread-Topic: [PWE3] Operational status definition in draft-ietf-pwe3-redundancy-bit Thread-Index: Acw9bVVwOzO2AWTrS0SXJI64diPnrwH1rU8AAJGU6JABQHB/sA== Message-ID: <5DF53972F7E9134782DCE51624466FE50AD1E40C0B@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <20110708124422.7813.29877.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA081306E5808B@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081306E5808B@tlvmail1> 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_5DF53972F7E9134782DCE51624466FE50AD1E40C0BUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [PWE3] Operational status definition in draft-ietf-pwe3-redundancy-bit 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, 27 Jul 2011 22:04:00 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD1E40C0BUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daniel, the definition for the PW UP state in the terminology section (Section 3) w= as meant to cover only the status bits related to defects of the PW, i.e., 0x00000001 - Pseudowire Not Forwarding 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 0x00000010 - Local PSN-facing PW (egress) Transmit Fault I will clarify this in the next version. Having said that, the selection of the active PW in Section 5.1 may need to= be updated to optionally consider remote AC state as advertized in the rec= eived status bits from the peer. I was made aware of some deployments where= the failure of a remote AC was not translated into a standby bit advertise= ment. Consider the scenario in Figure 15-1 where PE1 and PE3 did not synchr= onize the active/standby AC state. Thus both PE1 and PE3 advertized PW acti= ve status bit and PE2 choose PW1 based on precedence. When the active AC we= nt down, PE1 generated a status bit to notify PE2 of AC down but PE2 did no= t switch to PW2 because the AC state is not part of the selection criteria = in Section 5.1. Regards, Mustapha. ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dan= iel Cohn Sent: Thursday, July 21, 2011 5:47 AM To: pwe3@ietf.org Subject: [PWE3] Operational status definition in draft-ietf-pwe3-redundancy= -bit Hi authors, draft-ietf-pwe3-redundancy-bit uses the PW operational status as an input t= o the active PW selection logic. In this draft, the operational status is t= aken from the (local and remote) PW status bits. The draft defines "UP PW" (eligible to become active PW) as "PW which ... a= nd is not in any of the PW defect states specified in [2]". So the PW opera= tional status, in the context of this draft, takes into account local/remot= e AC statuses. On the other hand, the standard PW MIB (RFC 5601) explicitly defines the PW= operational status as not considering the AC statuses - "This object indic= ates the operational status of the PW; it does not reflect the status of th= e Customer Edge (CE) bound interface...". If my understanding is correct, then I believe there is a terminology confl= ict that should be resolved. Am I missing something? Please comment. Regards, Daniel --_000_5DF53972F7E9134782DCE51624466FE50AD1E40C0BUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
the definition for the PW UP state in the terminology section (Sec= tion=20 3) was meant to cover only the status bits related to defects of = the=20 PW, i.e.,
 
0x00000001 -  Pseudowire Not Forwarding
0x00000008 - = Local=20 PSN-facing PW (ingress) Receive Fault
0x00000010 -  Local PSN-facin= g PW=20 (egress) Transmit Fault
I=20 will clarify this in the next version.
 
Having said that, the selection of the active PW in Sect= ion 5.1=20 may need to be updated to optionally consider remote AC state as advertized= in=20 the received status bits from the peer. I was made aware of some deployment= s=20 where the failure of a remote AC was not translated into a standby bit=20 advertisement. Consider the scenario in Figure 15-1 where PE1 and PE3 = did=20 not synchronize the active/standby AC state. Thus both PE1 and PE3 advertiz= ed PW=20 active status bit and PE2 choose PW1 based on precedence. When the active A= C=20 went down, PE1 generated a status bit to notify PE2 of AC down but PE2 did = not=20 switch to PW2 because the AC state is not part of the selection criteria in= =20 Section 5.1.
 
Regards,
Mustapha.

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Daniel Cohn
Sent:<= /B>=20 Thursday, July 21, 2011 5:47 AM
To: pwe3@ietf.org
Subject:<= /B>=20 [PWE3] Operational status definition in=20 draft-ietf-pwe3-redundancy-bit

Hi authors,

 

draft-ietf-pwe3-redundancy-bit uses the PW operatio= nal=20 status as an input to the active PW selection logic. In this draft, the=20 operational status is taken from the (local and remote) PW status=20 bits.

The draft defines “UP PW” (eligible to = become active PW)=20 as “PW which … and is not in any of the PW defect states specif= ied in [2]”. So=20 the PW operational status, in the context of this draft, takes into account= =20 local/remote AC statuses.

 <= /o:p>

On the other hand, the standard PW MIB (RFC 5601)=20 explicitly defines the PW operational status as not considering the AC stat= uses=20 – “This object indicates the operational status of the PW; it d= oes not reflect=20 the status of the Customer Edge (CE) bound interface…”.

 

If my understanding is correct, then I believe ther= e is a=20 terminology conflict that should be resolved.

 

Am I missing something? Please comment.<= /P>

 

Regards,

 

Daniel

 

--_000_5DF53972F7E9134782DCE51624466FE50AD1E40C0BUSNAVSXCHMBSC_-- From DanielC@orckit.com Wed Jul 27 15:20:58 2011 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 AF72811E8182 for ; Wed, 27 Jul 2011 15:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgQWl8cE9gOn for ; Wed, 27 Jul 2011 15:20:56 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by ietfa.amsl.com (Postfix) with ESMTP id 88EAB11E8136 for ; Wed, 27 Jul 2011 15:20:55 -0700 (PDT) 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_01CC4CAB.D46F3DC4" Date: Thu, 28 Jul 2011 01:20:49 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306ED8146@tlvmail1> In-reply-to: <5DF53972F7E9134782DCE51624466FE50AD1E40C0B@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Operational status definition indraft-ietf-pwe3-redundancy-bit Thread-Index: Acw9bVVwOzO2AWTrS0SXJI64diPnrwH1rU8AAJGU6JABQHB/sAAHlsmQ References: <20110708124422.7813.29877.idtracker@ietfa.amsl.com> <44F4E579A764584EA9BDFD07D0CA081306E5808B@tlvmail1> <5DF53972F7E9134782DCE51624466FE50AD1E40C0B@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Daniel Cohn" To: "Aissaoui, Mustapha (Mustapha)" , Subject: Re: [PWE3] Operational status definition indraft-ietf-pwe3-redundancy-bit 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, 27 Jul 2011 22:20:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4CAB.D46F3DC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mustapha, =20 Actually I thought, and agreed, that selection must take AC status into account, as per the "UP PW" definitions in the current draft.=20 As you wrote, AC down should be a trigger for PW protection, seeing as the AC is an integral part of the PW. Figure 15-1 is an excellent example of this, and some additional, similar examples can also be presented. =20 So, may I suggest you leave the UP/DOWN PW definition as they are, and instead replace the loaded "operational state" terms by something unambiguous like for example "UP/DOWN state"? This will avoid misunderstanding and support scenarios like the one in figure 15-1. =20 Regards, =20 Daniel =20 From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-lucent.com]=20 Sent: Wednesday, July 27, 2011 6:04 PM To: Daniel Cohn; pwe3@ietf.org Subject: RE: [PWE3] Operational status definition indraft-ietf-pwe3-redundancy-bit =20 Hi Daniel, the definition for the PW UP state in the terminology section (Section 3) was meant to cover only the status bits related to defects of the PW, i.e., =20 0x00000001 - Pseudowire Not Forwarding 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 0x00000010 - Local PSN-facing PW (egress) Transmit Fault I will clarify this in the next version. =20 Having said that, the selection of the active PW in Section 5.1 may need to be updated to optionally consider remote AC state as advertized in the received status bits from the peer. I was made aware of some deployments where the failure of a remote AC was not translated into a standby bit advertisement. Consider the scenario in Figure 15-1 where PE1 and PE3 did not synchronize the active/standby AC state. Thus both PE1 and PE3 advertized PW active status bit and PE2 choose PW1 based on precedence. When the active AC went down, PE1 generated a status bit to notify PE2 of AC down but PE2 did not switch to PW2 because the AC state is not part of the selection criteria in Section 5.1. =20 Regards, Mustapha. =20 ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Daniel Cohn Sent: Thursday, July 21, 2011 5:47 AM To: pwe3@ietf.org Subject: [PWE3] Operational status definition in draft-ietf-pwe3-redundancy-bit Hi authors, =20 draft-ietf-pwe3-redundancy-bit uses the PW operational status as an input to the active PW selection logic. In this draft, the operational status is taken from the (local and remote) PW status bits. The draft defines "UP PW" (eligible to become active PW) as "PW which ... and is not in any of the PW defect states specified in [2]". So the PW operational status, in the context of this draft, takes into account local/remote AC statuses. =20 On the other hand, the standard PW MIB (RFC 5601) explicitly defines the PW operational status as not considering the AC statuses - "This object indicates the operational status of the PW; it does not reflect the status of the Customer Edge (CE) bound interface...".=20 =20 If my understanding is correct, then I believe there is a terminology conflict that should be resolved. =20 Am I missing something? Please comment. =20 Regards, =20 Daniel =20 ------_=_NextPart_001_01CC4CAB.D46F3DC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mustapha,

 

Actually I thought, and = agreed, that selection must take AC status into account, as per the = “UP PW” definitions in the current draft. =

As you wrote, AC down should be a trigger for PW = protection, seeing as the AC is an integral part of the PW. Figure 15-1 = is an excellent example of this, and some additional, similar examples = can also be presented.

 

So, may I suggest you = leave the UP/DOWN PW definition as they are, and instead replace the = loaded “operational state” terms by something unambiguous = like for example “UP/DOWN state”? This will avoid = misunderstanding and support scenarios like the one in figure = 15-1.

 

Regards,

 

Daniel

 

From:= = Aissaoui, Mustapha (Mustapha) = [mailto:mustapha.aissaoui@alcatel-lucent.com]
Sent: = Wednesday, July 27, 2011 6:04 PM
To: Daniel Cohn; = pwe3@ietf.org
Subject: RE: [PWE3] Operational status = definition = indraft-ietf-pwe3-redundancy-bit

 

Hi = Daniel,

the = definition for the PW UP state in the terminology section (Section = 3) was meant to cover only the status bits related to defects = of the PW, i.e.,

 

0x00000001 = -  Pseudowire Not Forwarding
0x00000008 -  Local PSN-facing = PW (ingress) Receive Fault
0x00000010 -  Local PSN-facing PW = (egress) Transmit Fault

I will = clarify this in the next version.

 

Having said = that, the selection of the active PW in Section 5.1 may need = to be updated to optionally consider remote AC state as advertized in = the received status bits from the peer. I was made aware of some = deployments where the failure of a remote AC was not translated into a = standby bit advertisement. Consider the scenario in Figure = 15-1 where PE1 and PE3 did not synchronize the active/standby AC = state. Thus both PE1 and PE3 advertized PW active status bit and PE2 = choose PW1 based on precedence. When the active AC went down, PE1 = generated a status bit to notify PE2 of AC down but PE2 did not switch = to PW2 because the AC state is not part of the selection criteria in = Section 5.1.

 

Regards,

Mustapha.

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Daniel Cohn
Sent: Thursday, July 21, 2011 5:47 = AM
To: pwe3@ietf.org
Subject: [PWE3] Operational = status definition in draft-ietf-pwe3-redundancy-bit

Hi = authors,

 

draft-ietf-pwe3-redundancy-bit uses the PW = operational status as an input to the active PW selection logic. In this = draft, the operational status is taken from the (local and remote) PW = status bits.

The draft defines = “UP PW” (eligible to become active PW) as “PW which = … and is not in any of the PW defect states specified in = [2]”. So the PW operational status, in the context of this draft, = takes into account local/remote AC statuses.

 =

On the other hand, the standard = PW MIB (RFC 5601) explicitly defines the PW operational status as not = considering the AC statuses – “This object indicates the = operational status of the PW; it does not reflect the status of the = Customer Edge (CE) bound interface…”.

 

If my = understanding is correct, then I believe there is a terminology conflict = that should be resolved.

 

Am I = missing something? Please comment.

 

Regards,

 

Daniel

 

------_=_NextPart_001_01CC4CAB.D46F3DC4-- From zhang.fei3@zte.com.cn Wed Jul 27 17:43:57 2011 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 C7D6111E813C; Wed, 27 Jul 2011 17:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.028 X-Spam-Level: X-Spam-Status: No, score=-97.028 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N6Q3oExEVl3; Wed, 27 Jul 2011 17:43:57 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0319411E807F; Wed, 27 Jul 2011 17:43:55 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643491178658; Thu, 28 Jul 2011 08:41:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.4446401813; Thu, 28 Jul 2011 08:43:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6S0hjDI086801; Thu, 28 Jul 2011 08:43:45 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <84B12E38-FE23-4593-83A6-70F49F9AD459@lucidvision.com> To: Thomas Nadeau MIME-Version: 1.0 X-KeepSent: 06D20823:BA4E96B6-482578DB:0001AF69; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 28 Jul 2011 08:43:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-28 08:43:46, Serialize complete at 2011-07-28 08:43:46 Content-Type: multipart/alternative; boundary="=_alternative 0003FE43482578DB_=" X-MAIL: mse02.zte.com.cn p6S0hjDI086801 Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, thomas.nadeau@ca.com Subject: Re: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 00:43:57 -0000 This is a multipart message in MIME format. --=_alternative 0003FE43482578DB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVG9tDQoNCllvdSBhcmUgdGFsa2luZyBhYm91dCBhIGdlbmVyYWwgcXVlc3Rpb24uLi4NCg0K QmVsb3cgaXMgdGhlIHVuZGVyc3RhbmRpbmcgZnJvbSBzaWRlIHdpdGggbWFyayA8RmVpPi4gSWYg aXQgaXMgd3JvbmcsIA0KcGxlYXNlIGxldCBtZSBrbm93DQoNClRoYW5rcw0KDQpGZWkNCg0KDQoN ClRob21hcyBOYWRlYXUgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPiANCjIwMTEtMDctMjcgMjA6 MzMNCg0KytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24NCrOty80NCnRob21hcy5uYWRlYXVA Y2EuY29tLCBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcsIHB3ZTNAaWV0Zi5vcmcNCtb3zOINClJlOiBb UFdFM10gUmVxdWVzdCBjb21tZW50cyBvbiBkcmFmdC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25m aWctMDUNCg0KDQoNCg0KDQoNCg0KTXkgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCAoYW5k IHRoZSBvdGhlciByZWxhdGVkICJjb25maWd1cmF0aW9uIHZpYSANCmNvbnRyb2wgcHJvdG9jb2xz IiBkb2N1bWVudHMpIGFyZSB0aGUgZm9sbG93aW5nOg0KDQoxKSBOZXR3b3JrIGNvbmZpZ3VyYXRp b24gaXMgYSBjb21wbGljYXRlZCBtYXR0ZXIuIElmIHlvdSB0YWtlIGEgcXVpY2sgbG9vayANCmF0 IE5FVENPTkYgb3IgYW55IG90aGVyIGNvbmZpZ3VyYXRpb24vcHJvdmlzaW9uaW5nIGFwcGFyYXR1 cy9wcm90b2NvbHMsIA0KeW91IHdpbGwgc2VlIHRoYXQgcHJvdmlzaW9uaW5nIGlzIG5vIHNpbXBs ZSBtYXR0ZXIgcmVxdWlyaW5nIGFsbCBzb3J0cyBvZiANCnRoaW5ncyB0byBmdW5jdGlvbiBpbmNs dWRpbmcgc2VjdXJpdHksIHN5bmNocm9uaXphdGlvbiwgdmVyc2lvbmluZyANCmNvbnRyb2wsIGV0 Yy4uLiBOb25lIGFyZSBjb3ZlcmVkIGluIHlvdXIgZHJhZnQgLSBub3Igc2hvdWxkIHRoZXkuICBU aGUgDQppc3N1ZSBpcyB0aGF0IHlvdXIgZHJhZnQgaXMgZGVzaWduaW5nIGEgbmV3IG1lYW5zIG9m IGNvbmZpZ3VyYXRpb24uDQoNCjxGZWk+IE5vdCB0b3RhbGx5IGEgbmV3IGRlc2lnbiwgdGhlIG1v dGl2YXRpb24gb2YgdGhpcyB3b3JrIGlzIHRvIA0KYWxsZXZpYXRlIHRoZSBsYWJvciBvZiBOTVMs IGFuZCBhdm9pZCBtaXNjb25uZWN0aW9uLiBTbyBpdCBpcyBub3QgdXNlZCB0byANCnJlcGxhY2Ug Tk1TLCBqdXN0IGFzIGEgY29tcGxlbWVudC4NCg0KMikgU3luY2hyb25pemF0aW9uIGJldHdlZW4g ZGlmZmVyZW50IGNvbmZpZ3VyYXRpb24gcG9pbnRzLiBDb25zaWRlciB0aGlzIA0KY2FzZTogdGhl IFNQJ3MgT1NTIGRlY2lkZXMgdG8gcHJvdmlzaW9uIGEgZGV2aWNlIGFuZCBhbHRlcnMgc29tZSBv ZiB0aGUgDQpwYXJhbWV0ZXJzIHBlcnRhaW5pbmcgdG8gTUlQL01FUCBjb25maWd1cmF0aW9uLiBU aGVuIGxhdGVyLCBzb21lb25lIGdvZXMgDQp0byB0aGUgQ0xJIG9mIHRoZSBzYW1lIGRldmljZSBh bmQgY2hhbmdlcyBzb21lIG9mIHRob3NlIHNhbWUgcGFyYW1ldGVycy4gDQpTdWRkZW5seSB5b3Ug YXJlIG91dC1vZi1zeW5jIHdpdGggdGhlIG1hc3RlciBwcm92aXNpb25pbmcgZGF0YSBiYXNlIHRo ZSANCnNlcnZpY2UgcHJvdmlkZXIga2VlcHMgd2l0aGluIHRoZSBPU1MuIFRoZW4gbGF0ZXIsIHNv bWVvbmUgZnJvbSAqYSANCmRpZmZlcmVudCogZGV2aWNlIGRlY2lkZXMgdG8gbWFrZSBhIGRpZmZl cmVudCBjaGFuZ2UgdGhhdCBzdWRkZW5seSBhcHBlYXJzIA0KYXQgdGhpcyBkZXZpY2UgdmlhIHRo ZSBjb250cm9sIHBsYW5lIHNpZ25hbGluZy4gVmlvbGEsIHRoZSBjb25maWd1cmF0aW9uIA0KaXMg ZXZlbiBmdXJ0aGVyIG91dC1vZi1zeW5jLiANCg0KPEZlaT4gSSBhbSBub3Qgc3VyZSB3aGV0aGVy IEkgdW5kZXJzdGFuZCB5b3VyIGlzc3VlLiBKdXN0IG15IHR3byBjZW50cywgDQp0aGlzIFNIT1VM RCBiZSBhIGdlbmVyYWwgc2VjdXJpdHkgcXVlc3Rpb24uIENvbnNpZGVyIHRoYXQgdGhlIHRyYW5z cG9ydCANCnBhdGggaXMgc2V0IHVwIGJ5IGNvbnRyb2wgcGxhbmUgd2l0aCBPQU0gY29uZmlndXJh dGlvbnMsIHNvbWVvbmUgY2FuIGFsc28gDQpnb2VzIHRvIHRoZSBDTEkgdG8gY2hhbmdlIHNvbWUg cGFyYW1ldGVycy4gDQoNCjMpIFlvdSBhcmUgbWFraW5nIHRoZSBpc3N1ZSBvZiBvcHRpb24gY29v cmRpbmF0aW9uIHRoYXQgTmljayBkZXNjcmliZXMgaW4gDQp0aGUgcmVjZW50IHN1cnZleSB0aGF0 IGhlIGNvbmR1Y3RlZCBwb3RlbnRpYWxseSB3b3JzZSBieSBvcGVuaW5nIHVwIGEgbmV3IA0KY2Fu IG9mIG9wdGlvbmFsIGNvbmZpZ3VyYXRpb24gdHlwZXMgYW5kIG9wdGlvbnMgdGhhdCBvcGVyYXRv cnMgd2lsbCANCmZ1cnRoZXIgaGF2ZSB0byBjb29yZGluYXRlIGFuZCByYXRpb25hbGl6ZS4gVGhp cyByZXRhcmRzIHRoZSBkZXBsb3ltZW50cyANCmF0IGJlc3QsIGFuZCBpbiB0aGUgd29yc3QgY2Fz ZXMsIG1ha2VzIHRoZW0gcGxhaW4gbm90IHdvcmsuDQoNCjxGZWk+IEkgZG8gbm90IHRoaW5rIHNv LCBOaWNrJ3Mgc3VydmV5IGlzIGFib3V0IHRoZSBDQyhjb250cm9sIGNoYW5uZWwpLCANCnRoZXJl IGFyZSB0d28gbWFueSBvcHRpb25zLiBCdXQgdGhlIGdlbmVyaWMgQWNoIGRlZmluZWQgaW4gUkZD NTU4NiBpcyANCmFsd2F5cyBiZSB1c2VkIGluIE1QTFMtVFAgd29ybGQuIEZ1cnRoZXJtb3JlLCB3 ZSBkbyBub3QgZGVmaW5lIG5ldyANCm1lY2hhbmlzbSB0byBjb29yZGluYXRlIHRoZSBjb250cm9s IGNoYW5uZWwgaW4gb3VyIGRyYWZ0LCBhbmQgdGhlIE9BTSANCm5lZ290aWF0aW9uIGlzIGRvbmUg aW4gdGhlIGluaXRpYWxpemFpdG9uIG1lc3NhZ2UuIEluIGNvbnRyYXN0LCBpdCB3aWxsIA0KcXVp Y2tlbiB0aGUgZGVwbG95bWVudCBieSBjb25maWd1cmluZyB0aGUgT0FNIGZ1bmN0aW9ucyBpbiB0 aGUgc2lnbmFsaW5nIA0KbWVzc2FnZSwgc2luY2UgdHdvIHN0ZXBzIGlzIGNvbXBhY3RlZCBpbnRv IG9uZSBzdGVwLiBJbiB0aGUgb2xkIA0KcHJvY2VkdXJlcywgdGhlIHRyYW5zcG9ydCBwYXRoIE1V U1QgYmUgc2V0IHVwIGZpcnN0bHksIHRoZW4gT0FNIGZ1bmN0aW9ucyANCmFyZSBjb25maWd1cmVk IGJ5IE5NUy4gDQoNCg0KLS1Ub20NCg0KDQoNCk9uIEp1bCAyNiwgMjAxMSwgYXQgNjo0MSBQTSwg emhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KDQoNCkhpIFRvbSANCg0KU29ycnkgSSBkbyBu b3QgY2F0Y2ggeW91ciBpbnRlcnByZXRhdGlvbiBjbGVhcmx5IGluIHRoZSBtZWV0aW5nLiANCg0K QXMgTWF0dGhldyBzYWlkLCBoZXJlIHRoZSBuZWdvdGlhdGlvbiBpcyBhYm91dCB0aGUgQ1YgZnVu Y3Rpb25zLCANCmVzcGVjaWFsbHkgZm9yIHRoZSBuZXdseSBkZXZlbG9wZWQgTVBMUy1UUCBPQU0g ZnVuY3Rpb25zLCBhbmQgaXQgaXMgZG9uZSANCmJlZm9yZSB0aGUgc2V0dGluZyB1cCBvZiBQV3Mu IA0KDQpXaGVuIHRoZSBuZWdvdGlhdGlvbiBmaW5pc2hlZCwgdGhpcyB3aWxsIG5vdCBjaGFuZ2Vk IGR1cmluZyBQVyBsaWZldGltZXMgDQpzaW5jZSB0aGUgZXF1aXBtZW50IHdpbGwgbm90IGNoYW5n ZSB0aGUgT0FNIGZ1bmN0aW9uIGl0IHN1cHBvcnRlZCANCmZyZXF1ZW50bHkuIA0KDQpEbyBJIGFu c3dlciB5b3VyIHF1ZXN0aW9uIG9yIHRoZXJlIGFyZSBzdGlsbCBzb21lIG1pc3VuZGVyc3RhbmRp bmc/IA0KDQpCZXN0IHJlZ2FyZHMgDQoNCkZlaSANCg0KDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24g DQq3orz+yMs6ICBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDctMjcgMDY6MzAgDQoNCg0K ytW8/sjLDQpwd2UzQGlldGYub3JnIA0Ks63LzQ0KDQrW98ziDQpbUFdFM10gUmVxdWVzdCBjb21t ZW50cyBvbiBkcmFmdC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25maWctMDUNCg0KDQoNCg0KDQoN Cg0KDQoNCkhpIFBXRWVycyANCg0KVGhpcyBkb2N1bWVudCBpcyBhYm91dCB0aGUgTVBMUy1UUCBQ VyBwcm9hY3RpdmUgT0FNIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gDQphbmQgY29uZmlndXJhdGlv biwgZmlyc3RseSB0aGUgdHdvIFQtUEVzIG5lZ290aWF0ZSB3aGF0IE1QTFMtVFAgT0FNIA0KZnVu Y3Rpb24gdGhleSBzdXBwb3J0LCB0aGVuIGNvbmZpZ3VyZSB0aGUgY29ycmVzcG9uZGluZyBPQU0g cGFyYW1ldGVycy4gDQoNCldlIHdpbGwgYmUgaGlnaGx5IGFwcHJlY2lhdGVkIGlmIHlvdSBjYW4g cmV2aWV3IGFuZCBnaXZlIGFueSBjb21tZW50cy4gDQoNCkJlbG93IGlzIHRoZSBsaW5rIA0KDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25m aWctMDUgDQoNCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMgDQoNClRoZSBhdXRob3JzX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBs aXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3B3ZTMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3B3ZTMNCg0KDQo= --=_alternative 0003FE43482578DB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIFRvbTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+WW91IGFyZSB0YWxraW5nIGFib3V0 IGEgZ2VuZXJhbCBxdWVzdGlvbi4uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+QmVsb3cgaXMgdGhlIHVuZGVyc3RhbmRpbmcgZnJvbSBzaWRlDQp3aXRo IG1hcmsgJmx0O0ZlaSZndDsuIElmIGl0IGlzIHdyb25nLCBwbGVhc2UgbGV0IG1lIGtub3c8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlRob21hcyBOYWRl YXUgJmx0O3RuYWRlYXVAbHVjaWR2aXNpb24uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTA3LTI3IDIwOjMzPC9mb250Pg0KPHRkIHdp ZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYW5nLmZlaTNAenRl LmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+dGhvbWFzLm5hZGVhdUBjYS5jb20sIHB3ZTMtYm91 bmNlc0BpZXRmLm9yZywNCnB3ZTNAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUFdF M10gUmVxdWVzdCBjb21tZW50cyBvbiBkcmFmdC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25maWct MDU8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+TXkgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCAo YW5kDQp0aGUgb3RoZXIgcmVsYXRlZCAmcXVvdDtjb25maWd1cmF0aW9uIHZpYSBjb250cm9sIHBy b3RvY29scyZxdW90OyBkb2N1bWVudHMpDQphcmUgdGhlIGZvbGxvd2luZzo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjEpIE5ldHdvcmsgY29uZmlndXJh dGlvbiBpcyBhIGNvbXBsaWNhdGVkDQptYXR0ZXIuIElmIHlvdSB0YWtlIGEgcXVpY2sgbG9vayBh dCBORVRDT05GIG9yIGFueSBvdGhlciBjb25maWd1cmF0aW9uL3Byb3Zpc2lvbmluZw0KYXBwYXJh dHVzL3Byb3RvY29scywgeW91IHdpbGwgc2VlIHRoYXQgcHJvdmlzaW9uaW5nIGlzIG5vIHNpbXBs ZSBtYXR0ZXINCnJlcXVpcmluZyBhbGwgc29ydHMgb2YgdGhpbmdzIHRvIGZ1bmN0aW9uIGluY2x1 ZGluZyBzZWN1cml0eSwgc3luY2hyb25pemF0aW9uLA0KdmVyc2lvbmluZyBjb250cm9sLCBldGMu Li4gTm9uZSBhcmUgY292ZXJlZCBpbiB5b3VyIGRyYWZ0IC0gbm9yIHNob3VsZA0KdGhleS4gJm5i c3A7VGhlIGlzc3VlIGlzIHRoYXQgeW91ciBkcmFmdCBpcyBkZXNpZ25pbmcgYSBuZXcgbWVhbnMg b2YgY29uZmlndXJhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZsdDtGZWkmZ3Q7IE5vdCB0b3RhbGx5IGEgbmV3IGRlc2lnbiwNCnRoZSBtb3Rp dmF0aW9uIG9mIHRoaXMgd29yayBpcyB0byBhbGxldmlhdGUgdGhlIGxhYm9yIG9mIE5NUywgYW5k IGF2b2lkDQptaXNjb25uZWN0aW9uLiBTbyBpdCBpcyBub3QgdXNlZCB0byByZXBsYWNlIE5NUywg anVzdCBhcyBhIGNvbXBsZW1lbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4yKSBTeW5jaHJvbml6YXRpb24gYmV0d2VlbiBkaWZmZXJlbnQNCmNvbmZp Z3VyYXRpb24gcG9pbnRzLiBDb25zaWRlciB0aGlzIGNhc2U6IHRoZSBTUCdzIE9TUyBkZWNpZGVz IHRvIHByb3Zpc2lvbg0KYSBkZXZpY2UgYW5kIGFsdGVycyBzb21lIG9mIHRoZSBwYXJhbWV0ZXJz IHBlcnRhaW5pbmcgdG8gTUlQL01FUCBjb25maWd1cmF0aW9uLg0KVGhlbiBsYXRlciwgc29tZW9u ZSBnb2VzIHRvIHRoZSBDTEkgb2YgdGhlIHNhbWUgZGV2aWNlIGFuZCBjaGFuZ2VzIHNvbWUNCm9m IHRob3NlIHNhbWUgcGFyYW1ldGVycy4gU3VkZGVubHkgeW91IGFyZSBvdXQtb2Ytc3luYyB3aXRo IHRoZSBtYXN0ZXINCnByb3Zpc2lvbmluZyBkYXRhIGJhc2UgdGhlIHNlcnZpY2UgcHJvdmlkZXIg a2VlcHMgd2l0aGluIHRoZSBPU1MuIFRoZW4NCmxhdGVyLCBzb21lb25lIGZyb20gKmEgZGlmZmVy ZW50KiBkZXZpY2UgZGVjaWRlcyB0byBtYWtlIGEgZGlmZmVyZW50IGNoYW5nZQ0KdGhhdCBzdWRk ZW5seSBhcHBlYXJzIGF0IHRoaXMgZGV2aWNlIHZpYSB0aGUgY29udHJvbCBwbGFuZSBzaWduYWxp bmcuIFZpb2xhLA0KdGhlIGNvbmZpZ3VyYXRpb24gaXMgZXZlbiBmdXJ0aGVyIG91dC1vZi1zeW5j LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtG ZWkmZ3Q7IEkgYW0gbm90IHN1cmUgd2hldGhlciBJDQp1bmRlcnN0YW5kIHlvdXIgaXNzdWUuIEp1 c3QgbXkgdHdvIGNlbnRzLCB0aGlzIFNIT1VMRCBiZSBhIGdlbmVyYWwgc2VjdXJpdHkNCnF1ZXN0 aW9uLiBDb25zaWRlciB0aGF0IHRoZSB0cmFuc3BvcnQgcGF0aCBpcyBzZXQgdXAgYnkgY29udHJv bCBwbGFuZSB3aXRoDQpPQU0gY29uZmlndXJhdGlvbnMsIHNvbWVvbmUgY2FuIGFsc28gZ29lcyB0 byB0aGUgQ0xJIHRvIGNoYW5nZSBzb21lIHBhcmFtZXRlcnMuDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjMpIFlvdSBhcmUgbWFraW5nIHRoZSBpc3N1 ZSBvZiBvcHRpb24NCmNvb3JkaW5hdGlvbiB0aGF0IE5pY2sgZGVzY3JpYmVzIGluIHRoZSByZWNl bnQgc3VydmV5IHRoYXQgaGUgY29uZHVjdGVkDQpwb3RlbnRpYWxseSB3b3JzZSBieSBvcGVuaW5n IHVwIGEgbmV3IGNhbiBvZiBvcHRpb25hbCBjb25maWd1cmF0aW9uIHR5cGVzDQphbmQgb3B0aW9u cyB0aGF0IG9wZXJhdG9ycyB3aWxsIGZ1cnRoZXIgaGF2ZSB0byBjb29yZGluYXRlIGFuZCByYXRp b25hbGl6ZS4NClRoaXMgcmV0YXJkcyB0aGUgZGVwbG95bWVudHMgYXQgYmVzdCwgYW5kIGluIHRo ZSB3b3JzdCBjYXNlcywgbWFrZXMgdGhlbQ0KcGxhaW4gbm90IHdvcmsuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7RmVpJmd0OyBJIGRvIG5vdCB0 aGluayBzbywgTmljaydzDQpzdXJ2ZXkgaXMgYWJvdXQgdGhlIENDKGNvbnRyb2wgY2hhbm5lbCks IHRoZXJlIGFyZSB0d28gbWFueSBvcHRpb25zLiBCdXQNCnRoZSBnZW5lcmljIEFjaCBkZWZpbmVk IGluIFJGQzU1ODYgaXMgYWx3YXlzIGJlIHVzZWQgaW4gTVBMUy1UUCB3b3JsZC4NCkZ1cnRoZXJt b3JlLCB3ZSBkbyBub3QgZGVmaW5lIG5ldyBtZWNoYW5pc20gdG8gY29vcmRpbmF0ZSB0aGUgY29u dHJvbCBjaGFubmVsDQppbiBvdXIgZHJhZnQsIGFuZCB0aGUgT0FNIG5lZ290aWF0aW9uIGlzIGRv bmUgaW4gdGhlIGluaXRpYWxpemFpdG9uIG1lc3NhZ2UuDQpJbiBjb250cmFzdCwgaXQgd2lsbCBx dWlja2VuIHRoZSBkZXBsb3ltZW50IGJ5IGNvbmZpZ3VyaW5nIHRoZSBPQU0gZnVuY3Rpb25zDQpp biB0aGUgc2lnbmFsaW5nIG1lc3NhZ2UsIHNpbmNlIHR3byBzdGVwcyBpcyBjb21wYWN0ZWQgaW50 byBvbmUgc3RlcC4gSW4NCnRoZSBvbGQgcHJvY2VkdXJlcywgdGhlIHRyYW5zcG9ydCBwYXRoIE1V U1QgYmUgc2V0IHVwIGZpcnN0bHksIHRoZW4gT0FNDQpmdW5jdGlvbnMgYXJlIGNvbmZpZ3VyZWQg YnkgTk1TLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPi0tVG9tPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj5PbiBKdWwgMjYsIDIwMTEsIGF0IDY6NDEgUE0sIDwvZm9udD48YSBo cmVmPW1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0Kd3JvdGU6PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBUb208L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NClNvcnJ5IEkgZG8gbm90IGNhdGNoIHlvdXIgaW50ZXJwcmV0YXRp b24gY2xlYXJseSBpbiB0aGUgbWVldGluZy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQpBcyBNYXR0aGV3IHNhaWQsIGhlcmUgdGhlIG5lZ290aWF0aW9uIGlzIGFib3V0IHRoZSBDViBm dW5jdGlvbnMsIGVzcGVjaWFsbHkNCmZvciB0aGUgbmV3bHkgZGV2ZWxvcGVkIE1QTFMtVFAgT0FN IGZ1bmN0aW9ucywgYW5kIGl0IGlzIGRvbmUgYmVmb3JlIHRoZQ0Kc2V0dGluZyB1cCBvZiBQV3Mu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpXaGVuIHRoZSBuZWdvdGlhdGlvbiBmaW5p c2hlZCwgdGhpcyB3aWxsIG5vdCBjaGFuZ2VkIGR1cmluZyBQVyBsaWZldGltZXMNCnNpbmNlIHRo ZSBlcXVpcG1lbnQgd2lsbCBub3QgY2hhbmdlIHRoZSBPQU0gZnVuY3Rpb24gaXQgc3VwcG9ydGVk IGZyZXF1ZW50bHkuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRG8gSSBhbnN3ZXIg eW91ciBxdWVzdGlvbiBvciB0aGVyZSBhcmUgc3RpbGwgc29tZSBtaXN1bmRlcnN0YW5kaW5nPzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkJlc3QgcmVnYXJkczwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KRmVpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD0zMCU+PGEgaHJlZj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjxm b250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PnpoYW5nLmZlaTNA enRlLmNvbS5jbjwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8YnI+DQq3orz+yMs6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86cHdlMy1ib3Vu Y2VzQGlldGYub3JnIj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5wd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDExLTA3LTI3IDA2OjMwPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02OSU+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTglPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk IHdpZHRoPTkxJT48YSBocmVmPW1haWx0bzpwd2UzQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnB3ZTNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOt y808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltQV0UzXSBSZXF1ZXN0IGNvbW1lbnRz IG9uIGRyYWZ0LXpoYW5nLW1wbHMtdHAtcHctb2FtLWNvbmZpZy0wNTwvZm9udD48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpIaSBQV0VlcnM8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjxicj4NClRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgdGhlIE1QTFMtVFAgUFcgcHJvYWN0 aXZlIE9BTSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uDQphbmQgY29uZmlndXJhdGlvbiwgZmlyc3Rs eSB0aGUgdHdvIFQtUEVzIG5lZ290aWF0ZSB3aGF0IE1QTFMtVFAgT0FNIGZ1bmN0aW9uDQp0aGV5 IHN1cHBvcnQsIHRoZW4gY29uZmlndXJlIHRoZSBjb3JyZXNwb25kaW5nIE9BTSBwYXJhbWV0ZXJz LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCldlIHdpbGwgYmUgaGlnaGx5IGFwcHJl Y2lhdGVkIGlmIHlvdSBjYW4gcmV2aWV3IGFuZCBnaXZlIGFueSBjb21tZW50cy48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQo8YnI+DQpCZWxvdyBpcyB0aGUgbGluazwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtemhhbmctbXBscy10cC1wdy1vYW0tY29uZmlnLTA1Ij48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1tcGxzLXRwLXB3LW9hbS1jb25maWctMDU8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCjxicj4NClRoYW5rcyBhbmQgYmVzdCByZWdhcmRzPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8YnI+DQpUaGUgYXV0aG9yczwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcHdlMyBt YWlsaW5nIGxpc3Q8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHU+PGJy Pg0KPC91PjwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+PHR0Pjxmb250 IHNpemU9MiBjb2xvcj1ibHVlPjx1PnB3ZTNAaWV0Zi5vcmc8L3U+PC9mb250PjwvdHQ+PC9hPjx0 dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjwvdHQ+PGEgaHJl Zj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM+PHR0Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHdlMzwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KcHdlMyBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzpwd2UzQGll dGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnB3ZTNA aWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPC9mb250Pg0KPGJy Pg0KPGJyPg0K --=_alternative 0003FE43482578DB_=-- From pranjal.dutta@alcatel-lucent.com Wed Jul 27 19:11:46 2011 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 2EA2721F8BDB; Wed, 27 Jul 2011 19:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5q7N30rj3El; Wed, 27 Jul 2011 19:11:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 824D521F8BD9; Wed, 27 Jul 2011 19:11:45 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6S2Bfn4026660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 21:11:43 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6S2BeQw000548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jul 2011 07:41:40 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 28 Jul 2011 07:41:40 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Ilya Varlashkin , IETF MPLS , "pwe3@ietf.org" Date: Thu, 28 Jul 2011 07:41:37 +0530 Thread-Topic: [mpls] terminology in draft-pkwok-pwe3-pw-communities Thread-Index: AcxL1w02weKgkv+9SLWeA9YGvo4X4gA884eQ Message-ID: References: <73460629-CAAC-4C2E-9ECA-7FEC8570480A@nobulus.com> In-Reply-To: <73460629-CAAC-4C2E-9ECA-7FEC8570480A@nobulus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Kwok, Paul \(Paul\)" Subject: Re: [PWE3] [mpls] terminology in draft-pkwok-pwe3-pw-communities 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, 28 Jul 2011 02:11:46 -0000 Hi, The intent was to keep the context similar to BGP communities and henc= e the terminology as "PW Communities". I am not able to think of any case tha= t would made us to ship PW communities thru BGP, even if we would ever do i= t there would be a mapping function from LDP Community->BGP X attribute, s= imilar to what we do for FEC129 AII->BGP NLRI.=20 Thanks, Pranjal=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ily= a Varlashkin Sent: Tuesday, July 26, 2011 2:00 PM To: IETF MPLS Subject: [mpls] terminology in draft-pkwok-pwe3-pw-communities Hi, sooner or later most of control-plane information makes its way into BGP. S= ome day somebody will want to carry PW communities in BGP. That's going to = be confusing as BGP already has community attribute. Presentation at the PW= E3 meeting mentioned "coloring". Couldn't then "PW color" be adopted instea= d of "PW community"? /iLya _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Thu Jul 28 10:26:42 2011 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 808A521F8C1A; Thu, 28 Jul 2011 10:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOO2lg3lKnIP; Thu, 28 Jul 2011 10:26:41 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 27EE021F8C0B; Thu, 28 Jul 2011 10:26:41 -0700 (PDT) Received: from dhcp-5719.meeting.ietf.org (dhcp-5719.meeting.ietf.org [130.129.87.25]) by lucidvision.com (Postfix) with ESMTP id 1C27F1D31239; Thu, 28 Jul 2011 13:26:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6242B12-D6C2-4913-BDF9-BC237B3EF430" From: Thomas Nadeau In-Reply-To: Date: Thu, 28 Jul 2011 13:26:46 -0400 Message-Id: <5F7021D6-BDB7-427E-A55A-5CF0D6461F0F@lucidvision.com> References: To: zhang.fei3@zte.com.cn X-Mailer: Apple Mail (2.1244.3) Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, thomas.nadeau@ca.com Subject: Re: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 17:26:42 -0000 --Apple-Mail=_F6242B12-D6C2-4913-BDF9-BC237B3EF430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Jul 27, 2011, at 8:43 PM, zhang.fei3@zte.com.cn wrote: >=20 > Hi Tom=20 >=20 > You are talking about a general question...=20 >=20 > Below is the understanding from side with mark . If it is wrong, = please let me know=20 >=20 > Thanks=20 >=20 > Fei=20 >=20 >=20 > Thomas Nadeau > 2011-07-27 20:33 >=20 > =CA=D5=BC=FE=C8=CB > zhang.fei3@zte.com.cn > =B3=AD=CB=CD > thomas.nadeau@ca.com, pwe3-bounces@ietf.org, pwe3@ietf.org > =D6=F7=CC=E2 > Re: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 >=20 >=20 >=20 >=20 >=20 >=20 > My concerns about this document (and the other related "configuration = via control protocols" documents) are the following:=20 >=20 > 1) Network configuration is a complicated matter. If you take a quick = look at NETCONF or any other configuration/provisioning = apparatus/protocols, you will see that provisioning is no simple matter = requiring all sorts of things to function including security, = synchronization, versioning control, etc... None are covered in your = draft - nor should they. The issue is that your draft is designing a = new means of configuration.=20 >=20 > Not totally a new design, the motivation of this work is to = alleviate the labor of NMS, and avoid misconnection. So it is not used = to replace NMS, just as a complement.=20 TOM: The issue is that you are alleviating the labor of the NMS only in = a small portion of potential configuration. That is why this raises the = potential for mis-cordination. > 2) Synchronization between different configuration points. Consider = this case: the SP's OSS decides to provision a device and alters some of = the parameters pertaining to MIP/MEP configuration. Then later, someone = goes to the CLI of the same device and changes some of those same = parameters. Suddenly you are out-of-sync with the master provisioning = data base the service provider keeps within the OSS. Then later, someone = from *a different* device decides to make a different change that = suddenly appears at this device via the control plane signaling. Viola, = the configuration is even further out-of-sync.=20 >=20 > I am not sure whether I understand your issue. Just my two = cents, this SHOULD be a general security question. Consider that the = transport path is set up by control plane with OAM configurations, = someone can also goes to the CLI to change some parameters.=20 TOM: This is not a security issue. Both accessors in the example I gave = have permission to change the configuration (authenticated). The issue = is again, that you can overwrite the other one's configuration without = their knowing. > 3) You are making the issue of option coordination that Nick describes = in the recent survey that he conducted potentially worse by opening up a = new can of optional configuration types and options that operators will = further have to coordinate and rationalize. This retards the deployments = at best, and in the worst cases, makes them plain not work.=20 >=20 > I do not think so, Nick's survey is about the CC(control = channel), there are two many options. But the generic Ach defined in = RFC5586 is always be used in MPLS-TP world. Furthermore, we do not = define new mechanism to coordinate the control channel in our draft, and = the OAM negotiation is done in the initializaiton message. In contrast, = it will quicken the deployment by configuring the OAM functions in the = signaling message, since two steps is compacted into one step. In the = old procedures, the transport path MUST be set up firstly, then OAM = functions are configured by NMS.=20 TOM: This again, has nothing to do with the CC or VCCV. The point I am = making is that the survey revealed that operators are experiencing a lot = of pain having multiple options in terms of PW OAM. This draft makes = the situation worse rather than better (simpler). --Tom >=20 >=20 > --Tom=20 >=20 >=20 >=20 > On Jul 26, 2011, at 6:41 PM, zhang.fei3@zte.com.cn wrote:=20 >=20 >=20 > Hi Tom=20 >=20 > Sorry I do not catch your interpretation clearly in the meeting.=20 >=20 > As Matthew said, here the negotiation is about the CV functions, = especially for the newly developed MPLS-TP OAM functions, and it is done = before the setting up of PWs.=20 >=20 > When the negotiation finished, this will not changed during PW = lifetimes since the equipment will not change the OAM function it = supported frequently.=20 >=20 > Do I answer your question or there are still some misunderstanding?=20 >=20 > Best regards=20 >=20 > Fei=20 >=20 > zhang.fei3@zte.com.cn=20 > =B7=A2=BC=FE=C8=CB: pwe3-bounces@ietf.org > 2011-07-27 06:30 >=20 >=20 > =CA=D5=BC=FE=C8=CB > pwe3@ietf.org > =B3=AD=CB=CD > =D6=F7=CC=E2 > [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi PWEers=20 >=20 > This document is about the MPLS-TP PW proactive OAM capability = negotiation and configuration, firstly the two T-PEs negotiate what = MPLS-TP OAM function they support, then configure the corresponding OAM = parameters.=20 >=20 > We will be highly appreciated if you can review and give any comments.=20= >=20 > Below is the link=20 >=20 > http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05=20 >=20 >=20 > Thanks and best regards=20 >=20 > The authors_______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3=20 >=20 --Apple-Mail=_F6242B12-D6C2-4913-BDF9-BC237B3EF430 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 zhang.fei3@zte.com.cn = wrote:

Hi Tom

You are talking about a general = question...

Below is the understanding from = side with mark <Fei>. If it is wrong, please let me know

Thanks

Fei


Thomas Nadeau = <tnadeau@lucidvision.com>

2011-07-27 20:33

=CA=D5=BC=FE=C8=CB
zhang.fei3@zte.com.cn
=B3=AD=CB=CD
thomas.nadeau@ca.com, pwe3-bounces@ietf.org, pwe3@ietf.org
=D6=F7=CC=E2
Re: [PWE3] Request = comments on = draft-zhang-mpls-tp-pw-oam-config-05






My concerns about this document = (and the other related "configuration via control protocols" documents) are the following:

1) Network configuration is a = complicated matter. If you take a quick look at NETCONF or any other = configuration/provisioning apparatus/protocols, you will see that provisioning is no simple matter requiring all sorts of things to function including security, = synchronization, versioning control, etc... None are covered in your draft - nor should they.  The issue is that your draft is designing a new means of = configuration.

<Fei> Not totally a new = design, the motivation of this work is to alleviate the labor of NMS, and avoid misconnection. So it is not used to replace NMS, just as a = complement.

TOM: The issue is that you are = alleviating the labor of the NMS only in a small portion of potential = configuration. That is why this raises the potential for = mis-cordination.

2) Synchronization between different configuration points. Consider this case: the SP's OSS decides to = provision a device and alters some of the parameters pertaining to MIP/MEP = configuration. Then later, someone goes to the CLI of the same device and changes some of those same parameters. Suddenly you are out-of-sync with the master provisioning data base the service provider keeps within the OSS. Then later, someone from *a different* device decides to make a different = change that suddenly appears at this device via the control plane signaling. = Viola, the configuration is even further out-of-sync.

<Fei> I am not sure = whether I understand your issue. Just my two cents, this SHOULD be a general = security question. Consider that the transport path is set up by control plane = with OAM configurations, someone can also goes to the CLI to change some = parameters.

TOM: This is not a security issue. = Both accessors in the example I gave have permission to change the = configuration (authenticated). The issue is again, that you can = overwrite the other one's configuration without their = knowing.

3) You are making the issue of option coordination that Nick describes in the recent survey that he conducted potentially worse by opening up a new can of optional configuration = types and options that operators will further have to coordinate and = rationalize. This retards the deployments at best, and in the worst cases, makes them plain not work.

<Fei> I do not think so, = Nick's survey is about the CC(control channel), there are two many options. But the generic Ach defined in RFC5586 is always be used in MPLS-TP world. Furthermore, we do not define new mechanism to coordinate the control = channel in our draft, and the OAM negotiation is done in the initializaiton = message. In contrast, it will quicken the deployment by configuring the OAM = functions in the signaling message, since two steps is compacted into one step. In the old procedures, the transport path MUST be set up firstly, then OAM functions are configured by NMS.

TOM: This again, has nothing to do with = the CC or VCCV. The point I am making is that the survey revealed that = operators are experiencing a lot of pain having multiple options in = terms of PW OAM.  This draft makes the situation worse rather than = better (simpler).

= --Tom






--Tom



On Jul 26, 2011, at 6:41 PM, = zhang.fei3@zte.com.cn wrote:


Hi Tom

Sorry I do not catch your interpretation clearly in the = meeting.

As Matthew said, here the negotiation is about the CV functions, = especially for the newly developed MPLS-TP OAM functions, and it is done before the setting up of PWs.

When the negotiation finished, this will not changed during PW lifetimes since the equipment will not change the OAM function it supported = frequently.

Do I answer your question or there are still some = misunderstanding?

Best regards

Fei

zhang.fei3@zte.com.cn
=B7=A2=BC=FE=C8=CB:  pwe3-bounces@ietf.org

2011-07-27 06:30


=CA=D5=BC=FE=C8=CB
pwe3@ietf.org
=B3=AD=CB=CD
=D6=F7=CC=E2
[PWE3] Request comments on = draft-zhang-mpls-tp-pw-oam-config-05








Hi PWEers

This document is about the MPLS-TP PW proactive OAM capability = negotiation and configuration, firstly the two T-PEs negotiate what MPLS-TP OAM = function they support, then configure the corresponding OAM = parameters.

We will be highly appreciated if you can review and give any = comments.

Below is the link =

<= font size=3D"2" color=3D"blue" = face=3D"sans-serif">http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-o= am-config-05


Thanks and best regards =

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

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


= --Apple-Mail=_F6242B12-D6C2-4913-BDF9-BC237B3EF430-- From matthew.bocci@alcatel-lucent.com Thu Jul 28 11:02:21 2011 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 B5C4821F8B6B for ; Thu, 28 Jul 2011 11:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.915 X-Spam-Level: X-Spam-Status: No, score=-105.915 tagged_above=-999 required=5 tests=[AWL=0.333, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB+bGPD3eymt for ; Thu, 28 Jul 2011 11:02:20 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE9921F8B46 for ; Thu, 28 Jul 2011 11:02:20 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6SI2HCA002736 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Jul 2011 20:02:17 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 28 Jul 2011 20:02:17 +0200 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Thu, 28 Jul 2011 20:02:16 +0200 Thread-Topic: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxNUHyDZAbasUF1Qk6dQX1EkI++NA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA5762B8150A0matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-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, 28 Jul 2011 18:02:21 -0000 --_000_CA5762B8150A0matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a two week poll to help assess if there is consensus to a= dopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also= send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy --_000_CA5762B8150A0matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This email begins a two = week poll to help assess if there is consensus to adopt draft-nadeau-p= we3-vccv-2-02.txt as a PWE3 working group draft.

P= lease indicate whether or not you support adoption of this draft, and also = send any comments to the PWE3 list.

This poll will= end on Friday 12th August.

Regards,
Matthew & Andy
--_000_CA5762B8150A0matthewboccialcatellucentcom_-- From hejia@huawei.com Thu Jul 28 12:30:34 2011 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 6A7B121F85EC for ; Thu, 28 Jul 2011 12:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=2.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upO-ddtltfUn for ; Thu, 28 Jul 2011 12:30:34 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CC92521F85C0 for ; Thu, 28 Jul 2011 12:30:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP200LTV66U29@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 29 Jul 2011 03:30:31 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP20071B66U4S@szxga03-in.huawei.com> for pwe3@ietf.org; Fri, 29 Jul 2011 03:30:30 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACR42848; Fri, 29 Jul 2011 03:30:30 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 29 Jul 2011 03:30:22 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.153]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 03:30:30 +0800 Date: Thu, 28 Jul 2011 19:30:29 +0000 From: Hejia In-reply-to: X-Originating-IP: [172.24.2.41] To: "pwe3@ietf.org" Message-id: <735916399E11684EAF4EB4FB376B71950143E6C8@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_p6vC/PYSDAsfabGwPmACbQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-index: AcxNUHyDZAbasUF1Qk6dQX1EkI++NAADCTKO X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-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, 28 Jul 2011 19:30:34 -0000 --Boundary_(ID_p6vC/PYSDAsfabGwPmACbQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Yes/Support. B.R. Jia ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Bocci, Matthew (Matthew) [matthew.bocci@alcatel-lucent.com] Sent: Friday, July 29, 2011 2:02 AM To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy --Boundary_(ID_p6vC/PYSDAsfabGwPmACbQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Yes/Support.

 

 

B.R.

Jia

 

From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Bocci, Matthew (Matthew) [matthew.bocci@alcatel-lucent.com]
Sent: Friday, July 29, 2011 2:02 AM
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list.

This poll will end on Friday 12th August.

Regards,

Matthew & Andy
--Boundary_(ID_p6vC/PYSDAsfabGwPmACbQ)-- From yaakov_s@rad.com Thu Jul 28 17:58:58 2011 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 19D4D11E8120 for ; Thu, 28 Jul 2011 17:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0bpN2jyXAUK for ; Thu, 28 Jul 2011 17:58:56 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAEA11E810E for ; Thu, 28 Jul 2011 17:58:53 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 29 Jul 2011 03:58:52 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 29 Jul 2011 03:58:39 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0289.001; Fri, 29 Jul 2011 03:58:39 +0300 From: Yaakov Stein To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Thread-Topic: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxNUHyDZAbasUF1Qk6dQX1EkI++NAAOE9Qw Date: Fri, 29 Jul 2011 00:58:38 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903E8FD81EXRAD5adradcoil_" MIME-Version: 1.0 Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-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, 29 Jul 2011 00:58:58 -0000 --_000_07F7D7DED63154409F13298786A2ADC903E8FD81EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not support ! and I can not understand how anyone can support it ! We do NOT need a fourth VCCV type, there are too many already. I completely agree with the part that says if there is a CW then the ACh sh= ould be marked by it. I do NOT agree that if the CW is not used then we should use a non-PW metho= d developed for MPLS-TP. I do NOT agree that there is any way to deprecate the use of TTL expiry to = mark the ACh. I do NOT agree that we should change mechanisms that have been widely deplo= yed for many years now, without an extremely pressing reason. Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the= ADDITIONAL option for ACh marking, I might be convinced not to object as strongly. However, since I don't think that PWs can be limited in this matter (the MP= LS WG adopted the "seamless" draft) it would be difficult to convince me that such a limitation is possible. I would have enthusiastically support this proposal had it been brought 8 y= ears ago. It's too late for this now. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Thursday, July 28, 2011 21:02 To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to a= dopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also= send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy --_000_07F7D7DED63154409F13298786A2ADC903E8FD81EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not support !    and I can not understan= d how anyone can support it !

 

We do NOT need a fourth VCCV type, there are too many alread= y.

 

I completely agree with the part that says if there is a CW = then the ACh should be marked by it.

 

I do NOT agree that if the CW is not used then we should use= a non-PW method developed for MPLS-TP.

I do NOT agree that there is any way to deprecate the use of= TTL expiry to mark the ACh.

I do NOT agree that we should change mechanisms that have be= en widely deployed for many years now,

without an extremely pressing reason.

 

Were the proposal to be that for PWs that traverse ONLY MPLS= -TP to have the ADDITIONAL option

for ACh marking, I might be convinced not to object as stron= gly.

However, since I don't think that PWs can be limited in this= matter (the MPLS WG adopted the "seamless" draft)

it would be difficult to convince me that such a limitation = is possible.

 

I would have enthusiastically support this proposal had it b= een brought 8 years ago.

It's too late for this now.

 

Y(J)S

 

From: pwe3-bou= nces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.= txt

 

This email begins a two week poll to help assess if there is c= onsensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working gr= oup draft.

 

Please indicate whether or not you support adoption of this dr= aft, and also send any comments to the PWE3 list.

 

This poll will end on Friday 12th August.

 

Regards,

 

Matthew & Andy

--_000_07F7D7DED63154409F13298786A2ADC903E8FD81EXRAD5adradcoil_-- From erminio.ottone_69@libero.it Fri Jul 29 11:24:22 2011 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 069BB21F8B72 for ; Fri, 29 Jul 2011 11:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.882 X-Spam-Level: * X-Spam-Status: No, score=1.882 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJK8Kr9+U5ep for ; Fri, 29 Jul 2011 11:24:21 -0700 (PDT) Received: from outrelay01.libero.it (outrelay01.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 4275121F8B0E for ; Fri, 29 Jul 2011 11:24:21 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0206.4E32FAD1.0047,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail49 (172.31.0.239) by outrelay01.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4E20483C01558C2F; Fri, 29 Jul 2011 20:24:17 +0200 Message-ID: <14175173.924231311963857105.JavaMail.defaultUser@defaultHost> Date: Fri, 29 Jul 2011 20:24:17 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "pwe3@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_68090_29376693.1311963857105" X-SenderIP: 79.41.164.240 Subject: [PWE3] R: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:24:22 -0000 ------=_Part_68090_29376693.1311963857105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit yes/support ----Messaggio originale---- Da: matthew.bocci@alcatel-lucent.com Data: 28-lug-2011 20.02 A: "pwe3@ietf.org" Ogg: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy ------=_Part_68090_29376693.1311963857105 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: 7bit

yes/support

----Messaggio originale----
Da: matthew.bocci@alcatel-lucent.com
Data: 28-lug-2011 20.02
A: "pwe3@ietf.org"<pwe3@ietf.org>
Ogg: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list.

This poll will end on Friday 12th August.

Regards,

Matthew & Andy


------=_Part_68090_29376693.1311963857105-- From huubatwork@gmail.com Fri Jul 29 11:34:56 2011 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 5804821F8B99 for ; Fri, 29 Jul 2011 11:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-FjgjXhi-Yi for ; Fri, 29 Jul 2011 11:34:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D221F8B95 for ; Fri, 29 Jul 2011 11:34:54 -0700 (PDT) Received: by qwc23 with SMTP id 23so2598182qwc.31 for ; Fri, 29 Jul 2011 11:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ldnMHW36H8iK/Y+2EipXIEMB/QcgfATD4wp5ExVAVrQ=; b=uNowDRp5HXqv/FjLmLe2XXFFJlQf32Df4lYYnPc+A5vp5vHirY3X8gBj0orvHH92te MHzrc1fr3vvjlolxMmHzh2AqzLoE+CERX7qQAHMxuWd3bPE0DLvnYfIisYdW/PUR3w/X +ZRNcbVQy6jdK7eJeUnuRRiMVn+HeOTp0QpN8= Received: by 10.224.186.194 with SMTP id ct2mr1102853qab.218.1311964493845; Fri, 29 Jul 2011 11:34:53 -0700 (PDT) Received: from McAsterix.local ([206.172.18.93]) by mx.google.com with ESMTPS id u12sm1547920qct.27.2011.07.29.11.34.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 11:34:52 -0700 (PDT) Message-ID: <4E32FD49.1060802@gmail.com> Date: Fri, 29 Jul 2011 20:34:49 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: pwe3@ietf.org References: <735916399E11684EAF4EB4FB376B71950143E6C8@SZXEML505-MBS.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B71950143E6C8@SZXEML505-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:34:56 -0000 Yes/Support. Regards, Huub. > ------------------------------------------------------------------------ > *From:* pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of > Bocci, Matthew (Matthew) [matthew.bocci@alcatel-lucent.com] > *Sent:* Friday, July 29, 2011 2:02 AM > *To:* pwe3@ietf.org > *Subject:* [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt > > This email begins a two week poll to help assess if there is consensus > to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. > > Please indicate whether or not you support adoption of this draft, and > also send any comments to the PWE3 list. > > This poll will end on Friday 12th August. > > Regards, > > Matthew & Andy From venkatflex@gmail.com Fri Jul 29 13:09:19 2011 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 BBD0C21F8AFF for ; Fri, 29 Jul 2011 13:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af15HtHT2AFM for ; Fri, 29 Jul 2011 13:09:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C48FF21F8AFD for ; Fri, 29 Jul 2011 13:09:18 -0700 (PDT) Received: by wyj26 with SMTP id 26so62816wyj.31 for ; Fri, 29 Jul 2011 13:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hE/MXmAFVZBkPK9z8KEIJ0u3byiwUhmI08pMLO5Zt9k=; b=T3cvfTql5KObKVF2zjxdjR5wSqo9qNQshs9Rpatx6N3lAQp8ECRfsOp4T7rBvCJxQf AMvGcYWOFNhNU2gP7sQWPT31pr0bqqYUJMo9FgPCvlQzCBFmH4Gmt9MrG/VAMCNUrmLf dBF0DjPiilP6fXjRxK5FcZW9Hw8eSMvjNv0dc= MIME-Version: 1.0 Received: by 10.227.63.17 with SMTP id z17mr2261230wbh.88.1311970157780; Fri, 29 Jul 2011 13:09:17 -0700 (PDT) Received: by 10.216.138.224 with HTTP; Fri, 29 Jul 2011 13:09:17 -0700 (PDT) Date: Fri, 29 Jul 2011 16:09:17 -0400 Message-ID: From: venkatesan mahalingam To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=20cf3001b83735de8704a93adb96 Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-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, 29 Jul 2011 20:09:19 -0000 --20cf3001b83735de8704a93adb96 Content-Type: text/plain; charset=ISO-8859-1 Yes/Support. Thanks, Venkat. From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Bocci, Matthew (Matthew) [matthew.bocci@alcatel-lucent.com] Sent: Friday, July 29, 2011 2:02 AM To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy --20cf3001b83735de8704a93adb96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes/Support.

Thanks,
Venkat.
From:= =A0pwe3-bounces@ietf.org=A0[pwe3-bounces@ietf.org] on behalf of Bocci, = Matthew (Matthew) [matthew.bocci@alcatel-lucent.com]
Sent: Friday, July 29, 2011 2:02 AM
To:=A0pwe3@ietf.org
Subject: [PWE3] Pol= l for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

This email begi= ns a two week poll to help assess if there is consensus to adopt draft-nade= au-pwe3-vccv-2-02.txt as a PWE3 working group draft.

Please indicate whether or not you support adoption of this draft, and = also send any comments to the PWE3 list.

This poll will end on Frida= y 12th August.

Regards,

Matthew & Andy --20cf3001b83735de8704a93adb96-- From wwwrun@rfc-editor.org Fri Jul 29 15:19:32 2011 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 27E9A11E80D4; Fri, 29 Jul 2011 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.492 X-Spam-Level: X-Spam-Status: No, score=-104.492 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyOcIWZlI9Rk; Fri, 29 Jul 2011 15:19:31 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7D56911E80C8; Fri, 29 Jul 2011 15:19:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 75B3698C52A; Fri, 29 Jul 2011 15:19:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110729221931.75B3698C52A@rfc-editor.org> Date: Fri, 29 Jul 2011 15:19:31 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 6310 on Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping 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, 29 Jul 2011 22:19:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6310 Title: Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping Author: M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein Status: Standards Track Stream: IETF Date: July 2011 Mailbox: mustapha.aissaoui@alcatel-lucent.com, busschbach@alcatel-lucent.com, lmartini@cisco.com, mmorrow@cisco.com, Thomas.Nadeau@ca.com, yaakov_s@rad.com Pages: 40 Characters: 85733 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-oam-msg-map-16.txt URL: http://www.rfc-editor.org/rfc/rfc6310.txt This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK] This document is a product of the Pseudowire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Alexander.Vainshtein@ecitele.com Sat Jul 30 21:46:19 2011 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 CAFED21F85DA for ; Sat, 30 Jul 2011 21:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJpUMm9ZHAj9 for ; Sat, 30 Jul 2011 21:46:18 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2761A21F856C for ; Sat, 30 Jul 2011 21:46:16 -0700 (PDT) X-AuditID: 93eaf2e8-b7c96ae000000a6e-2b-4e34d7536bd5 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 00.A4.02670.357D43E4; Sun, 31 Jul 2011 07:17:23 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 31 Jul 2011 07:46:17 +0300 From: Alexander Vainshtein To: Yaakov Stein , "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Sun, 31 Jul 2011 07:44:52 +0300 Thread-Topic: Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt Thread-Index: AcxNUHyDZAbasUF1Qk6dQX1EkI++NAAOE9QwAGzyndw= Message-ID: References: , <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903E8FD81@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76EC60119419ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgl+LIzCtJLcpLzFFi42KZ/OrTF93g6yZ+Bhvva1oc7rrLaNH3aQuL xYeuH6wOzB6tz/ayeixZ8pPJY9LatADmqAZGm8S8vPySxJJUhZTU4mRbpYCizLLE5EolhcwU WyVDJYWCnMTk1NzUvBJbpcSCgtS8FCU7LgUMYANUlpmnkJqXnJ+SmZduq+QZ7K9rYWFqqWuo ZKembGhszRWSkVmskKqbm5iZo5CbWlycmJ6qABRJ2MKc0bFqFnvB+pCKC7ffsjYw3vToYuTk kBAwkZi85xYbhC0mceHeeiCbi0NIYDejxPVt3cwQzjRGic2N91hAqtgEbCU2rb4LViUi0Moo sejEH0aQBIuAqkTr7Vlgo4QFXCSuHjgLFhcRcJV4PXUyC4RtJbG0/TuYzSvgL7Fj1S0mEFtI oEZiztIHYPWcAt4SbZP7weYwAp30/dQasBpmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sEPWi Enfa1zNC1OdLrHv7ng1il6DEyZlPWCDqJSUOrrjBMoFRdBaSsbOQtMxC0gIR15O4MXUKG4St LbFs4WtmCFtXYsa/QyzI4gsY2VcxSmbmFJQk5aYbGOnml5bopSZnlqTmpOol5+duYoQknxc7 GG+f0TzEKMDBqMTDu1PAxE+INbGsuDL3EKMkB5OSKK/dLaAQX1J+SmVGYnFGfFFpTmrxIUYJ DmYlEd4nR439hHhTEiurUovyYVKuwBiYyCzFnZwPTKh5JfHGBga4OUrivN3Jb3yFBNKBaTI7 NbUgtQhmjgwHh5IEr+9doPWCRanpqRVpmTklCGkmDk6QM3iAzmAGqeEtLkjMLc5Mh8ifYlSU EuftA0kIgCQySvPgekEZp/7///+vGMWBnhbmbQOp4gFmK7juV0CDmYAGs/IZggwG5he4lFQD Y+ZaJ+U3WWc79/2Wkuw+cbH2ZPC7kxqlGkzT/bfM7TfcrBngJjr9eUxWjSCP/92LeRbnbq7g VZy/nStqmU71C2sBA472A2+N+13Kb8w5Gqt54YP97ydR4R/8Mk+osK9lrUr459WtFbecw2yZ YdavZR3dm/WWfC12Fzr1O+WC0GOGNu+LQh1xSizFGYmGWsxFxYkAUKXc0xMEAAA= Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-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: Sun, 31 Jul 2011 04:46:19 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76EC60119419ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, I do NOT support this draft for the same reasons that Yaakov has indicated. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stei= n [yaakov_s@rad.com] Sent: Friday, July 29, 2011 3:58 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt I do not support ! and I can not understand how anyone can support it ! We do NOT need a fourth VCCV type, there are too many already. I completely agree with the part that says if there is a CW then the ACh sho= uld be marked by it. I do NOT agree that if the CW is not used then we should use a non-PW method= developed for MPLS-TP. I do NOT agree that there is any way to deprecate the use of TTL expiry to m= ark the ACh. I do NOT agree that we should change mechanisms that have been widely deploy= ed for many years now, without an extremely pressing reason. Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the= ADDITIONAL option for ACh marking, I might be convinced not to object as strongly. However, since I don't think that PWs can be limited in this matter (the MPL= S WG adopted the "seamless" draft) it would be difficult to convince me that such a limitation is possible. I would have enthusiastically support this proposal had it been brought 8 ye= ars ago. It's too late for this now. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocc= i, Matthew (Matthew) Sent: Thursday, July 28, 2011 21:02 To: pwe3@ietf.org Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt This email begins a two week poll to help assess if there is consensus to ad= opt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft. Please indicate whether or not you support adoption of this draft, and also= send any comments to the PWE3 list. This poll will end on Friday 12th August. Regards, Matthew & Andy 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_A3C5DF08D38B6049839A6F553B331C76EC60119419ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Hi all,
I do NOT support this draft for the same reasons that Yaakov has indica= ted.
 
Regards,
     Sasha
 
From: pwe3-bounces= @ietf.org [pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein [yaakov_s@rad.co= m]
Sent: Friday, July 29, 2011 3:58 AM
To: Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-= 02.txt

I do not support !    and I c= an not understand how anyone can support it !

 

We do NOT need a fourth VCCV type, there are= too many already.

 

I completely agree with the part that says i= f there is a CW then the ACh should be marked by it.

 

I do NOT agree that if the CW is not used th= en we should use a non-PW method developed for MPLS-TP.

I do NOT agree that there is any way to depr= ecate the use of TTL expiry to mark the ACh.

I do NOT agree that we should change mechani= sms that have been widely deployed for many years now,

without an extremely pressing reason.=

 

Were the proposal to be that for PWs that tr= averse ONLY MPLS-TP to have the ADDITIONAL option

for ACh marking, I might be convinced not to= object as strongly.

However, since I don't think that PWs can be= limited in this matter (the MPLS WG adopted the "seamless" draft)=

it would be difficult to convince me that su= ch a limitation is possible.

 

I would have enthusiastically support this p= roposal had it been brought 8 years ago.

It's too late for this now.

 

Y(J)S

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.o= rg] On Behalf Of Bocci, Matthew (Matthew)
Sent: Thursday, July 28, 2011 21:02
To: pwe3@ietf.org
Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t= xt

 

This email begins a two week poll to help as= sess if there is consensus to adopt draft-nadeau-pwe3-vccv-2-02.txt as= a PWE3 working group draft.

 

Please indicate whether or not you support a= doption of this draft, and also send any comments to the PWE3 list.

 

This poll will end on Friday 12th August.

 

Regards,

 

Matthew & Andy

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_A3C5DF08D38B6049839A6F553B331C76EC60119419ILPTMAIL02eci_--