From Internet-Drafts@ietf.org Sun Jan 2 00:30:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DA03A698D; Sun, 2 Jan 2011 00:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOw6yXCCRAL1; Sun, 2 Jan 2011 00:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F823A68D7; Sun, 2 Jan 2011 00:30:01 -0800 (PST) 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.10 Message-ID: <20110102083001.32530.72516.idtracker@localhost> Date: Sun, 02 Jan 2011 00:30:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-analysis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 08:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : OAM functions in MPLS based transport network Author(s) : N. Sprecher, et al. Filename : draft-ietf-mpls-tp-oam-analysis-03.txt Pages : 14 Date : 2011-01-02 This document describes the outcome of the discussions on the necessary OAM functionality for the first release of MPLS based transport networks. The discussion is based on the set of requirements for Operations, Administration, and Maintenance (OAM) for MPLS based transport networks as defined in [MPLS-TP OAM Reqs]. An important aspect was to evaluate whether existing OAM tools from the current MPLS protocol suite can be used to fulfill these requirements. Eventually, the purpose of the document is to map the set of functions to a set of tools based on the existing OAM tool- set. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-03.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-mpls-tp-oam-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-02001627.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Mon Jan 3 07:05:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF2B3A69E0; Mon, 3 Jan 2011 07:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCKe1uF+FkHd; Mon, 3 Jan 2011 07:05:32 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EA23A69E2; Mon, 3 Jan 2011 07:05:32 -0800 (PST) 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.10 Message-ID: <20110103150532.10310.79802.idtracker@localhost> Date: Mon, 03 Jan 2011 07:05:32 -0800 Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Label Edge Router Forwarding of IPv4 Option Packets' to Proposed Standard (draft-ietf-mpls-ip-options-07.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:05:33 -0000 The IESG has approved the following document: - 'Label Edge Router Forwarding of IPv4 Option Packets' (draft-ietf-mpls-ip-options-07.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ip-options/ Technical Summary Requirements for Label Edge Router Forwarding of IPv4 Option Packets specifies how Label Edge Routers (LER) should behave when determining whether to MPLS encapsulate an IP packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IP packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IP option packets that belong to a prefix-based FEC but fail to be MPLS encapsulated simply due to their header options present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IP packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. Working Group Summary Nothing worth noting, except that there was some discussion of whether this should go forward as an informational draft. The WG consensus was to have it on the Standards track. Further details of this dicussion can be seen in the proto write-up. Document Quality This is not a protocol extension but implementations of the described mechanism may exist. The document quality is good as well as the review. Personnel George Swallow is the Document Shepherd Adrian Farrel is the responsible Area Director From nick.delregno@verizon.com Mon Jan 3 08:38:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE793A6985; Mon, 3 Jan 2011 08:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZY8Sb9rSXbU; Mon, 3 Jan 2011 08:38:39 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 6F2903A698A; Mon, 3 Jan 2011 08:38:30 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LEG00785GZNKLA0@firewall.verizonbusiness.com>; Mon, 03 Jan 2011 16:40:35 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LEG007E9GZN7I00@pdcismtp03.vzbi.com>; Mon, 03 Jan 2011 16:40:35 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LEG0076RGZM8V00@pdcismtp03.vzbi.com>; Mon, 03 Jan 2011 16:40:35 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 03 Jan 2011 16:40:35 +0000 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_01CBAB64.F1302B7F" Date: Mon, 03 Jan 2011 16:40:26 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600061FAF51@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: PW / VCCV User Implementation Survey - Please Participate! Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQBuDxc0A= References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 03 Jan 2011 16:40:35.0156 (UTC) FILETIME=[F1C61140:01CBAB64] Subject: [mpls] PW / VCCV User Implementation Survey - Please Participate! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:38:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAB64.F1302B7F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Just a friendly reminder to complete (or ask your customers to complete) the PW/VCCV User Implementation Survey. =20 =20 We have 6 responses so far. =20 The deadline is February 25, 2011. =20 Thanks, Nick =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Delregno, Christopher N (Nick DelRegno) Sent: Thursday, November 04, 2010 3:55 PM To: pwe3; mpls@ietf.org; l2vpn@ietf.org Cc: Malis, Andrew G. (Andy) Subject: [PWE3] PW / VCCV Service Provider Implementation Survey =20 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBAB64.F1302B7F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Just a friendly reminder to complete (or ask = your customers to complete) the PW/VCCV User Implementation = Survey. 

 

We have 6 responses = so far.

 

The deadline is February = 25, 2011.

 

Thanks,

Nick

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Delregno, Christopher N (Nick DelRegno)
Sent: Thursday, = November 04, 2010 3:55 PM
To: pwe3; mpls@ietf.org; = l2vpn@ietf.org
Cc: Malis, Andrew G. (Andy)
Subject: = [PWE3] PW / VCCV Service Provider Implementation = Survey

 

All:

 

Per the = direction of the PWE3 working group, beginning in IETF77 and reinforced = in IETF78, the PWE3 working group is conducting a Service Provider = implementation survey related to:

 

-          = Pseudowire Encapsulations

-          = Control Word Support

-          = Control Word Use

-          = VCCV Control Channel Support

-          = VCCV Control Channel Use

 

http://www.surveymonkey.com/s= /pwe3

 

This is a short survey directed toward Service = Providers who currently operate networks using any of the defined PWE3 = encapsulations.  The results of this survey will be used to = determine the direction of the Control Word support in current and = future encapsulations as well as solutions to VCCV interoperability = challenges.

 

We sincerely urge all service providers to = participate.  We ask that all equipment providers encourage = participation by their Service Provider customers.  The more = feedback we receive, the better view of the existing network we can have = on which to base going-forward direction.

 

If you have = any questions, regarding the survey, especially of a technical nature, = please contact me.  If you have non-technical questions, feel free = to reach out to the PWE3 WG chairs and myself.

 

The results = of the survey will be aggregated and shared at a high level.  No = low-level details of network implementations will be shared.  All = participant’s responses will remain private, if not = anonymous.

 

All responses will require a valid email address to = help ensure the survey’s validity.

 

Thanks,

Nick

 

Christopher N. “Nick” DelRegno, = PMTS

CNT, Ethernet Network Architecture & = Design

400 International Pkwy

Richardson, TX  = 75081

Tel:  972-729-3411

Email:  = Nick.DelRegno@verizon.com

 

------_=_NextPart_001_01CBAB64.F1302B7F-- From yaacov.weingarten@nsn.com Mon Jan 3 23:49:06 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275113A6B51; Mon, 3 Jan 2011 23:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=2.510, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtR0GYlwPvSt; Mon, 3 Jan 2011 23:49:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 02DD73A6B4E; Mon, 3 Jan 2011 23:49:04 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p047p8Nj005842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jan 2011 08:51:08 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p047p4Rf024217; Tue, 4 Jan 2011 08:51:07 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 08:51:06 +0100 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, 4 Jan 2011 08:51:04 +0100 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D03215CDE@DEMUEXC030.nsn-intra.net> In-Reply-To: <20110102083001.32530.72516.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-tp-oam-analysis-03.txt Thread-Index: AcuqV7X8bfpWd1xBTum8n6lnnJcXDgBjCMCA References: <20110102083001.32530.72516.idtracker@localhost> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 04 Jan 2011 07:51:06.0086 (UTC) FILETIME=[24587060:01CBABE4] Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-oam-analysis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 07:49:06 -0000 Hi all, We have updated this draft to prevent it from expiring. This version addresses some of the comments received during the WG LC. We will republish when we have completed addressing all of the comments. Best Regards, The Editors >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of ext Internet-Drafts@ietf.org >> Sent: Sunday, January 02, 2011 10:30 AM >> To: i-d-announce@ietf.org >> Cc: mpls@ietf.org >> Subject: [mpls] I-D Action:draft-ietf-mpls-tp-oam-analysis-03.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Multiprotocol Label Switching Working >> Group of the IETF. >>=20 >>=20 >> Title : OAM functions in MPLS based transport network >> Author(s) : N. Sprecher, et al. >> Filename : draft-ietf-mpls-tp-oam-analysis-03.txt >> Pages : 14 >> Date : 2011-01-02 >>=20 >> This document describes the outcome of the discussions on the >> necessary OAM functionality for the first release of MPLS based >> transport networks. The discussion is based on the set of >> requirements for Operations, Administration, and Maintenance (OAM) >> for MPLS based transport networks as defined in [MPLS-TP OAM Reqs]. >> An important aspect was to evaluate whether existing OAM tools from >> the current MPLS protocol suite can be used to fulfill these >> requirements. Eventually, the purpose of the document is to map the >> set of functions to a set of tools based on the existing OAM tool- >> set. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis- >> 03.txt >>=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. From yaacov.weingarten@nsn.com Mon Jan 3 23:58:20 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E5F3A6B5D; Mon, 3 Jan 2011 23:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.246 X-Spam-Level: X-Spam-Status: No, score=-4.246 tagged_above=-999 required=5 tests=[AWL=2.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ9eI1t9B98M; Mon, 3 Jan 2011 23:58:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 927E33A6B4E; Mon, 3 Jan 2011 23:58:15 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0480LfL026199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jan 2011 09:00:21 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0480LJZ025408; Tue, 4 Jan 2011 09:00:21 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 09:00:21 +0100 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_01CBABE5.6EEBD34C" Date: Tue, 4 Jan 2011 09:00:19 +0100 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D03215CF1@DEMUEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-weingarten-mpls-tp-ring-protection-04 Thread-Index: Acur5W5MixiV9EijSkqw7jb+0SO5/g== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 04 Jan 2011 08:00:21.0131 (UTC) FILETIME=[6F2D95B0:01CBABE5] Subject: [mpls] New version of draft-weingarten-mpls-tp-ring-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 07:58:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBABE5.6EEBD34C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, We have submitted a new version of the ring protection draft, mainly to prevent the draft from expiring. However, there is one significant change from the previous version in the section on p2mp steering protection - where the description now references the concept of context-labels in order to explain the working of the working and protection SPME. Any comments regarding this section especially would be appreciated, as the editors are still discussing how to improve the description. Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_001_01CBABE5.6EEBD34C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of = draft-weingarten-mpls-tp-ring-protection-04

Hello all,

We have = submitted a new version of the ring protection draft, mainly to prevent = the draft from expiring.  However, there is one significant = change from the previous version in the section on p2mp steering = protection – where the description now references the concept of = context-labels in order to explain the working of the working and = protection SPME.  Any comments regarding this section especially would be = appreciated, as the editors are still discussing how to improve the = description.

Best = regards,

Yaacov = Weingarten

Nokia Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 0977

------_=_NextPart_001_01CBABE5.6EEBD34C-- From lizhong.jin@zte.com.cn Tue Jan 4 22:24:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF6A3A6992; Tue, 4 Jan 2011 22:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.475 X-Spam-Level: X-Spam-Status: No, score=-101.475 tagged_above=-999 required=5 tests=[AWL=0.363, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKGNRbHmTpBL; Tue, 4 Jan 2011 22:23:58 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2A8A03A6A77; Tue, 4 Jan 2011 22:23:56 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205952736992880; Wed, 5 Jan 2011 14:21:56 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 68277.4874703856; Wed, 5 Jan 2011 14:26:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id p056PvxR076684; Wed, 5 Jan 2011 14:25:57 +0800 (CST) (envelope-from lizhong.jin@zte.com.cn) To: mpls@ietf.org, tictoc@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, 5 Jan 2011 14:24:57 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-01-05 14:25:41, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-01-05 14:25:41, Serialize complete at 2011-01-05 14:25:41, S/MIME Sign failed at 2011-01-05 14:25:41: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-05 14:25:46, Serialize complete at 2011-01-05 14:25:46 Content-Type: multipart/alternative; boundary="=_alternative 00234FC14825780F_=" X-MAIL: mse3.zte.com.cn p056PvxR076684 Cc: Ice , N.Leymann@telekom.de Subject: [mpls] Request comments for HSMP LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 06:24:03 -0000 This is a multipart message in MIME format. --=_alternative 00234FC14825780F_= Content-Type: text/plain; charset="US-ASCII" Hi all, During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS session. HSMP LSP has several use cases described in the draft, e.g, time synchronization in MPLS network, IPTV scenario, or P2MP PW. It would be appreciated if you could give more scenarios for HSMP LSP. Please review the draft, and any comments are welcome. The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-01 Thank you. Authors of draft-hsmp. -------------------------------------------------------- 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 00234FC14825780F_= Content-Type: text/html; charset="US-ASCII"
Hi all,
During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS session.
HSMP LSP has several use cases described in the draft, e.g, time synchronization in MPLS network, IPTV scenario, or P2MP PW. It would be appreciated if you could give more scenarios for HSMP LSP. Please review the draft, and any comments are welcome.

The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-01
 
Thank you.
Authors of draft-hsmp.
--------------------------------------------------------
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 00234FC14825780F_=-- From maillist.ed@gmail.com Tue Jan 4 23:03:32 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3892E3A6B83; Tue, 4 Jan 2011 23:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1ZE6+wX2DGX; Tue, 4 Jan 2011 23:03:26 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E99B73A6B45; Tue, 4 Jan 2011 23:03:25 -0800 (PST) Received: by wwa36 with SMTP id 36so15091145wwa.13 for ; Tue, 04 Jan 2011 23:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=AiW3EnKOwTOhU5+l7PWdMpkL1Ha8mzFYUxQA267jyrE=; b=uKdwI6aVGLT2BpirWmO/xT4wUKqc2PSRTTWgTh0VrTqmOYPsaoGnwOtVKWMDDQsp8N nYosft4Y0P03VvZNb441A4mwI/DTUpABG4KQQhvfZQqeMEz6McYCM9QFs+npGZjzUckZ HVaPfXv/4ypn2ZARuvpSjz4ksScZNMwQQ7psc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HG2F49H2Kw6+mcMlUiVRknpa1mEpb/wTXXiNExCtnqVgM4k/60HbbK+/gH8JlB6aAV 3ID+MOfDIDfHPXMe768ak5pnEUUUROBBDeDcluQxEy6UE+ejRmWoYNKFioM51GBjKO5m UvQaOBpXzIQMJV5D4bOlJVavg8b2zNqNqwdkw= MIME-Version: 1.0 Received: by 10.227.96.212 with SMTP id i20mr12894823wbn.157.1294211130936; Tue, 04 Jan 2011 23:05:30 -0800 (PST) Received: by 10.227.144.68 with HTTP; Tue, 4 Jan 2011 23:05:30 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Jan 2011 18:05:30 +1100 Message-ID: From: Ed To: lizhong.jin@zte.com.cn Content-Type: multipart/alternative; boundary=000e0cd2e7d4b94e6e0499140252 Cc: mpls@ietf.org, Ice , tictoc@ietf.org, N.Leymann@telekom.de Subject: Re: [mpls] Request comments for HSMP LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 07:03:32 -0000 --000e0cd2e7d4b94e6e0499140252 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lizhong, I think one possible application for HSMP LSPs is to reduce the overall broadcast/multicast utilization on a VPLS. In current VPLS implementations with a full mesh of P2P LSPs between PEs, broadcast, multicast and unknown traffic are not efficiently propagated on the physical links between PEs an= d Ps. In the VPLS implementation scenario with HSMP LSPs, each PE signals a HSMP LSP with itself as a root to all other PEs in the VPLS. Thereafter, all broadcast/multicast/unknown traffic from this PE will use this HSMP LSP. Unicast traffic from a particular PE (e.g. PE1) to another PE (e.g. PE2) will be sent from leaf to root using the HSMP LSP where PE2 is the root. This simplifies the VPLS implementation by: - Reducing traffic utilization from broadcast, multicast and unknown traffic - Reducing the total number of LSPs maintained by each PE (i.e. instead of requiring a full mesh of LSPs, now only require one HSMP LSP per PE). This is similar to the idea expressed in draft-key-l2vpn-etree-frwk-03.txt (in a more general sense). What do you think? Would HSMP LSP be suitable for this? Regards, Edward On Wed, Jan 5, 2011 at 5:24 PM, wrote: > > Hi all, > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS > session. > HSMP LSP has several use cases described in the draft, e.g, time > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would be > appreciated if you could give more scenarios for HSMP LSP. Please review = the > draft, and any comments are welcome. > > The draft link is: > http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-01 > > Thank you. > Authors of draft-hsmp. > > -------------------------------------------------------- > 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 and = 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 individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --000e0cd2e7d4b94e6e0499140252 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Lizhong,

=A0

I think one possible application for HSMP L= SPs is to reduce the overall broadcast/multicast utilization on a VPLS. In = current VPLS implementations with a full mesh of P2P LSPs between PEs, broa= dcast, multicast and unknown traffic are not efficiently propagated on the = physical links between PEs and Ps.

=A0

In the VPLS implementation scenario with HS= MP LSPs, each PE signals a HSMP LSP with itself as a root to all other PEs = in the VPLS. Thereafter, all broadcast/multicast/unknown traffic from this = PE will use this HSMP LSP. Unicast traffic from a particular PE (e.g. PE1) = to another PE (e.g. PE2) will be sent from leaf to root using the HSMP LSP = where PE2 is the root.

=A0

This simplifies the VPLS implementation by:=

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Reducing traffic utilization from broadc= ast, multicast and unknown traffic

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Reducing the total number of LSPs mainta= ined by each PE (i.e. instead of requiring a full mesh of LSPs, now only re= quire one HSMP LSP per PE).

=A0

This is similar to the idea expressed in=A0 draft-key-l2vpn-etree-frwk-03.txt= (in a more general sense).

=A0

What do you think? = Would HSMP LSP be suitable for this?


Regards,

Edward

=A0

=A0

=A0
On Wed, Jan 5, 2011 at 5:24 PM, <lizhong.jin@zte.com.cn&= gt; wrote:

Hi all,
During IET= F 79 Beijing, we made a presentation for HSMP LSP at MPLS session. <= br> HSMP LSP has several use cases describ= ed in the draft, e.g, time synchronization in MPLS network, IPTV scenario, = or P2MP PW. It would be appreciated if you could give more scenarios for HS= MP LSP. Please review the draft, and any comments are welcome.

The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-01 =
=A0
Thank you.
Authors= of draft-hsmp.
--------------------------------------------=
------------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.

_______________________________________________
mpls mailing l= ist
mpls@ietf.org
https://www.ietf= .org/mailman/listinfo/mpls


--000e0cd2e7d4b94e6e0499140252-- From lizhong.jin@zte.com.cn Tue Jan 4 23:52:35 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0483A6B83; Tue, 4 Jan 2011 23:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.497 X-Spam-Level: X-Spam-Status: No, score=-101.497 tagged_above=-999 required=5 tests=[AWL=0.341, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJHLcLBaOW5o; Tue, 4 Jan 2011 23:52:34 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A6A4E3A6A2C; Tue, 4 Jan 2011 23:52:33 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205953314101978; Wed, 5 Jan 2011 15:50:20 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 68277.7391410851; Wed, 5 Jan 2011 15:51:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id p057plgj095486; Wed, 5 Jan 2011 15:51:47 +0800 (CST) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Ed 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, 5 Jan 2011 15:50:45 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-01-05 15:51:29, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-01-05 15:51:29, Serialize complete at 2011-01-05 15:51:29, S/MIME Sign failed at 2011-01-05 15:51:29: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-05 15:51:33, Serialize complete at 2011-01-05 15:51:33 Content-Type: multipart/alternative; boundary="=_alternative 002B2AB74825780F_=" X-MAIL: mse2.zte.com.cn p057plgj095486 Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , N.Leymann@telekom.de, tictoc@ietf.org Subject: Re: [mpls] Request comments for HSMP LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 07:52:35 -0000 This is a multipart message in MIME format. --=_alternative 002B2AB74825780F_= Content-Type: text/plain; charset="US-ASCII" Hi Edward, Thank you for the comments. I add l2vpn maillist in cc list. I agree with the application you proposed, and in order to improve the scalability of VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually this is a good application case for P2MP PW with reverse path (section 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this use case. Regards Lizhong Ed wrote on 2011-01-05 15:05:30: > Hi Lizhong, > > I think one possible application for HSMP LSPs is to reduce the > overall broadcast/multicast utilization on a VPLS. In current VPLS > implementations with a full mesh of P2P LSPs between PEs, broadcast, > multicast and unknown traffic are not efficiently propagated on the > physical links between PEs and Ps. > > In the VPLS implementation scenario with HSMP LSPs, each PE signals > a HSMP LSP with itself as a root to all other PEs in the VPLS. > Thereafter, all broadcast/multicast/unknown traffic from this PE > will use this HSMP LSP. Unicast traffic from a particular PE (e.g. > PE1) to another PE (e.g. PE2) will be sent from leaf to root using > the HSMP LSP where PE2 is the root. > > This simplifies the VPLS implementation by: > - Reducing traffic utilization from broadcast, multicast > and unknown traffic > - Reducing the total number of LSPs maintained by each PE > (i.e. instead of requiring a full mesh of LSPs, now only require one > HSMP LSP per PE). > > This is similar to the idea expressed in draft-key-l2vpn-etree- > frwk-03.txt (in a more general sense). > > What do you think? Would HSMP LSP be suitable for this? > > Regards, > Edward > > > > On Wed, Jan 5, 2011 at 5:24 PM, wrote: > > Hi all, > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS session. > HSMP LSP has several use cases described in the draft, e.g, time > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would > be appreciated if you could give more scenarios for HSMP LSP. Please > review the draft, and any comments are welcome. > > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls- > mldp-hsmp-01 > > Thank you. > Authors of draft-hsmp. > -------------------------------------------------------- > 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. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -------------------------------------------------------- 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 002B2AB74825780F_= Content-Type: text/html; charset="US-ASCII"
Hi Edward,
Thank you for the comments. I add l2vpn maillist in cc list. I agree with the application you proposed, and in order to improve the scalability of VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually this is a good application case for P2MP PW with reverse path (section 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this use case.

Regards
Lizhong
 

Ed <maillist.ed@gmail.com> wrote on 2011-01-05 15:05:30:

> Hi Lizhong,
>  
> I think one possible application for HSMP LSPs is to reduce the
> overall broadcast/multicast utilization on a VPLS. In current VPLS
> implementations with a full mesh of P2P LSPs between PEs, broadcast,
> multicast and unknown traffic are not efficiently propagated on the
> physical links between PEs and Ps.
>  
> In the VPLS implementation scenario with HSMP LSPs, each PE signals
> a HSMP LSP with itself as a root to all other PEs in the VPLS.
> Thereafter, all broadcast/multicast/unknown traffic from this PE
> will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
> PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> the HSMP LSP where PE2 is the root.
>  
> This simplifies the VPLS implementation by:
> -          Reducing traffic utilization from broadcast, multicast
> and unknown traffic
> -          Reducing the total number of LSPs maintained by each PE
> (i.e. instead of requiring a full mesh of LSPs, now only require one
> HSMP LSP per PE).
>  
> This is similar to the idea expressed in  draft-key-l2vpn-etree-
> frwk-03.txt (in a more general sense).
>  
> What do you think? Would HSMP LSP be suitable for this?
>
> Regards,
> Edward
>  
>  
>  
> On Wed, Jan 5, 2011 at 5:24 PM, <lizhong.jin@zte.com.cn> wrote:
>
> Hi all,
> During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS session.
> HSMP LSP has several use cases described in the draft, e.g, time
> synchronization in MPLS network, IPTV scenario, or P2MP PW. It would
> be appreciated if you could give more scenarios for HSMP LSP. Please
> review the draft, and any comments are welcome.
>
> The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> mldp-hsmp-01
>  
> Thank you.
> Authors of draft-hsmp.
> --------------------------------------------------------
> 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.
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

--------------------------------------------------------
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 002B2AB74825780F_=-- From Internet-Drafts@ietf.org Wed Jan 5 04:00:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1593A6B74; Wed, 5 Jan 2011 04:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lfBHm7HS9W3; Wed, 5 Jan 2011 04:00:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296463A6D3C; Wed, 5 Jan 2011 04:00:02 -0800 (PST) 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.10 Message-ID: <20110105120002.18857.25226.idtracker@localhost> Date: Wed, 05 Jan 2011 04:00:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-mib-management-overview-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 12:00:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-tp-mib-management-overview-01.txt Pages : 22 Date : 2011-01-05 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based management architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules would be required. 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 as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] King & Venkatesan, et al. [page 1] draft-ietf-mpls-tp-mib-management-overview-01.txt January 2011 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overview-01.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-mpls-tp-mib-management-overview-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05035746.I-D@ietf.org> --NextPart-- From daniel@olddog.co.uk Wed Jan 5 04:17:13 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C6B3A6B81; Wed, 5 Jan 2011 04:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-BRT31rdHWD; Wed, 5 Jan 2011 04:17:12 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id E939E3A6B71; Wed, 5 Jan 2011 04:17:11 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p05CJGdU010947; Wed, 5 Jan 2011 12:19:16 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p05CJEQj010927; Wed, 5 Jan 2011 12:19:14 GMT From: "Daniel King" To: , Date: Wed, 5 Jan 2011 12:19:12 -0000 Message-ID: <011901cbacd2$c31fc560$495f5020$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acus0NoSIwL/giWgSQWF+O1iF7AaCg== Content-Language: en-gb Subject: [mpls] New version of draft-ietf-mpls-tp-mib-management-overview (01) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 12:17:13 -0000 Hi All, Happy New Year! Please note that the authors of draft-ietf-mpls-tp-mib-management-overview have issued a new version of said document. Updates include: - Cleaned up Abstract. - Included GMPLS TC references where relevant. - Updated Pseudowire Module section. - Added significant text (tables) to the Fault Management and Performance Management section. - Updated MPLS-TP Gap Analysis section. - Added a new co-author. - Addressed various grammar and nits. We have also identified the need for an MPLS-TP abstract model document. This new draft will provide an abstract model and use a formal language to define the terminology, the information that must be retrieved and stored. It will also list the new MPLS-TP MIB modules, identified as part of the gap analysis in draft-ietf-mpls-tp-mib-management-overview. Br, Dan. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 05 January 2011 12:00 To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: I-D Action:draft-ietf-mpls-tp-mib-management-overview-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-tp-mib-management-overview-01.txt Pages : 22 Date : 2011-01-05 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based management architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules would be required. 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 as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] King & Venkatesan, et al. [page 1] draft-ietf-mpls-tp-mib-management-overview-01.txt January 2011 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvi ew-01.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. From michelg@upperside.fr Thu Jan 6 04:13:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527F43A6F00 for ; Thu, 6 Jan 2011 04:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38FtiBGJu8t7 for ; Thu, 6 Jan 2011 04:13:41 -0800 (PST) Received: from smtp02.msg.oleane.net (smtp02.msg.oleane.net [62.161.4.2]) by core3.amsl.com (Postfix) with ESMTP id C872D3A6EFF for ; Thu, 6 Jan 2011 04:13:39 -0800 (PST) Received: from MichelGosseDel (AAubervilliers-752-1-17-188.w90-61.abo.wanadoo.fr [90.61.48.188]) (authenticated) by smtp02.msg.oleane.net (MSA) with ESMTP id p06CFe3V032074 for ; Thu, 6 Jan 2011 13:15:40 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: References: <002a01cbad97$55fb2360$01f16a20$@upperside.fr> <00e701cbad98$b3e95a40$1bbc0ec0$@upperside.fr> In-Reply-To: <00e701cbad98$b3e95a40$1bbc0ec0$@upperside.fr> Date: Thu, 6 Jan 2011 13:15:41 +0100 Message-ID: <004e01cbad9b$6fdd2090$4f9761b0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CBADA3.D1A224D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu1CBwjuiBpSxoaFZN1i3XFpxnYAL6s8qykuW4w9A= Content-Language: fr X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.6.120615 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Congress 2011 - Paris X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 12:13:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01CBADA3.D1A224D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 13th edition of MPLS & Ethernet World Congress will start next 8 February 2011. The 2011 agenda will pay particular attention to MPLS TP OAM uncertainties, optical layer integration, Cloud services impact, mobile backhaul and multicast issues. More info: http://www.upperside.fr/ ------=_NextPart_000_004F_01CBADA3.D1A224D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 13th edition of MPLS & = Ethernet World Congress will start next 8 February = 2011.

The 2011 agenda will pay particular = attention to MPLS TP OAM = uncertainties, optical layer integration, Cloud services impact, mobile = backhaul and multicast issues. =

 

More info: http://www.upperside.fr/

------=_NextPart_000_004F_01CBADA3.D1A224D0-- From ldunbar@huawei.com Thu Jan 6 15:19:07 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66D03A6E3F; Thu, 6 Jan 2011 15:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.997 X-Spam-Level: X-Spam-Status: No, score=-105.997 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm4z3DcGPJFi; Thu, 6 Jan 2011 15:19:03 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 6723F3A6E2D; Thu, 6 Jan 2011 15:19:03 -0800 (PST) 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 <0LEM005Y3JJ9KU@usaga02-in.huawei.com>; Thu, 06 Jan 2011 15:21:10 -0800 (PST) Received: from L735042 ([10.124.12.121]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEM00DOMJJ9MJ@usaga02-in.huawei.com>; Thu, 06 Jan 2011 15:21:09 -0800 (PST) Date: Thu, 06 Jan 2011 17:21:09 -0600 From: Linda Dunbar To: mpls-tp@ietf.org, mpls@ietf.org, 'Dan Frost' , 'Stewart Bryant' Message-id: <002901cbadf8$66783640$790c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Nk8FTcJsBtZZk1Fz+Ped6Q)" Thread-index: Acut+GY8NiB+SQfOSi+H6qHdg0Hkpw== Subject: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:19:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Nk8FTcJsBtZZk1Fz+Ped6Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dan and Stewart, I have a few questions and some suggestions on your recent draft: Section 2 (Overview), there are several references of measuring "packets" without specifying if the packets are LM/DM packets or actual data plane packets. Such Page 7 first paragraph: " the count of packets received prior to time T2 over the channel from A (B_RxP)," Is this the intent? So that LM can be used to either measuring the LM losses and data plane loss? Section 2.7.1 Types of Channels: It stated that LM and DM flow over MPLS G-Ach. Since packets over G-Ach might encounter extra processing on intermediate nodes, the Delay measured over G-Ach channel might be slightly different from the data plane channel. Will it be a problem? Section 2.7.6. Loss Measurement Modes Under the "direct mode", I interpret it as measuring the data plane packets, is it correct? Counting data plane packets can be process intensive. Usually the each node (or line card) can only do actual packet counting for limited number of LSPs. Therefore, I suggest allowing B node to ignore A node's LM when B is not ready to do the counting or send back a reply to indicate the "not ready status". o Several options are possible for the negotiation: egress simply ignore the request when it is not ready, egress sends back an error, etc. Ingress node doesn't need to start counting traffic until it gets confirmation from the egress node. Should allow options of either byte counter or packet counter. Thank you very much. Linda Dunbar --Boundary_(ID_Nk8FTcJsBtZZk1Fz+Ped6Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable Questions on "draft-ietf-mpls-loss-delay-00"

Dan and Stewart, =

I have a few = questions and = some suggestions on your recent draft:

Section 2 = (Overview),

      there are several = references = of measuring “packets” without specifying if the packets are = LM/DM packets or actual data plane packets. Such Page = 7 first = paragraph: “ the = count of packets received prior to time T2 over the channel = from A (B_RxP),”

      Is this the intent? So that LM can be used to either = measuring the LM losses and data plane loss?

Section = 2.7.1 Types of Channels:

      It stated that LM and = DM flow over = MPLS G-Ach. Since packets over G-Ach might encounter extra processing = on intermediate nodes, = the Delay = measured over G-Ach channel might be slightly different = from the data plane channel. Will it be a problem?

Section 2.7.6. = Loss Measurement Modes

      Under the “direct mode”, = I interpret it as = measuring the data plane packets, is it = correct?

      Counting data plane packets can be = process intensive.  Usually the each node (or line card) = can only do actual = packet = counting for limited = number of LSPs. Therefore, I suggest allowing B node to ignore A = node’s LM when B is not ready to = do the counting = or send back a reply to indicate the = “not ready status”.

o       Several options are possible for = the negotiation: egress simply ignore the request when it is not ready, = egress sends back an error, etc. Ingress = node doesn’t need to start counting traffic until it gets = confirmation from the egress node. =

Should allow = options of either byte counter or packet counter.

Thank you very = much.

Linda = Dunbar

= --Boundary_(ID_Nk8FTcJsBtZZk1Fz+Ped6Q)-- From Alexander.Vainshtein@ecitele.com Thu Jan 6 22:46:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383503A67C1; Thu, 6 Jan 2011 22:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhtbkWS2p98P; Thu, 6 Jan 2011 22:46:40 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 2C2603A67B2; Thu, 6 Jan 2011 22:46:38 -0800 (PST) X-AuditID: 93eaf2e7-b7c8fae000002726-39-4d26b74e838f Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id BD.D2.10022.E47B62D4; Fri, 7 Jan 2011 08:48:46 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 7 Jan 2011 08:50:23 +0200 From: Alexander Vainshtein To: Linda Dunbar Date: Fri, 7 Jan 2011 08:48:42 +0200 Thread-Topic: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Thread-Index: Acut+GY8NiB+SQfOSi+H6qHdg0HkpwAPVrOB Message-ID: References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> In-Reply-To: <002901cbadf8$66783640$790c7c0a@china.huawei.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_A3C5DF08D38B6049839A6F553B331C76D6B8336307ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: 'Stewart Bryant' , "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:46:43 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6B8336307ILPTMAIL02eci_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Linda, Please see my comment inline below. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Linda Dunb= ar [ldunbar@huawei.com] Sent: Friday, January 07, 2011 1:21 AM To: mpls-tp@ietf.org; mpls@ietf.org; 'Dan Frost'; 'Stewart Bryant' Subject: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Dan and Stewart, I have a few questions and some suggestions on your recent draft: Section 2 (Overview), there are several references of measuring =93packets=94 without specifying = if the packets are LM/DM packets or actual data plane packets. Such Page 7 = first paragraph: =93 the count of packets received prior to time T2 over th= e channel from A (B_RxP),=94 Is this the intent? So that LM can be used to either measuring the LM losse= s and data plane loss? Section 2.7.1 Types of Channels: It stated that LM and DM flow over MPLS G-Ach. Since packets over G-Ach mig= ht encounter extra processing on intermediate nodes, the Delay measured ove= r G-Ach channel might be slightly different from the data plane channel. Wi= ll it be a problem? [[Sasha]] IMHO packets running over G-ACh SHOULD NOT experience any special= processing in the intermediate nodes because GAL (and, by implication G-AC= h) will not be exposed to these nodes. However, this is only true if the ov= erall depth of the label stack (GAL included) does not exceed the limit on = the number of labels these nodes are ready to treat normally. What happens if this limit is exceeded is implementation-specific and may b= e as severe as dropping offending packets unconditionally. Other known case= s include ignoring extra labels, slowing down processing etc. AFAIK, MPLS-TP development had, so far, ignored this problem. Maybe it is h= igh time to recognize it? Section 2.7.6. Loss Measurement Modes Under the =93direct mode=94, I interpret it as measuring the data plane pac= kets, is it correct? Counting data plane packets can be process intensive. Usually the each nod= e (or line card) can only do actual packet counting for limited number of L= SPs. Therefore, I suggest allowing B node to ignore A node=92s LM when B is= not ready to do the counting or send back a reply to indicate the =93not r= eady status=94. o Several options are possible for the negotiation: egress simply ign= ore the request when it is not ready, egress sends back an error, etc. Ingr= ess node doesn=92t need to start counting traffic until it gets confirmatio= n from the egress node. Should allow options of either byte counter or packet counter. Thank you very much. Linda Dunbar --_000_A3C5DF08D38B6049839A6F553B331C76D6B8336307ILPTMAIL02eci_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Linda,
Please see my comment inline bel= ow.
 
Regards,
     Sasha
 
From: mpls-bounce= s@ietf.org [mpls-bounces@ietf.org] On Behalf Of Linda Dunbar [ldunbar@huawe= i.com]
Sent: Friday, January 07, 2011 1:21 AM
To: mpls-tp@ietf.org; mpls@ietf.org; 'Dan Frost'; 'Stewart Bryant' Subject: [mpls] Questions on "draft-ietf-mpls-loss-delay-00&quo= t;

Dan and Stewart, <= /font>

I have a few quest= ions and some suggestions on your recent draft:

Section 2 (= Overview)<= font face=3D"Arial">,

      there are several = references of measuring =93packets=94 without<= span lang=3D"en-us"> specifying if the packets = are LM/DM packets or actual data plane packets.= Such Page 7 first paragraph: =93= the count of packets re= ceived prior to time T2 over the cha= nnel from A (B_RxP),=94

      Is this the intent? So that LM can be used to either measuring the LM losses and data plane loss? =

Section 2.7.1 Types of Channels:

      It stated that LM and DM flow over MPLS G-Ach. Since packets over G-Ach might encounter extra processing on intermediat= e nodes, the Delay measured= over G-Ach channel might be slightly different from the data plane channel<= /span>. Will it be a problem?

      [[Sasha]] IMHO packets running over G-ACh SHOULD NOT experience a= ny special processing in the intermediate nodes because GAL (and, by implic= ation G-ACh) will not be exposed to these nodes. However, this is only true if the overall depth of the label st= ack (GAL included) does not exceed the limit on the number of labels these = nodes are ready to treat normally.

      What happens if this limit is exceeded is implementation-specific= and may be as severe as dropping offending packets unconditionally. Other = known cases include ignoring extra labels, slowing down processing etc.

      AFAIK, MPLS-TP development had, so far, ignored this problem. May= be it is high time to recognize it?

       

Section 2.7.6. Los= s Measurement Modes

      Under the= =93direct mode=94, I interpret it as measurin= g the data plane packets, is it correct?

      Counting = data plane packets can be process intensive.  Usually the each node (or line card<= /font>) can only do actual packet counting for limited numbe= r of LSPs. Therefore, I suggest allowing B node to ignore = A node=92s LM when B is not ready to do the counting or send back a reply to indicate the =93not ready status=94.

o  = ;     Several options are possible for the negotiation: egre= ss simply ignore the request when it is not ready, egress sends back an err= or, etc. Ingress node doesn=92t need to start counting traffic until it gets confirmation from the egress node.=

Should allow optio= ns of either byte counter or packet counter.

Thank you very muc= h.

Linda Dunbar

--_000_A3C5DF08D38B6049839A6F553B331C76D6B8336307ILPTMAIL02eci_-- From neil.2.harrison@bt.com Fri Jan 7 00:25:35 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FCA3A67DF; Fri, 7 Jan 2011 00:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeLtwOuvMdgY; Fri, 7 Jan 2011 00:25:29 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 5F0393A67AC; Fri, 7 Jan 2011 00:25:28 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 7 Jan 2011 08:27:34 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.45]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 7 Jan 2011 08:27:34 +0000 From: To: , Date: Fri, 7 Jan 2011 08:27:27 +0000 Thread-Topic: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Thread-Index: Acut+GY8NiB+SQfOSi+H6qHdg0HkpwAPVrOBAANRHhA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44010665838@EMV62-UKRD.domain1.systemhost.net> References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E44010665838EMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org, mpls-tp@ietf.org, stbryant@cisco.com Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 08:25:35 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E44010665838EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, are you only considering sublayering (same layer network instance), = or are you considering both sublayering and layering (different layer netwo= rk instances) wrt depth of label stack (these are technically quite differe= nt cases even though they may look alike in the DP, though a pukka transpor= t network should not have sublayering as I have noted previously)? regards, Neil ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 07 January 2011 06:49 To: Linda Dunbar Cc: 'Stewart Bryant'; mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Linda, Please see my comment inline below. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Linda Dunb= ar [ldunbar@huawei.com] Sent: Friday, January 07, 2011 1:21 AM To: mpls-tp@ietf.org; mpls@ietf.org; 'Dan Frost'; 'Stewart Bryant' Subject: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Dan and Stewart, I have a few questions and some suggestions on your recent draft: Section 2 (Overview), there are several references of measuring "packets" without specifying if t= he packets are LM/DM packets or actual data plane packets. Such Page 7 firs= t paragraph: " the count of packets received prior to time T2 over the chan= nel from A (B_RxP)," Is this the intent? So that LM can be used to either measuring the LM losse= s and data plane loss? Section 2.7.1 Types of Channels: It stated that LM and DM flow over MPLS G-Ach. Since packets over G-Ach mig= ht encounter extra processing on intermediate nodes, the Delay measured ove= r G-Ach channel might be slightly different from the data plane channel. Wi= ll it be a problem? [[Sasha]] IMHO packets running over G-ACh SHOULD NOT experience any special= processing in the intermediate nodes because GAL (and, by implication G-AC= h) will not be exposed to these nodes. However, this is only true if the ov= erall depth of the label stack (GAL included) does not exceed the limit on = the number of labels these nodes are ready to treat normally. What happens if this limit is exceeded is implementation-specific and may b= e as severe as dropping offending packets unconditionally. Other known case= s include ignoring extra labels, slowing down processing etc. AFAIK, MPLS-TP development had, so far, ignored this problem. Maybe it is h= igh time to recognize it? Section 2.7.6. Loss Measurement Modes Under the "direct mode", I interpret it as measuring the data plane packets= , is it correct? Counting data plane packets can be process intensive. Usually the each nod= e (or line card) can only do actual packet counting for limited number of L= SPs. Therefore, I suggest allowing B node to ignore A node's LM when B is n= ot ready to do the counting or send back a reply to indicate the "not ready= status". o Several options are possible for the negotiation: egress simply ign= ore the request when it is not ready, egress sends back an error, etc. Ingr= ess node doesn't need to start counting traffic until it gets confirmation = from the egress node. Should allow options of either byte counter or packet counter. Thank you very much. Linda Dunbar --_000_6D3D47CB84BDE349BC23BF1C94E316E44010665838EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha,=20 are you only considering sublayering (same layer network instance), or = ;are=20 you considering both sublayering and layering (different layer network=20 instances) wrt depth of label stack (these are technically quite different = cases=20 even though they may look alike in the DP, though a pukka transport network= =20 should not have sublayering as I have noted previously)?
 
regards, Neil

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: 07 January 2011 06:49
To: Linda=20 Dunbar
Cc: 'Stewart Bryant'; mpls@ietf.org;=20 mpls-tp@ietf.org
Subject: Re: [mpls] Questions on=20 "draft-ietf-mpls-loss-delay-00"

Linda,
Please see my comment inline=20 below.
 
Regards,
     Sasha=
 
From: mpls-bounces@ietf.org=20 [mpls-bounces@ietf.org] On Behalf Of Linda Dunbar=20 [ldunbar@huawei.com]
Sent: Friday, January 07, 2011 1:21=20 AM
To: mpls-tp@ietf.org; mpls@ietf.org; 'Dan Frost'; 'Stewart=20 Bryant'
Subject: [mpls] Questions on=20 "draft-ietf-mpls-loss-delay-00"

Dan and Stewart,=20

I have a few=20 questions and some=20 suggestions on your=20 recent draft:

Section 2 (Overview= ),

      there are several= =20 references of= =20 measuring<= SPAN=20 lang=3Den-us> “packets”=20 without s<= FONT=20 face=3DArial>pecifying if the packets are LM/DM packets or actual dat= a plane=20 packets. Such Pag= e=20 7 first=20 paragraph: “ the co= unt of=20 packets received prior to time T2 over the channel from A=20 (B_RxP),”

      Is this = the=20 intent? So th= at LM can=20 be used to either measuring the LM losses and data plane loss?=20

Section 2.7.1 Types of Channels:

      It stated that LM and DM<= SPAN=20 lang=3Den-us> flow over MPLS G-Ach. Since packets over G-Ach might= =20 encounter extra processing on intermediate nodes, the Delay=20 measured over G-Ach channel might be slightly different=20 from the<= /FONT>=20 data plane=20 channel. Will it = be a=20 problem?

      [[Sasha]] IMHO packets running over G-ACh SHOULD NOT= =20 experience any special processing in the intermediate nodes because G= AL=20 (and, by implication G-ACh) will not be exposed to these nodes. Howev= er,=20 this is only true if the overall depth of the label stack (GAL=20 included) does not exceed the limit on the number of labels these nod= es=20 are ready to treat normally.

      What happens if this limit is exceeded is=20 implementation-specific and may be as severe as dropping offending pa= ckets=20 unconditionally. Other known cases include ignoring extra labels, slo= wing=20 down processing etc.

      AFAIK, MPLS-TP development had, so far, ignored this= =20 problem. Maybe it is high time to recognize it?

       

Section 2.7.6. Loss Me= asurement=20 Modes

      Under the “direct mode”, I= =20 interpret it as measuring the data plane=20 packets, is it correct?

      Counting data=20 plane packets can be process=20 intensive.  Usu= ally the=20 each node=20 (or line=20 card) can only do actual packet= counting f= or=20 limited number of LSPs. Therefore, I suggest allowing B node to ignore A=20 node’s LM when B is not=20 ready to do the counting=20 or send back a reply to indicate the= “not ready=20 status”.=20

o      <= SPAN=20 lang=3Den-us> Several options are possible for the neg= otiation:=20 egress simply ignore the request when it is not ready, egress sends back = an=20 error, etc. Ingress node doesn’t need to start counting tr= affic until it=20 gets confirmation from the egress node.= =20

Should allow options o= f either=20 byte counter or packet counter.

Thank you very much.=20

Linda Dunbar

--_000_6D3D47CB84BDE349BC23BF1C94E316E44010665838EMV62UKRDdoma_-- From danfrost@cisco.com Fri Jan 7 03:24:36 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA513A681A; Fri, 7 Jan 2011 03:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H15muk7WEqZ5; Fri, 7 Jan 2011 03:24:35 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A7EBB3A67E3; Fri, 7 Jan 2011 03:24:35 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2011 11:26:42 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p07BQg5o020665; Fri, 7 Jan 2011 11:26:42 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p07BQg6Z021025; Fri, 7 Jan 2011 06:26:42 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p07BQfod021024; Fri, 7 Jan 2011 11:26:41 GMT Date: Fri, 7 Jan 2011 11:26:41 +0000 From: Dan Frost To: Linda Dunbar Message-ID: <20110107112641.GA20790@cisco.com> References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002901cbadf8$66783640$790c7c0a@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mpls@ietf.org, 'Stewart Bryant' , mpls-tp@ietf.org Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:24:36 -0000 Hi Linda, On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: > Section 2 (Overview), > there are several references of measuring "packets" without > specifying if the packets are LM/DM packets or actual data plane packets. > Such Page 7 first paragraph: " the count of packets received prior to time > T2 over the channel from A (B_RxP)," > > Is this the intent? So that LM can be used to either > measuring the LM losses and data plane loss? Yes, this is intentional in the overview, because as the rest of the document makes clear, several options for what exactly to measure exist. > Section 2.7.1 Types of Channels: > It stated that LM and DM flow over MPLS G-Ach. Since packets > over G-Ach might encounter extra processing on intermediate nodes, the Delay > measured over G-Ach channel might be slightly different from the data plane > channel. Will it be a problem? If a node is truly intermediate and not itself the target of the measurement operation, I see no reason why the packet would "encounter extra processing" there, any more than any other packet label-switched through the node. > Section 2.7.6. Loss Measurement Modes > Under the "direct mode", I interpret it as measuring the > data plane packets, is it correct? Yes. This is the meaning of the definition in the text: If the counted packets are the packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode". > Counting data plane packets can be process intensive. > Usually the each node (or line card) can only do actual packet counting for > limited number of LSPs. Therefore, I suggest allowing B node to ignore A > node's LM when B is not ready to do the counting or send back a reply to > indicate the "not ready status". > > o Several options are possible for the negotiation: egress simply > ignore the request when it is not ready, egress sends back an error, etc. > Ingress node doesn't need to start counting traffic until it gets > confirmation from the egress node. Indeed, and the last paragraph of Section 4.1.1 says as much. This was added as a result of our discussion. > Should allow options of either byte counter or packet counter. This is also in the text; see Section 1, the last paragraph of Section 2.1, and the 'B' data format flag (DFlag) in Section 3.1. > Thank you very much. Thanks for your review! -d > Linda Dunbar From Internet-Drafts@ietf.org Fri Jan 7 06:45:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FB83A68E8; Fri, 7 Jan 2011 06:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lsgRz5iQcKS; Fri, 7 Jan 2011 06:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E8E3A68DD; Fri, 7 Jan 2011 06:45:01 -0800 (PST) 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.10 Message-ID: <20110107144501.19461.76573.idtracker@localhost> Date: Fri, 07 Jan 2011 06:45:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-uni-nni-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile User-to-Network and Network-to-Network Interfaces Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-uni-nni-03.txt Pages : 7 Date : 2011-01-07 The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) transport service interfaces, which are a User-to-Network Interface (UNI), and an MPLS-TP Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI. 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 Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-uni-nni-03.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-mpls-tp-uni-nni-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07064052.I-D@ietf.org> --NextPart-- From adrian@olddog.co.uk Fri Jan 7 12:22:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E21E3A6959; Fri, 7 Jan 2011 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl+EnJAUkaA2; Fri, 7 Jan 2011 12:22:02 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by core3.amsl.com (Postfix) with ESMTP id F00963A6973; Fri, 7 Jan 2011 12:21:49 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p07KNlT8000965; Fri, 7 Jan 2011 20:23:47 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p07KNkDb000957; Fri, 7 Jan 2011 20:23:46 GMT From: "Adrian Farrel" To: "'Alexander Vainshtein'" , "'Linda Dunbar'" References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> In-Reply-To: Date: Fri, 7 Jan 2011 20:23:43 -0000 Message-ID: <0bbf01cbaea8$c7e714e0$57b53ea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQIlvlBV59Kxf6Q5WY9TKG4IStLt2wIG6rkpkwGboKA= Cc: mpls@ietf.org, mpls-tp@ietf.org, 'Stewart Bryant' Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:22:04 -0000 Hi Sasha, [Major snipping - and conversion to plain text] > [[Sasha]] IMHO packets running over G-ACh SHOULD NOT experience any > special processing in the intermediate nodes because GAL (and, by implication > G-ACh) will not be exposed to these nodes. However, this is only true if the > overall depth of the label stack (GAL included) does not exceed the limit on > the number of labels these nodes are ready to treat normally. > What happens if this limit is exceeded is implementation-specific and may > be as severe as dropping offending packets unconditionally. Other known > cases include ignoring extra labels, slowing down processing etc. > > AFAIK, MPLS-TP development had, so far, ignored this problem. Maybe it > is high time to recognize it? There seems (to me) to be a contradiction in what you say. You say that the GAL is not exposed at intermediate nodes (I agree), but you imply that the change in the label stack depth will be noticed at the intermediate nodes. AFAICS, this would only happen on boxes doing DPI (stay calm, Neil!), and frankly those boxes *do* "expose" the GAL. Can you help me by explaining how a transit node could suffer from the increase the number of labels that a transit node has to "treat normally"? Thanks, Adrian From ldunbar@huawei.com Fri Jan 7 15:03:41 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09E03A68C5; Fri, 7 Jan 2011 15:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.041 X-Spam-Level: X-Spam-Status: No, score=-106.041 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkLt56phjzX3; Fri, 7 Jan 2011 15:03:33 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 33D2D28C15D; Fri, 7 Jan 2011 15:02:56 -0800 (PST) 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 <0LEO001TYDGDSJ@usaga02-in.huawei.com>; Fri, 07 Jan 2011 15:05:02 -0800 (PST) Received: from L735042 ([10.124.12.121]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEO00E43DGDAP@usaga02-in.huawei.com>; Fri, 07 Jan 2011 15:05:01 -0800 (PST) Date: Fri, 07 Jan 2011 17:05:00 -0600 From: Linda Dunbar In-reply-to: <20110107112641.GA20790@cisco.com> To: 'Dan Frost' Message-id: <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_eVeDEc+zwdtLwBitSOnugg)" Thread-index: AcuuXdIVgul8EEmhSnuJvY/GqCq6BgAXchGA References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> Cc: mpls@ietf.org, 'Stewart Bryant' , mpls-tp@ietf.org Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:03:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eVeDEc+zwdtLwBitSOnugg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dan, Thank you very much for the reply. As for Section 4.1.1, may I suggest some wording changes (in blue)? When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation, for example by stopping sending LMs after X (e.g. 3) number of LMs being sent without positive feedback. The initial LM interval before any response being received could be longer than normal to minimize the querier's resource consumption. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier should delay counting its transmitted packets until receiving a positive feedback from the far-end. Another comment: I think the document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher the processing loads on line cards. Therefore, it is necessary to describe the minimum (and maximum) intervals for LM/DM in the draft, and specifying the unit (like ms or second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format. Since the processing capability on the initiating node (the querier) and the far end (receiving) node could be different, the receiver (far end node) may indicate in the response a minimum interval it can support and the querier may adjust the LM interval to any desired value greater than that. Therefore, the interval value should be encoded in the LM/DM message. I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval and add a field in the message for interval. Linda Dunbar -----Original Message----- From: Dan Frost [mailto:danfrost@cisco.com] Sent: Friday, January 07, 2011 5:27 AM To: Linda Dunbar Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" Hi Linda, On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: > Section 2 (Overview), > there are several references of measuring "packets" without > specifying if the packets are LM/DM packets or actual data plane packets. > Such Page 7 first paragraph: " the count of packets received prior to time > T2 over the channel from A (B_RxP)," > > Is this the intent? So that LM can be used to either > measuring the LM losses and data plane loss? Yes, this is intentional in the overview, because as the rest of the document makes clear, several options for what exactly to measure exist. > Section 2.7.1 Types of Channels: > It stated that LM and DM flow over MPLS G-Ach. Since packets > over G-Ach might encounter extra processing on intermediate nodes, the Delay > measured over G-Ach channel might be slightly different from the data plane > channel. Will it be a problem? If a node is truly intermediate and not itself the target of the measurement operation, I see no reason why the packet would "encounter extra processing" there, any more than any other packet label-switched through the node. > Section 2.7.6. Loss Measurement Modes > Under the "direct mode", I interpret it as measuring the > data plane packets, is it correct? Yes. This is the meaning of the definition in the text: If the counted packets are the packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode". > Counting data plane packets can be process intensive. > Usually the each node (or line card) can only do actual packet counting for > limited number of LSPs. Therefore, I suggest allowing B node to ignore A > node's LM when B is not ready to do the counting or send back a reply to > indicate the "not ready status". > > o Several options are possible for the negotiation: egress simply > ignore the request when it is not ready, egress sends back an error, etc. > Ingress node doesn't need to start counting traffic until it gets > confirmation from the egress node. Indeed, and the last paragraph of Section 4.1.1 says as much. This was added as a result of our discussion. > Should allow options of either byte counter or packet counter. This is also in the text; see Section 1, the last paragraph of Section 2.1, and the 'B' data format flag (DFlag) in Section 3.1. > Thank you very much. Thanks for your review! -d > Linda Dunbar --Boundary_(ID_eVeDEc+zwdtLwBitSOnugg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: Questions on = "draft-ietf-mpls-loss-delay-00"

Dan, =

Thank you very much for the = reply.

As for = Section 4.1.1, may I suggest some = wording changes (in blue)?

          When initiating an LM operation, the far end may require a period of time to become = ready for the requested measurement operation or the far end may not be able to support the = requested measurement. = During this = period Under those circumstances, LM queries MAY simply be discarded, and the = querier expecting a response SHOULD be = prepared for this situation, for example by stopping sending LMs after X (e.g. 3) number = of LMs being sent without positive feedback. The initial LM = interval before = any response being received could be longer than normal to minimize the = querier’s resource consumption. = setting a timer to differentiate between = an acceptable initialization delay and a permanent unavailability = condition at the far end. Alternatively, the receiver MAY respond, possibly in a = rate-limited manner, to queries = received during this period with an appropriate notification = code. Since = counting transmitted packets at querier side will cost extra resources = (or is not free), the querier should delay = counting its transmitted packets until receiving a positive feedback from the = far-end. =

Another comment: =

      I think the = document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher = the processing = loads on = line cards. Therefore, it is necessary to describe = the minimum (and maximum) intervals for LM/DM in the = draft, and specifying the unit (like ms = or second). IEEE802.ag specifies = its CCM’s minimum = interval to be 3ms. To optimize the = bits = utilization, IEEE802.1Qbg uses 2x format.

      Since = the processing capability on = the initiating node (the = querier) = and the far end (receiving) node could = be different, the receiver (far end node) may = indicate in the response a minimum interval it can support and = the querier may adjust the LM interval to = any desired value greater than that. Therefore, the interval = value = should be encoded in the LM/DM = message.

      I suggest = adding a = section (e.g. 2.7.10) to = describe the LM/DM interval and add a field in the message for = interval.

Linda = Dunbar

-----Original Message-----
From: Dan Frost [mailto:danfrost@cisco.com]
Sent: Friday, January 07, 2011 5:27 AM
To: = Linda Dunbar
Cc: = mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant'
Subject: Re: Questions on = "draft-ietf-mpls-loss-delay-00"

Hi = Linda,

On Thu, Jan = 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote:

> = Section 2 (Overview), =

> =       =         there are several references = of measuring "packets" without

> = specifying if the packets are LM/DM packets or actual data plane = packets.

> Such = Page 7 first paragraph: " the count of packets received prior to = time

> T2 = over the channel from A (B_RxP),"

> =

> =       =         Is this the intent? So that = LM can be used to either

> = measuring the LM losses and data plane loss?

Yes, this = is intentional in the overview, because as the rest of = the

document = makes clear, several options for what = exactly to measure exist.

> = Section 2.7.1 Types of Channels:

> =       =         It stated that LM and DM flow = over MPLS G-Ach. Since packets

> over = G-Ach might encounter extra processing on intermediate nodes, the = Delay

> = measured over G-Ach channel might be slightly different from the data plane

> = channel. Will it be a problem?

If a node = is truly intermediate and not itself the target of the

measurement = operation, I see no reason why the packet would = "encounter

extra = processing" there, any more than any other packet label-switched

through the = node.

> = Section 2.7.6. Loss Measurement Modes

> =       =         Under the "direct = mode", I interpret it as measuring the

> data = plane packets, is it correct?

Yes.  = This is the meaning of the definition in the text:

   If the counted = packets are the packets flowing over the channel in = the

   data plane, the loss measurement is said to operate in = "direct mode".

> =       =         Counting data plane packets = can be process intensive.

> = Usually the each node (or line card) can only do actual packet counting = for

> = limited number of LSPs. Therefore, I suggest allowing B node to ignore = A

> node's = LM when B is not ready to do the counting or send back a reply = to

> = indicate the "not ready status".

> =

> = o     Several options are possible for the = negotiation: egress simply

> ignore = the request when it is not ready, egress sends back an error, = etc.

> = Ingress node doesn't need to start counting traffic until it = gets

> = confirmation from the egress node. =

Indeed, and = the last paragraph of Section 4.1.1 says as much.  This = was

added as a = result of our discussion.

> Should = allow options of either byte counter or packet counter. =

This is = also in the text; see Section 1, the last paragraph of = Section

2.1, and the 'B' data format flag = (DFlag) in Section 3.1.

> Thank = you very much.

Thanks for = your review!

-d

> Linda = Dunbar

= --Boundary_(ID_eVeDEc+zwdtLwBitSOnugg)-- From lamberto.sterling@gmail.com Sat Jan 8 08:17:36 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175F128C15D; Sat, 8 Jan 2011 08:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ade8vFNuEYDu; Sat, 8 Jan 2011 08:17:35 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 43F6A28C12F; Sat, 8 Jan 2011 08:17:32 -0800 (PST) Received: by mail-bw0-f44.google.com with SMTP id 12so17996019bwz.31 for ; Sat, 08 Jan 2011 08:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nNTLDKsCY60mvWe8iOKe6vpGtFWI7JNpuZ0M8VgWtfk=; b=l6UwYNF3eFnwLLLSqvMIsocjsyhplojA1IAb6E94blboZdx2KPNRwlCidpN+H+qQOW GUSWRN+CAjKECAIrfuJpJR3QHys/sIfjzVSk8UXOuxXxAI2on8ZhrtiK547MQXe154J5 qTVJ2MUwQXWJUH9Rj3599I677ncwdR6499r2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W6OvOfLzmWw3IYW/bLCcfUAVD2UgW8BEm82WilG7q5c/s9+46oSHnxgZf9Q36Xrjyj PpBjXwTL87G+MqPqfZPA8q6IF++o/k/lC/qROc+zoYUMd+Yig2L1CisGGJVA7lMLedsW Mgb2FueGLqYO8mZgIBT9xBH4b/JlC8Kc7ywCA= MIME-Version: 1.0 Received: by 10.204.52.134 with SMTP id i6mr20080302bkg.36.1294503579241; Sat, 08 Jan 2011 08:19:39 -0800 (PST) Received: by 10.204.98.204 with HTTP; Sat, 8 Jan 2011 08:19:39 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Jan 2011 00:19:39 +0800 Message-ID: From: Lamberto Sterling To: maillist.ed@gmail.com, lizhong.jin@zte.com.cn Content-Type: multipart/alternative; boundary=001636c5bfdd004dd00499581a94 Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , tictoc@ietf.org, N.Leymann@telekom.de Subject: Re: [mpls] mpls Digest, Vol 81, Issue 4 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:17:36 -0000 --001636c5bfdd004dd00499581a94 Content-Type: text/plain; charset=ISO-8859-1 Hi Lizhong, Edward, It seems that it is a good idea to apply HSMP LSP to VPLS, and the broadcast/unicast/unknow packet would be optimized. However, the path from leaf to root may not be the best path compared with current VPLS using P2P LSP, which is not a critical issue. Thanks Lamberto > > ------------------------------ > > Date: Wed, 5 Jan 2011 15:50:45 +0800 > From: lizhong.jin@zte.com.cn > Subject: Re: [mpls] Request comments for HSMP LSP > To: Ed > Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , > N.Leymann@telekom.de, tictoc@ietf.org > Message-ID: > < > OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn> > Content-Type: text/plain; charset="us-ascii" > > Hi Edward, > Thank you for the comments. I add l2vpn maillist in cc list. I agree with > the application you proposed, and in order to improve the scalability of > VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually > this is a good application case for P2MP PW with reverse path (section > 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this > use case. > > Regards > Lizhong > > > Ed wrote on 2011-01-05 15:05:30: > > > Hi Lizhong, > > > > I think one possible application for HSMP LSPs is to reduce the > > overall broadcast/multicast utilization on a VPLS. In current VPLS > > implementations with a full mesh of P2P LSPs between PEs, broadcast, > > multicast and unknown traffic are not efficiently propagated on the > > physical links between PEs and Ps. > > > > In the VPLS implementation scenario with HSMP LSPs, each PE signals > > a HSMP LSP with itself as a root to all other PEs in the VPLS. > > Thereafter, all broadcast/multicast/unknown traffic from this PE > > will use this HSMP LSP. Unicast traffic from a particular PE (e.g. > > PE1) to another PE (e.g. PE2) will be sent from leaf to root using > > the HSMP LSP where PE2 is the root. > > > > This simplifies the VPLS implementation by: > > - Reducing traffic utilization from broadcast, multicast > > and unknown traffic > > - Reducing the total number of LSPs maintained by each PE > > (i.e. instead of requiring a full mesh of LSPs, now only require one > > HSMP LSP per PE). > > > > This is similar to the idea expressed in draft-key-l2vpn-etree- > > frwk-03.txt (in a more general sense). > > > > What do you think? Would HSMP LSP be suitable for this? > > > > Regards, > > Edward > > > > > > > > On Wed, Jan 5, 2011 at 5:24 PM, wrote: > > > > Hi all, > > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS > session. > > HSMP LSP has several use cases described in the draft, e.g, time > > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would > > be appreciated if you could give more scenarios for HSMP LSP. Please > > review the draft, and any comments are welcome. > > > > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls- > > mldp-hsmp-01 > > > > Thank you. > > Authors of draft-hsmp. > > -------------------------------------------------------- > > --001636c5bfdd004dd00499581a94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Lizhong, Edward,
It seems that it is a good idea to apply HSMP LSP to VPLS, and the bro= adcast/unicast/unknow packet would be optimized.=A0However, the path from l= eaf to root may not be the best path compared with current VPLS using P2P L= SP, which is not a critical issue.
=A0
Thanks
Lamberto

=A0

----------------------------= --

Date: Wed, 5 Jan 2011 15:50:45 +0800
From: lizhong.jin@zte.com.cn
Subject: Re: [mpls] Request comments for HSMP LSP
To: Ed <maillist.ed@gmail.com>
Cc: l2vpn@ietf.org, mpls@ietf.org, Ice <ice@cisco.= com>,
=A0 =A0 =A0 =A0N.Leymann@telekom.de= , =A0 tictoc@ietf.org
Message= -ID:
=A0 =A0 =A0 =A0<OF4BA0BF75.A883E04C-ON4825780F.0028= 02E4-4825780F.002B2AB9@zte.com.cn>
Content-Type: text/plain; charset=3D"us-ascii"

Hi Edward,<= br>Thank you for the comments. I add l2vpn maillist in cc list. I agree wit= h
the application you proposed, and in order to improve the scalability = of
VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually
t= his is a good application case for P2MP PW with reverse path (section
4.= 4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
use case.

Regards
Lizhong


Ed <maillist.ed@gmail.com> wrote on 2011-01-05 15:05= :30:

> Hi Lizhong,
>
> I think one possible applicati= on for HSMP LSPs is to reduce the
> overall broadcast/multicast utilization on a VPLS. In current VPLS
= > implementations with a full mesh of P2P LSPs between PEs, broadcast,> multicast and unknown traffic are not efficiently propagated on the<= br> > physical links between PEs and Ps.
>
> In the VPLS impleme= ntation scenario with HSMP LSPs, each PE signals
> a HSMP LSP with it= self as a root to all other PEs in the VPLS.
> Thereafter, all broadc= ast/multicast/unknown traffic from this PE
> will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
= > PE1) to another PE (e.g. PE2) will be sent from leaf to root using
= > the HSMP LSP where PE2 is the root.
>
> This simplifies th= e VPLS implementation by:
> - =A0 =A0 =A0 =A0 =A0Reducing traffic utilization from broadcast, mult= icast
> and unknown traffic
> - =A0 =A0 =A0 =A0 =A0Reducing the= total number of LSPs maintained by each PE
> (i.e. instead of requir= ing a full mesh of LSPs, now only require one
> HSMP LSP per PE).
>
> This is similar to the idea expresse= d in =A0draft-key-l2vpn-etree-
> frwk-03.txt (in a more general sense= ).
>
> What do you think? Would HSMP LSP be suitable for this?<= br> >
> Regards,
> Edward
>
>
>
> On Wed= , Jan 5, 2011 at 5:24 PM, <liz= hong.jin@zte.com.cn> wrote:
>
> Hi all,
> During I= ETF 79 Beijing, we made a presentation for HSMP LSP at MPLS
session.
> HSMP LSP has several use cases described in the draft, e.g= , time
> synchronization in MPLS network, IPTV scenario, or P2MP PW. = It would
> be appreciated if you could give more scenarios for HSMP L= SP. Please
> review the draft, and any comments are welcome.
>
> The dr= aft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> mldp-hsmp-01
>
> Thank you.
> Authors of draft-hsmp.=
> --------------------------------------------------------
>
--001636c5bfdd004dd00499581a94-- From stbryant@cisco.com Sat Jan 8 08:30:29 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70C828C116 for ; Sat, 8 Jan 2011 08:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6VIcV830fpv for ; Sat, 8 Jan 2011 08:30:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 213AC28C11D for ; Sat, 8 Jan 2011 08:30:29 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF4gKE1AZnwM/2dsb2JhbACkQ3OjI4JQDgGVAIVMBIsKgzo Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jan 2011 16:32:37 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p08GWaQi029127 for ; Sat, 8 Jan 2011 16:32:36 GMT Received: from unknown-f8-1e-df-e1-e1-6c.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p08GWY811520; Sat, 8 Jan 2011 16:32:35 GMT Message-ID: <4D2891A2.4070503@cisco.com> Date: Sat, 08 Jan 2011 16:32:34 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Review request for ITU-T Draft Recommendation G.8110.1/Y.1370.1 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:30:30 -0000 Please can I draw the attention of the MPLS WG to the request by ITU-T to provide comments on Draft revised ITU-T Recommendation G.8110.1/Y.1370.1- Architecture of MPLS Transport Profile (MPLS-TP) layer network. This can be found at: https://datatracker.ietf.org/documents/LIAISON/file1155.pdf Regards Stewart From gregimirsky@gmail.com Sat Jan 8 13:41:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4676B28C0EF; Sat, 8 Jan 2011 13:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKMsWsdo4MA1; Sat, 8 Jan 2011 13:41:57 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 428B23A683E; Sat, 8 Jan 2011 13:41:54 -0800 (PST) Received: by vws7 with SMTP id 7so7415616vws.31 for ; Sat, 08 Jan 2011 13:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XicBjZVXGD9zWrLb2JTEwAmsuSV3Y6nrX6WE9apKDlQ=; b=c3xtIaO4Amy8tfmsbSKb+iGYvshJGPl0GCB9R/IaYT02TTBOkMUeYxqjX0RrBsl8OD rkd0QiEAHmkdfNlccxSmjR0swPQY0sFaZtlAr8J5ZCyiOHROlWudAmTe5mmBhnmulu4c OPA54NCK/j48QYdOL1HKnZTKhma+STuJ1lzao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hZex/9AxD0xlTFCFCOFnQdzfHHdPYvbefN048DE6P/vQPbqZb5tP2+0NBCjhR0v4hu hlv5UIbuP7dLDC0HBOrSbmLy+LtTXsdyH8isGD0Dve2NQ3+tBTGNr8/p5ZkWtevX4p0I S0AwEyJwNi+djN7quk29YOvoL3d4RGS1VAHk8= MIME-Version: 1.0 Received: by 10.220.193.131 with SMTP id du3mr5356869vcb.118.1294523042013; Sat, 08 Jan 2011 13:44:02 -0800 (PST) Received: by 10.220.103.4 with HTTP; Sat, 8 Jan 2011 13:44:01 -0800 (PST) In-Reply-To: <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> Date: Sat, 8 Jan 2011 13:44:01 -0800 Message-ID: From: Greg Mirsky To: Linda Dunbar Content-Type: multipart/alternative; boundary=e0cb4e3857a412a33504995ca2fb Cc: mpls@ietf.org, mpls-tp@ietf.org, Stewart Bryant Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:41:59 -0000 --e0cb4e3857a412a33504995ca2fb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Linda, I think that specifying particular minimum interval might become too restrictive when higher bandwidth links become available. Regards, Greg On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar wrote: > Dan, > > Thank you very much for the reply. > > As for Section 4.1.1, may I suggest some wording changes (in blue)? > > When initiating an LM operation, the far end may require a period of > time to become ready for the requested measurement operation = or > the far end may not be able to support the requested measurem= ent > . During this period Under those circumstances, LM queries MA= Y > simply be discarded, and the querier expecting a response > SHOULD be prepared for this situation, for example by stoppin= g > sending LMs after X (e.g. 3) number of LMs being sent without= positive > feedback. The initial LM interval before any response being r= eceived > could be longer than normal to minimize the querier=92s resou= rce > consumption. setting a timer to differentiate between an > acceptable initialization delay and a permanent unavailabilit= y condition at > the far end. Alternatively, the receiver MAY respond, possibl= y > in a rate-limited manner, to queries received during this > period with an appropriate notification code. Since counting > transmitted packets at querier side will cost extra resources= (or is not > free), the querier should delay counting its transmitted > packets until receiving a positive feedback from the far-end. > > Another comment: > > I think the document should add a description on the range of allowed > LM/DM intervals. The shorter the interval, the higher the processin= g > loads on line cards. Therefore, it is necessary to describe the > minimum (and maximum) intervals for LM/DM in the draft, andspecifyi= ng the unit (like ms or second) > . IEEE802.ag specifies its CCM=92s minimum interval to be 3ms. To > optimize the bits utilization, IEEE802.1Qbg uses 2x format. > > Since the processing capability on the initiating node (the querier= )and the far end (receiving) nodecould be different > , the receiver (far end node) may indicate in the response a minimu= m > interval it can support and the querier may adjust the LM interval > to any desired value greater than that. Therefore, the interval > value should be encoded in the LM/DM message. > > I suggest adding a section (e.g. 2.7.10) to describe the LM/DM > interval and add a field in the message for interval. > > Linda Dunbar > > -----Original Message----- > From: Dan Frost [mailto:danfrost@cisco.com ] > Sent: Friday, January 07, 2011 5:27 AM > To: Linda Dunbar > Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' > Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" > > Hi Linda, > > On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: > > > Section 2 (Overview), > > > there are several references of measuring "packets" witho= ut > > > specifying if the packets are LM/DM packets or actual data plane packet= s. > > > Such Page 7 first paragraph: " the count of packets received prior to > time > > > T2 over the channel from A (B_RxP)," > > > > > > Is this the intent? So that LM can be used to either > > > measuring the LM losses and data plane loss? > > Yes, this is intentional in the overview, because as the rest of the > > document makes clear, several options for what exactly to measure exist. > > > Section 2.7.1 Types of Channels: > > > It stated that LM and DM flow over MPLS G-Ach. Since > packets > > > over G-Ach might encounter extra processing on intermediate nodes, the > Delay > > > measured over G-Ach channel might be slightly different from the data > plane > > > channel. Will it be a problem? > > If a node is truly intermediate and not itself the target of the > > measurement operation, I see no reason why the packet would "encounter > > extra processing" there, any more than any other packet label-switched > > through the node. > > > Section 2.7.6. Loss Measurement Modes > > > Under the "direct mode", I interpret it as measuring the > > > data plane packets, is it correct? > > Yes. This is the meaning of the definition in the text: > > If the counted packets are the packets flowing over the channel in the > > data plane, the loss measurement is said to operate in "direct mode". > > > Counting data plane packets can be process intensive. > > > Usually the each node (or line card) can only do actual packet counting > for > > > limited number of LSPs. Therefore, I suggest allowing B node to ignore = A > > > node's LM when B is not ready to do the counting or send back a reply t= o > > > indicate the "not ready status". > > > > > > o Several options are possible for the negotiation: egress simply > > > ignore the request when it is not ready, egress sends back an error, et= c. > > > Ingress node doesn't need to start counting traffic until it gets > > > confirmation from the egress node. > > Indeed, and the last paragraph of Section 4.1.1 says as much. This was > > added as a result of our discussion. > > > Should allow options of either byte counter or packet counter. > > This is also in the text; see Section 1, the last paragraph of Section > > 2.1, and the 'B' data format flag (DFlag) in Section 3.1. > > > Thank you very much. > > Thanks for your review! > > -d > > > Linda Dunbar > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --e0cb4e3857a412a33504995ca2fb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Linda,
I think that specifying particular minimum interval might be= come too restrictive when higher bandwidth links become available.

R= egards,
Greg

On Fri, Jan 7, 2011 at 3:= 05 PM, Linda Dunbar <ldunbar@huawei.com> wrote:

Dan, =

Thank= you very much for the reply.

As for Secti= on 4.1.1, may I suggest some wording chan= ges (in blue)= ?

          When initiating an LM op= eration, the far end may require a= period of time to become ready for the requested measurement operation or the far end may not be able to supp= ort the requested measurement. During this period<= /font> Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared fo= r this situation, for example by<= span lang=3D"en-us"> st= opping sending LMs after X (e.g. 3) number of LMs being sent without positi= ve feedback.= = The initial LM interval before any response<= span lang=3D"en-us"> be= ing received could be longer than normal to minimiz= e the querier=92= s resource consu= mption. setting a timer to differentiate between an acceptable initialization del= ay and a permanent unavailability condition at the far end<= /span>.= Alternatively, the = receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appro= priate notification code. Since cou= nting transmitted packets at querier side will cost extra resources (or is = not free), the querier should delay counting its transmitted packets until receiving a positive feedb= ack from the far-end.

Another comment:

      I think the = document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher the processing loads on line cards.= Therefore, it is necessary to de= scribe the minimum<= /span> (and maximum) intervals for LM/DM in the draft, = and specifying the unit (li= ke ms or second). IEEE80= 2.ag spec= ifies its CC= M=92s<= /font> minimum inter= val t<= font face=3D"Courier New">o be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format.

      Since the processing capability on the initiating node (the querier) and the far end (receiving) node could be different, the receiver (fa= r end node) may indicate in the response a minimum interval it can support = and the querier may adjust the LM interval to any desired value gre= ater than that. Therefore,= the interval value should be encoded in the LM/DM message.

      I suggest ad= ding a section (e.g. 2.7.10) to describe the LM/DM interval and add a field in the message for = interval.

Linda Dunbar=

-----Origina= l Message-----
From: D= an Frost [mailto:da= nfrost@cisco.com]
Sent: F= riday, January 07, 2011 5:27 AM
To: Lin= da Dunbar
Cc: mpls-tp@ietf.org; mpls@ietf.org; 'St= ewart Bryant'
Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00"<= span lang=3D"en-us">

Hi Linda,

On Thu, Jan = 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote:

> Section= 2 (Overview),

> =A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 there are several references of measuring &= quot;packets" without

> specify= ing if the packets are LM/DM packets or actual data plane packets.

> Such Pa= ge 7 first paragraph: " the count of packets received prior to time

> T2 over= the channel from A (B_RxP),"

> =

> =A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Is this the intent? So that LM can be used = to either

> measuri= ng the LM losses and data plane loss?

Yes, this is= intentional in the overview, because as the rest of the

document mak= es clear, several options for what exactl= y to measure exist.

> Section= 2.7.1 Types of Channels:

> =A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 It stated that LM and DM flow over MPLS G-A= ch. Since packets

> over G-= Ach might encounter extra processing on intermediate nodes, the Delay

> measure= d over G-Ach channel might be slightly di= fferent from the data plane

> channel= . Will it be a problem?

If a node is= truly intermediate and not itself the target of the

measurement = operation, I see no reason why the packet would "encounter

extra proces= sing" there, any more than any other= packet label-switched

through the = node.

> Section= 2.7.6. Loss Measurement Modes

> =A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Under the "direct mode", I interp= ret it as measuring the

> data pl= ane packets, is it correct?

Yes.=A0 This= is the meaning of the definition in the text:

=A0=A0 If th= e counted packets are the packets flowing= over the channel in the

=A0=A0 data = plane, the loss measurement is said to operate in "direct mode".<= /font>

> =A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Counting data plane packets can be process = intensive.

> Usually= the each node (or line card) can only do actual packet counting for=

> limited= number of LSPs. Therefore, I suggest allowing B node to ignore A

> node= 9;s LM when B is not ready to do the counting or send back a reply to

> indicat= e the "not ready status".

> =

> o=A0=A0= =A0=A0 Several options are possible for the negotiation: egress simply

> ignore = the request when it is not ready, egress sends back an error, etc.

> Ingress= node doesn't need to start counting traffic until it gets

> confirm= ation from the egress node.

Indeed, and = the last paragraph of Section 4.1.1 says as much.=A0 This was=

added as a r= esult of our discussion.

> Should = allow options of either byte counter or packet counter.

This is also= in the text; see Section 1, the last paragraph of Section

2.1, and the 'B' data format flag (DFlag) in = Section 3.1.

> Thank y= ou very much.

Thanks for y= our review!

-d

> Linda D= unbar


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


--e0cb4e3857a412a33504995ca2fb-- From ben@niven-jenkins.co.uk Sat Jan 8 14:50:53 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392543A68C8; Sat, 8 Jan 2011 14:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjfG8WcdgMf3; Sat, 8 Jan 2011 14:50:52 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id A32183A68BD; Sat, 8 Jan 2011 14:50:51 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.205]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pbhec-0004cF-SU; Sat, 08 Jan 2011 22:52:59 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Sat, 8 Jan 2011 22:52:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9BCECFE9-04D8-4E8F-A01A-55D76C0E64C9@niven-jenkins.co.uk> References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> To: Greg Mirsky X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:50:53 -0000 Linda, colleagues, 4 comments: 1) The edits suggested by Linda change the semantics from suggesting a = querier maintain a timer to allow for the receiving end to "get its act = together" to if the receiving end doesn't get its act together within X = packets stop sending LM. Is that really what's intended? I would expect = the time taken for the receiving end "to get its act together" would not = be a function of the LM transmission rate and therefore using = transmission rate to guess whether the receiving end is dead Vs getting = itself ready doesn't sound sensible. 2) I don't like the final sentence suggesting queriers should delay = counting transmitted packets until receiving a positive response because = doing so costs resources. It sounds like an internal implementation = decision that has nothing to do with interoperability and therefore = irrelevant. 3) I am not sure of the value of specifically calling out = minimum/maximum intervals in the draft. Section 2.1 already describes = how to calculate theoretical min/max values as a function of counter = size, packet size & link speed, further restricting the set to specific = numbers doesn't seem helpful. On 8 Jan 2011, at 21:44, Greg Mirsky wrote: 4) Giving the receiving end the opportunity to reply with "I can;t = support the rate you're asking for it's too fast for me" sounds = attractive but I am not sure it is in practice if one thinks how such = functionality is likely to be used. If an operator is going to turn it = on with the thinking that performing LM of some sort is important = regardless of the LM interval then negotiating a shorter interval may = have value. However I don't expect that to be the case. I would expect = an operator to pre-plan what interval they need given their knowledge of = their network and the accuracy they desire, having the network change = that may well cause unexpected consequences. In such a scenario I think = it's better to let the receiver "hard fail" and the operator can = investigate rather than have the network re-configure and the = re-configuration go unnoticed, after all LM failing does not impact the = ability of the network to actually forward packets. Ben > Dear Linda, > I think that specifying particular minimum interval might become too = restrictive when higher bandwidth links become available. >=20 > Regards, > Greg >=20 > On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar = wrote: > Dan, >=20 > Thank you very much for the reply. >=20 > As for Section 4.1.1, may I suggest some wording changes (in blue)? >=20 > When initiating an LM operation, the far end may require a period of = time to become ready for the requested measurement operation or the far = end may not be able to support the requested measurement. During this = period Under those circumstances, LM queries MAY simply be discarded, = and the querier expecting a response SHOULD be prepared for this = situation, for example by stopping sending LMs after X (e.g. 3) number = of LMs being sent without positive feedback. The initial LM interval = before any response being received could be longer than normal to = minimize the querier=92s resource consumption. setting a timer to = differentiate between an acceptable initialization delay and a permanent = unavailability condition at the far end. Alternatively, the receiver MAY = respond, possibly in a rate-limited manner, to queries received during = this period with an appropriate notification code. Since counting = transmitted packets at querier side will cost extra resources (or is not = free), the querier should delay counting its transmitted packets until = receiving a positive feedback from the far-end. >=20 >=20 > Another comment: >=20 > I think the document should add a description on the range of allowed = LM/DM intervals. The shorter the interval, the higher the processing = loads on line cards. Therefore, it is necessary to describe the minimum = (and maximum) intervals for LM/DM in the draft, and specifying the unit = (like ms or second). IEEE802.ag specifies its CCM=92s minimum interval = to be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x = format. >=20 > Since the processing capability on the initiating node (the querier) = and the far end (receiving) node could be different, the receiver (far = end node) may indicate in the response a minimum interval it can support = and the querier may adjust the LM interval to any desired value greater = than that. Therefore, the interval value should be encoded in the LM/DM = message. >=20 > I suggest adding a section (e.g. 2.7.10) to describe the LM/DM = interval and add a field in the message for interval. >=20 >=20 > Linda Dunbar >=20 >=20 > -----Original Message----- > From: Dan Frost [mailto:danfrost@cisco.com] > Sent: Friday, January 07, 2011 5:27 AM > To: Linda Dunbar > Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' > Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" >=20 > Hi Linda, >=20 > On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: >=20 > > Section 2 (Overview), >=20 > > there are several references of measuring "packets" = without >=20 > > specifying if the packets are LM/DM packets or actual data plane = packets. >=20 > > Such Page 7 first paragraph: " the count of packets received prior = to time >=20 > > T2 over the channel from A (B_RxP)," >=20 > > >=20 > > Is this the intent? So that LM can be used to either >=20 > > measuring the LM losses and data plane loss? >=20 > Yes, this is intentional in the overview, because as the rest of the >=20 > document makes clear, several options for what exactly to measure = exist. >=20 > > Section 2.7.1 Types of Channels: >=20 > > It stated that LM and DM flow over MPLS G-Ach. Since = packets >=20 > > over G-Ach might encounter extra processing on intermediate nodes, = the Delay >=20 > > measured over G-Ach channel might be slightly different from the = data plane >=20 > > channel. Will it be a problem? >=20 > If a node is truly intermediate and not itself the target of the >=20 > measurement operation, I see no reason why the packet would "encounter >=20 > extra processing" there, any more than any other packet label-switched >=20 > through the node. >=20 > > Section 2.7.6. Loss Measurement Modes >=20 > > Under the "direct mode", I interpret it as measuring = the >=20 > > data plane packets, is it correct? >=20 > Yes. This is the meaning of the definition in the text: >=20 > If the counted packets are the packets flowing over the channel in = the >=20 > data plane, the loss measurement is said to operate in "direct = mode". >=20 > > Counting data plane packets can be process intensive. >=20 > > Usually the each node (or line card) can only do actual packet = counting for >=20 > > limited number of LSPs. Therefore, I suggest allowing B node to = ignore A >=20 > > node's LM when B is not ready to do the counting or send back a = reply to >=20 > > indicate the "not ready status". >=20 > > >=20 > > o Several options are possible for the negotiation: egress = simply >=20 > > ignore the request when it is not ready, egress sends back an error, = etc. >=20 > > Ingress node doesn't need to start counting traffic until it gets >=20 > > confirmation from the egress node. >=20 > Indeed, and the last paragraph of Section 4.1.1 says as much. This = was >=20 > added as a result of our discussion. >=20 > > Should allow options of either byte counter or packet counter. >=20 > This is also in the text; see Section 1, the last paragraph of Section >=20 > 2.1, and the 'B' data format flag (DFlag) in Section 3.1. >=20 > > Thank you very much. >=20 > Thanks for your review! >=20 > -d >=20 > > Linda Dunbar >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From lamberto.sterling@gmail.com Sat Jan 8 17:48:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58F428C15D; Sat, 8 Jan 2011 17:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x6leYb-F+Y3; Sat, 8 Jan 2011 17:48:09 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EBEC528C0D8; Sat, 8 Jan 2011 17:48:08 -0800 (PST) Received: by bwz12 with SMTP id 12so18199798bwz.31 for ; Sat, 08 Jan 2011 17:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ob5OHdIsb9uPtEvDPOOL3plPHbURByl61wsfe0Sc+bE=; b=TNlC2LWNEMHsAm5x0kQmiE4tEZDOSOwm+XYnObvr7oXld9dNAjbUzeImf3+wBsru8O ZzOuU5jJ4xOYHbCzFULBILtJ6MaZDgwjLegDa5g62pVSrnAb1RrhoascUa05kzbO5gBF OOFe/ysAwqpmJjQxwzNSQiTtUj0KG7JazKaeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=AKLqyLvtRexiOv8+JCsHAyTGx4KnIZm+6DQUXHgxov1n9bSldFrTsBe8rzhSHuAul7 w1tUyECrjT4LM958iqdRnSpmyBOGG6vmzPePpPK1EuPOqdyYZHAww1jMjhB6fN720WgH 66XgGIrCRL0QQclk4wlAM5b9OWNP/NnsPrZmE= MIME-Version: 1.0 Received: by 10.204.100.136 with SMTP id y8mr20327205bkn.171.1294537816129; Sat, 08 Jan 2011 17:50:16 -0800 (PST) Received: by 10.204.98.204 with HTTP; Sat, 8 Jan 2011 17:50:16 -0800 (PST) Date: Sun, 9 Jan 2011 02:50:16 +0100 Message-ID: From: Lamberto Sterling To: maillist.ed@gmail.com, lizhong.jin@zte.com.cn Content-Type: multipart/alternative; boundary=001485f6d050adc09f0499601258 Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , tictoc@ietf.org, N.Leymann@telekom.de Subject: Re: [mpls] Request comments for HSMP LSP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 01:48:11 -0000 --001485f6d050adc09f0499601258 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, Sorry for the email subject. Change it now. Lamberto On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling < lamberto.sterling@gmail.com> wrote: > Hi Lizhong, Edward, > It seems that it is a good idea to apply HSMP LSP to VPLS, and the > broadcast/unicast/unknow packet would be optimized. However, the path from > leaf to root may not be the best path compared with current VPLS using P2P > LSP, which is not a critical issue. > > Thanks > Lamberto > > > >> >> ------------------------------ >> >> >> Date: Wed, 5 Jan 2011 15:50:45 +0800 >> From: lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Request comments for HSMP LSP >> To: Ed >> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , >> N.Leymann@telekom.de, tictoc@ietf.org >> Message-ID: >> < >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi Edward, >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with >> the application you proposed, and in order to improve the scalability of >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually >> this is a good application case for P2MP PW with reverse path (section >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this >> use case. >> >> Regards >> Lizhong >> >> >> Ed wrote on 2011-01-05 15:05:30: >> >> > Hi Lizhong, >> > >> > I think one possible application for HSMP LSPs is to reduce the >> > overall broadcast/multicast utilization on a VPLS. In current VPLS >> > implementations with a full mesh of P2P LSPs between PEs, broadcast, >> > multicast and unknown traffic are not efficiently propagated on the >> > physical links between PEs and Ps. >> > >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals >> > a HSMP LSP with itself as a root to all other PEs in the VPLS. >> > Thereafter, all broadcast/multicast/unknown traffic from this PE >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g. >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using >> > the HSMP LSP where PE2 is the root. >> > >> > This simplifies the VPLS implementation by: >> > - Reducing traffic utilization from broadcast, multicast >> > and unknown traffic >> > - Reducing the total number of LSPs maintained by each PE >> > (i.e. instead of requiring a full mesh of LSPs, now only require one >> > HSMP LSP per PE). >> > >> > This is similar to the idea expressed in draft-key-l2vpn-etree- >> > frwk-03.txt (in a more general sense). >> > >> > What do you think? Would HSMP LSP be suitable for this? >> > >> > Regards, >> > Edward >> > >> > >> > >> > On Wed, Jan 5, 2011 at 5:24 PM, wrote: >> > >> > Hi all, >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS >> session. >> > HSMP LSP has several use cases described in the draft, e.g, time >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would >> > be appreciated if you could give more scenarios for HSMP LSP. Please >> > review the draft, and any comments are welcome. >> > >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls- >> > mldp-hsmp-01 >> > >> > Thank you. >> > Authors of draft-hsmp. >> > -------------------------------------------------------- >> > >> > --001485f6d050adc09f0499601258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,
Sorry for the email subject. Change it now.
=A0
Lamberto

On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterlin= g <lamb= erto.sterling@gmail.com> wrote:
Hi Lizhong, Edward,
It seems that it is a good idea to apply HSMP LSP to VPLS, and the bro= adcast/unicast/unknow packet would be optimized.=A0However, the path from l= eaf to root may not be the best path compared with current VPLS using P2P L= SP, which is not a critical issue.
=A0
Thanks
Lamberto

=A0

----------------------------= --=20


Date: Wed, 5 Jan 2011 15:50:45 +0800
From: lizhong.jin@zte.co= m.cn
Subject: Re: [mpls] Request comments for HSMP LSP
To: Ed <= ;maillist.ed@gma= il.com>
Cc: l2vpn@ietf.org,= mpls@ietf.org, Ice = <ice@cisco.com>= ;,
=A0 =A0 =A0 =A0N.Leymann@telekom.de, =A0 tictoc@ietf.org
Message-ID:
=A0 =A0 =A0 =A0<OF4BA0BF75= .A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn>
Conte= nt-Type: text/plain; charset=3D"us-ascii"

Hi Edward,
Thank you for the comments. I add l2vpn maillist in cc li= st. I agree with
the application you proposed, and in order to improve t= he scalability of
VPLS, P2MP PW multiplexed to HSMP LSP could be used fo= r VPLS. Actually
this is a good application case for P2MP PW with reverse path (section
4= .4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
= use case.

Regards
Lizhong


Ed <maillist.ed@gmail.com> wrote o= n 2011-01-05 15:05:30:

> Hi Lizhong,
>
> I think one possible application for H= SMP LSPs is to reduce the
> overall broadcast/multicast utilization o= n a VPLS. In current VPLS
> implementations with a full mesh of P2P L= SPs between PEs, broadcast,
> multicast and unknown traffic are not efficiently propagated on the> physical links between PEs and Ps.
>
> In the VPLS implem= entation scenario with HSMP LSPs, each PE signals
> a HSMP LSP with i= tself as a root to all other PEs in the VPLS.
> Thereafter, all broadcast/multicast/unknown traffic from this PE
&g= t; will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
&g= t; PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> the HSMP LSP where PE2 is the root.
>
> This simplifies th= e VPLS implementation by:
> - =A0 =A0 =A0 =A0 =A0Reducing traffic uti= lization from broadcast, multicast
> and unknown traffic
> - = =A0 =A0 =A0 =A0 =A0Reducing the total number of LSPs maintained by each PE<= br> > (i.e. instead of requiring a full mesh of LSPs, now only require one> HSMP LSP per PE).
>
> This is similar to the idea expres= sed in =A0draft-key-l2vpn-etree-
> frwk-03.txt (in a more general sen= se).
>
> What do you think? Would HSMP LSP be suitable for this?
>= ;
> Regards,
> Edward
>
>
>
> On Wed, J= an 5, 2011 at 5:24 PM, <lizhong.jin@zte.com.cn> wrote:
>
> Hi all,
> During IETF 79 Beijing, we made a presentation= for HSMP LSP at MPLS
session.
> HSMP LSP has several use cases de= scribed in the draft, e.g, time
> synchronization in MPLS network, IP= TV scenario, or P2MP PW. It would
> be appreciated if you could give more scenarios for HSMP LSP. Please> review the draft, and any comments are welcome.
>
> The = draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls- > mldp-hsmp-01
>
> Thank you.
> Authors of draft-hsmp.=
> --------------------------------------------------------
>

--001485f6d050adc09f0499601258-- From stbryant@cisco.com Mon Jan 10 02:48:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2332628C0ED for ; Mon, 10 Jan 2011 02:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.537 X-Spam-Level: X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.061, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuffRInrla4Y for ; Mon, 10 Jan 2011 02:48:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4635528C12A for ; Mon, 10 Jan 2011 02:48:02 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK9yKk1AZnwN/2dsb2JhbACfYoRcc6QyglAOAZR7hUwEiwo Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 10:50:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAoEUu009074 for ; Mon, 10 Jan 2011 10:50:15 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0AAoD818446; Mon, 10 Jan 2011 10:50:13 GMT Message-ID: <4D2AE465.60107@cisco.com> Date: Mon, 10 Jan 2011 10:50:13 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary="------------070601040002040107050303" Subject: [mpls] Draft: Response to Review of MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (ref #041.03) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:48:04 -0000 This is a multi-part message in MIME format. --------------070601040002040107050303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. Stewart ======= Response to Review of MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (ref #041.03) Submission Date:2010-12-03 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int , greg.jones@itu.int , hiroshi.ota@itu.int CC: Greg Jones , swallow@cisco.com , loa@pi.nu , paf@cisco.com stbryant@cisco.com , adrian.farrel@huawei.com , mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com , hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Information Thank you for your review of draft-ietf-mpls-tp-uni-nni-00.txt. The proposed change has been made to revision draft-ietf-mpls-tp-uni-nni-02.txt. The IETF last call completed on this document on 23rd December 2010, and document is scheduled for IESG review on 20th January 2011. ======= --------------070601040002040107050303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review.

Stewart

=======

Response to Review of MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (ref #041.03)

Submission Date:2010-12-03
From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com
To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int
CC: Greg Jones,  swallow@cisco.com, loa@pi.nu, paf@cisco.com
stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org
yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com
ghani.abbas@ericsson.com, hhelvoort@huawei.com
malcolm.betts@zte.com.cn,  kam.lam@alcatel-lucent.com

For Information

Thank you for your review of draft-ietf-mpls-tp-uni-nni-00.txt.

The proposed change has been made to revision draft-ietf-mpls-tp-uni-nni-02.txt. The IETF last call completed on this document on 23rd December 2010, and document is scheduled for IESG review on 20th January 2011.

=======
--------------070601040002040107050303-- From stbryant@cisco.com Mon Jan 10 02:49:57 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FD628C138 for ; Mon, 10 Jan 2011 02:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slRRnMEtZqmB for ; Mon, 10 Jan 2011 02:49:56 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BEC5A28C137 for ; Mon, 10 Jan 2011 02:49:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANtzKk1AZnwM/2dsb2JhbACfYoRcc6QfglAOAZR8hUwEiwo Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2011 10:52:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAq9cR021552 for ; Mon, 10 Jan 2011 10:52:09 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0AAq7818563; Mon, 10 Jan 2011 10:52:08 GMT Message-ID: <4D2AE4D7.1040408@cisco.com> Date: Mon, 10 Jan 2011 10:52:07 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary="------------050202070905080006090401" Subject: [mpls] Draft: Response to Comments on draft-ietf-mpls-tp-identifiers-03 [Ref # 046.03] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:49:57 -0000 This is a multi-part message in MIME format. --------------050202070905080006090401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ========== Response to Comments on draft-ietf-mpls-tp-identifiers-03 [Ref # 046.03] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int , greg.jones@itu.int , hiroshi.ota@itu.int CC: Greg Jones , swallow@cisco.com , loa@pi.nu , paf@cisco.com stbryant@cisco.com , adrian.farrel@huawei.com , mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com malcolm.betts@zte.com.cn For Information Thank you for your review of draft-ietf-mpls-tp-identifiers-03. Your comments have been passed to the authors who will either address them in the text or lead discussions on the MPLS mailing lists as appropriate. We will notify you when a new revision of the draft is available. =========== --------------050202070905080006090401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review.

==========

Response to Comments on draft-ietf-mpls-tp-identifiers-03 [Ref # 046.03]

From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com
To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int
CC: Greg Jones,  swallow@cisco.com, loa@pi.nu, paf@cisco.com
stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org
yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com
malcolm.betts@zte.com.cn

For Information

Thank you for your review of draft-ietf-mpls-tp-identifiers-03.

 Your comments have been passed to the authors who will either address them in the text or lead discussions on the MPLS mailing lists as appropriate.

We will notify you when a new revision of the draft is available.

=========== --------------050202070905080006090401-- From stbryant@cisco.com Mon Jan 10 02:52:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D4A28C138 for ; Mon, 10 Jan 2011 02:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lFCww-9XDZD for ; Mon, 10 Jan 2011 02:52:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7FE8E28C137 for ; Mon, 10 Jan 2011 02:52:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANtzKk1AZnwN/2dsb2JhbACkPnOkH4JQDgGUfIVMBIsK Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 10:54:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAsaGE010877 for ; Mon, 10 Jan 2011 10:54:36 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0AAsY818807; Mon, 10 Jan 2011 10:54:35 GMT Message-ID: <4D2AE56A.3060200@cisco.com> Date: Mon, 10 Jan 2011 10:54:34 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:52:24 -0000 I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ========= Response to Updated draft Recommendation G.8121 [Ref 042.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action Unfortunately ITU-T document WD19r2 was not attached to this liaison, and thus the MPLS Working Group is unable to comment on its content at this time. It is stated in the liaison that the modifications to this draft Recommendation are based on draft-bhh-mpls-tp-oam-y1731-06. Please may we draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. If this draft Recommendation for G.8121 is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process, the MPLS Working Group believe that this would be in breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 – 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm for further details. We have referred this liaison to the IAB for their consideration. =========== From stbryant@cisco.com Mon Jan 10 02:54:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8AC28C137 for ; Mon, 10 Jan 2011 02:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.24 X-Spam-Level: X-Spam-Status: No, score=-110.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgR9o8BGvHKH for ; Mon, 10 Jan 2011 02:54:22 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7D24628C13A for ; Mon, 10 Jan 2011 02:54:21 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAZ1Kk1AZnwM/2dsb2JhbACkPnOkJYJQDgGUfIVMBIsK Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 10:56:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAuYNg023143 for ; Mon, 10 Jan 2011 10:56:34 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0AAuW819051; Mon, 10 Jan 2011 10:56:32 GMT Message-ID: <4D2AE5E0.90703@cisco.com> Date: Mon, 10 Jan 2011 10:56:32 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:54:23 -0000 I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ======= Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 – 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. ========= From stbryant@cisco.com Mon Jan 10 02:55:32 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE48F28C143 for ; Mon, 10 Jan 2011 02:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.537 X-Spam-Level: X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBaMhtB56V6S for ; Mon, 10 Jan 2011 02:55:31 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CAA0B28C137 for ; Mon, 10 Jan 2011 02:55:31 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAZ1Kk1AZnwM/2dsb2JhbACkPnOkJYJQDgGUfIVMBIsK Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2011 10:57:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0AAvifK023453 for ; Mon, 10 Jan 2011 10:57:44 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0AAvg819131; Mon, 10 Jan 2011 10:57:43 GMT Message-ID: <4D2AE626.9040609@cisco.com> Date: Mon, 10 Jan 2011 10:57:42 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Draft : Draft revised Recommendation G.8110.1 [Ref 044.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:55:32 -0000 I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ======== Response to Draft revised Recommendation G.8110.1 [Ref 044.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Information The MPLS Working Group regrets that due to the numerous holidays since re received this liaison, we have not yet been able to review this this revised version of Draft Recommendation G.8110.1. We will review it and liaison comment before the February ITU-T SG15 Plenary Meeting. ======== From ldunbar@huawei.com Mon Jan 10 08:26:21 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7529D3A67FA; Mon, 10 Jan 2011 08:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noLyyo+m+Ohq; Mon, 10 Jan 2011 08:26:10 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4AB4D3A67ED; Mon, 10 Jan 2011 08:26:10 -0800 (PST) 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 <0LET00CWZF3BWH@usaga02-in.huawei.com>; Mon, 10 Jan 2011 08:28:24 -0800 (PST) Received: from L735042 ([10.124.12.121]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LET001M3F3BE4@usaga02-in.huawei.com>; Mon, 10 Jan 2011 08:28:23 -0800 (PST) Date: Mon, 10 Jan 2011 10:28:23 -0600 From: Linda Dunbar In-reply-to: <9BCECFE9-04D8-4E8F-A01A-55D76C0E64C9@niven-jenkins.co.uk> To: 'Ben Niven-Jenkins' , 'Greg Mirsky' Message-id: <009501cbb0e3$665cbe90$790c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Qo+4zvuSWR1RKSG7WSb6lg)" Thread-index: Acuvhs9iO3lG3SG2QdOktkR92i+tTwBWhasg References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> <9BCECFE9-04D8-4E8F-A01A-55D76C0E64C9@niven-jenkins.co.uk> Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:26:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Qo+4zvuSWR1RKSG7WSb6lg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Ben, Answers to your questions and comments are inserted below in Blue. -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Saturday, January 08, 2011 4:53 PM To: Greg Mirsky Cc: Linda Dunbar; mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Linda, colleagues, 4 comments: 1) The edits suggested by Linda change the semantics from suggesting a querier maintain a timer to allow for the receiving end to "get its act together" to if the receiving end doesn't get its act together within X packets stop sending LM. Is that really what's intended? I would expect the time taken for the receiving end "to get its act together" would not be a function of the LM transmission rate and therefore using transmission rate to guess whether the receiving end is dead Vs getting itself ready doesn't sound sensible. [Linda] The reason for suggesting Initiator to have slower transmission rate is to minimize processing needed at the Initiator before Far End committing to the counting. We have considered implementing this feature on our products and discovered that it DOES take some time for the Central CPU to receive the Counting Request (as LM in this draft), check if the requested Counting can be supported, pass the request to the corresponding line card, and get confirmation from the Line card. Sometimes, the Far End can't perform the requested Counting because it is performing counting for requests from other nodes. 2) I don't like the final sentence suggesting queriers should delay counting transmitted packets until receiving a positive response because doing so costs resources. It sounds like an internal implementation decision that has nothing to do with interoperability and therefore irrelevant. [Linda]I agree with your point that that the Source Node performing or not performing the counting before receiving the positive feedback from Far End is not interoperability issue. Maybe it can be a recommendation? But it is necessary for Source node to abort the effort after not receiving the positive feedback after sometime (like X number of LM or timer expires). 3) I am not sure of the value of specifically calling out minimum/maximum intervals in the draft. Section 2.1 already describes how to calculate theoretical min/max values as a function of counter size, packet size & link speed, further restricting the set to specific numbers doesn't seem helpful. On 8 Jan 2011, at 21:44, Greg Mirsky wrote: [Linda]I don't have strong feeling about specifying Min/Max intervals in the draft. But it is very important to have the interval specified in the Message because Far End needs to know in preparing for the counting, and there is a possibility that Far End may not be able to support the interval initiated by the Querier. 4) Giving the receiving end the opportunity to reply with "I can;t support the rate you're asking for it's too fast for me" sounds attractive but I am not sure it is in practice if one thinks how such functionality is likely to be used. If an operator is going to turn it on with the thinking that performing LM of some sort is important regardless of the LM interval then negotiating a shorter interval may have value. However I don't expect that to be the case. I would expect an operator to pre-plan what interval they need given their knowledge of their network and the accuracy they desire, having the network change that may well cause unexpected consequences. In such a scenario I think it's better to let the receiver "hard fail" and the operator can investigate rather than have the network re-configure and the re-configuration go unnoticed, after all LM failing does not impact the ability of the network to actually forward packets. [Linda] Do you mean that Receiver can ignore the LMs if the Interval specified in the message is more than it can handle? Ben > Dear Linda, > I think that specifying particular minimum interval might become too restrictive when higher bandwidth links become available. > > Regards, > Greg > > On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar wrote: > Dan, > > Thank you very much for the reply. > > As for Section 4.1.1, may I suggest some wording changes (in blue)? > > When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation, for example by stopping sending LMs after X (e.g. 3) number of LMs being sent without positive feedback. The initial LM interval before any response being received could be longer than normal to minimize the querier's resource consumption. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier should delay counting its transmitted packets until receiving a positive feedback from the far-end. > > > Another comment: > > I think the document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher the processing loads on line cards. Therefore, it is necessary to describe the minimum (and maximum) intervals for LM/DM in the draft, and specifying the unit (like ms or second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format. > > Since the processing capability on the initiating node (the querier) and the far end (receiving) node could be different, the receiver (far end node) may indicate in the response a minimum interval it can support and the querier may adjust the LM interval to any desired value greater than that. Therefore, the interval value should be encoded in the LM/DM message. > > I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval and add a field in the message for interval. > > > Linda Dunbar > > > -----Original Message----- > From: Dan Frost [mailto:danfrost@cisco.com] > Sent: Friday, January 07, 2011 5:27 AM > To: Linda Dunbar > Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' > Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" > > Hi Linda, > > On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: > > > Section 2 (Overview), > > > there are several references of measuring "packets" without > > > specifying if the packets are LM/DM packets or actual data plane packets. > > > Such Page 7 first paragraph: " the count of packets received prior to time > > > T2 over the channel from A (B_RxP)," > > > > > > Is this the intent? So that LM can be used to either > > > measuring the LM losses and data plane loss? > > Yes, this is intentional in the overview, because as the rest of the > > document makes clear, several options for what exactly to measure exist. > > > Section 2.7.1 Types of Channels: > > > It stated that LM and DM flow over MPLS G-Ach. Since packets > > > over G-Ach might encounter extra processing on intermediate nodes, the Delay > > > measured over G-Ach channel might be slightly different from the data plane > > > channel. Will it be a problem? > > If a node is truly intermediate and not itself the target of the > > measurement operation, I see no reason why the packet would "encounter > > extra processing" there, any more than any other packet label-switched > > through the node. > > > Section 2.7.6. Loss Measurement Modes > > > Under the "direct mode", I interpret it as measuring the > > > data plane packets, is it correct? > > Yes. This is the meaning of the definition in the text: > > If the counted packets are the packets flowing over the channel in the > > data plane, the loss measurement is said to operate in "direct mode". > > > Counting data plane packets can be process intensive. > > > Usually the each node (or line card) can only do actual packet counting for > > > limited number of LSPs. Therefore, I suggest allowing B node to ignore A > > > node's LM when B is not ready to do the counting or send back a reply to > > > indicate the "not ready status". > > > > > > o Several options are possible for the negotiation: egress simply > > > ignore the request when it is not ready, egress sends back an error, etc. > > > Ingress node doesn't need to start counting traffic until it gets > > > confirmation from the egress node. > > Indeed, and the last paragraph of Section 4.1.1 says as much. This was > > added as a result of our discussion. > > > Should allow options of either byte counter or packet counter. > > This is also in the text; see Section 1, the last paragraph of Section > > 2.1, and the 'B' data format flag (DFlag) in Section 3.1. > > > Thank you very much. > > Thanks for your review! > > -d > > > Linda Dunbar > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp --Boundary_(ID_Qo+4zvuSWR1RKSG7WSb6lg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: [mpls-tp] [mpls] Questions on = "draft-ietf-mpls-loss-delay-00"

Ben,

Answers to your questions and comments are inserted = below in Blue.

-----Original Message-----
From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
Sent: Saturday, January 08, 2011 4:53 PM
To: = Greg Mirsky
Cc: = Linda Dunbar; mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] Questions on = "draft-ietf-mpls-loss-delay-00"

Linda, = colleagues,

4 = comments:

1) The = edits suggested by Linda change the semantics from suggesting a querier = maintain a timer to allow for the = receiving end to "get its act together" to if the receiving = end doesn't get its act together within X packets stop sending LM. Is = that really what's intended? I would expect the time taken for the = receiving end "to get its act together" would not be a = function of the LM transmission rate and therefore using transmission = rate to guess whether the receiving end is dead Vs getting itself ready = doesn't sound sensible.

[Linda] The reason for suggesting = Initiator to have slower transmission rate is to minimize processing = needed at the Initiator before Far End committing to the counting.

We have considered implementing this feature on our = products and = discovered that it DOES take some time for the = Central CPU to receive the = Counting Request (as LM in this draft), check if = the requested Counting can be supported, pass the request to the corresponding line = card, and get confirmation from the = Line card. Sometimes, the Far End = can't perform the requested = Counting because it is performing counting for requests from other = nodes.

2) I don't = like the final sentence suggesting queriers should delay counting = transmitted packets until receiving a positive response because doing so = costs resources. It sounds like an internal implementation decision that = has nothing to do with interoperability and therefore = irrelevant.

[Linda]I agree with your point = that that the Source = Node performing or not = performing the counting before receiving = the positive feedback from Far End is = not interoperability = issue. Maybe it can be a recommendation? =

But it is necessary for Source node = to abort the effort after not receiving the positive = feedback after sometime (like X number of LM or timer = expires).

3) I am not = sure of the value of specifically calling out minimum/maximum intervals = in the draft. Section 2.1 already describes how to calculate theoretical = min/max values as a function of counter size, packet size & = link speed, further restricting the = set to specific numbers doesn't seem helpful.

On 8 Jan = 2011, at 21:44, Greg Mirsky wrote:

[Linda]I don't have strong feeling about = specifying Min/Max intervals in the draft.

But it is very important to have the interval specified in the = Message because Far End needs to know in preparing for the counting, and there = is a possibility that Far End may not be able to support the = interval initiated by the Querier. =

4) Giving = the receiving end the opportunity to reply with "I can;t support = the rate you're asking for it's too fast for me" sounds = attractive but I am not sure it is in = practice if one thinks how such functionality is likely to be used. If = an operator is going to turn it on with the thinking that performing LM = of some sort is important regardless of the LM interval then negotiating = a shorter interval may have value. However I don't expect that to be the = case. I would expect an operator to pre-plan what interval they need = given their knowledge of their network and the accuracy they desire, = having the network change that may well cause unexpected = consequences. In such a scenario I think it's better to let the receiver = "hard fail" and the operator can investigate rather than have = the network re-configure and the re-configuration go unnoticed, after = all LM failing does not impact the ability of the network to actually = forward packets.

[Linda] Do you mean that Receiver can ignore the = LMs if the Interval specified in = the message is more than it can handle? =

Ben

> Dear = Linda,

> I = think that specifying particular minimum interval might become too = restrictive when higher bandwidth links become = available.

> =

> = Regards,

> = Greg

> =

> On = Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar <ldunbar@huawei.com> wrote:

> = Dan,

> =

> Thank = you very much for the reply.

> =

> As for = Section 4.1.1, may I suggest some wording changes (in = blue)?

> =

> When = initiating an LM operation, the far end may require a period of time to = become ready for the requested = measurement operation or the far end may not be able to support the = requested measurement. During this period Under those circumstances, LM = queries MAY simply be discarded, and the querier expecting a response = SHOULD be prepared for this situation, for example by stopping = sending LMs after X (e.g. 3) number of LMs being sent without positive = feedback. The initial LM interval before any response being received = could be longer than normal to minimize the querier’s resource = consumption. setting a timer to differentiate between an acceptable = initialization delay and a permanent unavailability condition at the far = end. Alternatively, the receiver MAY respond, possibly in a rate-limited = manner, to queries received during this period with an = appropriate notification code. Since counting transmitted = packets at querier side will cost extra resources (or is not free), the = querier should delay counting its transmitted packets until receiving a = positive feedback from the far-end.

> =

> =

> = Another comment:

> =

> I think the document should = add a description on the range of allowed LM/DM intervals. The shorter = the interval, the higher the processing loads on line cards. Therefore, = it is necessary to describe the minimum (and maximum) intervals for = LM/DM in the draft, and specifying the unit (like ms or second). = IEEE802.ag specifies its CCM’s minimum interval to be = 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x = format.

> =

> Since = the processing capability on the initiating node (the querier) and the = far end (receiving) node could be different, the receiver (far end node) = may indicate in the response a minimum interval it can support and the = querier may adjust the LM interval to any desired value greater = than that. Therefore, the interval value should be encoded in the LM/DM = message.

> =

> I = suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval = and add a field in the message for interval.

> =

> =

> Linda = Dunbar

>

> =

> = -----Original Message-----

> From: = Dan Frost [mailto:danfrost@cisco.com]<= /SPAN>

> Sent: = Friday, January 07, 2011 5:27 AM

> To: = Linda Dunbar

> Cc: = mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant'

> = Subject: Re: Questions on = "draft-ietf-mpls-loss-delay-00"

> =

> Hi = Linda,

> =

> On = Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar = wrote:

> =

> > = Section 2 (Overview),

> =

> = >           &nb= sp;   there are several references of measuring = "packets" without

> =

> > = specifying if the packets are LM/DM packets or actual data plane packets.

> =

> > = Such Page 7 first paragraph: " the count of packets received prior = to time

> =

> > = T2 over the channel from A (B_RxP),"

> =

> = >

> =

> = >           &nb= sp;   Is this the intent? So that LM can be used to = either

> =

> > = measuring the LM losses and data plane loss?

> =

> Yes, = this is intentional in the overview, because as the rest of = the

> =

> = document makes clear, several options for what exactly to measure = exist.

> =

> > = Section 2.7.1 Types of Channels:

> =

> = >               It stated that LM = and DM flow over MPLS G-Ach. Since packets

> =

> > = over G-Ach might encounter extra processing on intermediate nodes, the = Delay

> =

> > = measured over G-Ach channel might be slightly different from the data = plane

> =

> > = channel. Will it be a = problem?

> =

> If a = node is truly intermediate and not itself the target of = the

> =

> = measurement operation, I see no reason why the packet would = "encounter

> =

> extra = processing" there, any more than any other packet = label-switched

> =

> = through the node.

> =

> > = Section 2.7.6. Loss Measurement Modes

> =

> = >           &nb= sp;   Under the "direct mode", I interpret it as = measuring the

> =

> > = data plane packets, is it correct?

> =

> = Yes.  This is the meaning of the definition in the = text:

> =

>    If the counted packets are the packets = flowing over the channel in the

> =

>    data plane, the loss measurement is said to = operate in "direct mode".

> =

> = >           &nb= sp;   Counting data plane packets can be process = intensive.

> =

> > = Usually the each node (or line card) = can only do actual packet counting for

> =

> > = limited number of LSPs. Therefore, I suggest allowing B node to ignore = A

> =

> > = node's LM when B is not ready to do the counting or send back a reply = to

> =

> > = indicate the "not ready status".

> =

> = >

> =

> > = o     Several options are possible for the = negotiation: egress simply

> =

> > = ignore the request when it is not ready, egress sends back an error, = etc.

> =

> > = Ingress node doesn't need to start counting traffic until it = gets

> =

> > = confirmation from the egress node.

> =

> = Indeed, and the last paragraph of Section 4.1.1 says as much.  This = was

> =

> added = as a result of our discussion.

> =

> > = Should allow options of either byte counter or packet = counter.

> =

> This = is also in the text; see Section 1, = the last paragraph of Section

> =

> 2.1, = and the 'B' data format flag (DFlag) in Section 3.1.

> =

> > = Thank you very much.

> =

> Thanks = for your review!

> =

> = -d

> =

> > = Linda Dunbar

> =

> =

> = _______________________________________________

> = mpls mailing list

> = mpls@ietf.org

> https://www.ietf.org/= mailman/listinfo/mpls

> =

> =

> = _______________________________________________

> = mpls-tp mailing list

> = mpls-tp@ietf.org

> https://www.ietf.o= rg/mailman/listinfo/mpls-tp

= --Boundary_(ID_Qo+4zvuSWR1RKSG7WSb6lg)-- From ldunbar@huawei.com Mon Jan 10 08:28:13 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F165B3A6803; Mon, 10 Jan 2011 08:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.086 X-Spam-Level: X-Spam-Status: No, score=-106.086 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gbEU6SZkDmJ; Mon, 10 Jan 2011 08:28:04 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id AEEB13A67FA; Mon, 10 Jan 2011 08:28:04 -0800 (PST) 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 <0LET00CCLF6IWH@usaga02-in.huawei.com>; Mon, 10 Jan 2011 08:30:18 -0800 (PST) Received: from L735042 ([10.124.12.121]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LET001ZHF6IE4@usaga02-in.huawei.com>; Mon, 10 Jan 2011 08:30:18 -0800 (PST) Date: Mon, 10 Jan 2011 10:30:18 -0600 From: Linda Dunbar In-reply-to: To: 'Greg Mirsky' Message-id: <009a01cbb0e3$aafa0d50$790c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_P8AeheEXRLliOdtlqme/tw)" Thread-index: AcuvfTcTlsihga7rS2KFE3ZunmNe1QBZjcFg References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> Cc: mpls@ietf.org, mpls-tp@ietf.org, 'Stewart Bryant' Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:28:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_P8AeheEXRLliOdtlqme/tw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Greg, Even though I don't have strong feeling about specifying the Min interval in the draft, you will find that any interval less than 3ms is not realistic. Linda _____ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Saturday, January 08, 2011 3:44 PM To: Linda Dunbar Cc: Dan Frost; mpls@ietf.org; Stewart Bryant; mpls-tp@ietf.org Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Dear Linda, I think that specifying particular minimum interval might become too restrictive when higher bandwidth links become available. Regards, Greg On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar wrote: Dan, Thank you very much for the reply. As for Section 4.1.1, may I suggest some wording changes (in blue)? When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation, for example by stopping sending LMs after X (e.g. 3) number of LMs being sent without positive feedback. The initial LM interval before any response being received could be longer than normal to minimize the querier's resource consumption. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier should delay counting its transmitted packets until receiving a positive feedback from the far-end. Another comment: I think the document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher the processing loads on line cards. Therefore, it is necessary to describe the minimum (and maximum) intervals for LM/DM in the draft, and specifying the unit (like ms or second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format. Since the processing capability on the initiating node (the querier) and the far end (receiving) node could be different, the receiver (far end node) may indicate in the response a minimum interval it can support and the querier may adjust the LM interval to any desired value greater than that. Therefore, the interval value should be encoded in the LM/DM message. I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval and add a field in the message for interval. Linda Dunbar -----Original Message----- From: Dan Frost [mailto:danfrost@cisco.com] Sent: Friday, January 07, 2011 5:27 AM To: Linda Dunbar Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" Hi Linda, On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: > Section 2 (Overview), > there are several references of measuring "packets" without > specifying if the packets are LM/DM packets or actual data plane packets. > Such Page 7 first paragraph: " the count of packets received prior to time > T2 over the channel from A (B_RxP)," > > Is this the intent? So that LM can be used to either > measuring the LM losses and data plane loss? Yes, this is intentional in the overview, because as the rest of the document makes clear, several options for what exactly to measure exist. > Section 2.7.1 Types of Channels: > It stated that LM and DM flow over MPLS G-Ach. Since packets > over G-Ach might encounter extra processing on intermediate nodes, the Delay > measured over G-Ach channel might be slightly different from the data plane > channel. Will it be a problem? If a node is truly intermediate and not itself the target of the measurement operation, I see no reason why the packet would "encounter extra processing" there, any more than any other packet label-switched through the node. > Section 2.7.6. Loss Measurement Modes > Under the "direct mode", I interpret it as measuring the > data plane packets, is it correct? Yes. This is the meaning of the definition in the text: If the counted packets are the packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode". > Counting data plane packets can be process intensive. > Usually the each node (or line card) can only do actual packet counting for > limited number of LSPs. Therefore, I suggest allowing B node to ignore A > node's LM when B is not ready to do the counting or send back a reply to > indicate the "not ready status". > > o Several options are possible for the negotiation: egress simply > ignore the request when it is not ready, egress sends back an error, etc. > Ingress node doesn't need to start counting traffic until it gets > confirmation from the egress node. Indeed, and the last paragraph of Section 4.1.1 says as much. This was added as a result of our discussion. > Should allow options of either byte counter or packet counter. This is also in the text; see Section 1, the last paragraph of Section 2.1, and the 'B' data format flag (DFlag) in Section 3.1. > Thank you very much. Thanks for your review! -d > Linda Dunbar _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --Boundary_(ID_P8AeheEXRLliOdtlqme/tw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Greg,

 

Even though I don’t have strong feeling about specifying the Min interval in the draft, you will find that any interval less than 3ms is not realistic.

 

Linda

 

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Saturday, January 08, 2011 3:44 PM
To: Linda Dunbar
Cc: Dan Frost; mpls@ietf.org; Stewart Bryant; mpls-tp@ietf.org
Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00"

 

Dear Linda,
I think that specifying particular minimum interval might become too restrictive when higher bandwidth links become available.

Regards,
Greg

On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar <ldunbar@huawei.com> wrote:

Dan,

Thank you very much for the reply.

As for Section 4.1.1, may I suggest some wording changes (in blue)?

When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation, for example by stopping sending LMs after X (e.g. 3) number of LMs being sent without positive feedback. The initial LM interval before any response being received could be longer than normal to minimize the querier’s resource consumption. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier should delay counting its transmitted packets until receiving a positive feedback from the far-end.

Another comment:

I think the document should add a description on the range of allowed LM/DM intervals. The shorter the interval, the higher the processing loads on line cards. Therefore, it is necessary to describe the minimum (and maximum) intervals for LM/DM in the draft, and specifying the unit (like ms or second). IEEE802.ag specifies its CCM’s minimum interval to be 3ms. To optimize the bits utilization, IEEE802.1Qbg uses 2x format.

Since the processing capability on the initiating node (the querier) and the far end (receiving) node could be different, the receiver (far end node) may indicate in the response a minimum interval it can support and the querier may adjust the LM interval to any desired value greater than that. Therefore, the interval value should be encoded in the LM/DM message.

I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval and add a field in the message for interval.

Linda Dunbar

-----Original Message-----
From: Dan Frost [mailto:danfrost@cisco.com]
Sent: Friday, January 07, 2011 5:27 AM
To: Linda Dunbar
Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant'
Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00"

Hi Linda,

On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote:

> Section 2 (Overview),

>               there are several references of measuring "packets" without

> specifying if the packets are LM/DM packets or actual data plane packets.

> Such Page 7 first paragraph: " the count of packets received prior to time

> T2 over the channel from A (B_RxP),"

>

>               Is this the intent? So that LM can be used to either

> measuring the LM losses and data plane loss?

Yes, this is intentional in the overview, because as the rest of the

document makes clear, several options for what exactly to measure exist.

> Section 2.7.1 Types of Channels:

>               It stated that LM and DM flow over MPLS G-Ach. Since packets

> over G-Ach might encounter extra processing on intermediate nodes, the Delay

> measured over G-Ach channel might be slightly different from the data plane

> channel. Will it be a problem?

If a node is truly intermediate and not itself the target of the

measurement operation, I see no reason why the packet would "encounter

extra processing" there, any more than any other packet label-switched

through the node.

> Section 2.7.6. Loss Measurement Modes

>               Under the "direct mode", I interpret it as measuring the

> data plane packets, is it correct?

Yes.  This is the meaning of the definition in the text:

   If the counted packets are the packets flowing over the channel in the

   data plane, the loss measurement is said to operate in "direct mode".

>               Counting data plane packets can be process intensive.

> Usually the each node (or line card) can only do actual packet counting for

> limited number of LSPs. Therefore, I suggest allowing B node to ignore A

> node's LM when B is not ready to do the counting or send back a reply to

> indicate the "not ready status".

>

> o     Several options are possible for the negotiation: egress simply

> ignore the request when it is not ready, egress sends back an error, etc.

> Ingress node doesn't need to start counting traffic until it gets

> confirmation from the egress node.

Indeed, and the last paragraph of Section 4.1.1 says as much.  This was

added as a result of our discussion.

> Should allow options of either byte counter or packet counter.

This is also in the text; see Section 1, the last paragraph of Section

2.1, and the 'B' data format flag (DFlag) in Section 3.1.

> Thank you very much.

Thanks for your review!

-d

> Linda Dunbar


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

 

--Boundary_(ID_P8AeheEXRLliOdtlqme/tw)-- From eosborne@cisco.com Mon Jan 10 08:34:22 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E6E3A680B; Mon, 10 Jan 2011 08:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUCK0KDfzqag; Mon, 10 Jan 2011 08:34:21 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C0E7F3A67FA; Mon, 10 Jan 2011 08:34:20 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALbEKk2tJV2a/2dsb2JhbACkR3OjK5dwhUwEhGeJSYJw Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 16:36:34 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0AGaYMS009670; Mon, 10 Jan 2011 16:36:34 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 10:36:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 10:36:32 -0600 Message-ID: In-Reply-To: <009a01cbb0e3$aafa0d50$790c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Thread-Index: AcuvfTcTlsihga7rS2KFE3ZunmNe1QBZjcFgAAAfUEA= References: <002901cbadf8$66783640$790c7c0a@china.huawei.com><20110107112641.GA20790@cisco.com><014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> <009a01cbb0e3$aafa0d50$790c7c0a@china.huawei.com> From: "Eric Osborne (eosborne)" To: "Linda Dunbar" , "Greg Mirsky" X-OriginalArrivalTime: 10 Jan 2011 16:36:34.0194 (UTC) FILETIME=[8B0A6F20:01CBB0E4] Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" , mpls-tp@ietf.org Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:34:22 -0000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Monday, January 10, 2011 11:30 AM > To: 'Greg Mirsky' > Cc: mpls@ietf.org; mpls-tp@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" >=20 > Greg, >=20 >=20 >=20 > Even though I don't have strong feeling about specifying the Min interval > in the draft, you will find that any interval less than 3ms is not > realistic. >=20 I don't have particular feelings about this draft, but I've discovered the one of the things I'm particularly bad at is deciding what operators will never, ever want to do at some point in the future. If you want to declare minimum and maximum ranges, I think it's always best practice to say something like "an implement SHOULD support an interval range from to " - this leaves room for implementations to both exceed the spec if desired and to do something other than what's specified if there is a good reason to. eric >=20 >=20 > Linda >=20 >=20 >=20 > ________________________________ >=20 > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Saturday, January 08, 2011 3:44 PM > To: Linda Dunbar > Cc: Dan Frost; mpls@ietf.org; Stewart Bryant; mpls-tp@ietf.org > Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" >=20 >=20 >=20 > Dear Linda, > I think that specifying particular minimum interval might become too > restrictive when higher bandwidth links become available. >=20 > Regards, > Greg >=20 > On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar wrote: >=20 > Dan, >=20 > Thank you very much for the reply. >=20 > As for Section 4.1.1, may I suggest some wording changes (in blue)? >=20 > When initiating an LM operation, the far end may require a period of time > to become ready for the requested measurement operation or the far end may > not be able to support the requested measurement. During this period Under > those circumstances, LM queries MAY simply be discarded, and the querier > expecting a response SHOULD be prepared for this situation, for example by > stopping sending LMs after X (e.g. 3) number of LMs being sent without > positive feedback. The initial LM interval before any response being > received could be longer than normal to minimize the querier's resource > consumption. setting a timer to differentiate between an acceptable > initialization delay and a permanent unavailability condition at the far > end. Alternatively, the receiver MAY respond, possibly in a rate-limited > manner, to queries received during this period with an appropriate > notification code. Since counting transmitted packets at querier side will > cost extra resources (or is not free), the querier should delay counting > its transmitted packets until receiving a positive feedback from the far- > end. >=20 > Another comment: >=20 > I think the document should add a description on the range of allowed > LM/DM intervals. The shorter the interval, the higher the processing loads > on line cards. Therefore, it is necessary to describe the minimum (and > maximum) intervals for LM/DM in the draft, and specifying the unit (like > ms or second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. > To optimize the bits utilization, IEEE802.1Qbg uses 2x format. >=20 > Since the processing capability on the initiating node (the querier) and > the far end (receiving) node could be different, the receiver (far end > node) may indicate in the response a minimum interval it can support and > the querier may adjust the LM interval to any desired value greater than > that. Therefore, the interval value should be encoded in the LM/DM > message. >=20 > I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval > and add a field in the message for interval. >=20 > Linda Dunbar >=20 > -----Original Message----- > From: Dan Frost [mailto:danfrost@cisco.com] > Sent: Friday, January 07, 2011 5:27 AM > To: Linda Dunbar > Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' > Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" >=20 > Hi Linda, >=20 > On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: >=20 > > Section 2 (Overview), >=20 > > there are several references of measuring "packets" > without >=20 > > specifying if the packets are LM/DM packets or actual data plane > packets. >=20 > > Such Page 7 first paragraph: " the count of packets received prior to > time >=20 > > T2 over the channel from A (B_RxP)," >=20 > > >=20 > > Is this the intent? So that LM can be used to either >=20 > > measuring the LM losses and data plane loss? >=20 > Yes, this is intentional in the overview, because as the rest of the >=20 > document makes clear, several options for what exactly to measure exist. >=20 > > Section 2.7.1 Types of Channels: >=20 > > It stated that LM and DM flow over MPLS G-Ach. Since > packets >=20 > > over G-Ach might encounter extra processing on intermediate nodes, the > Delay >=20 > > measured over G-Ach channel might be slightly different from the data > plane >=20 > > channel. Will it be a problem? >=20 > If a node is truly intermediate and not itself the target of the >=20 > measurement operation, I see no reason why the packet would "encounter >=20 > extra processing" there, any more than any other packet label-switched >=20 > through the node. >=20 > > Section 2.7.6. Loss Measurement Modes >=20 > > Under the "direct mode", I interpret it as measuring the >=20 > > data plane packets, is it correct? >=20 > Yes. This is the meaning of the definition in the text: >=20 > If the counted packets are the packets flowing over the channel in the >=20 > data plane, the loss measurement is said to operate in "direct mode". >=20 > > Counting data plane packets can be process intensive. >=20 > > Usually the each node (or line card) can only do actual packet counting > for >=20 > > limited number of LSPs. Therefore, I suggest allowing B node to ignore A >=20 > > node's LM when B is not ready to do the counting or send back a reply to >=20 > > indicate the "not ready status". >=20 > > >=20 > > o Several options are possible for the negotiation: egress simply >=20 > > ignore the request when it is not ready, egress sends back an error, > etc. >=20 > > Ingress node doesn't need to start counting traffic until it gets >=20 > > confirmation from the egress node. >=20 > Indeed, and the last paragraph of Section 4.1.1 says as much. This was >=20 > added as a result of our discussion. >=20 > > Should allow options of either byte counter or packet counter. >=20 > This is also in the text; see Section 1, the last paragraph of Section >=20 > 2.1, and the 'B' data format flag (DFlag) in Section 3.1. >=20 > > Thank you very much. >=20 > Thanks for your review! >=20 > -d >=20 > > Linda Dunbar >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From ben@niven-jenkins.co.uk Mon Jan 10 09:26:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6DF3A681F; Mon, 10 Jan 2011 09:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db0yQvr51vqp; Mon, 10 Jan 2011 09:26:48 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id B309A3A681A; Mon, 10 Jan 2011 09:26:47 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-122-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PcLYC-0003qn-I5; Mon, 10 Jan 2011 17:29:00 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <009501cbb0e3$665cbe90$790c7c0a@china.huawei.com> Date: Mon, 10 Jan 2011 17:29:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <48AA81F4-C02E-48F5-95BF-0159CFAB682C@niven-jenkins.co.uk> References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> <9BCECFE9-04D8-4E8F-A01A-55D76C0E64C9@niven-jenkins.co.uk> <009501cbb0e3$665cbe90$790c7c0a@china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: mpls-tp@ietf.org, mpls@ietf.org Subject: Re: [mpls] [mpls-tp] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:26:49 -0000 Linda, On 10 Jan 2011, at 16:28, Linda Dunbar wrote: > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >=20 > 1) The edits suggested by Linda change the semantics from suggesting a = querier maintain a timer to allow for the receiving end to "get its act = together" to if the receiving end doesn't get its act together within X = packets stop sending LM. Is that really what's intended? I would expect = the time taken for the receiving end "to get its act together" would not = be a function of the LM transmission rate and therefore using = transmission rate to guess whether the receiving end is dead Vs getting = itself ready doesn't sound sensible. >=20 >=20 > [Linda] The reason for suggesting Initiator to have slower = transmission rate is to minimize processing needed at the Initiator = before Far End committing to the counting. >=20 But you suggest edit does not suggest a slower transmission rate it = states the querier should stop transmission! > We have considered implementing this feature on our products and = discovered that it DOES take some time for the Central CPU to receive = the Counting Request (as LM in this draft), check if the requested = Counting can be supported, pass the request to the corresponding line = card, and get confirmation from the Line card. Sometimes, the Far End = can't perform the requested Counting because it is performing counting = for requests from other nodes. >=20 I accept that a receiver may take some time to configure itself for = counting and that the time it takes may be a function of other things it = is doing. What I am saying is that the time it takes is never a function = of the interval being configured. > 2) I don't like the final sentence suggesting queriers should delay = counting transmitted packets until receiving a positive response because = doing so costs resources. It sounds like an internal implementation = decision that has nothing to do with interoperability and therefore = irrelevant. >=20 >=20 > [Linda]I agree with your point that that the Source Node performing or = not performing the counting before receiving the positive feedback from = Far End is not interoperability issue. Maybe it can be a recommendation? >=20 > But it is necessary for Source node to abort the effort after not = receiving the positive feedback after sometime (like X number of LM or = timer expires). >=20 At some point, if the querier has not received a positive response it = must abort the operation. The original text suggest maintaing a timer. = Your edit suggested making ti a function of packets sent. I am saying = the former seems more sensible than the latter to me. > 4) Giving the receiving end the opportunity to reply with "I can;t = support the rate you're asking for it's too fast for me" sounds = attractive but I am not sure it is in practice if one thinks how such = functionality is likely to be used. If an operator is going to turn it = on with the thinking that performing LM of some sort is important = regardless of the LM interval then negotiating a shorter interval may = have value. However I don't expect that to be the case. I would expect = an operator to pre-plan what interval they need given their knowledge of = their network and the accuracy they desire, having the network change = that may well cause unexpected consequences. In such a scenario I think = it's better to let the receiver "hard fail" and the operator can = investigate rather than have the network re-configure and the = re-configuration go unnoticed, after all LM failing does not impact the = ability of the network to actually forward packets. >=20 >=20 > [Linda] Do you mean that Receiver can ignore the LMs if the Interval = specified in the message is more than it can handle? That is one option. The background to my thinking is: I assume that LM will be turned on explicitly (i.e. it will not be on by = default) I assume that LM is turned on for a reason, e.g. because an operator = needs to support an SLA involving packet loss. The interval may affect the accuracy of the packet loss count. I expect operators would rather LM "hard fail" rather than have the = network re-configure automatically to a different interval because an = SLA calculation (or whatever else is relying on the LM) could become = inaccurate and no-one would know unless they really dug deep into what = the network was doing. The network re-configuring itself in order to repair itself so it can = continue to forward packets is one thing. The network reconfiguring non-forwarding related features itself because = it believes it knows what to do better than the person who designed & = configured it could lead to all sorts of trouble in the field IMO. Ben =20 From ldunbar@huawei.com Tue Jan 11 07:36:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82F53A6809; Tue, 11 Jan 2011 07:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.113 X-Spam-Level: X-Spam-Status: No, score=-106.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vENr7tbxR04F; Tue, 11 Jan 2011 07:36:43 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 58C2E3A67A8; Tue, 11 Jan 2011 07:36:43 -0800 (PST) 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 <0LEV001A67GZBZ@usaga02-in.huawei.com>; Tue, 11 Jan 2011 07:39:00 -0800 (PST) Received: from L735042 ([10.124.12.121]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV00I547GZ4O@usaga02-in.huawei.com>; Tue, 11 Jan 2011 07:38:59 -0800 (PST) Date: Tue, 11 Jan 2011 09:38:59 -0600 From: Linda Dunbar In-reply-to: To: "'Eric Osborne (eosborne)'" , 'Greg Mirsky' Message-id: <004701cbb1a5$aa47e630$790c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcuvfTcTlsihga7rS2KFE3ZunmNe1QBZjcFgAAAfUEAAMF7hAA== References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> <009a01cbb0e3$aafa0d50$790c7c0a@china.huawei.com> Cc: mpls@ietf.org, "'Stewart Bryant \(stbryant\)'" , mpls-tp@ietf.org Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:36:44 -0000 Eric, That is a good suggestion. Linda -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] Sent: Monday, January 10, 2011 10:37 AM To: Linda Dunbar; Greg Mirsky Cc: mpls@ietf.org; mpls-tp@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Linda Dunbar > Sent: Monday, January 10, 2011 11:30 AM > To: 'Greg Mirsky' > Cc: mpls@ietf.org; mpls-tp@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" > > Greg, > > > > Even though I don't have strong feeling about specifying the Min interval > in the draft, you will find that any interval less than 3ms is not > realistic. > I don't have particular feelings about this draft, but I've discovered the one of the things I'm particularly bad at is deciding what operators will never, ever want to do at some point in the future. If you want to declare minimum and maximum ranges, I think it's always best practice to say something like "an implement SHOULD support an interval range from to " - this leaves room for implementations to both exceed the spec if desired and to do something other than what's specified if there is a good reason to. eric > > > Linda > > > > ________________________________ > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > Sent: Saturday, January 08, 2011 3:44 PM > To: Linda Dunbar > Cc: Dan Frost; mpls@ietf.org; Stewart Bryant; mpls-tp@ietf.org > Subject: Re: [mpls] Questions on "draft-ietf-mpls-loss-delay-00" > > > > Dear Linda, > I think that specifying particular minimum interval might become too > restrictive when higher bandwidth links become available. > > Regards, > Greg > > On Fri, Jan 7, 2011 at 3:05 PM, Linda Dunbar wrote: > > Dan, > > Thank you very much for the reply. > > As for Section 4.1.1, may I suggest some wording changes (in blue)? > > When initiating an LM operation, the far end may require a period of time > to become ready for the requested measurement operation or the far end may > not be able to support the requested measurement. During this period Under > those circumstances, LM queries MAY simply be discarded, and the querier > expecting a response SHOULD be prepared for this situation, for example by > stopping sending LMs after X (e.g. 3) number of LMs being sent without > positive feedback. The initial LM interval before any response being > received could be longer than normal to minimize the querier's resource > consumption. setting a timer to differentiate between an acceptable > initialization delay and a permanent unavailability condition at the far > end. Alternatively, the receiver MAY respond, possibly in a rate-limited > manner, to queries received during this period with an appropriate > notification code. Since counting transmitted packets at querier side will > cost extra resources (or is not free), the querier should delay counting > its transmitted packets until receiving a positive feedback from the far- > end. > > Another comment: > > I think the document should add a description on the range of allowed > LM/DM intervals. The shorter the interval, the higher the processing loads > on line cards. Therefore, it is necessary to describe the minimum (and > maximum) intervals for LM/DM in the draft, and specifying the unit (like > ms or second). IEEE802.ag specifies its CCM's minimum interval to be 3ms. > To optimize the bits utilization, IEEE802.1Qbg uses 2x format. > > Since the processing capability on the initiating node (the querier) and > the far end (receiving) node could be different, the receiver (far end > node) may indicate in the response a minimum interval it can support and > the querier may adjust the LM interval to any desired value greater than > that. Therefore, the interval value should be encoded in the LM/DM > message. > > I suggest adding a section (e.g. 2.7.10) to describe the LM/DM interval > and add a field in the message for interval. > > Linda Dunbar > > -----Original Message----- > From: Dan Frost [mailto:danfrost@cisco.com] > Sent: Friday, January 07, 2011 5:27 AM > To: Linda Dunbar > Cc: mpls-tp@ietf.org; mpls@ietf.org; 'Stewart Bryant' > Subject: Re: Questions on "draft-ietf-mpls-loss-delay-00" > > Hi Linda, > > On Thu, Jan 06, 2011 at 05:21:09PM -0600, Linda Dunbar wrote: > > > Section 2 (Overview), > > > there are several references of measuring "packets" > without > > > specifying if the packets are LM/DM packets or actual data plane > packets. > > > Such Page 7 first paragraph: " the count of packets received prior to > time > > > T2 over the channel from A (B_RxP)," > > > > > > Is this the intent? So that LM can be used to either > > > measuring the LM losses and data plane loss? > > Yes, this is intentional in the overview, because as the rest of the > > document makes clear, several options for what exactly to measure exist. > > > Section 2.7.1 Types of Channels: > > > It stated that LM and DM flow over MPLS G-Ach. Since > packets > > > over G-Ach might encounter extra processing on intermediate nodes, the > Delay > > > measured over G-Ach channel might be slightly different from the data > plane > > > channel. Will it be a problem? > > If a node is truly intermediate and not itself the target of the > > measurement operation, I see no reason why the packet would "encounter > > extra processing" there, any more than any other packet label-switched > > through the node. > > > Section 2.7.6. Loss Measurement Modes > > > Under the "direct mode", I interpret it as measuring the > > > data plane packets, is it correct? > > Yes. This is the meaning of the definition in the text: > > If the counted packets are the packets flowing over the channel in the > > data plane, the loss measurement is said to operate in "direct mode". > > > Counting data plane packets can be process intensive. > > > Usually the each node (or line card) can only do actual packet counting > for > > > limited number of LSPs. Therefore, I suggest allowing B node to ignore A > > > node's LM when B is not ready to do the counting or send back a reply to > > > indicate the "not ready status". > > > > > > o Several options are possible for the negotiation: egress simply > > > ignore the request when it is not ready, egress sends back an error, > etc. > > > Ingress node doesn't need to start counting traffic until it gets > > > confirmation from the egress node. > > Indeed, and the last paragraph of Section 4.1.1 says as much. This was > > added as a result of our discussion. > > > Should allow options of either byte counter or packet counter. > > This is also in the text; see Section 1, the last paragraph of Section > > 2.1, and the 'B' data format flag (DFlag) in Section 3.1. > > > Thank you very much. > > Thanks for your review! > > -d > > > Linda Dunbar > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From wwwrun@core3.amsl.com Tue Jan 11 09:23:14 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 38F433A6A47; Tue, 11 Jan 2011 09:23:14 -0800 (PST) To: pmohapat@cisco.com, rajiva@cisco.com, bobthomas@alum.mit.edu, chenying220@huawei.com From: IETF Secretariat Message-Id: <20110111172314.38F433A6A47@core3.amsl.com> Date: Tue, 11 Jan 2011 09:23:14 -0800 (PST) Cc: mpls@ietf.org, housley@vigilsec.com, adrian.farrel@huawei.com, rcallon@juniper.net, stbryant@cisco.com, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: HUAWEI TECHNOLOGIES CO., LTD's Statement about IPR related to RFC 5919 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:23:14 -0000 Dear Pradosh Mohapatra, Rajiv Asati, Bob Thomas, Emily Chen: An IPR disclosure that pertains to your RFC entitled "Signaling LDP Label Advertisement Completion" (RFC5919) was submitted to the IETF Secretariat on 2010-12-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1465/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to RFC 5919." The IETF Secretariat From ldunbar@huawei.com Tue Jan 11 11:53:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46CC3A67D2; Tue, 11 Jan 2011 11:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.837 X-Spam-Level: X-Spam-Status: No, score=-105.837 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXy6uf3e1xjv; Tue, 11 Jan 2011 11:53:35 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id C06E63A6AA0; Tue, 11 Jan 2011 11:53:35 -0800 (PST) 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 <0LEV00MA8JD4RH@usaga02-in.huawei.com>; Tue, 11 Jan 2011 11:55:53 -0800 (PST) Received: from L735042 ([10.124.12.121]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV0084QJD3QI@usaga02-in.huawei.com>; Tue, 11 Jan 2011 11:55:52 -0800 (PST) Date: Tue, 11 Jan 2011 13:55:51 -0600 From: Linda Dunbar In-reply-to: <48AA81F4-C02E-48F5-95BF-0159CFAB682C@niven-jenkins.co.uk> To: 'Ben Niven-Jenkins' Message-id: <00bc01cbb1c9$8ceac4d0$790c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_aiZ8cClfPmqLJcHkHVMzAA)" Thread-index: Acuw7A+P5Ld48maVS9u8IMoWvmCnMQAzrYbg References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> <9BCECFE9-04D8-4E8F-A01A-55D76C0E64C9@niven-jenkins.co.uk> <009501cbb0e3$665cbe90$790c7c0a@china.huawei.com> <48AA81F4-C02E-48F5-95BF-0159CFAB682C@niven-jenkins.co.uk> Cc: mpls-tp@ietf.org, mpls@ietf.org Subject: Re: [mpls] [mpls-tp] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:53:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aiZ8cClfPmqLJcHkHVMzAA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Ben and colleagues: You said " But you suggest edit does not suggest a slower transmission rate it states the querier should stop transmission", Two comments: 1. I think "slower transmission rate by querier" should be included in the text. 2. I suggested that querier may choose not starting counting (not transmission) until a positive feedback from Far End has been received. Based on the discussion over this email thread, do people think the following text is more appropriate? When initiating an LM operation, the far end may require a period of time to become ready for the requested measurement operation or the far end may not be able to support the requested measurement. During this period Under those circumstances, LM queries MAY simply be discarded, and the querier expecting a response SHOULD be prepared for this situation. The frequency of the initial LM for requesting starting the measurement should be slow, so that there is enough time for far end to check if the requested measurement can be done. The querier should abort the measurement after not receiving any positive feedback when a specified timer expires. setting a timer to differentiate between an acceptable initialization delay and a permanent unavailability condition at the far end. Alternatively, the receiver MAY respond, possibly in a rate-limited manner, to queries received during this period with an appropriate notification code. Since counting transmitted packets at querier side will cost extra resources (or is not free), the querier doesn't need to start counting its transmitted packets until receiving a positive feedback from the far-end. Suggested text for LM/DM Interval: 2.7.10: LM Interval The interval may affect the accuracy of the packet loss count. From implementation point of view, the shorter the interval, the higher the processing cost to equipment. Querier should encode its intended interval in its LM Message. If the interval specified by the LM message can't be supported by the far end, the far end can simply ignore the LM requests by not responding anything or respond with an appropriate notification code indicating its minimum allowed LM interval. In the Section 3.1 LM Message Format, add an 8 (or 16) bits field for LM Interval. The Interval Unit should be in ms. Linda Dunbar -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Monday, January 10, 2011 11:29 AM To: Linda Dunbar Cc: 'Greg Mirsky'; mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] [mpls] Questions on "draft-ietf-mpls-loss-delay-00" Linda, On 10 Jan 2011, at 16:28, Linda Dunbar wrote: > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > 1) The edits suggested by Linda change the semantics from suggesting a querier maintain a timer to allow for the receiving end to "get its act together" to if the receiving end doesn't get its act together within X packets stop sending LM. Is that really what's intended? I would expect the time taken for the receiving end "to get its act together" would not be a function of the LM transmission rate and therefore using transmission rate to guess whether the receiving end is dead Vs getting itself ready doesn't sound sensible. > > > [Linda] The reason for suggesting Initiator to have slower transmission rate is to minimize processing needed at the Initiator before Far End committing to the counting. > But you suggest edit does not suggest a slower transmission rate it states the querier should stop transmission! > We have considered implementing this feature on our products and discovered that it DOES take some time for the Central CPU to receive the Counting Request (as LM in this draft), check if the requested Counting can be supported, pass the request to the corresponding line card, and get confirmation from the Line card. Sometimes, the Far End can't perform the requested Counting because it is performing counting for requests from other nodes. > I accept that a receiver may take some time to configure itself for counting and that the time it takes may be a function of other things it is doing. What I am saying is that the time it takes is never a function of the interval being configured. > 2) I don't like the final sentence suggesting queriers should delay counting transmitted packets until receiving a positive response because doing so costs resources. It sounds like an internal implementation decision that has nothing to do with interoperability and therefore irrelevant. > > > [Linda]I agree with your point that that the Source Node performing or not performing the counting before receiving the positive feedback from Far End is not interoperability issue. Maybe it can be a recommendation? > > But it is necessary for Source node to abort the effort after not receiving the positive feedback after sometime (like X number of LM or timer expires). > At some point, if the querier has not received a positive response it must abort the operation. The original text suggest maintaing a timer. Your edit suggested making ti a function of packets sent. I am saying the former seems more sensible than the latter to me. > 4) Giving the receiving end the opportunity to reply with "I can;t support the rate you're asking for it's too fast for me" sounds attractive but I am not sure it is in practice if one thinks how such functionality is likely to be used. If an operator is going to turn it on with the thinking that performing LM of some sort is important regardless of the LM interval then negotiating a shorter interval may have value. However I don't expect that to be the case. I would expect an operator to pre-plan what interval they need given their knowledge of their network and the accuracy they desire, having the network change that may well cause unexpected consequences. In such a scenario I think it's better to let the receiver "hard fail" and the operator can investigate rather than have the network re-configure and the re-configuration go unnoticed, after all LM failing does not impact the ability of the network to actually forward packets. > > > [Linda] Do you mean that Receiver can ignore the LMs if the Interval specified in the message is more than it can handle? That is one option. The background to my thinking is: I assume that LM will be turned on explicitly (i.e. it will not be on by default) I assume that LM is turned on for a reason, e.g. because an operator needs to support an SLA involving packet loss. The interval may affect the accuracy of the packet loss count. I expect operators would rather LM "hard fail" rather than have the network re-configure automatically to a different interval because an SLA calculation (or whatever else is relying on the LM) could become inaccurate and no-one would know unless they really dug deep into what the network was doing. The network re-configuring itself in order to repair itself so it can continue to forward packets is one thing. The network reconfiguring non-forwarding related features itself because it believes it knows what to do better than the person who designed & configured it could lead to all sorts of trouble in the field IMO. Ben --Boundary_(ID_aiZ8cClfPmqLJcHkHVMzAA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: [mpls-tp] [mpls] Questions on = "draft-ietf-mpls-loss-delay-00"

Ben and colleagues:

You said = " But you suggest edit does not suggest a = slower transmission rate it states the querier should stop transmission",

Two comments: =

1.      I think “slower transmission rate by = querier” should be included = in the text.

2.      I = suggested that querier may = choose not starting counting (not transmission) until a = positive feedback from Far End has been received.

Based on the discussion over this email = thread, = do people think the following text is more appropriate?

      When initiating an LM operation, the far end = may require a period of time to become ready for the requested = measurement operation or the = far end may not be able to support the requested = measurement. = During this = period Under those circumstances, LM queries MAY = simply be discarded, and the querier expecting a response SHOULD be = prepared for this situation. The = frequency of the initial LM for requesting starting the measurement should be = slow, so that there is enough time for far end to check if the requested measurement can be = done. The querier should abort the measurement after = not receiving any positive = feedback when a = specified timer expires. = setting a timer to differentiate between = an acceptable initialization delay and a permanent unavailability = condition at the far end. Alternatively, the receiver MAY respond, possibly in a = rate-limited manner, to queries received during this period with an = appropriate notification code. Since counting transmitted packets at querier = side will cost extra resources (or is not free), the querier doesn’t need = to start = counting its = transmitted packets until receiving a positive feedback from the = far-end.

Suggested text for LM/DM = Interval:

      2.7.10: LM Interval

      The interval may affect the = accuracy of the packet loss count. = From = implementation point of view, the shorter the interval, the higher the = processing cost to equipment. Querier should encode its intended interval in its LM = Message. If = the = interval = specified by the LM = message can’t = be supported by = the far end, the far = end can = simply ignore the LM = requests = by not = responding anything or respond with = an appropriate notification code indicating its minimum allowed LM interval.  

In the Section 3.1 LM Message Format, = add an 8 (or 16) bits = field for LM Interval. The Interval = Unit should be in ms.

Linda = Dunbar

-----Original Message-----
From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
Sent: Monday, January 10, 2011 11:29 AM
To: Linda Dunbar
Cc: = 'Greg Mirsky'; mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] Questions on = "draft-ietf-mpls-loss-delay-00"

Linda,

On 10 Jan = 2011, at 16:28, Linda Dunbar = wrote:

> From: = Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]

> =

> 1) The = edits suggested by Linda change the semantics from suggesting a querier = maintain a timer to allow for the receiving end to "get its act = together" to if the receiving end doesn't get its act together within X packets stop sending LM. Is = that really what's intended? I would expect the time taken for the = receiving end "to get its act together" would not be a = function of the LM transmission rate and therefore using = transmission rate to guess whether the receiving end is dead Vs = getting itself ready doesn't sound sensible.

> =

> =

> = [Linda] The reason for suggesting Initiator to have slower transmission = rate is to minimize processing needed at the Initiator before Far End = committing to the counting.

> =

But you = suggest edit does not suggest a slower transmission rate it states the = querier should stop = transmission!

> We = have considered implementing this feature on our products and discovered = that it DOES take some time for the Central CPU to receive the Counting = Request (as LM in this draft), check if the requested Counting can be = supported, pass the request to the = corresponding line card, and get confirmation from the Line card. = Sometimes, the Far End can't perform the requested Counting because it = is performing counting for requests from other nodes.

> =

I accept = that a receiver may take some time to = configure itself for counting and that the time it takes may be a = function of other things it is doing. What I am saying is that the time = it takes is never a function of the interval being = configured.

> 2) I = don't like the final sentence = suggesting queriers should delay counting transmitted packets until = receiving a positive response because doing so costs resources. It = sounds like an internal implementation decision that has nothing to do = with interoperability and therefore irrelevant.

> =

> =

> = [Linda]I agree with your point that that the Source Node performing or = not performing the counting before receiving the positive feedback from = Far End is not interoperability issue. Maybe it can be a = recommendation?

> =

> But it = is necessary for Source node to abort = the effort after not receiving the positive feedback after sometime = (like X number of LM or timer expires).

> =

At some = point, if the querier has not received a positive response it must abort = the operation. The original text suggest maintaing a timer. Your edit suggested making ti a = function of packets sent. I am saying the former seems more sensible = than the latter to me.

> 4) = Giving the receiving end the opportunity to reply with "I can;t = support the rate you're asking for it's too fast for me" sounds attractive but I am not sure = it is in practice if one thinks how such functionality is likely to be = used. If an operator is going to turn it on with the thinking that = performing LM of some sort is important regardless of the LM interval = then = negotiating a shorter interval may have value. However I don't expect = that to be the case. I would expect an operator to pre-plan what = interval they need given their knowledge of their network and the = accuracy they desire, having the network change that may well cause = unexpected consequences. In such a scenario I think it's better to let = the receiver "hard fail" and the operator can investigate = rather than have the network re-configure and the re-configuration go = unnoticed, after all LM failing does not impact the ability of the = network to actually forward packets.

> =

> =

> = [Linda] Do you mean that Receiver can ignore the LMs if the Interval = specified in the message is more than it can handle?

That is one = option.

The = background to my thinking is:

I assume = that LM will be turned on explicitly (i.e. it will not be on by = default)

I assume = that LM is turned on for a reason, e.g. because an operator needs to = support an SLA involving packet loss.

The = interval may affect the accuracy of the packet loss count.

I expect = operators would rather LM "hard fail" rather than have the = network re-configure automatically to a different interval because an = SLA calculation (or whatever else is relying on the LM) could become = inaccurate and no-one would know unless they really dug deep into what the network was doing.

The network = re-configuring itself in order to repair itself so it can continue to = forward packets is one thing.

The network = reconfiguring non-forwarding related features itself because it believes = it knows what to do better than the = person who designed & configured it could lead to all sorts of = trouble in the field IMO.

Ben

 

= --Boundary_(ID_aiZ8cClfPmqLJcHkHVMzAA)-- From nurit.sprecher@nsn.com Thu Jan 13 00:16:01 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBBD3A6AB7 for ; Thu, 13 Jan 2011 00:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.152 X-Spam-Level: X-Spam-Status: No, score=-4.152 tagged_above=-999 required=5 tests=[AWL=1.847, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2BnZnMTBVUm for ; Thu, 13 Jan 2011 00:15:58 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 0D15C3A69C2 for ; Thu, 13 Jan 2011 00:15:54 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0D8IDB1020183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jan 2011 09:18:13 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0D8IAjE022285; Thu, 13 Jan 2011 09:18:13 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 09:18:11 +0100 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: Thu, 13 Jan 2011 09:18:09 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D2AE5E0.90703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuwtRGLd9xxAStESUK8g5O/l8FWKgCRGKOQ References: <4D2AE5E0.90703@cisco.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 13 Jan 2011 08:18:11.0749 (UTC) FILETIME=[6B08AD50:01CBB2FA] Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 08:16:01 -0000 Hi, I support the proposal. We have a cooperative agreement with the ITU-T concerning the work on MPLS-TP.=20 The agreement recognizes the design authority of the IETF for MPLS and it is agreed that the development of the protocol should be done in the IETF using the IETF processes. The ITU-T should not take any uncoordinated action in the development of the MPLS_TP protocol.=20 We would appreciate if the ITU-T continues (as it committed to) with the collaborative work with the IETF on MPLS_TP and contributes from its expertise to the development of the protocol using the IETF processes.=20 We would also not like to see two competing solutions which may confuse the Industry, bloat operational and capital expenses and badly affect the end customer.=20 Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant Sent: Monday, January 10, 2011 12:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday=20 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF=20 Standards process. Specifically it uses material from=20 draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of=20 draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix=20 string "draft-bhh" this clearly identifies it to the reader as a=20 document expressing the personal technical views of the authors and=20 hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an=20 MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report=20 of the first meeting of Working Party 3/15 Transport network structures=20 (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at=20 http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF=20 MPLS-TP OAM design before advancing this document through the ITU-T=20 publication process. The MPLS Working Group would also like to draw the attention of ITU-T=20 SG15 to the IETF copyright rules. Please see=20 http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 0091228.htm=20 for further details. Since this draft Recommendation contains text in which the ITU-T SG15=20 has proposed making changes to IETF protocols without the approval of=20 the IETF, the MPLS Working Group have referred this liaison to the IAB=20 for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Feng.f.Huang@alcatel-sbell.com.cn Thu Jan 13 01:32:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57A63A6AF1; Thu, 13 Jan 2011 01:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uuygv1w93QbC; Thu, 13 Jan 2011 01:32:29 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id 694B73A6AC5; Thu, 13 Jan 2011 01:32:28 -0800 (PST) X-AuditID: ac189297-b7cc5ae00000285e-bb-4d2ec73857ab Received: from cnshgsbhs01.ad4.ad.alcatel.com (smtp.cn.alcatel-lucent.com [172.24.146.145]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 68.1C.10334.837CE2D4; Thu, 13 Jan 2011 17:34:48 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 17:34:38 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 17:34:37 +0800 Message-ID: In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Thread-Index: AcuwtRGLd9xxAStESUK8g5O/l8FWKgCRGKOQAAJfcJA= References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> From: "HUANG Feng F" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , X-OriginalArrivalTime: 13 Jan 2011 09:34:38.0788 (UTC) FILETIME=[191F4840:01CBB305] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: mpls-tp@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 09:32:31 -0000 Hi,Nurit, I can't agree with you. Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport Network by many applications and public demo and it has many = supporters. I am wondering why this solutions is not standardized in = ietf?=20 Further more, I really don't agree with your last sentence, this = solution is asked by customers in Industry, you can see at least 7 = providers in global support this solution. B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 2011=C4=EA1=D4=C213=C8=D5 16:18 To: stbryant@cisco.com; mpls@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] Hi, I support the proposal. We have a cooperative agreement with the ITU-T concerning the work on = MPLS-TP.=20 The agreement recognizes the design authority of the IETF for MPLS and = it is agreed that the development of the protocol should be done in the = IETF using the IETF processes. The ITU-T should not take any = uncoordinated action in the development of the MPLS_TP protocol.=20 We would appreciate if the ITU-T continues (as it committed to) with the = collaborative work with the IETF on MPLS_TP and contributes from its = expertise to the development of the protocol using the IETF processes.=20 We would also not like to see two competing solutions which may confuse = the Industry, bloat operational and capital expenses and badly affect = the end customer.=20 Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Stewart Bryant Sent: Monday, January 10, 2011 12:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam = [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday = 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org = yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, = kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF = Standards process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix = string "draft-bhh" this clearly identifies it to the reader as a = document expressing the personal technical views of the authors and = hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an = MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report = of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at = http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF = MPLS-TP OAM design before advancing this document through the ITU-T = publication process. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 0091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 = has proposed making changes to IETF protocols without the approval of = the IETF, the MPLS Working Group have referred this liaison to the IAB = for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Thu Jan 13 01:37:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC3428C0DE for ; Thu, 13 Jan 2011 01:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpoQZRyhiUsp for ; Thu, 13 Jan 2011 01:37:00 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id D63ED28C0CE for ; Thu, 13 Jan 2011 01:36:58 -0800 (PST) X-AuditID: 93eaf2e7-b7c67ae0000028de-2d-4d2ec845c1f1 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 35.AB.10462.548CE2D4; Thu, 13 Jan 2011 11:39:17 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 13 Jan 2011 11:40:59 +0200 From: Alexander Vainshtein To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "stbryant@cisco.com" Date: Thu, 13 Jan 2011 11:40:57 +0200 Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuwtRGLd9xxAStESUK8g5O/l8FWKgCRGKOQAAMfcKA= Message-ID: References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> 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: AAAAARchi5M= Cc: "mpls@ietf.org" Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 09:37:03 -0000 +1 Regards, Sasha -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: Thursday, January 13, 2011 10:18 AM To: stbryant@cisco.com; mpls@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam= [Ref043.02] Hi, I support the proposal. We have a cooperative agreement with the ITU-T concerning the work on MPLS-TP.=20 The agreement recognizes the design authority of the IETF for MPLS and it is agreed that the development of the protocol should be done in the IETF using the IETF processes. The ITU-T should not take any uncoordinated action in the development of the MPLS_TP protocol.=20 We would appreciate if the ITU-T continues (as it committed to) with the collaborative work with the IETF on MPLS_TP and contributes from its expertise to the development of the protocol using the IETF processes.=20 We would also not like to see two competing solutions which may confuse the Industry, bloat operational and capital expenses and badly affect the end customer.=20 Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant Sent: Monday, January 10, 2011 12:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday=20 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF=20 Standards process. Specifically it uses material from=20 draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of=20 draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix=20 string "draft-bhh" this clearly identifies it to the reader as a=20 document expressing the personal technical views of the authors and=20 hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an=20 MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report=20 of the first meeting of Working Party 3/15 Transport network structures=20 (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at=20 http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF=20 MPLS-TP OAM design before advancing this document through the ITU-T=20 publication process. The MPLS Working Group would also like to draw the attention of ITU-T=20 SG15 to the IETF copyright rules. Please see=20 http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 0091228.htm=20 for further details. Since this draft Recommendation contains text in which the ITU-T SG15=20 has proposed making changes to IETF protocols without the approval of=20 the IETF, the MPLS Working Group have referred this liaison to the IAB=20 for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Thu Jan 13 01:45:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1103A6AE3; Thu, 13 Jan 2011 01:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.214 X-Spam-Level: X-Spam-Status: No, score=-4.214 tagged_above=-999 required=5 tests=[AWL=1.785, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLyb7EBlcPyc; Thu, 13 Jan 2011 01:45:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id B25983A69E5; Thu, 13 Jan 2011 01:45:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0D9jC3D026559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jan 2011 10:45:12 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0D9jApU009968; Thu, 13 Jan 2011 10:45:11 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 10:45:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2011 10:45:09 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Thread-Index: AcuwtRGLd9xxAStESUK8g5O/l8FWKgCRGKOQAAJfcJAAAJGFwA== References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext HUANG Feng F" , , X-OriginalArrivalTime: 13 Jan 2011 09:45:10.0233 (UTC) FILETIME=[917E2490:01CBB306] Cc: mpls-tp@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 09:45:03 -0000 Hi Feng, I did not refer to specific solution, validity and acceptance of a solution, so I cannot see to what you disagree and how your response fit to mine. If you think that you have a good solution which is proven and supported please discuss it in the IETF and try to get support for it! I would like the ITU-T to continue with its collaborative agreement with the IETF and ensure that the development of the protocol is done as agreed and supported by SG15 using the IETF processes. I will support a single global solution interoperable solution (whatever the solution is). Best regards, Nurit -----Original Message----- From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] Sent: Thursday, January 13, 2011 11:35 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org Cc: mpls-tp@ietf.org Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Hi,Nurit, I can't agree with you. Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet Transport Network by many applications and public demo and it has many supporters. I am wondering why this solutions is not standardized in ietf? Further more, I really don't agree with your last sentence, this solution is asked by customers in Industry, you can see at least 7 providers in global support this solution. B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 2011$BG/(J1$B7n(J13$BF|(J 16:18 To: stbryant@cisco.com; mpls@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Hi, I support the proposal. We have a cooperative agreement with the ITU-T concerning the work on MPLS-TP. The agreement recognizes the design authority of the IETF for MPLS and it is agreed that the development of the protocol should be done in the IETF using the IETF processes. The ITU-T should not take any uncoordinated action in the development of the MPLS_TP protocol. We would appreciate if the ITU-T continues (as it committed to) with the collaborative work with the IETF on MPLS_TP and contributes from its expertise to the development of the protocol using the IETF processes. We would also not like to see two competing solutions which may confuse the Industry, bloat operational and capital expenses and badly affect the end customer. Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant Sent: Monday, January 10, 2011 12:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ======= Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 0091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. ========= _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Feng.f.Huang@alcatel-sbell.com.cn Thu Jan 13 02:29:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B443A6B60; Thu, 13 Jan 2011 02:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.462 X-Spam-Level: X-Spam-Status: No, score=0.462 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4Q8KZ8gep7q; Thu, 13 Jan 2011 02:29:07 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id A75BF3A6B58; Thu, 13 Jan 2011 02:29:06 -0800 (PST) X-AuditID: ac189297-b7cc5ae00000285e-82-4d2ed47f07cc Received: from cnshgsbhs01.ad4.ad.alcatel.com (smtp.cn.alcatel-lucent.com [172.24.146.145]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id F4.8F.10334.F74DE2D4; Thu, 13 Jan 2011 18:31:27 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 18:31:17 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 18:31:15 +0800 Message-ID: In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Thread-Index: AcuwtRGLd9xxAStESUK8g5O/l8FWKgCRGKOQAAJfcJAAAJGFwAABmzRA References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> From: "HUANG Feng F" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , , X-OriginalArrivalTime: 13 Jan 2011 10:31:17.0394 (UTC) FILETIME=[02D96720:01CBB30D] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: mpls-tp@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:29:09 -0000 Hi, Nurit, Please see in line. B.R. Feng =20 -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn.com]=20 Sent: 2011=C4=EA1=D4=C213=C8=D5 17:45 To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org Cc: mpls-tp@ietf.org Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] Hi Feng, I did not refer to specific solution, validity and acceptance of a = solution, so I cannot see to what you disagree and how your response fit = to mine.=20 If you think that you have a good solution which is proven and supported = please discuss it in the IETF and try to get support for it!=20 HF> The solution has been submitted to ietf for 2 year! I would like the ITU-T to continue with its collaborative agreement with = the IETF and ensure that the development of the protocol is done as = agreed and supported by SG15 using the IETF processes. HF> I can't image the meaning of cooperation is that ITU-T do nothing = and just obey IETF's process! I will support a single global solution interoperable solution (whatever = the solution is).=20 Best regards, Nurit -----Original Message----- From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] Sent: Thursday, January 13, 2011 11:35 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; = mpls@ietf.org Cc: mpls-tp@ietf.org Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] Hi,Nurit, I can't agree with you. Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport Network by many applications and public demo and it has many = supporters. I am wondering why this solutions is not standardized in = ietf?=20 Further more, I really don't agree with your last sentence, this = solution is asked by customers in Industry, you can see at least 7 = providers in global support this solution. B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 2011=C4=EA1=D4=C213=C8=D5 16:18 To: stbryant@cisco.com; mpls@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] Hi, I support the proposal. We have a cooperative agreement with the ITU-T concerning the work on = MPLS-TP.=20 The agreement recognizes the design authority of the IETF for MPLS and = it is agreed that the development of the protocol should be done in the = IETF using the IETF processes. The ITU-T should not take any = uncoordinated action in the development of the MPLS_TP protocol.=20 We would appreciate if the ITU-T continues (as it committed to) with the = collaborative work with the IETF on MPLS_TP and contributes from its = expertise to the development of the protocol using the IETF processes.=20 We would also not like to see two competing solutions which may confuse = the Industry, bloat operational and capital expenses and badly affect = the end customer.=20 Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Stewart Bryant Sent: Monday, January 10, 2011 12:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam = [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday = 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org = yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, = kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF = Standards process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix = string "draft-bhh" this clearly identifies it to the reader as a = document expressing the personal technical views of the authors and = hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an = MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report = of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at = http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF = MPLS-TP OAM design before advancing this document through the ITU-T = publication process. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 0091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 = has proposed making changes to IETF protocols without the approval of = the IETF, the MPLS Working Group have referred this liaison to the IAB = for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Thu Jan 13 04:52:00 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755F63A6B79; Thu, 13 Jan 2011 04:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.271 X-Spam-Level: X-Spam-Status: No, score=-4.271 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyjtQXxtU-b0; Thu, 13 Jan 2011 04:51:59 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8C3AE3A6B76; Thu, 13 Jan 2011 04:51:58 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0DCsC9L028832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jan 2011 13:54:12 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0DCs6nZ029522; Thu, 13 Jan 2011 13:54:12 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 13:54:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2011 13:54:05 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264033054B9@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Thread-Index: AcuwtRGLd9xxAStESUK8g5O/l8FWKgCRGKOQAAJfcJAAAJGFwAABmzRAAAQptcA= References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext HUANG Feng F" , , X-OriginalArrivalTime: 13 Jan 2011 12:54:09.0802 (UTC) FILETIME=[F8670EA0:01CBB320] Cc: mpls-tp@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 12:52:00 -0000 Hi Feng, You say " HF> I can't image the meaning of cooperation is that ITU-T do nothing and just obey IETF's process!" It seems that you are not familiar with the agreement on the joint work. The ITU-T experts are called to contribute to (also by the SG15) to assist in the development the development of the protocol in the IETF using the IETF standard processes... Best regards, Nurit -----Original Message----- From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] Sent: Thursday, January 13, 2011 12:31 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org Cc: mpls-tp@ietf.org Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Hi, Nurit, Please see in line. B.R. Feng -----Original Message----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.com] Sent: 2011$BG/(J1$B7n(J13$BF|(J 17:45 To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org Cc: mpls-tp@ietf.org Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Hi Feng, I did not refer to specific solution, validity and acceptance of a solution, so I cannot see to what you disagree and how your response fit to mine. If you think that you have a good solution which is proven and supported please discuss it in the IETF and try to get support for it! HF> The solution has been submitted to ietf for 2 year! I would like the ITU-T to continue with its collaborative agreement with the IETF and ensure that the development of the protocol is done as agreed and supported by SG15 using the IETF processes. HF> I can't image the meaning of cooperation is that ITU-T do nothing and just obey IETF's process! I will support a single global solution interoperable solution (whatever the solution is). Best regards, Nurit -----Original Message----- From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] Sent: Thursday, January 13, 2011 11:35 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org Cc: mpls-tp@ietf.org Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Hi,Nurit, I can't agree with you. Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet Transport Network by many applications and public demo and it has many supporters. I am wondering why this solutions is not standardized in ietf? Further more, I really don't agree with your last sentence, this solution is asked by customers in Industry, you can see at least 7 providers in global support this solution. B.R. Feng -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: 2011$BG/(J1$B7n(J13$BF|(J 16:18 To: stbryant@cisco.com; mpls@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Hi, I support the proposal. We have a cooperative agreement with the ITU-T concerning the work on MPLS-TP. The agreement recognizes the design authority of the IETF for MPLS and it is agreed that the development of the protocol should be done in the IETF using the IETF processes. The ITU-T should not take any uncoordinated action in the development of the MPLS_TP protocol. We would appreciate if the ITU-T continues (as it committed to) with the collaborative work with the IETF on MPLS_TP and contributes from its expertise to the development of the protocol using the IETF processes. We would also not like to see two competing solutions which may confuse the Industry, bloat operational and capital expenses and badly affect the end customer. Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant Sent: Monday, January 10, 2011 12:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ======= Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 0091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. ========= _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ben@niven-jenkins.co.uk Thu Jan 13 05:50:26 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0233A6B89; Thu, 13 Jan 2011 05:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.052 X-Spam-Level: X-Spam-Status: No, score=-101.052 tagged_above=-999 required=5 tests=[AWL=-2.103, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-pwhW+LgcXf; Thu, 13 Jan 2011 05:50:24 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 191733A6B8A; Thu, 13 Jan 2011 05:50:24 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-122-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PdNbW-00080J-Vn; Thu, 13 Jan 2011 13:52:45 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=GB2312 From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 13 Jan 2011 13:52:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk> References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> To: HUANG Feng F X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: mpls@ietf.org, mpls-tp@ietf.org, stbryant@cisco.com Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 13:50:26 -0000 Feng, colleagues, On 13 Jan 2011, at 10:31, HUANG Feng F wrote: > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn.com]=20 > Sent: 2011=C4=EA1=D4=C213=C8=D5 17:45 > To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org > Cc: mpls-tp@ietf.org > Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] >=20 > Hi Feng, > I did not refer to specific solution, validity and acceptance of a = solution, so I cannot see to what you disagree and how your response fit = to mine.=20 > If you think that you have a good solution which is proven and = supported please discuss it in the IETF and try to get support for it!=20= >=20 > HF> The solution has been submitted to ietf for 2 year! >=20 We seem to be going round the same loop we've being going round for a = while. An OAM solution (draft-bhh) was submitted for consideration and the MPLS = WG decided to select a different proposal for MPLS-TP OAM. That's life, = that's how standards development works because standards development is = "design by committee" and that means that the decisions of the = "committee" are unlikely to please everyone all of the time. > I would like the ITU-T to continue with its collaborative agreement = with the IETF and ensure that the development of the protocol is done as = agreed and supported by SG15 using the IETF processes. >=20 > HF> I can't image the meaning of cooperation is that ITU-T do nothing = and just obey IETF's process! >=20 It isn't, but that collaborative agreement recognised IETF as being the = protocol design authority for MPLS & MPLS-TP, which means IETF have the = final decision on what the MPLS-TP protocols are and how they work. What you seem to be arguing for is that IETF just obey the demands of = other organisations, i.e. to paraphrase your argument: "CCSA have used = draft-bhh in one of their standards so IETF must rubber stamp it as = being part of MPLS-TP". It was similar behaviour (ITU-T defining MPLS extensions without = consultation with IETF) that causes the original bun fight that lead to = the JWT etc being formed and much time being expended on politics rather = than technical work to get us to where we are. I suggest we stop trying to re-ignite a debate as to whether the MPLS-TP = OAM solution should include draft-bhh or not as the decision has been = made. Let's accept that decision. In future if another standards body wants to use an Internet-Draft as = the basis for one of their standards they would be well advised to = enquire of the IETF as to the status and likely future of the = Internet-Draft before making any decisions and we could avoid these = sorts of situations occurring in the first place. Ben P.S. I think the original liaison text is fine as-is. > I will support a single global solution interoperable solution = (whatever the solution is).=20 > Best regards, > Nurit >=20 > -----Original Message----- > From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] > Sent: Thursday, January 13, 2011 11:35 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; = mpls@ietf.org > Cc: mpls-tp@ietf.org > Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] >=20 > Hi,Nurit, > I can't agree with you. > Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport Network by many applications and public demo and it has many = supporters. I am wondering why this solutions is not standardized in = ietf?=20 > Further more, I really don't agree with your last sentence, this = solution is asked by customers in Industry, you can see at least 7 = providers in global support this solution. >=20 > B.R. > Feng >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: 2011=C4=EA1=D4=C213=C8=D5 16:18 > To: stbryant@cisco.com; mpls@ietf.org > Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam[Ref043.02] >=20 > Hi, > I support the proposal. > We have a cooperative agreement with the ITU-T concerning the work on = MPLS-TP.=20 > The agreement recognizes the design authority of the IETF for MPLS and = it is agreed that the development of the protocol should be done in the = IETF using the IETF processes. The ITU-T should not take any = uncoordinated action in the development of the MPLS_TP protocol.=20 > We would appreciate if the ITU-T continues (as it committed to) with = the collaborative work with the IETF on MPLS_TP and contributes from its = expertise to the development of the protocol using the IETF processes.=20= > We would also not like to see two competing solutions which may = confuse the Industry, bloat operational and capital expenses and badly = affect the end customer.=20 > Best regards, > Nurit >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of ext Stewart Bryant > Sent: Monday, January 10, 2011 12:57 PM > To: mpls@ietf.org > Subject: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam [Ref043.02] >=20 > I propose to send the following Liaison Response to the ITU-T on = Friday 14th January and am posting it to the MPLS WG list for review. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > Response to Updated draft Recommendation G.tpoam [Ref 043.02] >=20 > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org = yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com, hhelvoort@huawei.com = malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com >=20 > For Action >=20 > The MPLS Working Group notes that this document contains text = describing >=20 > MPLS-TP OAM protocols not designed and standardized using the IETF = Standards process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06. >=20 > We wish to draw your attention to the status section of > draft-bhh-mpls-tp-oam-y1731-06 which states: >=20 > "Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress". >=20 > Please also note that since the draft filename starts with the prefix = string "draft-bhh" this clearly identifies it to the reader as a = document expressing the personal technical views of the authors and = hence hence as a document that that does not have any acknowledged level >=20 > of IETF consensus. >=20 > Since the text of draft Recommendation for G.tpoam is based on an = MPLS-TP OAM protocol not designed within the IETF Standards Process this >=20 > is a breach of the SG15 agreement with the IETF as published in Report = of the first meeting of Working Party 3/15 Transport network structures > (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at = http://www.itu.int/md/T09-SG15-R-0004/en >=20 > Please confirm that the ITU-T intends to continue with the joint work = on >=20 > MPLS-TP and that the ITU-T will align this recommendation with the = IETF MPLS-TP OAM design before advancing this document through the ITU-T = publication process. >=20 > The MPLS Working Group would also like to draw the attention of ITU-T > SG15 to the IETF copyright rules. Please see > = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 > 0091228.htm > for further details. >=20 > Since this draft Recommendation contains text in which the ITU-T SG15 = has proposed making changes to IETF protocols without the approval of = the IETF, the MPLS Working Group have referred this liaison to the IAB = for their consideration. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Thu Jan 13 06:05:50 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0153A6B27; Thu, 13 Jan 2011 06:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ2nc+T022vx; Thu, 13 Jan 2011 06:05:48 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id AF6A83A6B2C; Thu, 13 Jan 2011 06:05:47 -0800 (PST) X-AuditID: 93eaf2e7-b7c67ae0000028de-ca-4d2f074ba9f2 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id B0.15.10462.B470F2D4; Thu, 13 Jan 2011 16:08:11 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 13 Jan 2011 16:08:07 +0200 From: Alexander Vainshtein To: Ben Niven-Jenkins Date: Thu, 13 Jan 2011 16:09:51 +0200 Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Thread-Index: AcuzKS0sCnEzojKMRA2BY4fOGvXd7QAAiPEA Message-ID: References: <4D2AE5E0.90703@cisco.com> <077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk> In-Reply-To: <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAhcg2WYXIYuT Cc: "mpls@ietf.org" , "stbryant@cisco.com" , HUANG Feng F , "mpls-tp@ietf.org" Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:05:50 -0000 Ben, all, It has been said that design of standards by committee is the worst form of= design except all those other forms that have been tried from time to time= ... Regards, Sasha -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: Thursday, January 13, 2011 3:53 PM To: HUANG Feng F Cc: mpls@ietf.org; mpls-tp@ietf.org; stbryant@cisco.com Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam= [Ref043.02] Feng, colleagues, On 13 Jan 2011, at 10:31, HUANG Feng F wrote: > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn.= com]=20 > Sent: 2011=1B$BG/=1B(B1=1B$B7n=1B(B13=1B$BF|=1B(B 17:45 > To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org > Cc: mpls-tp@ietf.org > Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpo= am[Ref043.02] >=20 > Hi Feng, > I did not refer to specific solution, validity and acceptance of a soluti= on, so I cannot see to what you disagree and how your response fit to mine.= =20 > If you think that you have a good solution which is proven and supported = please discuss it in the IETF and try to get support for it!=20 >=20 > HF> The solution has been submitted to ietf for 2 year! >=20 We seem to be going round the same loop we've being going round for a while= . An OAM solution (draft-bhh) was submitted for consideration and the MPLS WG= decided to select a different proposal for MPLS-TP OAM. That's life, that'= s how standards development works because standards development is "design = by committee" and that means that the decisions of the "committee" are unli= kely to please everyone all of the time. > I would like the ITU-T to continue with its collaborative agreement with = the IETF and ensure that the development of the protocol is done as agreed = and supported by SG15 using the IETF processes. >=20 > HF> I can't image the meaning of cooperation is that ITU-T do nothing and= just obey IETF's process! >=20 It isn't, but that collaborative agreement recognised IETF as being the pro= tocol design authority for MPLS & MPLS-TP, which means IETF have the final = decision on what the MPLS-TP protocols are and how they work. What you seem to be arguing for is that IETF just obey the demands of other= organisations, i.e. to paraphrase your argument: "CCSA have used draft-bhh= in one of their standards so IETF must rubber stamp it as being part of MP= LS-TP". It was similar behaviour (ITU-T defining MPLS extensions without consultati= on with IETF) that causes the original bun fight that lead to the JWT etc b= eing formed and much time being expended on politics rather than technical = work to get us to where we are. I suggest we stop trying to re-ignite a debate as to whether the MPLS-TP OA= M solution should include draft-bhh or not as the decision has been made. L= et's accept that decision. In future if another standards body wants to use an Internet-Draft as the b= asis for one of their standards they would be well advised to enquire of th= e IETF as to the status and likely future of the Internet-Draft before maki= ng any decisions and we could avoid these sorts of situations occurring in = the first place. Ben P.S. I think the original liaison text is fine as-is. > I will support a single global solution interoperable solution (whatever = the solution is).=20 > Best regards, > Nurit >=20 > -----Original Message----- > From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] > Sent: Thursday, January 13, 2011 11:35 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@iet= f.org > Cc: mpls-tp@ietf.org > Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpo= am[Ref043.02] >=20 > Hi,Nurit, > I can't agree with you. > Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet Transp= ort Network by many applications and public demo and it has many supporters= . I am wondering why this solutions is not standardized in ietf?=20 > Further more, I really don't agree with your last sentence, this solu= tion is asked by customers in Industry, you can see at least 7 providers in= global support this solution. >=20 > B.R. > Feng >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of S= precher, Nurit (NSN - IL/Hod HaSharon) > Sent: 2011=1B$BG/=1B(B1=1B$B7n=1B(B13=1B$BF|=1B(B 16:18 > To: stbryant@cisco.com; mpls@ietf.org > Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpo= am[Ref043.02] >=20 > Hi, > I support the proposal. > We have a cooperative agreement with the ITU-T concerning the work on MPL= S-TP.=20 > The agreement recognizes the design authority of the IETF for MPLS and it= is agreed that the development of the protocol should be done in the IETF = using the IETF processes. The ITU-T should not take any uncoordinated actio= n in the development of the MPLS_TP protocol.=20 > We would appreciate if the ITU-T continues (as it committed to) with the = collaborative work with the IETF on MPLS_TP and contributes from its expert= ise to the development of the protocol using the IETF processes.=20 > We would also not like to see two competing solutions which may confuse t= he Industry, bloat operational and capital expenses and badly affect the en= d customer.=20 > Best regards, > Nurit >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of e= xt Stewart Bryant > Sent: Monday, January 10, 2011 12:57 PM > To: mpls@ietf.org > Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [= Ref043.02] >=20 > I propose to send the following Liaison Response to the ITU-T on Friday 1= 4th January and am posting it to the MPLS WG list for review. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > Response to Updated draft Recommendation G.tpoam [Ref 043.02] >=20 > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.or= g > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisc= o.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, stev= e.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, = kam.lam@alcatel-lucent.com >=20 > For Action >=20 > The MPLS Working Group notes that this document contains text describing >=20 > MPLS-TP OAM protocols not designed and standardized using the IETF Standa= rds process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731= -06. >=20 > We wish to draw your attention to the status section of > draft-bhh-mpls-tp-oam-y1731-06 which states: >=20 > "Internet-Drafts are draft documents valid for a maximum of six months an= d may be updated, replaced, or obsoleted by other documents at any time. It= is inappropriate to use Internet-Drafts as reference material or to cite t= hem other than as "work in progress". >=20 > Please also note that since the draft filename starts with the prefix str= ing "draft-bhh" this clearly identifies it to the reader as a document expr= essing the personal technical views of the authors and hence hence as a doc= ument that that does not have any acknowledged level >=20 > of IETF consensus. >=20 > Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP= OAM protocol not designed within the IETF Standards Process this >=20 > is a breach of the SG15 agreement with the IETF as published in Report of= the first meeting of Working Party 3/15 Transport network structures > (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at http://w= ww.itu.int/md/T09-SG15-R-0004/en >=20 > Please confirm that the ITU-T intends to continue with the joint work on >=20 > MPLS-TP and that the ITU-T will align this recommendation with the IETF M= PLS-TP OAM design before advancing this document through the ITU-T publicat= ion process. >=20 > The MPLS Working Group would also like to draw the attention of ITU-T > SG15 to the IETF copyright rules. Please see > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 > 0091228.htm > for further details. >=20 > Since this draft Recommendation contains text in which the ITU-T SG15 has= proposed making changes to IETF protocols without the approval of the IETF= , the MPLS Working Group have referred this liaison to the IAB for their co= nsideration. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From larryli888@yahoo.com.cn Thu Jan 13 06:53:17 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9872928C0FC for ; Thu, 13 Jan 2011 06:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFe-GxoBHlaZ for ; Thu, 13 Jan 2011 06:53:17 -0800 (PST) Received: from web15605.mail.cnb.yahoo.com (web15605.mail.cnb.yahoo.com [202.165.102.59]) by core3.amsl.com (Postfix) with SMTP id BAA0B28C0DB for ; Thu, 13 Jan 2011 06:53:16 -0800 (PST) Received: (qmail 56841 invoked by uid 60001); 13 Jan 2011 14:55:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1294930531; bh=6UmjHEMTc1iq3ioFKoMGK6N+kZvp10dnpCJLR8n+B6U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ka/wvzssMSqlWH/IbCxjrr6LAeltheZdAc9AUhMZM2+PS0IJj47znmuMGOx9mNUkxZv1I0nX12KuYVmpE2is7dayB9584Eja2QyhlWWiz/AVJBA4iCTgA6/frUOsvyRR7UBggWuSP5IA75mftxssXfUebXcuktwc+grmb6Ldv8I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vYy652xcB2kju3mk+z3IqEC+vJOe61yS7Cq3J7SE8VI7RiarKg3cJBIVQX3pKpZFulUfOPGozfULWFRyMrYaJf7is5Q1/GW3h2icfZXFhmtqZeCeWEPTgLWDpw09ugb9HLKVmssXprx+s0cWn3BpLVfGeOwHn0omPbNOogVk9u0=; Message-ID: <526321.56478.qm@web15605.mail.cnb.yahoo.com> X-YMail-OSG: jz0jIGoVM1nXK3dqnXMM7RFZ9eztXc2sGKMbUtafPLk6qN1 BUp_.A7wvNgLWgl6b7qwmfW35tA0q.1tZqxHSlR3x0DuCYblgaPPx2Ub9rsZ XUk.a8aKvqxkKwa4zwhxuhVyMiVwvendwOrO82rwaKVMVg1tmC1.tPhETkTh OrozDzvEJQd2OIfM1r8u72fq.0IXjHqZdhT3G5EewxxXC9PepQpYLWmBsgtl BE1ftUAcfZm1GFemUQZn0pvVAj0TxhxtdydpAaHRydwcMAML0E1A- Received: from [211.160.76.213] by web15605.mail.cnb.yahoo.com via HTTP; Thu, 13 Jan 2011 22:55:31 CST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Thu, 13 Jan 2011 22:55:31 +0800 (CST) From: Larry To: jingr@ties.itu.ch, ruiquan.jing@ties.itu.int In-Reply-To: <1294906173.4d2eb33dd1ffa@gold.itu.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:53:17 -0000 Hi, I don't think it is proper to send the LS to ITU-T because the text doe= sn't reflect the requirement from providers. Apparently, draft-bhh based OAM is the most mature solution currently. = It has been proved by more than 200,000 applications and is supported by a = lot of operators and vendors.=20 =20 Best regards, Han Li ************************************************************************* Han Li, Ph.D=20 China Mobile Research Institute Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 Fax: +86 10 63601087=20 MOBILE: 13501093385=20 ************************************************************************* --- 11=E5=B9=B41=E6=9C=8813=E6=97=A5=EF=BC=8C=E5=91=A8=E5=9B=9B, ruiquan.ji= ng@ties.itu.int =E5=86=99=E9=81=93=EF=BC=9A > =E5=8F=91=E4=BB=B6=E4=BA=BA: ruiquan.jing@ties.itu.int > =E4=B8=BB=E9=A2=98: Re: [mpls-tp] [mpls] Draft: Response to Updated draft= Recommendation G.tpoam [Ref043.02] > =E6=94=B6=E4=BB=B6=E4=BA=BA: jingr@ties.itu.ch > =E6=8A=84=E9=80=81: mpls-tp@ietf.org > =E6=97=A5=E6=9C=9F: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5,=E5=91=A8=E5=9B=9B= ,=E4=B8=8B=E5=8D=884:09 > Resend to mpls-tp list. >=20 > Quoting jingr@ties.itu.ch: >=20 > > Hi Stewart Bryant, > >=20 > > I don=E2=80=99t agree with the current LS text. > >=20 > > China Telecom support the standardization of Y.1731 > based MPLS-TP OAM tools > > in=20 > > the ITU-T to meet the urgent and increasing > requirements for PTN deployment.=20 > >=20 > > It=E2=80=99s a multi-vendor supported, interoperability > certificated and feasible=20 > > solution.=C2=A0 It had been specified in both CCSA > (China Communications Standards > >=20 > > Association) and China Telecom=E2=80=99s PTN standard as the > only standard OAM=20 > > mechanism. > >=20 > >=C2=A0=20 > >=20 > > Best Regards > >=20 > > Jing Ruiquan > >=20 > > China=E3=80=80Telecom=C2=A0 Beijing=C2=A0 > Research=E3=80=80Institute > >=20 > > > -------------------------------------------------------------------------= ----- > -- > > From: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] > On Behalf Of > > Stewart=20 > > Bryant > > Sent: Monday, January 10, 2011 6:57 PM > > To: mpls@ietf.org > > Subject: [mpls] Draft: Response to Updated draft > Recommendation G.tpoam=20 > > [Ref043.02] > >=20 > >=20 > > I propose to send the following Liaison Response to > the ITU-T on Friday=20 > > 14th January and am posting it to the MPLS WG list for > review.=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=20 > >=20 > > Response to Updated draft Recommendation G.tpoam [Ref > 043.02]=20 > >=20 > > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >=20 > > To: tsbsg15@itu.int, > greg.jones@itu.int, > hiroshi.ota@itu.int, > IAB@ietf.org=20 > > CC: Greg Jones, swallow@cisco.com, > loa@pi.nu, paf@cisco.com=20 > > stbryant@cisco.com, > adrian.farrel@huawei.com, > mpls@ietf.org=20 > > yoichi.maeda@ttc.or.jp, > steve.trowbridge@alcatel-lucent.com >=20 > > ghani.abbas@ericsson.com, > hhelvoort@huawei.com >=20 > > malcolm.betts@zte.com.cn, > kam.lam@alcatel-lucent.com >=20 > >=20 > > For Action=20 > >=20 > > The MPLS Working Group notes that this document > contains text describing=20 > > MPLS-TP OAM protocols not designed and standardized > using the IETF=20 > > Standards process. Specifically it uses material from >=20 > > draft-bhh-mpls-tp-oam-y1731-06.=20 > >=20 > > We wish to draw your attention to the status section > of=20 > > draft-bhh-mpls-tp-oam-y1731-06 which states:=20 > >=20 > > "Internet-Drafts are draft documents valid for a > maximum of six months=20 > > and may be updated, replaced, or obsoleted by other > documents at any=20 > > time. It is inappropriate to use Internet-Drafts as > reference material=20 > > or to cite them other than as "work in progress".=20 > >=20 > > Please also note that since the draft filename starts > with the prefix=20 > > string "draft-bhh" this clearly identifies it to the > reader as a=20 > > document expressing the personal technical views of > the authors and=20 > > hence hence as a document that that does not have any > acknowledged level=20 > > of IETF consensus.=20 > >=20 > > Since the text of draft Recommendation for G.tpoam is > based on an=20 > > MPLS-TP OAM protocol not designed within the IETF > Standards Process this=20 > > is a breach of the SG15 agreement with the IETF as > published in Report=20 > > of the first meeting of Working Party 3/15 Transport > network structures=20 > > (2009-2012) (Geneva, 1 =E2=80=93 12 December 2008) which can > be found at=20 > > http://www.itu.int/md/T09-SG15-R-0004/en >=20 > >=20 > > Please confirm that the ITU-T intends to continue with > the joint work on=20 > > MPLS-TP and that the ITU-T will align this > recommendation with the IETF=20 > > MPLS-TP OAM design before advancing this document > through the ITU-T=20 > > publication process.=20 > >=20 > > The MPLS Working Group would also like to draw the > attention of ITU-T=20 > > SG15 to the IETF copyright rules. Please see=20 > > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- > > 20091228.htm=20 > > for further details.=20 > >=20 > > Since this draft Recommendation contains text in which > the ITU-T SG15=20 > > has proposed making changes to IETF protocols without > the approval of=20 > > the IETF, the MPLS Working Group have referred this > liaison to the IAB=20 > > for their consideration.=20 > >=20 > >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > > _______________________________________________=20 > > mpls mailing list=20 > > mpls@ietf.org=20 > > https://www.ietf.org/mailman/listinfo/mpls=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > =0A=0A=0A From lufang@cisco.com Thu Jan 13 06:59:21 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B61A28C0DB; Thu, 13 Jan 2011 06:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfqKKYZgJdhD; Thu, 13 Jan 2011 06:59:19 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CDF803A6B9A; Thu, 13 Jan 2011 06:59:18 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPSiLk2tJXHB/2dsb2JhbACECKA/c6QuilABjhGBHoM3dwSEaIlQ Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2011 15:01:40 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p0DF1eG9001736; Thu, 13 Jan 2011 15:01:40 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 09:01:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2011 09:01:38 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25041C4A04@XMB-RCD-201.cisco.com> In-Reply-To: <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02] Thread-Index: AcuzKTZq2jnBERhwR6aVB5jHpXiUDgAAP+ng References: <4D2AE5E0.90703@cisco.com><077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net><077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net> <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk> From: "Luyuan Fang (lufang)" To: "Ben Niven-Jenkins" , "HUANG Feng F" , "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 13 Jan 2011 15:01:40.0334 (UTC) FILETIME=[C87998E0:01CBB332] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:59:21 -0000 Well said, Ben and Nurit. I support the proposal Stewart sent. Let's reiterate the IETF process here. IETF has published a number of RFCs that specify the procedures for external bodies to request the modification of IETF protocols. [RFC 4775] $B!H(JProcedures for Protocol Extensions and Variations$B!I(J lays down the guideline and procedures for protocols extensions. It recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with IETF. This document is directed principally at other SDOs and vendors considering extensions to IETF protocols. [RFC 4929] specifies the change process for MPLS, GMPLS protocols and procedures. It indicates the definition and publishing of non-standard extension by other fora without IETF review, and outside of IETF publication process, regardless if rationalized as limited to use among fora vendors, or limited to a particular application, or rationalized as allowing timely demos, has the unfortunate potential to hinder interoperability and increase complexity, sows confusion in the industry, and circumvents the Internet standards process that exists to ensure protocol implementability. As described in [RFC4775] and [RFC 4929], any non-standard extensions to IETF protocols, including experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards body. Standard extensions to IETF protocols must be reviewed and published by IETF. Extensions to MPLS(-TP) protocols made outside of IETF creates a great risk of interoperability. How could any other SDOs standardize something that extend IETF MPLS protocols without IETF's agreement, nor IANA issued code point? The process issue was the reason for IETF/ITU-T agreements for joint development for MPLS-TP two years ago. In Beijing IETF 79, November 2011, IETF Chair Russ Housley said clearly in the MPLS WG meeting that IETF decided to support one MPLS-TP OAM solution only. We all heard that, let's move on. You can do things elsewhere if not extending/modifying IETF protocols. Luyuan -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 13 January 2011 08:53 To: HUANG Feng F Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02] Feng, colleagues, On 13 Jan 2011, at 10:31, HUANG Feng F wrote: > -----Original Message----- > From: Sprecher, Nurit (NSN - IL/Hod HaSharon) > [mailto:nurit.sprecher@nsn.com] > Sent: 2011$BG/(J1$B7n(J13$BF|(J 17:45 > To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org > Cc: mpls-tp@ietf.org > Subject: RE: [mpls] Draft: Response to Updated draft Recommendation > G.tpoam[Ref043.02] > > Hi Feng, > I did not refer to specific solution, validity and acceptance of a solution, so I cannot see to what you disagree and how your response fit to mine. > If you think that you have a good solution which is proven and supported please discuss it in the IETF and try to get support for it! > > HF> The solution has been submitted to ietf for 2 year! > We seem to be going round the same loop we've being going round for a while. An OAM solution (draft-bhh) was submitted for consideration and the MPLS WG decided to select a different proposal for MPLS-TP OAM. That's life, that's how standards development works because standards development is "design by committee" and that means that the decisions of the "committee" are unlikely to please everyone all of the time. > I would like the ITU-T to continue with its collaborative agreement with the IETF and ensure that the development of the protocol is done as agreed and supported by SG15 using the IETF processes. > > HF> I can't image the meaning of cooperation is that ITU-T do nothing and just obey IETF's process! > It isn't, but that collaborative agreement recognised IETF as being the protocol design authority for MPLS & MPLS-TP, which means IETF have the final decision on what the MPLS-TP protocols are and how they work. What you seem to be arguing for is that IETF just obey the demands of other organisations, i.e. to paraphrase your argument: "CCSA have used draft-bhh in one of their standards so IETF must rubber stamp it as being part of MPLS-TP". It was similar behaviour (ITU-T defining MPLS extensions without consultation with IETF) that causes the original bun fight that lead to the JWT etc being formed and much time being expended on politics rather than technical work to get us to where we are. I suggest we stop trying to re-ignite a debate as to whether the MPLS-TP OAM solution should include draft-bhh or not as the decision has been made. Let's accept that decision. In future if another standards body wants to use an Internet-Draft as the basis for one of their standards they would be well advised to enquire of the IETF as to the status and likely future of the Internet-Draft before making any decisions and we could avoid these sorts of situations occurring in the first place. Ben P.S. I think the original liaison text is fine as-is. > I will support a single global solution interoperable solution (whatever the solution is). > Best regards, > Nurit > > -----Original Message----- > From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] > Sent: Thursday, January 13, 2011 11:35 AM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; > mpls@ietf.org > Cc: mpls-tp@ietf.org > Subject: RE: [mpls] Draft: Response to Updated draft Recommendation > G.tpoam[Ref043.02] > > Hi,Nurit, > I can't agree with you. > Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet Transport Network by many applications and public demo and it has many supporters. I am wondering why this solutions is not standardized in ietf? > Further more, I really don't agree with your last sentence, this solution is asked by customers in Industry, you can see at least 7 providers in global support this solution. > > B.R. > Feng > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: 2011$BG/(J1$B7n(J13$BF|(J 16:18 > To: stbryant@cisco.com; mpls@ietf.org > Subject: Re: [mpls] Draft: Response to Updated draft Recommendation > G.tpoam[Ref043.02] > > Hi, > I support the proposal. > We have a cooperative agreement with the ITU-T concerning the work on MPLS-TP. > The agreement recognizes the design authority of the IETF for MPLS and it is agreed that the development of the protocol should be done in the IETF using the IETF processes. The ITU-T should not take any uncoordinated action in the development of the MPLS_TP protocol. > We would appreciate if the ITU-T continues (as it committed to) with the collaborative work with the IETF on MPLS_TP and contributes from its expertise to the development of the protocol using the IETF processes. > We would also not like to see two competing solutions which may confuse the Industry, bloat operational and capital expenses and badly affect the end customer. > Best regards, > Nurit > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of ext Stewart Bryant > Sent: Monday, January 10, 2011 12:57 PM > To: mpls@ietf.org > Subject: [mpls] Draft: Response to Updated draft Recommendation > G.tpoam [Ref043.02] > > I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. > > ======= > > Response to Updated draft Recommendation G.tpoam [Ref 043.02] > > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, > IAB@ietf.org > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com > stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org > yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com, hhelvoort@huawei.com > malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com > > For Action > > The MPLS Working Group notes that this document contains text > describing > > MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. > > We wish to draw your attention to the status section of > draft-bhh-mpls-tp-oam-y1731-06 which states: > > "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". > > Please also note that since the draft filename starts with the prefix > string "draft-bhh" this clearly identifies it to the reader as a > document expressing the personal technical views of the authors and > hence hence as a document that that does not have any acknowledged > level > > of IETF consensus. > > Since the text of draft Recommendation for G.tpoam is based on an > MPLS-TP OAM protocol not designed within the IETF Standards Process > this > > is a breach of the SG15 agreement with the IETF as published in Report > of the first meeting of Working Party 3/15 Transport network > structures > (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at > http://www.itu.int/md/T09-SG15-R-0004/en > > Please confirm that the ITU-T intends to continue with the joint work > on > > MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. > > The MPLS Working Group would also like to draw the attention of ITU-T > SG15 to the IETF copyright rules. Please see > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy > -2 > 0091228.htm > for further details. > > Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. > > > ========= > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From nurit.sprecher@nsn.com Thu Jan 13 07:28:32 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B2D3A6B3F; Thu, 13 Jan 2011 07:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.325 X-Spam-Level: X-Spam-Status: No, score=-4.325 tagged_above=-999 required=5 tests=[AWL=1.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbx-ivxjL9Z4; Thu, 13 Jan 2011 07:28:30 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 3DFE33A69B9; Thu, 13 Jan 2011 07:28:29 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0DFUob5024072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jan 2011 16:30:50 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0DFUnHd004187; Thu, 13 Jan 2011 16:30:50 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 16:30:41 +0100 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_01CBB336.D57B1EC7" Date: Thu, 13 Jan 2011 16:30:32 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264033056FB@DEMUEXC014.nsn-intra.net> In-Reply-To: <526321.56478.qm@web15605.mail.cnb.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam [Ref043.02] Thread-Index: AcuzMfUF0Qh1GFyISiuucMDLFyKA0AAAz/Zg References: <1294906173.4d2eb33dd1ffa@gold.itu.ch> <526321.56478.qm@web15605.mail.cnb.yahoo.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Larry" , , X-OriginalArrivalTime: 13 Jan 2011 15:30:41.0061 (UTC) FILETIME=[D6077550:01CBB336] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draftRecommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:28:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB336.D57B1EC7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGFuIExpLA0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgbGlhaXNvbiBpcyBub3QgaW50ZW5kZWQg dG8gZ2V0IGludG8gdGVjaG5pY2FsIGRpc2N1c3Npb24gb3IgaW50byBTUHMnIHJlcXVpcmVtZW50 cy4gDQoNCkl0IGlzIG1vcmUgb24gdGhlIHByb2NlZHVyZXMgYW5kIHByb2Nlc3Nlcy4uLi4NCg0K QWNjb3JkaW5nIHRvIHRoZSBjb2xsYWJvcmF0aXZlIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBJVFUt VCBhbmQgdGhlIElFVEYgKHdoaWNoIHdhcyBhY2NlcHRlZCBieSBJVFUtVCBTRzE1IGluIERlY2Vt YmVyIDIwMDgpLCB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIHByb3RvY29sIHNob3VsZCBiZSBkb25l IGluIHRoZSBJRVRGIHVzaW5nIHRoZSBJRVRGIHByb2Nlc3Nlcy4gVGhlIElUVS1UIGRvY3VtZW50 cyBzaG91bGQgcmVmZXIgdG8gdGhlIElFVEYgc29sdXRpb25zLiANCg0KV2Ugbm90ZSBhIGRvY3Vt ZW50ICh1bmRlciBkZXZlbG9wbWVudCkgaW4gdGhlIElUVS1UIChnLnRwb2FtKSwgd2hpY2ggaW5j bHVkZXMgdGhlIGRlZmluaXRpb24gb2YgbWVzc2FnZXMgYW5kIHByb2NlZHVyZXMgZm9yIE1TUEwt VFAgd2hpY2ggd2VyZSBub3QgZGV2ZWxvcGVkIHVzaW5nIHRoZSBJRVRGIHN0YW5kYXJkIHByb2Nl c3NlcyBhbmQgZG9lcyBub3QgZm9sbG93IHRoZSBJRVRGIGNoYW5nZS9leHRlbnNpb24gcHJvY2Vz c2VzLiBUaGlzIGlzIGNvbnRyYXJ5IHRvIHRoZSBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUgSUVURiBh bmQgdGhlIElUVS1UIGZyb20gRGVjZW1iZXIgMjAwOC4gDQoNCldlIGFyZSByZXNwb25kaW5nIG9u IHRoZSBwcm9jZXNzIGFuZCB3YW50IHRvIGJlIHN1cmUgKGFuZCBob3BlKSB0aGF0IHRoZSBJVFUt VCBpbnRlbmRzIHRvIGNvbnRpbnVlIHdpdGggdGhlIGpvaW50IHdvcmsgb24gTVBMUy1UUCBhcyBh Z3JlZWQgb24gaW4gRGVjZW1iZXIgMjAwOC4gDQoNCkkgdGhpbmsgdGhlIGxpYWlzb24gaXMgdmVy eSB3ZWxsIHdyaXR0ZW4hDQoNCkJlc3QgcmVnYXJkcywNCg0KTnVyaXQNCg0KIA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IExhcnJ5DQpTZW50 OiBUaHVyc2RheSwgSmFudWFyeSAxMywgMjAxMSA0OjU2IFBNDQpUbzogamluZ3JAdGllcy5pdHUu Y2g7IHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLXRw QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVzcG9uc2Ug dG8gVXBkYXRlZCBkcmFmdFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZjA0My4wMl0NCg0KIA0K DQpIaSwNCg0KIA0KDQogICAgSSBkb24ndCB0aGluayBpdCBpcyBwcm9wZXIgdG8gc2VuZCB0aGUg TFMgdG8gSVRVLVQgYmVjYXVzZSB0aGUgdGV4dCBkb2Vzbid0IHJlZmxlY3QgdGhlIHJlcXVpcmVt ZW50IGZyb20gcHJvdmlkZXJzLg0KDQogICAgQXBwYXJlbnRseSwgZHJhZnQtYmhoIGJhc2VkIE9B TSBpcyB0aGUgbW9zdCBtYXR1cmUgc29sdXRpb24gY3VycmVudGx5LiBJdCBoYXMgYmVlbiBwcm92 ZWQgYnkgbW9yZSB0aGFuIDIwMCwwMDAgYXBwbGljYXRpb25zIGFuZCBpcyBzdXBwb3J0ZWQgYnkg YSBsb3Qgb2Ygb3BlcmF0b3JzIGFuZCB2ZW5kb3JzLiANCg0KICAgIA0KDQpCZXN0IHJlZ2FyZHMs DQoNCiANCg0KICAgICAgICAgICAgICBIYW4gTGkNCg0KIA0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoN CkhhbiBMaSwgUGguRCANCg0KQ2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0ZQ0KDQpVbml0 IDIsIDI4IFh1YW53dW1lbnhpIEF2ZSwgWHVhbnd1IERpc3RyaWN0LCBCZWlqaW5nIDEwMDA1Mywg Q2hpbmEgDQoNCkZheDogKzg2IDEwIDYzNjAxMDg3IA0KDQpNT0JJTEU6IDEzNTAxMDkzMzg1IA0K DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQoNCiANCg0KIA0KDQotLS0gMTHlubQx5pyIMTPml6XvvIzlkajl m5ssIHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQgPHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ+ IOWGmemBk++8mg0KDQogDQoNCj4g5Y+R5Lu25Lq6OiBydWlxdWFuLmppbmdAdGllcy5pdHUuaW50 IDxydWlxdWFuLmppbmdAdGllcy5pdHUuaW50Pg0KDQo+IOS4u+mimDogUmU6IFttcGxzLXRwXSBb bXBsc10gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50 cG9hbSBbUmVmMDQzLjAyXQ0KDQo+IOaUtuS7tuS6ujogamluZ3JAdGllcy5pdHUuY2gNCg0KPiDm ioTpgIE6IG1wbHMtdHBAaWV0Zi5vcmcNCg0KPiDml6XmnJ86IDIwMTHlubQx5pyIMTPml6Us5ZGo 5ZubLOS4i+WNiDQ6MDkNCg0KPiBSZXNlbmQgdG8gbXBscy10cCBsaXN0Lg0KDQo+IA0KDQo+IFF1 b3RpbmcgamluZ3JAdGllcy5pdHUuY2g6DQoNCj4gDQoNCj4gPiBIaSBTdGV3YXJ0IEJyeWFudCwN Cg0KPiA+IA0KDQo+ID4gSSBkb27igJl0IGFncmVlIHdpdGggdGhlIGN1cnJlbnQgTFMgdGV4dC4N Cg0KPiA+IA0KDQo+ID4gQ2hpbmEgVGVsZWNvbSBzdXBwb3J0IHRoZSBzdGFuZGFyZGl6YXRpb24g b2YgWS4xNzMxDQoNCj4gYmFzZWQgTVBMUy1UUCBPQU0gdG9vbHMNCg0KPiA+IGluIA0KDQo+ID4g dGhlIElUVS1UIHRvIG1lZXQgdGhlIHVyZ2VudCBhbmQgaW5jcmVhc2luZw0KDQo+IHJlcXVpcmVt ZW50cyBmb3IgUFROIGRlcGxveW1lbnQuIA0KDQo+ID4gDQoNCj4gPiBJdOKAmXMgYSBtdWx0aS12 ZW5kb3Igc3VwcG9ydGVkLCBpbnRlcm9wZXJhYmlsaXR5DQoNCj4gY2VydGlmaWNhdGVkIGFuZCBm ZWFzaWJsZSANCg0KPiA+IHNvbHV0aW9uLiAgSXQgaGFkIGJlZW4gc3BlY2lmaWVkIGluIGJvdGgg Q0NTQQ0KDQo+IChDaGluYSBDb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMNCg0KPiA+IA0KDQo+ID4g QXNzb2NpYXRpb24pIGFuZCBDaGluYSBUZWxlY29t4oCZcyBQVE4gc3RhbmRhcmQgYXMgdGhlDQoN Cj4gb25seSBzdGFuZGFyZCBPQU0gDQoNCj4gPiBtZWNoYW5pc20uDQoNCj4gPiANCg0KPiA+ICAN Cg0KPiA+IA0KDQo+ID4gQmVzdCBSZWdhcmRzDQoNCj4gPiANCg0KPiA+IEppbmcgUnVpcXVhbg0K DQo+ID4gDQoNCj4gPiBDaGluYeOAgFRlbGVjb20gIEJlaWppbmcgDQoNCj4gUmVzZWFyY2jjgIBJ bnN0aXR1dGUNCg0KPiA+IA0KDQo+ID4NCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiAt LQ0KDQo+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnDQoNCj4gW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddDQoNCj4gT24gQmVoYWxmIE9mDQoNCj4gPiBTdGV3YXJ0IA0KDQo+ID4g QnJ5YW50DQoNCj4gPiBTZW50OiBNb25kYXksIEphbnVhcnkgMTAsIDIwMTEgNjo1NyBQTQ0KDQo+ ID4gVG86IG1wbHNAaWV0Zi5vcmcNCg0KPiA+IFN1YmplY3Q6IFttcGxzXSBEcmFmdDogUmVzcG9u c2UgdG8gVXBkYXRlZCBkcmFmdA0KDQo+IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gDQoNCj4gPiBb UmVmMDQzLjAyXQ0KDQo+ID4gDQoNCj4gPiANCg0KPiA+IEkgcHJvcG9zZSB0byBzZW5kIHRoZSBm b2xsb3dpbmcgTGlhaXNvbiBSZXNwb25zZSB0bw0KDQo+IHRoZSBJVFUtVCBvbiBGcmlkYXkgDQoN Cj4gPiAxNHRoIEphbnVhcnkgYW5kIGFtIHBvc3RpbmcgaXQgdG8gdGhlIE1QTFMgV0cgbGlzdCBm b3INCg0KPiByZXZpZXcuIA0KDQo+ID4gDQoNCj4gPiA9PT09PT09IA0KDQo+ID4gDQoNCj4gPiBS ZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZg0KDQo+ IDA0My4wMl0gDQoNCj4gPiANCg0KPiA+IEZyb206IElFVEYgTGlhaXNvbiB0byBJVFUtVCBvbiBN UExTIHN0YnJ5YW50QGNpc2NvLmNvbQ0KDQo+IA0KDQo+ID4gVG86IHRzYnNnMTVAaXR1LmludCwN Cg0KPiBncmVnLmpvbmVzQGl0dS5pbnQsDQoNCj4gaGlyb3NoaS5vdGFAaXR1LmludCwNCg0KPiBJ QUJAaWV0Zi5vcmcgDQoNCj4gPiBDQzogR3JlZyBKb25lcywgc3dhbGxvd0BjaXNjby5jb20sDQoN Cj4gbG9hQHBpLm51LCBwYWZAY2lzY28uY29tIA0KDQo+ID4gc3RicnlhbnRAY2lzY28uY29tLA0K DQo+IGFkcmlhbi5mYXJyZWxAaHVhd2VpLmNvbSwNCg0KPiBtcGxzQGlldGYub3JnIA0KDQo+ID4g eW9pY2hpLm1hZWRhQHR0Yy5vci5qcCwNCg0KPiBzdGV2ZS50cm93YnJpZGdlQGFsY2F0ZWwtbHVj ZW50LmNvbQ0KDQo+IA0KDQo+ID4gZ2hhbmkuYWJiYXNAZXJpY3Nzb24uY29tLA0KDQo+IGhoZWx2 b29ydEBodWF3ZWkuY29tDQoNCj4gDQoNCj4gPiBtYWxjb2xtLmJldHRzQHp0ZS5jb20uY24sDQoN Cj4ga2FtLmxhbUBhbGNhdGVsLWx1Y2VudC5jb20NCg0KPiANCg0KPiA+IA0KDQo+ID4gRm9yIEFj dGlvbiANCg0KPiA+IA0KDQo+ID4gVGhlIE1QTFMgV29ya2luZyBHcm91cCBub3RlcyB0aGF0IHRo aXMgZG9jdW1lbnQNCg0KPiBjb250YWlucyB0ZXh0IGRlc2NyaWJpbmcgDQoNCj4gPiBNUExTLVRQ IE9BTSBwcm90b2NvbHMgbm90IGRlc2lnbmVkIGFuZCBzdGFuZGFyZGl6ZWQNCg0KPiB1c2luZyB0 aGUgSUVURiANCg0KPiA+IFN0YW5kYXJkcyBwcm9jZXNzLiBTcGVjaWZpY2FsbHkgaXQgdXNlcyBt YXRlcmlhbCBmcm9tDQoNCj4gDQoNCj4gPiBkcmFmdC1iaGgtbXBscy10cC1vYW0teTE3MzEtMDYu IA0KDQo+ID4gDQoNCj4gPiBXZSB3aXNoIHRvIGRyYXcgeW91ciBhdHRlbnRpb24gdG8gdGhlIHN0 YXR1cyBzZWN0aW9uDQoNCj4gb2YgDQoNCj4gPiBkcmFmdC1iaGgtbXBscy10cC1vYW0teTE3MzEt MDYgd2hpY2ggc3RhdGVzOiANCg0KPiA+IA0KDQo+ID4gIkludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhDQoNCj4gbWF4aW11bSBvZiBzaXggbW9udGhzIA0KDQo+ ID4gYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyDQoN Cj4gZG9jdW1lbnRzIGF0IGFueSANCg0KPiA+IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g dXNlIEludGVybmV0LURyYWZ0cyBhcw0KDQo+IHJlZmVyZW5jZSBtYXRlcmlhbCANCg0KPiA+IG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzIi4gDQoNCj4gPiAN Cg0KPiA+IFBsZWFzZSBhbHNvIG5vdGUgdGhhdCBzaW5jZSB0aGUgZHJhZnQgZmlsZW5hbWUgc3Rh cnRzDQoNCj4gd2l0aCB0aGUgcHJlZml4IA0KDQo+ID4gc3RyaW5nICJkcmFmdC1iaGgiIHRoaXMg Y2xlYXJseSBpZGVudGlmaWVzIGl0IHRvIHRoZQ0KDQo+IHJlYWRlciBhcyBhIA0KDQo+ID4gZG9j dW1lbnQgZXhwcmVzc2luZyB0aGUgcGVyc29uYWwgdGVjaG5pY2FsIHZpZXdzIG9mDQoNCj4gdGhl IGF1dGhvcnMgYW5kIA0KDQo+ID4gaGVuY2UgaGVuY2UgYXMgYSBkb2N1bWVudCB0aGF0IHRoYXQg ZG9lcyBub3QgaGF2ZSBhbnkNCg0KPiBhY2tub3dsZWRnZWQgbGV2ZWwgDQoNCj4gPiBvZiBJRVRG IGNvbnNlbnN1cy4gDQoNCj4gPiANCg0KPiA+IFNpbmNlIHRoZSB0ZXh0IG9mIGRyYWZ0IFJlY29t bWVuZGF0aW9uIGZvciBHLnRwb2FtIGlzDQoNCj4gYmFzZWQgb24gYW4gDQoNCj4gPiBNUExTLVRQ IE9BTSBwcm90b2NvbCBub3QgZGVzaWduZWQgd2l0aGluIHRoZSBJRVRGDQoNCj4gU3RhbmRhcmRz IFByb2Nlc3MgdGhpcyANCg0KPiA+IGlzIGEgYnJlYWNoIG9mIHRoZSBTRzE1IGFncmVlbWVudCB3 aXRoIHRoZSBJRVRGIGFzDQoNCj4gcHVibGlzaGVkIGluIFJlcG9ydCANCg0KPiA+IG9mIHRoZSBm aXJzdCBtZWV0aW5nIG9mIFdvcmtpbmcgUGFydHkgMy8xNSBUcmFuc3BvcnQNCg0KPiBuZXR3b3Jr IHN0cnVjdHVyZXMgDQoNCj4gPiAoMjAwOS0yMDEyKSAoR2VuZXZhLCAxIOKAkyAxMiBEZWNlbWJl ciAyMDA4KSB3aGljaCBjYW4NCg0KPiBiZSBmb3VuZCBhdCANCg0KPiA+IGh0dHA6Ly93d3cuaXR1 LmludC9tZC9UMDktU0cxNS1SLTAwMDQvZW4NCg0KPiANCg0KPiA+IA0KDQo+ID4gUGxlYXNlIGNv bmZpcm0gdGhhdCB0aGUgSVRVLVQgaW50ZW5kcyB0byBjb250aW51ZSB3aXRoDQoNCj4gdGhlIGpv aW50IHdvcmsgb24gDQoNCj4gPiBNUExTLVRQIGFuZCB0aGF0IHRoZSBJVFUtVCB3aWxsIGFsaWdu IHRoaXMNCg0KPiByZWNvbW1lbmRhdGlvbiB3aXRoIHRoZSBJRVRGIA0KDQo+ID4gTVBMUy1UUCBP QU0gZGVzaWduIGJlZm9yZSBhZHZhbmNpbmcgdGhpcyBkb2N1bWVudA0KDQo+IHRocm91Z2ggdGhl IElUVS1UIA0KDQo+ID4gcHVibGljYXRpb24gcHJvY2Vzcy4gDQoNCj4gPiANCg0KPiA+IFRoZSBN UExTIFdvcmtpbmcgR3JvdXAgd291bGQgYWxzbyBsaWtlIHRvIGRyYXcgdGhlDQoNCj4gYXR0ZW50 aW9uIG9mIElUVS1UIA0KDQo+ID4gU0cxNSB0byB0aGUgSUVURiBjb3B5cmlnaHQgcnVsZXMuIFBs ZWFzZSBzZWUgDQoNCj4gPiBodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8vYXJj aGl2ZS9JRVRGLVRydXN0LUxpY2Vuc2UtUG9saWN5LQ0KDQo+ID4gMjAwOTEyMjguaHRtIA0KDQo+ ID4gZm9yIGZ1cnRoZXIgZGV0YWlscy4gDQoNCj4gPiANCg0KPiA+IFNpbmNlIHRoaXMgZHJhZnQg UmVjb21tZW5kYXRpb24gY29udGFpbnMgdGV4dCBpbiB3aGljaA0KDQo+IHRoZSBJVFUtVCBTRzE1 IA0KDQo+ID4gaGFzIHByb3Bvc2VkIG1ha2luZyBjaGFuZ2VzIHRvIElFVEYgcHJvdG9jb2xzIHdp dGhvdXQNCg0KPiB0aGUgYXBwcm92YWwgb2YgDQoNCj4gPiB0aGUgSUVURiwgdGhlIE1QTFMgV29y a2luZyBHcm91cCBoYXZlIHJlZmVycmVkIHRoaXMNCg0KPiBsaWFpc29uIHRvIHRoZSBJQUIgDQoN Cj4gPiBmb3IgdGhlaXIgY29uc2lkZXJhdGlvbi4gDQoNCj4gPiANCg0KPiA+IA0KDQo+ID4gDQoN Cj4gPiA9PT09PT09PT0gDQoNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyANCg0KPiA+IG1wbHMgbWFpbGluZyBsaXN0IA0KDQo+ID4gbXBsc0BpZXRm Lm9yZyANCg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyAN Cg0KPiA+IA0KDQo+ID4gDQoNCj4gPiANCg0KPiANCg0KPiANCg0KPiANCg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IG1wbHMtdHAgbWFpbGlu ZyBsaXN0DQoNCj4gbXBscy10cEBpZXRmLm9yZw0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQo+IA0KDQogDQoNCiANCg0KICAgICAgDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm1wbHMtdHAgbWFp bGluZyBsaXN0DQoNCm1wbHMtdHBAaWV0Zi5vcmcNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQoNCg== ------_=_NextPart_001_01CBB336.D57B1EC7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMg R290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDMgOSAwIDAgMCAwIDAgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDMgOSAwIDAg MCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xh czsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgMyA5 IDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkhhbiBMaSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGxpYWlzb24gaXMgbm90IGludGVuZGVkIHRv IGdldCBpbnRvIHRlY2huaWNhbCBkaXNjdXNzaW9uIG9yIGludG8gU1BzJyByZXF1aXJlbWVudHMu IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JdCBpcyBtb3JlIG9uIHRoZSBw cm9jZWR1cmVzIGFuZCBwcm9jZXNzZXMuLi4uPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PkFjY29yZGluZyB0byB0aGUgY29sbGFib3JhdGl2ZSBhZ3JlZW1lbnQgYmV0d2VlbiB0 aGUgSVRVLVQgYW5kIHRoZSBJRVRGICh3aGljaCB3YXMgYWNjZXB0ZWQgYnkgSVRVLVQgU0cxNSBp biBEZWNlbWJlciAyMDA4KSwgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBwcm90b2NvbCBzaG91bGQg YmUgZG9uZSBpbiB0aGUgSUVURiB1c2luZyB0aGUgPGI+PHU+SUVURiBwcm9jZXNzZXM8L3U+PC9i Pi4gVGhlIElUVS1UIGRvY3VtZW50cyBzaG91bGQgcmVmZXIgdG8gdGhlIElFVEYgc29sdXRpb25z LiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+V2Ugbm90ZSBhIGRvY3VtZW50 ICh1bmRlciBkZXZlbG9wbWVudCkgaW4gdGhlIElUVS1UIChnLnRwb2FtKSwgd2hpY2ggaW5jbHVk ZXMgdGhlIGRlZmluaXRpb24gb2YgbWVzc2FnZXMgYW5kIHByb2NlZHVyZXMgZm9yIE1TUEwtVFAg d2hpY2ggd2VyZSBub3QgZGV2ZWxvcGVkIHVzaW5nIHRoZSBJRVRGIHN0YW5kYXJkIHByb2Nlc3Nl cyBhbmQgZG9lcyBub3QgZm9sbG93IHRoZSBJRVRGIGNoYW5nZS9leHRlbnNpb24gcHJvY2Vzc2Vz LiBUaGlzIGlzIGNvbnRyYXJ5IHRvIHRoZSBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUgSUVURiBhbmQg dGhlIElUVS1UIGZyb20gRGVjZW1iZXIgMjAwOC4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PldlIGFyZSByZXNwb25kaW5nIG9uIHRoZSBwcm9jZXNzIGFuZCB3YW50IHRvIGJl IHN1cmUgKGFuZCBob3BlKSB0aGF0IHRoZSBJVFUtVCBpbnRlbmRzIHRvIGNvbnRpbnVlIHdpdGgg dGhlIGpvaW50IHdvcmsgb24gTVBMUy1UUCBhcyBhZ3JlZWQgb24gaW4gRGVjZW1iZXIgMjAwOC4g PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkkgdGhpbmsgdGhlIGxpYWlzb24g aXMgdmVyeSB3ZWxsIHdyaXR0ZW4hPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+TnVyaXQ8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPkZyb206 IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIGV4dCBMYXJyeTxicj5TZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMywg MjAxMSA0OjU2IFBNPGJyPlRvOiBqaW5nckB0aWVzLml0dS5jaDsgcnVpcXVhbi5qaW5nQHRpZXMu aXR1LmludDxicj5DYzogbXBsc0BpZXRmLm9yZzsgbXBscy10cEBpZXRmLm9yZzxicj5TdWJqZWN0 OiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdFJl Y29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZjA0My4wMl08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pkhp LDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+wqDCoMKgIEkgZG9uJ3QgdGhpbmsgaXQgaXMgcHJvcGVy IHRvIHNlbmQgdGhlIExTIHRvIElUVS1UIGJlY2F1c2UgdGhlIHRleHQgZG9lc24ndCByZWZsZWN0 IHRoZSByZXF1aXJlbWVudCBmcm9tIHByb3ZpZGVycy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+wqDCoMKgIEFwcGFyZW50bHksIGRyYWZ0LWJoaCBiYXNlZCBPQU0gaXMgdGhl IG1vc3QgbWF0dXJlIHNvbHV0aW9uIGN1cnJlbnRseS4gSXQgaGFzIGJlZW4gcHJvdmVkIGJ5IG1v cmUgdGhhbiAyMDAsMDAwIGFwcGxpY2F0aW9ucyBhbmQgaXMgc3VwcG9ydGVkIGJ5IGEgbG90IG9m IG9wZXJhdG9ycyBhbmQgdmVuZG9ycy4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PsKgwqDCoMKgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEhh biBMaTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD5IYW4gTGksIFBoLkQgPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PkNoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGU8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+VW5pdCAyLCAyOCBYdWFud3VtZW54aSBBdmUsIFh1 YW53dSBEaXN0cmljdCwgQmVpamluZyAxMDAwNTMsIENoaW5hIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD5GYXg6ICs4NiAxMCA2MzYwMTA4NyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+TU9CSUxFOiAxMzUwMTA5MzM4NSA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pi0tLSAxMTxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiTVMgR290aGljIic+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaciDwvc3Bhbj4xMzxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiTVMgR290aGljIic+5pel77yM5ZGo5ZubPC9zcGFuPiwgcnVpcXVhbi5qaW5nQHRpZXMuaXR1 LmludCAmbHQ7cnVpcXVhbi5qaW5nQHRpZXMuaXR1LmludCZndDsgPHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJNUyBHb3RoaWMiJz7lhpnpgZPvvJo8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7IDxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpNaW5nTGlVJz7lj5Hku7bkuro8L3NwYW4+ OiBydWlxdWFuLmppbmdAdGllcy5pdHUuaW50ICZsdDtydWlxdWFuLmppbmdAdGllcy5pdHUuaW50 Jmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiTVMgR290aGljIic+5Li7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseTpNaW5nTGlVJz7popg8L3NwYW4+OiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVz cG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYwNDMuMDJd PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7mlLbku7bkuro8L3NwYW4+OiBqaW5nckB0aWVzLml0dS5j aDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiTVMgR290aGljIic+5oqE6YCBPC9zcGFuPjogbXBscy10cEBpZXRmLm9yZzxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiTVMgR290aGljIic+5pel5pyfPC9zcGFuPjogMjAxMTxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiTVMgR290aGljIic+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyInPuaciDwvc3Bhbj4xMzxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMgR290 aGljIic+5pelPC9zcGFuPiw8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuWR qOWbmzwvc3Bhbj4sPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7kuIvljYg8 L3NwYW4+NDowOTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFJlc2Vu ZCB0byBtcGxzLXRwIGxpc3QuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgUXVvdGluZyBqaW5n ckB0aWVzLml0dS5jaDo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEhpIFN0ZXdhcnQg QnJ5YW50LDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBJIGRvbuKAmXQgYWdy ZWUgd2l0aCB0aGUgY3VycmVudCBMUyB0ZXh0LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgJmd0OyBDaGluYSBUZWxlY29tIHN1cHBvcnQgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBZLjE3 MzE8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBiYXNlZCBNUExTLVRQ IE9BTSB0b29sczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsg aW4gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyB0aGUgSVRV LVQgdG8gbWVldCB0aGUgdXJnZW50IGFuZCBpbmNyZWFzaW5nPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgcmVxdWlyZW1lbnRzIGZvciBQVE4gZGVwbG95bWVudC4gPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEl04oCZcyBhIG11bHRpLXZlbmRvciBz dXBwb3J0ZWQsIGludGVyb3BlcmFiaWxpdHk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyBjZXJ0aWZpY2F0ZWQgYW5kIGZlYXNpYmxlIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgc29sdXRpb24uJm5ic3A7IEl0IGhhZCBiZWVuIHNw ZWNpZmllZCBpbiBib3RoIENDU0E8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyAoQ2hpbmEgQ29tbXVuaWNhdGlvbnMgU3RhbmRhcmRzPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyAmZ3Q7IEFzc29jaWF0aW9uKSBhbmQgQ2hpbmEgVGVsZWNvbeKAmXMgUFROIHN0 YW5kYXJkIGFzIHRoZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG9u bHkgc3RhbmRhcmQgT0FNIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyZuYnNw OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgQmVzdCBSZWdhcmRzPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEppbmcgUnVpcXVhbjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBDaGluYTxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiTVMg R290aGljIic+44CAPC9zcGFuPlRlbGVjb20mbmJzcDsgQmVpamluZyZuYnNwOzxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFJlc2VhcmNoPHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJNUyBHb3RoaWMiJz7jgIA8L3NwYW4+SW5zdGl0dXRlPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgLS08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7 IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXTxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IE9uIEJlaGFsZiBPZjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgU3Rld2FydCA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IEJyeWFudDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBKYW51YXJ5IDEwLCAyMDExIDY6 NTcgUE08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IFRvOiBt cGxzQGlldGYub3JnPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0 OyBTdWJqZWN0OiBbbXBsc10gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQ8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBSZWNvbW1lbmRhdGlvbiBHLnRwb2Ft IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgW1JlZjA0My4w Ml08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBJIHByb3Bvc2UgdG8gc2VuZCB0aGUgZm9sbG93 aW5nIExpYWlzb24gUmVzcG9uc2UgdG88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyB0aGUgSVRVLVQgb24gRnJpZGF5IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7ICZndDsgMTR0aCBKYW51YXJ5IGFuZCBhbSBwb3N0aW5nIGl0IHRvIHRoZSBN UExTIFdHIGxpc3QgZm9yPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg cmV2aWV3LiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPT09PT09PSA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFm dCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWY8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyAwNDMuMDJdIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0 OyBGcm9tOiBJRVRGIExpYWlzb24gdG8gSVRVLVQgb24gTVBMUyBzdGJyeWFudEBjaXNjby5jb208 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IFRvOiB0c2JzZzE1QGl0dS5pbnQsPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgZ3JlZy5qb25lc0BpdHUuaW50LDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGhpcm9zaGkub3RhQGl0dS5p bnQsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgSUFCQGlldGYub3Jn IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgQ0M6IEdyZWcg Sm9uZXMsIHN3YWxsb3dAY2lzY28uY29tLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IGxvYUBwaS5udSwgcGFmQGNpc2NvLmNvbSA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IHN0YnJ5YW50QGNpc2NvLmNvbSw8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBhZHJpYW4uZmFycmVsQGh1YXdlaS5jb20sPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgbXBsc0BpZXRmLm9yZyA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IHlvaWNoaS5tYWVkYUB0 dGMub3IuanAsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgc3RldmUu dHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb208bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAm Z3Q7IGdoYW5pLmFiYmFzQGVyaWNzc29uLmNvbSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyBoaGVsdm9vcnRAaHVhd2VpLmNvbTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7ICZndDsgbWFsY29sbS5iZXR0c0B6dGUuY29tLmNuLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7IGthbS5sYW1AYWxjYXRlbC1sdWNlbnQuY29tPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyAmZ3Q7IEZvciBBY3Rpb24gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7 IFRoZSBNUExTIFdvcmtpbmcgR3JvdXAgbm90ZXMgdGhhdCB0aGlzIGRvY3VtZW50PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgY29udGFpbnMgdGV4dCBkZXNjcmliaW5n IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgTVBMUy1UUCBP QU0gcHJvdG9jb2xzIG5vdCBkZXNpZ25lZCBhbmQgc3RhbmRhcmRpemVkPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgdXNpbmcgdGhlIElFVEYgPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBTdGFuZGFyZHMgcHJvY2Vzcy4gU3BlY2lm aWNhbGx5IGl0IHVzZXMgbWF0ZXJpYWwgZnJvbTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZn dDsgZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2LiA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7ICZndDsgV2Ugd2lzaCB0byBkcmF3IHlvdXIgYXR0ZW50aW9uIHRvIHRoZSBzdGF0 dXMgc2VjdGlvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG9mIDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgZHJhZnQtYmhoLW1w bHMtdHAtb2FtLXkxNzMxLTA2IHdoaWNoIHN0YXRlczogPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyAmZ3Q7ICZxdW90O0ludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgbWF4aW11 bSBvZiBzaXggbW9udGhzIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgZG9jdW1lbnRzIGF0IGFu eSA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IHRpbWUuIEl0 IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhczxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHJlZmVyZW5jZSBtYXRlcmlhbCA8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICZxdW90O3dvcmsgaW4gcHJvZ3Jlc3MmcXVvdDsuIDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsgJmd0OyBQbGVhc2UgYWxzbyBub3RlIHRoYXQgc2luY2UgdGhlIGRyYWZ0 IGZpbGVuYW1lIHN0YXJ0czxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IHdpdGggdGhlIHByZWZpeCA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyAmZ3Q7IHN0cmluZyAmcXVvdDtkcmFmdC1iaGgmcXVvdDsgdGhpcyBjbGVhcmx5IGlkZW50aWZp ZXMgaXQgdG8gdGhlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgcmVh ZGVyIGFzIGEgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBk b2N1bWVudCBleHByZXNzaW5nIHRoZSBwZXJzb25hbCB0ZWNobmljYWwgdmlld3Mgb2Y8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyB0aGUgYXV0aG9ycyBhbmQgPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBoZW5jZSBoZW5jZSBhcyBh IGRvY3VtZW50IHRoYXQgdGhhdCBkb2VzIG5vdCBoYXZlIGFueTxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGFja25vd2xlZGdlZCBsZXZlbCA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IG9mIElFVEYgY29uc2Vuc3VzLiA8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgU2luY2UgdGhlIHRleHQgb2YgZHJhZnQgUmVj b21tZW5kYXRpb24gZm9yIEcudHBvYW0gaXM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyBiYXNlZCBvbiBhbiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyAmZ3Q7IE1QTFMtVFAgT0FNIHByb3RvY29sIG5vdCBkZXNpZ25lZCB3aXRoaW4gdGhl IElFVEY8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBTdGFuZGFyZHMg UHJvY2VzcyB0aGlzIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZn dDsgaXMgYSBicmVhY2ggb2YgdGhlIFNHMTUgYWdyZWVtZW50IHdpdGggdGhlIElFVEYgYXM8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBwdWJsaXNoZWQgaW4gUmVwb3J0 IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgb2YgdGhlIGZp cnN0IG1lZXRpbmcgb2YgV29ya2luZyBQYXJ0eSAzLzE1IFRyYW5zcG9ydDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG5ldHdvcmsgc3RydWN0dXJlcyA8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7ICgyMDA5LTIwMTIpIChHZW5ldmEs IDEg4oCTIDEyIERlY2VtYmVyIDIwMDgpIHdoaWNoIGNhbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7IGJlIGZvdW5kIGF0IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7ICZndDsgaHR0cDovL3d3dy5pdHUuaW50L21kL1QwOS1TRzE1LVItMDAw NC9lbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBQbGVhc2UgY29uZmlybSB0aGF0IHRoZSBJVFUtVCBp bnRlbmRzIHRvIGNvbnRpbnVlIHdpdGg8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyB0aGUgam9pbnQgd29yayBvbiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyAmZ3Q7IE1QTFMtVFAgYW5kIHRoYXQgdGhlIElUVS1UIHdpbGwgYWxpZ24gdGhp czxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHJlY29tbWVuZGF0aW9u IHdpdGggdGhlIElFVEYgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg Jmd0OyBNUExTLVRQIE9BTSBkZXNpZ24gYmVmb3JlIGFkdmFuY2luZyB0aGlzIGRvY3VtZW50PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgdGhyb3VnaCB0aGUgSVRVLVQg PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBwdWJsaWNhdGlv biBwcm9jZXNzLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7 IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgVGhlIE1QTFMg V29ya2luZyBHcm91cCB3b3VsZCBhbHNvIGxpa2UgdG8gZHJhdyB0aGU8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBhdHRlbnRpb24gb2YgSVRVLVQgPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyBTRzE1IHRvIHRoZSBJRVRGIGNvcHly aWdodCBydWxlcy4gUGxlYXNlIHNlZSA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyAmZ3Q7IGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mby9hcmNoaXZl L0lFVEYtVHJ1c3QtTGljZW5zZS1Qb2xpY3ktPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgJmd0OyAyMDA5MTIyOC5odG0gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsgJmd0OyBmb3IgZnVydGhlciBkZXRhaWxzLiA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7ICZndDsgU2luY2UgdGhpcyBkcmFmdCBSZWNvbW1lbmRhdGlvbiBjb250 YWlucyB0ZXh0IGluIHdoaWNoPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgdGhlIElUVS1UIFNHMTUgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgJmd0OyBoYXMgcHJvcG9zZWQgbWFraW5nIGNoYW5nZXMgdG8gSUVURiBwcm90b2NvbHMgd2l0 aG91dDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHRoZSBhcHByb3Zh bCBvZiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IHRoZSBJ RVRGLCB0aGUgTVBMUyBXb3JraW5nIEdyb3VwIGhhdmUgcmVmZXJyZWQgdGhpczxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGxpYWlzb24gdG8gdGhlIElBQiA8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IGZvciB0aGVpciBjb25zaWRl cmF0aW9uLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7ID09PT09PT09PSA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICZndDsgbXBscyBtYWlsaW5nIGxpc3QgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgJmd0OyBtcGxzQGlldGYub3JnIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZndDsgPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgbXBscy10cCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyBtcGxzLXRwQGlldGYub3JnPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzLXRwPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+wqDCoMKgwqDC oCA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+bXBscy10cCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+bXBscy10cEBpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHA8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CBB336.D57B1EC7-- From ben@niven-jenkins.co.uk Thu Jan 13 07:39:30 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611053A6BA8; Thu, 13 Jan 2011 07:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.822 X-Spam-Level: X-Spam-Status: No, score=-101.822 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuAqir8aTlUR; Thu, 13 Jan 2011 07:39:29 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id AD9423A6B60; Thu, 13 Jan 2011 07:39:28 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-122-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PdPJ6-0002QR-0n; Thu, 13 Jan 2011 15:41:50 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Ben Niven-Jenkins In-Reply-To: <526321.56478.qm@web15605.mail.cnb.yahoo.com> Date: Thu, 13 Jan 2011 15:41:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> To: Larry X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: mpls@ietf.org, jingr@ties.itu.ch, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:39:30 -0000 Larry, On 13 Jan 2011, at 14:55, Larry wrote: > Hi, >=20 > I don't think it is proper to send the LS to ITU-T because the text = doesn't reflect the requirement from providers. > Apparently, draft-bhh based OAM is the most mature solution = currently. It has been proved by more than 200,000 applications and is = supported by a lot of operators and vendors.=20 >=20 That may or may not be true, but either way it is irrelevant to the = liaison. ITU liaised G.tpoam to IETF. The liaison response Stewart has drafted = points out that G.tpoam uses technology (draft-bhh) that is not endorsed = by IETF consensus and points to some risks of doing so, including breach = of a prior ITU-IETF agreement on how to progress MPLS-TP development. Everything in the liaison is fact. Whether draft-bhh is good/bad/ugly, = deployed, supported by operators, etc. is irrelevant, it is not endorsed = by IETF as a MPLS-TP OAM solution and all the liaison does is point out = that fact. FWIW this isn't the first time a group of operators have brought a = proposal to IETF only to find that the IETF has decided to do something = else, and I'm sure it won't be the last.=20 Ben P.S. for some reason email chains related to draft-bhh remind me of this = Dilbert cartoon http://www.dilbert.com/2010-12-22/ > Best regards, >=20 > Han Li >=20 > = ************************************************************************* > Han Li, Ph.D=20 > China Mobile Research Institute > Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 > Fax: +86 10 63601087=20 > MOBILE: 13501093385=20 > = ************************************************************************* >=20 >=20 > --- 11=E5=B9=B41=E6=9C=8813=E6=97=A5=EF=BC=8C=E5=91=A8=E5=9B=9B, = ruiquan.jing@ties.itu.int =E5=86=99=E9=81=93=EF= =BC=9A >=20 >> =E5=8F=91=E4=BB=B6=E4=BA=BA: ruiquan.jing@ties.itu.int = >> =E4=B8=BB=E9=A2=98: Re: [mpls-tp] [mpls] Draft: Response to Updated = draft Recommendation G.tpoam [Ref043.02] >> =E6=94=B6=E4=BB=B6=E4=BA=BA: jingr@ties.itu.ch >> =E6=8A=84=E9=80=81: mpls-tp@ietf.org >> =E6=97=A5=E6=9C=9F: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5,=E5=91=A8=E5=9B=9B= ,=E4=B8=8B=E5=8D=884:09 >> Resend to mpls-tp list. >>=20 >> Quoting jingr@ties.itu.ch: >>=20 >>> Hi Stewart Bryant, >>>=20 >>> I don=E2=80=99t agree with the current LS text. >>>=20 >>> China Telecom support the standardization of Y.1731 >> based MPLS-TP OAM tools >>> in=20 >>> the ITU-T to meet the urgent and increasing >> requirements for PTN deployment.=20 >>>=20 >>> It=E2=80=99s a multi-vendor supported, interoperability >> certificated and feasible=20 >>> solution. It had been specified in both CCSA >> (China Communications Standards >>>=20 >>> Association) and China Telecom=E2=80=99s PTN standard as the >> only standard OAM=20 >>> mechanism. >>>=20 >>> =20 >>>=20 >>> Best Regards >>>=20 >>> Jing Ruiquan >>>=20 >>> China=E3=80=80Telecom Beijing=20 >> Research=E3=80=80Institute >>>=20 >>>=20 >> = --------------------------------------------------------------------------= ---- >> -- >>> From: mpls-bounces@ietf.org >> [mailto:mpls-bounces@ietf.org] >> On Behalf Of >>> Stewart=20 >>> Bryant >>> Sent: Monday, January 10, 2011 6:57 PM >>> To: mpls@ietf.org >>> Subject: [mpls] Draft: Response to Updated draft >> Recommendation G.tpoam=20 >>> [Ref043.02] >>>=20 >>>=20 >>> I propose to send the following Liaison Response to >> the ITU-T on Friday=20 >>> 14th January and am posting it to the MPLS WG list for >> review.=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=20 >>>=20 >>> Response to Updated draft Recommendation G.tpoam [Ref >> 043.02]=20 >>>=20 >>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >>=20 >>> To: tsbsg15@itu.int, >> greg.jones@itu.int, >> hiroshi.ota@itu.int, >> IAB@ietf.org=20 >>> CC: Greg Jones, swallow@cisco.com, >> loa@pi.nu, paf@cisco.com=20 >>> stbryant@cisco.com, >> adrian.farrel@huawei.com, >> mpls@ietf.org=20 >>> yoichi.maeda@ttc.or.jp, >> steve.trowbridge@alcatel-lucent.com >>=20 >>> ghani.abbas@ericsson.com, >> hhelvoort@huawei.com >>=20 >>> malcolm.betts@zte.com.cn, >> kam.lam@alcatel-lucent.com >>=20 >>>=20 >>> For Action=20 >>>=20 >>> The MPLS Working Group notes that this document >> contains text describing=20 >>> MPLS-TP OAM protocols not designed and standardized >> using the IETF=20 >>> Standards process. Specifically it uses material from >>=20 >>> draft-bhh-mpls-tp-oam-y1731-06.=20 >>>=20 >>> We wish to draw your attention to the status section >> of=20 >>> draft-bhh-mpls-tp-oam-y1731-06 which states:=20 >>>=20 >>> "Internet-Drafts are draft documents valid for a >> maximum of six months=20 >>> and may be updated, replaced, or obsoleted by other >> documents at any=20 >>> time. It is inappropriate to use Internet-Drafts as >> reference material=20 >>> or to cite them other than as "work in progress".=20 >>>=20 >>> Please also note that since the draft filename starts >> with the prefix=20 >>> string "draft-bhh" this clearly identifies it to the >> reader as a=20 >>> document expressing the personal technical views of >> the authors and=20 >>> hence hence as a document that that does not have any >> acknowledged level=20 >>> of IETF consensus.=20 >>>=20 >>> Since the text of draft Recommendation for G.tpoam is >> based on an=20 >>> MPLS-TP OAM protocol not designed within the IETF >> Standards Process this=20 >>> is a breach of the SG15 agreement with the IETF as >> published in Report=20 >>> of the first meeting of Working Party 3/15 Transport >> network structures=20 >>> (2009-2012) (Geneva, 1 =E2=80=93 12 December 2008) which can >> be found at=20 >>> http://www.itu.int/md/T09-SG15-R-0004/en >>=20 >>>=20 >>> Please confirm that the ITU-T intends to continue with >> the joint work on=20 >>> MPLS-TP and that the ITU-T will align this >> recommendation with the IETF=20 >>> MPLS-TP OAM design before advancing this document >> through the ITU-T=20 >>> publication process.=20 >>>=20 >>> The MPLS Working Group would also like to draw the >> attention of ITU-T=20 >>> SG15 to the IETF copyright rules. Please see=20 >>> = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- >>> 20091228.htm=20 >>> for further details.=20 >>>=20 >>> Since this draft Recommendation contains text in which >> the ITU-T SG15=20 >>> has proposed making changes to IETF protocols without >> the approval of=20 >>> the IETF, the MPLS Working Group have referred this >> liaison to the IAB=20 >>> for their consideration.=20 >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >>> _______________________________________________=20 >>> mpls mailing list=20 >>> mpls@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/mpls=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From alessandro.dalessandro@telecomitalia.it Thu Jan 13 08:18:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344F93A6BB4 for ; Thu, 13 Jan 2011 08:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.715 X-Spam-Level: * X-Spam-Status: No, score=1.715 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcnExIEEhJi3 for ; Thu, 13 Jan 2011 08:18:24 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by core3.amsl.com (Postfix) with ESMTP id DCEFF3A6BB9 for ; Thu, 13 Jan 2011 08:18:23 -0800 (PST) Content-Type: multipart/mixed; boundary="_91d43299-5390-4718-8d0c-73ecf779e4ee_" Received: from GRFHUB706RM001.griffon.local (10.19.3.71) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Jan 2011 17:20:45 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by GRFHUB706RM001.griffon.local ([10.19.9.239]) with mapi; Thu, 13 Jan 2011 17:20:45 +0100 From: D'Alessandro Alessandro Gerardo To: "stbryant@cisco.com" , "mpls@ietf.org" Date: Thu, 13 Jan 2011 17:20:43 +0100 Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: AcuwtRRfrWRIYWIyQSuhsgVsQwpebQCelrnw Message-ID: References: <4D2AE5E0.90703@cisco.com> In-Reply-To: <4D2AE5E0.90703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 16:18:33 -0000 --_91d43299-5390-4718-8d0c-73ecf779e4ee_ Content-Type: multipart/alternative; boundary="_000_A1F769BC58A8B146B2EEA818EAE052A20966098744GRFMBX702RM00_" --_000_A1F769BC58A8B146B2EEA818EAE052A20966098744GRFMBX702RM00_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Stewart, all, I do not agree on the proposed Liaison text for the reasons explained inlin= e below. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: luned=EC 10 gennaio 2011 11.57 To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Re= f 043.02] I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. [dalessandro] In my understanding ITU-T G.tpoam is based on ITU-T Y.1731. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. [dalessandro] I would take the opportunity this email give me to invite IET= F community to review draft-bhh (and the other related contributions)that a= re fueling a lot of discussions inside IETF. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en [dalessandro] In my understanding ITU-T documents are based on contribution= s and consensus. G.tpoam does not preclude inclusion of material agreed ins= ide IETF therefore I do not see it as a breach of the SG15 agreement with t= he IETF. For that reason I do not agree sending this Liaison. Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. [dalessandro] Is it appropriate for IETF to do that statement? I never hear= d statements in ITU-T meetings and I never read ITU-T contributions asking = to break the joint work with IETF. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2009= 1228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A1F769BC58A8B146B2EEA818EAE052A20966098744GRFMBX702RM00_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Stewart, all,<= /font>

I do not agree on the proposed Liaiso= n text for the reasons explained inline below.

 

Best regards,

Alessandro

------------------------------------------------------------------<= o:p>

Telecom Italia

Alessandro D'Alessandro

Transport & OPB Innovation

Via Reiss Romoli, 274 - 10148 Torino

phone:  +39 011 228 5887

mobile: +39 335 766 9607

fax: +39 06 418 639 07=

 

 

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: luned=EC 10 gennaio 2011 11.57
To: mpls@ietf.org
Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Re= f 043.02]

 

I propose to send the following Liais= on Response to the ITU-T on Friday

14th January and am posting it to the= MPLS WG list for review.

 

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

 

Response to Updated draft Recommendat= ion G.tpoam [Ref 043.02]

 

From: IETF Liaison to ITU-T on MPLS s= tbryant@cisco.com

To: tsbsg15@itu.int, greg.jones@itu.i= nt, hiroshi.ota@itu.int, IAB@ietf.org

CC: Greg Jones, swallow@cisco.com, loa@pi.nu, = paf@cisco.com

stbryant@cisco.com, adrian.farrel@hua= wei.com, mpls@ietf.org

yoichi.maeda@ttc.or.jp, steve.trowbri= dge@alcatel-lucent.com

ghani.abba= s@ericsson.com, hhelvoort@huawei.com

malcolm.betts@zte.com.cn, kam.lam@alc= atel-lucent.com

 

For Action

 

The MPLS Working Group notes that thi= s document contains text describing

MPLS-TP OAM protocols not designed an= d standardized using the IETF

Standards process. Specifically it us= es material from

draft-bhh-mpls-tp-oam-y1731-06.<= /o:p>

[dalessandro] = In my understanding ITU-T G.tpoam is based on ITU-T Y.1731.

 

We wish to draw your attention to the= status section of

draft-bhh-mpls-tp-oam-y1731-06 which = states:

 

"Internet-Drafts are draft docum= ents valid for a maximum of six months

and may be updated, replaced, or obso= leted by other documents at any

time. It is inappropriate to use Inte= rnet-Drafts as reference material

or to cite them other than as "w= ork in progress".

 

Please also note that since the draft= filename starts with the prefix

string "draft-bhh" this cle= arly identifies it to the reader as a

document expressing the personal tech= nical views of the authors and

hence hence as a document that that d= oes not have any acknowledged level

of IETF consensus.<= /font>

[dalessandro] = I would take the opportunity this email give me to invite IETF community to= review draft-bhh (and the other related contributions)that are fueling a lot of discussions inside IETF.

 = ;

Since the text of draft Recommendatio= n for G.tpoam is based on an

MPLS-TP OAM protocol not designed wit= hin the IETF Standards Process this

is a breach of the SG15 agreement wit= h the IETF as published in Report

of the first meeting of Working Party= 3/15 Transport network structures

(2009-2012) (<= st1:City w:st=3D"on">Geneva, 1 – 12 December 2= 008) which can be found at

http://www.itu.int/md/T09-SG15-R-0004= /en

[dalessandro] = In my understanding ITU-T documents are based on contributions and consensu= s. G.tpoam does not preclude inclusion of material agreed inside IETF therefore I do not see it as a breach of the SG15 agree= ment with the IETF. For that reason I do not agree sending this Liaison.

 

Please confirm that the ITU-T intends= to continue with the joint work on

MPLS-TP and that the ITU-T will align= this recommendation with the IETF

MPLS-TP OAM design before advancing t= his document through the ITU-T

publication process.

[dalessandro] = Is it appropriate for IETF to do that statement? I never heard statements i= n ITU-T meetings and I never read ITU-T contributions asking to break the joint work with IETF.

 = ;

 

The MPLS Working Group would also lik= e to draw the attention of ITU-T

SG15 to the IETF copyright rules. Ple= ase see

http://trustee.ietf.org/license-info/= archive/IETF-Trust-License-Policy-20091228.htm

for further details.

 

Since this draft Recommendation conta= ins text in which the ITU-T SG15

has proposed making changes to IETF p= rotocols without the approval of

the IETF, the MPLS Working Group have= referred this liaison to the IAB

for their consideration.

 

 

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

_____________________________________= __________

mpls mailing list

mpls@ietf.= org

https://www.ietf.org/mailman/listinfo= /mpls

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A1F769BC58A8B146B2EEA818EAE052A20966098744GRFMBX702RM00_-- --_91d43299-5390-4718-8d0c-73ecf779e4ee_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_91d43299-5390-4718-8d0c-73ecf779e4ee_-- From stbryant@cisco.com Thu Jan 13 08:25:12 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DB93A6B33 for ; Thu, 13 Jan 2011 08:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9QhHMCOYbml for ; Thu, 13 Jan 2011 08:25:10 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7945E3A69ED for ; Thu, 13 Jan 2011 08:25:09 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABq3Lk1AZnwN/2dsb2JhbACECKBAc6QsglEOAYd1jXeBIYM3dASLEA Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2011 16:27:32 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0DGRVtb025320 for ; Thu, 13 Jan 2011 16:27:31 GMT Received: from dhcp-gpk02-vlan300-64-103-65-54.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0DGRT827893; Thu, 13 Jan 2011 16:27:30 GMT Message-ID: <4D2F27F1.1070209@cisco.com> Date: Thu, 13 Jan 2011 16:27:29 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mpls@ietf.org References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 16:25:13 -0000 Exactly Ben. The Liaison is list of statements of relevant facts, and none of the contra points dispute those facts. Stewart On 13/01/2011 15:41, Ben Niven-Jenkins wrote: > Larry, > > On 13 Jan 2011, at 14:55, Larry wrote: > >> Hi, >> >> I don't think it is proper to send the LS to ITU-T because the text doesn't reflect the requirement from providers. >> Apparently, draft-bhh based OAM is the most mature solution currently. It has been proved by more than 200,000 applications and is supported by a lot of operators and vendors. >> > That may or may not be true, but either way it is irrelevant to the liaison. > > ITU liaised G.tpoam to IETF. The liaison response Stewart has drafted points out that G.tpoam uses technology (draft-bhh) that is not endorsed by IETF consensus and points to some risks of doing so, including breach of a prior ITU-IETF agreement on how to progress MPLS-TP development. > > Everything in the liaison is fact. Whether draft-bhh is good/bad/ugly, deployed, supported by operators, etc. is irrelevant, it is not endorsed by IETF as a MPLS-TP OAM solution and all the liaison does is point out that fact. > > FWIW this isn't the first time a group of operators have brought a proposal to IETF only to find that the IETF has decided to do something else, and I'm sure it won't be the last. > > Ben > > P.S. for some reason email chains related to draft-bhh remind me of this Dilbert cartoon http://www.dilbert.com/2010-12-22/ > > > >> Best regards, >> >> Han Li >> >> ************************************************************************* >> Han Li, Ph.D >> China Mobile Research Institute >> Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China >> Fax: +86 10 63601087 >> MOBILE: 13501093385 >> ************************************************************************* >> >> >> --- 11å¹´1月13日，周四, ruiquan.jing@ties.itu.int 写é“： >> >>> å‘件人: ruiquan.jing@ties.itu.int >>> 主题: Re: [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] >>> 收件人: jingr@ties.itu.ch >>> 抄é€: mpls-tp@ietf.org >>> 日期: 2011å¹´1月13æ—¥,周四,下åˆ4:09 >>> Resend to mpls-tp list. >>> >>> Quoting jingr@ties.itu.ch: >>> >>>> Hi Stewart Bryant, >>>> >>>> I don’t agree with the current LS text. >>>> >>>> China Telecom support the standardization of Y.1731 >>> based MPLS-TP OAM tools >>>> in >>>> the ITU-T to meet the urgent and increasing >>> requirements for PTN deployment. >>>> It’s a multi-vendor supported, interoperability >>> certificated and feasible >>>> solution. It had been specified in both CCSA >>> (China Communications Standards >>>> Association) and China Telecom’s PTN standard as the >>> only standard OAM >>>> mechanism. >>>> >>>> >>>> >>>> Best Regards >>>> >>>> Jing Ruiquan >>>> >>>> China　Telecom Beijing >>> Research　Institute >>>> >>> ------------------------------------------------------------------------------ >>> -- >>>> From: mpls-bounces@ietf.org >>> [mailto:mpls-bounces@ietf.org] >>> On Behalf Of >>>> Stewart >>>> Bryant >>>> Sent: Monday, January 10, 2011 6:57 PM >>>> To: mpls@ietf.org >>>> Subject: [mpls] Draft: Response to Updated draft >>> Recommendation G.tpoam >>>> [Ref043.02] >>>> >>>> >>>> I propose to send the following Liaison Response to >>> the ITU-T on Friday >>>> 14th January and am posting it to the MPLS WG list for >>> review. >>>> ======= >>>> >>>> Response to Updated draft Recommendation G.tpoam [Ref >>> 043.02] >>>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >>>> To: tsbsg15@itu.int, >>> greg.jones@itu.int, >>> hiroshi.ota@itu.int, >>> IAB@ietf.org >>>> CC: Greg Jones, swallow@cisco.com, >>> loa@pi.nu, paf@cisco.com >>>> stbryant@cisco.com, >>> adrian.farrel@huawei.com, >>> mpls@ietf.org >>>> yoichi.maeda@ttc.or.jp, >>> steve.trowbridge@alcatel-lucent.com >>> >>>> ghani.abbas@ericsson.com, >>> hhelvoort@huawei.com >>> >>>> malcolm.betts@zte.com.cn, >>> kam.lam@alcatel-lucent.com >>> >>>> For Action >>>> >>>> The MPLS Working Group notes that this document >>> contains text describing >>>> MPLS-TP OAM protocols not designed and standardized >>> using the IETF >>>> Standards process. Specifically it uses material from >>>> draft-bhh-mpls-tp-oam-y1731-06. >>>> >>>> We wish to draw your attention to the status section >>> of >>>> draft-bhh-mpls-tp-oam-y1731-06 which states: >>>> >>>> "Internet-Drafts are draft documents valid for a >>> maximum of six months >>>> and may be updated, replaced, or obsoleted by other >>> documents at any >>>> time. It is inappropriate to use Internet-Drafts as >>> reference material >>>> or to cite them other than as "work in progress". >>>> >>>> Please also note that since the draft filename starts >>> with the prefix >>>> string "draft-bhh" this clearly identifies it to the >>> reader as a >>>> document expressing the personal technical views of >>> the authors and >>>> hence hence as a document that that does not have any >>> acknowledged level >>>> of IETF consensus. >>>> >>>> Since the text of draft Recommendation for G.tpoam is >>> based on an >>>> MPLS-TP OAM protocol not designed within the IETF >>> Standards Process this >>>> is a breach of the SG15 agreement with the IETF as >>> published in Report >>>> of the first meeting of Working Party 3/15 Transport >>> network structures >>>> (2009-2012) (Geneva, 1 – 12 December 2008) which can >>> be found at >>>> http://www.itu.int/md/T09-SG15-R-0004/en >>>> Please confirm that the ITU-T intends to continue with >>> the joint work on >>>> MPLS-TP and that the ITU-T will align this >>> recommendation with the IETF >>>> MPLS-TP OAM design before advancing this document >>> through the ITU-T >>>> publication process. >>>> >>>> The MPLS Working Group would also like to draw the >>> attention of ITU-T >>>> SG15 to the IETF copyright rules. Please see >>>> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- >>>> 20091228.htm >>>> for further details. >>>> >>>> Since this draft Recommendation contains text in which >>> the ITU-T SG15 >>>> has proposed making changes to IETF protocols without >>> the approval of >>>> the IETF, the MPLS Working Group have referred this >>> liaison to the IAB >>>> for their consideration. >>>> >>>> >>>> >>>> ========= >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Thu Jan 13 09:02:34 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418B528C0E8 for ; Thu, 13 Jan 2011 09:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.086 X-Spam-Level: X-Spam-Status: No, score=-109.086 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oiFafte2Uqw for ; Thu, 13 Jan 2011 09:02:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 89BC43A6BBC for ; Thu, 13 Jan 2011 09:02:24 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFANe+Lk2rRDoJ/2dsb2JhbACCOp0shGJzpEeCUQ4BlWkCgwyCPgSBXoky Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2011 17:04:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0DH4j3u028821; Thu, 13 Jan 2011 17:04:46 GMT Received: from dhcp-gpk02-vlan300-64-103-65-54.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0DH4h800550; Thu, 13 Jan 2011 17:04:43 GMT Message-ID: <4D2F30AB.2060902@cisco.com> Date: Thu, 13 Jan 2011 17:04:43 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "D'Alessandro Alessandro Gerardo" References: <4D2AE5E0.90703@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090901060907000401060804" Cc: "mpls@ietf.org" Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:02:34 -0000 This is a multi-part message in MIME format. --------------090901060907000401060804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Please see inline On 13/01/2011 16:20, D'Alessandro Alessandro Gerardo wrote: > > Dear Stewart, all, > > I do not agree on the proposed Liaison text for the reasons explained > inline below. > > Best regards, > > Alessandro > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport & OPB Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Stewart Bryant > Sent: lunedì 10 gennaio 2011 11.57 > To: mpls@ietf.org > Subject: [mpls] Draft: Response to Updated draft Recommendation > G.tpoam [Ref 043.02] > > I propose to send the following Liaison Response to the ITU-T on Friday > > 14th January and am posting it to the MPLS WG list for review. > > ======= > > Response to Updated draft Recommendation G.tpoam [Ref 043.02] > > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org > > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com > > stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org > > yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com > > ghani.abbas@ericsson.com, hhelvoort@huawei.com > > malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com > > For Action > > The MPLS Working Group notes that this document contains text describing > > MPLS-TP OAM protocols not designed and standardized using the IETF > > Standards process. Specifically it uses material from > > draft-bhh-mpls-tp-oam-y1731-06. > > [dalessandro] In my understanding ITU-T G.tpoam is based on ITU-T Y.1731. > Please read the inbound liaison. It specifically states that the changes to G.tpoam based on draft-bhh-mpls-tp-oam-y1731 > > We wish to draw your attention to the status section of > > draft-bhh-mpls-tp-oam-y1731-06 which states: > > "Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference material > > or to cite them other than as "work in progress". > > Please also note that since the draft filename starts with the prefix > > string "draft-bhh" this clearly identifies it to the reader as a > > document expressing the personal technical views of the authors and > > hence hence as a document that that does not have any acknowledged level > > of IETF consensus. > > [dalessandro] I would take the opportunity this email give me to > invite IETF community to review draft-bhh (and the other related > contributions)that are fueling a lot of discussions inside IETF. > Please see Ben's email on this thread > > Since the text of draft Recommendation for G.tpoam is based on an > > MPLS-TP OAM protocol not designed within the IETF Standards Process this > > is a breach of the SG15 agreement with the IETF as published in Report > > of the first meeting of Working Party 3/15 Transport network structures > > (2009-2012) (Geneva, 1 -- 12 December 2008) which can be found at > > http://www.itu.int/md/T09-SG15-R-0004/en > > [dalessandro] In my understanding ITU-T documents are based on > contributions and consensus. G.tpoam does not preclude inclusion of > material agreed inside IETF therefore I do not see it as a breach of > the SG15 agreement with the IETF. For that reason I do not agree > sending this Liaison. > In the case of MPLS-TP, the agreement is that the protocols will be standardized using the IETF Standards Process. The relevant text in the JWT is: Consensus on recommendation of Option 1 Jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process > Please confirm that the ITU-T intends to continue with the joint work on > > MPLS-TP and that the ITU-T will align this recommendation with the IETF > > MPLS-TP OAM design before advancing this document through the ITU-T > > publication process. > > [dalessandro] Is it appropriate for IETF to do that statement? I never > heard statements in ITU-T meetings and I never read ITU-T > contributions asking to break the joint work with IETF. > The output of the Berlin meeting seems to throw considerable doubt on the ITU-T intentions If the ITU-T is fully committed to the JWT, the answer will be a simple "yes". > The MPLS Working Group would also like to draw the attention of ITU-T > > SG15 to the IETF copyright rules. Please see > > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm > > > for further details. > > Since this draft Recommendation contains text in which the ITU-T SG15 > > has proposed making changes to IETF protocols without the approval of > > the IETF, the MPLS Working Group have referred this liaison to the IAB > > for their consideration. > > ========= > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > /This e-mail and any attachments//is //confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete > this message and any attachments and advise the sender by return > e-mail, Thanks./ > > *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se > non è necessario.* > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------090901060907000401060804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please see inline

On 13/01/2011 16:20, D'Alessandro Alessandro Gerardo wrote: Please read the inbound liaison. It specifically states that the changes to G.tpoam based on draft-bhh-mpls-tp-oam-y1731

 

We wish to draw your attention to the status section of

draft-bhh-mpls-tp-oam-y1731-06 which states:

 

"Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference material

or to cite them other than as "work in progress".

 

Please also note that since the draft filename starts with the prefix

string "draft-bhh" this clearly identifies it to the reader as a

document expressing the personal technical views of the authors and

hence hence as a document that that does not have any acknowledged level

of IETF consensus.

[dalessandro] I would take the opportunity this email give me to invite IETF community to review draft-bhh (and the other related contributions)that are fueling a lot of discussions inside IETF.

Please see Ben's email on this thread

 

Since the text of draft Recommendation for G.tpoam is based on an

MPLS-TP OAM protocol not designed within the IETF Standards Process this

is a breach of the SG15 agreement with the IETF as published in Report

of the first meeting of Working Party 3/15 Transport network structures

(2009-2012) (Geneva, 1 – 12 December 2008) which can be found at

http://www.itu.int/md/T09-SG15-R-0004/en

[dalessandro] In my understanding ITU-T documents are based on contributions and consensus. G.tpoam does not preclude inclusion of material agreed inside IETF therefore I do not see it as a breach of the SG15 agreement with the IETF. For that reason I do not agree sending this Liaison.

In the case of MPLS-TP, the agreement is that the protocols will be standardized using the IETF Standards Process.

The relevant text in the JWT is:

Consensus on recommendation of Option 1
Jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process


 

Please confirm that the ITU-T intends to continue with the joint work on

MPLS-TP and that the ITU-T will align this recommendation with the IETF

MPLS-TP OAM design before advancing this document through the ITU-T

publication process.

[dalessandro] Is it appropriate for IETF to do that statement? I never heard statements in ITU-T meetings and I never read ITU-T contributions asking to break the joint work with IETF.

The output of the Berlin meeting seems to throw considerable doubt on the ITU-T intentions

If the ITU-T is fully committed to the JWT, the answer will be a simple "yes".


 

 

The MPLS Working Group would also like to draw the attention of ITU-T

SG15 to the IETF copyright rules. Please see

http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm

for further details.

 

Since this draft Recommendation contains text in which the ITU-T SG15

has proposed making changes to IETF protocols without the approval of

the IETF, the MPLS Working Group have referred this liaison to the IAB

for their consideration.

 

 

=========

_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario. 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------090901060907000401060804-- From david.sinicrope@ericsson.com Thu Jan 13 09:07:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA4028C0E0 for ; Thu, 13 Jan 2011 09:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgDc1mx4YYtw for ; Thu, 13 Jan 2011 09:07:30 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 3AFF53A6B15 for ; Thu, 13 Jan 2011 09:07:30 -0800 (PST) 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 p0DHlgwo004516; Thu, 13 Jan 2011 11:47:43 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 13 Jan 2011 12:09:49 -0500 From: David Sinicrope To: "stbryant@cisco.com" , "mpls@ietf.org" Date: Thu, 13 Jan 2011 12:09:48 -0500 Thread-Topic: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuzPtNiCSJci2O7QCyzhe3lOc/srgABGhvw Message-ID: <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se> References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> In-Reply-To: <4D2F27F1.1070209@cisco.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:07:31 -0000 SXQgc2VlbXMgdGhhdCByZWZlcmVuY2UgYW5kIHVzZSBvZiBkcmFmdC1iaGggaXMgaW4gdmlvbGF0 aW9uIG9mIHRoZSBJVFUtVCBleHRlcm5hbCBjb29wZXJhdGlvbiBhZ3JlZW1lbnQgIlJlZmVyZW5j aW5nIEEuNSBRdWFsaWZpZWQgT3JnYW5pemF0aW9ucyIgdGV4dCBmb3VuZCBhdCANCmh0dHA6Ly93 d3cuaXR1LmludC9lbi9JVFUtVC9leHRjb29wL1BhZ2VzL3Nkby5hc3B4IHVuZGVyIHRoZSBSZWZl cmVuY2luZyBJRVRGIERvY3VtZW50cyBsaW5rLg0KSW4gcGFydGljdWxhciBjbGF1c2UgMTAgb2Yg dGhpcyBkb2N1bWVudCBzdGF0ZXM6IChTZWUgMm5kIHNlbnRlbmNlLikNCg0KIjEwCU90aGVyOiBJ ZiBhIHN0dWR5IGdyb3VwIGRlY2lkZXMgdG8gbWFrZSB0aGUgcmVmZXJlbmNlIHRvIGFuIElFVEYg UkZDLCB0aGUgcmVmZXJlbmNlIHNob3VsZCBhbHdheXMgYmUgbWFkZSBieSBSRkMgbnVtYmVyIChh bmQgbm90IGJ5IG90aGVyIGRlc2lnbmF0aW9ucyBzdWNoIGFzIFNURCwgQkNQLCBldGMuKS4gUmVm ZXJlbmNlcyBzaG91bGQgbm90IGJlIG1hZGUgdG8gZG9jdW1lbnRzIHJlZmVycmVkIHRvIGFzICJJ bnRlcm5ldCBEcmFmdHMiIG9yIHRvIElFVEYgUkZDcyBjYXRlZ29yaXplZCBhcyBIaXN0b3JpYyBv ciBFeHBlcmltZW50YWwuIE5vcm1hdGl2ZSByZWZlcmVuY2VzIG11c3Qgb25seSBiZSBtYWRlIHRv IElFVEYgUkZDcyB0aGF0IGFyZSBTdGFuZGFyZHMgVHJhY2sgb3IgdG8gSW5mb3JtYXRpb25hbCBS RkNzIHRoYXQgaGF2ZSBJRVRGIGNvbnNlbnN1cy4iDQoNCklzIHRoaXMgbm90IGNvcnJlY3Q/ICBJ ZiBjb3JyZWN0LCBzaG91bGRuJ3QgdGhpcyBhbHNvIGJlIHBvaW50ZWQgb3V0IGluIHRoZSBsaWFp c29uPw0KRGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U3Rld2FydCBCcnlhbnQNClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDExIDExOjI3IEFN DQpUbzogbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBbbXBscy10cF0gRHJhZnQ6 IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmMDQz LjAyXQ0KDQpFeGFjdGx5IEJlbi4NCg0KVGhlIExpYWlzb24gaXMgbGlzdCBvZiBzdGF0ZW1lbnRz IG9mIHJlbGV2YW50IGZhY3RzLCBhbmQgbm9uZSBvZiB0aGUgY29udHJhIHBvaW50cyBkaXNwdXRl IHRob3NlIGZhY3RzLg0KDQpTdGV3YXJ0DQoNCk9uIDEzLzAxLzIwMTEgMTU6NDEsIEJlbiBOaXZl bi1KZW5raW5zIHdyb3RlOg0KPiBMYXJyeSwNCj4NCj4gT24gMTMgSmFuIDIwMTEsIGF0IDE0OjU1 LCBMYXJyeSB3cm90ZToNCj4NCj4+IEhpLA0KPj4NCj4+ICAgICBJIGRvbid0IHRoaW5rIGl0IGlz IHByb3BlciB0byBzZW5kIHRoZSBMUyB0byBJVFUtVCBiZWNhdXNlIHRoZSB0ZXh0IGRvZXNuJ3Qg cmVmbGVjdCB0aGUgcmVxdWlyZW1lbnQgZnJvbSBwcm92aWRlcnMuDQo+PiAgICAgQXBwYXJlbnRs eSwgZHJhZnQtYmhoIGJhc2VkIE9BTSBpcyB0aGUgbW9zdCBtYXR1cmUgc29sdXRpb24gY3VycmVu dGx5LiBJdCBoYXMgYmVlbiBwcm92ZWQgYnkgbW9yZSB0aGFuIDIwMCwwMDAgYXBwbGljYXRpb25z IGFuZCBpcyBzdXBwb3J0ZWQgYnkgYSBsb3Qgb2Ygb3BlcmF0b3JzIGFuZCB2ZW5kb3JzLg0KPj4N Cj4gVGhhdCBtYXkgb3IgbWF5IG5vdCBiZSB0cnVlLCBidXQgZWl0aGVyIHdheSBpdCBpcyBpcnJl bGV2YW50IHRvIHRoZSBsaWFpc29uLg0KPg0KPiBJVFUgbGlhaXNlZCBHLnRwb2FtIHRvIElFVEYu IFRoZSBsaWFpc29uIHJlc3BvbnNlIFN0ZXdhcnQgaGFzIGRyYWZ0ZWQgcG9pbnRzIG91dCB0aGF0 IEcudHBvYW0gdXNlcyB0ZWNobm9sb2d5IChkcmFmdC1iaGgpIHRoYXQgaXMgbm90IGVuZG9yc2Vk IGJ5IElFVEYgY29uc2Vuc3VzIGFuZCBwb2ludHMgdG8gc29tZSByaXNrcyBvZiBkb2luZyBzbywg aW5jbHVkaW5nIGJyZWFjaCBvZiBhIHByaW9yIElUVS1JRVRGIGFncmVlbWVudCBvbiBob3cgdG8g cHJvZ3Jlc3MgTVBMUy1UUCBkZXZlbG9wbWVudC4NCj4NCj4gRXZlcnl0aGluZyBpbiB0aGUgbGlh aXNvbiBpcyBmYWN0LiBXaGV0aGVyIGRyYWZ0LWJoaCBpcyBnb29kL2JhZC91Z2x5LCBkZXBsb3ll ZCwgc3VwcG9ydGVkIGJ5IG9wZXJhdG9ycywgZXRjLiBpcyBpcnJlbGV2YW50LCBpdCBpcyBub3Qg ZW5kb3JzZWQgYnkgSUVURiBhcyBhIE1QTFMtVFAgT0FNIHNvbHV0aW9uIGFuZCBhbGwgdGhlIGxp YWlzb24gZG9lcyBpcyBwb2ludCBvdXQgdGhhdCBmYWN0Lg0KPg0KPiBGV0lXIHRoaXMgaXNuJ3Qg dGhlIGZpcnN0IHRpbWUgYSBncm91cCBvZiBvcGVyYXRvcnMgaGF2ZSBicm91Z2h0IGEgcHJvcG9z YWwgdG8gSUVURiBvbmx5IHRvIGZpbmQgdGhhdCB0aGUgSUVURiBoYXMgZGVjaWRlZCB0byBkbyBz b21ldGhpbmcgZWxzZSwgYW5kIEknbSBzdXJlIGl0IHdvbid0IGJlIHRoZSBsYXN0Lg0KPg0KPiBC ZW4NCj4NCj4gUC5TLiBmb3Igc29tZSByZWFzb24gZW1haWwgY2hhaW5zIHJlbGF0ZWQgdG8gZHJh ZnQtYmhoIHJlbWluZCBtZSBvZiANCj4gdGhpcyBEaWxiZXJ0IGNhcnRvb24gaHR0cDovL3d3dy5k aWxiZXJ0LmNvbS8yMDEwLTEyLTIyLw0KPg0KPg0KPg0KPj4gQmVzdCByZWdhcmRzLA0KPj4NCj4+ ICAgICAgICAgICAgICAgSGFuIExpDQo+Pg0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+PiAqKioqDQo+PiBI YW4gTGksIFBoLkQNCj4+IENoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGUNCj4+IFVuaXQg MiwgMjggWHVhbnd1bWVueGkgQXZlLCBYdWFud3UgRGlzdHJpY3QsIEJlaWppbmcgMTAwMDUzLCBD aGluYQ0KPj4gRmF4OiArODYgMTAgNjM2MDEwODcNCj4+IE1PQklMRTogMTM1MDEwOTMzODUNCj4+ ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPj4gKioqKg0KPj4NCj4+DQo+PiAtLS0gMTHlubQx5pyIMTPml6XvvIzl kajlm5ssIHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ8cnVpcXVhbi5qaW5nQHRpZXMuaXR1Lmlu dD4gIA0KPj4g5YaZ6YGT77yaDQo+Pg0KPj4+IOWPkeS7tuS6ujogcnVpcXVhbi5qaW5nQHRpZXMu aXR1LmludDxydWlxdWFuLmppbmdAdGllcy5pdHUuaW50Pg0KPj4+IOS4u+mimDogUmU6IFttcGxz LXRwXSBbbXBsc10gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgDQo+Pj4gUmVjb21t ZW5kYXRpb24gRy50cG9hbSBbUmVmMDQzLjAyXQ0KPj4+IOaUtuS7tuS6ujogamluZ3JAdGllcy5p dHUuY2gNCj4+PiDmioTpgIE6IG1wbHMtdHBAaWV0Zi5vcmcNCj4+PiDml6XmnJ86IDIwMTHlubQx 5pyIMTPml6Us5ZGo5ZubLOS4i+WNiDQ6MDkNCj4+PiBSZXNlbmQgdG8gbXBscy10cCBsaXN0Lg0K Pj4+DQo+Pj4gUXVvdGluZyBqaW5nckB0aWVzLml0dS5jaDoNCj4+Pg0KPj4+PiBIaSBTdGV3YXJ0 IEJyeWFudCwNCj4+Pj4NCj4+Pj4gSSBkb27igJl0IGFncmVlIHdpdGggdGhlIGN1cnJlbnQgTFMg dGV4dC4NCj4+Pj4NCj4+Pj4gQ2hpbmEgVGVsZWNvbSBzdXBwb3J0IHRoZSBzdGFuZGFyZGl6YXRp b24gb2YgWS4xNzMxDQo+Pj4gYmFzZWQgTVBMUy1UUCBPQU0gdG9vbHMNCj4+Pj4gaW4NCj4+Pj4g dGhlIElUVS1UIHRvIG1lZXQgdGhlIHVyZ2VudCBhbmQgaW5jcmVhc2luZw0KPj4+IHJlcXVpcmVt ZW50cyBmb3IgUFROIGRlcGxveW1lbnQuDQo+Pj4+IEl04oCZcyBhIG11bHRpLXZlbmRvciBzdXBw b3J0ZWQsIGludGVyb3BlcmFiaWxpdHkNCj4+PiBjZXJ0aWZpY2F0ZWQgYW5kIGZlYXNpYmxlDQo+ Pj4+IHNvbHV0aW9uLiAgSXQgaGFkIGJlZW4gc3BlY2lmaWVkIGluIGJvdGggQ0NTQQ0KPj4+IChD aGluYSBDb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMNCj4+Pj4gQXNzb2NpYXRpb24pIGFuZCBDaGlu YSBUZWxlY29t4oCZcyBQVE4gc3RhbmRhcmQgYXMgdGhlDQo+Pj4gb25seSBzdGFuZGFyZCBPQU0N Cj4+Pj4gbWVjaGFuaXNtLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBCZXN0IFJlZ2FyZHMNCj4+ Pj4NCj4+Pj4gSmluZyBSdWlxdWFuDQo+Pj4+DQo+Pj4+IENoaW5h44CAVGVsZWNvbSAgQmVpamlu Zw0KPj4+IFJlc2VhcmNo44CASW5zdGl0dXRlDQo+Pj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAt LS0tLS0tLS0tDQo+Pj4gLS0NCj4+Pj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnDQo+Pj4g W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4gT24gQmVoYWxmIE9mDQo+Pj4+IFN0 ZXdhcnQNCj4+Pj4gQnJ5YW50DQo+Pj4+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMCwgMjAxMSA2 OjU3IFBNDQo+Pj4+IFRvOiBtcGxzQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFttcGxzXSBEcmFm dDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdA0KPj4+IFJlY29tbWVuZGF0aW9uIEcudHBvYW0N Cj4+Pj4gW1JlZjA0My4wMl0NCj4+Pj4NCj4+Pj4NCj4+Pj4gSSBwcm9wb3NlIHRvIHNlbmQgdGhl IGZvbGxvd2luZyBMaWFpc29uIFJlc3BvbnNlIHRvDQo+Pj4gdGhlIElUVS1UIG9uIEZyaWRheQ0K Pj4+PiAxNHRoIEphbnVhcnkgYW5kIGFtIHBvc3RpbmcgaXQgdG8gdGhlIE1QTFMgV0cgbGlzdCBm b3INCj4+PiByZXZpZXcuDQo+Pj4+ID09PT09PT0NCj4+Pj4NCj4+Pj4gUmVzcG9uc2UgdG8gVXBk YXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYNCj4+PiAwNDMuMDJdDQo+Pj4+ IEZyb206IElFVEYgTGlhaXNvbiB0byBJVFUtVCBvbiBNUExTIHN0YnJ5YW50QGNpc2NvLmNvbQ0K Pj4+PiBUbzogdHNic2cxNUBpdHUuaW50LA0KPj4+IGdyZWcuam9uZXNAaXR1LmludCwNCj4+PiBo aXJvc2hpLm90YUBpdHUuaW50LA0KPj4+IElBQkBpZXRmLm9yZw0KPj4+PiBDQzogR3JlZyBKb25l cywgc3dhbGxvd0BjaXNjby5jb20sDQo+Pj4gbG9hQHBpLm51LCBwYWZAY2lzY28uY29tDQo+Pj4+ IHN0YnJ5YW50QGNpc2NvLmNvbSwNCj4+PiBhZHJpYW4uZmFycmVsQGh1YXdlaS5jb20sDQo+Pj4g bXBsc0BpZXRmLm9yZw0KPj4+PiB5b2ljaGkubWFlZGFAdHRjLm9yLmpwLA0KPj4+IHN0ZXZlLnRy b3dicmlkZ2VAYWxjYXRlbC1sdWNlbnQuY29tDQo+Pj4NCj4+Pj4gZ2hhbmkuYWJiYXNAZXJpY3Nz b24uY29tLA0KPj4+IGhoZWx2b29ydEBodWF3ZWkuY29tDQo+Pj4NCj4+Pj4gbWFsY29sbS5iZXR0 c0B6dGUuY29tLmNuLA0KPj4+IGthbS5sYW1AYWxjYXRlbC1sdWNlbnQuY29tDQo+Pj4NCj4+Pj4g Rm9yIEFjdGlvbg0KPj4+Pg0KPj4+PiBUaGUgTVBMUyBXb3JraW5nIEdyb3VwIG5vdGVzIHRoYXQg dGhpcyBkb2N1bWVudA0KPj4+IGNvbnRhaW5zIHRleHQgZGVzY3JpYmluZw0KPj4+PiBNUExTLVRQ IE9BTSBwcm90b2NvbHMgbm90IGRlc2lnbmVkIGFuZCBzdGFuZGFyZGl6ZWQNCj4+PiB1c2luZyB0 aGUgSUVURg0KPj4+PiBTdGFuZGFyZHMgcHJvY2Vzcy4gU3BlY2lmaWNhbGx5IGl0IHVzZXMgbWF0 ZXJpYWwgZnJvbSANCj4+Pj4gZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2Lg0KPj4+Pg0K Pj4+PiBXZSB3aXNoIHRvIGRyYXcgeW91ciBhdHRlbnRpb24gdG8gdGhlIHN0YXR1cyBzZWN0aW9u DQo+Pj4gb2YNCj4+Pj4gZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2IHdoaWNoIHN0YXRl czoNCj4+Pj4NCj4+Pj4gIkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhDQo+Pj4gbWF4aW11bSBvZiBzaXggbW9udGhzDQo+Pj4+IGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0KPj4+IGRvY3VtZW50cyBhdCBhbnkN Cj4+Pj4gdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFz DQo+Pj4gcmVmZXJlbmNlIG1hdGVyaWFsDQo+Pj4+IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzIi4NCj4+Pj4NCj4+Pj4gUGxlYXNlIGFsc28gbm90ZSB0aGF0 IHNpbmNlIHRoZSBkcmFmdCBmaWxlbmFtZSBzdGFydHMNCj4+PiB3aXRoIHRoZSBwcmVmaXgNCj4+ Pj4gc3RyaW5nICJkcmFmdC1iaGgiIHRoaXMgY2xlYXJseSBpZGVudGlmaWVzIGl0IHRvIHRoZQ0K Pj4+IHJlYWRlciBhcyBhDQo+Pj4+IGRvY3VtZW50IGV4cHJlc3NpbmcgdGhlIHBlcnNvbmFsIHRl Y2huaWNhbCB2aWV3cyBvZg0KPj4+IHRoZSBhdXRob3JzIGFuZA0KPj4+PiBoZW5jZSBoZW5jZSBh cyBhIGRvY3VtZW50IHRoYXQgdGhhdCBkb2VzIG5vdCBoYXZlIGFueQ0KPj4+IGFja25vd2xlZGdl ZCBsZXZlbA0KPj4+PiBvZiBJRVRGIGNvbnNlbnN1cy4NCj4+Pj4NCj4+Pj4gU2luY2UgdGhlIHRl eHQgb2YgZHJhZnQgUmVjb21tZW5kYXRpb24gZm9yIEcudHBvYW0gaXMNCj4+PiBiYXNlZCBvbiBh bg0KPj4+PiBNUExTLVRQIE9BTSBwcm90b2NvbCBub3QgZGVzaWduZWQgd2l0aGluIHRoZSBJRVRG DQo+Pj4gU3RhbmRhcmRzIFByb2Nlc3MgdGhpcw0KPj4+PiBpcyBhIGJyZWFjaCBvZiB0aGUgU0cx NSBhZ3JlZW1lbnQgd2l0aCB0aGUgSUVURiBhcw0KPj4+IHB1Ymxpc2hlZCBpbiBSZXBvcnQNCj4+ Pj4gb2YgdGhlIGZpcnN0IG1lZXRpbmcgb2YgV29ya2luZyBQYXJ0eSAzLzE1IFRyYW5zcG9ydA0K Pj4+IG5ldHdvcmsgc3RydWN0dXJlcw0KPj4+PiAoMjAwOS0yMDEyKSAoR2VuZXZhLCAxIOKAkyAx MiBEZWNlbWJlciAyMDA4KSB3aGljaCBjYW4NCj4+PiBiZSBmb3VuZCBhdA0KPj4+PiBodHRwOi8v d3d3Lml0dS5pbnQvbWQvVDA5LVNHMTUtUi0wMDA0L2VuDQo+Pj4+IFBsZWFzZSBjb25maXJtIHRo YXQgdGhlIElUVS1UIGludGVuZHMgdG8gY29udGludWUgd2l0aA0KPj4+IHRoZSBqb2ludCB3b3Jr IG9uDQo+Pj4+IE1QTFMtVFAgYW5kIHRoYXQgdGhlIElUVS1UIHdpbGwgYWxpZ24gdGhpcw0KPj4+ IHJlY29tbWVuZGF0aW9uIHdpdGggdGhlIElFVEYNCj4+Pj4gTVBMUy1UUCBPQU0gZGVzaWduIGJl Zm9yZSBhZHZhbmNpbmcgdGhpcyBkb2N1bWVudA0KPj4+IHRocm91Z2ggdGhlIElUVS1UDQo+Pj4+ IHB1YmxpY2F0aW9uIHByb2Nlc3MuDQo+Pj4+DQo+Pj4+IFRoZSBNUExTIFdvcmtpbmcgR3JvdXAg d291bGQgYWxzbyBsaWtlIHRvIGRyYXcgdGhlDQo+Pj4gYXR0ZW50aW9uIG9mIElUVS1UDQo+Pj4+ IFNHMTUgdG8gdGhlIElFVEYgY29weXJpZ2h0IHJ1bGVzLiBQbGVhc2Ugc2VlDQo+Pj4+IGh0dHA6 Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mby9hcmNoaXZlL0lFVEYtVHJ1c3QtTGljZW5z ZS1Qb2wNCj4+Pj4gaWN5LQ0KPj4+PiAyMDA5MTIyOC5odG0NCj4+Pj4gZm9yIGZ1cnRoZXIgZGV0 YWlscy4NCj4+Pj4NCj4+Pj4gU2luY2UgdGhpcyBkcmFmdCBSZWNvbW1lbmRhdGlvbiBjb250YWlu cyB0ZXh0IGluIHdoaWNoDQo+Pj4gdGhlIElUVS1UIFNHMTUNCj4+Pj4gaGFzIHByb3Bvc2VkIG1h a2luZyBjaGFuZ2VzIHRvIElFVEYgcHJvdG9jb2xzIHdpdGhvdXQNCj4+PiB0aGUgYXBwcm92YWwg b2YNCj4+Pj4gdGhlIElFVEYsIHRoZSBNUExTIFdvcmtpbmcgR3JvdXAgaGF2ZSByZWZlcnJlZCB0 aGlzDQo+Pj4gbGlhaXNvbiB0byB0aGUgSUFCDQo+Pj4+IGZvciB0aGVpciBjb25zaWRlcmF0aW9u Lg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiA9PT09PT09PT0NCj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QN Cj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBtcGxzLXRwIG1haWxpbmcg bGlzdA0KPj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMtdHANCj4+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4+ IG1wbHMtdHBAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscy10cA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCi0tDQpGb3IgY29ycG9yYXRlIGxl Z2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KDQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQv ZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From hongk@cisco.com Thu Jan 13 09:53:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066F528C13A for ; Thu, 13 Jan 2011 09:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1EKM-3dl0gq for ; Thu, 13 Jan 2011 09:53:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 31CB528C12F for ; Thu, 13 Jan 2011 09:53:42 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAfLLk2tJV2Z/2dsb2JhbACECJ9fZHOkU4pVjXmBIYM3dASEaIlQ Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2011 17:56:04 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0DHu4k6012740 for ; Thu, 13 Jan 2011 17:56:04 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 11:56:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 13 Jan 2011 11:56:03 -0600 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC02FFFDE3@XMB-RCD-103.cisco.com> In-Reply-To: <4D2F27F1.1070209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuzPtGxygzZslkOTH6WKdbKBhDz6gACu1pA References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> From: "Kyung-Yeop Hong (hongk)" To: "Stewart Bryant (stbryant)" , X-OriginalArrivalTime: 13 Jan 2011 17:56:04.0618 (UTC) FILETIME=[25AC9EA0:01CBB34B] Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 17:53:44 -0000 SSBzdXBwb3J0IHRoZSBwcm9wb3NhbC4NCg0KSUVURiBoYXMgYW4gaW50ZXJuYWwgcHJvY2VzcyBm b3IgZXZvbHZpbmcgYW5kIG1haW50YWluaW5nIHRoZSBJRVRGIHByb3RvY29scyBmb3Igd2hpY2gg aXQgaXMgdGhlIGRlc2lnbiBhdXRob3JpdHkuICBUaGUgY2hhbmdlIHByb2Nlc3NlcyBhcmUgaW4g cGxhY2UgW1JGQzQ5MjldIGZvciBNUExTIHByb3RvY29scyB0byB3b3JrIHdpdGggb3RoZXIgU0RP cyB0aGF0IHJlcXVpcmUgZW5oYW5jZW1lbnRzIHRvIGl0cyBwcm90b2NvbHMgYW5kIGFyY2hpdGVj dHVyZXMuDQpJIHRvdGFsbHkgYWdyZWUgd2l0aCB0aGUgcHJvcG9zZWQgbGlhaXNvbiBzdGF0ZW1l bnQuDQoNCktZDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT dGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMywgMjAx MSAxMToyNyBBTQ0KVG86IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gW21wbHMt dHBdIERyYWZ0OiBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBv YW0gW1JlZjA0My4wMl0NCg0KRXhhY3RseSBCZW4uDQoNClRoZSBMaWFpc29uIGlzIGxpc3Qgb2Yg c3RhdGVtZW50cyBvZiByZWxldmFudCBmYWN0cywgYW5kIG5vbmUgb2YgdGhlIA0KY29udHJhIHBv aW50cyBkaXNwdXRlIHRob3NlIGZhY3RzLg0KDQpTdGV3YXJ0DQoNCk9uIDEzLzAxLzIwMTEgMTU6 NDEsIEJlbiBOaXZlbi1KZW5raW5zIHdyb3RlOg0KPiBMYXJyeSwNCj4NCj4gT24gMTMgSmFuIDIw MTEsIGF0IDE0OjU1LCBMYXJyeSB3cm90ZToNCj4NCj4+IEhpLA0KPj4NCj4+ICAgICBJIGRvbid0 IHRoaW5rIGl0IGlzIHByb3BlciB0byBzZW5kIHRoZSBMUyB0byBJVFUtVCBiZWNhdXNlIHRoZSB0 ZXh0IGRvZXNuJ3QgcmVmbGVjdCB0aGUgcmVxdWlyZW1lbnQgZnJvbSBwcm92aWRlcnMuDQo+PiAg ICAgQXBwYXJlbnRseSwgZHJhZnQtYmhoIGJhc2VkIE9BTSBpcyB0aGUgbW9zdCBtYXR1cmUgc29s dXRpb24gY3VycmVudGx5LiBJdCBoYXMgYmVlbiBwcm92ZWQgYnkgbW9yZSB0aGFuIDIwMCwwMDAg YXBwbGljYXRpb25zIGFuZCBpcyBzdXBwb3J0ZWQgYnkgYSBsb3Qgb2Ygb3BlcmF0b3JzIGFuZCB2 ZW5kb3JzLg0KPj4NCj4gVGhhdCBtYXkgb3IgbWF5IG5vdCBiZSB0cnVlLCBidXQgZWl0aGVyIHdh eSBpdCBpcyBpcnJlbGV2YW50IHRvIHRoZSBsaWFpc29uLg0KPg0KPiBJVFUgbGlhaXNlZCBHLnRw b2FtIHRvIElFVEYuIFRoZSBsaWFpc29uIHJlc3BvbnNlIFN0ZXdhcnQgaGFzIGRyYWZ0ZWQgcG9p bnRzIG91dCB0aGF0IEcudHBvYW0gdXNlcyB0ZWNobm9sb2d5IChkcmFmdC1iaGgpIHRoYXQgaXMg bm90IGVuZG9yc2VkIGJ5IElFVEYgY29uc2Vuc3VzIGFuZCBwb2ludHMgdG8gc29tZSByaXNrcyBv ZiBkb2luZyBzbywgaW5jbHVkaW5nIGJyZWFjaCBvZiBhIHByaW9yIElUVS1JRVRGIGFncmVlbWVu dCBvbiBob3cgdG8gcHJvZ3Jlc3MgTVBMUy1UUCBkZXZlbG9wbWVudC4NCj4NCj4gRXZlcnl0aGlu ZyBpbiB0aGUgbGlhaXNvbiBpcyBmYWN0LiBXaGV0aGVyIGRyYWZ0LWJoaCBpcyBnb29kL2JhZC91 Z2x5LCBkZXBsb3llZCwgc3VwcG9ydGVkIGJ5IG9wZXJhdG9ycywgZXRjLiBpcyBpcnJlbGV2YW50 LCBpdCBpcyBub3QgZW5kb3JzZWQgYnkgSUVURiBhcyBhIE1QTFMtVFAgT0FNIHNvbHV0aW9uIGFu ZCBhbGwgdGhlIGxpYWlzb24gZG9lcyBpcyBwb2ludCBvdXQgdGhhdCBmYWN0Lg0KPg0KPiBGV0lX IHRoaXMgaXNuJ3QgdGhlIGZpcnN0IHRpbWUgYSBncm91cCBvZiBvcGVyYXRvcnMgaGF2ZSBicm91 Z2h0IGEgcHJvcG9zYWwgdG8gSUVURiBvbmx5IHRvIGZpbmQgdGhhdCB0aGUgSUVURiBoYXMgZGVj aWRlZCB0byBkbyBzb21ldGhpbmcgZWxzZSwgYW5kIEknbSBzdXJlIGl0IHdvbid0IGJlIHRoZSBs YXN0Lg0KPg0KPiBCZW4NCj4NCj4gUC5TLiBmb3Igc29tZSByZWFzb24gZW1haWwgY2hhaW5zIHJl bGF0ZWQgdG8gZHJhZnQtYmhoIHJlbWluZCBtZSBvZiB0aGlzIERpbGJlcnQgY2FydG9vbiBodHRw Oi8vd3d3LmRpbGJlcnQuY29tLzIwMTAtMTItMjIvDQo+DQo+DQo+DQo+PiBCZXN0IHJlZ2FyZHMs DQo+Pg0KPj4gICAgICAgICAgICAgICBIYW4gTGkNCj4+DQo+PiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ PiBIYW4gTGksIFBoLkQNCj4+IENoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGUNCj4+IFVu aXQgMiwgMjggWHVhbnd1bWVueGkgQXZlLCBYdWFud3UgRGlzdHJpY3QsIEJlaWppbmcgMTAwMDUz LCBDaGluYQ0KPj4gRmF4OiArODYgMTAgNjM2MDEwODcNCj4+IE1PQklMRTogMTM1MDEwOTMzODUN Cj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCj4+DQo+Pg0KPj4gLS0tIDEx5bm0MeaciDEz5pel77yM5ZGo 5ZubLCBydWlxdWFuLmppbmdAdGllcy5pdHUuaW50PHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ+ ICDlhpnpgZPvvJoNCj4+DQo+Pj4g5Y+R5Lu25Lq6OiBydWlxdWFuLmppbmdAdGllcy5pdHUuaW50 PHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ+DQo+Pj4g5Li76aKYOiBSZTogW21wbHMtdHBdIFtt cGxzXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRw b2FtIFtSZWYwNDMuMDJdDQo+Pj4g5pS25Lu25Lq6OiBqaW5nckB0aWVzLml0dS5jaA0KPj4+IOaK hOmAgTogbXBscy10cEBpZXRmLm9yZw0KPj4+IOaXpeacnzogMjAxMeW5tDHmnIgxM+aXpSzlkajl m5ss5LiL5Y2INDowOQ0KPj4+IFJlc2VuZCB0byBtcGxzLXRwIGxpc3QuDQo+Pj4NCj4+PiBRdW90 aW5nIGppbmdyQHRpZXMuaXR1LmNoOg0KPj4+DQo+Pj4+IEhpIFN0ZXdhcnQgQnJ5YW50LA0KPj4+ Pg0KPj4+PiBJIGRvbuKAmXQgYWdyZWUgd2l0aCB0aGUgY3VycmVudCBMUyB0ZXh0Lg0KPj4+Pg0K Pj4+PiBDaGluYSBUZWxlY29tIHN1cHBvcnQgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBZLjE3MzEN Cj4+PiBiYXNlZCBNUExTLVRQIE9BTSB0b29scw0KPj4+PiBpbg0KPj4+PiB0aGUgSVRVLVQgdG8g bWVldCB0aGUgdXJnZW50IGFuZCBpbmNyZWFzaW5nDQo+Pj4gcmVxdWlyZW1lbnRzIGZvciBQVE4g ZGVwbG95bWVudC4NCj4+Pj4gSXTigJlzIGEgbXVsdGktdmVuZG9yIHN1cHBvcnRlZCwgaW50ZXJv cGVyYWJpbGl0eQ0KPj4+IGNlcnRpZmljYXRlZCBhbmQgZmVhc2libGUNCj4+Pj4gc29sdXRpb24u ICBJdCBoYWQgYmVlbiBzcGVjaWZpZWQgaW4gYm90aCBDQ1NBDQo+Pj4gKENoaW5hIENvbW11bmlj YXRpb25zIFN0YW5kYXJkcw0KPj4+PiBBc3NvY2lhdGlvbikgYW5kIENoaW5hIFRlbGVjb23igJlz IFBUTiBzdGFuZGFyZCBhcyB0aGUNCj4+PiBvbmx5IHN0YW5kYXJkIE9BTQ0KPj4+PiBtZWNoYW5p c20uDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEJlc3QgUmVnYXJkcw0KPj4+Pg0KPj4+PiBKaW5n IFJ1aXF1YW4NCj4+Pj4NCj4+Pj4gQ2hpbmHjgIBUZWxlY29tICBCZWlqaW5nDQo+Pj4gUmVzZWFy Y2jjgIBJbnN0aXR1dGUNCj4+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAtLQ0K Pj4+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4+PiBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10NCj4+PiBPbiBCZWhhbGYgT2YNCj4+Pj4gU3Rld2FydA0KPj4+PiBCcnlhbnQN Cj4+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDEwLCAyMDExIDY6NTcgUE0NCj4+Pj4gVG86IG1w bHNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogW21wbHNdIERyYWZ0OiBSZXNwb25zZSB0byBVcGRh dGVkIGRyYWZ0DQo+Pj4gUmVjb21tZW5kYXRpb24gRy50cG9hbQ0KPj4+PiBbUmVmMDQzLjAyXQ0K Pj4+Pg0KPj4+Pg0KPj4+PiBJIHByb3Bvc2UgdG8gc2VuZCB0aGUgZm9sbG93aW5nIExpYWlzb24g UmVzcG9uc2UgdG8NCj4+PiB0aGUgSVRVLVQgb24gRnJpZGF5DQo+Pj4+IDE0dGggSmFudWFyeSBh bmQgYW0gcG9zdGluZyBpdCB0byB0aGUgTVBMUyBXRyBsaXN0IGZvcg0KPj4+IHJldmlldy4NCj4+ Pj4gPT09PT09PQ0KPj4+Pg0KPj4+PiBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVu ZGF0aW9uIEcudHBvYW0gW1JlZg0KPj4+IDA0My4wMl0NCj4+Pj4gRnJvbTogSUVURiBMaWFpc29u IHRvIElUVS1UIG9uIE1QTFMgc3RicnlhbnRAY2lzY28uY29tDQo+Pj4+IFRvOiB0c2JzZzE1QGl0 dS5pbnQsDQo+Pj4gZ3JlZy5qb25lc0BpdHUuaW50LA0KPj4+IGhpcm9zaGkub3RhQGl0dS5pbnQs DQo+Pj4gSUFCQGlldGYub3JnDQo+Pj4+IENDOiBHcmVnIEpvbmVzLCBzd2FsbG93QGNpc2NvLmNv bSwNCj4+PiBsb2FAcGkubnUsIHBhZkBjaXNjby5jb20NCj4+Pj4gc3RicnlhbnRAY2lzY28uY29t LA0KPj4+IGFkcmlhbi5mYXJyZWxAaHVhd2VpLmNvbSwNCj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+ IHlvaWNoaS5tYWVkYUB0dGMub3IuanAsDQo+Pj4gc3RldmUudHJvd2JyaWRnZUBhbGNhdGVsLWx1 Y2VudC5jb20NCj4+Pg0KPj4+PiBnaGFuaS5hYmJhc0Blcmljc3Nvbi5jb20sDQo+Pj4gaGhlbHZv b3J0QGh1YXdlaS5jb20NCj4+Pg0KPj4+PiBtYWxjb2xtLmJldHRzQHp0ZS5jb20uY24sDQo+Pj4g a2FtLmxhbUBhbGNhdGVsLWx1Y2VudC5jb20NCj4+Pg0KPj4+PiBGb3IgQWN0aW9uDQo+Pj4+DQo+ Pj4+IFRoZSBNUExTIFdvcmtpbmcgR3JvdXAgbm90ZXMgdGhhdCB0aGlzIGRvY3VtZW50DQo+Pj4g Y29udGFpbnMgdGV4dCBkZXNjcmliaW5nDQo+Pj4+IE1QTFMtVFAgT0FNIHByb3RvY29scyBub3Qg ZGVzaWduZWQgYW5kIHN0YW5kYXJkaXplZA0KPj4+IHVzaW5nIHRoZSBJRVRGDQo+Pj4+IFN0YW5k YXJkcyBwcm9jZXNzLiBTcGVjaWZpY2FsbHkgaXQgdXNlcyBtYXRlcmlhbCBmcm9tDQo+Pj4+IGRy YWZ0LWJoaC1tcGxzLXRwLW9hbS15MTczMS0wNi4NCj4+Pj4NCj4+Pj4gV2Ugd2lzaCB0byBkcmF3 IHlvdXIgYXR0ZW50aW9uIHRvIHRoZSBzdGF0dXMgc2VjdGlvbg0KPj4+IG9mDQo+Pj4+IGRyYWZ0 LWJoaC1tcGxzLXRwLW9hbS15MTczMS0wNiB3aGljaCBzdGF0ZXM6DQo+Pj4+DQo+Pj4+ICJJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYQ0KPj4+IG1heGltdW0g b2Ygc2l4IG1vbnRocw0KPj4+PiBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXINCj4+PiBkb2N1bWVudHMgYXQgYW55DQo+Pj4+IHRpbWUuIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcw0KPj4+IHJlZmVyZW5jZSBtYXRl cmlhbA0KPj4+PiBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz cyIuDQo+Pj4+DQo+Pj4+IFBsZWFzZSBhbHNvIG5vdGUgdGhhdCBzaW5jZSB0aGUgZHJhZnQgZmls ZW5hbWUgc3RhcnRzDQo+Pj4gd2l0aCB0aGUgcHJlZml4DQo+Pj4+IHN0cmluZyAiZHJhZnQtYmho IiB0aGlzIGNsZWFybHkgaWRlbnRpZmllcyBpdCB0byB0aGUNCj4+PiByZWFkZXIgYXMgYQ0KPj4+ PiBkb2N1bWVudCBleHByZXNzaW5nIHRoZSBwZXJzb25hbCB0ZWNobmljYWwgdmlld3Mgb2YNCj4+ PiB0aGUgYXV0aG9ycyBhbmQNCj4+Pj4gaGVuY2UgaGVuY2UgYXMgYSBkb2N1bWVudCB0aGF0IHRo YXQgZG9lcyBub3QgaGF2ZSBhbnkNCj4+PiBhY2tub3dsZWRnZWQgbGV2ZWwNCj4+Pj4gb2YgSUVU RiBjb25zZW5zdXMuDQo+Pj4+DQo+Pj4+IFNpbmNlIHRoZSB0ZXh0IG9mIGRyYWZ0IFJlY29tbWVu ZGF0aW9uIGZvciBHLnRwb2FtIGlzDQo+Pj4gYmFzZWQgb24gYW4NCj4+Pj4gTVBMUy1UUCBPQU0g cHJvdG9jb2wgbm90IGRlc2lnbmVkIHdpdGhpbiB0aGUgSUVURg0KPj4+IFN0YW5kYXJkcyBQcm9j ZXNzIHRoaXMNCj4+Pj4gaXMgYSBicmVhY2ggb2YgdGhlIFNHMTUgYWdyZWVtZW50IHdpdGggdGhl IElFVEYgYXMNCj4+PiBwdWJsaXNoZWQgaW4gUmVwb3J0DQo+Pj4+IG9mIHRoZSBmaXJzdCBtZWV0 aW5nIG9mIFdvcmtpbmcgUGFydHkgMy8xNSBUcmFuc3BvcnQNCj4+PiBuZXR3b3JrIHN0cnVjdHVy ZXMNCj4+Pj4gKDIwMDktMjAxMikgKEdlbmV2YSwgMSDigJMgMTIgRGVjZW1iZXIgMjAwOCkgd2hp Y2ggY2FuDQo+Pj4gYmUgZm91bmQgYXQNCj4+Pj4gaHR0cDovL3d3dy5pdHUuaW50L21kL1QwOS1T RzE1LVItMDAwNC9lbg0KPj4+PiBQbGVhc2UgY29uZmlybSB0aGF0IHRoZSBJVFUtVCBpbnRlbmRz IHRvIGNvbnRpbnVlIHdpdGgNCj4+PiB0aGUgam9pbnQgd29yayBvbg0KPj4+PiBNUExTLVRQIGFu ZCB0aGF0IHRoZSBJVFUtVCB3aWxsIGFsaWduIHRoaXMNCj4+PiByZWNvbW1lbmRhdGlvbiB3aXRo IHRoZSBJRVRGDQo+Pj4+IE1QTFMtVFAgT0FNIGRlc2lnbiBiZWZvcmUgYWR2YW5jaW5nIHRoaXMg ZG9jdW1lbnQNCj4+PiB0aHJvdWdoIHRoZSBJVFUtVA0KPj4+PiBwdWJsaWNhdGlvbiBwcm9jZXNz Lg0KPj4+Pg0KPj4+PiBUaGUgTVBMUyBXb3JraW5nIEdyb3VwIHdvdWxkIGFsc28gbGlrZSB0byBk cmF3IHRoZQ0KPj4+IGF0dGVudGlvbiBvZiBJVFUtVA0KPj4+PiBTRzE1IHRvIHRoZSBJRVRGIGNv cHlyaWdodCBydWxlcy4gUGxlYXNlIHNlZQ0KPj4+PiBodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8vYXJjaGl2ZS9JRVRGLVRydXN0LUxpY2Vuc2UtUG9saWN5LQ0KPj4+PiAyMDA5 MTIyOC5odG0NCj4+Pj4gZm9yIGZ1cnRoZXIgZGV0YWlscy4NCj4+Pj4NCj4+Pj4gU2luY2UgdGhp cyBkcmFmdCBSZWNvbW1lbmRhdGlvbiBjb250YWlucyB0ZXh0IGluIHdoaWNoDQo+Pj4gdGhlIElU VS1UIFNHMTUNCj4+Pj4gaGFzIHByb3Bvc2VkIG1ha2luZyBjaGFuZ2VzIHRvIElFVEYgcHJvdG9j b2xzIHdpdGhvdXQNCj4+PiB0aGUgYXBwcm92YWwgb2YNCj4+Pj4gdGhlIElFVEYsIHRoZSBNUExT IFdvcmtpbmcgR3JvdXAgaGF2ZSByZWZlcnJlZCB0aGlzDQo+Pj4gbGlhaXNvbiB0byB0aGUgSUFC DQo+Pj4+IGZvciB0aGVpciBjb25zaWRlcmF0aW9uLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiA9 PT09PT09PT0NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPj4+IG1wbHMtdHBAaWV0Zi5vcmcN Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4+Pg0K Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gbXBscy10cCBtYWlsaW5nIGxpc3QNCj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0K PiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQoNCi0tIA0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCg0K aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9p bmRleC5odG1sDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From RCosta@ptinovacao.pt Thu Jan 13 10:21:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A166D3A6A6D for ; Thu, 13 Jan 2011 10:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0upzMEbVxTX for ; Thu, 13 Jan 2011 10:21:43 -0800 (PST) Received: from owa.ptinovacao.pt (mail6.ptinovacao.pt [194.65.138.99]) by core3.amsl.com (Postfix) with ESMTP id A9AC53A67B8 for ; Thu, 13 Jan 2011 10:21:42 -0800 (PST) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Thu, 13 Jan 2011 18:24:03 +0000 From: Rui Costa To: "stbryant@cisco.com" , "mpls@ietf.org" Date: Thu, 13 Jan 2011 18:24:01 +0000 Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: AcuwtRh2oOJUOeyiSd+HsECFZEc4JACBIY9w Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201DA53C3B8E0@INOAVREX11.ptin.corpPT.com> References: <4D2AE5E0.90703@cisco.com> In-Reply-To: <4D2AE5E0.90703@cisco.com> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:21:44 -0000 Hello,=09 This LS doesn't recognize service providers' inputs, where the inclusion of= Y.1731 based OAM tools within the MPLS-TP OAM toolkit is grounded, so I do= n't agree with it.=09 I think both approaches (this one as well as the one documented in a set of= MPLS WG drafts) should proceed. This one meets a need that has been expres= sed in the IETF. =20 Regards,=09 Rui=09 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: segunda-feira, 10 de Janeiro de 2011 10:57 To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Re= f 043.02] I propose to send the following Liaison Response to the ITU-T on Friday=20 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing=20 MPLS-TP OAM protocols not designed and standardized using the IETF=20 Standards process. Specifically it uses material from=20 draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of=20 draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix=20 string "draft-bhh" this clearly identifies it to the reader as a=20 document expressing the personal technical views of the authors and=20 hence hence as a document that that does not have any acknowledged level=20 of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an=20 MPLS-TP OAM protocol not designed within the IETF Standards Process this=20 is a breach of the SG15 agreement with the IETF as published in Report=20 of the first meeting of Working Party 3/15 Transport network structures=20 (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at=20 http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on=20 MPLS-TP and that the ITU-T will align this recommendation with the IETF=20 MPLS-TP OAM design before advancing this document through the ITU-T=20 publication process. The MPLS Working Group would also like to draw the attention of ITU-T=20 SG15 to the IETF copyright rules. Please see=20 http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2009= 1228.htm=20 for further details. Since this draft Recommendation contains text in which the ITU-T SG15=20 has proposed making changes to IETF protocols without the approval of=20 the IETF, the MPLS Working Group have referred this liaison to the IAB=20 for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nurit.sprecher@nsn.com Thu Jan 13 10:23:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF48D28C143 for ; Thu, 13 Jan 2011 10:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i41EZbUenTOo for ; Thu, 13 Jan 2011 10:23:00 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D566C3A6A53 for ; Thu, 13 Jan 2011 10:22:59 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0DIPJaj014490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jan 2011 19:25:19 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0DIPEbq009679; Thu, 13 Jan 2011 19:25:18 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 19:24:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBB34F.20291622" Date: Thu, 13 Jan 2011 19:24:28 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264033057F6@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: AcuwtRRfrWRIYWIyQSuhsgVsQwpebQCelrnwAAcRnFA= References: <4D2AE5E0.90703@cisco.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext D'Alessandro Alessandro Gerardo" , , X-OriginalArrivalTime: 13 Jan 2011 18:24:33.0480 (UTC) FILETIME=[203C4480:01CBB34F] Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:23:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB34F.20291622 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBB34F.20291622" ------_=_NextPart_002_01CBB34F.20291622 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alessandro, Please see inline. Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext D'Alessandro Alessandro Gerardo Sent: Thursday, January 13, 2011 6:21 PM To: stbryant@cisco.com; mpls@ietf.org Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam [Ref 043.02] =20 Dear Stewart, all, I do not agree on the proposed Liaison text for the reasons explained = inline below. =20 Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 =20 =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Stewart Bryant Sent: luned=EC 10 gennaio 2011 11.57 To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam = [Ref 043.02] =20 I propose to send the following Liaison Response to the ITU-T on Friday=20 14th January and am posting it to the MPLS WG list for review. =20 =3D=3D=3D=3D=3D=3D=3D =20 Response to Updated draft Recommendation G.tpoam [Ref 043.02] =20 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com =20 For Action =20 The MPLS Working Group notes that this document contains text describing = MPLS-TP OAM protocols not designed and standardized using the IETF=20 Standards process. Specifically it uses material from=20 draft-bhh-mpls-tp-oam-y1731-06. [dalessandro] In my understanding ITU-T G.tpoam is based on ITU-T = Y.1731. the meeting report from Berlin say that it is based on = draft-bhh version 6.=20 =20 We wish to draw your attention to the status section of=20 draft-bhh-mpls-tp-oam-y1731-06 which states: =20 "Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress". =20 Please also note that since the draft filename starts with the prefix=20 string "draft-bhh" this clearly identifies it to the reader as a=20 document expressing the personal technical views of the authors and=20 hence hence as a document that that does not have any acknowledged level = of IETF consensus. [dalessandro] I would take the opportunity this email give me to invite = IETF community to review draft-bhh (and the other related = contributions)that are fueling a lot of discussions inside IETF. =20 Since the text of draft Recommendation for G.tpoam is based on an=20 MPLS-TP OAM protocol not designed within the IETF Standards Process this = is a breach of the SG15 agreement with the IETF as published in Report=20 of the first meeting of Working Party 3/15 Transport network structures=20 (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at=20 http://www.itu.int/md/T09-SG15-R-0004/en [dalessandro] In my understanding ITU-T documents are based on = contributions and consensus. G.tpoam does not preclude inclusion of = material agreed inside IETF therefore I do not see it as a breach of the = SG15 agreement with the IETF. For that reason I do not agree sending = this Liaison. although this is not in the context of the liaison, I cannot = find any justification to allow for two solutions! But the liaison is = not focusing on this but on the procedure and the agreement with the = ITU-T on the development of the MPLS-TP protocols.=20 =20 Please confirm that the ITU-T intends to continue with the joint work on = MPLS-TP and that the ITU-T will align this recommendation with the IETF=20 MPLS-TP OAM design before advancing this document through the ITU-T=20 publication process. [dalessandro] Is it appropriate for IETF to do that statement? I never = heard statements in ITU-T meetings and I never read ITU-T contributions = asking to break the joint work with IETF.=20 The action of the ITU-T when developing a solution outside of = the IETF was contrary to the agreement with the IETF (from December = 2008) and we need to be sure that the ITU-T intends to continue with the = collaboration. We hope so. We think the collaboration is very beneficial = to the whole Industry.=20 =20 =20 The MPLS Working Group would also like to draw the attention of ITU-T=20 SG15 to the IETF copyright rules. Please see=20 http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20= 091228.htm=20 for further details. =20 Since this draft Recommendation contains text in which the ITU-T SG15=20 has proposed making changes to IETF protocols without the approval of=20 the IETF, the MPLS Working Group have referred this liaison to the IAB=20 for their consideration. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.=20 =20 ------_=_NextPart_002_01CBB34F.20291622 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Alessandro,

Please see inline.

Best regards,

Nurit

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext D'Alessandro Alessandro Gerardo
Sent: Thursday, = January 13, 2011 6:21 PM
To: stbryant@cisco.com; = mpls@ietf.org
Subject: Re: [mpls] Draft: Response to Updated = draft Recommendation G.tpoam [Ref = 043.02]

 

Dear = Stewart, all,

I do not agree on = the proposed Liaison text for the reasons explained inline = below.

 

Best regards,

Alessandro

---------------------------------------------------------------= ---

Telecom = Italia

Alessandro D'Alessandro

Transport & OPB = Innovation

Via Reiss Romoli, 274 - 10148 Torino

phone:  +39 011 228 = 5887

mobile: +39 335 766 = 9607

fax: +39 06 418 639 = 07

 

 

-----Original Message-----
From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Stewart Bryant
Sent: luned=EC 10 gennaio 2011 11.57
To: = mpls@ietf.org
Subject: [mpls] Draft: Response to Updated draft = Recommendation G.tpoam [Ref 043.02]

 

I = propose to send the following Liaison Response to the ITU-T on Friday =

14th January and am posting it to = the MPLS WG list for review.

 

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

 

Response to Updated draft Recommendation G.tpoam = [Ref 043.02]

 

From: = IETF Liaison to ITU-T on MPLS stbryant@cisco.com

To: tsbsg15@itu.int, greg.jones@itu.int, = hiroshi.ota@itu.int, IAB@ietf.org

CC: Greg Jones, swallow@cisco.com, loa@pi.nu, = paf@cisco.com

stbryant@cisco.com, = adrian.farrel@huawei.com, mpls@ietf.org

yoichi.maeda@ttc.or.jp, = steve.trowbridge@alcatel-lucent.com

ghani.abbas@ericsson.com, = hhelvoort@huawei.com

malcolm.betts@zte.com.cn, = kam.lam@alcatel-lucent.com

 

For = Action

 

The MPLS Working Group notes that this document = contains text describing

MPLS-TP = OAM protocols not designed and standardized using the IETF =

Standards process. Specifically = it uses material from

draft-bhh-mpls-tp-oam-y1731-06.

[dalessandro] In my = understanding ITU-T G.tpoam is based on ITU-T = Y.1731.

<Nurit>=A0 the meeting report from Berlin say that it is based = on draft-bhh version 6.

 

We = wish to draw your attention to the status section of

draft-bhh-mpls-tp-oam-y1731-06 which = states:

 

"Internet-Drafts are draft documents valid for = a maximum of six months

and may = be updated, replaced, or obsoleted by other documents at any =

time. It is inappropriate to use = Internet-Drafts as reference material

or to cite them other than as "work in = progress".

 

Please = also note that since the draft filename starts with the prefix =

string "draft-bhh" this = clearly identifies it to the reader as a

document expressing the personal technical views of = the authors and

hence hence as a = document that that does not have any acknowledged level =

of IETF = consensus.

[dalessandro] I would take the opportunity this = email give me to invite IETF community to review draft-bhh (and the = other related contributions)that are fueling a lot of discussions inside = IETF.

 

Since the text of draft Recommendation for G.tpoam = is based on an

MPLS-TP OAM = protocol not designed within the IETF Standards Process this =

is a breach of the SG15 agreement = with the IETF as published in Report

of the first meeting of Working Party 3/15 = Transport network structures

(2009-2012) (Geneva, 1 – 12 December 2008) = which can be found at

http://www.itu.int/md/T09-SG15-R-0004/en<= /p>

[dalessandro] In my = understanding ITU-T documents are based on contributions and consensus. = G.tpoam does not preclude inclusion of material agreed inside IETF = therefore I do not see it as a breach of the SG15 agreement with the = IETF. For that reason I do not agree sending this = Liaison.

<Nurit> although this is not in the context of the liaison, I = cannot find any justification to allow for two solutions! But the = liaison is not focusing on this but on the procedure and the agreement = with the ITU-T on the development of the MPLS-TP protocols. =

 

Please confirm that the ITU-T intends to continue = with the joint work on

MPLS-TP = and that the ITU-T will align this recommendation with the IETF =

MPLS-TP OAM design before = advancing this document through the ITU-T

publication process.

[dalessandro] Is it = appropriate for IETF to do that statement? I never heard statements in = ITU-T meetings and I never read ITU-T contributions asking to break the = joint work with IETF.

<Nurit> The action of the ITU-T when developing a solution = outside of the IETF was contrary to the agreement with the IETF (from = December 2008) and we need to be sure that the ITU-T intends to continue = with the collaboration. We hope so. We think the collaboration is very = beneficial to the whole Industry.

 

 

The = MPLS Working Group would also like to draw the attention of ITU-T =

SG15 to the IETF copyright rules. = Please see

http://trustee.ietf.org/license-info/archive/IETF-Tr= ust-License-Policy-20091228.htm

for further details.

 

Since = this draft Recommendation contains text in which the ITU-T SG15 =

has proposed making changes to = IETF protocols without the approval of

the IETF, the MPLS Working Group have referred this = liaison to the IAB

for their = consideration.

 

 

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

_______________________________________________=

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. =

= This e-mail and any attachments=  is = confidential and may contain privileged information intended for the = addressee(s) only. Dissemination, copying, printing or use by anybody = else is unauthorised. If you are not the intended recipient, please = delete this message and any attachments and advise the sender by return = e-mail, Thanks.= =

= 3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 = necessario.=

 

------_=_NextPart_002_01CBB34F.20291622-- ------_=_NextPart_001_01CBB34F.20291622 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= ------_=_NextPart_001_01CBB34F.20291622-- From stbryant@cisco.com Thu Jan 13 10:41:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5873A6A58 for ; Thu, 13 Jan 2011 10:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.222 X-Spam-Level: X-Spam-Status: No, score=-110.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rZfNH1ffxC8 for ; Thu, 13 Jan 2011 10:41:49 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4D5703A684B for ; Thu, 13 Jan 2011 10:41:49 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL7WLk1AZnwM/2dsb2JhbACECKBDc6RUglEOAYd1jXSBIYM3dASLEA Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2011 18:44:12 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0DIiBUn006216; Thu, 13 Jan 2011 18:44:11 GMT Received: from dhcp-gpk02-vlan300-64-103-65-54.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0DIi9810203; Thu, 13 Jan 2011 18:44:10 GMT Message-ID: <4D2F47F9.8040701@cisco.com> Date: Thu, 13 Jan 2011 18:44:09 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Sinicrope References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:41:51 -0000 Does anyone disagree with the statement that David makes? Stewart On 13/01/2011 17:09, David Sinicrope wrote: > It seems that reference and use of draft-bhh is in violation of the ITU-T external cooperation agreement "Referencing A.5 Qualified Organizations" text found at > http://www.itu.int/en/ITU-T/extcoop/Pages/sdo.aspx under the Referencing IETF Documents link. > In particular clause 10 of this document states: (See 2nd sentence.) > > "10 Other: If a study group decides to make the reference to an IETF RFC, the reference should always be made by RFC number (and not by other designations such as STD, BCP, etc.). References should not be made to documents referred to as "Internet Drafts" or to IETF RFCs categorized as Historic or Experimental. Normative references must only be made to IETF RFCs that are Standards Track or to Informational RFCs that have IETF consensus." > > Is this not correct? If correct, shouldn't this also be pointed out in the liaison? > Dave > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Thursday, January 13, 2011 11:27 AM > To: mpls@ietf.org > Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] > > Exactly Ben. > > The Liaison is list of statements of relevant facts, and none of the contra points dispute those facts. > > Stewart > > On 13/01/2011 15:41, Ben Niven-Jenkins wrote: >> Larry, >> >> On 13 Jan 2011, at 14:55, Larry wrote: >> >>> Hi, >>> >>> I don't think it is proper to send the LS to ITU-T because the text doesn't reflect the requirement from providers. >>> Apparently, draft-bhh based OAM is the most mature solution currently. It has been proved by more than 200,000 applications and is supported by a lot of operators and vendors. >>> >> That may or may not be true, but either way it is irrelevant to the liaison. >> >> ITU liaised G.tpoam to IETF. The liaison response Stewart has drafted points out that G.tpoam uses technology (draft-bhh) that is not endorsed by IETF consensus and points to some risks of doing so, including breach of a prior ITU-IETF agreement on how to progress MPLS-TP development. >> >> Everything in the liaison is fact. Whether draft-bhh is good/bad/ugly, deployed, supported by operators, etc. is irrelevant, it is not endorsed by IETF as a MPLS-TP OAM solution and all the liaison does is point out that fact. >> >> FWIW this isn't the first time a group of operators have brought a proposal to IETF only to find that the IETF has decided to do something else, and I'm sure it won't be the last. >> >> Ben >> >> P.S. for some reason email chains related to draft-bhh remind me of >> this Dilbert cartoon http://www.dilbert.com/2010-12-22/ >> >> >> >>> Best regards, >>> >>> Han Li >>> >>> ********************************************************************* >>> **** >>> Han Li, Ph.D >>> China Mobile Research Institute >>> Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China >>> Fax: +86 10 63601087 >>> MOBILE: 13501093385 >>> ********************************************************************* >>> **** >>> >>> >>> --- 11å¹´1月13日，周四, ruiquan.jing@ties.itu.int >>> 写é“： >>> >>>> å‘件人: ruiquan.jing@ties.itu.int >>>> 主题: Re: [mpls-tp] [mpls] Draft: Response to Updated draft >>>> Recommendation G.tpoam [Ref043.02] >>>> 收件人: jingr@ties.itu.ch >>>> 抄é€: mpls-tp@ietf.org >>>> 日期: 2011å¹´1月13æ—¥,周四,下åˆ4:09 >>>> Resend to mpls-tp list. >>>> >>>> Quoting jingr@ties.itu.ch: >>>> >>>>> Hi Stewart Bryant, >>>>> >>>>> I don’t agree with the current LS text. >>>>> >>>>> China Telecom support the standardization of Y.1731 >>>> based MPLS-TP OAM tools >>>>> in >>>>> the ITU-T to meet the urgent and increasing >>>> requirements for PTN deployment. >>>>> It’s a multi-vendor supported, interoperability >>>> certificated and feasible >>>>> solution. It had been specified in both CCSA >>>> (China Communications Standards >>>>> Association) and China Telecom’s PTN standard as the >>>> only standard OAM >>>>> mechanism. >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Jing Ruiquan >>>>> >>>>> China　Telecom Beijing >>>> Research　Institute >>>> -------------------------------------------------------------------- >>>> ---------- >>>> -- >>>>> From: mpls-bounces@ietf.org >>>> [mailto:mpls-bounces@ietf.org] >>>> On Behalf Of >>>>> Stewart >>>>> Bryant >>>>> Sent: Monday, January 10, 2011 6:57 PM >>>>> To: mpls@ietf.org >>>>> Subject: [mpls] Draft: Response to Updated draft >>>> Recommendation G.tpoam >>>>> [Ref043.02] >>>>> >>>>> >>>>> I propose to send the following Liaison Response to >>>> the ITU-T on Friday >>>>> 14th January and am posting it to the MPLS WG list for >>>> review. >>>>> ======= >>>>> >>>>> Response to Updated draft Recommendation G.tpoam [Ref >>>> 043.02] >>>>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >>>>> To: tsbsg15@itu.int, >>>> greg.jones@itu.int, >>>> hiroshi.ota@itu.int, >>>> IAB@ietf.org >>>>> CC: Greg Jones, swallow@cisco.com, >>>> loa@pi.nu, paf@cisco.com >>>>> stbryant@cisco.com, >>>> adrian.farrel@huawei.com, >>>> mpls@ietf.org >>>>> yoichi.maeda@ttc.or.jp, >>>> steve.trowbridge@alcatel-lucent.com >>>> >>>>> ghani.abbas@ericsson.com, >>>> hhelvoort@huawei.com >>>> >>>>> malcolm.betts@zte.com.cn, >>>> kam.lam@alcatel-lucent.com >>>> >>>>> For Action >>>>> >>>>> The MPLS Working Group notes that this document >>>> contains text describing >>>>> MPLS-TP OAM protocols not designed and standardized >>>> using the IETF >>>>> Standards process. Specifically it uses material from >>>>> draft-bhh-mpls-tp-oam-y1731-06. >>>>> >>>>> We wish to draw your attention to the status section >>>> of >>>>> draft-bhh-mpls-tp-oam-y1731-06 which states: >>>>> >>>>> "Internet-Drafts are draft documents valid for a >>>> maximum of six months >>>>> and may be updated, replaced, or obsoleted by other >>>> documents at any >>>>> time. It is inappropriate to use Internet-Drafts as >>>> reference material >>>>> or to cite them other than as "work in progress". >>>>> >>>>> Please also note that since the draft filename starts >>>> with the prefix >>>>> string "draft-bhh" this clearly identifies it to the >>>> reader as a >>>>> document expressing the personal technical views of >>>> the authors and >>>>> hence hence as a document that that does not have any >>>> acknowledged level >>>>> of IETF consensus. >>>>> >>>>> Since the text of draft Recommendation for G.tpoam is >>>> based on an >>>>> MPLS-TP OAM protocol not designed within the IETF >>>> Standards Process this >>>>> is a breach of the SG15 agreement with the IETF as >>>> published in Report >>>>> of the first meeting of Working Party 3/15 Transport >>>> network structures >>>>> (2009-2012) (Geneva, 1 – 12 December 2008) which can >>>> be found at >>>>> http://www.itu.int/md/T09-SG15-R-0004/en >>>>> Please confirm that the ITU-T intends to continue with >>>> the joint work on >>>>> MPLS-TP and that the ITU-T will align this >>>> recommendation with the IETF >>>>> MPLS-TP OAM design before advancing this document >>>> through the ITU-T >>>>> publication process. >>>>> >>>>> The MPLS Working Group would also like to draw the >>>> attention of ITU-T >>>>> SG15 to the IETF copyright rules. Please see >>>>> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Pol >>>>> icy- >>>>> 20091228.htm >>>>> for further details. >>>>> >>>>> Since this draft Recommendation contains text in which >>>> the ITU-T SG15 >>>>> has proposed making changes to IETF protocols without >>>> the approval of >>>>> the IETF, the MPLS Working Group have referred this >>>> liaison to the IAB >>>>> for their consideration. >>>>> >>>>> >>>>> >>>>> ========= >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jdrake@juniper.net Thu Jan 13 11:32:32 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9D928C10B for ; Thu, 13 Jan 2011 11:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05R3YzICkuqR for ; Thu, 13 Jan 2011 11:32:31 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 0553A28C107 for ; Thu, 13 Jan 2011 11:32:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTS9T3fZN7NWu2SXkLDiqngGmIuQ2AQcQ@postini.com; Thu, 13 Jan 2011 11:34:54 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 13 Jan 2011 11:31:38 -0800 From: John E Drake To: "stbryant@cisco.com" , "mpls@ietf.org" Date: Thu, 13 Jan 2011 11:33:35 -0800 Thread-Topic: [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] Thread-Index: AcuwtJr6ZjHAM8X0R7mxBusQKWEqDQCpB1aQ Message-ID: <5E893DB832F57341992548CDBB33316398C6F3B9E6@EMBX01-HQ.jnpr.net> References: <4D2AE56A.3060200@cisco.com> In-Reply-To: <4D2AE56A.3060200@cisco.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 Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 19:32:32 -0000 Support. =20 Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Monday, January 10, 2011 2:55 AM > To: mpls@ietf.org > Subject: [mpls] Draft: Response to Updated draft Recommendation G.8121 > [Ref 042.02] >=20 >=20 > I propose to send the following Liaison Response to the ITU-T on Friday > 14th January and am posting it to the MPLS WG list for review. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Response to Updated draft Recommendation G.8121 [Ref 042.02] >=20 > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, > IAB@ietf.org > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com > stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org > yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com, hhelvoort@huawei.com > malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com >=20 > For Action >=20 > Unfortunately ITU-T document WD19r2 was not attached to this liaison, > and thus the MPLS Working Group is unable to comment on its content at > this time. >=20 > It is stated in the liaison that the modifications to this draft > Recommendation are based on draft-bhh-mpls-tp-oam-y1731-06. Please may > we draw your attention to the status section of > draft-bhh-mpls-tp-oam-y1731-06 which states >=20 > "Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference material > or to cite them other than as "work in progress". >=20 > Please also note that since the draft filename starts with the prefix > string "draft-bhh" this clearly identifies it to the reader as a > document expressing the personal technical views of the authors and > hence hence as a document that that does not have any acknowledged > level > of IETF consensus. >=20 > If this draft Recommendation for G.8121 is based on an MPLS-TP OAM > protocol not designed within the IETF Standards Process, the MPLS > Working Group believe that this would be in breach of the SG15 > agreement > with the IETF as published in Report of the first meeting of Working > Party 3/15 Transport network structures (2009-2012) (Geneva, 1 - 12 > December 2008) which can be found at > http://www.itu.int/md/T09-SG15-R-0004/en >=20 > The MPLS Working Group would also like to draw the attention of ITU-T > SG15 to the IETF copyright rules. Please see > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- > 20091228.htm > for further details. >=20 > We have referred this liaison to the IAB for their consideration. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Thu Jan 13 14:16:34 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E62C3A6BF9; Thu, 13 Jan 2011 14:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pU+5JzmK9tJ; Thu, 13 Jan 2011 14:16:33 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B20223A6BF8; Thu, 13 Jan 2011 14:16:32 -0800 (PST) Received: by ewy8 with SMTP id 8so1215638ewy.31 for ; Thu, 13 Jan 2011 14:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yZEKO+tVFbDsWHA//ZOUrEkkgW2k7cOHVex4FJkeZNU=; b=q+XFgDgIq6zLWUJhA9dHlWlDL8g/CNrPeL/0So6ST624JeJNDX/NnMTrNF2999AVo2 MtlysCa6jygr7Qjftzd44YA62FbiVg/8WmzGRJOOf1qJIa3u6rNQ6q3zaUgr7VkxTrwa lZoLstrJC2khNRIc0s42mW278N/9MB/+jZ7Zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=fbpgkRLTzA7iCAkk/rCV6l3GKMbJvIBYSYP5bYiNE7WPHHKmJpv0aTd93ZyGnkydVr JLW2z6TlmCfvrhftbJ1CrX60MorTZuDIl5tiCai3VLkeX7wf7ubSafq/1R92ZeKg4liy MB20IfvePm+LQlpjQuiLpdce6rIDwrwrOmP78= Received: by 10.213.23.7 with SMTP id p7mr147613ebb.79.1294957135203; Thu, 13 Jan 2011 14:18:55 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id t5sm407305eeh.20.2011.01.13.14.18.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 14:18:54 -0800 (PST) Message-ID: <4D2F7A4C.80304@gmail.com> Date: Thu, 13 Jan 2011 23:18:52 +0100 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: mpls@ietf.org, "mpls-tp@ietf.org" References: <4D2AE56A.3060200@cisco.com> In-Reply-To: <4D2AE56A.3060200@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:16:34 -0000 Hello Stewart, You wrote: > I propose to send the following Liaison Response to the ITU-T on Friday > 14th January and am posting it to the MPLS WG list for review. I do not support sending the liaison as proposed. We should restrict it to the first paragraph noting that the file that should be reviewed is missing and ask for sending the missing file so it can be reviewed by the WG. The remainder of the text is based on assumptions and not on facts. Regards, Huub. > ========= > > Response to Updated draft Recommendation G.8121 [Ref 042.02] > > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com > stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org > yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com, hhelvoort@huawei.com > malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com > > For Action > > Unfortunately ITU-T document WD19r2 was not attached to this liaison, > and thus the MPLS Working Group is unable to comment on its content at > this time. > > It is stated in the liaison that the modifications to this draft > Recommendation are based on draft-bhh-mpls-tp-oam-y1731-06. Please may > we draw your attention to the status section of > draft-bhh-mpls-tp-oam-y1731-06 which states > > "Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference material > or to cite them other than as "work in progress". > > Please also note that since the draft filename starts with the prefix > string "draft-bhh" this clearly identifies it to the reader as a > document expressing the personal technical views of the authors and > hence hence as a document that that does not have any acknowledged level > of IETF consensus. > > If this draft Recommendation for G.8121 is based on an MPLS-TP OAM > protocol not designed within the IETF Standards Process, the MPLS > Working Group believe that this would be in breach of the SG15 agreement > with the IETF as published in Report of the first meeting of Working > Party 3/15 Transport network structures (2009-2012) (Geneva, 1 – 12 > December 2008) which can be found at > http://www.itu.int/md/T09-SG15-R-0004/en > > The MPLS Working Group would also like to draw the attention of ITU-T > SG15 to the IETF copyright rules. Please see > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm > for further details. > > We have referred this liaison to the IAB for their consideration. > > > =========== > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 我爱外点一七三一 From jdrake@juniper.net Thu Jan 13 14:26:58 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EAE3A6C02; Thu, 13 Jan 2011 14:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqdrrlxe0bug; Thu, 13 Jan 2011 14:26:57 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id B55FF3A6BFE; Thu, 13 Jan 2011 14:26:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTS98wKKtDwwS3neUDs93rx1f3xjCqZrr@postini.com; Thu, 13 Jan 2011 14:29:20 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 13 Jan 2011 14:25:01 -0800 From: John E Drake To: Huub van Helvoort , "mpls@ietf.org" , "mpls-tp@ietf.org" Date: Thu, 13 Jan 2011 14:26:57 -0800 Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] Thread-Index: Acuzb61fIYYPAbIKTHyDcIrIhN6cKQAARNSw Message-ID: <5E893DB832F57341992548CDBB33316398C6F3BCCC@EMBX01-HQ.jnpr.net> References: <4D2AE56A.3060200@cisco.com> <4D2F7A4C.80304@gmail.com> In-Reply-To: <4D2F7A4C.80304@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:26:58 -0000 SW5saW5lDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIEh1dWIgdmFuIEhlbHZvb3J0DQo+IFNl bnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDExIDI6MTkgUE0NCj4gVG86IG1wbHNAaWV0Zi5v cmc7IG1wbHMtdHBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBbbXBsc10gRHJh ZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQNCj4gUmVjb21tZW5kYXRpb24gRy44MTIxIFtS ZWYgMDQyLjAyXQ0KPiANCj4gSGVsbG8gU3Rld2FydCwNCj4gDQo+IFlvdSB3cm90ZToNCj4gDQo+ ID4gSSBwcm9wb3NlIHRvIHNlbmQgdGhlIGZvbGxvd2luZyBMaWFpc29uIFJlc3BvbnNlIHRvIHRo ZSBJVFUtVCBvbg0KPiBGcmlkYXkNCj4gPiAxNHRoIEphbnVhcnkgYW5kIGFtIHBvc3RpbmcgaXQg dG8gdGhlIE1QTFMgV0cgbGlzdCBmb3IgcmV2aWV3Lg0KPiANCj4gSSBkbyBub3Qgc3VwcG9ydCBz ZW5kaW5nIHRoZSBsaWFpc29uIGFzIHByb3Bvc2VkLg0KPiANCj4gV2Ugc2hvdWxkIHJlc3RyaWN0 IGl0IHRvIHRoZSBmaXJzdCBwYXJhZ3JhcGggbm90aW5nIHRoYXQgdGhlIGZpbGUNCj4gdGhhdCBz aG91bGQgYmUgcmV2aWV3ZWQgaXMgbWlzc2luZyBhbmQgYXNrIGZvciBzZW5kaW5nIHRoZSBtaXNz aW5nDQo+IGZpbGUgc28gaXQgY2FuIGJlIHJldmlld2VkIGJ5IHRoZSBXRy4NCj4gDQo+IFRoZSBy ZW1haW5kZXIgb2YgdGhlIHRleHQgaXMgYmFzZWQgb24gYXNzdW1wdGlvbnMgYW5kIG5vdCBvbiBm YWN0cy4NCg0KSkQ6ICBUaGUgYWJvdmUgc3RhdGVtZW50IGlzIGFuIGFzc2VydGlvbiBub3Qgc3Vw cG9ydGVkIGJ5IGZhY3RzLg0KDQo+IA0KPiBSZWdhcmRzLCBIdXViLg0KPiANCj4gDQo= From huubatwork@gmail.com Thu Jan 13 14:30:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A7728B56A; Thu, 13 Jan 2011 14:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwEIj9JVIFTg; Thu, 13 Jan 2011 14:30:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id AC61B3A6C06; Thu, 13 Jan 2011 14:30:26 -0800 (PST) Received: by eyd10 with SMTP id 10so1225929eyd.31 for ; Thu, 13 Jan 2011 14:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IkTaytcFV7wMpkVwDzK+eGDIfYeJ36km1DIcJy/thaw=; b=vLs6nLCQSBiOBYgQVZjJcDSM+1Nky6GVzMdi1yxAMykyGa/eWSmhfm+XMbYDAgpHyH N132oADYO2ky0ZTJu3/iZOHBf1FempvOCJG7Aov8HKlXmlZPpbtvols+ZMn69XV1GOrV dF64TJYVP42ZlqiUS709nMHv+Ze5VrBsvO4IU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=I+NbHAjal+961Vgd/OOPnqgxykSWxiPiSr3mU+37e02cOuNIGuZmN8u7aefHJTDVSv ZGHVHABrBxkMsWU+Oexj5SPaQfC5DbTpi5EgEIy9oKDtJr3hP/4k1eZiHk4PA7t5qCMU eoQHHpEPeGM1yf0EJkBakY+XTiR3nWLLvJIFo= Received: by 10.213.4.198 with SMTP id 6mr984583ebs.74.1294957969688; Thu, 13 Jan 2011 14:32:49 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id x54sm415404eeh.23.2011.01.13.14.32.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 14:32:48 -0800 (PST) Message-ID: <4D2F7D8E.9040505@gmail.com> Date: Thu, 13 Jan 2011 23:32:46 +0100 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: mpls@ietf.org, "mpls-tp@ietf.org" References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se> <4D2F47F9.8040701@cisco.com> In-Reply-To: <4D2F47F9.8040701@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:30:29 -0000 Hello Stewart, You asked: > Does anyone disagree with the statement that David makes? I disagree with this statement in relation to this liaison. The draft recommendation G.tpoam that was sent for review does not contain a reference to draft-bhh at all. Also the statements about validity and copyright are irrelevant. Regards, Huub. ============== > On 13/01/2011 17:09, David Sinicrope wrote: >> It seems that reference and use of draft-bhh is in violation of the >> ITU-T external cooperation agreement "Referencing A.5 Qualified >> Organizations" text found at >> http://www.itu.int/en/ITU-T/extcoop/Pages/sdo.aspx under the >> Referencing IETF Documents link. >> In particular clause 10 of this document states: (See 2nd sentence.) >> >> "10 Other: If a study group decides to make the reference to an IETF >> RFC, the reference should always be made by RFC number (and not by >> other designations such as STD, BCP, etc.). References should not be >> made to documents referred to as "Internet Drafts" or to IETF RFCs >> categorized as Historic or Experimental. Normative references must >> only be made to IETF RFCs that are Standards Track or to Informational >> RFCs that have IETF consensus." >> >> Is this not correct? If correct, shouldn't this also be pointed out in >> the liaison? >> Dave >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of Stewart Bryant >> Sent: Thursday, January 13, 2011 11:27 AM >> To: mpls@ietf.org >> Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft >> Recommendation G.tpoam [Ref043.02] >> >> Exactly Ben. >> >> The Liaison is list of statements of relevant facts, and none of the >> contra points dispute those facts. >> >> Stewart >> >> On 13/01/2011 15:41, Ben Niven-Jenkins wrote: >>> Larry, >>> >>> On 13 Jan 2011, at 14:55, Larry wrote: >>> >>>> Hi, >>>> >>>> I don't think it is proper to send the LS to ITU-T because the text >>>> doesn't reflect the requirement from providers. >>>> Apparently, draft-bhh based OAM is the most mature solution >>>> currently. It has been proved by more than 200,000 applications and >>>> is supported by a lot of operators and vendors. >>>> >>> That may or may not be true, but either way it is irrelevant to the >>> liaison. >>> >>> ITU liaised G.tpoam to IETF. The liaison response Stewart has drafted >>> points out that G.tpoam uses technology (draft-bhh) that is not >>> endorsed by IETF consensus and points to some risks of doing so, >>> including breach of a prior ITU-IETF agreement on how to progress >>> MPLS-TP development. >>> >>> Everything in the liaison is fact. Whether draft-bhh is >>> good/bad/ugly, deployed, supported by operators, etc. is irrelevant, >>> it is not endorsed by IETF as a MPLS-TP OAM solution and all the >>> liaison does is point out that fact. >>> >>> FWIW this isn't the first time a group of operators have brought a >>> proposal to IETF only to find that the IETF has decided to do >>> something else, and I'm sure it won't be the last. >>> >>> Ben >>> >>> P.S. for some reason email chains related to draft-bhh remind me of >>> this Dilbert cartoon http://www.dilbert.com/2010-12-22/ >>> >>> >>> >>>> Best regards, >>>> >>>> Han Li >>>> >>>> ********************************************************************* >>>> **** >>>> Han Li, Ph.D >>>> China Mobile Research Institute >>>> Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China >>>> Fax: +86 10 63601087 >>>> MOBILE: 13501093385 >>>> ********************************************************************* >>>> **** >>>> >>>> >>>> --- 11å¹´1月13日，周四, >>>> ruiquan.jing@ties.itu.int >>>> 写é“： >>>> >>>>> å‘件人: ruiquan.jing@ties.itu.int >>>>> 主题: Re: [mpls-tp] [mpls] Draft: Response to Updated draft >>>>> Recommendation G.tpoam [Ref043.02] >>>>> 收件人: jingr@ties.itu.ch >>>>> 抄é€: mpls-tp@ietf.org >>>>> 日期: 2011å¹´1月13æ—¥,周四,下åˆ4:09 >>>>> Resend to mpls-tp list. >>>>> >>>>> Quoting jingr@ties.itu.ch: >>>>> >>>>>> Hi Stewart Bryant, >>>>>> >>>>>> I don’t agree with the current LS text. >>>>>> >>>>>> China Telecom support the standardization of Y.1731 >>>>> based MPLS-TP OAM tools >>>>>> in >>>>>> the ITU-T to meet the urgent and increasing >>>>> requirements for PTN deployment. >>>>>> It’s a multi-vendor supported, interoperability >>>>> certificated and feasible >>>>>> solution. It had been specified in both CCSA >>>>> (China Communications Standards >>>>>> Association) and China Telecom’s PTN standard as the >>>>> only standard OAM >>>>>> mechanism. >>>>>> >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Jing Ruiquan >>>>>> >>>>>> China　Telecom Beijing >>>>> Research　Institute >>>>> -------------------------------------------------------------------- >>>>> ---------- >>>>> -- >>>>>> From: mpls-bounces@ietf.org >>>>> [mailto:mpls-bounces@ietf.org] >>>>> On Behalf Of >>>>>> Stewart >>>>>> Bryant >>>>>> Sent: Monday, January 10, 2011 6:57 PM >>>>>> To: mpls@ietf.org >>>>>> Subject: [mpls] Draft: Response to Updated draft >>>>> Recommendation G.tpoam >>>>>> [Ref043.02] >>>>>> >>>>>> >>>>>> I propose to send the following Liaison Response to >>>>> the ITU-T on Friday >>>>>> 14th January and am posting it to the MPLS WG list for >>>>> review. >>>>>> ======= >>>>>> >>>>>> Response to Updated draft Recommendation G.tpoam [Ref >>>>> 043.02] >>>>>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >>>>>> To: tsbsg15@itu.int, >>>>> greg.jones@itu.int, >>>>> hiroshi.ota@itu.int, >>>>> IAB@ietf.org >>>>>> CC: Greg Jones, swallow@cisco.com, >>>>> loa@pi.nu, paf@cisco.com >>>>>> stbryant@cisco.com, >>>>> adrian.farrel@huawei.com, >>>>> mpls@ietf.org >>>>>> yoichi.maeda@ttc.or.jp, >>>>> steve.trowbridge@alcatel-lucent.com >>>>> >>>>>> ghani.abbas@ericsson.com, >>>>> hhelvoort@huawei.com >>>>> >>>>>> malcolm.betts@zte.com.cn, >>>>> kam.lam@alcatel-lucent.com >>>>> >>>>>> For Action >>>>>> >>>>>> The MPLS Working Group notes that this document >>>>> contains text describing >>>>>> MPLS-TP OAM protocols not designed and standardized >>>>> using the IETF >>>>>> Standards process. Specifically it uses material from >>>>>> draft-bhh-mpls-tp-oam-y1731-06. >>>>>> >>>>>> We wish to draw your attention to the status section >>>>> of >>>>>> draft-bhh-mpls-tp-oam-y1731-06 which states: >>>>>> >>>>>> "Internet-Drafts are draft documents valid for a >>>>> maximum of six months >>>>>> and may be updated, replaced, or obsoleted by other >>>>> documents at any >>>>>> time. It is inappropriate to use Internet-Drafts as >>>>> reference material >>>>>> or to cite them other than as "work in progress". >>>>>> >>>>>> Please also note that since the draft filename starts >>>>> with the prefix >>>>>> string "draft-bhh" this clearly identifies it to the >>>>> reader as a >>>>>> document expressing the personal technical views of >>>>> the authors and >>>>>> hence hence as a document that that does not have any >>>>> acknowledged level >>>>>> of IETF consensus. >>>>>> >>>>>> Since the text of draft Recommendation for G.tpoam is >>>>> based on an >>>>>> MPLS-TP OAM protocol not designed within the IETF >>>>> Standards Process this >>>>>> is a breach of the SG15 agreement with the IETF as >>>>> published in Report >>>>>> of the first meeting of Working Party 3/15 Transport >>>>> network structures >>>>>> (2009-2012) (Geneva, 1 – 12 December 2008) which can >>>>> be found at >>>>>> http://www.itu.int/md/T09-SG15-R-0004/en >>>>>> Please confirm that the ITU-T intends to continue with >>>>> the joint work on >>>>>> MPLS-TP and that the ITU-T will align this >>>>> recommendation with the IETF >>>>>> MPLS-TP OAM design before advancing this document >>>>> through the ITU-T >>>>>> publication process. >>>>>> >>>>>> The MPLS Working Group would also like to draw the >>>>> attention of ITU-T >>>>>> SG15 to the IETF copyright rules. Please see >>>>>> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Pol >>>>>> icy- >>>>>> 20091228.htm >>>>>> for further details. >>>>>> >>>>>> Since this draft Recommendation contains text in which >>>>> the ITU-T SG15 >>>>>> has proposed making changes to IETF protocols without >>>>> the approval of >>>>>> the IETF, the MPLS Working Group have referred this >>>>> liaison to the IAB >>>>>> for their consideration. >>>>>> >>>>>> >>>>>> >>>>>> ========= >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> >>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > -- ***************************************************************** 我爱外点一七三一 From nurit.sprecher@nsn.com Thu Jan 13 14:42:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2902128B56A; Thu, 13 Jan 2011 14:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=1.945, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOtdtozws7ZS; Thu, 13 Jan 2011 14:42:30 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5F7DE28B23E; Thu, 13 Jan 2011 14:42:29 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0DMimki022729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jan 2011 23:44:48 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0DMilOs029332; Thu, 13 Jan 2011 23:44:48 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 23:44:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 13 Jan 2011 23:44:20 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640332E310@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D2F7A4C.80304@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] Thread-Index: Acuzb+Nb8KRr+mUjSkyFe5VeJgEzywAARscg References: <4D2AE56A.3060200@cisco.com> <4D2F7A4C.80304@gmail.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Huub van Helvoort" , , X-OriginalArrivalTime: 13 Jan 2011 22:44:20.0962 (UTC) FILETIME=[6B194420:01CBB373] Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:42:31 -0000 SHV1YiwNCkRvIHlvdSBzYXkgdGhhdCB0aGUgcGFyYWdyYXBoIHNheWluZyAiSXQgaXMgc3RhdGVk IGluIHRoZSBsaWFpc29uIHRoYXQgdGhlIG1vZGlmaWNhdGlvbnMgdG8gdGhpcyBkcmFmdCBSZWNv bW1lbmRhdGlvbiBhcmUgYmFzZWQgb24gZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2IiBp cyBhbiBhc3N1bXB0aW9uPw0KSXQgd2FzIHN0YXRlZCBpbiB0aGUgbGlhaXNvbiBhcyB3ZWxsIGFz IGluIHRoZSBCZXJsaW4gbWVldGluZyByZXBvcnQuDQpJdCBpcyBhIGZhY3QhDQpJIHRoaW5rIHRo YXQgYWxsIHRoZSByZXN0IG9mIHRoZSBwYXJhZ3JhcGhzIGFyZSBmYWN0cyBhcyB3ZWxsIQ0KQmVz dCByZWdhcmRzLA0KTnVyaXQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1w bHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGV4dCBIdXViIHZhbiBIZWx2b29ydA0KU2VudDogRnJpZGF5LCBKYW51YXJ5 IDE0LCAyMDExIDEyOjE5IEFNDQpUbzogbXBsc0BpZXRmLm9yZzsgbXBscy10cEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFttcGxzLXRwXSBbbXBsc10gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQg ZHJhZnQgUmVjb21tZW5kYXRpb24gRy44MTIxIFtSZWYgMDQyLjAyXQ0KDQpIZWxsbyBTdGV3YXJ0 LA0KDQpZb3Ugd3JvdGU6DQoNCj4gSSBwcm9wb3NlIHRvIHNlbmQgdGhlIGZvbGxvd2luZyBMaWFp c29uIFJlc3BvbnNlIHRvIHRoZSBJVFUtVCBvbiBGcmlkYXkNCj4gMTR0aCBKYW51YXJ5IGFuZCBh bSBwb3N0aW5nIGl0IHRvIHRoZSBNUExTIFdHIGxpc3QgZm9yIHJldmlldy4NCg0KSSBkbyBub3Qg c3VwcG9ydCBzZW5kaW5nIHRoZSBsaWFpc29uIGFzIHByb3Bvc2VkLg0KDQpXZSBzaG91bGQgcmVz dHJpY3QgaXQgdG8gdGhlIGZpcnN0IHBhcmFncmFwaCBub3RpbmcgdGhhdCB0aGUgZmlsZQ0KdGhh dCBzaG91bGQgYmUgcmV2aWV3ZWQgaXMgbWlzc2luZyBhbmQgYXNrIGZvciBzZW5kaW5nIHRoZSBt aXNzaW5nDQpmaWxlIHNvIGl0IGNhbiBiZSByZXZpZXdlZCBieSB0aGUgV0cuDQoNClRoZSByZW1h aW5kZXIgb2YgdGhlIHRleHQgaXMgYmFzZWQgb24gYXNzdW1wdGlvbnMgYW5kIG5vdCBvbiBmYWN0 cy4NCg0KUmVnYXJkcywgSHV1Yi4NCg0KDQo+ID09PT09PT09PQ0KPg0KPiBSZXNwb25zZSB0byBV cGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcuODEyMSBbUmVmIDA0Mi4wMl0NCj4NCj4gRnJv bTogSUVURiBMaWFpc29uIHRvIElUVS1UIG9uIE1QTFMgc3RicnlhbnRAY2lzY28uY29tDQo+IFRv OiB0c2JzZzE1QGl0dS5pbnQsIGdyZWcuam9uZXNAaXR1LmludCwgaGlyb3NoaS5vdGFAaXR1Lmlu dCwgSUFCQGlldGYub3JnDQo+IENDOiBHcmVnIEpvbmVzLCBzd2FsbG93QGNpc2NvLmNvbSwgbG9h QHBpLm51LCBwYWZAY2lzY28uY29tDQo+IHN0YnJ5YW50QGNpc2NvLmNvbSwgYWRyaWFuLmZhcnJl bEBodWF3ZWkuY29tLCBtcGxzQGlldGYub3JnDQo+IHlvaWNoaS5tYWVkYUB0dGMub3IuanAsIHN0 ZXZlLnRyb3dicmlkZ2VAYWxjYXRlbC1sdWNlbnQuY29tDQo+IGdoYW5pLmFiYmFzQGVyaWNzc29u LmNvbSwgaGhlbHZvb3J0QGh1YXdlaS5jb20NCj4gbWFsY29sbS5iZXR0c0B6dGUuY29tLmNuLCBr YW0ubGFtQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPg0KPiBGb3IgQWN0aW9uDQo+DQo+IFVuZm9ydHVu YXRlbHkgSVRVLVQgZG9jdW1lbnQgV0QxOXIyIHdhcyBub3QgYXR0YWNoZWQgdG8gdGhpcyBsaWFp c29uLA0KPiBhbmQgdGh1cyB0aGUgTVBMUyBXb3JraW5nIEdyb3VwIGlzIHVuYWJsZSB0byBjb21t ZW50IG9uIGl0cyBjb250ZW50IGF0DQo+IHRoaXMgdGltZS4NCj4NCj4gSXQgaXMgc3RhdGVkIGlu IHRoZSBsaWFpc29uIHRoYXQgdGhlIG1vZGlmaWNhdGlvbnMgdG8gdGhpcyBkcmFmdA0KPiBSZWNv bW1lbmRhdGlvbiBhcmUgYmFzZWQgb24gZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2LiBQ bGVhc2UgbWF5DQo+IHdlIGRyYXcgeW91ciBhdHRlbnRpb24gdG8gdGhlIHN0YXR1cyBzZWN0aW9u IG9mDQo+IGRyYWZ0LWJoaC1tcGxzLXRwLW9hbS15MTczMS0wNiB3aGljaCBzdGF0ZXMNCj4NCj4g IkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocw0KPiBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0 ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KPiB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGVyaWFsDQo+IG9yIHRvIGNp dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzIi4NCj4NCj4gUGxlYXNlIGFs c28gbm90ZSB0aGF0IHNpbmNlIHRoZSBkcmFmdCBmaWxlbmFtZSBzdGFydHMgd2l0aCB0aGUgcHJl Zml4DQo+IHN0cmluZyAiZHJhZnQtYmhoIiB0aGlzIGNsZWFybHkgaWRlbnRpZmllcyBpdCB0byB0 aGUgcmVhZGVyIGFzIGENCj4gZG9jdW1lbnQgZXhwcmVzc2luZyB0aGUgcGVyc29uYWwgdGVjaG5p Y2FsIHZpZXdzIG9mIHRoZSBhdXRob3JzIGFuZA0KPiBoZW5jZSBoZW5jZSBhcyBhIGRvY3VtZW50 IHRoYXQgdGhhdCBkb2VzIG5vdCBoYXZlIGFueSBhY2tub3dsZWRnZWQgbGV2ZWwNCj4gb2YgSUVU RiBjb25zZW5zdXMuDQo+DQo+IElmIHRoaXMgZHJhZnQgUmVjb21tZW5kYXRpb24gZm9yIEcuODEy MSBpcyBiYXNlZCBvbiBhbiBNUExTLVRQIE9BTQ0KPiBwcm90b2NvbCBub3QgZGVzaWduZWQgd2l0 aGluIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCB0aGUgTVBMUw0KPiBXb3JraW5nIEdyb3Vw IGJlbGlldmUgdGhhdCB0aGlzIHdvdWxkIGJlIGluIGJyZWFjaCBvZiB0aGUgU0cxNSBhZ3JlZW1l bnQNCj4gd2l0aCB0aGUgSUVURiBhcyBwdWJsaXNoZWQgaW4gUmVwb3J0IG9mIHRoZSBmaXJzdCBt ZWV0aW5nIG9mIFdvcmtpbmcNCj4gUGFydHkgMy8xNSBUcmFuc3BvcnQgbmV0d29yayBzdHJ1Y3R1 cmVzICgyMDA5LTIwMTIpIChHZW5ldmEsIDEg4oCTIDEyDQo+IERlY2VtYmVyIDIwMDgpIHdoaWNo IGNhbiBiZSBmb3VuZCBhdA0KPiBodHRwOi8vd3d3Lml0dS5pbnQvbWQvVDA5LVNHMTUtUi0wMDA0 L2VuDQo+DQo+IFRoZSBNUExTIFdvcmtpbmcgR3JvdXAgd291bGQgYWxzbyBsaWtlIHRvIGRyYXcg dGhlIGF0dGVudGlvbiBvZiBJVFUtVA0KPiBTRzE1IHRvIHRoZSBJRVRGIGNvcHlyaWdodCBydWxl cy4gUGxlYXNlIHNlZQ0KPiBodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8vYXJj aGl2ZS9JRVRGLVRydXN0LUxpY2Vuc2UtUG9saWN5LTIwMDkxMjI4Lmh0bQ0KPiBmb3IgZnVydGhl ciBkZXRhaWxzLg0KPg0KPiBXZSBoYXZlIHJlZmVycmVkIHRoaXMgbGlhaXNvbiB0byB0aGUgSUFC IGZvciB0aGVpciBjb25zaWRlcmF0aW9uLg0KPg0KPg0KPiA9PT09PT09PT09PQ0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcg bGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KDQoNCi0tIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgICAgICAgICAgICAgICAgICAgICAgICAg 5oiR54ix5aSW54K55LiA5LiD5LiJ5LiADQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0K From eosborne@cisco.com Thu Jan 13 14:49:13 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D18F28C0DD; Thu, 13 Jan 2011 14:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAhvMgejN9GZ; Thu, 13 Jan 2011 14:49:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 87ED728B23E; Thu, 13 Jan 2011 14:49:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFcRL02tJXG+/2dsb2JhbACECJ9hZHOkHIpVjWCBIYM3dASEaIlQ Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 13 Jan 2011 22:51:34 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0DMpYps013548; Thu, 13 Jan 2011 22:51:34 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 16:51:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 13 Jan 2011 16:51:32 -0600 Message-ID: In-Reply-To: <4D2F7D8E.9040505@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuzcdYOACJqkL8SQ1KnmKq/hzcCPgAAFzOA References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se><4D2F47F9.8040701@cisco.com> <4D2F7D8E.9040505@gmail.com> From: "Eric Osborne (eosborne)" To: "Huub van Helvoort" , , X-OriginalArrivalTime: 13 Jan 2011 22:51:34.0250 (UTC) FILETIME=[6D5BC4A0:01CBB374] Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:49:13 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbXBscy10cC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YgSHV1YiB2YW4gSGVsdm9vcnQNCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTMsIDIwMTEg NTozMyBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZzsgbXBscy10cEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdA0K PiBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYwNDMuMDJdDQo+IA0KPiBIZWxsbyBTdGV3YXJ0 LA0KPiANCj4gWW91IGFza2VkOg0KPiANCj4gPiBEb2VzIGFueW9uZSBkaXNhZ3JlZSB3aXRoIHRo ZSBzdGF0ZW1lbnQgdGhhdCBEYXZpZCBtYWtlcz8NCj4gDQo+IEkgZGlzYWdyZWUgd2l0aCB0aGlz IHN0YXRlbWVudCBpbiByZWxhdGlvbiB0byB0aGlzIGxpYWlzb24uDQo+IA0KPiBUaGUgZHJhZnQg cmVjb21tZW5kYXRpb24gRy50cG9hbSB0aGF0IHdhcyBzZW50IGZvciByZXZpZXcgZG9lcyBub3Qg Y29udGFpbg0KPiBhIHJlZmVyZW5jZSB0byBkcmFmdC1iaGggYXQgYWxsLg0KDQpUaGUgbGlhc29u IGlzIGhlcmU6IFtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vOTgzL10NCmFu ZCBpdCByZWZlcmVuY2VzICJMUzIzMyAtIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50 cG9hbSBbUmVmIDA0My4wMV0gLSBwZGYgYm9keSIgW2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jdW1lbnRzL0xJQUlTT04vZmlsZTExNTEucGRmXQ0Kd2hpY2ggc2F5cw0KDQotLS0tDQpB dCB0aGUgQmVybGluIGludGVyaW0gbWVldGluZyBvbiBNUExTLVRQIGZ1cnRoZXIgd29yayB3YXMg dW5kZXJ0YWtlbiBvbiB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIA0KT0FNIFJlY29tbWVuZGF0aW9u IEcudHBvYW0uICBUaGlzIHZlcnNpb24gd2FzIGRldmVsb3BlZCB1c2luZyBhbGwgb2YgdGhlIHJl bGV2YW50IGlucHV0IA0KZG9jdW1lbnRzIHRvIHRoZSBtZWV0aW5nIGFuZCBpcyBiYXNlZCBvbiBk cmFmdC1iaGgtbXBscy10cC1vYW0teTE3MzEtMDYuICBXZSBpbnZpdGUgeW91ciANCmNvbW1lbnRz IG9uIHRoaXMgZG9jdW1lbnQNCi0tLS0NCg0KV2hpbGUgeW91IGFyZSB0ZWNobmljYWxseSBjb3Jy ZWN0IHRoYXQgRy50cG9hbSBkb2VzIG5vdCBpdHNlbGYgY29udGFpbiBhIHJlZmVyZW5jZSB0byBk cmFmdC1iaGgsIGhvdyBhcmUgd2UgdG8gaW50ZXJwcmV0IHRoZSBsaWFzb24gc3RhdGVtZW50IHdo aWNoIGNsYWltcyBhIGNsZWFyIGxpbmVhZ2UgYmV0d2VlbiBkcmFmdC1iaGggYW5kIEcudHBvYW0/ DQoNCj4gQWxzbyB0aGUgc3RhdGVtZW50cyBhYm91dCB2YWxpZGl0eSBhbmQgY29weXJpZ2h0IGFy ZSBpcnJlbGV2YW50Lg0KPiANCg0KQ2FuIHdlIGFzc3VtZSB0aGF0IHlvdSBhZ3JlZSB0aGV5IGFy ZSBjb3JyZWN0LCByZWdhcmRsZXNzIG9mIHJlbGV2YW5jZT8NCg0KDQoNCmVyaWMNCg0KDQo+IFJl Z2FyZHMsIEh1dWIuDQo+IA0KPiANCj4gPT09PT09PT09PT09PT0NCj4gPiBPbiAxMy8wMS8yMDEx IDE3OjA5LCBEYXZpZCBTaW5pY3JvcGUgd3JvdGU6DQo+ID4+IEl0IHNlZW1zIHRoYXQgcmVmZXJl bmNlIGFuZCB1c2Ugb2YgZHJhZnQtYmhoIGlzIGluIHZpb2xhdGlvbiBvZiB0aGUNCj4gPj4gSVRV LVQgZXh0ZXJuYWwgY29vcGVyYXRpb24gYWdyZWVtZW50ICJSZWZlcmVuY2luZyBBLjUgUXVhbGlm aWVkDQo+ID4+IE9yZ2FuaXphdGlvbnMiIHRleHQgZm91bmQgYXQNCj4gPj4gaHR0cDovL3d3dy5p dHUuaW50L2VuL0lUVS1UL2V4dGNvb3AvUGFnZXMvc2RvLmFzcHggdW5kZXIgdGhlDQo+ID4+IFJl ZmVyZW5jaW5nIElFVEYgRG9jdW1lbnRzIGxpbmsuDQo+ID4+IEluIHBhcnRpY3VsYXIgY2xhdXNl IDEwIG9mIHRoaXMgZG9jdW1lbnQgc3RhdGVzOiAoU2VlIDJuZCBzZW50ZW5jZS4pDQo+ID4+DQo+ ID4+ICIxMCBPdGhlcjogSWYgYSBzdHVkeSBncm91cCBkZWNpZGVzIHRvIG1ha2UgdGhlIHJlZmVy ZW5jZSB0byBhbiBJRVRGDQo+ID4+IFJGQywgdGhlIHJlZmVyZW5jZSBzaG91bGQgYWx3YXlzIGJl IG1hZGUgYnkgUkZDIG51bWJlciAoYW5kIG5vdCBieQ0KPiA+PiBvdGhlciBkZXNpZ25hdGlvbnMg c3VjaCBhcyBTVEQsIEJDUCwgZXRjLikuIFJlZmVyZW5jZXMgc2hvdWxkIG5vdCBiZQ0KPiA+PiBt YWRlIHRvIGRvY3VtZW50cyByZWZlcnJlZCB0byBhcyAiSW50ZXJuZXQgRHJhZnRzIiBvciB0byBJ RVRGIFJGQ3MNCj4gPj4gY2F0ZWdvcml6ZWQgYXMgSGlzdG9yaWMgb3IgRXhwZXJpbWVudGFsLiBO b3JtYXRpdmUgcmVmZXJlbmNlcyBtdXN0DQo+ID4+IG9ubHkgYmUgbWFkZSB0byBJRVRGIFJGQ3Mg dGhhdCBhcmUgU3RhbmRhcmRzIFRyYWNrIG9yIHRvDQo+ID4+IEluZm9ybWF0aW9uYWwgUkZDcyB0 aGF0IGhhdmUgSUVURiBjb25zZW5zdXMuIg0KPiA+Pg0KPiA+PiBJcyB0aGlzIG5vdCBjb3JyZWN0 PyBJZiBjb3JyZWN0LCBzaG91bGRuJ3QgdGhpcyBhbHNvIGJlIHBvaW50ZWQgb3V0DQo+ID4+IGlu IHRoZSBsaWFpc29uPw0KPiA+PiBEYXZlDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4+IE9mIFN0ZXdhcnQgQnJ5YW50DQo+ID4+IFNl bnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDExIDExOjI3IEFNDQo+ID4+IFRvOiBtcGxzQGll dGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gW21wbHMtdHBdIERyYWZ0OiBSZXNwb25z ZSB0byBVcGRhdGVkIGRyYWZ0DQo+ID4+IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZjA0My4w Ml0NCj4gPj4NCj4gPj4gRXhhY3RseSBCZW4uDQo+ID4+DQo+ID4+IFRoZSBMaWFpc29uIGlzIGxp c3Qgb2Ygc3RhdGVtZW50cyBvZiByZWxldmFudCBmYWN0cywgYW5kIG5vbmUgb2YgdGhlDQo+ID4+ IGNvbnRyYSBwb2ludHMgZGlzcHV0ZSB0aG9zZSBmYWN0cy4NCj4gPj4NCj4gPj4gU3Rld2FydA0K PiA+Pg0KPiA+PiBPbiAxMy8wMS8yMDExIDE1OjQxLCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZToN Cj4gPj4+IExhcnJ5LA0KPiA+Pj4NCj4gPj4+IE9uIDEzIEphbiAyMDExLCBhdCAxNDo1NSwgTGFy cnkgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+IEhpLA0KPiA+Pj4+DQo+ID4+Pj4gSSBkb24ndCB0aGlu ayBpdCBpcyBwcm9wZXIgdG8gc2VuZCB0aGUgTFMgdG8gSVRVLVQgYmVjYXVzZSB0aGUgdGV4dA0K PiA+Pj4+IGRvZXNuJ3QgcmVmbGVjdCB0aGUgcmVxdWlyZW1lbnQgZnJvbSBwcm92aWRlcnMuDQo+ ID4+Pj4gQXBwYXJlbnRseSwgZHJhZnQtYmhoIGJhc2VkIE9BTSBpcyB0aGUgbW9zdCBtYXR1cmUg c29sdXRpb24NCj4gPj4+PiBjdXJyZW50bHkuIEl0IGhhcyBiZWVuIHByb3ZlZCBieSBtb3JlIHRo YW4gMjAwLDAwMCBhcHBsaWNhdGlvbnMgYW5kDQo+ID4+Pj4gaXMgc3VwcG9ydGVkIGJ5IGEgbG90 IG9mIG9wZXJhdG9ycyBhbmQgdmVuZG9ycy4NCj4gPj4+Pg0KPiA+Pj4gVGhhdCBtYXkgb3IgbWF5 IG5vdCBiZSB0cnVlLCBidXQgZWl0aGVyIHdheSBpdCBpcyBpcnJlbGV2YW50IHRvIHRoZQ0KPiA+ Pj4gbGlhaXNvbi4NCj4gPj4+DQo+ID4+PiBJVFUgbGlhaXNlZCBHLnRwb2FtIHRvIElFVEYuIFRo ZSBsaWFpc29uIHJlc3BvbnNlIFN0ZXdhcnQgaGFzDQo+ID4+PiBkcmFmdGVkIHBvaW50cyBvdXQg dGhhdCBHLnRwb2FtIHVzZXMgdGVjaG5vbG9neSAoZHJhZnQtYmhoKSB0aGF0IGlzDQo+ID4+PiBu b3QgZW5kb3JzZWQgYnkgSUVURiBjb25zZW5zdXMgYW5kIHBvaW50cyB0byBzb21lIHJpc2tzIG9m IGRvaW5nIHNvLA0KPiA+Pj4gaW5jbHVkaW5nIGJyZWFjaCBvZiBhIHByaW9yIElUVS1JRVRGIGFn cmVlbWVudCBvbiBob3cgdG8gcHJvZ3Jlc3MNCj4gPj4+IE1QTFMtVFAgZGV2ZWxvcG1lbnQuDQo+ ID4+Pg0KPiA+Pj4gRXZlcnl0aGluZyBpbiB0aGUgbGlhaXNvbiBpcyBmYWN0LiBXaGV0aGVyIGRy YWZ0LWJoaCBpcw0KPiA+Pj4gZ29vZC9iYWQvdWdseSwgZGVwbG95ZWQsIHN1cHBvcnRlZCBieSBv cGVyYXRvcnMsIGV0Yy4gaXMgaXJyZWxldmFudCwNCj4gPj4+IGl0IGlzIG5vdCBlbmRvcnNlZCBi eSBJRVRGIGFzIGEgTVBMUy1UUCBPQU0gc29sdXRpb24gYW5kIGFsbCB0aGUNCj4gPj4+IGxpYWlz b24gZG9lcyBpcyBwb2ludCBvdXQgdGhhdCBmYWN0Lg0KPiA+Pj4NCj4gPj4+IEZXSVcgdGhpcyBp c24ndCB0aGUgZmlyc3QgdGltZSBhIGdyb3VwIG9mIG9wZXJhdG9ycyBoYXZlIGJyb3VnaHQgYQ0K PiA+Pj4gcHJvcG9zYWwgdG8gSUVURiBvbmx5IHRvIGZpbmQgdGhhdCB0aGUgSUVURiBoYXMgZGVj aWRlZCB0byBkbw0KPiA+Pj4gc29tZXRoaW5nIGVsc2UsIGFuZCBJJ20gc3VyZSBpdCB3b24ndCBi ZSB0aGUgbGFzdC4NCj4gPj4+DQo+ID4+PiBCZW4NCj4gPj4+DQo+ID4+PiBQLlMuIGZvciBzb21l IHJlYXNvbiBlbWFpbCBjaGFpbnMgcmVsYXRlZCB0byBkcmFmdC1iaGggcmVtaW5kIG1lIG9mDQo+ ID4+PiB0aGlzIERpbGJlcnQgY2FydG9vbiBodHRwOi8vd3d3LmRpbGJlcnQuY29tLzIwMTAtMTIt MjIvDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+DQo+ ID4+Pj4gSGFuIExpDQo+ID4+Pj4NCj4gPj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+Pj4gKioNCj4gPj4+ PiAqKioqDQo+ID4+Pj4gSGFuIExpLCBQaC5EDQo+ID4+Pj4gQ2hpbmEgTW9iaWxlIFJlc2VhcmNo IEluc3RpdHV0ZQ0KPiA+Pj4+IFVuaXQgMiwgMjggWHVhbnd1bWVueGkgQXZlLCBYdWFud3UgRGlz dHJpY3QsIEJlaWppbmcgMTAwMDUzLCBDaGluYQ0KPiA+Pj4+IEZheDogKzg2IDEwIDYzNjAxMDg3 DQo+ID4+Pj4gTU9CSUxFOiAxMzUwMTA5MzM4NQ0KPiA+Pj4+ICoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4+PiAq Kg0KPiA+Pj4+ICoqKioNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tIDEx5bm0MeaciDEz5pel 77yM5ZGo5ZubLA0KPiA+Pj4+IHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ8cnVpcXVhbi5qaW5n QHRpZXMuaXR1LmludD4NCj4gPj4+PiDlhpnpgZPvvJoNCj4gPj4+Pg0KPiA+Pj4+PiDlj5Hku7bk uro6IHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ8cnVpcXVhbi5qaW5nQHRpZXMuaXR1LmludD4N Cj4gPj4+Pj4g5Li76aKYOiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVzcG9uc2UgdG8g VXBkYXRlZCBkcmFmdA0KPiA+Pj4+PiBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYwNDMuMDJd DQo+ID4+Pj4+IOaUtuS7tuS6ujogamluZ3JAdGllcy5pdHUuY2gNCj4gPj4+Pj4g5oqE6YCBOiBt cGxzLXRwQGlldGYub3JnDQo+ID4+Pj4+IOaXpeacnzogMjAxMeW5tDHmnIgxM+aXpSzlkajlm5ss 5LiL5Y2INDowOQ0KPiA+Pj4+PiBSZXNlbmQgdG8gbXBscy10cCBsaXN0Lg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBRdW90aW5nIGppbmdyQHRpZXMuaXR1LmNoOg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gSGkgU3Rl d2FydCBCcnlhbnQsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBkb27igJl0IGFncmVlIHdpdGggdGhl IGN1cnJlbnQgTFMgdGV4dC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBDaGluYSBUZWxlY29tIHN1cHBv cnQgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBZLjE3MzENCj4gPj4+Pj4gYmFzZWQgTVBMUy1UUCBP QU0gdG9vbHMNCj4gPj4+Pj4+IGluDQo+ID4+Pj4+PiB0aGUgSVRVLVQgdG8gbWVldCB0aGUgdXJn ZW50IGFuZCBpbmNyZWFzaW5nDQo+ID4+Pj4+IHJlcXVpcmVtZW50cyBmb3IgUFROIGRlcGxveW1l bnQuDQo+ID4+Pj4+PiBJdOKAmXMgYSBtdWx0aS12ZW5kb3Igc3VwcG9ydGVkLCBpbnRlcm9wZXJh YmlsaXR5DQo+ID4+Pj4+IGNlcnRpZmljYXRlZCBhbmQgZmVhc2libGUNCj4gPj4+Pj4+IHNvbHV0 aW9uLiBJdCBoYWQgYmVlbiBzcGVjaWZpZWQgaW4gYm90aCBDQ1NBDQo+ID4+Pj4+IChDaGluYSBD b21tdW5pY2F0aW9ucyBTdGFuZGFyZHMNCj4gPj4+Pj4+IEFzc29jaWF0aW9uKSBhbmQgQ2hpbmEg VGVsZWNvbeKAmXMgUFROIHN0YW5kYXJkIGFzIHRoZQ0KPiA+Pj4+PiBvbmx5IHN0YW5kYXJkIE9B TQ0KPiA+Pj4+Pj4gbWVjaGFuaXNtLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSmluZyBSdWlxdWFuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gQ2hpbmHjgIBUZWxlY29tIEJlaWppbmcNCj4gPj4+Pj4gUmVzZWFyY2jj gIBJbnN0aXR1dGUNCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+IC0tDQo+ID4+Pj4+IC0tLS0t LS0tLS0NCj4gPj4+Pj4gLS0NCj4gPj4+Pj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0K PiA+Pj4+PiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCj4gPj4+Pj4gT24gQmVoYWxm IE9mDQo+ID4+Pj4+PiBTdGV3YXJ0DQo+ID4+Pj4+PiBCcnlhbnQNCj4gPj4+Pj4+IFNlbnQ6IE1v bmRheSwgSmFudWFyeSAxMCwgMjAxMSA2OjU3IFBNDQo+ID4+Pj4+PiBUbzogbXBsc0BpZXRmLm9y Zw0KPiA+Pj4+Pj4gU3ViamVjdDogW21wbHNdIERyYWZ0OiBSZXNwb25zZSB0byBVcGRhdGVkIGRy YWZ0DQo+ID4+Pj4+IFJlY29tbWVuZGF0aW9uIEcudHBvYW0NCj4gPj4+Pj4+IFtSZWYwNDMuMDJd DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgcHJvcG9zZSB0byBzZW5kIHRoZSBmb2xs b3dpbmcgTGlhaXNvbiBSZXNwb25zZSB0bw0KPiA+Pj4+PiB0aGUgSVRVLVQgb24gRnJpZGF5DQo+ ID4+Pj4+PiAxNHRoIEphbnVhcnkgYW5kIGFtIHBvc3RpbmcgaXQgdG8gdGhlIE1QTFMgV0cgbGlz dCBmb3INCj4gPj4+Pj4gcmV2aWV3Lg0KPiA+Pj4+Pj4gPT09PT09PQ0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVm DQo+ID4+Pj4+IDA0My4wMl0NCj4gPj4+Pj4+IEZyb206IElFVEYgTGlhaXNvbiB0byBJVFUtVCBv biBNUExTIHN0YnJ5YW50QGNpc2NvLmNvbQ0KPiA+Pj4+Pj4gVG86IHRzYnNnMTVAaXR1LmludCwN Cj4gPj4+Pj4gZ3JlZy5qb25lc0BpdHUuaW50LA0KPiA+Pj4+PiBoaXJvc2hpLm90YUBpdHUuaW50 LA0KPiA+Pj4+PiBJQUJAaWV0Zi5vcmcNCj4gPj4+Pj4+IENDOiBHcmVnIEpvbmVzLCBzd2FsbG93 QGNpc2NvLmNvbSwNCj4gPj4+Pj4gbG9hQHBpLm51LCBwYWZAY2lzY28uY29tDQo+ID4+Pj4+PiBz dGJyeWFudEBjaXNjby5jb20sDQo+ID4+Pj4+IGFkcmlhbi5mYXJyZWxAaHVhd2VpLmNvbSwNCj4g Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4+Pj4geW9pY2hpLm1hZWRhQHR0Yy5vci5qcCwNCj4g Pj4+Pj4gc3RldmUudHJvd2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb20NCj4gPj4+Pj4NCj4gPj4+ Pj4+IGdoYW5pLmFiYmFzQGVyaWNzc29uLmNvbSwNCj4gPj4+Pj4gaGhlbHZvb3J0QGh1YXdlaS5j b20NCj4gPj4+Pj4NCj4gPj4+Pj4+IG1hbGNvbG0uYmV0dHNAenRlLmNvbS5jbiwNCj4gPj4+Pj4g a2FtLmxhbUBhbGNhdGVsLWx1Y2VudC5jb20NCj4gPj4+Pj4NCj4gPj4+Pj4+IEZvciBBY3Rpb24N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGUgTVBMUyBXb3JraW5nIEdyb3VwIG5vdGVzIHRoYXQgdGhp cyBkb2N1bWVudA0KPiA+Pj4+PiBjb250YWlucyB0ZXh0IGRlc2NyaWJpbmcNCj4gPj4+Pj4+IE1Q TFMtVFAgT0FNIHByb3RvY29scyBub3QgZGVzaWduZWQgYW5kIHN0YW5kYXJkaXplZA0KPiA+Pj4+ PiB1c2luZyB0aGUgSUVURg0KPiA+Pj4+Pj4gU3RhbmRhcmRzIHByb2Nlc3MuIFNwZWNpZmljYWxs eSBpdCB1c2VzIG1hdGVyaWFsIGZyb20NCj4gPj4+Pj4+IGRyYWZ0LWJoaC1tcGxzLXRwLW9hbS15 MTczMS0wNi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBXZSB3aXNoIHRvIGRyYXcgeW91ciBhdHRlbnRp b24gdG8gdGhlIHN0YXR1cyBzZWN0aW9uDQo+ID4+Pj4+IG9mDQo+ID4+Pj4+PiBkcmFmdC1iaGgt bXBscy10cC1vYW0teTE3MzEtMDYgd2hpY2ggc3RhdGVzOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICJJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYQ0KPiA+Pj4+PiBt YXhpbXVtIG9mIHNpeCBtb250aHMNCj4gPj4+Pj4+IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0KPiA+Pj4+PiBkb2N1bWVudHMgYXQgYW55DQo+ID4+ Pj4+PiB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMN Cj4gPj4+Pj4gcmVmZXJlbmNlIG1hdGVyaWFsDQo+ID4+Pj4+PiBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcyIuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNl IGFsc28gbm90ZSB0aGF0IHNpbmNlIHRoZSBkcmFmdCBmaWxlbmFtZSBzdGFydHMNCj4gPj4+Pj4g d2l0aCB0aGUgcHJlZml4DQo+ID4+Pj4+PiBzdHJpbmcgImRyYWZ0LWJoaCIgdGhpcyBjbGVhcmx5 IGlkZW50aWZpZXMgaXQgdG8gdGhlDQo+ID4+Pj4+IHJlYWRlciBhcyBhDQo+ID4+Pj4+PiBkb2N1 bWVudCBleHByZXNzaW5nIHRoZSBwZXJzb25hbCB0ZWNobmljYWwgdmlld3Mgb2YNCj4gPj4+Pj4g dGhlIGF1dGhvcnMgYW5kDQo+ID4+Pj4+PiBoZW5jZSBoZW5jZSBhcyBhIGRvY3VtZW50IHRoYXQg dGhhdCBkb2VzIG5vdCBoYXZlIGFueQ0KPiA+Pj4+PiBhY2tub3dsZWRnZWQgbGV2ZWwNCj4gPj4+ Pj4+IG9mIElFVEYgY29uc2Vuc3VzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNpbmNlIHRoZSB0ZXh0 IG9mIGRyYWZ0IFJlY29tbWVuZGF0aW9uIGZvciBHLnRwb2FtIGlzDQo+ID4+Pj4+IGJhc2VkIG9u IGFuDQo+ID4+Pj4+PiBNUExTLVRQIE9BTSBwcm90b2NvbCBub3QgZGVzaWduZWQgd2l0aGluIHRo ZSBJRVRGDQo+ID4+Pj4+IFN0YW5kYXJkcyBQcm9jZXNzIHRoaXMNCj4gPj4+Pj4+IGlzIGEgYnJl YWNoIG9mIHRoZSBTRzE1IGFncmVlbWVudCB3aXRoIHRoZSBJRVRGIGFzDQo+ID4+Pj4+IHB1Ymxp c2hlZCBpbiBSZXBvcnQNCj4gPj4+Pj4+IG9mIHRoZSBmaXJzdCBtZWV0aW5nIG9mIFdvcmtpbmcg UGFydHkgMy8xNSBUcmFuc3BvcnQNCj4gPj4+Pj4gbmV0d29yayBzdHJ1Y3R1cmVzDQo+ID4+Pj4+ PiAoMjAwOS0yMDEyKSAoR2VuZXZhLCAxIOKAkyAxMiBEZWNlbWJlciAyMDA4KSB3aGljaCBjYW4N Cj4gPj4+Pj4gYmUgZm91bmQgYXQNCj4gPj4+Pj4+IGh0dHA6Ly93d3cuaXR1LmludC9tZC9UMDkt U0cxNS1SLTAwMDQvZW4NCj4gPj4+Pj4+IFBsZWFzZSBjb25maXJtIHRoYXQgdGhlIElUVS1UIGlu dGVuZHMgdG8gY29udGludWUgd2l0aA0KPiA+Pj4+PiB0aGUgam9pbnQgd29yayBvbg0KPiA+Pj4+ Pj4gTVBMUy1UUCBhbmQgdGhhdCB0aGUgSVRVLVQgd2lsbCBhbGlnbiB0aGlzDQo+ID4+Pj4+IHJl Y29tbWVuZGF0aW9uIHdpdGggdGhlIElFVEYNCj4gPj4+Pj4+IE1QTFMtVFAgT0FNIGRlc2lnbiBi ZWZvcmUgYWR2YW5jaW5nIHRoaXMgZG9jdW1lbnQNCj4gPj4+Pj4gdGhyb3VnaCB0aGUgSVRVLVQN Cj4gPj4+Pj4+IHB1YmxpY2F0aW9uIHByb2Nlc3MuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIE1Q TFMgV29ya2luZyBHcm91cCB3b3VsZCBhbHNvIGxpa2UgdG8gZHJhdyB0aGUNCj4gPj4+Pj4gYXR0 ZW50aW9uIG9mIElUVS1UDQo+ID4+Pj4+PiBTRzE1IHRvIHRoZSBJRVRGIGNvcHlyaWdodCBydWxl cy4gUGxlYXNlIHNlZQ0KPiA+Pj4+Pj4gaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvL2FyY2hpdmUvSUVURi1UcnVzdC1MaWNlbnNlLVANCj4gPj4+Pj4+IG9sDQo+ID4+Pj4+PiBp Y3ktDQo+ID4+Pj4+PiAyMDA5MTIyOC5odG0NCj4gPj4+Pj4+IGZvciBmdXJ0aGVyIGRldGFpbHMu DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU2luY2UgdGhpcyBkcmFmdCBSZWNvbW1lbmRhdGlvbiBjb250 YWlucyB0ZXh0IGluIHdoaWNoDQo+ID4+Pj4+IHRoZSBJVFUtVCBTRzE1DQo+ID4+Pj4+PiBoYXMg cHJvcG9zZWQgbWFraW5nIGNoYW5nZXMgdG8gSUVURiBwcm90b2NvbHMgd2l0aG91dA0KPiA+Pj4+ PiB0aGUgYXBwcm92YWwgb2YNCj4gPj4+Pj4+IHRoZSBJRVRGLCB0aGUgTVBMUyBXb3JraW5nIEdy b3VwIGhhdmUgcmVmZXJyZWQgdGhpcw0KPiA+Pj4+PiBsaWFpc29uIHRvIHRoZSBJQUINCj4gPj4+ Pj4+IGZvciB0aGVpciBjb25zaWRlcmF0aW9uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gPT09PT09PT09DQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+ Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ Pj4+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiBtcGxzLXRwQGlldGYub3JnDQo+ID4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+Pj4+ Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+Pj4+IG1wbHMtdHBAaWV0 Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMt dHANCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+DQo+ID4+IC0tDQo+ ID4+IEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQo+ID4+DQo+ID4+IGh0 dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5k ZXguaHRtbA0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+PiBtcGxzQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ DQo+ID4NCj4gDQo+IA0KPiAtLQ0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIOaIkeeIseWklueCueS4gOS4g+S4ieS4gA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiBtcGxzLXRw QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10 cA0K From jdrake@juniper.net Thu Jan 13 14:49:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A073928C105; Thu, 13 Jan 2011 14:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZehPndIqAQb; Thu, 13 Jan 2011 14:49:17 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id E83EA28B23E; Thu, 13 Jan 2011 14:49:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTS+B+/Tj0SBUSZqTgaVApNjXo82N9RUE@postini.com; Thu, 13 Jan 2011 14:51:41 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 13 Jan 2011 14:47:13 -0800 From: John E Drake To: Huub van Helvoort , "mpls@ietf.org" , "mpls-tp@ietf.org" Date: Thu, 13 Jan 2011 14:49:09 -0800 Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuzcZ91cyVLfJeKTGmQ0aLyJTWuzwAAV5zA Message-ID: <5E893DB832F57341992548CDBB33316398C6F3BD48@EMBX01-HQ.jnpr.net> References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se> <4D2F47F9.8040701@cisco.com> <4D2F7D8E.9040505@gmail.com> In-Reply-To: <4D2F7D8E.9040505@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:49:18 -0000 VGhpcyBsaWFzb24sIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi85ODMvLCBp bmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudDoNCg0KIkF0IHRoZSBCZXJsaW4gaW50ZXJp bSBtZWV0aW5nIG9uIE1QTFMtVFAgZnVydGhlciB3b3JrIHdhcyB1bmRlcnRha2VuIG9uIHRoZSBk ZXZlbG9wbWVudCBvZiB0aGUgT0FNIFJlY29tbWVuZGF0aW9uIEcudHBvYW0uIFRoaXMgdmVyc2lv biB3YXMgZGV2ZWxvcGVkIHVzaW5nIGFsbCBvZiB0aGUgcmVsZXZhbnQgaW5wdXQgZG9jdW1lbnRz IHRvIHRoZSBtZWV0aW5nIGFuZCBpcyBiYXNlZCBvbiBkcmFmdC1iaGgtbXBscy10cC1vYW0teTE3 MzEtMDYuIFdlIGludml0ZSB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgZG9jdW1lbnQuIg0KDQpTbyB5 b3VyIHN0YXRlbWVudCBtYXkgYmUgZmFjdHVhbGx5IGNvcnJlY3QgYnV0IG1pc2xlYWRpbmcuIA0K DQpTZW50IGZyb20gbXkgaVBob25lDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLXRwLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBIdXViIHZhbiBIZWx2b29ydA0KPiBTZW50OiBUaHVy c2RheSwgSmFudWFyeSAxMywgMjAxMSAyOjMzIFBNDQo+IFRvOiBtcGxzQGlldGYub3JnOyBtcGxz LXRwQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBscy10cF0gW21wbHNdIERyYWZ0OiBSZXNw b25zZSB0byBVcGRhdGVkIGRyYWZ0DQo+IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZjA0My4w Ml0NCj4gDQo+IEhlbGxvIFN0ZXdhcnQsDQo+IA0KPiBZb3UgYXNrZWQ6DQo+IA0KPiA+IERvZXMg YW55b25lIGRpc2FncmVlIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IERhdmlkIG1ha2VzPw0KPiAN Cj4gSSBkaXNhZ3JlZSB3aXRoIHRoaXMgc3RhdGVtZW50IGluIHJlbGF0aW9uIHRvIHRoaXMgbGlh aXNvbi4NCj4gDQo+IFRoZSBkcmFmdCByZWNvbW1lbmRhdGlvbiBHLnRwb2FtIHRoYXQgd2FzIHNl bnQgZm9yIHJldmlldyBkb2VzDQo+IG5vdCBjb250YWluIGEgcmVmZXJlbmNlIHRvIGRyYWZ0LWJo aCBhdCBhbGwuDQo+IA0KPiBBbHNvIHRoZSBzdGF0ZW1lbnRzIGFib3V0IHZhbGlkaXR5IGFuZCBj b3B5cmlnaHQgYXJlIGlycmVsZXZhbnQuDQo+IA0KPiBSZWdhcmRzLCBIdXViLg0KPiANCj4gDQo+ ID09PT09PT09PT09PT09DQo+ID4gT24gMTMvMDEvMjAxMSAxNzowOSwgRGF2aWQgU2luaWNyb3Bl IHdyb3RlOg0KPiA+PiBJdCBzZWVtcyB0aGF0IHJlZmVyZW5jZSBhbmQgdXNlIG9mIGRyYWZ0LWJo aCBpcyBpbiB2aW9sYXRpb24gb2YgdGhlDQo+ID4+IElUVS1UIGV4dGVybmFsIGNvb3BlcmF0aW9u IGFncmVlbWVudCAiUmVmZXJlbmNpbmcgQS41IFF1YWxpZmllZA0KPiA+PiBPcmdhbml6YXRpb25z IiB0ZXh0IGZvdW5kIGF0DQo+ID4+IGh0dHA6Ly93d3cuaXR1LmludC9lbi9JVFUtVC9leHRjb29w L1BhZ2VzL3Nkby5hc3B4IHVuZGVyIHRoZQ0KPiA+PiBSZWZlcmVuY2luZyBJRVRGIERvY3VtZW50 cyBsaW5rLg0KPiA+PiBJbiBwYXJ0aWN1bGFyIGNsYXVzZSAxMCBvZiB0aGlzIGRvY3VtZW50IHN0 YXRlczogKFNlZSAybmQgc2VudGVuY2UuKQ0KPiA+Pg0KPiA+PiAiMTAgT3RoZXI6IElmIGEgc3R1 ZHkgZ3JvdXAgZGVjaWRlcyB0byBtYWtlIHRoZSByZWZlcmVuY2UgdG8gYW4gSUVURg0KPiA+PiBS RkMsIHRoZSByZWZlcmVuY2Ugc2hvdWxkIGFsd2F5cyBiZSBtYWRlIGJ5IFJGQyBudW1iZXIgKGFu ZCBub3QgYnkNCj4gPj4gb3RoZXIgZGVzaWduYXRpb25zIHN1Y2ggYXMgU1RELCBCQ1AsIGV0Yy4p LiBSZWZlcmVuY2VzIHNob3VsZCBub3QgYmUNCj4gPj4gbWFkZSB0byBkb2N1bWVudHMgcmVmZXJy ZWQgdG8gYXMgIkludGVybmV0IERyYWZ0cyIgb3IgdG8gSUVURiBSRkNzDQo+ID4+IGNhdGVnb3Jp emVkIGFzIEhpc3RvcmljIG9yIEV4cGVyaW1lbnRhbC4gTm9ybWF0aXZlIHJlZmVyZW5jZXMgbXVz dA0KPiA+PiBvbmx5IGJlIG1hZGUgdG8gSUVURiBSRkNzIHRoYXQgYXJlIFN0YW5kYXJkcyBUcmFj ayBvciB0bw0KPiBJbmZvcm1hdGlvbmFsDQo+ID4+IFJGQ3MgdGhhdCBoYXZlIElFVEYgY29uc2Vu c3VzLiINCj4gPj4NCj4gPj4gSXMgdGhpcyBub3QgY29ycmVjdD8gSWYgY29ycmVjdCwgc2hvdWxk bid0IHRoaXMgYWxzbyBiZSBwb2ludGVkIG91dA0KPiBpbg0KPiA+PiB0aGUgbGlhaXNvbj8NCj4g Pj4gRGF2ZQ0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KPiA+PiBPZiBTdGV3YXJ0IEJyeWFudA0KPiA+PiBTZW50OiBUaHVyc2RheSwgSmFu dWFyeSAxMywgMjAxMSAxMToyNyBBTQ0KPiA+PiBUbzogbXBsc0BpZXRmLm9yZw0KPiA+PiBTdWJq ZWN0OiBSZTogW21wbHNdIFttcGxzLXRwXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFm dA0KPiA+PiBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYwNDMuMDJdDQo+ID4+DQo+ID4+IEV4 YWN0bHkgQmVuLg0KPiA+Pg0KPiA+PiBUaGUgTGlhaXNvbiBpcyBsaXN0IG9mIHN0YXRlbWVudHMg b2YgcmVsZXZhbnQgZmFjdHMsIGFuZCBub25lIG9mIHRoZQ0KPiA+PiBjb250cmEgcG9pbnRzIGRp c3B1dGUgdGhvc2UgZmFjdHMuDQo+ID4+DQo+ID4+IFN0ZXdhcnQNCj4gPj4NCj4gPj4gT24gMTMv MDEvMjAxMSAxNTo0MSwgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6DQo+ID4+PiBMYXJyeSwNCj4g Pj4+DQo+ID4+PiBPbiAxMyBKYW4gMjAxMSwgYXQgMTQ6NTUsIExhcnJ5IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+PiBIaSwNCj4gPj4+Pg0KPiA+Pj4+IEkgZG9uJ3QgdGhpbmsgaXQgaXMgcHJvcGVyIHRv IHNlbmQgdGhlIExTIHRvIElUVS1UIGJlY2F1c2UgdGhlDQo+IHRleHQNCj4gPj4+PiBkb2Vzbid0 IHJlZmxlY3QgdGhlIHJlcXVpcmVtZW50IGZyb20gcHJvdmlkZXJzLg0KPiA+Pj4+IEFwcGFyZW50 bHksIGRyYWZ0LWJoaCBiYXNlZCBPQU0gaXMgdGhlIG1vc3QgbWF0dXJlIHNvbHV0aW9uDQo+ID4+ Pj4gY3VycmVudGx5LiBJdCBoYXMgYmVlbiBwcm92ZWQgYnkgbW9yZSB0aGFuIDIwMCwwMDAgYXBw bGljYXRpb25zDQo+IGFuZA0KPiA+Pj4+IGlzIHN1cHBvcnRlZCBieSBhIGxvdCBvZiBvcGVyYXRv cnMgYW5kIHZlbmRvcnMuDQo+ID4+Pj4NCj4gPj4+IFRoYXQgbWF5IG9yIG1heSBub3QgYmUgdHJ1 ZSwgYnV0IGVpdGhlciB3YXkgaXQgaXMgaXJyZWxldmFudCB0byB0aGUNCj4gPj4+IGxpYWlzb24u DQo+ID4+Pg0KPiA+Pj4gSVRVIGxpYWlzZWQgRy50cG9hbSB0byBJRVRGLiBUaGUgbGlhaXNvbiBy ZXNwb25zZSBTdGV3YXJ0IGhhcw0KPiBkcmFmdGVkDQo+ID4+PiBwb2ludHMgb3V0IHRoYXQgRy50 cG9hbSB1c2VzIHRlY2hub2xvZ3kgKGRyYWZ0LWJoaCkgdGhhdCBpcyBub3QNCj4gPj4+IGVuZG9y c2VkIGJ5IElFVEYgY29uc2Vuc3VzIGFuZCBwb2ludHMgdG8gc29tZSByaXNrcyBvZiBkb2luZyBz bywNCj4gPj4+IGluY2x1ZGluZyBicmVhY2ggb2YgYSBwcmlvciBJVFUtSUVURiBhZ3JlZW1lbnQg b24gaG93IHRvIHByb2dyZXNzDQo+ID4+PiBNUExTLVRQIGRldmVsb3BtZW50Lg0KPiA+Pj4NCj4g Pj4+IEV2ZXJ5dGhpbmcgaW4gdGhlIGxpYWlzb24gaXMgZmFjdC4gV2hldGhlciBkcmFmdC1iaGgg aXMNCj4gPj4+IGdvb2QvYmFkL3VnbHksIGRlcGxveWVkLCBzdXBwb3J0ZWQgYnkgb3BlcmF0b3Jz LCBldGMuIGlzDQo+IGlycmVsZXZhbnQsDQo+ID4+PiBpdCBpcyBub3QgZW5kb3JzZWQgYnkgSUVU RiBhcyBhIE1QTFMtVFAgT0FNIHNvbHV0aW9uIGFuZCBhbGwgdGhlDQo+ID4+PiBsaWFpc29uIGRv ZXMgaXMgcG9pbnQgb3V0IHRoYXQgZmFjdC4NCj4gPj4+DQo+ID4+PiBGV0lXIHRoaXMgaXNuJ3Qg dGhlIGZpcnN0IHRpbWUgYSBncm91cCBvZiBvcGVyYXRvcnMgaGF2ZSBicm91Z2h0IGENCj4gPj4+ IHByb3Bvc2FsIHRvIElFVEYgb25seSB0byBmaW5kIHRoYXQgdGhlIElFVEYgaGFzIGRlY2lkZWQg dG8gZG8NCj4gPj4+IHNvbWV0aGluZyBlbHNlLCBhbmQgSSdtIHN1cmUgaXQgd29uJ3QgYmUgdGhl IGxhc3QuDQo+ID4+Pg0KPiA+Pj4gQmVuDQo+ID4+Pg0KPiA+Pj4gUC5TLiBmb3Igc29tZSByZWFz b24gZW1haWwgY2hhaW5zIHJlbGF0ZWQgdG8gZHJhZnQtYmhoIHJlbWluZCBtZSBvZg0KPiA+Pj4g dGhpcyBEaWxiZXJ0IGNhcnRvb24gaHR0cDovL3d3dy5kaWxiZXJ0LmNvbS8yMDEwLTEyLTIyLw0K PiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+Pg0KPiA+Pj4+ IEhhbiBMaQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+Pj4gKioqKg0KPiA+ Pj4+IEhhbiBMaSwgUGguRA0KPiA+Pj4+IENoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGUN Cj4gPj4+PiBVbml0IDIsIDI4IFh1YW53dW1lbnhpIEF2ZSwgWHVhbnd1IERpc3RyaWN0LCBCZWlq aW5nIDEwMDA1MywgQ2hpbmENCj4gPj4+PiBGYXg6ICs4NiAxMCA2MzYwMTA4Nw0KPiA+Pj4+IE1P QklMRTogMTM1MDEwOTMzODUNCj4gPj4+Pg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4+PiAqKioqDQo+ ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IC0tLSAxMeW5tDHmnIgxM+aXpe+8jOWRqOWbmywNCj4gPj4+ PiBydWlxdWFuLmppbmdAdGllcy5pdHUuaW50PHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ+DQo+ ID4+Pj4g5YaZ6YGT77yaDQo+ID4+Pj4NCj4gPj4+Pj4g5Y+R5Lu25Lq6OiBydWlxdWFuLmppbmdA dGllcy5pdHUuaW50PHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ+DQo+ID4+Pj4+IOS4u+mimDog UmU6IFttcGxzLXRwXSBbbXBsc10gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQNCj4g Pj4+Pj4gUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmMDQzLjAyXQ0KPiA+Pj4+PiDmlLbku7bk uro6IGppbmdyQHRpZXMuaXR1LmNoDQo+ID4+Pj4+IOaKhOmAgTogbXBscy10cEBpZXRmLm9yZw0K PiA+Pj4+PiDml6XmnJ86IDIwMTHlubQx5pyIMTPml6Us5ZGo5ZubLOS4i+WNiDQ6MDkNCj4gPj4+ Pj4gUmVzZW5kIHRvIG1wbHMtdHAgbGlzdC4NCj4gPj4+Pj4NCj4gPj4+Pj4gUXVvdGluZyBqaW5n ckB0aWVzLml0dS5jaDoNCj4gPj4+Pj4NCj4gPj4+Pj4+IEhpIFN0ZXdhcnQgQnJ5YW50LA0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IEkgZG9u4oCZdCBhZ3JlZSB3aXRoIHRoZSBjdXJyZW50IExTIHRleHQu DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQ2hpbmEgVGVsZWNvbSBzdXBwb3J0IHRoZSBzdGFuZGFyZGl6 YXRpb24gb2YgWS4xNzMxDQo+ID4+Pj4+IGJhc2VkIE1QTFMtVFAgT0FNIHRvb2xzDQo+ID4+Pj4+ PiBpbg0KPiA+Pj4+Pj4gdGhlIElUVS1UIHRvIG1lZXQgdGhlIHVyZ2VudCBhbmQgaW5jcmVhc2lu Zw0KPiA+Pj4+PiByZXF1aXJlbWVudHMgZm9yIFBUTiBkZXBsb3ltZW50Lg0KPiA+Pj4+Pj4gSXTi gJlzIGEgbXVsdGktdmVuZG9yIHN1cHBvcnRlZCwgaW50ZXJvcGVyYWJpbGl0eQ0KPiA+Pj4+PiBj ZXJ0aWZpY2F0ZWQgYW5kIGZlYXNpYmxlDQo+ID4+Pj4+PiBzb2x1dGlvbi4gSXQgaGFkIGJlZW4g c3BlY2lmaWVkIGluIGJvdGggQ0NTQQ0KPiA+Pj4+PiAoQ2hpbmEgQ29tbXVuaWNhdGlvbnMgU3Rh bmRhcmRzDQo+ID4+Pj4+PiBBc3NvY2lhdGlvbikgYW5kIENoaW5hIFRlbGVjb23igJlzIFBUTiBz dGFuZGFyZCBhcyB0aGUNCj4gPj4+Pj4gb25seSBzdGFuZGFyZCBPQU0NCj4gPj4+Pj4+IG1lY2hh bmlzbS4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEJlc3QgUmVnYXJk cw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEppbmcgUnVpcXVhbg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IENo aW5h44CAVGVsZWNvbSBCZWlqaW5nDQo+ID4+Pj4+IFJlc2VhcmNo44CASW5zdGl0dXRlDQo+ID4+ Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IC0tLQ0KPiA+Pj4+PiAtLS0tLS0tLS0tDQo+ID4+Pj4+IC0tDQo+ID4+ Pj4+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPj4+Pj4gW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddDQo+ID4+Pj4+IE9uIEJlaGFsZiBPZg0KPiA+Pj4+Pj4gU3Rld2FydA0K PiA+Pj4+Pj4gQnJ5YW50DQo+ID4+Pj4+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMTAsIDIwMTEg Njo1NyBQTQ0KPiA+Pj4+Pj4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+IFN1YmplY3Q6IFtt cGxzXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdA0KPiA+Pj4+PiBSZWNvbW1lbmRh dGlvbiBHLnRwb2FtDQo+ID4+Pj4+PiBbUmVmMDQzLjAyXQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ ID4+Pj4+PiBJIHByb3Bvc2UgdG8gc2VuZCB0aGUgZm9sbG93aW5nIExpYWlzb24gUmVzcG9uc2Ug dG8NCj4gPj4+Pj4gdGhlIElUVS1UIG9uIEZyaWRheQ0KPiA+Pj4+Pj4gMTR0aCBKYW51YXJ5IGFu ZCBhbSBwb3N0aW5nIGl0IHRvIHRoZSBNUExTIFdHIGxpc3QgZm9yDQo+ID4+Pj4+IHJldmlldy4N Cj4gPj4+Pj4+ID09PT09PT0NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBSZXNwb25zZSB0byBVcGRhdGVk IGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZg0KPiA+Pj4+PiAwNDMuMDJdDQo+ID4+ Pj4+PiBGcm9tOiBJRVRGIExpYWlzb24gdG8gSVRVLVQgb24gTVBMUyBzdGJyeWFudEBjaXNjby5j b20NCj4gPj4+Pj4+IFRvOiB0c2JzZzE1QGl0dS5pbnQsDQo+ID4+Pj4+IGdyZWcuam9uZXNAaXR1 LmludCwNCj4gPj4+Pj4gaGlyb3NoaS5vdGFAaXR1LmludCwNCj4gPj4+Pj4gSUFCQGlldGYub3Jn DQo+ID4+Pj4+PiBDQzogR3JlZyBKb25lcywgc3dhbGxvd0BjaXNjby5jb20sDQo+ID4+Pj4+IGxv YUBwaS5udSwgcGFmQGNpc2NvLmNvbQ0KPiA+Pj4+Pj4gc3RicnlhbnRAY2lzY28uY29tLA0KPiA+ Pj4+PiBhZHJpYW4uZmFycmVsQGh1YXdlaS5jb20sDQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4g Pj4+Pj4+IHlvaWNoaS5tYWVkYUB0dGMub3IuanAsDQo+ID4+Pj4+IHN0ZXZlLnRyb3dicmlkZ2VA YWxjYXRlbC1sdWNlbnQuY29tDQo+ID4+Pj4+DQo+ID4+Pj4+PiBnaGFuaS5hYmJhc0Blcmljc3Nv bi5jb20sDQo+ID4+Pj4+IGhoZWx2b29ydEBodWF3ZWkuY29tDQo+ID4+Pj4+DQo+ID4+Pj4+PiBt YWxjb2xtLmJldHRzQHp0ZS5jb20uY24sDQo+ID4+Pj4+IGthbS5sYW1AYWxjYXRlbC1sdWNlbnQu Y29tDQo+ID4+Pj4+DQo+ID4+Pj4+PiBGb3IgQWN0aW9uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhl IE1QTFMgV29ya2luZyBHcm91cCBub3RlcyB0aGF0IHRoaXMgZG9jdW1lbnQNCj4gPj4+Pj4gY29u dGFpbnMgdGV4dCBkZXNjcmliaW5nDQo+ID4+Pj4+PiBNUExTLVRQIE9BTSBwcm90b2NvbHMgbm90 IGRlc2lnbmVkIGFuZCBzdGFuZGFyZGl6ZWQNCj4gPj4+Pj4gdXNpbmcgdGhlIElFVEYNCj4gPj4+ Pj4+IFN0YW5kYXJkcyBwcm9jZXNzLiBTcGVjaWZpY2FsbHkgaXQgdXNlcyBtYXRlcmlhbCBmcm9t DQo+ID4+Pj4+PiBkcmFmdC1iaGgtbXBscy10cC1vYW0teTE3MzEtMDYuDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gV2Ugd2lzaCB0byBkcmF3IHlvdXIgYXR0ZW50aW9uIHRvIHRoZSBzdGF0dXMgc2VjdGlv bg0KPiA+Pj4+PiBvZg0KPiA+Pj4+Pj4gZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2IHdo aWNoIHN0YXRlczoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAiSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGENCj4gPj4+Pj4gbWF4aW11bSBvZiBzaXggbW9udGhzDQo+ ID4+Pj4+PiBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXINCj4gPj4+Pj4gZG9jdW1lbnRzIGF0IGFueQ0KPiA+Pj4+Pj4gdGltZS4gSXQgaXMgaW5hcHBy b3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzDQo+ID4+Pj4+IHJlZmVyZW5jZSBtYXRl cmlhbA0KPiA+Pj4+Pj4gb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJv Z3Jlc3MiLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFBsZWFzZSBhbHNvIG5vdGUgdGhhdCBzaW5jZSB0 aGUgZHJhZnQgZmlsZW5hbWUgc3RhcnRzDQo+ID4+Pj4+IHdpdGggdGhlIHByZWZpeA0KPiA+Pj4+ Pj4gc3RyaW5nICJkcmFmdC1iaGgiIHRoaXMgY2xlYXJseSBpZGVudGlmaWVzIGl0IHRvIHRoZQ0K PiA+Pj4+PiByZWFkZXIgYXMgYQ0KPiA+Pj4+Pj4gZG9jdW1lbnQgZXhwcmVzc2luZyB0aGUgcGVy c29uYWwgdGVjaG5pY2FsIHZpZXdzIG9mDQo+ID4+Pj4+IHRoZSBhdXRob3JzIGFuZA0KPiA+Pj4+ Pj4gaGVuY2UgaGVuY2UgYXMgYSBkb2N1bWVudCB0aGF0IHRoYXQgZG9lcyBub3QgaGF2ZSBhbnkN Cj4gPj4+Pj4gYWNrbm93bGVkZ2VkIGxldmVsDQo+ID4+Pj4+PiBvZiBJRVRGIGNvbnNlbnN1cy4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBTaW5jZSB0aGUgdGV4dCBvZiBkcmFmdCBSZWNvbW1lbmRhdGlv biBmb3IgRy50cG9hbSBpcw0KPiA+Pj4+PiBiYXNlZCBvbiBhbg0KPiA+Pj4+Pj4gTVBMUy1UUCBP QU0gcHJvdG9jb2wgbm90IGRlc2lnbmVkIHdpdGhpbiB0aGUgSUVURg0KPiA+Pj4+PiBTdGFuZGFy ZHMgUHJvY2VzcyB0aGlzDQo+ID4+Pj4+PiBpcyBhIGJyZWFjaCBvZiB0aGUgU0cxNSBhZ3JlZW1l bnQgd2l0aCB0aGUgSUVURiBhcw0KPiA+Pj4+PiBwdWJsaXNoZWQgaW4gUmVwb3J0DQo+ID4+Pj4+ PiBvZiB0aGUgZmlyc3QgbWVldGluZyBvZiBXb3JraW5nIFBhcnR5IDMvMTUgVHJhbnNwb3J0DQo+ ID4+Pj4+IG5ldHdvcmsgc3RydWN0dXJlcw0KPiA+Pj4+Pj4gKDIwMDktMjAxMikgKEdlbmV2YSwg MSDigJMgMTIgRGVjZW1iZXIgMjAwOCkgd2hpY2ggY2FuDQo+ID4+Pj4+IGJlIGZvdW5kIGF0DQo+ ID4+Pj4+PiBodHRwOi8vd3d3Lml0dS5pbnQvbWQvVDA5LVNHMTUtUi0wMDA0L2VuDQo+ID4+Pj4+ PiBQbGVhc2UgY29uZmlybSB0aGF0IHRoZSBJVFUtVCBpbnRlbmRzIHRvIGNvbnRpbnVlIHdpdGgN Cj4gPj4+Pj4gdGhlIGpvaW50IHdvcmsgb24NCj4gPj4+Pj4+IE1QTFMtVFAgYW5kIHRoYXQgdGhl IElUVS1UIHdpbGwgYWxpZ24gdGhpcw0KPiA+Pj4+PiByZWNvbW1lbmRhdGlvbiB3aXRoIHRoZSBJ RVRGDQo+ID4+Pj4+PiBNUExTLVRQIE9BTSBkZXNpZ24gYmVmb3JlIGFkdmFuY2luZyB0aGlzIGRv Y3VtZW50DQo+ID4+Pj4+IHRocm91Z2ggdGhlIElUVS1UDQo+ID4+Pj4+PiBwdWJsaWNhdGlvbiBw cm9jZXNzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBNUExTIFdvcmtpbmcgR3JvdXAgd291bGQg YWxzbyBsaWtlIHRvIGRyYXcgdGhlDQo+ID4+Pj4+IGF0dGVudGlvbiBvZiBJVFUtVA0KPiA+Pj4+ Pj4gU0cxNSB0byB0aGUgSUVURiBjb3B5cmlnaHQgcnVsZXMuIFBsZWFzZSBzZWUNCj4gPj4+Pj4+ IGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mby9hcmNoaXZlL0lFVEYtVHJ1c3Qt TGljZW5zZS0NCj4gUG9sDQo+ID4+Pj4+PiBpY3ktDQo+ID4+Pj4+PiAyMDA5MTIyOC5odG0NCj4g Pj4+Pj4+IGZvciBmdXJ0aGVyIGRldGFpbHMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU2luY2UgdGhp cyBkcmFmdCBSZWNvbW1lbmRhdGlvbiBjb250YWlucyB0ZXh0IGluIHdoaWNoDQo+ID4+Pj4+IHRo ZSBJVFUtVCBTRzE1DQo+ID4+Pj4+PiBoYXMgcHJvcG9zZWQgbWFraW5nIGNoYW5nZXMgdG8gSUVU RiBwcm90b2NvbHMgd2l0aG91dA0KPiA+Pj4+PiB0aGUgYXBwcm92YWwgb2YNCj4gPj4+Pj4+IHRo ZSBJRVRGLCB0aGUgTVBMUyBXb3JraW5nIEdyb3VwIGhhdmUgcmVmZXJyZWQgdGhpcw0KPiA+Pj4+ PiBsaWFpc29uIHRvIHRoZSBJQUINCj4gPj4+Pj4+IGZvciB0aGVpciBjb25zaWRlcmF0aW9uLg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gPT09PT09PT09DQo+ID4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+ Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+ Pj4+PiBtcGxzLXRwQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscy10cA0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBtcGxzLXRwIG1haWxp bmcgbGlzdA0KPiA+Pj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo+ID4+DQo+ID4+IC0tDQo+ID4+IEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3Jt YXRpb24gZ28gdG86DQo+ID4+DQo+ID4+IGh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9k b2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtcGxzIG1h aWxpbmcgbGlzdA0KPiA+PiBtcGxzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+DQo+ID4NCj4gDQo+IA0KPiAtLQ0KPiAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIOaIkeeIseWklueCueS4gOS4g+S4ieS4gA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxz LXRwIG1haWxpbmcgbGlzdA0KPiBtcGxzLXRwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0K From ietf@cdl.asgaard.org Thu Jan 13 14:51:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4060B3A6BED; Thu, 13 Jan 2011 14:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbvc-a5J2zzd; Thu, 13 Jan 2011 14:51:07 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id 673AC3A6452; Thu, 13 Jan 2011 14:51:06 -0800 (PST) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id 21193A0951B; Thu, 13 Jan 2011 22:53:25 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-139-971899664" From: Christopher LILJENSTOLPE In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264033056FB@DEMUEXC014.nsn-intra.net> Date: Fri, 14 Jan 2011 09:53:15 +1100 Message-Id: <616B8263-BEB6-4A15-9F8C-E9798A726CA5@cdl.asgaard.org> References: <1294906173.4d2eb33dd1ffa@gold.itu.ch> <526321.56478.qm@web15605.mail.cnb.yahoo.com> <077E41CFFD002C4CAB7DFA4386A53264033056FB@DEMUEXC014.nsn-intra.net> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: mpls@ietf.org, ext Larry , jingr@ties.itu.ch, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draftRecommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:51:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-139-971899664 Content-Type: multipart/alternative; boundary=Apple-Mail-138-971899564 --Apple-Mail-138-971899564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Nurit. Christopher LILJENSTOLPE Director, Architecture, Telstra On 14Jan2011, at 02.30, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: > Han Li, >=20 > Please note that this liaison is not intended to get into technical = discussion or into SPs' requirements.=20 >=20 > It is more on the procedures and processes.... >=20 > According to the collaborative agreement between the ITU-T and the = IETF (which was accepted by ITU-T SG15 in December 2008), the = development of the protocol should be done in the IETF using the IETF = processes. The ITU-T documents should refer to the IETF solutions.=20 >=20 > We note a document (under development) in the ITU-T (g.tpoam), which = includes the definition of messages and procedures for MSPL-TP which = were not developed using the IETF standard processes and does not follow = the IETF change/extension processes. This is contrary to the agreement = between the IETF and the ITU-T from December 2008.=20 >=20 > We are responding on the process and want to be sure (and hope) that = the ITU-T intends to continue with the joint work on MPLS-TP as agreed = on in December 2008.=20 >=20 > I think the liaison is very well written! >=20 > Best regards, >=20 > Nurit >=20 >=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext Larry > Sent: Thursday, January 13, 2011 4:56 PM > To: jingr@ties.itu.ch; ruiquan.jing@ties.itu.int > Cc: mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [mpls] Draft: Response to Updated = draftRecommendation G.tpoam [Ref043.02] >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > I don't think it is proper to send the LS to ITU-T because the text = doesn't reflect the requirement from providers. >=20 > Apparently, draft-bhh based OAM is the most mature solution = currently. It has been proved by more than 200,000 applications and is = supported by a lot of operators and vendors.=20 >=20 >=20 >=20 > Best regards, >=20 >=20 >=20 > Han Li >=20 >=20 >=20 > = ************************************************************************* >=20 > Han Li, Ph.D=20 >=20 > China Mobile Research Institute >=20 > Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 >=20 > Fax: +86 10 63601087=20 >=20 > MOBILE: 13501093385=20 >=20 > = ************************************************************************* >=20 >=20 >=20 >=20 >=20 > --- 11=E5=B9=B41=E6=9C=8813=E6=97=A5=EF=BC=8C=E5=91=A8=E5=9B=9B, = ruiquan.jing@ties.itu.int =E5=86=99=E9=81=93=EF= =BC=9A >=20 >=20 >=20 >> =E5=8F=91=E4=BB=B6=E4=BA=BA: ruiquan.jing@ties.itu.int = >=20 >> =E4=B8=BB=E9=A2=98: Re: [mpls-tp] [mpls] Draft: Response to Updated = draft Recommendation G.tpoam [Ref043.02] >=20 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: jingr@ties.itu.ch >=20 >> =E6=8A=84=E9=80=81: mpls-tp@ietf.org >=20 >> =E6=97=A5=E6=9C=9F: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5,=E5=91=A8=E5=9B=9B= ,=E4=B8=8B=E5=8D=884:09 >=20 >> Resend to mpls-tp list. >=20 >>=20 >=20 >> Quoting jingr@ties.itu.ch: >=20 >>=20 >=20 >>> Hi Stewart Bryant, >=20 >>>=20 >=20 >>> I don=E2=80=99t agree with the current LS text. >=20 >>>=20 >=20 >>> China Telecom support the standardization of Y.1731 >=20 >> based MPLS-TP OAM tools >=20 >>> in=20 >=20 >>> the ITU-T to meet the urgent and increasing >=20 >> requirements for PTN deployment.=20 >=20 >>>=20 >=20 >>> It=E2=80=99s a multi-vendor supported, interoperability >=20 >> certificated and feasible=20 >=20 >>> solution. It had been specified in both CCSA >=20 >> (China Communications Standards >=20 >>>=20 >=20 >>> Association) and China Telecom=E2=80=99s PTN standard as the >=20 >> only standard OAM=20 >=20 >>> mechanism. >=20 >>>=20 >=20 >>>=20 >=20 >>>=20 >=20 >>> Best Regards >=20 >>>=20 >=20 >>> Jing Ruiquan >=20 >>>=20 >=20 >>> China=E3=80=80Telecom Beijing=20 >=20 >> Research=E3=80=80Institute >=20 >>>=20 >=20 >>>=20 >=20 >> = --------------------------------------------------------------------------= ---- >=20 >> -- >=20 >>> From: mpls-bounces@ietf.org >=20 >> [mailto:mpls-bounces@ietf.org] >=20 >> On Behalf Of >=20 >>> Stewart=20 >=20 >>> Bryant >=20 >>> Sent: Monday, January 10, 2011 6:57 PM >=20 >>> To: mpls@ietf.org >=20 >>> Subject: [mpls] Draft: Response to Updated draft >=20 >> Recommendation G.tpoam=20 >=20 >>> [Ref043.02] >=20 >>>=20 >=20 >>>=20 >=20 >>> I propose to send the following Liaison Response to >=20 >> the ITU-T on Friday=20 >=20 >>> 14th January and am posting it to the MPLS WG list for >=20 >> review.=20 >=20 >>>=20 >=20 >>> =3D=3D=3D=3D=3D=3D=3D=20 >=20 >>>=20 >=20 >>> Response to Updated draft Recommendation G.tpoam [Ref >=20 >> 043.02]=20 >=20 >>>=20 >=20 >>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >=20 >>=20 >=20 >>> To: tsbsg15@itu.int, >=20 >> greg.jones@itu.int, >=20 >> hiroshi.ota@itu.int, >=20 >> IAB@ietf.org=20 >=20 >>> CC: Greg Jones, swallow@cisco.com, >=20 >> loa@pi.nu, paf@cisco.com=20 >=20 >>> stbryant@cisco.com, >=20 >> adrian.farrel@huawei.com, >=20 >> mpls@ietf.org=20 >=20 >>> yoichi.maeda@ttc.or.jp, >=20 >> steve.trowbridge@alcatel-lucent.com >=20 >>=20 >=20 >>> ghani.abbas@ericsson.com, >=20 >> hhelvoort@huawei.com >=20 >>=20 >=20 >>> malcolm.betts@zte.com.cn, >=20 >> kam.lam@alcatel-lucent.com >=20 >>=20 >=20 >>>=20 >=20 >>> For Action=20 >=20 >>>=20 >=20 >>> The MPLS Working Group notes that this document >=20 >> contains text describing=20 >=20 >>> MPLS-TP OAM protocols not designed and standardized >=20 >> using the IETF=20 >=20 >>> Standards process. Specifically it uses material from >=20 >>=20 >=20 >>> draft-bhh-mpls-tp-oam-y1731-06.=20 >=20 >>>=20 >=20 >>> We wish to draw your attention to the status section >=20 >> of=20 >=20 >>> draft-bhh-mpls-tp-oam-y1731-06 which states:=20 >=20 >>>=20 >=20 >>> "Internet-Drafts are draft documents valid for a >=20 >> maximum of six months=20 >=20 >>> and may be updated, replaced, or obsoleted by other >=20 >> documents at any=20 >=20 >>> time. It is inappropriate to use Internet-Drafts as >=20 >> reference material=20 >=20 >>> or to cite them other than as "work in progress".=20 >=20 >>>=20 >=20 >>> Please also note that since the draft filename starts >=20 >> with the prefix=20 >=20 >>> string "draft-bhh" this clearly identifies it to the >=20 >> reader as a=20 >=20 >>> document expressing the personal technical views of >=20 >> the authors and=20 >=20 >>> hence hence as a document that that does not have any >=20 >> acknowledged level=20 >=20 >>> of IETF consensus.=20 >=20 >>>=20 >=20 >>> Since the text of draft Recommendation for G.tpoam is >=20 >> based on an=20 >=20 >>> MPLS-TP OAM protocol not designed within the IETF >=20 >> Standards Process this=20 >=20 >>> is a breach of the SG15 agreement with the IETF as >=20 >> published in Report=20 >=20 >>> of the first meeting of Working Party 3/15 Transport >=20 >> network structures=20 >=20 >>> (2009-2012) (Geneva, 1 =E2=80=93 12 December 2008) which can >=20 >> be found at=20 >=20 >>> http://www.itu.int/md/T09-SG15-R-0004/en >=20 >>=20 >=20 >>>=20 >=20 >>> Please confirm that the ITU-T intends to continue with >=20 >> the joint work on=20 >=20 >>> MPLS-TP and that the ITU-T will align this >=20 >> recommendation with the IETF=20 >=20 >>> MPLS-TP OAM design before advancing this document >=20 >> through the ITU-T=20 >=20 >>> publication process.=20 >=20 >>>=20 >=20 >>> The MPLS Working Group would also like to draw the >=20 >> attention of ITU-T=20 >=20 >>> SG15 to the IETF copyright rules. Please see=20 >=20 >>> = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- >=20 >>> 20091228.htm=20 >=20 >>> for further details.=20 >=20 >>>=20 >=20 >>> Since this draft Recommendation contains text in which >=20 >> the ITU-T SG15=20 >=20 >>> has proposed making changes to IETF protocols without >=20 >> the approval of=20 >=20 >>> the IETF, the MPLS Working Group have referred this >=20 >> liaison to the IAB=20 >=20 >>> for their consideration.=20 >=20 >>>=20 >=20 >>>=20 >=20 >>>=20 >=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=20 >>> _______________________________________________=20 >=20 >>> mpls mailing list=20 >=20 >>> mpls@ietf.org=20 >=20 >>> https://www.ietf.org/mailman/listinfo/mpls=20 >=20 >>>=20 >=20 >>>=20 >=20 >>>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> _______________________________________________ >=20 >> mpls-tp mailing list >=20 >> mpls-tp@ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >>=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > mpls-tp mailing list >=20 > mpls-tp@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-138-971899564 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Nurit.

Christopher = LILJENSTOLPE
Director, Architecture, = Telstra

Dear Stewart, all,

I do not agree on the proposed Liaison text for the reasons explained inline below.

 

Best regards,

Alessandro

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

Telecom Italia

Alessandro D'Alessandro

Transport & OPB Innovation

Via Reiss Romoli, 274 - 10148 Torino

phone:  +39 011 228 5887

mobile: +39 335 766 9607

fax: +39 06 418 639 07

 

 

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: lunedì 10 gennaio 2011 11.57
To: mpls@ietf.org
Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02]

 

I propose to send the following Liaison Response to the ITU-T on Friday

14th January and am posting it to the MPLS WG list for review.

 

=======

 

Response to Updated draft Recommendation G.tpoam [Ref 043.02]

 

From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com

To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org

CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com

stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org

yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com

ghani.abbas@ericsson.com, hhelvoort@huawei.com

malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com

 

For Action

 

The MPLS Working Group notes that this document contains text describing

MPLS-TP OAM protocols not designed and standardized using the IETF

Standards process. Specifically it uses material from

draft-bhh-mpls-tp-oam-y1731-06.

[dalessandro] In my understanding ITU-T G.tpoam is based on ITU-T Y.1731.


On 14Jan2011, at 02.30, = Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:

Han = Li,

Please note that this liaison is not intended to get into = technical discussion or into SPs' requirements.

It is more on = the procedures and processes....

According to the collaborative = agreement between the ITU-T and the IETF (which was accepted by ITU-T = SG15 in December 2008), the development of the protocol should be done = in the IETF using the IETF processes. The ITU-T documents should refer = to the IETF solutions.

We note a document (under development) in = the ITU-T (g.tpoam), which includes the definition of messages and = procedures for MSPL-TP which were not developed using the IETF standard = processes and does not follow the IETF change/extension processes. This = is contrary to the agreement between the IETF and the ITU-T from = December 2008.

We are responding on the process and want to be = sure (and hope) that the ITU-T intends to continue with the joint work = on MPLS-TP as agreed on in December 2008.

I think the liaison is = very well written!

Best = regards,

Nurit



-----Original Message-----
From: = mpls-tp-bounces@ietf.org = [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Larry
Sent: = Thursday, January 13, 2011 4:56 PM
To: jingr@ties.itu.ch; ruiquan.jing@ties.itu.intCc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: = [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam = [Ref043.02]



Hi,



   I don't = think it is proper to send the LS to ITU-T because the text doesn't = reflect the requirement from providers.

=    Apparently, draft-bhh based OAM is the most mature = solution currently. It has been proved by more than 200,000 applications = and is supported by a lot of operators and vendors.



Best = regards,



=             &n= bsp;Han = Li



********************************************************= *****************

Han Li, Ph.D

China Mobile Research = Institute

Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing = 100053, China

Fax: +86 10 63601087

MOBILE: 13501093385 =

******************************************************************= *******





--- 11=E5=B9=B41=E6=9C=8813=E6=97=A5=EF=BC=8C= =E5=91=A8=E5=9B=9B, ruiquan.jing@ties.itu.int = <ruiquan.jing@ties.itu.int>= ; =E5=86=99=E9=81=93=EF=BC=9A



=E5=8F=91=E4=BB=B6=E4=BA=BA: ruiquan.jing@ties.itu.int = <ruiquan.jing@ties.itu.int>= ;

=E4=B8=BB=E9=A2=98: Re: = [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.tpoam = [Ref043.02]

=E6=94=B6=E4=BB=B6= =E4=BA=BA: jingr@ties.itu.ch
=E6=8A=84=E9=80=81: mpls-tp@ietf.org

=
=E6=97=A5=E6=9C=9F: = 2011=E5=B9=B41=E6=9C=8813=E6=97=A5,=E5=91=A8=E5=9B=9B,=E4=B8=8B=E5=8D=884:= 09

Resend to mpls-tp = list.



Quoting jingr@ties.itu.ch:
<= br>


Hi Stewart = Bryant,



I don=E2=80=99t agree with the = current LS text.



China Telecom support the = standardization of Y.1731

based MPLS-TP OAM tools

in =

the ITU-T to meet the urgent and = increasing

requirements for PTN deployment. =



It=E2=80=99s a multi-vendor = supported, interoperability

certificated and feasible

solution.  It had been = specified in both CCSA

(China Communications = Standards



Association) and China = Telecom=E2=80=99s PTN standard as = the

only = standard OAM

mechanism.







Best = Regards



Jing = Ruiquan



China=E3=80=80Telecom =  Beijing

Research=E3=80=80Institute





------------------------------------------------------------= ------------------

--

From: mpls-bounces@ietf.org

[mailto:mpls-bounces@ietf.org]

On Behalf Of

Stewart =

Bryant

Sent: Monday, January 10, 2011 = 6:57 PM

To: mpls@ietf.org

Subject: = [mpls] Draft: Response to Updated = draft

Recommendation G.tpoam

[Ref043.02]





I propose to send the following = Liaison Response to

the ITU-T on Friday

14th January and am posting it = to the MPLS WG list for

review.



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



Response to Updated draft = Recommendation G.tpoam [Ref

043.02]



From: IETF Liaison to ITU-T on = MPLS stbryant@cisco.com
=



To: tsbsg15@itu.int,

greg.jones@itu.int,

hiroshi.ota@itu.int,

IAB@ietf.org =

CC: Greg Jones, swallow@cisco.com,
<= /blockquote>
loa@pi.nu, paf@cisco.com =

stbryant@cisco.com,

adrian.farrel@huawei.com,
=

mpls@ietf.org =

yoichi.maeda@ttc.or.jp,

steve.trowbridge@alcat= el-lucent.com



ghani.abbas@ericsson.com,
=

hhelvoort@huawei.com



malcolm.betts@zte.com.cn,
=

kam.lam@alcatel-lucent.com<= br>





For Action =



The MPLS Working Group notes = that this document

contains text describing

MPLS-TP OAM protocols not = designed and standardized

using the IETF

Standards process. Specifically = it uses material from



draft-bhh-mpls-tp-oam-y1731-06. =



We wish to draw your attention = to the status section

of

draft-bhh-mpls-tp-oam-y1731-06 = which states:



"Internet-Drafts are draft = documents valid for a

maximum of six months

and may be updated, replaced, or = obsoleted by other

documents at any

time. It is inappropriate to use = Internet-Drafts as

reference material

or to cite them other than as = "work in progress".



Please also note that since the = draft filename starts

with the prefix

string "draft-bhh" this clearly = identifies it to the

reader as a

document expressing the personal = technical views of

the authors and

hence hence as a document that = that does not have any

acknowledged level

of IETF consensus. =



Since the text of draft = Recommendation for G.tpoam = is

based on = an

MPLS-TP OAM protocol not designed within the = IETF

Standards = Process this

is a breach of the SG15 agreement with the IETF = as

published = in Report

of the first meeting of Working Party 3/15 = Transport

network structures

(2009-2012) (Geneva, 1 =E2=80=93 = 12 December 2008) which can

be found at

http://www.itu.int/md/T0= 9-SG15-R-0004/en





Please confirm that the ITU-T = intends to continue with

the joint work on

MPLS-TP and that the ITU-T will = align this

recommendation with the IETF =

MPLS-TP OAM design before advancing this = document

through the ITU-T

publication process. =



The MPLS Working Group would = also like to draw the

attention of ITU-T

SG15 to the IETF copyright = rules. Please see

http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Pol= icy-

20091228.htm =

for further details. =



Since this draft Recommendation = contains text in which

the ITU-T SG15

has proposed making changes to = IETF protocols without

the approval of

the IETF, the MPLS Working Group = have referred this

liaison to the IAB

for their consideration. =







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

_______________________________________________ =

mpls mailing list =

mpls@ietf.org =

https://www.ietf.org/m= ailman/listinfo/mpls













_______________________________________________

mpls-tp mailing = list

mpls-tp@ietf.org

=
https://www.ietf.or= g/mailman/listinfo/mpls-tp









_______________= ________________________________

mpls-tp mailing list

mpls-tp@ietf.org

https://www.ietf.or= g/mailman/listinfo/mpls-tp

____________________________________= ___________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


= --Apple-Mail-138-971899564-- --Apple-Mail-139-971899664 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNL4JiAAoJEGmx2Mt/+Iw/HqcH/0tFTxLD8N3m8kbgIEMCSRYb rt+PiDVxcRXHJnS/bzbaSDjwNPkNxgOVUsSTOCvWfoqXnqEJVLBZT/LPVtW5RIuA ExfQZ4XxoFUvUWasKpxH6F0icWhDlUwZJ0KBe/P8qnj7+i0RrpgdM2apjTn81XS5 WEfTCMBFB2dueE2OSdpa0HwvAhQppUV7wzz76+J8tEc6JH2YBBRmIfjdYJfYNXUJ GwLR5tAPMKWMwT+hITjWSzfs8/isCmF8EC0RXlM84llNPzzjM3aZjaSF/cVXaz1e kOfjA2CNDX3DYgb2HXQpxpmF0gjRa7iKMK+wOgoiHOFxABgZy3oY5dB70OKXvqs= =edM8 -----END PGP SIGNATURE----- --Apple-Mail-139-971899664-- From erminio.ottone_69@libero.it Thu Jan 13 14:55:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C8C3A6C0D for ; Thu, 13 Jan 2011 14:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg7DwRvZQsLU for ; Thu, 13 Jan 2011 14:55:22 -0800 (PST) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by core3.amsl.com (Postfix) with ESMTP id EC2C23A6BED for ; Thu, 13 Jan 2011 14:55:21 -0800 (PST) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4D2F833A.0014,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail62 (172.31.0.59) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D10BF990165317A; Thu, 13 Jan 2011 23:56:57 +0100 Message-ID: <15285602.971221294959417963.JavaMail.defaultUser@defaultHost> Date: Thu, 13 Jan 2011 23:56:57 +0100 (CET) From: "erminio.ottone_69@libero.it" To: , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.30.163.233 Subject: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:55:23 -0000 I do not support sending this LS in its current form. The LS is currently stating that the IETF is not committed to deliver to IT= U-T=20 what it was promised in the JWT agreement. What is the real concern the LS is trying to resolve? The fact that the=20 document is not based on an IETF RFC? >----Messaggio originale---- >Da: stbryant@cisco.com >Data: 10-gen-2011 11.56 >A: "mpls@ietf.org" >Ogg: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref= =09 043.02] > >I propose to send the following Liaison Response to the ITU-T on Friday=20 >14th January and am posting it to the MPLS WG list for review. > >=3D=3D=3D=3D=3D=3D=3D > >Response to Updated draft Recommendation G.tpoam [Ref 043.02] > >From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org >CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com >stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org >yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com >ghani.abbas@ericsson.com, hhelvoort@huawei.com >malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com > >For Action > >The MPLS Working Group notes that this document contains text describing= =20 >MPLS-TP OAM protocols not designed and standardized using the IETF=20 >Standards process. Specifically it uses material from=20 >draft-bhh-mpls-tp-oam-y1731-06. > >We wish to draw your attention to the status section of=20 >draft-bhh-mpls-tp-oam-y1731-06 which states: > >"Internet-Drafts are draft documents valid for a maximum of six months=20 >and may be updated, replaced, or obsoleted by other documents at any=20 >time. It is inappropriate to use Internet-Drafts as reference material=20 >or to cite them other than as "work in progress". > >Please also note that since the draft filename starts with the prefix=20 >string "draft-bhh" this clearly identifies it to the reader as a=20 >document expressing the personal technical views of the authors and=20 >hence hence as a document that that does not have any acknowledged level= =20 >of IETF consensus. > >Since the text of draft Recommendation for G.tpoam is based on an=20 >MPLS-TP OAM protocol not designed within the IETF Standards Process this= =20 >is a breach of the SG15 agreement with the IETF as published in Report=20 >of the first meeting of Working Party 3/15 Transport network structures=20 >(2009-2012) (Geneva, 1 =E2=80=93 12 December 2008) which can be found at= =20 >http://www.itu.int/md/T09-SG15-R-0004/en > >Please confirm that the ITU-T intends to continue with the joint work on= =20 >MPLS-TP and that the ITU-T will align this recommendation with the IETF=20 >MPLS-TP OAM design before advancing this document through the ITU-T=20 >publication process. > >The MPLS Working Group would also like to draw the attention of ITU-T=20 >SG15 to the IETF copyright rules. Please see=20 >http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- 20091228.htm=20 >for further details. > >Since this draft Recommendation contains text in which the ITU-T SG15=20 >has proposed making changes to IETF protocols without the approval of=20 >the IETF, the MPLS Working Group have referred this liaison to the IAB=20 >for their consideration. > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Thu Jan 13 14:58:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BCC3A6C0D; Thu, 13 Jan 2011 14:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np24r9CxuIkw; Thu, 13 Jan 2011 14:58:21 -0800 (PST) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by core3.amsl.com (Postfix) with ESMTP id 6DFAE3A6BED; Thu, 13 Jan 2011 14:58:20 -0800 (PST) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4D2F8400.0151,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail62 (172.31.0.59) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D10BF99016537E4; Fri, 14 Jan 2011 00:00:16 +0100 Message-ID: <24506674.971481294959616690.JavaMail.defaultUser@defaultHost> Date: Fri, 14 Jan 2011 00:00:16 +0100 (CET) From: "erminio.ottone_69@libero.it" To: , ext HUANG Feng F , , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.30.163.233 Cc: mpls-tp@ietf.org Subject: [mpls] R: Re: [mpls-tp] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:58:23 -0000 You forget that ITU-T experts have not been allowed to speak at IETF 79 and= a=20 new trend of approving RFCs without resolving ITU-T have been started. >----Messaggio originale---- >Da: nurit.sprecher@nsn.com >Data: 13-gen-2011 13.54 >A: "ext HUANG Feng F", , >Cc: >Ogg: Re: [mpls-tp] [mpls] Draft: Response to Updated draft=09Recommendatio= n G. tpoam[Ref043.02] > >Hi Feng, >=09You say " HF> I can't image the meaning of cooperation is that ITU-T do= =20 nothing and just obey IETF's process!" >It seems that you are not familiar with the agreement on the joint work. T= he=20 ITU-T experts are called to contribute to (also by the SG15) to assist in t= he=20 development the development of the protocol in the IETF using the IETF stan= dard=20 processes... >Best regards, >Nurit > > >-----Original Message----- >From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]=20 >Sent: Thursday, January 13, 2011 12:31 PM >To: Sprecher, > Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org >Cc: mpls-tp@ietf.org >Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoa= m [Ref043.02] > >Hi, Nurit, > Please see in line. >B.R. >Feng >=20 > >-----Original Message----- >From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprecher@nsn. com]=20 >Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 17:45 >To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org >Cc: mpls-tp@ietf.org >Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoa= m [Ref043.02] > >Hi Feng, >I did not refer to specific solution, validity and acceptance of a solutio= n,=20 so I cannot see to what you disagree and how your response fit to mine.=20 >If you think that you have a good solution which is proven and supported= =20 please discuss it in the IETF and try to get support for it!=20 > >HF> The solution has been submitted to ietf for 2 year! > >I would like the ITU-T to continue with its collaborative agreement with t= he=20 IETF and ensure that the development of the protocol is done as agreed and= =20 supported by SG15 using the IETF processes. > >HF> I can't image the meaning of cooperation is that ITU-T do nothing and= =20 just obey IETF's process! > >I will support a single global solution interoperable solution (whatever t= he=20 solution is).=20 >Best regards, >Nurit > >-----Original Message----- >From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] >Sent: Thursday, January 13, 2011 11:35 AM >To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf= . org >Cc: mpls-tp@ietf.org >Subject: RE: [mpls] Draft: Response to Updated draft Recommendation G.tpoa= m [Ref043.02] > >Hi,Nurit, > I can't agree with you. > Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet Transp= ort=20 Network by many applications and public demo and it has many supporters. I = am=20 wondering why this solutions is not standardized in ietf?=20 > Further more, I really don't agree with your last sentence, this=20 solution is asked by customers in Industry, you can see at least 7 provider= s in=20 global support this solution. > >B.R. >Feng > > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of=20 Sprecher, Nurit (NSN - IL/Hod HaSharon) >Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 16:18 >To: stbryant@cisco.com; mpls@ietf.org >Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoa= m [Ref043.02] > >Hi, >I support the proposal. >We have a cooperative agreement with the ITU-T concerning the work on MPLS= - TP.=20 >The agreement recognizes the design authority of the IETF for MPLS and it = is=20 agreed that the development of the protocol should be done in the IETF usin= g=20 the IETF processes. The ITU-T should not take any uncoordinated action in t= he=20 development of the MPLS_TP protocol.=20 >We would appreciate if the ITU-T continues (as it committed to) with the= =20 collaborative work with the IETF on MPLS_TP and contributes from its expert= ise=20 to the development of the protocol using the IETF processes.=20 >We would also not like to see two competing solutions which may confuse th= e=20 Industry, bloat operational and capital expenses and badly affect the end= =20 customer.=20 >Best regards, >Nurit > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ex= t=20 Stewart Bryant >Sent: Monday, January 10, 2011 12:57 PM >To: mpls@ietf.org >Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam=20 [Ref043.02] > >I propose to send the following Liaison Response to the ITU-T on Friday 14= th=20 January and am posting it to the MPLS WG list for review. > >=3D=3D=3D=3D=3D=3D=3D > >Response to Updated draft Recommendation G.tpoam [Ref 043.02] > >From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org >CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco= . com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve. trowbridge@alcatel-lucent.com >ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, k= am. lam@alcatel-lucent.com > >For Action > >The MPLS Working Group notes that this document contains text describing > >MPLS-TP OAM protocols not designed and standardized using the IETF Standar= ds=20 process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. > >We wish to draw your attention to the status section of >draft-bhh-mpls-tp-oam-y1731-06 which states: > >"Internet-Drafts are draft documents valid for a maximum of six months and= =20 may be updated, replaced, or obsoleted by other documents at any time. It i= s=20 inappropriate to use Internet-Drafts as reference material or to cite them= =20 other than as "work in progress". > >Please also note that since the draft filename starts with the prefix stri= ng=20 "draft-bhh" this clearly identifies it to the reader as a document expressi= ng=20 the personal technical views of the authors and hence hence as a document t= hat=20 that does not have any acknowledged level > >of IETF consensus. > >Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP = OAM=20 protocol not designed within the IETF Standards Process this > >is a breach of the SG15 agreement with the IETF as published in Report of = the=20 first meeting of Working Party 3/15 Transport network structures >(2009-2012) (Geneva, 1 - 12 December 2008) which can be found at http://ww= w. itu.int/md/T09-SG15-R-0004/en > >Please confirm that the ITU-T intends to continue with the joint work on > >MPLS-TP and that the ITU-T will align this recommendation with the IETF MP= LS- TP OAM design before advancing this document through the ITU-T publication= =20 process. > >The MPLS Working Group would also like to draw the attention of ITU-T >SG15 to the IETF copyright rules. Please see >http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 >0091228.htm >for further details. > >Since this draft Recommendation contains text in which the ITU-T SG15 has= =20 proposed making changes to IETF protocols without the approval of the IETF,= the=20 MPLS Working Group have referred this liaison to the IAB for their=20 consideration. > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls-tp mailing list >mpls-tp@ietf.org >https://www.ietf.org/mailman/listinfo/mpls-tp > From ietf@cdl.asgaard.org Thu Jan 13 15:04:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA023A6BED for ; Thu, 13 Jan 2011 15:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pflOB5Ub26QS for ; Thu, 13 Jan 2011 15:04:49 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id 5B1573A6855 for ; Thu, 13 Jan 2011 15:04:49 -0800 (PST) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id E4427A09555; Thu, 13 Jan 2011 23:07:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-145-972727639" From: Christopher LILJENSTOLPE In-Reply-To: <15285602.971221294959417963.JavaMail.defaultUser@defaultHost> Date: Fri, 14 Jan 2011 10:07:03 +1100 Message-Id: References: <15285602.971221294959417963.JavaMail.defaultUser@defaultHost> To: "erminio.ottone_69@libero.it" Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: "mpls@ietf.org" , stbryant@cisco.com Subject: Re: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:04:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-145-972727639 Content-Type: multipart/alternative; boundary=Apple-Mail-144-972727576 --Apple-Mail-144-972727576 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Erminio, I don't agree with your statement. It is a statement that = identifies that the ITU-T did not follow the JWT agreement between the = IETF and the ITU-T, nor internal ITU-T and IETF processes. It does not = say that the IETF will not meet it's obligations under the JWT if the = request is made the correct way. It's not a "bugger off" it's a "please = work with us in the manner previously agreed and respect our process" - = is that too hard a request to make? Chris On 14Jan2011, at 09.56, erminio.ottone_69@libero.it wrote: > I do not support sending this LS in its current form. >=20 > The LS is currently stating that the IETF is not committed to deliver = to ITU-T=20 > what it was promised in the JWT agreement. >=20 > What is the real concern the LS is trying to resolve? The fact that = the=20 > document is not based on an IETF RFC? >=20 >> ----Messaggio originale---- >> Da: stbryant@cisco.com >> Data: 10-gen-2011 11.56 >> A: "mpls@ietf.org" >> Ogg: [mpls] Draft: Response to Updated draft Recommendation G.tpoam = [Ref=09 > 043.02] >>=20 >> I propose to send the following Liaison Response to the ITU-T on = Friday=20 >> 14th January and am posting it to the MPLS WG list for review. >>=20 >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> Response to Updated draft Recommendation G.tpoam [Ref 043.02] >>=20 >> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >> To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org >> CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com >> stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org >> yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com >> ghani.abbas@ericsson.com, hhelvoort@huawei.com >> malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com >>=20 >> For Action >>=20 >> The MPLS Working Group notes that this document contains text = describing=20 >> MPLS-TP OAM protocols not designed and standardized using the IETF=20 >> Standards process. Specifically it uses material from=20 >> draft-bhh-mpls-tp-oam-y1731-06. >>=20 >> We wish to draw your attention to the status section of=20 >> draft-bhh-mpls-tp-oam-y1731-06 which states: >>=20 >> "Internet-Drafts are draft documents valid for a maximum of six = months=20 >> and may be updated, replaced, or obsoleted by other documents at any=20= >> time. It is inappropriate to use Internet-Drafts as reference = material=20 >> or to cite them other than as "work in progress". >>=20 >> Please also note that since the draft filename starts with the prefix=20= >> string "draft-bhh" this clearly identifies it to the reader as a=20 >> document expressing the personal technical views of the authors and=20= >> hence hence as a document that that does not have any acknowledged = level=20 >> of IETF consensus. >>=20 >> Since the text of draft Recommendation for G.tpoam is based on an=20 >> MPLS-TP OAM protocol not designed within the IETF Standards Process = this=20 >> is a breach of the SG15 agreement with the IETF as published in = Report=20 >> of the first meeting of Working Party 3/15 Transport network = structures=20 >> (2009-2012) (Geneva, 1 =E2=80=93 12 December 2008) which can be found = at=20 >> http://www.itu.int/md/T09-SG15-R-0004/en >>=20 >> Please confirm that the ITU-T intends to continue with the joint work = on=20 >> MPLS-TP and that the ITU-T will align this recommendation with the = IETF=20 >> MPLS-TP OAM design before advancing this document through the ITU-T=20= >> publication process. >>=20 >> The MPLS Working Group would also like to draw the attention of ITU-T=20= >> SG15 to the IETF copyright rules. Please see=20 >> = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- > 20091228.htm=20 >> for further details. >>=20 >> Since this draft Recommendation contains text in which the ITU-T SG15=20= >> has proposed making changes to IETF protocols without the approval of=20= >> the IETF, the MPLS Working Group have referred this liaison to the = IAB=20 >> for their consideration. >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-144-972727576 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I don't agree with your = statement.  It is a statement that identifies that the ITU-T did = not follow the JWT agreement between the IETF and the ITU-T, nor = internal ITU-T and IETF processes.  It does not say that the IETF = will not meet it's obligations under the JWT if the request is made the = correct way.  It's not a "bugger off" it's a "please work with us = in the manner previously agreed and respect our process" - is that too = hard a request to make?

= Chris

On 14Jan2011, at 09.56, erminio.ottone_69@libero.it wrote:

043.02]

I propose to = send the following Liaison Response to the ITU-T on Friday =
14th January and am posting = it to the MPLS WG list for review.

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

Response to = Updated draft Recommendation G.tpoam [Ref = 043.02]

From: IETF = Liaison to ITU-T on MPLS stbryant@cisco.com
=
To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org
CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com
stbryant@cisco.com, adrian.farrel@huawei.com, = mpls@ietf.org
yoichi.maeda@ttc.or.jp, steve.trowbridge@alcat= el-lucent.com
ghani.abbas@ericsson.com, = hhelvoort@huawei.com
malcolm.betts@zte.com.cn, = kam.lam@alcatel-lucent.com<= br>

For Action

The MPLS = Working Group notes that this document contains text describing =
MPLS-TP OAM protocols not = designed and standardized using the IETF
Standards process. Specifically it uses material from =
draft-bhh-mpls-tp-oam-y1731-06.

We wish to draw = your attention to the status section of
draft-bhh-mpls-tp-oam-y1731-06 which = states:

"Internet-Drafts = are draft documents valid for a maximum of six months =
and may be updated, replaced, = or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as = reference material
or to cite = them other than as "work in progress".

Please also = note that since the draft filename starts with the prefix =
string "draft-bhh" this = clearly identifies it to the reader as a
document expressing the personal technical views of the = authors and
hence hence as a = document that that does not have any acknowledged level =
of IETF = consensus.

Since the text = of draft Recommendation for G.tpoam is based on an =
MPLS-TP OAM protocol not = designed within the IETF Standards Process this =
is a breach of the SG15 = agreement with the IETF as published in Report =
of the first meeting of = Working Party 3/15 Transport network structures =
(2009-2012) (Geneva, 1 =E2=80=93= 12 December 2008) which can be found at
http://www.itu.int/md/T0= 9-SG15-R-0004/en

Please confirm = that the ITU-T intends to continue with the joint work on =
MPLS-TP and that the ITU-T = will align this recommendation with the IETF =
MPLS-TP OAM design before = advancing this document through the ITU-T
publication process.

The MPLS = Working Group would also like to draw the attention of ITU-T =
SG15 to the IETF copyright = rules. Please see
http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Pol= icy-
20091228.htm
for = further details.

Since this = draft Recommendation contains text in which the ITU-T SG15 =
has proposed making changes = to IETF protocols without the approval of
the IETF, the MPLS Working Group have referred this = liaison to the IAB
for their = consideration.


=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls



___________________________________= ____________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls


= --Apple-Mail-144-972727576-- --Apple-Mail-145-972727639 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNL4WbAAoJEGmx2Mt/+Iw/OdQH/ifYhwJSwRSrYWKCZCwedhk0 AYXCfuiaY9X/UIx1wNGaZlljS9QZT9rgF20S60KXVdRPpq1iHddDSYOZghMvSHN7 DqEK1OKqvtyGXDTpcohwcOFZF1/Fpujns/CZ5LzYCW+Zk8AUtCR5Kf/WnUefolx2 iByZkD2r1KCaYVvrUIVL45D7+ATR7iYY2iF3ZwRhOWwItIC9suiswJjRT9VW9l7h ZNQ4eBZ14EtIeHg5GiGhCEulbCng+E95x5oYrT6lZvkxuaSkSSkTau9PPrORDpwS 7D8VKS4ZeS4W4rXmGGfde0tQS3O6bGycFQqx0OaTu5NViVLSwJV2oP4EACF1zbs= =yaY0 -----END PGP SIGNATURE----- --Apple-Mail-145-972727639-- From tochio@jp.fujitsu.com Thu Jan 13 15:08:21 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFEC43A6C19; Thu, 13 Jan 2011 15:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9fApTXTzUpK; Thu, 13 Jan 2011 15:08:20 -0800 (PST) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by core3.amsl.com (Postfix) with ESMTP id 5392C3A6BED; Thu, 13 Jan 2011 15:08:20 -0800 (PST) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail7.fujitsu.co.jp (Postfix) with ESMTP id 34D013EE0B5; Fri, 14 Jan 2011 08:10:43 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1D7CD2AEA8D; Fri, 14 Jan 2011 08:10:43 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id F067445DE54; Fri, 14 Jan 2011 08:10:42 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id E23EFE08001; Fri, 14 Jan 2011 08:10:42 +0900 (JST) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id A75391DB8049; Fri, 14 Jan 2011 08:10:42 +0900 (JST) Received: from vs.kawasaki.flab.fujitsu.co.jp (vs.kawasaki.flab.fujitsu.co.jp [10.25.192.38]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/100813-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id p0DNAghZ015582; Fri, 14 Jan 2011 08:10:42 +0900 (JST) X-AuditID: 0a19c026-00000005000001f8-92-4d2f867228ca Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vs.kawasaki.flab.fujitsu.co.jp (Symantec Mail Security) with ESMTP id 3FD042923D; Fri, 14 Jan 2011 08:10:42 +0900 (JST) Received: from [127.0.0.1] (dhcp98.dream.flab.fujitsu.co.jp [10.25.144.157]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/100813-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id p0DNAfkA015579; Fri, 14 Jan 2011 08:10:42 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4D2F8669.1090103@jp.fujitsu.com> Date: Fri, 14 Jan 2011 08:10:33 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mpls@ietf.org, "mpls-tp@ietf.org" References: <4D2AE56A.3060200@cisco.com> <4D2F7A4C.80304@gmail.com> In-Reply-To: <4D2F7A4C.80304@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:08:21 -0000 Hi, As to this response (G.8121), I support Huub's comment. The important is to review the draft G.8121 so that IETF should ask for the missing file at first. In that sense, the first paragraph of LS with asking for the draft (i.e. wd19r2) is enough. Of course, ITU-T should have verified that the attachment is included.... Regards, Yuji (2011/01/14 7:18), Huub van Helvoort wrote: > Hello Stewart, > > You wrote: > >> I propose to send the following Liaison Response to the ITU-T on Friday >> 14th January and am posting it to the MPLS WG list for review. > > I do not support sending the liaison as proposed. > > We should restrict it to the first paragraph noting that the file > that should be reviewed is missing and ask for sending the missing > file so it can be reviewed by the WG. > > The remainder of the text is based on assumptions and not on facts. > > Regards, Huub. > > >> ========= >> >> Response to Updated draft Recommendation G.8121 [Ref 042.02] >> >> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >> To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org >> CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com >> stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org >> yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com >> ghani.abbas@ericsson.com, hhelvoort@huawei.com >> malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com >> >> For Action >> >> Unfortunately ITU-T document WD19r2 was not attached to this liaison, >> and thus the MPLS Working Group is unable to comment on its content at >> this time. >> >> It is stated in the liaison that the modifications to this draft >> Recommendation are based on draft-bhh-mpls-tp-oam-y1731-06. Please may >> we draw your attention to the status section of >> draft-bhh-mpls-tp-oam-y1731-06 which states >> >> "Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference material >> or to cite them other than as "work in progress". >> >> Please also note that since the draft filename starts with the prefix >> string "draft-bhh" this clearly identifies it to the reader as a >> document expressing the personal technical views of the authors and >> hence hence as a document that that does not have any acknowledged level >> of IETF consensus. >> >> If this draft Recommendation for G.8121 is based on an MPLS-TP OAM >> protocol not designed within the IETF Standards Process, the MPLS >> Working Group believe that this would be in breach of the SG15 agreement >> with the IETF as published in Report of the first meeting of Working >> Party 3/15 Transport network structures (2009-2012) (Geneva, 1 – 12 >> December 2008) which can be found at >> http://www.itu.int/md/T09-SG15-R-0004/en >> >> The MPLS Working Group would also like to draw the attention of ITU-T >> SG15 to the IETF copyright rules. Please see >> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm >> for further details. >> >> We have referred this liaison to the IAB for their consideration. >> >> >> =========== >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > From cdl@asgaard.org Thu Jan 13 15:09:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03B328C0DD; Thu, 13 Jan 2011 15:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHgsm9mLP4hB; Thu, 13 Jan 2011 15:09:13 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id 8ECCA3A6BED; Thu, 13 Jan 2011 15:09:12 -0800 (PST) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id EE2EAA0956A; Thu, 13 Jan 2011 23:11:32 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-148-972993379" From: Christopher LILJENSTOLPE In-Reply-To: <24506674.971481294959616690.JavaMail.defaultUser@defaultHost> Date: Fri, 14 Jan 2011 10:11:29 +1100 Message-Id: <22AC359C-CD36-4607-87B9-1DE6329096AE@asgaard.org> References: <24506674.971481294959616690.JavaMail.defaultUser@defaultHost> To: "erminio.ottone_69@libero.it" Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: mpls@ietf.org, mpls-tp@ietf.org, ext HUANG Feng F , stbryant@cisco.com Subject: Re: [mpls] [mpls-tp] R: Re: Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:09:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-148-972993379 Content-Type: multipart/alternative; boundary=Apple-Mail-147-972993311 --Apple-Mail-147-972993311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Erminio, I was at the meeting, and I did not see anyone denied a chance = to approach the mic. I did see a pair of working group chairs struggle = to keep a working group on the previously published and agreed upon = agenda. The fact that a group of individuals wanted to dramatically = change the agenda at the beginning of the meeting would have denied the = other groups who had scheduled time from their allotted segments. = Having worked in some SG's in the ITU-T as well, I don't believe that = behavior would have been any more allowed in an ITU-T meeting, than an = IETF one (if anything, the ITU-T process probably would have shut it = down faster). =20 Christopher On 14Jan2011, at 10.00, erminio.ottone_69@libero.it wrote: > You forget that ITU-T experts have not been allowed to speak at IETF = 79 and a=20 > new trend of approving RFCs without resolving ITU-T have been started. >=20 >> ----Messaggio originale---- >> Da: nurit.sprecher@nsn.com >> Data: 13-gen-2011 13.54 >> A: "ext HUANG Feng F", = com>, >> Cc: >> Ogg: Re: [mpls-tp] [mpls] Draft: Response to Updated draft = Recommendation G. > tpoam[Ref043.02] >>=20 >> Hi Feng, >> You say " HF> I can't image the meaning of cooperation is that = ITU-T do=20 > nothing and just obey IETF's process!" >> It seems that you are not familiar with the agreement on the joint = work. The=20 > ITU-T experts are called to contribute to (also by the SG15) to assist = in the=20 > development the development of the protocol in the IETF using the IETF = standard=20 > processes... >> Best regards, >> Nurit >>=20 >>=20 >> -----Original Message----- >> From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]=20 >> Sent: Thursday, January 13, 2011 12:31 PM >> To: Sprecher, >> Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi, Nurit, >> Please see in line. >> B.R. >> Feng >>=20 >>=20 >> -----Original Message----- >> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn. > com]=20 >> Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 17:45 >> To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi Feng, >> I did not refer to specific solution, validity and acceptance of a = solution,=20 > so I cannot see to what you disagree and how your response fit to = mine.=20 >> If you think that you have a good solution which is proven and = supported=20 > please discuss it in the IETF and try to get support for it!=20 >>=20 >> HF> The solution has been submitted to ietf for 2 year! >>=20 >> I would like the ITU-T to continue with its collaborative agreement = with the=20 > IETF and ensure that the development of the protocol is done as agreed = and=20 > supported by SG15 using the IETF processes. >>=20 >> HF> I can't image the meaning of cooperation is that ITU-T do nothing = and=20 > just obey IETF's process! >>=20 >> I will support a single global solution interoperable solution = (whatever the=20 > solution is).=20 >> Best regards, >> Nurit >>=20 >> -----Original Message----- >> From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] >> Sent: Thursday, January 13, 2011 11:35 AM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; = mpls@ietf. > org >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi,Nurit, >> I can't agree with you. >> Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport=20 > Network by many applications and public demo and it has many = supporters. I am=20 > wondering why this solutions is not standardized in ietf?=20 >> Further more, I really don't agree with your last sentence, this=20= > solution is asked by customers in Industry, you can see at least 7 = providers in=20 > global support this solution. >>=20 >> B.R. >> Feng >>=20 >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of=20 > Sprecher, Nurit (NSN - IL/Hod HaSharon) >> Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 16:18 >> To: stbryant@cisco.com; mpls@ietf.org >> Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi, >> I support the proposal. >> We have a cooperative agreement with the ITU-T concerning the work on = MPLS- > TP.=20 >> The agreement recognizes the design authority of the IETF for MPLS = and it is=20 > agreed that the development of the protocol should be done in the IETF = using=20 > the IETF processes. The ITU-T should not take any uncoordinated action = in the=20 > development of the MPLS_TP protocol.=20 >> We would appreciate if the ITU-T continues (as it committed to) with = the=20 > collaborative work with the IETF on MPLS_TP and contributes from its = expertise=20 > to the development of the protocol using the IETF processes.=20 >> We would also not like to see two competing solutions which may = confuse the=20 > Industry, bloat operational and capital expenses and badly affect the = end=20 > customer.=20 >> Best regards, >> Nurit >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of ext=20 > Stewart Bryant >> Sent: Monday, January 10, 2011 12:57 PM >> To: mpls@ietf.org >> Subject: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam=20 > [Ref043.02] >>=20 >> I propose to send the following Liaison Response to the ITU-T on = Friday 14th=20 > January and am posting it to the MPLS WG list for review. >>=20 >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> Response to Updated draft Recommendation G.tpoam [Ref 043.02] >>=20 >> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >> To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org >> CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco. > com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, = steve. > trowbridge@alcatel-lucent.com >> ghani.abbas@ericsson.com, hhelvoort@huawei.com = malcolm.betts@zte.com.cn, kam. > lam@alcatel-lucent.com >>=20 >> For Action >>=20 >> The MPLS Working Group notes that this document contains text = describing >>=20 >> MPLS-TP OAM protocols not designed and standardized using the IETF = Standards=20 > process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06. >>=20 >> We wish to draw your attention to the status section of >> draft-bhh-mpls-tp-oam-y1731-06 which states: >>=20 >> "Internet-Drafts are draft documents valid for a maximum of six = months and=20 > may be updated, replaced, or obsoleted by other documents at any time. = It is=20 > inappropriate to use Internet-Drafts as reference material or to cite = them=20 > other than as "work in progress". >>=20 >> Please also note that since the draft filename starts with the prefix = string=20 > "draft-bhh" this clearly identifies it to the reader as a document = expressing=20 > the personal technical views of the authors and hence hence as a = document that=20 > that does not have any acknowledged level >>=20 >> of IETF consensus. >>=20 >> Since the text of draft Recommendation for G.tpoam is based on an = MPLS-TP OAM=20 > protocol not designed within the IETF Standards Process this >>=20 >> is a breach of the SG15 agreement with the IETF as published in = Report of the=20 > first meeting of Working Party 3/15 Transport network structures >> (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at = http://www. > itu.int/md/T09-SG15-R-0004/en >>=20 >> Please confirm that the ITU-T intends to continue with the joint work = on >>=20 >> MPLS-TP and that the ITU-T will align this recommendation with the = IETF MPLS- > TP OAM design before advancing this document through the ITU-T = publication=20 > process. >>=20 >> The MPLS Working Group would also like to draw the attention of ITU-T >> SG15 to the IETF copyright rules. Please see >> = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 >> 0091228.htm >> for further details. >>=20 >> Since this draft Recommendation contains text in which the ITU-T SG15 = has=20 > proposed making changes to IETF protocols without the approval of the = IETF, the=20 > MPLS Working Group have referred this liaison to the IAB for their=20 > consideration. >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-147-972993311 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I was at the meeting, and I did = not see anyone denied a chance to approach the mic.  I did see a = pair of working group chairs struggle to keep a working group on the = previously published and agreed upon agenda.  The fact that a group = of individuals wanted to dramatically change the agenda at the beginning = of the meeting would have denied the other groups who had scheduled time = from their allotted segments.  Having worked in some SG's in the = ITU-T as well, I don't believe that behavior would have been any more = allowed in an ITU-T meeting, than an IETF one (if anything, the ITU-T = process probably would have shut it down faster). =  

= Christopher

On 14Jan2011, at 10.00, erminio.ottone_69@libero.it wrote:

You forget that ITU-T experts have not been allowed = to speak at IETF 79 and a
new trend of approving RFCs without = resolving ITU-T have been started.

----Messaggio originale----
Da: nurit.sprecher@nsn.com
Data: 13-gen-2011 = 13.54
A: "ext HUANG Feng = F"<Feng.f.Huang@alcatel-sbe= ll.com.cn>, <stbryant@cisco.
com>, <mpls@ietf.org>
Cc: <mpls-tp@ietf.org>
=
Ogg: Re: [mpls-tp] [mpls] Draft: Response to = Updated draft = Recommendation G.
tpoam[Ref043.02]

Hi = Feng,
You say " = HF> I can't image the meaning of cooperation is that ITU-T do =
nothing and just obey IETF's process!"
It seems that you are not familiar with the agreement on = the joint work. The
ITU-T experts are called to = contribute to (also by the SG15) to assist in the
development the = development of the protocol in the IETF using the IETF standard =
processes...
Best = regards,
Nurit


-----Original = Message-----
From: ext HUANG = Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] =
Sent: Thursday, January 13, = 2011 12:31 PM
To: = Sprecher,
Nurit (NSN - IL/Hod = HaSharon); stbryant@cisco.com; = mpls@ietf.org
Cc: mpls-tp@ietf.org
Subject: RE: [mpls] Draft: Response to Updated = draft Recommendation G.tpoam
[Ref043.02]

Hi, = Nurit,
 Please see in = line.
B.R.
Feng


-----Original = Message-----
From: Sprecher, = Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn.
com]
Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 = 17:45
To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org
Cc: mpls-tp@ietf.org
Subject: RE: [mpls] Draft: Response to Updated = draft Recommendation G.tpoam
[Ref043.02]

Hi = Feng,
I did not refer to = specific solution, validity and acceptance of a solution, =
so I cannot see to what you disagree and how your = response fit to mine.
If you think that = you have a good solution which is proven and supported =
please discuss it in the IETF and try to get support = for it!

HF> The solution has been submitted to ietf for 2 = year!

I would like = the ITU-T to continue with its collaborative agreement with the =
IETF and ensure that the development of the protocol is = done as agreed and
supported by SG15 using the IETF = processes.

HF> I can't image the meaning of cooperation is that = ITU-T do nothing and
just obey IETF's = process!

I will support a single global solution interoperable = solution (whatever the
solution is).
Best regards,
Nurit

-----Original = Message-----
From: ext HUANG = Feng F = [mailto:Feng.f.Huang@alcatel-sbell.com.cn]
Sent: Thursday, January 13, 2011 11:35 = AM
To: Sprecher, Nurit (NSN - = IL/Hod HaSharon); stbryant@cisco.com; = mpls@ietf.
org
Cc: mpls-tp@ietf.org
Subject: RE: [mpls] Draft: Response to Updated = draft Recommendation G.tpoam
[Ref043.02]

Hi,Nurit,
=  I can't agree with you.
=  Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport
Network by many applications and public demo = and it has many supporters. I am
wondering why  this solutions = is not  standardized in ietf?
=   Further more,  I really don't agree with your last = sentence, this
solution is asked by customers in = Industry, you can see at least 7 providers in
global support this = solution.

B.R.
Feng


-----Original = Message-----
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of
Sprecher, = Nurit (NSN - IL/Hod HaSharon)
Sent: = 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 16:18
To: stbryant@cisco.com; mpls@ietf.org
Subject: Re: [mpls] Draft: Response to Updated draft = Recommendation G.tpoam
[Ref043.02]

Hi,
I support = the proposal.
We have a = cooperative agreement with the ITU-T concerning the work on = MPLS-
TP.
The agreement = recognizes the design authority of the IETF for MPLS and it is =
agreed that the development of the protocol should be = done in the IETF using
the IETF processes. The ITU-T should not take = any uncoordinated action in the
development of the MPLS_TP protocol. =
We would appreciate if the ITU-T continues = (as it committed to) with the
collaborative work with = the IETF on MPLS_TP and contributes from its expertise
to the = development of the protocol using the IETF processes.
We would also not like to see two competing solutions = which may confuse the
Industry, bloat operational and = capital expenses and badly affect the end
customer.
Best regards,
Nurit

-----Original = Message-----
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of ext
Stewart = Bryant
Sent: Monday, January 10, 2011 12:57 = PM
To: mpls@ietf.org
Subject: [mpls] Draft: Response to Updated draft = Recommendation G.tpoam
[Ref043.02]

I propose to = send the following Liaison Response to the ITU-T on Friday 14th =
January and am posting it to the MPLS WG list for = review.

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

Response to = Updated draft Recommendation G.tpoam [Ref = 043.02]

From: IETF = Liaison to ITU-T on MPLS stbryant@cisco.com
=
To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org
CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco.
com, adrian.farrel@huawei.com, = mpls@ietf.org yoichi.maeda@ttc.or.jp, = steve.
trowbridge@alcatel-lucent.co= m
ghani.abbas@ericsson.com, = hhelvoort@huawei.com malcolm.betts@zte.com.cn, = kam.
lam@alcatel-lucent.com

For = Action

The MPLS = Working Group notes that this document contains text = describing

MPLS-TP OAM = protocols not designed and standardized using the IETF Standards =
process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06.

We wish to draw = your attention to the status section of
draft-bhh-mpls-tp-oam-y1731-06 which = states:

"Internet-Drafts = are draft documents valid for a maximum of six months and =
may be updated, replaced, or obsoleted by other = documents at any time. It is
inappropriate to use Internet-Drafts as = reference material or to cite them
other than as "work in = progress".

Please also note that since the draft filename starts with = the prefix string
"draft-bhh" this clearly identifies = it to the reader as a document expressing
the personal technical = views of the authors and hence hence as a document that
that does = not have any acknowledged level

of IETF = consensus.

Since the text = of draft Recommendation for G.tpoam is based on an MPLS-TP OAM =
protocol not designed within the IETF Standards Process = this

is a breach of the SG15 agreement with the IETF as = published in Report of the
first meeting of Working = Party 3/15 Transport network structures
(2009-2012) (Geneva, 1 - 12 December 2008) which can be = found at = http://www.
itu.int/md/T09-SG15-R-0004/en

Please confirm = that the ITU-T intends to continue with the joint work = on

MPLS-TP and that the ITU-T will align this recommendation = with the IETF MPLS-
TP OAM design before advancing this = document through the ITU-T publication
process.

The MPLS = Working Group would also like to draw the attention of = ITU-T
SG15 to the IETF = copyright rules. Please see
http://trustee.ietf.org/license-info/archive/IETF-Trust-Lice= nse-Policy-2
0091228.htm
for = further details.

Since this = draft Recommendation contains text in which the ITU-T SG15 has =
proposed making changes to IETF protocols without the = approval of the IETF, the
MPLS Working Group have referred this = liaison to the IAB for their
consideration.


=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
<= blockquote = type=3D"cite">_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
<= blockquote = type=3D"cite">_______________________________________________
mpls-tp mailing = list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp



___________________________________= ____________
mpls-tp mailing = list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp<= br>


= --Apple-Mail-147-972993311-- --Apple-Mail-148-972993379 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNL4ahAAoJEGmx2Mt/+Iw/COwH/0T8hToAqchNcXbvj7yYVRDE rSiXmZ8pw4lEXz3U8gWVrH5iTy0IV7t3xEVzhJdgi7iAoC3uq9fJG5zia/LC5HEg n1nRcwvjZ1wdnP1lYZaW5TjXhKnt3O4bJVmm4qLzoamFTQb1eS9g/VZ9Qc0DZYRR 5ov74HYhQXv+54OJxRgg3NP5fCLEQA0qLQEk1zpJsdAIwG0xxj2PQOksd9FwzaVr bjbtyfXZnp1iOHvqzSb+jUXeGU0F8QYlG1VDn1uoXwYZtWjYkcHqhf4gp+1tsg8f ddWasjupeVr+jJqnv+K8ltAe7gIK5v7YVIi0zY9My13PVXn/MQczTYnoewVWbH4= =OxrO -----END PGP SIGNATURE----- --Apple-Mail-148-972993379-- From nurit.sprecher@nsn.com Thu Jan 13 15:10:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319CB3A6C13; Thu, 13 Jan 2011 15:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.496 X-Spam-Level: X-Spam-Status: No, score=-4.496 tagged_above=-999 required=5 tests=[AWL=1.503, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtMs-kyu2gPL; Thu, 13 Jan 2011 15:10:46 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A309A3A6C19; Thu, 13 Jan 2011 15:10:44 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0DND26l016404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Jan 2011 00:13:02 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0DND28A030108; Fri, 14 Jan 2011 00:13:02 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 00:12:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 14 Jan 2011 00:12:53 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640332E318@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [mpls-tp] Draft: Response to Updateddraft Recommendation G.tpoam [Ref043.02] Thread-Index: AcuzcdYOACJqkL8SQ1KnmKq/hzcCPgAAFzOAAACWA8A= References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se><4D2F47F9.8040701@cisco.com><4D2F7D8E.9040505@gmail.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Eric Osborne (eosborne)" , "Huub van Helvoort" , , X-OriginalArrivalTime: 13 Jan 2011 23:12:56.0270 (UTC) FILETIME=[69807EE0:01CBB377] Subject: Re: [mpls] [mpls-tp] Draft: Response to Updateddraft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:10:51 -0000 SHV1YiwNCkkgd291bGQgYWxzbyByZWNvbW1lbmQgeW91IHRvIHJlYWQgdGhlIHJlcG9ydCBvZiB0 aGUgcmFwcG9ydGV1cnMgb2YgUTksIFExMCwgUTEyIGFuZCBRMTQgZnJvbSB0aGUgQmVybGluIG1l ZXRpbmcuDQpUaGUgcmVwb3J0IGV4cGxpY2l0bHkgc2F5cyB0aGF0IHdvcmsgd2FzIHVuZGVydGFr ZW4gb24gdGhlIGRldmVsb3BtZW50IG9mIHRoZSBPQU0gcHJvdG9jb2wgRy50cG9hbSwgRy44MTIx IGFuZCBHLjgxNTEuIFRoZSBkcmFmdHMgb2YgdGhlc2UgZG9jdW1lbnRzIGFyZSBiYXNlZCBvbiBk cmFmdC1iaGgtbXBscy10cC1vYW0teTE3MzEtMDYuDQpCZXN0IHJlZ2FyZHMsDQpOdXJpdA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IEVyaWMgT3Nib3Ju ZSAoZW9zYm9ybmUpDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTI6NTIgQU0NClRv OiBIdXViIHZhbiBIZWx2b29ydDsgbXBsc0BpZXRmLm9yZzsgbXBscy10cEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFttcGxzXSBbbXBscy10cF0gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWRkcmFm dCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYwNDMuMDJdDQoNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEh1dWIgdmFuIEhlbHZv b3J0DQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDExIDU6MzMgUE0NCj4gVG86IG1w bHNAaWV0Zi5vcmc7IG1wbHMtdHBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzLXRwXSBb bXBsc10gRHJhZnQ6IFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQNCj4gUmVjb21tZW5kYXRpb24g Ry50cG9hbSBbUmVmMDQzLjAyXQ0KPiANCj4gSGVsbG8gU3Rld2FydCwNCj4gDQo+IFlvdSBhc2tl ZDoNCj4gDQo+ID4gRG9lcyBhbnlvbmUgZGlzYWdyZWUgd2l0aCB0aGUgc3RhdGVtZW50IHRoYXQg RGF2aWQgbWFrZXM/DQo+IA0KPiBJIGRpc2FncmVlIHdpdGggdGhpcyBzdGF0ZW1lbnQgaW4gcmVs YXRpb24gdG8gdGhpcyBsaWFpc29uLg0KPiANCj4gVGhlIGRyYWZ0IHJlY29tbWVuZGF0aW9uIEcu dHBvYW0gdGhhdCB3YXMgc2VudCBmb3IgcmV2aWV3IGRvZXMgbm90IGNvbnRhaW4NCj4gYSByZWZl cmVuY2UgdG8gZHJhZnQtYmhoIGF0IGFsbC4NCg0KVGhlIGxpYXNvbiBpcyBoZXJlOiBbaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzk4My9dDQphbmQgaXQgcmVmZXJlbmNlcyAi TFMyMzMgLSBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZiAwNDMuMDFd IC0gcGRmIGJvZHkiIFtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJ U09OL2ZpbGUxMTUxLnBkZl0NCndoaWNoIHNheXMNCg0KLS0tLQ0KQXQgdGhlIEJlcmxpbiBpbnRl cmltIG1lZXRpbmcgb24gTVBMUy1UUCBmdXJ0aGVyIHdvcmsgd2FzIHVuZGVydGFrZW4gb24gdGhl IGRldmVsb3BtZW50IG9mIHRoZSANCk9BTSBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtLsKgIFRoaXMg dmVyc2lvbiB3YXMgZGV2ZWxvcGVkIHVzaW5nIGFsbCBvZiB0aGUgcmVsZXZhbnQgaW5wdXQgDQpk b2N1bWVudHMgdG8gdGhlIG1lZXRpbmcgYW5kIGlzIGJhc2VkIG9uIGRyYWZ0LWJoaC1tcGxzLXRw LW9hbS15MTczMS0wNi7CoCBXZSBpbnZpdGUgeW91ciANCmNvbW1lbnRzIG9uIHRoaXMgZG9jdW1l bnQNCi0tLS0NCg0KV2hpbGUgeW91IGFyZSB0ZWNobmljYWxseSBjb3JyZWN0IHRoYXQgRy50cG9h bSBkb2VzIG5vdCBpdHNlbGYgY29udGFpbiBhIHJlZmVyZW5jZSB0byBkcmFmdC1iaGgsIGhvdyBh cmUgd2UgdG8gaW50ZXJwcmV0IHRoZSBsaWFzb24gc3RhdGVtZW50IHdoaWNoIGNsYWltcyBhIGNs ZWFyIGxpbmVhZ2UgYmV0d2VlbiBkcmFmdC1iaGggYW5kIEcudHBvYW0/DQoNCj4gQWxzbyB0aGUg c3RhdGVtZW50cyBhYm91dCB2YWxpZGl0eSBhbmQgY29weXJpZ2h0IGFyZSBpcnJlbGV2YW50Lg0K PiANCg0KQ2FuIHdlIGFzc3VtZSB0aGF0IHlvdSBhZ3JlZSB0aGV5IGFyZSBjb3JyZWN0LCByZWdh cmRsZXNzIG9mIHJlbGV2YW5jZT8NCg0KDQoNCmVyaWMNCg0KDQo+IFJlZ2FyZHMsIEh1dWIuDQo+ IA0KPiANCj4gPT09PT09PT09PT09PT0NCj4gPiBPbiAxMy8wMS8yMDExIDE3OjA5LCBEYXZpZCBT aW5pY3JvcGUgd3JvdGU6DQo+ID4+IEl0IHNlZW1zIHRoYXQgcmVmZXJlbmNlIGFuZCB1c2Ugb2Yg ZHJhZnQtYmhoIGlzIGluIHZpb2xhdGlvbiBvZiB0aGUNCj4gPj4gSVRVLVQgZXh0ZXJuYWwgY29v cGVyYXRpb24gYWdyZWVtZW50ICJSZWZlcmVuY2luZyBBLjUgUXVhbGlmaWVkDQo+ID4+IE9yZ2Fu aXphdGlvbnMiIHRleHQgZm91bmQgYXQNCj4gPj4gaHR0cDovL3d3dy5pdHUuaW50L2VuL0lUVS1U L2V4dGNvb3AvUGFnZXMvc2RvLmFzcHggdW5kZXIgdGhlDQo+ID4+IFJlZmVyZW5jaW5nIElFVEYg RG9jdW1lbnRzIGxpbmsuDQo+ID4+IEluIHBhcnRpY3VsYXIgY2xhdXNlIDEwIG9mIHRoaXMgZG9j dW1lbnQgc3RhdGVzOiAoU2VlIDJuZCBzZW50ZW5jZS4pDQo+ID4+DQo+ID4+ICIxMCBPdGhlcjog SWYgYSBzdHVkeSBncm91cCBkZWNpZGVzIHRvIG1ha2UgdGhlIHJlZmVyZW5jZSB0byBhbiBJRVRG DQo+ID4+IFJGQywgdGhlIHJlZmVyZW5jZSBzaG91bGQgYWx3YXlzIGJlIG1hZGUgYnkgUkZDIG51 bWJlciAoYW5kIG5vdCBieQ0KPiA+PiBvdGhlciBkZXNpZ25hdGlvbnMgc3VjaCBhcyBTVEQsIEJD UCwgZXRjLikuIFJlZmVyZW5jZXMgc2hvdWxkIG5vdCBiZQ0KPiA+PiBtYWRlIHRvIGRvY3VtZW50 cyByZWZlcnJlZCB0byBhcyAiSW50ZXJuZXQgRHJhZnRzIiBvciB0byBJRVRGIFJGQ3MNCj4gPj4g Y2F0ZWdvcml6ZWQgYXMgSGlzdG9yaWMgb3IgRXhwZXJpbWVudGFsLiBOb3JtYXRpdmUgcmVmZXJl bmNlcyBtdXN0DQo+ID4+IG9ubHkgYmUgbWFkZSB0byBJRVRGIFJGQ3MgdGhhdCBhcmUgU3RhbmRh cmRzIFRyYWNrIG9yIHRvDQo+ID4+IEluZm9ybWF0aW9uYWwgUkZDcyB0aGF0IGhhdmUgSUVURiBj b25zZW5zdXMuIg0KPiA+Pg0KPiA+PiBJcyB0aGlzIG5vdCBjb3JyZWN0PyBJZiBjb3JyZWN0LCBz aG91bGRuJ3QgdGhpcyBhbHNvIGJlIHBvaW50ZWQgb3V0DQo+ID4+IGluIHRoZSBsaWFpc29uPw0K PiA+PiBEYXZlDQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQo+ID4+IE9mIFN0ZXdhcnQgQnJ5YW50DQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBK YW51YXJ5IDEzLCAyMDExIDExOjI3IEFNDQo+ID4+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4+IFN1 YmplY3Q6IFJlOiBbbXBsc10gW21wbHMtdHBdIERyYWZ0OiBSZXNwb25zZSB0byBVcGRhdGVkIGRy YWZ0DQo+ID4+IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZjA0My4wMl0NCj4gPj4NCj4gPj4g RXhhY3RseSBCZW4uDQo+ID4+DQo+ID4+IFRoZSBMaWFpc29uIGlzIGxpc3Qgb2Ygc3RhdGVtZW50 cyBvZiByZWxldmFudCBmYWN0cywgYW5kIG5vbmUgb2YgdGhlDQo+ID4+IGNvbnRyYSBwb2ludHMg ZGlzcHV0ZSB0aG9zZSBmYWN0cy4NCj4gPj4NCj4gPj4gU3Rld2FydA0KPiA+Pg0KPiA+PiBPbiAx My8wMS8yMDExIDE1OjQxLCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZToNCj4gPj4+IExhcnJ5LA0K PiA+Pj4NCj4gPj4+IE9uIDEzIEphbiAyMDExLCBhdCAxNDo1NSwgTGFycnkgd3JvdGU6DQo+ID4+ Pg0KPiA+Pj4+IEhpLA0KPiA+Pj4+DQo+ID4+Pj4gSSBkb24ndCB0aGluayBpdCBpcyBwcm9wZXIg dG8gc2VuZCB0aGUgTFMgdG8gSVRVLVQgYmVjYXVzZSB0aGUgdGV4dA0KPiA+Pj4+IGRvZXNuJ3Qg cmVmbGVjdCB0aGUgcmVxdWlyZW1lbnQgZnJvbSBwcm92aWRlcnMuDQo+ID4+Pj4gQXBwYXJlbnRs eSwgZHJhZnQtYmhoIGJhc2VkIE9BTSBpcyB0aGUgbW9zdCBtYXR1cmUgc29sdXRpb24NCj4gPj4+ PiBjdXJyZW50bHkuIEl0IGhhcyBiZWVuIHByb3ZlZCBieSBtb3JlIHRoYW4gMjAwLDAwMCBhcHBs aWNhdGlvbnMgYW5kDQo+ID4+Pj4gaXMgc3VwcG9ydGVkIGJ5IGEgbG90IG9mIG9wZXJhdG9ycyBh bmQgdmVuZG9ycy4NCj4gPj4+Pg0KPiA+Pj4gVGhhdCBtYXkgb3IgbWF5IG5vdCBiZSB0cnVlLCBi dXQgZWl0aGVyIHdheSBpdCBpcyBpcnJlbGV2YW50IHRvIHRoZQ0KPiA+Pj4gbGlhaXNvbi4NCj4g Pj4+DQo+ID4+PiBJVFUgbGlhaXNlZCBHLnRwb2FtIHRvIElFVEYuIFRoZSBsaWFpc29uIHJlc3Bv bnNlIFN0ZXdhcnQgaGFzDQo+ID4+PiBkcmFmdGVkIHBvaW50cyBvdXQgdGhhdCBHLnRwb2FtIHVz ZXMgdGVjaG5vbG9neSAoZHJhZnQtYmhoKSB0aGF0IGlzDQo+ID4+PiBub3QgZW5kb3JzZWQgYnkg SUVURiBjb25zZW5zdXMgYW5kIHBvaW50cyB0byBzb21lIHJpc2tzIG9mIGRvaW5nIHNvLA0KPiA+ Pj4gaW5jbHVkaW5nIGJyZWFjaCBvZiBhIHByaW9yIElUVS1JRVRGIGFncmVlbWVudCBvbiBob3cg dG8gcHJvZ3Jlc3MNCj4gPj4+IE1QTFMtVFAgZGV2ZWxvcG1lbnQuDQo+ID4+Pg0KPiA+Pj4gRXZl cnl0aGluZyBpbiB0aGUgbGlhaXNvbiBpcyBmYWN0LiBXaGV0aGVyIGRyYWZ0LWJoaCBpcw0KPiA+ Pj4gZ29vZC9iYWQvdWdseSwgZGVwbG95ZWQsIHN1cHBvcnRlZCBieSBvcGVyYXRvcnMsIGV0Yy4g aXMgaXJyZWxldmFudCwNCj4gPj4+IGl0IGlzIG5vdCBlbmRvcnNlZCBieSBJRVRGIGFzIGEgTVBM Uy1UUCBPQU0gc29sdXRpb24gYW5kIGFsbCB0aGUNCj4gPj4+IGxpYWlzb24gZG9lcyBpcyBwb2lu dCBvdXQgdGhhdCBmYWN0Lg0KPiA+Pj4NCj4gPj4+IEZXSVcgdGhpcyBpc24ndCB0aGUgZmlyc3Qg dGltZSBhIGdyb3VwIG9mIG9wZXJhdG9ycyBoYXZlIGJyb3VnaHQgYQ0KPiA+Pj4gcHJvcG9zYWwg dG8gSUVURiBvbmx5IHRvIGZpbmQgdGhhdCB0aGUgSUVURiBoYXMgZGVjaWRlZCB0byBkbw0KPiA+ Pj4gc29tZXRoaW5nIGVsc2UsIGFuZCBJJ20gc3VyZSBpdCB3b24ndCBiZSB0aGUgbGFzdC4NCj4g Pj4+DQo+ID4+PiBCZW4NCj4gPj4+DQo+ID4+PiBQLlMuIGZvciBzb21lIHJlYXNvbiBlbWFpbCBj aGFpbnMgcmVsYXRlZCB0byBkcmFmdC1iaGggcmVtaW5kIG1lIG9mDQo+ID4+PiB0aGlzIERpbGJl cnQgY2FydG9vbiBodHRwOi8vd3d3LmRpbGJlcnQuY29tLzIwMTAtMTItMjIvDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+DQo+ID4+Pj4gSGFuIExpDQo+ ID4+Pj4NCj4gPj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+Pj4gKioNCj4gPj4+PiAqKioqDQo+ID4+Pj4g SGFuIExpLCBQaC5EDQo+ID4+Pj4gQ2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0ZQ0KPiA+ Pj4+IFVuaXQgMiwgMjggWHVhbnd1bWVueGkgQXZlLCBYdWFud3UgRGlzdHJpY3QsIEJlaWppbmcg MTAwMDUzLCBDaGluYQ0KPiA+Pj4+IEZheDogKzg2IDEwIDYzNjAxMDg3DQo+ID4+Pj4gTU9CSUxF OiAxMzUwMTA5MzM4NQ0KPiA+Pj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4+PiAqKg0KPiA+Pj4+ICoqKioN Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tIDEx5bm0MeaciDEz5pel77yM5ZGo5ZubLA0KPiA+ Pj4+IHJ1aXF1YW4uamluZ0B0aWVzLml0dS5pbnQ8cnVpcXVhbi5qaW5nQHRpZXMuaXR1LmludD4N Cj4gPj4+PiDlhpnpgZPvvJoNCj4gPj4+Pg0KPiA+Pj4+PiDlj5Hku7bkuro6IHJ1aXF1YW4uamlu Z0B0aWVzLml0dS5pbnQ8cnVpcXVhbi5qaW5nQHRpZXMuaXR1LmludD4NCj4gPj4+Pj4g5Li76aKY OiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdA0K PiA+Pj4+PiBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYwNDMuMDJdDQo+ID4+Pj4+IOaUtuS7 tuS6ujogamluZ3JAdGllcy5pdHUuY2gNCj4gPj4+Pj4g5oqE6YCBOiBtcGxzLXRwQGlldGYub3Jn DQo+ID4+Pj4+IOaXpeacnzogMjAxMeW5tDHmnIgxM+aXpSzlkajlm5ss5LiL5Y2INDowOQ0KPiA+ Pj4+PiBSZXNlbmQgdG8gbXBscy10cCBsaXN0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBRdW90aW5nIGpp bmdyQHRpZXMuaXR1LmNoOg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gSGkgU3Rld2FydCBCcnlhbnQsDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBkb27igJl0IGFncmVlIHdpdGggdGhlIGN1cnJlbnQgTFMgdGV4 dC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBDaGluYSBUZWxlY29tIHN1cHBvcnQgdGhlIHN0YW5kYXJk aXphdGlvbiBvZiBZLjE3MzENCj4gPj4+Pj4gYmFzZWQgTVBMUy1UUCBPQU0gdG9vbHMNCj4gPj4+ Pj4+IGluDQo+ID4+Pj4+PiB0aGUgSVRVLVQgdG8gbWVldCB0aGUgdXJnZW50IGFuZCBpbmNyZWFz aW5nDQo+ID4+Pj4+IHJlcXVpcmVtZW50cyBmb3IgUFROIGRlcGxveW1lbnQuDQo+ID4+Pj4+PiBJ dOKAmXMgYSBtdWx0aS12ZW5kb3Igc3VwcG9ydGVkLCBpbnRlcm9wZXJhYmlsaXR5DQo+ID4+Pj4+ IGNlcnRpZmljYXRlZCBhbmQgZmVhc2libGUNCj4gPj4+Pj4+IHNvbHV0aW9uLiBJdCBoYWQgYmVl biBzcGVjaWZpZWQgaW4gYm90aCBDQ1NBDQo+ID4+Pj4+IChDaGluYSBDb21tdW5pY2F0aW9ucyBT dGFuZGFyZHMNCj4gPj4+Pj4+IEFzc29jaWF0aW9uKSBhbmQgQ2hpbmEgVGVsZWNvbeKAmXMgUFRO IHN0YW5kYXJkIGFzIHRoZQ0KPiA+Pj4+PiBvbmx5IHN0YW5kYXJkIE9BTQ0KPiA+Pj4+Pj4gbWVj aGFuaXNtLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQmVzdCBSZWdh cmRzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSmluZyBSdWlxdWFuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g Q2hpbmHjgIBUZWxlY29tIEJlaWppbmcNCj4gPj4+Pj4gUmVzZWFyY2jjgIBJbnN0aXR1dGUNCj4g Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+IC0tDQo+ID4+Pj4+IC0tLS0tLS0tLS0NCj4gPj4+Pj4g LS0NCj4gPj4+Pj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4+PiBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCj4gPj4+Pj4gT24gQmVoYWxmIE9mDQo+ID4+Pj4+PiBT dGV3YXJ0DQo+ID4+Pj4+PiBCcnlhbnQNCj4gPj4+Pj4+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAx MCwgMjAxMSA2OjU3IFBNDQo+ID4+Pj4+PiBUbzogbXBsc0BpZXRmLm9yZw0KPiA+Pj4+Pj4gU3Vi amVjdDogW21wbHNdIERyYWZ0OiBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0DQo+ID4+Pj4+IFJl Y29tbWVuZGF0aW9uIEcudHBvYW0NCj4gPj4+Pj4+IFtSZWYwNDMuMDJdDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IEkgcHJvcG9zZSB0byBzZW5kIHRoZSBmb2xsb3dpbmcgTGlhaXNvbiBS ZXNwb25zZSB0bw0KPiA+Pj4+PiB0aGUgSVRVLVQgb24gRnJpZGF5DQo+ID4+Pj4+PiAxNHRoIEph bnVhcnkgYW5kIGFtIHBvc3RpbmcgaXQgdG8gdGhlIE1QTFMgV0cgbGlzdCBmb3INCj4gPj4+Pj4g cmV2aWV3Lg0KPiA+Pj4+Pj4gPT09PT09PQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFJlc3BvbnNlIHRv IFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmDQo+ID4+Pj4+IDA0My4w Ml0NCj4gPj4+Pj4+IEZyb206IElFVEYgTGlhaXNvbiB0byBJVFUtVCBvbiBNUExTIHN0YnJ5YW50 QGNpc2NvLmNvbQ0KPiA+Pj4+Pj4gVG86IHRzYnNnMTVAaXR1LmludCwNCj4gPj4+Pj4gZ3JlZy5q b25lc0BpdHUuaW50LA0KPiA+Pj4+PiBoaXJvc2hpLm90YUBpdHUuaW50LA0KPiA+Pj4+PiBJQUJA aWV0Zi5vcmcNCj4gPj4+Pj4+IENDOiBHcmVnIEpvbmVzLCBzd2FsbG93QGNpc2NvLmNvbSwNCj4g Pj4+Pj4gbG9hQHBpLm51LCBwYWZAY2lzY28uY29tDQo+ID4+Pj4+PiBzdGJyeWFudEBjaXNjby5j b20sDQo+ID4+Pj4+IGFkcmlhbi5mYXJyZWxAaHVhd2VpLmNvbSwNCj4gPj4+Pj4gbXBsc0BpZXRm Lm9yZw0KPiA+Pj4+Pj4geW9pY2hpLm1hZWRhQHR0Yy5vci5qcCwNCj4gPj4+Pj4gc3RldmUudHJv d2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb20NCj4gPj4+Pj4NCj4gPj4+Pj4+IGdoYW5pLmFiYmFz QGVyaWNzc29uLmNvbSwNCj4gPj4+Pj4gaGhlbHZvb3J0QGh1YXdlaS5jb20NCj4gPj4+Pj4NCj4g Pj4+Pj4+IG1hbGNvbG0uYmV0dHNAenRlLmNvbS5jbiwNCj4gPj4+Pj4ga2FtLmxhbUBhbGNhdGVs LWx1Y2VudC5jb20NCj4gPj4+Pj4NCj4gPj4+Pj4+IEZvciBBY3Rpb24NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBUaGUgTVBMUyBXb3JraW5nIEdyb3VwIG5vdGVzIHRoYXQgdGhpcyBkb2N1bWVudA0KPiA+ Pj4+PiBjb250YWlucyB0ZXh0IGRlc2NyaWJpbmcNCj4gPj4+Pj4+IE1QTFMtVFAgT0FNIHByb3Rv Y29scyBub3QgZGVzaWduZWQgYW5kIHN0YW5kYXJkaXplZA0KPiA+Pj4+PiB1c2luZyB0aGUgSUVU Rg0KPiA+Pj4+Pj4gU3RhbmRhcmRzIHByb2Nlc3MuIFNwZWNpZmljYWxseSBpdCB1c2VzIG1hdGVy aWFsIGZyb20NCj4gPj4+Pj4+IGRyYWZ0LWJoaC1tcGxzLXRwLW9hbS15MTczMS0wNi4NCj4gPj4+ Pj4+DQo+ID4+Pj4+PiBXZSB3aXNoIHRvIGRyYXcgeW91ciBhdHRlbnRpb24gdG8gdGhlIHN0YXR1 cyBzZWN0aW9uDQo+ID4+Pj4+IG9mDQo+ID4+Pj4+PiBkcmFmdC1iaGgtbXBscy10cC1vYW0teTE3 MzEtMDYgd2hpY2ggc3RhdGVzOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICJJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYQ0KPiA+Pj4+PiBtYXhpbXVtIG9mIHNpeCBt b250aHMNCj4gPj4+Pj4+IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlcg0KPiA+Pj4+PiBkb2N1bWVudHMgYXQgYW55DQo+ID4+Pj4+PiB0aW1lLiBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMNCj4gPj4+Pj4gcmVmZXJl bmNlIG1hdGVyaWFsDQo+ID4+Pj4+PiBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29y ayBpbiBwcm9ncmVzcyIuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUGxlYXNlIGFsc28gbm90ZSB0aGF0 IHNpbmNlIHRoZSBkcmFmdCBmaWxlbmFtZSBzdGFydHMNCj4gPj4+Pj4gd2l0aCB0aGUgcHJlZml4 DQo+ID4+Pj4+PiBzdHJpbmcgImRyYWZ0LWJoaCIgdGhpcyBjbGVhcmx5IGlkZW50aWZpZXMgaXQg dG8gdGhlDQo+ID4+Pj4+IHJlYWRlciBhcyBhDQo+ID4+Pj4+PiBkb2N1bWVudCBleHByZXNzaW5n IHRoZSBwZXJzb25hbCB0ZWNobmljYWwgdmlld3Mgb2YNCj4gPj4+Pj4gdGhlIGF1dGhvcnMgYW5k DQo+ID4+Pj4+PiBoZW5jZSBoZW5jZSBhcyBhIGRvY3VtZW50IHRoYXQgdGhhdCBkb2VzIG5vdCBo YXZlIGFueQ0KPiA+Pj4+PiBhY2tub3dsZWRnZWQgbGV2ZWwNCj4gPj4+Pj4+IG9mIElFVEYgY29u c2Vuc3VzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNpbmNlIHRoZSB0ZXh0IG9mIGRyYWZ0IFJlY29t bWVuZGF0aW9uIGZvciBHLnRwb2FtIGlzDQo+ID4+Pj4+IGJhc2VkIG9uIGFuDQo+ID4+Pj4+PiBN UExTLVRQIE9BTSBwcm90b2NvbCBub3QgZGVzaWduZWQgd2l0aGluIHRoZSBJRVRGDQo+ID4+Pj4+ IFN0YW5kYXJkcyBQcm9jZXNzIHRoaXMNCj4gPj4+Pj4+IGlzIGEgYnJlYWNoIG9mIHRoZSBTRzE1 IGFncmVlbWVudCB3aXRoIHRoZSBJRVRGIGFzDQo+ID4+Pj4+IHB1Ymxpc2hlZCBpbiBSZXBvcnQN Cj4gPj4+Pj4+IG9mIHRoZSBmaXJzdCBtZWV0aW5nIG9mIFdvcmtpbmcgUGFydHkgMy8xNSBUcmFu c3BvcnQNCj4gPj4+Pj4gbmV0d29yayBzdHJ1Y3R1cmVzDQo+ID4+Pj4+PiAoMjAwOS0yMDEyKSAo R2VuZXZhLCAxIOKAkyAxMiBEZWNlbWJlciAyMDA4KSB3aGljaCBjYW4NCj4gPj4+Pj4gYmUgZm91 bmQgYXQNCj4gPj4+Pj4+IGh0dHA6Ly93d3cuaXR1LmludC9tZC9UMDktU0cxNS1SLTAwMDQvZW4N Cj4gPj4+Pj4+IFBsZWFzZSBjb25maXJtIHRoYXQgdGhlIElUVS1UIGludGVuZHMgdG8gY29udGlu dWUgd2l0aA0KPiA+Pj4+PiB0aGUgam9pbnQgd29yayBvbg0KPiA+Pj4+Pj4gTVBMUy1UUCBhbmQg dGhhdCB0aGUgSVRVLVQgd2lsbCBhbGlnbiB0aGlzDQo+ID4+Pj4+IHJlY29tbWVuZGF0aW9uIHdp dGggdGhlIElFVEYNCj4gPj4+Pj4+IE1QTFMtVFAgT0FNIGRlc2lnbiBiZWZvcmUgYWR2YW5jaW5n IHRoaXMgZG9jdW1lbnQNCj4gPj4+Pj4gdGhyb3VnaCB0aGUgSVRVLVQNCj4gPj4+Pj4+IHB1Ymxp Y2F0aW9uIHByb2Nlc3MuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIE1QTFMgV29ya2luZyBHcm91 cCB3b3VsZCBhbHNvIGxpa2UgdG8gZHJhdyB0aGUNCj4gPj4+Pj4gYXR0ZW50aW9uIG9mIElUVS1U DQo+ID4+Pj4+PiBTRzE1IHRvIHRoZSBJRVRGIGNvcHlyaWdodCBydWxlcy4gUGxlYXNlIHNlZQ0K PiA+Pj4+Pj4gaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvL2FyY2hpdmUvSUVU Ri1UcnVzdC1MaWNlbnNlLVANCj4gPj4+Pj4+IG9sDQo+ID4+Pj4+PiBpY3ktDQo+ID4+Pj4+PiAy MDA5MTIyOC5odG0NCj4gPj4+Pj4+IGZvciBmdXJ0aGVyIGRldGFpbHMuDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gU2luY2UgdGhpcyBkcmFmdCBSZWNvbW1lbmRhdGlvbiBjb250YWlucyB0ZXh0IGluIHdo aWNoDQo+ID4+Pj4+IHRoZSBJVFUtVCBTRzE1DQo+ID4+Pj4+PiBoYXMgcHJvcG9zZWQgbWFraW5n IGNoYW5nZXMgdG8gSUVURiBwcm90b2NvbHMgd2l0aG91dA0KPiA+Pj4+PiB0aGUgYXBwcm92YWwg b2YNCj4gPj4+Pj4+IHRoZSBJRVRGLCB0aGUgTVBMUyBXb3JraW5nIEdyb3VwIGhhdmUgcmVmZXJy ZWQgdGhpcw0KPiA+Pj4+PiBsaWFpc29uIHRvIHRoZSBJQUINCj4gPj4+Pj4+IGZvciB0aGVpciBj b25zaWRlcmF0aW9uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gPT09 PT09PT09DQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+IG1wbHNAaWV0Zi5v cmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K PiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBtcGxzLXRwIG1h aWxpbmcgbGlzdA0KPiA+Pj4+PiBtcGxzLXRwQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ PiBtcGxzLXRwIG1haWxpbmcgbGlzdA0KPiA+Pj4+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCj4gPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBtcGxzIG1h aWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+DQo+ID4+IC0tDQo+ID4+IEZvciBjb3Jwb3Jh dGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQo+ID4+DQo+ID4+IGh0dHA6Ly93d3cuY2lzY28u Y29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KPiA+Pg0K PiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+PiBtcGxzQGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+DQo+ID4NCj4gDQo+IA0K PiAtLQ0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAg5oiR54ix5aSW54K55LiA5LiD5LiJ5LiADQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFpbGluZyBsaXN0 DQo+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzLXRwDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From cdl@asgaard.org Thu Jan 13 15:14:34 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC32B3A6C11; Thu, 13 Jan 2011 15:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFwgt29tWSg8; Thu, 13 Jan 2011 15:14:33 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id 032A23A6C10; Thu, 13 Jan 2011 15:14:33 -0800 (PST) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id 2BB3DA0958E; Thu, 13 Jan 2011 23:16:54 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Christopher LILJENSTOLPE In-Reply-To: <24506674.971481294959616690.JavaMail.defaultUser@defaultHost> Resent-From: Christopher LILJENSTOLPE Date: Fri, 14 Jan 2011 10:11:29 +1100 Content-Transfer-Encoding: quoted-printable Resent-Date: Fri, 14 Jan 2011 10:16:54 +1100 Resent-To: mpls@ietf.org, mpls-tp@ietf.org References: <24506674.971481294959616690.JavaMail.defaultUser@defaultHost> Message-Id: <22AC359C-CD36-4607-87B9-1DE6329096AE@asgaard.org> To: "erminio.ottone_69@libero.it" X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Resent-Message-Id: <20110113231655.2BB3DA0958E@asgaard.org> Cc: "mpls@ietf.org, mpls-tp@ietf.org, ext HUANG Feng F , stbryant@cisco.com" Subject: Re: [mpls] [mpls-tp] R: Re: Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:14:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erminio, I was at the meeting, and I did not see anyone denied a chance = to approach the mic. I did see a pair of working group chairs struggle = to keep a working group on the previously published and agreed upon = agenda. The fact that a group of individuals wanted to dramatically = change the agenda at the beginning of the meeting would have denied the = other groups who had scheduled time from their allotted segments. = Having worked in some SG's in the ITU-T as well, I don't believe that = behavior would have been any more allowed in an ITU-T meeting, than an = IETF one (if anything, the ITU-T process probably would have shut it = down faster). =20 Christopher On 14Jan2011, at 10.00, erminio.ottone_69@libero.it wrote: > You forget that ITU-T experts have not been allowed to speak at IETF = 79 and a=20 > new trend of approving RFCs without resolving ITU-T have been started. >=20 >> ----Messaggio originale---- >> Da: nurit.sprecher@nsn.com >> Data: 13-gen-2011 13.54 >> A: "ext HUANG Feng F", = com>, >> Cc: >> Ogg: Re: [mpls-tp] [mpls] Draft: Response to Updated draft = Recommendation G. > tpoam[Ref043.02] >>=20 >> Hi Feng, >> You say " HF> I can't image the meaning of cooperation is that = ITU-T do=20 > nothing and just obey IETF's process!" >> It seems that you are not familiar with the agreement on the joint = work. The=20 > ITU-T experts are called to contribute to (also by the SG15) to assist = in the=20 > development the development of the protocol in the IETF using the IETF = standard=20 > processes... >> Best regards, >> Nurit >>=20 >>=20 >> -----Original Message----- >> From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]=20 >> Sent: Thursday, January 13, 2011 12:31 PM >> To: Sprecher, >> Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi, Nurit, >> Please see in line. >> B.R. >> Feng >>=20 >>=20 >> -----Original Message----- >> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn. > com]=20 >> Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 17:45 >> To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi Feng, >> I did not refer to specific solution, validity and acceptance of a = solution,=20 > so I cannot see to what you disagree and how your response fit to = mine.=20 >> If you think that you have a good solution which is proven and = supported=20 > please discuss it in the IETF and try to get support for it!=20 >>=20 >> HF> The solution has been submitted to ietf for 2 year! >>=20 >> I would like the ITU-T to continue with its collaborative agreement = with the=20 > IETF and ensure that the development of the protocol is done as agreed = and=20 > supported by SG15 using the IETF processes. >>=20 >> HF> I can't image the meaning of cooperation is that ITU-T do nothing = and=20 > just obey IETF's process! >>=20 >> I will support a single global solution interoperable solution = (whatever the=20 > solution is).=20 >> Best regards, >> Nurit >>=20 >> -----Original Message----- >> From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] >> Sent: Thursday, January 13, 2011 11:35 AM >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; = mpls@ietf. > org >> Cc: mpls-tp@ietf.org >> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi,Nurit, >> I can't agree with you. >> Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport=20 > Network by many applications and public demo and it has many = supporters. I am=20 > wondering why this solutions is not standardized in ietf?=20 >> Further more, I really don't agree with your last sentence, this=20 > solution is asked by customers in Industry, you can see at least 7 = providers in=20 > global support this solution. >>=20 >> B.R. >> Feng >>=20 >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of=20 > Sprecher, Nurit (NSN - IL/Hod HaSharon) >> Sent: 2011=E5=B9=B41=E6=9C=8813=E6=97=A5 16:18 >> To: stbryant@cisco.com; mpls@ietf.org >> Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam > [Ref043.02] >>=20 >> Hi, >> I support the proposal. >> We have a cooperative agreement with the ITU-T concerning the work on = MPLS- > TP.=20 >> The agreement recognizes the design authority of the IETF for MPLS = and it is=20 > agreed that the development of the protocol should be done in the IETF = using=20 > the IETF processes. The ITU-T should not take any uncoordinated action = in the=20 > development of the MPLS_TP protocol.=20 >> We would appreciate if the ITU-T continues (as it committed to) with = the=20 > collaborative work with the IETF on MPLS_TP and contributes from its = expertise=20 > to the development of the protocol using the IETF processes.=20 >> We would also not like to see two competing solutions which may = confuse the=20 > Industry, bloat operational and capital expenses and badly affect the = end=20 > customer.=20 >> Best regards, >> Nurit >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of ext=20 > Stewart Bryant >> Sent: Monday, January 10, 2011 12:57 PM >> To: mpls@ietf.org >> Subject: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam=20 > [Ref043.02] >>=20 >> I propose to send the following Liaison Response to the ITU-T on = Friday 14th=20 > January and am posting it to the MPLS WG list for review. >>=20 >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> Response to Updated draft Recommendation G.tpoam [Ref 043.02] >>=20 >> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >> To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org >> CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco. > com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, = steve. > trowbridge@alcatel-lucent.com >> ghani.abbas@ericsson.com, hhelvoort@huawei.com = malcolm.betts@zte.com.cn, kam. > lam@alcatel-lucent.com >>=20 >> For Action >>=20 >> The MPLS Working Group notes that this document contains text = describing >>=20 >> MPLS-TP OAM protocols not designed and standardized using the IETF = Standards=20 > process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06. >>=20 >> We wish to draw your attention to the status section of >> draft-bhh-mpls-tp-oam-y1731-06 which states: >>=20 >> "Internet-Drafts are draft documents valid for a maximum of six = months and=20 > may be updated, replaced, or obsoleted by other documents at any time. = It is=20 > inappropriate to use Internet-Drafts as reference material or to cite = them=20 > other than as "work in progress". >>=20 >> Please also note that since the draft filename starts with the prefix = string=20 > "draft-bhh" this clearly identifies it to the reader as a document = expressing=20 > the personal technical views of the authors and hence hence as a = document that=20 > that does not have any acknowledged level >>=20 >> of IETF consensus. >>=20 >> Since the text of draft Recommendation for G.tpoam is based on an = MPLS-TP OAM=20 > protocol not designed within the IETF Standards Process this >>=20 >> is a breach of the SG15 agreement with the IETF as published in = Report of the=20 > first meeting of Working Party 3/15 Transport network structures >> (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at = http://www. > itu.int/md/T09-SG15-R-0004/en >>=20 >> Please confirm that the ITU-T intends to continue with the joint work = on >>=20 >> MPLS-TP and that the ITU-T will align this recommendation with the = IETF MPLS- > TP OAM design before advancing this document through the ITU-T = publication=20 > process. >>=20 >> The MPLS Working Group would also like to draw the attention of ITU-T >> SG15 to the IETF copyright rules. Please see >> = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 >> 0091228.htm >> for further details. >>=20 >> Since this draft Recommendation contains text in which the ITU-T SG15 = has=20 > proposed making changes to IETF protocols without the approval of the = IETF, the=20 > MPLS Working Group have referred this liaison to the IAB for their=20 > consideration. >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp - --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNL4fmAAoJEGmx2Mt/+Iw/GA0H/2zEtXK00w056tMi8X/VSgPH Xo8i3Q9Fk/pP5fG2UFcbUkhU8JZBcNYW2a8cu7dUna2RU5lekmiI8ymy1q6z+KXM 9fTGvdWDgHWgDt8dmG3VA3KibeEZYygrBvShjCMNYWWV5I6SU1Ll6dfg5wK/D9b1 drK+kQuXQNryVfs3tEIqRincvpiVgRr68NCzoBwtNReXQLClp1YuVaBvpBXi9tWL 0g0SjN4wLfVNe1uNXIEON8FHkU/clyVfH9bsrnk6WNDurxMmoJRr5Xbd2mSk3Ldp p+n372HfozZBnMYq40KTQS+wZPPaTy1IQgx0SE7zJHaC3igDnWA9d44TJy2E7og=3D =3DS6uo -----END PGP SIGNATURE----- From tochio@jp.fujitsu.com Thu Jan 13 15:35:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57EC3A6C13; Thu, 13 Jan 2011 15:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TReVoq9-T6z7; Thu, 13 Jan 2011 15:35:16 -0800 (PST) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by core3.amsl.com (Postfix) with ESMTP id F0EAB3A6872; Thu, 13 Jan 2011 15:35:15 -0800 (PST) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail7.fujitsu.co.jp (Postfix) with ESMTP id A2D823EE0AE; Fri, 14 Jan 2011 08:37:39 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8426345DE55; Fri, 14 Jan 2011 08:37:39 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6E83345DE54; Fri, 14 Jan 2011 08:37:39 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 639671DB804A; Fri, 14 Jan 2011 08:37:39 +0900 (JST) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 31E4B1DB804B; Fri, 14 Jan 2011 08:37:39 +0900 (JST) Received: from vs.kawasaki.flab.fujitsu.co.jp (vs.kawasaki.flab.fujitsu.co.jp [10.25.192.38]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/100813-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id p0DNbdXo018157; Fri, 14 Jan 2011 08:37:39 +0900 (JST) X-AuditID: 0a19c026-00000008000001f8-95-4d2f8cc27d74 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vs.kawasaki.flab.fujitsu.co.jp (Symantec Mail Security) with ESMTP id C55D12923D; Fri, 14 Jan 2011 08:37:38 +0900 (JST) Received: from [127.0.0.1] (dhcp98.dream.flab.fujitsu.co.jp [10.25.144.157]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/100813-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id p0DNbcqs018154; Fri, 14 Jan 2011 08:37:38 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4D2F8CA4.40402@jp.fujitsu.com> Date: Fri, 14 Jan 2011 08:37:08 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" References: <526321.56478.qm@web15605.mail.cnb.yahoo.com> <4D2F27F1.1070209@cisco.com> <6873FACCBB5DDD4D88AABD78A8E483A468CE4D0311@EUSAACMS0703.eamcs.ericsson.se><4D2F47F9.8040701@cisco.com><4D2F7D8E.9040505@gmail.com> <077E41CFFD002C4CAB7DFA4386A532640332E318@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A532640332E318@DEMUEXC014.nsn-intra.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] Draft: Response to Updateddraft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:35:18 -0000 Nurit, You should not discuss on the report of ITU-T interim meeting on this thread that is for the reviewing LS to ITU-T since the report was not sent as the part of LS233 from ITU-T. And it is noted that drafts had been developed using all of the relevant the input documents to the meeting as well. LSs from ITU-T state this point as well. Regards, Yuji (2011/01/14 8:12), Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: > Huub, > I would also recommend you to read the report of the rapporteurs of Q9, Q10, Q12 and Q14 from the Berlin meeting. > The report explicitly says that work was undertaken on the development of the OAM protocol G.tpoam, G.8121 and G.8151. The drafts of these documents are based on draft-bhh-mpls-tp-oam-y1731-06. > Best regards, > Nurit > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Eric Osborne (eosborne) > Sent: Friday, January 14, 2011 12:52 AM > To: Huub van Helvoort; mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls] [mpls-tp] Draft: Response to Updateddraft Recommendation G.tpoam [Ref043.02] > > > >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf >> Of Huub van Helvoort >> Sent: Thursday, January 13, 2011 5:33 PM >> To: mpls@ietf.org; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] [mpls] Draft: Response to Updated draft >> Recommendation G.tpoam [Ref043.02] >> >> Hello Stewart, >> >> You asked: >> >>> Does anyone disagree with the statement that David makes? >> I disagree with this statement in relation to this liaison. >> >> The draft recommendation G.tpoam that was sent for review does not contain >> a reference to draft-bhh at all. > The liason is here: [https://datatracker.ietf.org/liaison/983/] > and it references "LS233 - Updated draft Recommendation G.tpoam [Ref 043.01] - pdf body" [https://datatracker.ietf.org/documents/LIAISON/file1151.pdf] > which says > > ---- > At the Berlin interim meeting on MPLS-TP further work was undertaken on the development of the > OAM Recommendation G.tpoam. This version was developed using all of the relevant input > documents to the meeting and is based on draft-bhh-mpls-tp-oam-y1731-06. We invite your > comments on this document > ---- > > While you are technically correct that G.tpoam does not itself contain a reference to draft-bhh, how are we to interpret the liason statement which claims a clear lineage between draft-bhh and G.tpoam? > >> Also the statements about validity and copyright are irrelevant. >> > Can we assume that you agree they are correct, regardless of relevance? > > > > eric > > >> Regards, Huub. >> >> >> ============== >>> On 13/01/2011 17:09, David Sinicrope wrote: >>>> It seems that reference and use of draft-bhh is in violation of the >>>> ITU-T external cooperation agreement "Referencing A.5 Qualified >>>> Organizations" text found at >>>> http://www.itu.int/en/ITU-T/extcoop/Pages/sdo.aspx under the >>>> Referencing IETF Documents link. >>>> In particular clause 10 of this document states: (See 2nd sentence.) >>>> >>>> "10 Other: If a study group decides to make the reference to an IETF >>>> RFC, the reference should always be made by RFC number (and not by >>>> other designations such as STD, BCP, etc.). References should not be >>>> made to documents referred to as "Internet Drafts" or to IETF RFCs >>>> categorized as Historic or Experimental. Normative references must >>>> only be made to IETF RFCs that are Standards Track or to >>>> Informational RFCs that have IETF consensus." >>>> >>>> Is this not correct? If correct, shouldn't this also be pointed out >>>> in the liaison? >>>> Dave >>>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>> Of Stewart Bryant >>>> Sent: Thursday, January 13, 2011 11:27 AM >>>> To: mpls@ietf.org >>>> Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft >>>> Recommendation G.tpoam [Ref043.02] >>>> >>>> Exactly Ben. >>>> >>>> The Liaison is list of statements of relevant facts, and none of the >>>> contra points dispute those facts. >>>> >>>> Stewart >>>> >>>> On 13/01/2011 15:41, Ben Niven-Jenkins wrote: >>>>> Larry, >>>>> >>>>> On 13 Jan 2011, at 14:55, Larry wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I don't think it is proper to send the LS to ITU-T because the text >>>>>> doesn't reflect the requirement from providers. >>>>>> Apparently, draft-bhh based OAM is the most mature solution >>>>>> currently. It has been proved by more than 200,000 applications and >>>>>> is supported by a lot of operators and vendors. >>>>>> >>>>> That may or may not be true, but either way it is irrelevant to the >>>>> liaison. >>>>> >>>>> ITU liaised G.tpoam to IETF. The liaison response Stewart has >>>>> drafted points out that G.tpoam uses technology (draft-bhh) that is >>>>> not endorsed by IETF consensus and points to some risks of doing so, >>>>> including breach of a prior ITU-IETF agreement on how to progress >>>>> MPLS-TP development. >>>>> >>>>> Everything in the liaison is fact. Whether draft-bhh is >>>>> good/bad/ugly, deployed, supported by operators, etc. is irrelevant, >>>>> it is not endorsed by IETF as a MPLS-TP OAM solution and all the >>>>> liaison does is point out that fact. >>>>> >>>>> FWIW this isn't the first time a group of operators have brought a >>>>> proposal to IETF only to find that the IETF has decided to do >>>>> something else, and I'm sure it won't be the last. >>>>> >>>>> Ben >>>>> >>>>> P.S. for some reason email chains related to draft-bhh remind me of >>>>> this Dilbert cartoon http://www.dilbert.com/2010-12-22/ >>>>> >>>>> >>>>> >>>>>> Best regards, >>>>>> >>>>>> Han Li >>>>>> >>>>>> ******************************************************************* >>>>>> ** >>>>>> **** >>>>>> Han Li, Ph.D >>>>>> China Mobile Research Institute >>>>>> Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China >>>>>> Fax: +86 10 63601087 >>>>>> MOBILE: 13501093385 >>>>>> ******************************************************************* >>>>>> ** >>>>>> **** >>>>>> >>>>>> >>>>>> --- 11å¹´1月13日，周四, >>>>>> ruiquan.jing@ties.itu.int >>>>>> 写é“： >>>>>> >>>>>>> å‘件人: ruiquan.jing@ties.itu.int >>>>>>> 主题: Re: [mpls-tp] [mpls] Draft: Response to Updated draft >>>>>>> Recommendation G.tpoam [Ref043.02] >>>>>>> 收件人: jingr@ties.itu.ch >>>>>>> 抄é€: mpls-tp@ietf.org >>>>>>> 日期: 2011å¹´1月13æ—¥,周四,下åˆ4:09 >>>>>>> Resend to mpls-tp list. >>>>>>> >>>>>>> Quoting jingr@ties.itu.ch: >>>>>>> >>>>>>>> Hi Stewart Bryant, >>>>>>>> >>>>>>>> I don’t agree with the current LS text. >>>>>>>> >>>>>>>> China Telecom support the standardization of Y.1731 >>>>>>> based MPLS-TP OAM tools >>>>>>>> in >>>>>>>> the ITU-T to meet the urgent and increasing >>>>>>> requirements for PTN deployment. >>>>>>>> It’s a multi-vendor supported, interoperability >>>>>>> certificated and feasible >>>>>>>> solution. It had been specified in both CCSA >>>>>>> (China Communications Standards >>>>>>>> Association) and China Telecom’s PTN standard as the >>>>>>> only standard OAM >>>>>>>> mechanism. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Jing Ruiquan >>>>>>>> >>>>>>>> China　Telecom Beijing >>>>>>> Research　Institute >>>>>>> ------------------------------------------------------------------ >>>>>>> -- >>>>>>> ---------- >>>>>>> -- >>>>>>>> From: mpls-bounces@ietf.org >>>>>>> [mailto:mpls-bounces@ietf.org] >>>>>>> On Behalf Of >>>>>>>> Stewart >>>>>>>> Bryant >>>>>>>> Sent: Monday, January 10, 2011 6:57 PM >>>>>>>> To: mpls@ietf.org >>>>>>>> Subject: [mpls] Draft: Response to Updated draft >>>>>>> Recommendation G.tpoam >>>>>>>> [Ref043.02] >>>>>>>> >>>>>>>> >>>>>>>> I propose to send the following Liaison Response to >>>>>>> the ITU-T on Friday >>>>>>>> 14th January and am posting it to the MPLS WG list for >>>>>>> review. >>>>>>>> ======= >>>>>>>> >>>>>>>> Response to Updated draft Recommendation G.tpoam [Ref >>>>>>> 043.02] >>>>>>>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >>>>>>>> To: tsbsg15@itu.int, >>>>>>> greg.jones@itu.int, >>>>>>> hiroshi.ota@itu.int, >>>>>>> IAB@ietf.org >>>>>>>> CC: Greg Jones, swallow@cisco.com, >>>>>>> loa@pi.nu, paf@cisco.com >>>>>>>> stbryant@cisco.com, >>>>>>> adrian.farrel@huawei.com, >>>>>>> mpls@ietf.org >>>>>>>> yoichi.maeda@ttc.or.jp, >>>>>>> steve.trowbridge@alcatel-lucent.com >>>>>>> >>>>>>>> ghani.abbas@ericsson.com, >>>>>>> hhelvoort@huawei.com >>>>>>> >>>>>>>> malcolm.betts@zte.com.cn, >>>>>>> kam.lam@alcatel-lucent.com >>>>>>> >>>>>>>> For Action >>>>>>>> >>>>>>>> The MPLS Working Group notes that this document >>>>>>> contains text describing >>>>>>>> MPLS-TP OAM protocols not designed and standardized >>>>>>> using the IETF >>>>>>>> Standards process. Specifically it uses material from >>>>>>>> draft-bhh-mpls-tp-oam-y1731-06. >>>>>>>> >>>>>>>> We wish to draw your attention to the status section >>>>>>> of >>>>>>>> draft-bhh-mpls-tp-oam-y1731-06 which states: >>>>>>>> >>>>>>>> "Internet-Drafts are draft documents valid for a >>>>>>> maximum of six months >>>>>>>> and may be updated, replaced, or obsoleted by other >>>>>>> documents at any >>>>>>>> time. It is inappropriate to use Internet-Drafts as >>>>>>> reference material >>>>>>>> or to cite them other than as "work in progress". >>>>>>>> >>>>>>>> Please also note that since the draft filename starts >>>>>>> with the prefix >>>>>>>> string "draft-bhh" this clearly identifies it to the >>>>>>> reader as a >>>>>>>> document expressing the personal technical views of >>>>>>> the authors and >>>>>>>> hence hence as a document that that does not have any >>>>>>> acknowledged level >>>>>>>> of IETF consensus. >>>>>>>> >>>>>>>> Since the text of draft Recommendation for G.tpoam is >>>>>>> based on an >>>>>>>> MPLS-TP OAM protocol not designed within the IETF >>>>>>> Standards Process this >>>>>>>> is a breach of the SG15 agreement with the IETF as >>>>>>> published in Report >>>>>>>> of the first meeting of Working Party 3/15 Transport >>>>>>> network structures >>>>>>>> (2009-2012) (Geneva, 1 – 12 December 2008) which can >>>>>>> be found at >>>>>>>> http://www.itu.int/md/T09-SG15-R-0004/en >>>>>>>> Please confirm that the ITU-T intends to continue with >>>>>>> the joint work on >>>>>>>> MPLS-TP and that the ITU-T will align this >>>>>>> recommendation with the IETF >>>>>>>> MPLS-TP OAM design before advancing this document >>>>>>> through the ITU-T >>>>>>>> publication process. >>>>>>>> >>>>>>>> The MPLS Working Group would also like to draw the >>>>>>> attention of ITU-T >>>>>>>> SG15 to the IETF copyright rules. Please see >>>>>>>> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-P >>>>>>>> ol >>>>>>>> icy- >>>>>>>> 20091228.htm >>>>>>>> for further details. >>>>>>>> >>>>>>>> Since this draft Recommendation contains text in which >>>>>>> the ITU-T SG15 >>>>>>>> has proposed making changes to IETF protocols without >>>>>>> the approval of >>>>>>>> the IETF, the MPLS Working Group have referred this >>>>>>> liaison to the IAB >>>>>>>> for their consideration. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ========= >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpls-tp mailing list >>>>>>> mpls-tp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>>>> >>>>>> _______________________________________________ >>>>>> mpls-tp mailing list >>>>>> mpls-tp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> -- >>>> For corporate legal information go to: >>>> >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> -- >> ***************************************************************** >> 我爱外点一七三一 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From jdrake@juniper.net Thu Jan 13 16:02:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83DB3A6C16; Thu, 13 Jan 2011 16:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NglsrmsXLS+L; Thu, 13 Jan 2011 16:02:36 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 537A73A6BC7; Thu, 13 Jan 2011 16:02:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTS+TK0/eDpW3HFz3Vj4OBofHzZLVmdQk@postini.com; Thu, 13 Jan 2011 16:05:00 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 13 Jan 2011 16:03:12 -0800 From: John E Drake To: Yuji Tochio , "mpls@ietf.org" , "mpls-tp@ietf.org" Date: Thu, 13 Jan 2011 16:05:08 -0800 Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] Thread-Index: AcuzduoQA61s1qsNQeGAVKUoWQ06fwAAKzrQ Message-ID: <5E893DB832F57341992548CDBB33316398C702A766@EMBX01-HQ.jnpr.net> References: <4D2AE56A.3060200@cisco.com> <4D2F7A4C.80304@gmail.com> <4D2F8669.1090103@jp.fujitsu.com> In-Reply-To: <4D2F8669.1090103@jp.fujitsu.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 00:02:38 -0000 QWN0dWFsbHksIHRoZSBmaXJzdCBwYXJhZ3JhcGggZG9lcyBub3QgYXNrIGZvciB3ZDE5cjIuICBH aXZlbiB0aGUgc3RhdHVzIG9mIGRyYWZ0IGJoaCBpbiB0aGUgSUVURiBhbmQgZ2l2ZW4gdGhlIHN0 aWxsIGluIGZvcmNlIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBJVFUgYW5kIHRoZSBJRVRGLCB3aHkg c2hvdWxkIGFueSBJRVRGIGN5Y2xlcyBiZSBzcGVudCByZXZpZXdpbmcgRy44MTIxPw0KDQpTZW50 IGZyb20gbXkgaVBob25lDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog bXBscy10cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy10cC1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiBCZWhhbGYgT2YgWXVqaSBUb2NoaW8NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkg MTMsIDIwMTEgMzoxMSBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZzsgbXBscy10cEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW21wbHMtdHBdIFttcGxzXSBEcmFmdDogUmVzcG9uc2UgdG8gVXBkYXRl ZCBkcmFmdA0KPiBSZWNvbW1lbmRhdGlvbiBHLjgxMjEgW1JlZiAwNDIuMDJdDQo+IA0KPiBIaSwN Cj4gDQo+IEFzIHRvIHRoaXMgcmVzcG9uc2UgKEcuODEyMSksIEkgc3VwcG9ydCBIdXViJ3MgY29t bWVudC4NCj4gVGhlIGltcG9ydGFudCBpcyB0byByZXZpZXcgdGhlIGRyYWZ0IEcuODEyMSBzbyB0 aGF0IElFVEYgc2hvdWxkDQo+IGFzayBmb3IgdGhlIG1pc3NpbmcgZmlsZSBhdCBmaXJzdC4NCj4g SW4gdGhhdCBzZW5zZSwgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBMUyB3aXRoIGFza2luZyBmb3Ig dGhlIGRyYWZ0DQo+IChpLmUuIHdkMTlyMikgaXMgZW5vdWdoLg0KPiANCj4gT2YgY291cnNlLCBJ VFUtVCBzaG91bGQgaGF2ZSB2ZXJpZmllZCB0aGF0IHRoZSBhdHRhY2htZW50IGlzDQo+IGluY2x1 ZGVkLi4uLg0KPiANCj4gUmVnYXJkcywNCj4gWXVqaQ0KPiANCj4gKDIwMTEvMDEvMTQgNzoxOCks IEh1dWIgdmFuIEhlbHZvb3J0IHdyb3RlOg0KPiA+IEhlbGxvIFN0ZXdhcnQsDQo+ID4NCj4gPiBZ b3Ugd3JvdGU6DQo+ID4NCj4gPj4gSSBwcm9wb3NlIHRvIHNlbmQgdGhlIGZvbGxvd2luZyBMaWFp c29uIFJlc3BvbnNlIHRvIHRoZSBJVFUtVCBvbg0KPiBGcmlkYXkNCj4gPj4gMTR0aCBKYW51YXJ5 IGFuZCBhbSBwb3N0aW5nIGl0IHRvIHRoZSBNUExTIFdHIGxpc3QgZm9yIHJldmlldy4NCj4gPg0K PiA+IEkgZG8gbm90IHN1cHBvcnQgc2VuZGluZyB0aGUgbGlhaXNvbiBhcyBwcm9wb3NlZC4NCj4g Pg0KPiA+IFdlIHNob3VsZCByZXN0cmljdCBpdCB0byB0aGUgZmlyc3QgcGFyYWdyYXBoIG5vdGlu ZyB0aGF0IHRoZSBmaWxlDQo+ID4gdGhhdCBzaG91bGQgYmUgcmV2aWV3ZWQgaXMgbWlzc2luZyBh bmQgYXNrIGZvciBzZW5kaW5nIHRoZSBtaXNzaW5nDQo+ID4gZmlsZSBzbyBpdCBjYW4gYmUgcmV2 aWV3ZWQgYnkgdGhlIFdHLg0KPiA+DQo+ID4gVGhlIHJlbWFpbmRlciBvZiB0aGUgdGV4dCBpcyBi YXNlZCBvbiBhc3N1bXB0aW9ucyBhbmQgbm90IG9uIGZhY3RzLg0KPiA+DQo+ID4gUmVnYXJkcywg SHV1Yi4NCj4gPg0KPiA+DQo+ID4+ID09PT09PT09PQ0KPiA+Pg0KPiA+PiBSZXNwb25zZSB0byBV cGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcuODEyMSBbUmVmIDA0Mi4wMl0NCj4gPj4NCj4g Pj4gRnJvbTogSUVURiBMaWFpc29uIHRvIElUVS1UIG9uIE1QTFMgc3RicnlhbnRAY2lzY28uY29t DQo+ID4+IFRvOiB0c2JzZzE1QGl0dS5pbnQsIGdyZWcuam9uZXNAaXR1LmludCwgaGlyb3NoaS5v dGFAaXR1LmludCwNCj4gSUFCQGlldGYub3JnDQo+ID4+IENDOiBHcmVnIEpvbmVzLCBzd2FsbG93 QGNpc2NvLmNvbSwgbG9hQHBpLm51LCBwYWZAY2lzY28uY29tDQo+ID4+IHN0YnJ5YW50QGNpc2Nv LmNvbSwgYWRyaWFuLmZhcnJlbEBodWF3ZWkuY29tLCBtcGxzQGlldGYub3JnDQo+ID4+IHlvaWNo aS5tYWVkYUB0dGMub3IuanAsIHN0ZXZlLnRyb3dicmlkZ2VAYWxjYXRlbC1sdWNlbnQuY29tDQo+ ID4+IGdoYW5pLmFiYmFzQGVyaWNzc29uLmNvbSwgaGhlbHZvb3J0QGh1YXdlaS5jb20NCj4gPj4g bWFsY29sbS5iZXR0c0B6dGUuY29tLmNuLCBrYW0ubGFtQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPiA+ Pg0KPiA+PiBGb3IgQWN0aW9uDQo+ID4+DQo+ID4+IFVuZm9ydHVuYXRlbHkgSVRVLVQgZG9jdW1l bnQgV0QxOXIyIHdhcyBub3QgYXR0YWNoZWQgdG8gdGhpcw0KPiBsaWFpc29uLA0KPiA+PiBhbmQg dGh1cyB0aGUgTVBMUyBXb3JraW5nIEdyb3VwIGlzIHVuYWJsZSB0byBjb21tZW50IG9uIGl0cyBj b250ZW50DQo+IGF0DQo+ID4+IHRoaXMgdGltZS4NCj4gPj4NCj4gPj4gSXQgaXMgc3RhdGVkIGlu IHRoZSBsaWFpc29uIHRoYXQgdGhlIG1vZGlmaWNhdGlvbnMgdG8gdGhpcyBkcmFmdA0KPiA+PiBS ZWNvbW1lbmRhdGlvbiBhcmUgYmFzZWQgb24gZHJhZnQtYmhoLW1wbHMtdHAtb2FtLXkxNzMxLTA2 LiBQbGVhc2UNCj4gbWF5DQo+ID4+IHdlIGRyYXcgeW91ciBhdHRlbnRpb24gdG8gdGhlIHN0YXR1 cyBzZWN0aW9uIG9mDQo+ID4+IGRyYWZ0LWJoaC1tcGxzLXRwLW9hbS15MTczMS0wNiB3aGljaCBz dGF0ZXMNCj4gPj4NCj4gPj4gIkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4DQo+IG1vbnRocw0KPiA+PiBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KPiA+ PiB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlDQo+IG1hdGVyaWFsDQo+ID4+IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzIi4NCj4gPj4NCj4gPj4gUGxlYXNlIGFsc28gbm90ZSB0aGF0IHNpbmNl IHRoZSBkcmFmdCBmaWxlbmFtZSBzdGFydHMgd2l0aCB0aGUNCj4gcHJlZml4DQo+ID4+IHN0cmlu ZyAiZHJhZnQtYmhoIiB0aGlzIGNsZWFybHkgaWRlbnRpZmllcyBpdCB0byB0aGUgcmVhZGVyIGFz IGENCj4gPj4gZG9jdW1lbnQgZXhwcmVzc2luZyB0aGUgcGVyc29uYWwgdGVjaG5pY2FsIHZpZXdz IG9mIHRoZSBhdXRob3JzIGFuZA0KPiA+PiBoZW5jZSBoZW5jZSBhcyBhIGRvY3VtZW50IHRoYXQg dGhhdCBkb2VzIG5vdCBoYXZlIGFueSBhY2tub3dsZWRnZWQNCj4gbGV2ZWwNCj4gPj4gb2YgSUVU RiBjb25zZW5zdXMuDQo+ID4+DQo+ID4+IElmIHRoaXMgZHJhZnQgUmVjb21tZW5kYXRpb24gZm9y IEcuODEyMSBpcyBiYXNlZCBvbiBhbiBNUExTLVRQIE9BTQ0KPiA+PiBwcm90b2NvbCBub3QgZGVz aWduZWQgd2l0aGluIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCB0aGUgTVBMUw0KPiA+PiBX b3JraW5nIEdyb3VwIGJlbGlldmUgdGhhdCB0aGlzIHdvdWxkIGJlIGluIGJyZWFjaCBvZiB0aGUg U0cxNQ0KPiBhZ3JlZW1lbnQNCj4gPj4gd2l0aCB0aGUgSUVURiBhcyBwdWJsaXNoZWQgaW4gUmVw b3J0IG9mIHRoZSBmaXJzdCBtZWV0aW5nIG9mIFdvcmtpbmcNCj4gPj4gUGFydHkgMy8xNSBUcmFu c3BvcnQgbmV0d29yayBzdHJ1Y3R1cmVzICgyMDA5LTIwMTIpIChHZW5ldmEsIDEg4oCTIDEyDQo+ ID4+IERlY2VtYmVyIDIwMDgpIHdoaWNoIGNhbiBiZSBmb3VuZCBhdA0KPiA+PiBodHRwOi8vd3d3 Lml0dS5pbnQvbWQvVDA5LVNHMTUtUi0wMDA0L2VuDQo+ID4+DQo+ID4+IFRoZSBNUExTIFdvcmtp bmcgR3JvdXAgd291bGQgYWxzbyBsaWtlIHRvIGRyYXcgdGhlIGF0dGVudGlvbiBvZiBJVFUtDQo+ IFQNCj4gPj4gU0cxNSB0byB0aGUgSUVURiBjb3B5cmlnaHQgcnVsZXMuIFBsZWFzZSBzZWUNCj4g Pj4gaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvL2FyY2hpdmUvSUVURi1UcnVz dC1MaWNlbnNlLQ0KPiBQb2xpY3ktMjAwOTEyMjguaHRtDQo+ID4+IGZvciBmdXJ0aGVyIGRldGFp bHMuDQo+ID4+DQo+ID4+IFdlIGhhdmUgcmVmZXJyZWQgdGhpcyBsaWFpc29uIHRvIHRoZSBJQUIg Zm9yIHRoZWlyIGNvbnNpZGVyYXRpb24uDQo+ID4+DQo+ID4+DQo+ID4+ID09PT09PT09PT09DQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCj4gPg0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMtdHAgbWFp bGluZyBsaXN0DQo+IG1wbHMtdHBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzLXRwDQo= From Feng.f.Huang@alcatel-sbell.com.cn Thu Jan 13 16:25:13 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1166F3A6BFB; Thu, 13 Jan 2011 16:25:13 -0800 (PST) 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=[AWL=-0.733, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3DfolJtr2X1; Thu, 13 Jan 2011 16:25:09 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id D856628B23E; Thu, 13 Jan 2011 16:25:07 -0800 (PST) X-AuditID: ac189297-b7cc5ae00000285e-eb-4d2f98702f94 Received: from cnshgsbhs01.ad4.ad.alcatel.com (smtp.cn.alcatel-lucent.com [172.24.146.145]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 6F.FF.10334.1789F2D4; Fri, 14 Jan 2011 08:27:29 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 08:27:18 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB381.CD40B1C0" Date: Fri, 14 Jan 2011 08:27:17 +0800 Message-ID: In-Reply-To: <22AC359C-CD36-4607-87B9-1DE6329096AE@asgaard.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] R: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] Thread-Index: AcuzdzfRunCxMCJNQcivuoBlWMZNxgAB4tmg References: <24506674.971481294959616690.JavaMail.defaultUser@defaultHost> <22AC359C-CD36-4607-87B9-1DE6329096AE@asgaard.org> From: "HUANG Feng F" To: "Christopher LILJENSTOLPE" , X-OriginalArrivalTime: 14 Jan 2011 00:27:18.0896 (UTC) FILETIME=[CD6F2F00:01CBB381] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, mpls-tp@ietf.org, stbryant@cisco.com Subject: Re: [mpls] [mpls-tp] R: Re: Draft: Response to Updated draft Recommendation G.tpoam[Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 00:25:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB381.CD40B1C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Christopher, I was at the meeting too. Do you forgot that it is in IETF79 plenary in Beijing, the meeting = was closed before 5 minutes as it was planed though it was said that = itu-t expert can present if time is enough? Do you forgot that IETF ignored ITU-T inputs on some RFCs before = approving them as RFCs such as RFC 5921 and = draft-ietf-mpls-tp-survivability-framework etc? I am wondering whether = IETF have already break the JWT agreement or not? It is right to accuse = ITU-T on standardize G.tpoam in the liaison text with agreement. B.R. Feng =20 ________________________________ From: Christopher LILJENSTOLPE [mailto:cdl@asgaard.org]=20 Sent: 2011=C4=EA1=D4=C214=C8=D5 7:11 To: erminio.ottone_69@libero.it Cc: nurit.sprecher@nsn.com; HUANG Feng F; stbryant@cisco.com; = mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] R: Re: [mpls] Draft: Response to Updated draft = Recommendation G.tpoam[Ref043.02] Erminio,=20 I was at the meeting, and I did not see anyone denied a chance to = approach the mic. I did see a pair of working group chairs struggle to = keep a working group on the previously published and agreed upon agenda. = The fact that a group of individuals wanted to dramatically change the = agenda at the beginning of the meeting would have denied the other = groups who had scheduled time from their allotted segments. Having = worked in some SG's in the ITU-T as well, I don't believe that behavior = would have been any more allowed in an ITU-T meeting, than an IETF one = (if anything, the ITU-T process probably would have shut it down = faster). =20 Christopher On 14Jan2011, at 10.00, erminio.ottone_69@libero.it wrote: You forget that ITU-T experts have not been allowed to speak at IETF 79 = and a=20 new trend of approving RFCs without resolving ITU-T have been started. =09 =09 ----Messaggio originale---- =09 Da: nurit.sprecher@nsn.com =09 Data: 13-gen-2011 13.54 =09 A: "ext HUANG Feng F", = , =09 Cc: =09 Ogg: Re: [mpls-tp] [mpls] Draft: Response to Updated draft = Recommendation G. =09 tpoam[Ref043.02] =09 Hi Feng, =09 You say " HF> I can't image the meaning of cooperation is that ITU-T = do=20 =09 nothing and just obey IETF's process!" =09 It seems that you are not familiar with the agreement on the joint = work. The=20 =09 ITU-T experts are called to contribute to (also by the SG15) to assist = in the=20 development the development of the protocol in the IETF using the IETF = standard=20 processes... =09 Best regards, =09 Nurit =09 -----Original Message----- =09 From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]=20 =09 Sent: Thursday, January 13, 2011 12:31 PM =09 To: Sprecher, =09 Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org =09 Cc: mpls-tp@ietf.org =09 Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam =09 [Ref043.02] =09 Hi, Nurit, =09 Please see in line. =09 B.R. =09 Feng =09 -----Original Message----- =09 From: Sprecher, Nurit (NSN - IL/Hod HaSharon) = [mailto:nurit.sprecher@nsn. =09 com]=20 =09 Sent: 2011=C4=EA1=D4=C213=C8=D5 17:45 =09 To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org =09 Cc: mpls-tp@ietf.org =09 Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam =09 [Ref043.02] =09 Hi Feng, =09 I did not refer to specific solution, validity and acceptance of a = solution,=20 =09 so I cannot see to what you disagree and how your response fit to mine. = =09 If you think that you have a good solution which is proven and = supported=20 =09 please discuss it in the IETF and try to get support for it!=20 =09 HF> The solution has been submitted to ietf for 2 year! =09 I would like the ITU-T to continue with its collaborative agreement = with the=20 =09 IETF and ensure that the development of the protocol is done as agreed = and=20 supported by SG15 using the IETF processes. =09 HF> I can't image the meaning of cooperation is that ITU-T do nothing = and=20 =09 just obey IETF's process! =09 I will support a single global solution interoperable solution = (whatever the=20 =09 solution is).=20 =09 Best regards, =09 Nurit =09 -----Original Message----- =09 From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn] =09 Sent: Thursday, January 13, 2011 11:35 AM =09 To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; = mpls@ietf. =09 org =09 Cc: mpls-tp@ietf.org =09 Subject: RE: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam =09 [Ref043.02] =09 Hi,Nurit, =09 I can't agree with you. =09 Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet = Transport=20 =09 Network by many applications and public demo and it has many = supporters. I am=20 wondering why this solutions is not standardized in ietf?=20 =09 Further more, I really don't agree with your last sentence, this=20 =09 solution is asked by customers in Industry, you can see at least 7 = providers in=20 global support this solution. =09 B.R. =09 Feng =09 -----Original Message----- =09 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of=20 =09 Sprecher, Nurit (NSN - IL/Hod HaSharon) =09 Sent: 2011=C4=EA1=D4=C213=C8=D5 16:18 =09 To: stbryant@cisco.com; mpls@ietf.org =09 Subject: Re: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam =09 [Ref043.02] =09 Hi, =09 I support the proposal. =09 We have a cooperative agreement with the ITU-T concerning the work on = MPLS- =09 TP.=20 =09 The agreement recognizes the design authority of the IETF for MPLS and = it is=20 =09 agreed that the development of the protocol should be done in the IETF = using=20 the IETF processes. The ITU-T should not take any uncoordinated action = in the=20 development of the MPLS_TP protocol.=20 =09 We would appreciate if the ITU-T continues (as it committed to) with = the=20 =09 collaborative work with the IETF on MPLS_TP and contributes from its = expertise=20 to the development of the protocol using the IETF processes.=20 =09 We would also not like to see two competing solutions which may = confuse the=20 =09 Industry, bloat operational and capital expenses and badly affect the = end=20 customer.=20 =09 Best regards, =09 Nurit =09 -----Original Message----- =09 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of ext=20 =09 Stewart Bryant =09 Sent: Monday, January 10, 2011 12:57 PM =09 To: mpls@ietf.org =09 Subject: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam=20 =09 [Ref043.02] =09 I propose to send the following Liaison Response to the ITU-T on = Friday 14th=20 =09 January and am posting it to the MPLS WG list for review. =09 =3D=3D=3D=3D=3D=3D=3D =09 Response to Updated draft Recommendation G.tpoam [Ref 043.02] =09 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com =09 To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org =09 CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com = stbryant@cisco. =09 com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, = steve. trowbridge@alcatel-lucent.com =09 ghani.abbas@ericsson.com, hhelvoort@huawei.com = malcolm.betts@zte.com.cn, kam. =09 lam@alcatel-lucent.com =09 For Action =09 The MPLS Working Group notes that this document contains text = describing =09 MPLS-TP OAM protocols not designed and standardized using the IETF = Standards=20 =09 process. Specifically it uses material from = draft-bhh-mpls-tp-oam-y1731-06. =09 We wish to draw your attention to the status section of =09 draft-bhh-mpls-tp-oam-y1731-06 which states: =09 "Internet-Drafts are draft documents valid for a maximum of six months = and=20 =09 may be updated, replaced, or obsoleted by other documents at any time. = It is=20 inappropriate to use Internet-Drafts as reference material or to cite = them=20 other than as "work in progress". =09 Please also note that since the draft filename starts with the prefix = string=20 =09 "draft-bhh" this clearly identifies it to the reader as a document = expressing=20 the personal technical views of the authors and hence hence as a = document that=20 that does not have any acknowledged level =09 of IETF consensus. =09 Since the text of draft Recommendation for G.tpoam is based on an = MPLS-TP OAM=20 =09 protocol not designed within the IETF Standards Process this =09 is a breach of the SG15 agreement with the IETF as published in Report = of the=20 =09 first meeting of Working Party 3/15 Transport network structures =09 (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at = http://www. =09 itu.int/md/T09-SG15-R-0004/en =09 Please confirm that the ITU-T intends to continue with the joint work = on =09 MPLS-TP and that the ITU-T will align this recommendation with the = IETF MPLS- =09 TP OAM design before advancing this document through the ITU-T = publication=20 process. =09 The MPLS Working Group would also like to draw the attention of ITU-T =09 SG15 to the IETF copyright rules. Please see =09 = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-2 =09 0091228.htm =09 for further details. =09 Since this draft Recommendation contains text in which the ITU-T SG15 = has=20 =09 proposed making changes to IETF protocols without the approval of the = IETF, the=20 MPLS Working Group have referred this liaison to the IAB for their=20 consideration. =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D =09 _______________________________________________ =09 mpls mailing list =09 mpls@ietf.org =09 https://www.ietf.org/mailman/listinfo/mpls =09 _______________________________________________ =09 mpls mailing list =09 mpls@ietf.org =09 https://www.ietf.org/mailman/listinfo/mpls =09 _______________________________________________ =09 mpls-tp mailing list =09 mpls-tp@ietf.org =09 https://www.ietf.org/mailman/listinfo/mpls-tp =09 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp =09 --- =C0=EE=BF=C2=EE=A3 Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc ------_=_NextPart_001_01CBB381.CD40B1C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Christopher,
   I was at the = meeting=20 too.
   Do you forgot that = it is in=20 IETF79 plenary in Beijing, the  meeting was closed before 5 minutes = as=20 it was planed though it was said that itu-t expert can = present if=20 time is enough?
   Do you forgot = that IETF=20  ignored ITU-T inputs on some RFCs before approving them as RFCs = such as=20 RFC 5921 and draft-ietf-mpls-tp-survivability-framework  etc? =  I am=20 wondering whether IETF have already break the JWT agreement or not? = It is=20 right to accuse ITU-T on standardize G.tpoam in the liaison text with=20 agreement.
B.R.
Feng
 

From: Christopher LILJENSTOLPE=20 [mailto:cdl@asgaard.org]
Sent: 2011=C4=EA1=D4=C214=C8=D5 = 7:11
To:=20 erminio.ottone_69@libero.it
Cc: nurit.sprecher@nsn.com; HUANG = Feng F;=20 stbryant@cisco.com; mpls@ietf.org; mpls-tp@ietf.org
Subject: = Re:=20 [mpls-tp] R: Re: [mpls] Draft: Response to Updated draft Recommendation=20 G.tpoam[Ref043.02]

Erminio,

I = was at the=20 meeting, and I did not see anyone denied a chance to approach the mic. =  I=20 did see a pair of working group chairs struggle to keep a working group = on the=20 previously published and agreed upon agenda.  The fact that a group = of=20 individuals wanted to dramatically change the agenda at the beginning of = the=20 meeting would have denied the other groups who had scheduled time from = their=20 allotted segments.  Having worked in some SG's in the ITU-T as = well, I=20 don't believe that behavior would have been any more allowed in an ITU-T = meeting, than an IETF one (if anything, the ITU-T process probably would = have=20 shut it down faster).  

Christopher

On 14Jan2011, at 10.00, erminio.ottone_69@libero.it=20 wrote:

You forget that ITU-T experts have not been allowed to speak at = IETF 79=20 and a
new trend of approving RFCs without resolving ITU-T have = been=20 started.

----Messaggio originale----
Da: nurit.sprecher@nsn.com
Data: 13-gen-2011 13.54
A: "ext HUANG Feng F"<Feng.f.Huang@alcatel-sb= ell.com.cn>,=20 <stbryant@cisco.
com>, <mpls@ietf.org>
Cc: <mpls-tp@ietf.org>
Ogg: Re: [mpls-tp] [mpls] Draft: Response to = Updated=20 draft=20 Recommendation G.
tpoam[Ref043.02]

Hi Feng,
You say " HF> I can't image the = meaning=20 of cooperation is that ITU-T do
nothing and just = obey IETF's=20 process!"
It seems that you are not familiar with the=20 agreement on the joint work. The
ITU-T experts are = called to=20 contribute to (also by the SG15) to assist in the
development the=20 development of the protocol in the IETF using the IETF standard=20
processes...
Best regards,
Nurit


-----Original Message-----
From: ext HUANG Feng F=20 [mailto:Feng.f.Huang@alcatel-sbell.com.cn]
Sent: Thursday, January 13, 2011 12:31=20 PM
To: Sprecher,
Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; mpls@ietf.org
Cc: mpls-tp@ietf.org
Subject: RE: [mpls] Draft: Response to = Updated draft=20 Recommendation G.tpoam
[Ref043.02]

Hi, Nurit,
 Please see in line.
B.R.
Feng


-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod = HaSharon)=20 [mailto:nurit.sprecher@nsn.
com]
Sent: 2011=C4=EA1=D4=C213=C8=D5 = 17:45
To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org
Cc: mpls-tp@ietf.org
Subject: RE: [mpls] Draft: Response to = Updated draft=20 Recommendation G.tpoam
[Ref043.02]

Hi Feng,
I did not refer to specific solution, = validity and=20 acceptance of a solution,
so I cannot see to what = you=20 disagree and how your response fit to mine.
If you think that you have a good solution = which is=20 proven and supported
please discuss it in the IETF = and try to=20 get support for it!

HF> The solution has been submitted to = ietf for 2=20 year!

I would like the ITU-T to continue with its=20 collaborative agreement with the
IETF and ensure = that the=20 development of the protocol is done as agreed and
supported by = SG15 using=20 the IETF processes.

HF> I can't image the meaning of = cooperation is=20 that ITU-T do nothing and
just obey IETF's = process!

I will support a single global solution=20 interoperable solution (whatever the
solution is). =
Best regards,
Nurit

-----Original Message-----
From: ext HUANG Feng F=20 [mailto:Feng.f.Huang@alcatel-sbell.com.cn]
Sent: Thursday, January 13, 2011 11:35=20 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); = stbryant@cisco.com;=20 mpls@ietf.
org
Cc: mpls-tp@ietf.org
Subject: RE: [mpls] Draft: Response to = Updated draft=20 Recommendation G.tpoam
[Ref043.02]

Hi,Nurit,
 I can't agree with = you.
 Solution of GACH+Y.1731 in G.tpoam is = proven=20 work well in Packet Transport
Network by many = applications=20 and public demo and it has many supporters. I am
wondering why =  this=20 solutions is not  standardized in ietf?
  Further more,  I really = don't agree=20 with your last sentence, this
solution is asked by = customers=20 in Industry, you can see at least 7 providers in
global support = this=20 solution.

B.R.
Feng


-----Original Message-----
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of =
Sprecher, Nurit=20 (NSN - IL/Hod HaSharon)
Sent: 2011=C4=EA1=D4=C213=C8=D5 = 16:18
To: stbryant@cisco.com; mpls@ietf.org
Subject: Re: [mpls] Draft: Response to = Updated draft=20 Recommendation G.tpoam
[Ref043.02]

Hi,
I support the proposal.
We have a cooperative agreement with the = ITU-T=20 concerning the work on MPLS-
TP.
The agreement recognizes the design = authority of the=20 IETF for MPLS and it is
agreed that the development = of the=20 protocol should be done in the IETF using
the IETF processes. The = ITU-T=20 should not take any uncoordinated action in the
development of the = MPLS_TP=20 protocol.
We would appreciate if the ITU-T continues = (as it=20 committed to) with the
collaborative work with the = IETF on=20 MPLS_TP and contributes from its expertise
to the development of = the=20 protocol using the IETF processes.
We would also not like to see two competing=20 solutions which may confuse the
Industry, bloat = operational=20 and capital expenses and badly affect the end
customer.
Best regards,
Nurit

-----Original Message-----
From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of ext =
Stewart=20 Bryant
Sent: Monday, January 10, 2011 12:57=20 PM
To: mpls@ietf.org
Subject: [mpls] Draft: Response to Updated = draft=20 Recommendation G.tpoam
[Ref043.02]

I propose to send the following Liaison = Response to=20 the ITU-T on Friday 14th
January and am posting it = to the=20 MPLS WG list for review.

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

Response to Updated draft Recommendation = G.tpoam=20 [Ref 043.02]

From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com
To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org
CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com=20 stbryant@cisco.
com, adrian.farrel@huawei.com, = mpls@ietf.org yoichi.maeda@ttc.or.jp, = steve.
trowbridge@alcatel-lucent.c= om
ghani.abbas@ericsson.com, = hhelvoort@huawei.com malcolm.betts@zte.com.cn,=20 kam.
lam@alcatel-lucent.com

For Action

The MPLS Working Group notes that this = document=20 contains text describing

MPLS-TP OAM protocols not designed and = standardized=20 using the IETF Standards
process. Specifically it = uses=20 material from draft-bhh-mpls-tp-oam-y1731-06.

We wish to draw your attention to the status = section=20 of
draft-bhh-mpls-tp-oam-y1731-06 which=20 states:

"Internet-Drafts are draft documents valid = for a=20 maximum of six months and
may be updated, replaced, = or=20 obsoleted by other documents at any time. It is
inappropriate to = use=20 Internet-Drafts as reference material or to cite them
other than = as "work=20 in progress".

Please also note that since the draft = filename=20 starts with the prefix string
"draft-bhh" this = clearly=20 identifies it to the reader as a document expressing
the personal=20 technical views of the authors and hence hence as a document that =
that=20 does not have any acknowledged level

of IETF consensus.

Since the text of draft Recommendation for = G.tpoam=20 is based on an MPLS-TP OAM
protocol not designed = within the=20 IETF Standards Process this

is a breach of the SG15 agreement with the = IETF as=20 published in Report of the
first meeting of Working = Party=20 3/15 Transport network structures
(2009-2012) (Geneva, 1 - 12 December 2008) = which can=20 be found at = http://www.
itu.int/md/T09-SG15-R-0004/en

Please confirm that the ITU-T intends to = continue=20 with the joint work on

MPLS-TP and that the ITU-T will align this=20 recommendation with the IETF MPLS-
TP OAM design = before=20 advancing this document through the ITU-T publication
process.

The MPLS Working Group would also like to = draw the=20 attention of ITU-T
SG15 to the IETF copyright rules. Please=20 see
http://trustee.ietf.org/license-info/archive/IETF-Trust-Lic= ense-Policy-2
0091228.htm
for further details.

Since this draft Recommendation contains = text in=20 which the ITU-T SG15 has
proposed making changes to = IETF=20 protocols without the approval of the IETF, the
MPLS Working Group = have=20 referred this liaison to the IAB for their
consideration.


=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
= _______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
= _______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp



__________________________________= _____________
mpls-tp=20 mailing=20 = list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp=

---
=C0=EE=BF=C2=EE=A3
Check my PGP key here:
https://www.asgaard.org/~cd= l/cdl.asc

------_=_NextPart_001_01CBB381.CD40B1C0-- From huubatwork@gmail.com Fri Jan 14 02:14:38 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31D73A6AFB; Fri, 14 Jan 2011 02:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8nVIXod9i0Q; Fri, 14 Jan 2011 02:14:36 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 22A813A6AC9; Fri, 14 Jan 2011 02:14:35 -0800 (PST) Received: by eyd10 with SMTP id 10so1399289eyd.31 for ; Fri, 14 Jan 2011 02:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DDdn1+FdlfZFbVq6weSUAGQ+jTcgiNI+yjahiKwSxCU=; b=dYJirwPjRkroVQpJh5k9vEuAdPqoh1YlAbQeNoIcEuJqTYcLElx9J9DMsXSleBFXKz VasTpV46W/2TtqnjguMOdhGx8RU/UuzjfbxmpYBS0NKVTKlSTxcTUhySL4pJ2XusF72d KsRdmTrz7hiwIyW1Ev/ZqAGx3KfVK3CbkStxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=CzR+VRZSRYs8E/3sPdMMWhAdMiPysd4/RDSLDtzNQeW3Mz1br8r2KG2coauY2xlm6k L7Gc/ApJMZiSHadGxufXWZOZxNGX5AiJRczgdEoJ55grZ3Wkq9KGt7bWm66/y/YW04w6 V/fvIk1Rv9rD1DNNnqW4LU4edOfDDtNcYAW/w= Received: by 10.14.11.226 with SMTP id 74mr459720eex.5.1295000220241; Fri, 14 Jan 2011 02:17:00 -0800 (PST) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id v59sm824435eeh.15.2011.01.14.02.16.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Jan 2011 02:16:59 -0800 (PST) Message-ID: <4D302299.3020803@gmail.com> Date: Fri, 14 Jan 2011 11:16:57 +0100 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: "mpls@ietf.org" , "mpls-tp@ietf.org" References: <4D2AE56A.3060200@cisco.com> <4D2F7A4C.80304@gmail.com> <4D2F8669.1090103@jp.fujitsu.com> <5E893DB832F57341992548CDBB33316398C702A766@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316398C702A766@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] [mpls-tp] Draft: Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 10:14:38 -0000 Hi John, You wrote: > Actually, the first paragraph does not ask for wd19r2. > Given the status of draft bhh in the IETF and given the still > in force agreement between the ITU and the IETF, why should > any IETF cycles be spent reviewing G.8121? If this is a fact,then why is this not mentioned in the liaison. Proposed text: "Given the status of draft-bhh in the IETF we do not intend to review G.8121 nor G.tpoam" Regards, Huub. Sent from my MacBook. >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of Yuji Tochio >> Sent: Thursday, January 13, 2011 3:11 PM >> To: mpls@ietf.org; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] [mpls] Draft: Response to Updated draft >> Recommendation G.8121 [Ref 042.02] >> >> Hi, >> >> As to this response (G.8121), I support Huub's comment. >> The important is to review the draft G.8121 so that IETF should >> ask for the missing file at first. >> In that sense, the first paragraph of LS with asking for the draft >> (i.e. wd19r2) is enough. >> >> Of course, ITU-T should have verified that the attachment is >> included.... >> >> Regards, >> Yuji >> >> (2011/01/14 7:18), Huub van Helvoort wrote: >>> Hello Stewart, >>> >>> You wrote: >>> >>>> I propose to send the following Liaison Response to the ITU-T on >> Friday >>>> 14th January and am posting it to the MPLS WG list for review. >>> >>> I do not support sending the liaison as proposed. >>> >>> We should restrict it to the first paragraph noting that the file >>> that should be reviewed is missing and ask for sending the missing >>> file so it can be reviewed by the WG. >>> >>> The remainder of the text is based on assumptions and not on facts. >>> >>> Regards, Huub. >>> >>> >>>> ========= >>>> >>>> Response to Updated draft Recommendation G.8121 [Ref 042.02] >>>> >>>> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >>>> To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, >> IAB@ietf.org >>>> CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com >>>> stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org >>>> yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com >>>> ghani.abbas@ericsson.com, hhelvoort@huawei.com >>>> malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com >>>> >>>> For Action >>>> >>>> Unfortunately ITU-T document WD19r2 was not attached to this >> liaison, >>>> and thus the MPLS Working Group is unable to comment on its content >> at >>>> this time. >>>> >>>> It is stated in the liaison that the modifications to this draft >>>> Recommendation are based on draft-bhh-mpls-tp-oam-y1731-06. Please >> may >>>> we draw your attention to the status section of >>>> draft-bhh-mpls-tp-oam-y1731-06 which states >>>> >>>> "Internet-Drafts are draft documents valid for a maximum of six >> months >>>> and may be updated, replaced, or obsoleted by other documents at any >>>> time. It is inappropriate to use Internet-Drafts as reference >> material >>>> or to cite them other than as "work in progress". >>>> >>>> Please also note that since the draft filename starts with the >> prefix >>>> string "draft-bhh" this clearly identifies it to the reader as a >>>> document expressing the personal technical views of the authors and >>>> hence hence as a document that that does not have any acknowledged >> level >>>> of IETF consensus. >>>> >>>> If this draft Recommendation for G.8121 is based on an MPLS-TP OAM >>>> protocol not designed within the IETF Standards Process, the MPLS >>>> Working Group believe that this would be in breach of the SG15 >> agreement >>>> with the IETF as published in Report of the first meeting of Working >>>> Party 3/15 Transport network structures (2009-2012) (Geneva, 1 – 12 >>>> December 2008) which can be found at >>>> http://www.itu.int/md/T09-SG15-R-0004/en >>>> >>>> The MPLS Working Group would also like to draw the attention of ITU- >> T >>>> SG15 to the IETF copyright rules. Please see >>>> http://trustee.ietf.org/license-info/archive/IETF-Trust-License- >> Policy-20091228.htm >>>> for further details. >>>> >>>> We have referred this liaison to the IAB for their consideration. >>>> >>>> >>>> =========== >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >> >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- ***************************************************************** 我爱外点一七三一 From ietf@cdl.asgaard.org Fri Jan 14 06:10:19 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06153A6C59 for ; Fri, 14 Jan 2011 06:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTyaqR7Zfuv4 for ; Fri, 14 Jan 2011 06:10:18 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id ED4B53A6B26 for ; Fri, 14 Jan 2011 06:10:17 -0800 (PST) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id 5EC10A0A071; Fri, 14 Jan 2011 14:12:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-234-1027056878" From: Christopher LILJENSTOLPE In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201DA53C3B8E0@INOAVREX11.ptin.corpPT.com> Date: Sat, 15 Jan 2011 01:12:32 +1100 Message-Id: References: <4D2AE5E0.90703@cisco.com> <52981DB05D3C5247A12D0AEE309F3CC201DA53C3B8E0@INOAVREX11.ptin.corpPT.com> To: Rui Costa Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: "mpls@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 14:10:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-234-1027056878 Content-Type: multipart/alternative; boundary=Apple-Mail-233-1027056806 --Apple-Mail-233-1027056806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings Rui, I'm not sure how the LS should recognize anyone's "inputs" = outside of the form of "there is an agreement and the IETF has a policy = (as does the ITU) regarding referencing I-D's by other SDOs" and this = inbound liaison seems to contravene those. The merits of bhh, or any = other technical discussion, is not the topic of the LS. My = interpretation of the JWT agreement, IETF process, and ITU-T's own = statements on reference to ID's would lead me to support this LS. On the non-germain topic of "not supporting service provider = inputs" - it may not support all service provider inputs, but there are = service providers that do support the current path of the WG. Chris On 14Jan2011, at 05.24, Rui Costa wrote: > Hello,=09 >=20 > This LS doesn't recognize service providers' inputs, where the = inclusion of Y.1731 based OAM tools within the MPLS-TP OAM toolkit is = grounded, so I don't agree with it.=09 >=20 > I think both approaches (this one as well as the one documented in a = set of MPLS WG drafts) should proceed. This one meets a need that has = been expressed in the IETF. =20 >=20 > Regards,=09 > Rui=09 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Stewart Bryant > Sent: segunda-feira, 10 de Janeiro de 2011 10:57 > To: mpls@ietf.org > Subject: [mpls] Draft: Response to Updated draft Recommendation = G.tpoam [Ref 043.02] >=20 > I propose to send the following Liaison Response to the ITU-T on = Friday=20 > 14th January and am posting it to the MPLS WG list for review. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > Response to Updated draft Recommendation G.tpoam [Ref 043.02] >=20 > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, = IAB@ietf.org > CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com > stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org > yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com, hhelvoort@huawei.com > malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com >=20 > For Action >=20 > The MPLS Working Group notes that this document contains text = describing=20 > MPLS-TP OAM protocols not designed and standardized using the IETF=20 > Standards process. Specifically it uses material from=20 > draft-bhh-mpls-tp-oam-y1731-06. >=20 > We wish to draw your attention to the status section of=20 > draft-bhh-mpls-tp-oam-y1731-06 which states: >=20 > "Internet-Drafts are draft documents valid for a maximum of six months=20= > and may be updated, replaced, or obsoleted by other documents at any=20= > time. It is inappropriate to use Internet-Drafts as reference material=20= > or to cite them other than as "work in progress". >=20 > Please also note that since the draft filename starts with the prefix=20= > string "draft-bhh" this clearly identifies it to the reader as a=20 > document expressing the personal technical views of the authors and=20 > hence hence as a document that that does not have any acknowledged = level=20 > of IETF consensus. >=20 > Since the text of draft Recommendation for G.tpoam is based on an=20 > MPLS-TP OAM protocol not designed within the IETF Standards Process = this=20 > is a breach of the SG15 agreement with the IETF as published in Report=20= > of the first meeting of Working Party 3/15 Transport network = structures=20 > (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at=20 > http://www.itu.int/md/T09-SG15-R-0004/en >=20 > Please confirm that the ITU-T intends to continue with the joint work = on=20 > MPLS-TP and that the ITU-T will align this recommendation with the = IETF=20 > MPLS-TP OAM design before advancing this document through the ITU-T=20 > publication process. >=20 > The MPLS Working Group would also like to draw the attention of ITU-T=20= > SG15 to the IETF copyright rules. Please see=20 > = http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-200= 91228.htm=20 > for further details. >=20 > Since this draft Recommendation contains text in which the ITU-T SG15=20= > has proposed making changes to IETF protocols without the approval of=20= > the IETF, the MPLS Working Group have referred this liaison to the IAB=20= > for their consideration. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-233-1027056806 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I'm not sure how the LS should = recognize anyone's "inputs" outside of the form of "there is an = agreement and the IETF has a policy (as does the ITU) regarding = referencing I-D's by other SDOs"  and this inbound liaison seems to = contravene those.  The merits of bhh, or any other technical = discussion, is not the topic of the LS.  My interpretation of the = JWT agreement, IETF process, and ITU-T's own statements on reference to = ID's would lead me to support this LS.

On the = non-germain topic of "not supporting service provider inputs" - it may = not support all service provider inputs, but there are service providers = that do support the current path of the = WG.

Chris

On = 14Jan2011, at 05.24, Rui Costa wrote:

Hello,

This LS doesn't recognize = service providers' inputs, where the inclusion of Y.1731 based OAM tools = within the MPLS-TP OAM toolkit is grounded, so I don't agree with = it. =

I think both approaches (this one as well as the one = documented in a set of MPLS WG drafts) should proceed. This one meets a = need that has been expressed in the IETF. =   

Regards,
Rui =


-----Original Message-----
From: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: = segunda-feira, 10 de Janeiro de 2011 10:57
To: mpls@ietf.org
Subject: [mpls] = Draft: Response to Updated draft Recommendation G.tpoam [Ref = 043.02]

I propose to send the following Liaison Response to the = ITU-T on Friday
14th January and am posting it to the MPLS WG list = for review.

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

Response to Updated = draft Recommendation G.tpoam [Ref 043.02]

From: IETF Liaison to = ITU-T on MPLS stbryant@cisco.com
To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org
CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com
stbryant@cisco.com, adrian.farrel@huawei.com, = mpls@ietf.org
yoichi.maeda@ttc.or.jp, steve.trowbridge@alcat= el-lucent.com
ghani.abbas@ericsson.com, = hhelvoort@huawei.com
malcolm.betts@zte.com.cn, = kam.lam@alcatel-lucent.com<= br>
For Action

The MPLS Working Group notes that this document = contains text describing
MPLS-TP OAM protocols not designed and = standardized using the IETF
Standards process. Specifically it uses = material from
draft-bhh-mpls-tp-oam-y1731-06.

We wish to draw = your attention to the status section of =
draft-bhh-mpls-tp-oam-y1731-06 which states:

"Internet-Drafts = are draft documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any
time. It = is inappropriate to use Internet-Drafts as reference material
or to = cite them other than as "work in progress".

Please also note that = since the draft filename starts with the prefix
string "draft-bhh" = this clearly identifies it to the reader as a
document expressing = the personal technical views of the authors and
hence hence as a = document that that does not have any acknowledged level
of IETF = consensus.

Since the text of draft Recommendation for G.tpoam is = based on an
MPLS-TP OAM protocol not designed within the IETF = Standards Process this
is a breach of the SG15 agreement with the = IETF as published in Report
of the first meeting of Working Party = 3/15 Transport network structures
(2009-2012) (Geneva, 1 - 12 = December 2008) which can be found at
http://www.itu.int/md/T0= 9-SG15-R-0004/en

Please confirm that the ITU-T intends to = continue with the joint work on
MPLS-TP and that the ITU-T will = align this recommendation with the IETF
MPLS-TP OAM design before = advancing this document through the ITU-T
publication = process.

The MPLS Working Group would also like to draw the = attention of ITU-T
SG15 to the IETF copyright rules. Please see =
http://trustee.ietf.org/license-info/archive/IETF-Trust= -License-Policy-20091228.htm
for further details.

Since = this draft Recommendation contains text in which the ITU-T SG15
has = proposed making changes to IETF protocols without the approval of =
the IETF, the MPLS Working Group have referred this liaison to the = IAB
for their = consideration.


=3D=3D=3D=3D=3D=3D=3D=3D=3D
_________________= ______________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls
_______________________________________________
= mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


= --Apple-Mail-233-1027056806-- --Apple-Mail-234-1027056878 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNMFnWAAoJEGmx2Mt/+Iw/j3gH/RMUCSGPRWq1of3ZClm1Gv8r HeazK8R+xojim73wfZcdjulGcO6OJgs3ZNpTsZkgg63eIDGD3klvxtq3yISiH/kK f/cVvDuC92JsPKQw7krP3F0jjxwPj8lqMp3YovsAExUn+WtDujalgLtrEXiU6LW6 hMLkQ1cTleoFnPcPhj9/qLByMjaE/EfWGFDE8ketOz5cnOxo3yVpxkw9fF27D3Lj mkciyg0ZOcWziDeJXNBbVZYFd4+j+96hC+rD6KMFEsyjfFB/nEIgVEgC94vHY9gM kmZUhbnWmQoFsH/dAO/cGQfDBWsfmwbV+gBiTGw/rhwHl4RdIy5oIHDwlDrL/bc= =2VrJ -----END PGP SIGNATURE----- --Apple-Mail-234-1027056878-- From erosen@cisco.com Fri Jan 14 06:16:26 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6AC3A6B26 for ; Fri, 14 Jan 2011 06:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4adR5ITf0PT for ; Fri, 14 Jan 2011 06:16:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AD8333A6C59 for ; Fri, 14 Jan 2011 06:16:25 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Jan 2011 14:18:51 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0EEIoII022819; Fri, 14 Jan 2011 14:18:50 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p0EEIodx011121; Fri, 14 Jan 2011 09:18:50 -0500 To: Christopher LILJENSTOLPE In-reply-to: Your message of Fri, 14 Jan 2011 10:07:03 +1100. MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 09:18:50 -0500 Message-ID: <11120.1295014730@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" , stbryant@cisco.com Subject: Re: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 14:16:26 -0000 > It is a statement that identifies that the ITU-T did not follow the JWT > agreement between the IETF and the ITU-T, nor internal ITU-T and IETF > processes. =A0It does not say that the IETF will not meet it's obligations > under the JWT if the request is made the correct way. =A0It's not a "bugg= er > off" it's a "please work with us in the manner previously agreed and > respect our process" I don't understand why the Liaison is so measured and restrained (wishy-washy). Since the ITU-T has breached the agreement, I don't see why the IETF should be thought to have any further obligations under the JWT. Shouldn't the liaison state the consequences of this breach? From lufang@cisco.com Fri Jan 14 07:16:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135CC3A6B27 for ; Fri, 14 Jan 2011 07:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OLphCk9nrqF for ; Fri, 14 Jan 2011 07:16:24 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4DBDE3A6ACF for ; Fri, 14 Jan 2011 07:16:20 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD34L02tJXG9/2dsb2JhbACkVnOiR5hGhU8EhGuJUw Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rtp-iport-2.cisco.com with ESMTP; 14 Jan 2011 15:18:45 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0EFIiLi006005; Fri, 14 Jan 2011 15:18:45 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 09:18:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 09:18:31 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25041C4FFA@XMB-RCD-201.cisco.com> In-Reply-To: <11120.1295014730@erosen-linux> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] Thread-Index: Acuz9fy1grbKJU1lTaSDGpYH1oKqGgAA3khQ References: Your message of Fri, 14 Jan 2011 10:07:03 +1100. <11120.1295014730@erosen-linux> From: "Luyuan Fang (lufang)" To: "Eric Rosen (erosen)" , "Christopher LILJENSTOLPE" X-OriginalArrivalTime: 14 Jan 2011 15:18:33.0180 (UTC) FILETIME=[4E9761C0:01CBB3FE] Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 15:16:25 -0000 Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport = requirements, IETF defines the protocols.=20 Option 2: IETF and ITU-T each develop separately, in that case, no MPLS = protocol extensions/modifications can be standardized outside of IETF, = nor the use of MPLS naming.=20 The consequences of breaching the joint agreement would lead to Option = 2. References:=20 [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural = Considerations for a Transport Profile, Feb. 2009.=20 [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. = 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and = Generalized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Eric Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft = RecommendationG.tpoam [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the=20 > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and=20 > IETF processes. =A0It does not say that the IETF will not meet it's=20 > obligations under the JWT if the request is made the correct way. =A0 > It's not a "bugger off" it's a "please work with us in the manner=20 > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained = (wishy-washy). Since the ITU-T has breached the agreement, I don't see = why the IETF should be thought to have any further obligations under the = JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Fri Jan 14 07:26:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02703A67EC for ; Fri, 14 Jan 2011 07:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEQ9YDwYSSxD for ; Fri, 14 Jan 2011 07:26:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C5AAD3A6A51 for ; Fri, 14 Jan 2011 07:26:10 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIr6L02tJV2a/2dsb2JhbACkVnOiU5hGhU8EhGuJUw Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 14 Jan 2011 15:28:36 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0EFSZvP018036; Fri, 14 Jan 2011 15:28:35 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 09:28:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 09:28:16 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25041C5007@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] Thread-Index: Acuz9fy1grbKJU1lTaSDGpYH1oKqGgAA3khQAAFWaZA= References: Your message of Fri, 14 Jan 2011 10:07:03 +1100. <11120.1295014730@erosen-linux> From: "Luyuan Fang (lufang)" To: "Eric Rosen (erosen)" , "Christopher LILJENSTOLPE" X-OriginalArrivalTime: 14 Jan 2011 15:28:17.0786 (UTC) FILETIME=[AB0B2DA0:01CBB3FF] Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 15:26:14 -0000 In fact, no MPLS or any other IETF protocol extensions/modifications can = be standardized outside of IETF in any case. Other SDOs can develop technologies independently as long as not = extending/modifying IETF protocols on their own. Luyuan=20 -----Original Message----- From: Luyuan Fang (lufang)=20 Sent: 14 January 2011 10:19 To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draft = RecommendationG.tpoam [Ref 043.02] Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport = requirements, IETF defines the protocols.=20 Option 2: IETF and ITU-T each develop separately, in that case, no MPLS = protocol extensions/modifications can be standardized outside of IETF, = nor the use of MPLS naming.=20 The consequences of breaching the joint agreement would lead to Option = 2. References:=20 [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural = Considerations for a Transport Profile, Feb. 2009.=20 [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. = 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and = Generalized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Eric Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft = RecommendationG.tpoam [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the=20 > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and=20 > IETF processes. =A0It does not say that the IETF will not meet it's=20 > obligations under the JWT if the request is made the correct way. > It's not a "bugger off" it's a "please work with us in the manner=20 > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained = (wishy-washy). Since the ITU-T has breached the agreement, I don't see = why the IETF should be thought to have any further obligations under the = JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From twalsh@juniper.net Fri Jan 14 07:52:45 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EE23A6B3F for ; Fri, 14 Jan 2011 07:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK-pzwTtSphy for ; Fri, 14 Jan 2011 07:52:44 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id D04693A688E for ; Fri, 14 Jan 2011 07:52:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTTBx26SXQBHedCzUJJLPjfOmdS8dM4s7@postini.com; Fri, 14 Jan 2011 07:55:09 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 14 Jan 2011 07:53:52 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 14 Jan 2011 10:53:51 -0500 From: Thomas Walsh To: "Luyuan Fang (lufang)" , "Eric Rosen (erosen)" , Christopher LILJENSTOLPE Date: Fri, 14 Jan 2011 10:53:50 -0500 Thread-Topic: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] Thread-Index: Acuz9fy1grbKJU1lTaSDGpYH1oKqGgAA3khQAAFWaZAAALDuwA== Message-ID: References: Your message of Fri, 14 Jan 2011 10:07:03 +1100. <11120.1295014730@erosen-linux> <238542D917511A45B6B8AA806E875E25041C5007@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25041C5007@XMB-RCD-201.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 15:52:45 -0000 The problem is only at the Rapporteur level. It isn't an official ITU-T ac= tion until and unless its is confirmed at the Working Party meeting in Gene= va in February. =20 There is an interesting liaison (TD-563 GEN) from IETF to SG 11 meeting thi= s month explaining what needs to be done if ITU-T wants to develop a new pr= otocol rather than use IETF protocol. "In particular, different identifiers= , formats, protocol names, and protocol component names be used at all leve= ls of the protocol stack implied by the design."=20 MPLS can not be modified without IETF approval and ITU-T would need to crea= te an entire new suite of protocols with new identifiers, formats, names, e= tc. =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Luy= uan Fang (lufang) Sent: Friday, January 14, 2011 7:28 AM To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] In fact, no MPLS or any other IETF protocol extensions/modifications can be= standardized outside of IETF in any case. Other SDOs can develop technologies independently as long as not extending/= modifying IETF protocols on their own. Luyuan=20 -----Original Message----- From: Luyuan Fang (lufang)=20 Sent: 14 January 2011 10:19 To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport requirements, = IETF defines the protocols.=20 Option 2: IETF and ITU-T each develop separately, in that case, no MPLS pro= tocol extensions/modifications can be standardized outside of IETF, nor the= use of MPLS naming.=20 The consequences of breaching the joint agreement would lead to Option 2. References:=20 [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural Considera= tions for a Transport Profile, Feb. 2009.=20 [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and Gen= eralized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the=20 > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and=20 > IETF processes. =A0It does not say that the IETF will not meet it's=20 > obligations under the JWT if the request is made the correct way. > It's not a "bugger off" it's a "please work with us in the manner=20 > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained (wishy-was= hy). Since the ITU-T has breached the agreement, I don't see why the IETF = should be thought to have any further obligations under the JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Fri Jan 14 08:17:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4EE3A6BB3 for ; Fri, 14 Jan 2011 08:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shKPJoWWMNui for ; Fri, 14 Jan 2011 08:17:53 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 931B73A6BAA for ; Fri, 14 Jan 2011 08:17:52 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEMGME2tJV2Y/2dsb2JhbACkVnOiTphDghmDNgSEa4lT Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 14 Jan 2011 16:20:17 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p0EGKHSb002426; Fri, 14 Jan 2011 16:20:17 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:20:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:20:16 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25041C5078@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: Draft: Response to Updated draftRecommendationG.tpoam [Ref 043.02] Thread-Index: Acuz9fy1grbKJU1lTaSDGpYH1oKqGgAA3khQAAFWaZAAALDuwAABMwTw References: Your message of Fri, 14 Jan 2011 10:07:03+1100.<11120.1295014730@erosen-linux> <238542D917511A45B6B8AA806E875E25041C5007@XMB-RCD-201.cisco.com> From: "Luyuan Fang (lufang)" To: "Thomas Walsh" , "Eric Rosen (erosen)" , "Christopher LILJENSTOLPE" X-OriginalArrivalTime: 14 Jan 2011 16:20:17.0703 (UTC) FILETIME=[EEA8BB70:01CBB406] Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Subject: Re: [mpls] R: Draft: Response to Updated draftRecommendationG.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:17:54 -0000 > MPLS can not be modified without IETF approval and ITU-T would need to = create an entire new suite of protocols with new identifiers, formats, = names, etc. =20 Yep, if that is the route folks like to take.=20 -----Original Message----- From: Thomas Walsh [mailto:twalsh@juniper.net]=20 Sent: 14 January 2011 10:54 To: Luyuan Fang (lufang); Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated = draftRecommendationG.tpoam [Ref 043.02] The problem is only at the Rapporteur level. It isn't an official ITU-T = action until and unless its is confirmed at the Working Party meeting in = Geneva in February. =20 There is an interesting liaison (TD-563 GEN) from IETF to SG 11 meeting = this month explaining what needs to be done if ITU-T wants to develop a = new protocol rather than use IETF protocol. "In particular, different = identifiers, formats, protocol names, and protocol component names be = used at all levels of the protocol stack implied by the design."=20 MPLS can not be modified without IETF approval and ITU-T would need to = create an entire new suite of protocols with new identifiers, formats, = names, etc. =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Luyuan Fang (lufang) Sent: Friday, January 14, 2011 7:28 AM To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft = RecommendationG.tpoam [Ref 043.02] In fact, no MPLS or any other IETF protocol extensions/modifications can = be standardized outside of IETF in any case. Other SDOs can develop technologies independently as long as not = extending/modifying IETF protocols on their own. Luyuan=20 -----Original Message----- From: Luyuan Fang (lufang) Sent: 14 January 2011 10:19 To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draft = RecommendationG.tpoam [Ref 043.02] Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport = requirements, IETF defines the protocols.=20 Option 2: IETF and ITU-T each develop separately, in that case, no MPLS = protocol extensions/modifications can be standardized outside of IETF, = nor the use of MPLS naming.=20 The consequences of breaching the joint agreement would lead to Option = 2. References:=20 [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural = Considerations for a Transport Profile, Feb. 2009.=20 [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. = 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and = Generalized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Eric Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft = RecommendationG.tpoam [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the=20 > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and=20 > IETF processes. =A0It does not say that the IETF will not meet it's=20 > obligations under the JWT if the request is made the correct way. > It's not a "bugger off" it's a "please work with us in the manner=20 > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained = (wishy-washy). Since the ITU-T has breached the agreement, I don't see = why the IETF should be thought to have any further obligations under the = JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From jdrake@juniper.net Fri Jan 14 09:59:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853BD3A6C74 for ; Fri, 14 Jan 2011 09:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRxHjVziVdnp for ; Fri, 14 Jan 2011 09:59:24 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 95A843A6C70 for ; Fri, 14 Jan 2011 09:59:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTTCPjfC752pBzHh5XnxOFQK5sT51iIGz@postini.com; Fri, 14 Jan 2011 10:01:51 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 14 Jan 2011 09:59:50 -0800 From: John E Drake To: "erosen@cisco.com" , Christopher LILJENSTOLPE Date: Fri, 14 Jan 2011 10:01:47 -0800 Thread-Topic: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acuz9cgUkP5k0YCNSYGWftLi9PJeoQAHxb7A Message-ID: <5E893DB832F57341992548CDBB33316398C702ACF2@EMBX01-HQ.jnpr.net> References: Your message of Fri, 14 Jan 2011 10:07:03 +1100. <11120.1295014730@erosen-linux> In-Reply-To: <11120.1295014730@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:59:25 -0000 And actually, given the situation, asking the IETF to review this document = is really an act of disrespect. Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Rosen > Sent: Friday, January 14, 2011 6:19 AM > To: Christopher LILJENSTOLPE > Cc: mpls@ietf.org; stbryant@cisco.com > Subject: Re: [mpls] R: Draft: Response to Updated draft Recommendation > G.tpoam [Ref 043.02] >=20 >=20 > > It is a statement that identifies that the ITU-T did not follow the > JWT > > agreement between the IETF and the ITU-T, nor internal ITU-T and IETF > > processes. =A0It does not say that the IETF will not meet it's > obligations > > under the JWT if the request is made the correct way. =A0It's not a > "bugger > > off" it's a "please work with us in the manner previously agreed and > > respect our process" >=20 > I don't understand why the Liaison is so measured and restrained > (wishy-washy). Since the ITU-T has breached the agreement, I don't see > why > the IETF should be thought to have any further obligations under the > JWT. > Shouldn't the liaison state the consequences of this breach? >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jingr@ties.itu.ch Wed Jan 12 18:31:15 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191593A6801 for ; Wed, 12 Jan 2011 18:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbXiIpgoko8l for ; Wed, 12 Jan 2011 18:31:13 -0800 (PST) Received: from mail9.itu.ch (mail9.itu.ch [156.106.192.39]) by core3.amsl.com (Postfix) with ESMTP id 93EF43A67B1 for ; Wed, 12 Jan 2011 18:31:13 -0800 (PST) Received: from ties.itu.ch (ties.itu.ch [156.106.192.33]) by mail9.itu.ch (8.13.8/8.14.4) with ESMTP id p0D2X8R1023261; Thu, 13 Jan 2011 03:33:10 +0100 Received: from localhost (tokaj.itu.ch [156.106.192.34]) by ties.itu.ch (8.14.3/8.14.3) with ESMTP id p0D2X8LW466561; Thu, 13 Jan 2011 03:33:08 +0100 (CET) Received: from 156.106.192.159 ( [156.106.192.159]) as user jingr@ties.itu.ch by gold.itu.ch with HTTP; Thu, 13 Jan 2011 03:33:08 +0100 Message-ID: <1294885988.4d2e64642cd0e@gold.itu.ch> Date: Thu, 13 Jan 2011 03:33:08 +0100 From: ruiquan.jing@ties.itu.int To: stbryant@cisco.com, mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 156.106.192.159 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (mail9.itu.ch [156.106.192.39]); Thu, 13 Jan 2011 03:33:11 +0100 (CET) X-Mailman-Approved-At: Fri, 14 Jan 2011 13:37:21 -0800 Subject: Re: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 02:31:15 -0000 Hi Stewart Bryant, I don¡¯t agree with the current LS text. China Telecom support the standardization of Y.1731 based MPLS-TP OAM tools in the ITU-T to meet the urgent and increasing requirements for PTN deployment. It¡¯s a multi-vendor supported, interoperability certificated and feasible solution. It had been specified in both CCSA (China Communications Standards Association) and China Telecom¡¯s PTN standard as the only standard OAM mechanism. Best Regards Jing Ruiquan China¡¡Telecom Beijing Research¡¡Institute -------------------------------------------------------------------------------- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Monday, January 10, 2011 6:57 PM To: mpls@ietf.org Subject: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref043.02] I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review. ======= Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 ¨C 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. The MPLS Working Group would also like to draw the attention of ITU-T SG15 to the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- 20091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. ========= _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Fri Jan 14 23:42:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23483A6D1C; Fri, 14 Jan 2011 23:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 393udrk5pNGD; Fri, 14 Jan 2011 23:42:43 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 950E63A6D1B; Fri, 14 Jan 2011 23:42:43 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Jan 2011 07:45:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0F7j9vZ028666; Sat, 15 Jan 2011 07:45:09 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F7j3803561; Sat, 15 Jan 2011 07:45:04 GMT Message-ID: <4D31507F.7060408@cisco.com> Date: Sat, 15 Jan 2011 07:45:03 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB; Greg" , Hiroshi Ota Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "ITU-T SG15 TSB; Greg" , Ghani Abbas , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "Lam, Hing-Kam \(Kam\)" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Huub Van Helvoort , Stewart Bryant Subject: [mpls] Response to Review of MPLS Transport Profile, User-to-Network and Network-to-Network Interfaces (ref #041.03) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 07:42:44 -0000 Title: Response to Review of MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (ref #041.03) Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: Greg Jones@itu.int swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Information Thank you for your liaison statement "LS235 - Review of MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (ref #041.02)" and for your review of draft-ietf-mpls-tp-uni-nni-00.txt. The proposed change has been made to revision draft-ietf-mpls-tp-uni-nni-02.txt. The IETF last call completed on this document on 23rd December 2010, and document is scheduled for IESG review on 20th January 2011. From stbryant@cisco.com Fri Jan 14 23:54:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B39428C0E3; Fri, 14 Jan 2011 23:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ4jYuD7kAN3; Fri, 14 Jan 2011 23:54:53 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9CA9628B23E; Fri, 14 Jan 2011 23:54:53 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2011 07:57:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0F7vJd2019625; Sat, 15 Jan 2011 07:57:19 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F7vD803876; Sat, 15 Jan 2011 07:57:14 GMT Message-ID: <4D315359.2050802@cisco.com> Date: Sat, 15 Jan 2011 07:57:13 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB; Greg" , Hiroshi Ota Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, Greg.Jones@itu.int, malcolm.betts@zte.com.cn, statements@ietf.org, yoichi.maeda@ttc.or.jp, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , adrian.farrel@huawei.com, stbryant@cisco.com Subject: [mpls] Response to Comments on draft-ietf-mpls-tp-identifiers-03 [Ref # 046.03] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 07:54:55 -0000 Title: Response to Comments on draft-ietf-mpls-tp-identifiers-03 [Ref#046.03] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: Greg.Jones@itu.int swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com malcolm.betts@zte.com.cn statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Information Thank you for your liaison statement "LS245 - Comments on draft-ietf-mpls-tp-identifiers-03 [Ref#046.02]" and for your review of draft-ietf-mpls-tp-identifiers-03. Your comments have been passed to the authors who will either address them in the text or lead discussions on the MPLS mailing lists as appropriate. We will notify you when a new revision of the draft is available. From stbryant@cisco.com Sat Jan 15 00:05:26 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B7B3A6D1D; Sat, 15 Jan 2011 00:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBubGU2R7Xpx; Sat, 15 Jan 2011 00:05:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 173AB3A6D20; Sat, 15 Jan 2011 00:05:25 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2011 08:07:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0F87oEV022206; Sat, 15 Jan 2011 08:07:51 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F87j804083; Sat, 15 Jan 2011 08:07:45 GMT Message-ID: <4D3155D1.3080002@cisco.com> Date: Sat, 15 Jan 2011 08:07:45 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB; Greg" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Huub Van Helvoort , Ghani Abbas , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "Lam, Hing-Kam \(Kam\)" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant Subject: [mpls] Response to Draft revised Recommendation G.8110.1 [Ref#044.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:05:26 -0000 Title: Response to Draft revised Recommendation G.8110.1 [Ref#044.02] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Information Thank you for your liaison statement "LS236 - Draft revised Recommendation G.8110.1 [Ref#044.01]" The MPLS Working Group regrets that due to the numerous holidays since we received this liaison, we have not yet been able to review this this revised version of Draft Recommendation G.8110.1. We will review it and liaison comment before the February ITU-T SG15 Plenary Meeting. From stbryant@cisco.com Sat Jan 15 00:10:32 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02F428C0E3; Sat, 15 Jan 2011 00:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UykXfAZTEIHD; Sat, 15 Jan 2011 00:10:31 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 07D553A6D16; Sat, 15 Jan 2011 00:10:30 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2011 08:12:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0F8CuYt004190; Sat, 15 Jan 2011 08:12:56 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F8Cq804252; Sat, 15 Jan 2011 08:12:52 GMT Message-ID: <4D315704.5030904@cisco.com> Date: Sat, 15 Jan 2011 08:12:52 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Huub Van Helvoort , Ghani Abbas , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "Lam, Hing-Kam \(Kam\)" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant Subject: [mpls] Response to Updated draft Recommendation G.8151 [Ref 045.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:10:32 -0000 Title: Response to Updated draft Recommendation G.8151 [Ref 045.02] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Information Thank you for your liaison statement "LS237 - Updated draft Recommendation G.8151 [Ref 045.01]" The MPLS Working Group regrets that due to the numerous holidays since we received this liaison, we have not yet been able to review this this revised version of Draft Recommendation G.8151. We will review it and liaise comments before the February ITU-T SG15 Plenary Meeting. From stbryant@cisco.com Sat Jan 15 00:15:58 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD7D28C0E3 for ; Sat, 15 Jan 2011 00:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.221 X-Spam-Level: X-Spam-Status: No, score=-111.221 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnspmQAgKuyz for ; Sat, 15 Jan 2011 00:15:53 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 993AB3A6D16 for ; Sat, 15 Jan 2011 00:15:47 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAELnME1AZnwN/2dsb2JhbACkZnOjTIJSDgGWEoVQBIsf Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jan 2011 08:18:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0F8ICMo024322 for ; Sat, 15 Jan 2011 08:18:13 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F8IB804391; Sat, 15 Jan 2011 08:18:11 GMT Message-ID: <4D315842.6010708@cisco.com> Date: Sat, 15 Jan 2011 08:18:10 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] Fwd: Response to Updated draft Recommendation G.8151 [Ref 045.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:15:58 -0000 Please can the MPLS Working group take a look at G.8151 which can be found at https://datatracker.ietf.org/documents/LIAISON/file1157.pdf We should particularly look with a view to determining whether as the liaison body says it "is based on draft-bhh-mpls-tp-oam-y1731-06" or whether it is actually OAM technology neutral. As far as I can see it is neutral and the statement in the liaison letter in incorrect, but I would much appreciate someone else taking a look. Thanks Stewart -------- Original Message -------- Subject: [mpls] Response to Updated draft Recommendation G.8151 [Ref 045.02] Date: Sat, 15 Jan 2011 08:12:52 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg CC: mpls@ietf.org , Huub Van Helvoort , Ghani Abbas , Malcolm.BETTS , statements@ietf.org, yoichi.maeda@ttc.or.jp, Lam, Hing-Kam (Kam) , Patrik Fältström , Adrian Farrel , Stewart Bryant Title: Response to Updated draft Recommendation G.8151 [Ref 045.02] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Information Thank you for your liaison statement "LS237 - Updated draft Recommendation G.8151 [Ref 045.01]" The MPLS Working Group regrets that due to the numerous holidays since we received this liaison, we have not yet been able to review this this revised version of Draft Recommendation G.8151. We will review it and liaise comments before the February ITU-T SG15 Plenary Meeting. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Sat Jan 15 00:32:56 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271343A6D16; Sat, 15 Jan 2011 00:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.528 X-Spam-Level: X-Spam-Status: No, score=-111.528 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eIKCRBeJooj; Sat, 15 Jan 2011 00:32:53 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 59ABC3A6D20; Sat, 15 Jan 2011 00:32:53 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2011 08:35:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0F8ZJfw027780; Sat, 15 Jan 2011 08:35:19 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F8ZF804726; Sat, 15 Jan 2011 08:35:15 GMT Message-ID: <4D315C42.8060204@cisco.com> Date: Sat, 15 Jan 2011 08:35:14 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg , Hiroshi Ota , IAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , Greg , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "ITU-T SG15 TSB"@cisco.com, "Lam, Hing-Kam \(Kam\)" , =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant , Huub Van Helvoort , Ghani Abbas Subject: [mpls] Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:32:56 -0000 Title: Response to Updated draft Recommendation G.8121 [Ref 042.02] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int iab@ietf.org CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Action Deadline: 15th March 2011 Thank you for your liaison statement "LS232 - Updated draft Recommendation G.8121 [Ref 042.01]" Unfortunately ITU-T document WD19r2 was not attached to this liaison, and thus the MPLS Working Group is unable to comment on its content at this time. It is stated in the covering letter of the liaison that the modifications to this draft Recommendation are based on draft-bhh-mpls-tp-oam-y1731-06. Please may we draw your attention to the status section of all Internet-Drafts which says: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. If this draft Recommendation for G.8121 is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process, the MPLS Working Group Chairs and the Routing Area Directors believe that this would be in breach of the SG15 agreement with the IETF as published in Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012) (Geneva, 1 – 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en You should also be aware of the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, we have referred this liaison to the IAB for their consideration. From stbryant@cisco.com Sat Jan 15 00:35:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B1E3A6D20 for ; Sat, 15 Jan 2011 00:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.538 X-Spam-Level: X-Spam-Status: No, score=-111.538 tagged_above=-999 required=5 tests=[AWL=1.061, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irbDSEKINK69 for ; Sat, 15 Jan 2011 00:35:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1B6E63A6D16 for ; Sat, 15 Jan 2011 00:35:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPLrME1AZnwN/2dsb2JhbACkZnOjNoJSDgGWEoVQBIsf Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jan 2011 08:37:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0F8beAR028170 for ; Sat, 15 Jan 2011 08:37:40 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F8bc804769; Sat, 15 Jan 2011 08:37:39 GMT Message-ID: <4D315CD1.2070303@cisco.com> Date: Sat, 15 Jan 2011 08:37:37 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mpls@ietf.org References: <4D315C42.8060204@cisco.com> In-Reply-To: <4D315C42.8060204@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Response to Updated draft Recommendation G.8121 [Ref 042.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:35:14 -0000 I would like to thank the MPLS Working Group for the review of this liaison. I have sent the following to the ITU-T which I believe to be factually correct. Regards Stewart (IETF Liaison to ITU-T on MPLS) On 15/01/2011 08:35, Stewart Bryant wrote: > Title: Response to Updated draft Recommendation G.8121 [Ref 042.02] > > Submission Date: 15th January 2011 > > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > iab@ietf.org > CC: swallow@cisco.com > loa@pi.nu > paf@cisco.com > stbryant@cisco.com > adrian.farrel@huawei.com > mpls@ietf.org > yoichi.maeda@ttc.or.jp > steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com > hhelvoort@huawei.com > malcolm.betts@zte.com.cn > kam.lam@alcatel-lucent.com > statements@ietf.org > > Response Contact: stbryant@cisco.com > Technical Contact: stbryant@cisco.com > > Purpose: For Action > Deadline: 15th March 2011 > > Thank you for your liaison statement "LS232 - Updated draft > Recommendation G.8121 [Ref 042.01]" > > Unfortunately ITU-T document WD19r2 was not attached to this > liaison, and thus the MPLS Working Group is unable to comment > on its content at this time. > > It is stated in the covering letter of the liaison that the > modifications to this draft Recommendation are based on > draft-bhh-mpls-tp-oam-y1731-06. Please may we draw your attention > to the status section of all Internet-Drafts which says: > > "Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress". > > Please also note that since the draft filename starts with the > prefix string "draft-bhh" this clearly identifies it to the reader > as a document expressing the personal technical views of the > authors and hence hence as a document that that does not have > any acknowledged level of IETF consensus. > > If this draft Recommendation for G.8121 is based on an MPLS-TP > OAM protocol not designed within the IETF Standards Process, the > MPLS Working Group Chairs and the Routing Area Directors believe > that this would be in breach of the SG15 agreement with the IETF > as published in Report of the first meeting of Working > Party 3/15 Transport network structures (2009-2012) > (Geneva, 1 – 12 December 2008) which can be found at > http://www.itu.int/md/T09-SG15-R-0004/en > > You should also be aware of the IETF copyright rules. Please > see > http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm > for further details. > > Since this draft Recommendation contains text in which the > ITU-T SG15 has proposed making changes to IETF protocols without > the approval of the IETF, we have referred this liaison to the IAB > for their consideration. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Sat Jan 15 00:46:57 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AB228C0EC; Sat, 15 Jan 2011 00:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezcCN8Wdb47c; Sat, 15 Jan 2011 00:46:56 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7634D28C0EB; Sat, 15 Jan 2011 00:46:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jan 2011 08:49:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0F8nMca010730; Sat, 15 Jan 2011 08:49:22 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F8nH805005; Sat, 15 Jan 2011 08:49:17 GMT Message-ID: <4D315F8C.1070904@cisco.com> Date: Sat, 15 Jan 2011 08:49:16 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg , Hiroshi Ota , IAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , Greg , "Malcolm.BETTS" , statements@ietf.org, yoichi.maeda@ttc.or.jp, "ITU-T SG15 TSB"@cisco.com, "Lam, Hing-Kam \(Kam\)" , =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= , Adrian Farrel , Stewart Bryant , Huub Van Helvoort , Ghani Abbas Subject: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:46:57 -0000 Title: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int iab@ietf.org CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Action Deadline: 15th March 2011 Thank you for your liaison statement "LS233 - Updated draft Recommendation G.tpoam [Ref 043.01]" The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. Please may we draw your attention to the status section of all Internet-Drafts which says: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in "Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012)" (Geneva, 1 – 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en. As a consequence the MPLS WG has not been asked to review this Draft Recommendation by the IETF management. When the ITU-T SG15 liaises a draft Recommendation written in accordance with the above agreement, IETF management will ask the MPLS WG to perform an in depth review. We look forward to receiving your next draft. Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. You should also be aware of the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF- Trust-License-Policy-20091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. Please can we take this opportunity state that the IETF is committed to developing the MPLS-TP solution as described in the Joint Working Team Recommendations and meeting the jointly agreed MPLS-TP requirements documented in RFC5654. From stbryant@cisco.com Sat Jan 15 00:48:16 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDFE28C0EC for ; Sat, 15 Jan 2011 00:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.946 X-Spam-Level: X-Spam-Status: No, score=-109.946 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxTQ6XanKgOe for ; Sat, 15 Jan 2011 00:48:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C22613A6D28 for ; Sat, 15 Jan 2011 00:48:15 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEvuME1AZnwN/2dsb2JhbACkZnOjOIJSDgGWEoVQBIsf Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jan 2011 08:50:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0F8ofEX029989 for ; Sat, 15 Jan 2011 08:50:41 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0F8od805043; Sat, 15 Jan 2011 08:50:40 GMT Message-ID: <4D315FDE.7070207@cisco.com> Date: Sat, 15 Jan 2011 08:50:38 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [mpls] Fwd: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 08:48:17 -0000 I would like to thank the MPLS Working Group for the review of this liaison. I have sent the following to the ITU-T which I believe to be factually correct. Regards Stewart (IETF Liaison to ITU-T on MPLS) -------- Original Message -------- Subject: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Date: Sat, 15 Jan 2011 08:49:16 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg , Hiroshi Ota , IAB CC: mpls@ietf.org , Greg , Malcolm.BETTS , statements@ietf.org, yoichi.maeda@ttc.or.jp, ITU-T SG15 TSB@cisco.com, Lam, Hing-Kam (Kam) , Patrik Fältström , Adrian Farrel , Stewart Bryant , Huub Van Helvoort , Ghani Abbas Title: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Submission Date: 15th January 2011 From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int iab@ietf.org CC: swallow@cisco.com loa@pi.nu paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com statements@ietf.org Response Contact: stbryant@cisco.com Technical Contact: stbryant@cisco.com Purpose: For Action Deadline: 15th March 2011 Thank you for your liaison statement "LS233 - Updated draft Recommendation G.tpoam [Ref 043.01]" The MPLS Working Group notes that this document contains text describing MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06. Please may we draw your attention to the status section of all Internet-Drafts which says: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix string "draft-bhh" this clearly identifies it to the reader as a document expressing the personal technical views of the authors and hence hence as a document that that does not have any acknowledged level of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an MPLS-TP OAM protocol not designed within the IETF Standards Process this is a breach of the SG15 agreement with the IETF as published in "Report of the first meeting of Working Party 3/15 Transport network structures (2009-2012)" (Geneva, 1 – 12 December 2008) which can be found at http://www.itu.int/md/T09-SG15-R-0004/en. As a consequence the MPLS WG has not been asked to review this Draft Recommendation by the IETF management. When the ITU-T SG15 liaises a draft Recommendation written in accordance with the above agreement, IETF management will ask the MPLS WG to perform an in depth review. We look forward to receiving your next draft. Please confirm that the ITU-T intends to continue with the joint work on MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process. You should also be aware of the IETF copyright rules. Please see http://trustee.ietf.org/license-info/archive/IETF- Trust-License-Policy-20091228.htm for further details. Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration. Please can we take this opportunity state that the IETF is committed to developing the MPLS-TP solution as described in the Joint Working Team Recommendations and meeting the jointly agreed MPLS-TP requirements documented in RFC5654. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From erminio.ottone_69@libero.it Sat Jan 15 04:53:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DD63A6C16 for ; Sat, 15 Jan 2011 04:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM4sAz55NvoR for ; Sat, 15 Jan 2011 04:53:31 -0800 (PST) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by core3.amsl.com (Postfix) with ESMTP id 2EA3C3A6AA9 for ; Sat, 15 Jan 2011 04:53:31 -0800 (PST) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0202.4D319958.00B1,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail23 (172.31.0.48) by cp-out4.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D10BF99017F67E4; Sat, 15 Jan 2011 13:55:52 +0100 Message-ID: <14580236.3666561295096151996.JavaMail.defaultUser@defaultHost> Date: Sat, 15 Jan 2011 13:55:51 +0100 (CET) From: "erminio.ottone_69@libero.it" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_346839_27336339.1295096151995" X-SenderIP: 79.45.142.79 Cc: "mpls@ietf.org" , stbryant@cisco.com Subject: [mpls] R: Re: R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 12:53:34 -0000 ------=_Part_346839_27336339.1295096151995 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is very unpolite and rude making such a statement after having failed to= deliver what previously committed ----Messaggio originale---- Da: ietf@cdl.asgaard.org Data: 14-gen-2011 0.07 A: "erminio.ottone_69@libero.it" Cc: , "mpls@ietf.org" Ogg: Re: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam = [Ref 043.02] Erminio, I don't agree with your statement. It is a statement that identifies that = the ITU-T did not follow the JWT agreement between the IETF and the ITU-T, = nor internal ITU-T and IETF processes. It does not say that the IETF will = not meet it's obligations under the JWT if the request is made the correct = way. It's not a "bugger off" it's a "please work with us in the manner pre= viously agreed and respect our process" - is that too hard a request to mak= e? Chris On 14Jan2011, at 09.56, erminio.ottone_69@libero.it wrote: I do not support sending this LS in its current form. The LS is currently stating that the IETF is not committed to deliver to IT= U-T=20 what it was promised in the JWT agreement. What is the real concern the LS is trying to resolve? The fact that the=20 document is not based on an IETF RFC? ----Messaggio originale---- Da: stbryant@cisco.com Data: 10-gen-2011 11.56 A: "mpls@ietf.org" Ogg: [mpls] Draft: Response to Updated draft Recommendation G.tpoam [Ref=20 043.02] I propose to send the following Liaison Response to the ITU-T on Friday=20 14th January and am posting it to the MPLS WG list for review. =3D=3D=3D=3D=3D=3D=3D Response to Updated draft Recommendation G.tpoam [Ref 043.02] From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, IAB@ietf.org CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com ghani.abbas@ericsson.com, hhelvoort@huawei.com malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com For Action The MPLS Working Group notes that this document contains text describing=20 MPLS-TP OAM protocols not designed and standardized using the IETF=20 Standards process. Specifically it uses material from=20 draft-bhh-mpls-tp-oam-y1731-06. We wish to draw your attention to the status section of=20 draft-bhh-mpls-tp-oam-y1731-06 which states: "Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress". Please also note that since the draft filename starts with the prefix=20 string "draft-bhh" this clearly identifies it to the reader as a=20 document expressing the personal technical views of the authors and=20 hence hence as a document that that does not have any acknowledged level=20 of IETF consensus. Since the text of draft Recommendation for G.tpoam is based on an=20 MPLS-TP OAM protocol not designed within the IETF Standards Process this=20 is a breach of the SG15 agreement with the IETF as published in Report=20 of the first meeting of Working Party 3/15 Transport network structures=20 (2009-2012) (Geneva, 1 =E2=80=93 12 December 2008) which can be found at=20 http://www.itu.int/md/T09-SG15-R-0004/en Please confirm that the ITU-T intends to continue with the joint work on=20 MPLS-TP and that the ITU-T will align this recommendation with the IETF=20 MPLS-TP OAM design before advancing this document through the ITU-T=20 publication process. The MPLS Working Group would also like to draw the attention of ITU-T=20 SG15 to the IETF copyright rules. Please see=20 http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy- 20091228.htm=20 for further details. Since this draft Recommendation contains text in which the ITU-T SG15=20 has proposed making changes to IETF protocols without the approval of=20 the IETF, the MPLS Working Group have referred this liaison to the IAB=20 for their consideration. =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc ------=_Part_346839_27336339.1295096151995 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It is very unpolite and rude making such a statement after having failed= to deliver what previously committed

----Messaggio originale----
Da: ietf@cdl.asgaard.org
Data= : 14-gen-2011 0.07
A: "erminio.ottone_69@libero.it"<erminio.ottone_69= @libero.it>
Cc: <stbryant@cisco.com>, "mpls@ietf.org"<mpls@i= etf.org>
Ogg: Re: [mpls] R: Draft: Response to Updated draft Recommen= dation G.tpoam [Ref 043.02]

Erminio,

I don't agree with your statement.  It is a sta= tement that identifies that the ITU-T did not follow the JWT agreement betw= een the IETF and the ITU-T, nor internal ITU-T and IETF processes.  It= does not say that the IETF will not meet it's obligations under the JWT if= the request is made the correct way.  It's not a "bugger off" it's a = "please work with us in the manner previously agreed and respect our proces= s" - is that too hard a request to make?

Chris

On 14Jan2011, at 09.56, erminio.ottone_69@libero.i= t wrote:

I do not support sending this LS in its current form.

The LS is= currently stating that the IETF is not committed to deliver to ITU-T
w= hat it was promised in the JWT agreement.

What is the real concern t= he LS is trying to resolve? The fact that the
document is not based on = an IETF RFC?

----Messaggio originale----
Da: stbryant@cisco.com
Data: 10-gen-2011 11.56
A: "mpls@ietf.org"<mpls@ietf.org>
Ogg: [mpls] Draft: Response to Updated draft Reco= mmendation G.tpoam [Ref
043.02]

I propose to send the following Liaison Response = to the ITU-T on Friday
14th January and am posting it to the MPLS WG lis= t for review.

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

Response to Updated draft Recommendation G.tpoam = [Ref 043.02]

From: IETF Liaison to ITU-T on MPLS stbryant@ci= sco.com
To: tsbsg15@itu.int, greg.jones@itu.int, = hiroshi.ota@itu.int, IAB@ietf.org
CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com
stbryant@cisco.com, adrian.fa= rrel@huawei.com, mpls@ietf.org
yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com
ghani.abbas@ericsson.com, hhelvoort@huawei.com
malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com

For Action

The MPLS Working Group notes that this document c= ontains text describing
MPLS-TP OAM protocols not designed and standardiz= ed using the IETF
Standards process. Specifically it uses material = from
draft-bhh-mpls-tp-oam-y1731-06.

We wish to draw your attention to the status sect= ion of
draft-bhh-mpls-tp-oam-y1731-06 which states:
<= /BLOCKQUOTE>

"Internet-Drafts are draft documents valid for a = maximum of six months
and may be updated, replaced, or obsoleted by oth= er documents at any
time. It is inappropriate to use Internet-Drafts = as reference material
or to cite them other than as "work in progress".=

Please also note that since the draft filename st= arts with the prefix
string "draft-bhh" this clearly identifies it to = the reader as a
document expressing the personal technical views = of the authors and
hence hence as a document that that does not have= any acknowledged level
of IETF consensus.

Since the text of draft Recommendation for G.tpoa= m is based on an
MPLS-TP OAM protocol not designed within the IETF= Standards Process this
is a breach of the SG15 agreement with the IETF a= s published in Report
of the first meeting of Working Party 3/15 Transp= ort network structures
(2009-2012) (Geneva, 1 =E2=80=93 12 December 2008= ) which can be found at
http://www.itu.in= t/md/T09-SG15-R-0004/en

Please confirm that the ITU-T intends to continue= with the joint work on
MPLS-TP and that the ITU-T will align this recomm= endation with the IETF
MPLS-TP OAM design before advancing this document= through the ITU-T
publication process.

The MPLS Working Group would also like to draw th= e attention of ITU-T
SG15 to the IETF copyright rules. Please see
=
http://trustee.ietf.org/licens= e-info/archive/IETF-Trust-License-Policy-
20091228.htm =
for further details.

Since this draft Recommendation contains text in = which the ITU-T SG15
has proposed making changes to IETF protocols wit= hout the approval of
the IETF, the MPLS Working Group have referred th= is liaison to the IAB
for their consideration.


=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.i= etf.org/mailman/listinfo/mpls



________________________= _______________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

---
=E6=9D=8E=E6=9F=AF=E7=9D=BF
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc=



------=_Part_346839_27336339.1295096151995-- From erminio.ottone_69@libero.it Sat Jan 15 04:54:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5783A6B5B for ; Sat, 15 Jan 2011 04:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z5iasoa+1zK for ; Sat, 15 Jan 2011 04:54:18 -0800 (PST) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by core3.amsl.com (Postfix) with ESMTP id C86813A6AA9 for ; Sat, 15 Jan 2011 04:54:17 -0800 (PST) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4D319988.01AD,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail23 (172.31.0.48) by cp-out2.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D10BE650181D2CD; Sat, 15 Jan 2011 13:56:40 +0100 Message-ID: <24033832.3666581295096200780.JavaMail.defaultUser@defaultHost> Date: Sat, 15 Jan 2011 13:56:40 +0100 (CET) From: "erminio.ottone_69@libero.it" To: , Christopher LILJENSTOLPE MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.142.79 Cc: "mpls@ietf.org" , stbryant@cisco.com Subject: [mpls] R: Re: R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 12:54:18 -0000 We have already violated our commitments under the JWT agreement multiple= =20 times >----Messaggio originale---- >Da: erosen@cisco.com >Data: 14-gen-2011 15.18 >A: "Christopher LILJENSTOLPE" >Cc: "mpls@ietf.org", >Ogg: Re: [mpls] R: Draft: Response to Updated draft Recommendation=09G.tpo= am=20 [Ref 043.02] > > >> It is a statement that identifies that the ITU-T did not follow the JWT >> agreement between the IETF and the ITU-T, nor internal ITU-T and IETF >> processes. =C2=A0It does not say that the IETF will not meet it's obliga= tions >> under the JWT if the request is made the correct way. =C2=A0It's not a "= bugger >> off" it's a "please work with us in the manner previously agreed and >> respect our process" > >I don't understand why the Liaison is so measured and restrained >(wishy-washy). Since the ITU-T has breached the agreement, I don't see wh= y >the IETF should be thought to have any further obligations under the JWT. >Shouldn't the liaison state the consequences of this breach? > > > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Sat Jan 15 04:59:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50BD53A6D43 for ; Sat, 15 Jan 2011 04:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhhs4rXcLQOs for ; Sat, 15 Jan 2011 04:59:47 -0800 (PST) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by core3.amsl.com (Postfix) with ESMTP id 973E33A6BD7 for ; Sat, 15 Jan 2011 04:59:46 -0800 (PST) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0209.4D319AD3.01D4,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail23 (172.31.0.48) by cp-out2.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D10BE650181E140; Sat, 15 Jan 2011 14:02:11 +0100 Message-ID: <13335901.3667141295096531759.JavaMail.defaultUser@defaultHost> Date: Sat, 15 Jan 2011 14:02:11 +0100 (CET) From: "erminio.ottone_69@libero.it" To: , "mpls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.45.142.79 Subject: [mpls] R: Fwd: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 12:59:49 -0000 The new LS text does not address my concern. The LS is now stating that although the IETF is not commited to deliver to = ITU- T what it was promised in the JWT agreement, the IETF will keep saying the= =20 opposite. >----Messaggio originale---- >Da: stbryant@cisco.com >Data: 15-gen-2011 9.50 >A: "mpls@ietf.org" >Ogg: [mpls] Fwd: Response to Updated draft Recommendation G.tpoam [Ref=20 043.02] > >I would like to thank the MPLS Working Group for the review of this=20 >liaison. > >I have sent the following to the ITU-T which I believe to be factually=20 >correct. > >Regards > >Stewart >(IETF Liaison to ITU-T on MPLS) > > >-------- Original Message -------- >Subject: =09[mpls] Response to Updated draft Recommendation G.tpoam [Ref= =20 >043.02] >Date: =09Sat, 15 Jan 2011 08:49:16 +0000 >From: =09Stewart Bryant >Reply-To: =09stbryant@cisco.com >To: =09tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg=20 >, Hiroshi Ota , IAB >CC: =09mpls@ietf.org , Greg ,=20 >Malcolm.BETTS , statements@ietf.org,=20 >yoichi.maeda@ttc.or.jp, ITU-T SG15 TSB@cisco.com, Lam, Hing-Kam (Kam)=20 >, Patrik F=C3=A4ltstr=C3=B6m , = Adrian=20 >Farrel , Stewart Bryant ,=20 >Huub Van Helvoort , Ghani Abbas=20 > > > > >Title: Response to Updated draft Recommendation G.tpoam [Ref 043.02] > >Submission Date: 15th January 2011 > >From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com >To: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > iab@ietf.org >CC: swallow@cisco.com > loa@pi.nu > paf@cisco.com > stbryant@cisco.com > adrian.farrel@huawei.com > mpls@ietf.org > yoichi.maeda@ttc.or.jp > steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com > hhelvoort@huawei.com > malcolm.betts@zte.com.cn > kam.lam@alcatel-lucent.com > statements@ietf.org > >Response Contact: stbryant@cisco.com >Technical Contact: stbryant@cisco.com > >Purpose: For Action >Deadline: 15th March 2011 > >Thank you for your liaison statement "LS233 - Updated draft >Recommendation G.tpoam [Ref 043.01]" > >The MPLS Working Group notes that this document contains >text describing MPLS-TP OAM protocols not designed and >standardized using the IETF Standards process. Specifically it >uses material from draft-bhh-mpls-tp-oam-y1731-06. Please may we >draw your attention to the status section of all Internet-Drafts >which says: > >"Internet-Drafts are draft documents valid for a maximum of six >months and may be updated, replaced, or obsoleted by other >documents at any time. It is inappropriate to use Internet-Drafts >as reference material or to cite them other than as >"work in progress". > >Please also note that since the draft filename starts with >the prefix string "draft-bhh" this clearly identifies it to >the reader as a document expressing the personal technical >views of the authors and hence hence as a document that that >does not have any acknowledged level of IETF consensus. > >Since the text of draft Recommendation for G.tpoam is based >on an MPLS-TP OAM protocol not designed within the IETF >Standards Process this is a breach of the SG15 agreement >with the IETF as published in "Report of the first meeting >of Working Party 3/15 Transport network structures >(2009-2012)" (Geneva, 1 =E2=80=93 12 December 2008) which can >be found at http://www.itu.int/md/T09-SG15-R-0004/en. As a >consequence the MPLS WG has not been asked to review this >Draft Recommendation by the IETF management. When the ITU-T >SG15 liaises a draft Recommendation written in accordance >with the above agreement, IETF management will ask the MPLS >WG to perform an in depth review. We look forward to receiving >your next draft. > >Please confirm that the ITU-T intends to continue with the >joint work on MPLS-TP and that the ITU-T will align this >recommendation with the IETF MPLS-TP OAM design before advancing >this document through the ITU-T publication process. > >You should also be aware of the IETF copyright rules. Please >see http://trustee.ietf.org/license-info/archive/IETF- >Trust-License-Policy-20091228.htm for further details. > >Since this draft Recommendation contains text in which >the ITU-T SG15 has proposed making changes to IETF protocols >without the approval of the IETF, the MPLS Working Group >have referred this liaison to the IAB for their >consideration. > >Please can we take this opportunity state that the IETF >is committed to developing the MPLS-TP solution as described >in the Joint Working Team Recommendations and meeting >the jointly agreed MPLS-TP requirements documented in >RFC5654. > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From wwwrun@core3.amsl.com Sun Jan 16 13:21:28 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D281C3A6E62; Sun, 16 Jan 2011 13:21:28 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110116212128.D281C3A6E62@core3.amsl.com> Date: Sun, 16 Jan 2011 13:21:28 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, malcolm.betts@zte.com.cn, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, ghani.abbas@ericsson.com, hhelvoort@huawei.com, stbryant@cisco.com Subject: [mpls] Updated Liaison Statement, "LS232 - Updated draft Recommendation G.8121 [Ref 042.01]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 21:21:28 -0000 Title: LS232 - Updated draft Recommendation G.8121 [Ref 042.01] Submission Date: 2010-12-03 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=982 Please reply by 2011-01-17 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com Purpose: For comment Body: Attachment(s): LS232 - Updated draft Recommendation G.8121 [Ref 042.01] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1150.pdf) LS232 - Updated draft Recommendation G.8121 [Ref 042.01] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1165.pdf) From mach@huawei.com Mon Jan 17 01:15:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14363A6D1F for ; Mon, 17 Jan 2011 01:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxykQOVgM+5a for ; Mon, 17 Jan 2011 01:15:51 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0538C3A6D1A for ; Mon, 17 Jan 2011 01:15:51 -0800 (PST) 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 <0LF500ERSTQZ1K@szxga04-in.huawei.com> for mpls@ietf.org; Mon, 17 Jan 2011 17:16:11 +0800 (CST) Received: from C55527A ([10.110.98.37]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF500LJRTQXIC@szxga04-in.huawei.com> for mpls@ietf.org; Mon, 17 Jan 2011 17:16:11 +0800 (CST) Date: Mon, 17 Jan 2011 17:16:09 +0800 From: Mach Chen To: mpls@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal Subject: [mpls] One question about U and F-bit for Status TLV X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 09:15:52 -0000 Hi, I have one question about U and F-bit setting for Status TLV. In Section 3.3, the F-bit of a TLV is defined as: "F-bit Forward unknown TLV bit. This bit applies only when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. ..." And in Section 3.4.6. The definition of Status TLV says: "U-bit SHOULD be 0 when the Status TLV is sent in a Notification message. SHOULD be 1 when the Status TLV is sent in some other message. F-bit SHOULD be the same as the setting of the F-bit in the Status Code field." So, for a Notification message contained Status TLV, the F-bit of Status TLV should make no sence. And if an LSR receives a Nofication message and it does not know the Status TLV, the entrie Notification message MUST be ignored. But following up, the Status Code defines: "F-bit Forward bit. If set (=1), the notification SHOULD be forwarded to the LSR for the next-hop or previous-hop for the LSP, if any, associated with the event being signaled. If clear (=0),the notification SHOULD NOT be forwarded." It seems that it wants to use the F-bit to control whether to forward the notification messsage, but this should not work since the U-bit is clear. I am not sure which is the intent of the specification. I'd appreciate that someone clarify this! Best regards, Mach From mach@huawei.com Mon Jan 17 01:53:09 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2EE228C1E8 for ; Mon, 17 Jan 2011 01:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01nnvBS9LjHq for ; Mon, 17 Jan 2011 01:53:08 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BEE4D28C1E1 for ; Mon, 17 Jan 2011 01:53:08 -0800 (PST) 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 <0LF500I3AVIUA3@szxga04-in.huawei.com> for mpls@ietf.org; Mon, 17 Jan 2011 17:54:30 +0800 (CST) Received: from C55527A ([10.110.98.37]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF500B3VVIR6L@szxga04-in.huawei.com> for mpls@ietf.org; Mon, 17 Jan 2011 17:54:30 +0800 (CST) Date: Mon, 17 Jan 2011 17:54:27 +0800 From: Mach Chen In-reply-to: To: Mach Chen , mpls@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [mpls] One question about U and F-bit for Status TLV X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 09:53:09 -0000 The question is about RFC5036 Best regards, Mach -------------------------------------------------- From: "Mach Chen" Sent: Monday, January 17, 2011 5:16 PM To: Subject: [mpls] One question about U and F-bit for Status TLV > Hi, > > I have one question about U and F-bit setting for Status TLV. > > In Section 3.3, the F-bit of a TLV is defined as: > "F-bit > Forward unknown TLV bit. This bit applies only when the U-bit is set > and the LDP message containing the unknown TLV is to be forwarded. ..." > > And in Section 3.4.6. > The definition of Status TLV says: > "U-bit > SHOULD be 0 when the Status TLV is sent in a Notification message. > SHOULD be 1 when the Status TLV is sent in some other message. > F-bit > SHOULD be the same as the setting of the F-bit in the Status Code > field." > > So, for a Notification message contained Status TLV, the F-bit of Status > TLV should make no sence. And if an LSR receives a Nofication message and > it does not know the Status TLV, the entrie Notification message MUST be > ignored. > > But following up, the Status Code defines: > "F-bit > Forward bit. If set (=1), the notification SHOULD be forwarded to > the LSR for the next-hop or previous-hop for the LSP, if any, associated > with the event being signaled. If clear (=0),the notification SHOULD NOT > be forwarded." > > It seems that it wants to use the F-bit to control whether to forward the > notification messsage, but this should not work since the U-bit is clear. > > I am not sure which is the intent of the specification. I'd appreciate > that someone clarify this! > > Best regards, > Mach > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From ietf@cdl.asgaard.org Mon Jan 17 03:50:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026F03A6F33 for ; Mon, 17 Jan 2011 03:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjEh9uF8GXb7 for ; Mon, 17 Jan 2011 03:50:22 -0800 (PST) Received: from asgaard.org (ratatosk.asgaard.org [204.29.150.73]) by core3.amsl.com (Postfix) with ESMTP id 099C63A6F2B for ; Mon, 17 Jan 2011 03:50:19 -0800 (PST) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTP id 8BCF6A0CD60; Mon, 17 Jan 2011 11:52:51 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-28--869611054" From: Christopher LILJENSTOLPE In-Reply-To: <24033832.3666581295096200780.JavaMail.defaultUser@defaultHost> Date: Mon, 17 Jan 2011 22:52:48 +1100 Message-Id: References: <24033832.3666581295096200780.JavaMail.defaultUser@defaultHost> To: "erminio.ottone_69@libero.it" Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: "mpls@ietf.org" , stbryant@cisco.com Subject: Re: [mpls] R: Re: R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 11:50:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-28--869611054 Content-Type: multipart/alternative; boundary=Apple-Mail-27--869611105 --Apple-Mail-27--869611105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That may be your opinion Erminio, but I can assure you that it is not a = universally held one. Or, are you offically talking for SG15 now? Christopher On 15Jan2011, at 23.56, erminio.ottone_69@libero.it wrote: > We have already violated our commitments under the JWT agreement = multiple=20 > times >=20 >> ----Messaggio originale---- >> Da: erosen@cisco.com >> Data: 14-gen-2011 15.18 >> A: "Christopher LILJENSTOLPE" >> Cc: "mpls@ietf.org", >> Ogg: Re: [mpls] R: Draft: Response to Updated draft Recommendation = G.tpoam=20 > [Ref 043.02] >>=20 >>=20 >>> It is a statement that identifies that the ITU-T did not follow the = JWT >>> agreement between the IETF and the ITU-T, nor internal ITU-T and = IETF >>> processes. It does not say that the IETF will not meet it's = obligations >>> under the JWT if the request is made the correct way. It's not a = "bugger >>> off" it's a "please work with us in the manner previously agreed and >>> respect our process" >>=20 >> I don't understand why the Liaison is so measured and restrained >> (wishy-washy). Since the ITU-T has breached the agreement, I don't = see why >> the IETF should be thought to have any further obligations under the = JWT. >> Shouldn't the liaison state the consequences of this breach? >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 >=20 --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-27--869611105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = may be your opinion Erminio, but I can assure you that it is not a = universally held one.   Or, are you offically talking for SG15 = now?

Christopher


O= n 15Jan2011, at 23.56, erminio.ottone_69@libero.it wrote:

A: "Christopher = LILJENSTOLPE"<ietf@cdl.asgaard.org>
Cc: "mpls@ietf.org"<mpls@ietf.org>, <stbryant@cisco.com>
Ogg: Re: [mpls] R: Draft: Response to = Updated draft Recommendation G.tpoam
[Ref = 043.02]


It is a statement that identifies that the ITU-T did not = follow the JWT
agreement between the IETF and = the ITU-T, nor internal ITU-T and = IETF
processes.  It does not say that the IETF will not = meet it's obligations
under the JWT if the request is = made the correct way.  It's not a = "bugger
off" it's a "please work with us in the manner previously = agreed and
respect our = process"

I don't = understand why the Liaison is so measured and = restrained
(wishy-washy). =  Since the ITU-T has breached the agreement, I don't see = why
the IETF should be thought = to have any further obligations under the = JWT.
Shouldn't the liaison = state the consequences of this breach?





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






= --Apple-Mail-27--869611105-- --Apple-Mail-28--869611054 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNNC2QAAoJEGmx2Mt/+Iw/zbgH/jMM07Mugk4071+awzuLwF3U q6sz/VlM5gfyi2uaIdqnkaVm4b44PdA6HRYjnSxKlXQHcllskv/rdw8w2eRAtBr2 g7Vh1bZTSDvACJhBC5IIyVVW1hMJgpg1TIuqd6wgeYlssKQ80fMHYsGuECkZvS4Y F+HWvRLLNbucVRwzFW3gIsHZtKApd0UBNgcQbIrGVrbfzr+oW6PZDn0de9sUQ2+t MlF3XhWksxNTAKEw8LKrVl5Cnon6leOzngQzQi+2NI4HifafmFBzUCq+UquSIDnK FyKDmYlsBKcdRh3p67xwus0AXIWPuf7JJME8Sy/vdF9LhtJEFe0FUl1pe3yJa74= =0HQL -----END PGP SIGNATURE----- --Apple-Mail-28--869611054-- From erminio.ottone_69@libero.it Mon Jan 17 10:16:36 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A394028C20A for ; Mon, 17 Jan 2011 10:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKWkx0Mx5157 for ; Mon, 17 Jan 2011 10:16:35 -0800 (PST) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by core3.amsl.com (Postfix) with ESMTP id BCF4C28C205 for ; Mon, 17 Jan 2011 10:16:34 -0800 (PST) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0209.4D348802.0035,ss=1,re=0.000,fgs=0 X-libjamoibt: 1419 Received: from wmail40 (172.31.0.229) by cp-out2.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4D10BE6501A4997D; Mon, 17 Jan 2011 19:18:41 +0100 Message-ID: <7537310.3973121295288321688.JavaMail.defaultUser@defaultHost> Date: Mon, 17 Jan 2011 19:18:41 +0100 (CET) From: "erminio.ottone_69@libero.it" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_375071_30081047.1295288321688" X-SenderIP: 79.31.131.65 Cc: "mpls@ietf.org" , stbryant@cisco.com Subject: [mpls] R: Re: R: Re: R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:16:36 -0000 ------=_Part_375071_30081047.1295288321688 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is my opinion as an individual after having read RFC 5317 and looked a= t the facts that followed. ----Messaggio originale---- Da: ietf@cdl.asgaard.org Data: 17-gen-2011 12.52 A: "erminio.ottone_69@libero.it" Cc: , "mpls@ietf.org", Ogg: Re: R: Re: [mpls] R: Draft: Response to Updated draft Recommendation G= .tpoam [Ref 043.02] That may be your opinion Erminio, but I can assure you that it is not a uni= versally held one. Or, are you offically talking for SG15 now? Christopher On 15Jan2011, at 23.56, erminio.ottone_69@libero.it wrote: We have already violated our commitments under the JWT agreement multiple= =20 times ----Messaggio originale---- Da: erosen@cisco.com Data: 14-gen-2011 15.18 A: "Christopher LILJENSTOLPE" Cc: "mpls@ietf.org", Ogg: Re: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam= =20 [Ref 043.02] It is a statement that identifies that the ITU-T did not follow the JWT agreement between the IETF and the ITU-T, nor internal ITU-T and IETF processes. It does not say that the IETF will not meet it's obligations under the JWT if the request is made the correct way. It's not a "bugger off" it's a "please work with us in the manner previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained (wishy-washy). Since the ITU-T has breached the agreement, I don't see why the IETF should be thought to have any further obligations under the JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc ------=_Part_375071_30081047.1295288321688 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This is my opinion as an individual after having read RFC 5317 and looke= d at the facts that followed.

----Messaggio originale----
Da: ietf@cdl.asgaard.org
Data= : 17-gen-2011 12.52
A: "erminio.ottone_69@libero.it"<erminio.ottone_6= 9@libero.it>
Cc: <erosen@cisco.com>, "mpls@ietf.org"<mpls@ie= tf.org>, <stbryant@cisco.com>
Ogg: Re: R: Re: [mpls] R: Draft: = Response to Updated draft Recommendation G.tpoam [Ref 043.02]

MPLS & Ethernet World will start in three weeks. =

 

Optical layer integration, mobile backhaul, data center = interconnection: the main technical issues will be covered by the most = well-known specialists.

The debate will cover MPLS-TP = OAM issues.

 

More info: http://www.upperside.fr/

 

 

 

------=_NextPart_000_0001_01CBB722.72E54430-- From Adrian.Farrel@huawei.com Tue Jan 18 08:36:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95143A6FEC for ; Tue, 18 Jan 2011 08:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6dNVXkbVuO3 for ; Tue, 18 Jan 2011 08:36:41 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 42C3428C146 for ; Tue, 18 Jan 2011 08:36:41 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF8004NL8XHT6@usaga03-in.huawei.com> for mpls@ietf.org; Tue, 18 Jan 2011 10:39:18 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF800FCU8XGWE@usaga03-in.huawei.com> for mpls@ietf.org; Tue, 18 Jan 2011 10:39:17 -0600 (CST) Date: Tue, 18 Jan 2011 16:39:14 +0000 From: Adrian Farrel To: mpls@ietf.org Message-id: <04a801cbb72e$3fa4e1a0$beeea4e0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu3LiuFEznYfIytQVe8gGm30+XRnw== Subject: [mpls] Unsubstantiated Assertions on this Mailing List X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:36:44 -0000 Hi, I have been discussing some of the emails on this list with the working group chairs, and we have agreed that I should respond to a couple of points. Don't feel bad if I didn't pick on something you said: my points apply to all similar cases. > Do you forgot that it is in IETF79 plenary in Beijing, the meeting was closed before 5 > minutes as it was planed though it was said that itu-t expert can present if time is > enough? I don't think this refers to the plenary meeting, but to the second MPLS working group meeting. I don't think we have ITU-T experts attending IETF meetings except by special invitation. I wasn't aware of any special invitations, so I think this refers to an IETF participant. It is worth noting that there were a number of people who asked to present on their drafts in the IETF meeting, but for which there was not time on the agenda. The working group chairs constructed the agenda according to the normal principles focusing on the working group charter, the current working group drafts, and the topics of discussion on the mailing list that they felt could most profitably be resolved through face-to-face discussion. There was no objection to the agenda when it was posted before the meeting; the only objection came some ten or fifteen minutes into the first of the two sessions that the WG held. Indeed, this period of objection and discussion of the agenda used up a considerable amount of time that might have been better used discussing drafts. During the interval between the two meetings, I convinced the WG chairs that they would allow an extra agenda item for one person from a service provider to present his company's view of MPLS-TP deployment scenarios and requirements if there was time. Although the meeting ran significantly behind schedule, it caught up with itself very suddenly, and it is true that the meeting closed almost exactly five minutes early without the additional presentation. The chairs judged that by the time the presenter was installed and had his slides up, he would have had less than four minutes to speak. That would clearly have been pointless for him and the working group. Therefore, we moved this presentation to the Routing Area working group where there was sufficient time - in the end the presentation and questions took twelve minutes. The meeting was attended by a good number of people who normally participate in the MPLS working group, so the message was not lost. The presentation attracted a number of useful questions from people who work at other service providers: something that would not have been possible within the MPLS working group schedule. > Do you forgot that IETF ignored ITU-T inputs on some RFCs before approving >them as RFCs such as RFC 5921 and draft-ietf-mpls-tp-survivability-framework > etc? This is quite a claim! Let us look at the two documents named here. == RFC 5921 was originally draft-ietf-mpls-tp-framework == 2008-11-28 draft-ietf-mpls-tp-framework-00 2009-06-30 draft-ietf-mpls-tp-framework-01 2009-07-10 draft-ietf-mpls-tp-framework-02 2009-08-28 draft-ietf-mpls-tp-framework-03 2009-09-11 draft-ietf-mpls-tp-framework-04 2009-09-25 draft-ietf-mpls-tp-framework-05 2009-20-16 draft-ietf-mpls-tp-framework-06 2009-10-16 Sent to ITU-T for early review (deadline 2009-11-09) 2009-11-10 Review comments received from ITU-T (further comments promised by 2009-11-25) (For action deadline 2010-01-02) 2009-12-22 draft-ietf-mpls-tp-framework-07 2010-01-12 Response to ITU-T noting that no specific action was requested, and that no further comments had been received. Promise to consider all review comments. 2010-01-22 draft-ietf-mpls-tp-framework-08 2010-01-29 draft-ietf-mpls-tp-framework-09 2010-02-04 draft-ietf-mpls-tp-framework-10 2010-02-04 Sent to ITU-T for review during WG last call. (deadline 2010-03-05 - twice the normal WG review period) 2010-02-05 Response to 2009-11-10 comments sent to ITU-T 2010-03-05 Review comments received from ITU-T (For action deadline 2010-04-12) 2010-04-02 draft-ietf-mpls-tp-framework-11 2010-04-03 Sent to ITU-T for review during second WG last call. Last call strictly limited to discussion of resolution of issues raised in previous last call. (deadline 2010-04-17)s 2010-04-06 Response to 2010-04-12 comments sent to ITU-T 2010-04-07 IETF last call starts 2010-04-19 Review comments received from ITU-T (For action deadline 2010-05-27) 2010-04-21 IETF last call completes 2010-05-05 draft-ietf-mpls-tp-framework-12 2010-05-06 IESG evaluation starts 2010-05-20 IESG telechat 2010-05-24 Document approved for publication as RFC 2010-06-24 Spontaneous further review from ITU-T (For action deadline 2010-07-30) 2010-07-09 RFC 5921 published 2010-07-27 Response to 2010-07-27 review comments Minor comments that were previously communicated informally had already been accepted during RFC Editing. Major comment were too late for acceptance. Correct way forward explained. 2010-08-31 draft-ietf-mpls-tp-nni-uni-00 2010-11-03 Sent to ITU-T for review during WG last call of draft-ietf-mpls-tp-uni-nni. (deadline 2010-11-23) 2010-11-26 draft-ietf-mpls-tp-nni-uni-01 (including change that will be requested in 2010-12-03 review) 2010-12-03 Review comments received from ITU-T. Only one minor typographical issue. (For action 2011-01-14) 2010-12-08 draft-ietf-mpls-tp-nni-uni-02 2010-12-09 IETF last call starts 2010-12-23 IETF last call ends 2011-01-07 draft-ietf-mpls-tp-nni-uni-03 2011-01-07 IESG evaluation starts 2011-01-15 Response to 2010-12-03 review comments. Looking at the timeline and results here, I cannot say that either SDO was absolutely perfect in its adherence to dates or provision of the most useful information that is possible. However, it also appears to me that the right technical result has been achieved to the agreement of all parties. I find it simply ridiculous to suggest that the processing of this document somehow constitutes an attempt by the IETF to disregard ITU-T input. Instead, it suggests to me that the IETF is very willing to listen to the input and to make the necessary changes. == draft-ietf-mpls-tp-survivability-framework == * Full disclosure: I am an author of this document 2009-04-06 draft-ietf-mpls-tp-survive-fwk-00 2009-10-25 draft-ietf-mpls-tp-survive-fwk-01 2009-10-25 draft-ietf-mpls-tp-survive-fwk-02 2009-10-26 Sent to ITU-T for early review (deadline 2010-11-21) 2009-11-09 draft-ietf-mpls-tp-survive-fwk-03 2009-11-18 Review comments received from ITU-T (For action deadline 2010-04-30) 2010-03-08 draft-ietf-mpls-tp-survive-fwk-04 2010-03-10 Sent to ITU-T for review during WG last call (deadline 2010-04-02) 2010-03-10 Disposition of 2009-11-18 review comments 2010-04-12 Review comments received from ITU-T (For action deadline 2010-04-25) 2010-04-19 draft-ietf-mpls-tp-survive-fwk-05 2010-04-21 Sent to ITU-T for review during WG last call (deadline 2010-05-05) 2010-04-22 IETF last call starts 2010-05-05 Review comments received from ITU-T (For action deadline 2010-05-28) 2010-05-06 IETF last call ends 2010-06-04 Disposition of 2010-05-05 review comments 2010-06-20 draft-ietf-mpls-tp-survive-fwk-06 2010-06-24 IESG evaluation starts 2010-06-30 Spontaneous further review from ITU-T (For action deadline 2010-07-30) 2010-07-01 Document approved for publication as RFC 2010-07-01 Publication held by Area Director pending examination of 2010-06-30 review comments 2010-07-13 Document approved for publication as RFC 2010-07-16 Disposition of 2010-06-30 review comments Minor comments are largely already addressed or taken as changes in RFC Editor note. Major changes are too late and advice on how to proceed is given. 2010-07-22 ITU-T states no plan for further review and no plans to review disposition of 2010-07-16. (For action deadline 2010-08-31 but no action requested in the liaison) Again, the process was long, and the flow of information detailed. Again, the majority of input came very late in the process (some of it too late). Again, the IETF did what it could to speed the process as requested. Again, the IETF took on board review comments that would normally have been considered to have arrived too late. In these two cases, I have done the leg-work to collect the data and supply the details around the claims that were made. I find the necessity to "prove innocence" irksome, and the presence of unsubstantiated allegations on the mailing list offensive. Next time anyone wants to make a claim like this, could they please supply the details to back up their claims. Please note that the ITU-T experts participating in the reviews in the ITU-T did not bring their comments to the IETF as individuals for discussion on the mailing list despite many of them being subscribed. One might draw the conclusion that, rather than participating in the development of MPLS-TP within the IETF using the normal IETF process, these individuals were waiting until the last possible minute to raise their concerns and attempting to do so using the weight of the ITU-T rather than their own technical arguments - of course, I do not draw any such conclusions. > I am wondering whether IETF have already break the JWT agreement or not? If anyone wants to "wonder" this in public, they have an absolute responsibility to provide examples. IMHO the IETF has "gone the extra mile" by allowing comments outside the normal process, accepting comments via liaison from people who are normal WG participants, and by attempting to speed up the IETF process in order to achieve more rapid delivery as requested. As yet, I have seen no credible evidence provided that the IETF has broken the JWT agreement, and I find unsubstantiated suggestions that this has happen to be misleading. > It is right to accuse ITU-T on standardize G.tpoam in the liaison text with agreement. I have trouble parsing this sentence, but I think it is objecting to liaison text that says that the inclusion of protocol-specific text in a draft MPLS-TP Recommendation appears to be in violation of an agreement to carry out all MPLS-TP development within the IETF using normal IETF processes. To evaluate this, we must observe that SG15 agreed in plenary session ( http://www.itu.int/md/T09-SG15-R-0004/en) to accept the recommendations of the JWT that IETF development would be done in the IETF following normal IETF process. There may be many different personal opinions about where protocol development should be done, but it is hard to argue with the fact of the agreement. > We have already violated our commitments under the JWT agreement > multiple times This is an opinion, but there is no substance provided. I note that the author counts himself as part of the problem, but does not say exactly what he did wrong. This type of statement is not helpful to reasoned discussion. > The LS is now stating that although the IETF is not commited to > deliver to ITU-T what it was promised in the JWT agreement This is also an opinion, but I can find nothing in the LS that makes any such statement. Instead of the assertion, it would have been really helpful if the poster had pointed to the specific text that was a problem. To the contrary, the liaison makes a specific statement of commitment to the development of MPLS-TP. - - - - - - Now, I am quite happy that people should discuss the workings of the MPLS working group and the IETF in general (so far as it impacts on the MPLS working group) on either of the MPLS working group's mailing lists (mpls or mpls-tp). But I am not happy that history and facts are misrepresented by accident or on purpose. Therefore, I call on everyone on the mailing list to carefully check their facts and substantiate their arguments before posting to the list. There is no reason why discussions of process should be subject to any less technical rigour than discussions of technical issues. Likewise, I call on all people with an interest in MPLS-TP to participate in the technical discussions on the mailing list. Objections to working group documents are valid and welcome, but they must be reasoned technical discussions: there is no point in saying "I prefer X", you need to say "Y is broken because..." I also request that these discussions take place as early in the cycle as possible: coming with a technical opinion at the time of working group last call is at best a frustration to everyone concerned, but may also be interpreted poorly when the comments come from someone who is subscribed to the mailing list and has a known strong interest in the technology. Thank you, Adrian (as AD) From Internet-Drafts@ietf.org Tue Jan 18 10:00:11 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75E93A7068; Tue, 18 Jan 2011 10:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C+PX3VfMxyw; Tue, 18 Jan 2011 10:00:10 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE343A6FE2; Tue, 18 Jan 2011 10:00:04 -0800 (PST) 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.10 Message-ID: <20110118180004.8071.22670.idtracker@localhost> Date: Tue, 18 Jan 2011 10:00:04 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-fastreroute-mib-16.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:00:12 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin, T. Nadeau, K. Koushik Filename : draft-ietf-mpls-fastreroute-mib-16.txt Pages : 47 Date : 2011-1-18 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-16.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-mpls-fastreroute-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-18095839.I-D@ietf.org> --NextPart-- From eosborne@cisco.com Tue Jan 18 10:13:19 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D981E3A706A for ; Tue, 18 Jan 2011 10:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.166 X-Spam-Level: X-Spam-Status: No, score=-11.166 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmIaC2FooWAw for ; Tue, 18 Jan 2011 10:13:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 85A5E3A7023 for ; Tue, 18 Jan 2011 10:13:17 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADZnNU2tJV2Z/2dsb2JhbACkVHOoP5oJhVAEhG+JWQ Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2011 18:15:55 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0IIFsgv016884 for ; Tue, 18 Jan 2011 18:15:54 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 12:15:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 12:15:53 -0600 Message-ID: In-Reply-To: <4D315842.6010708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Fwd: Response to Updated draft Recommendation G.8151 [Ref 045.02] Thread-Index: Acu0jMviUXRSfOvTQN6mU9Yp41hyKwCrcnUg References: <4D315842.6010708@cisco.com> From: "Eric Osborne (eosborne)" To: "Stewart Bryant (stbryant)" , X-OriginalArrivalTime: 18 Jan 2011 18:15:54.0964 (UTC) FILETIME=[BF3DC140:01CBB73B] Subject: Re: [mpls] Fwd: Response to Updated draft Recommendation G.8151 [Ref 045.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:13:20 -0000 Hi Stewart- I took a look at the document and I agree that it looks nothing like = draft-bhh/y.1731. The acronyms are different, the tables of contents = across the two documents contain nothing substantial in common, and = g.8151 appears to be about a network management architecture and alarm = hierarchy (node function) rather than a protocol and packet format. = g.8151 doesn't contain any reference to y.1731 or "OAM", both of which = figure heavily in draft-bhh. My first guess is probably the same as = yours was, that the liason statement reused some boilerplate. The fact = that the relevant section in the liason is the gramatically awkward = "This version was developed using all of the relevant the input = documents to the meeting is based on draft-bhh-mpls-tp-oam-y1731-06" = makes it look even more like a typo or cut-and-paste error. That said, there may well be some function in g.8151 that was derived = from a behavior specified in draft-bhh; that'll be much harder to sort = out without deep knowledge of both documents and all the stuff leading = up to them. Is it possible to request some clarity from the ITU-T as to = whether this was a typo or whether there's some actual connection here? For the record, the entire liason is here: https://datatracker.ietf.org/liaison/986/ (1157 is the 'pdf attach', 1156 is the 'pdf body' which refers to = draft-bhh/y.1731 eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Stewart Bryant (stbryant) > Sent: Saturday, January 15, 2011 3:18 AM > To: mpls@ietf.org > Subject: [mpls] Fwd: Response to Updated draft Recommendation G.8151 = [Ref > 045.02] >=20 > Please can the MPLS Working group take a look at G.8151 which can be = found > at https://datatracker.ietf.org/documents/LIAISON/file1157.pdf >=20 > We should particularly look with a view to determining whether as the > liaison body says it "is based on draft-bhh-mpls-tp-oam-y1731-06" or > whether it is actually OAM technology neutral. >=20 > As far as I can see it is neutral and the statement in the liaison = letter > in incorrect, but I would much appreciate someone else taking a look. >=20 > Thanks >=20 > Stewart >=20 >=20 > -------- Original Message -------- > Subject: [mpls] Response to Updated draft Recommendation G.8151 [Ref > 045.02] > Date: Sat, 15 Jan 2011 08:12:52 +0000 > From: Stewart Bryant > Reply-To: stbryant@cisco.com > To: tsbsg15@itu.int, "ITU-T SG15 TSB"@cisco.com, Greg > > CC: mpls@ietf.org , Huub Van Helvoort > , Ghani Abbas , > Malcolm.BETTS , statements@ietf.org, > yoichi.maeda@ttc.or.jp, Lam, Hing-Kam (Kam) = , > Patrik F=E4ltstr=F6m , Adrian Farrel > , Stewart Bryant >=20 >=20 >=20 > Title: Response to Updated draft Recommendation G.8151 [Ref 045.02] >=20 > Submission Date: 15th January 2011 >=20 > From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com > To: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > CC: swallow@cisco.com > loa@pi.nu > paf@cisco.com > stbryant@cisco.com > adrian.farrel@huawei.com > mpls@ietf.org > yoichi.maeda@ttc.or.jp > steve.trowbridge@alcatel-lucent.com > ghani.abbas@ericsson.com > hhelvoort@huawei.com > malcolm.betts@zte.com.cn > kam.lam@alcatel-lucent.com > statements@ietf.org >=20 > Response Contact: stbryant@cisco.com > Technical Contact: stbryant@cisco.com >=20 > Purpose: For Information >=20 > Thank you for your liaison statement "LS237 - Updated draft = Recommendation > G.8151 [Ref 045.01]" >=20 > The MPLS Working Group regrets that due to the numerous holidays since = we > received this liaison, we have not yet been able to review this this > revised version of Draft Recommendation G.8151. >=20 > We will review it and liaise comments before the February ITU-T SG15 > Plenary Meeting. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Tue Jan 18 12:38:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A2C28C117 for ; Tue, 18 Jan 2011 12:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc1qmV4Ref9B for ; Tue, 18 Jan 2011 12:38:03 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1AEF628C14E for ; Tue, 18 Jan 2011 12:38:03 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTTX6yVFxnP5u32PvB8zz60x4PZT3QW9B@postini.com; Tue, 18 Jan 2011 12:40:41 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 Jan 2011 12:39:02 -0800 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, 18 Jan 2011 15:39:02 -0500 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 18 Jan 2011 15:39:00 -0500 Thread-Topic: Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3HYMA39d2ehnN5keIjEDiuC/lkgAAlaTAAAvOhPA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:38:04 -0000 There are at least three questions here: - Do we want one solution for MPLS OAM, or two? - Once we make a decision, do we intend to work to make it happen, or to continue the argument indefinitely? - Do we want standards for the IETF TCP/IP/MPLS protocol suite to be done in one standards body, or independently in two=20 different groups with incompatible standards resulting? Answering these in the reverse order: It is a very bad idea to have two different standards bodies writing incompatible standards for the same protocol. The best that we could hope for in this case would be to severely slow down any attempt to=20 produce standards, with a very real possibility of equipment being=20 deployed that won't interwork, or that might interwork in disastrous=20 ways (it is possible for entire networks to collapse). There is a very long history in the IETF, as well as other standards groups, of multiple groups of people coming into the standards effort with different ideas with regard to what a standard should look like.=20 We work to discuss those ideas and come to a rough consensus on a way=20 forward. At some point we need to stop arguing the same points over and=20 over again and get on with the productive task of actually writing=20 workable standards. It is common for "pre-standards" solutions to be=20 deployed in at least some networks. It is normal that most or usually=20 all vendors involved have to change their products to fit the emerging=20 standard, and normal for vendors and service providers to need to work=20 together to migrate the deployed equipment to follow the standards.=20 Every vendor has been in the situation where they need to update products=20 to match the standards, that is just life. One outcome that has been=20 followed on occasion is that we pick one standards track solution, publish= =20 that solution in standards track RFCs, and document one or more other=20 additional solutions in informational RFCs with the statement that these=20 were offered for consideration in the IETF deliberations that resulted in=20 [reference the standard]. =20 We have not seen any disagreement over the point that the various=20 proposed OAM solutions could be enhanced to fulfill the requirements. The primary justification for having two solutions to do the same thing seems to be "we have already deployed this so you have to accept it".=20 That argument has almost never won in any standards group that we have=20 been involved in (and over the past 30+ years some of us have been=20 involved in IEEE802, Internet Working Groups, ANSI, ISO, Gads, IETF,=20 and at least a few CCITT and ITU-T meetings). There have been times over=20 the past 25 years that the IETF has accepted two solutions for the same=20 thing, and we (the entire IETF community) generally have lived to regret=20 it. The basic summary of what happens is that both get deployed, and we=20 are stuck with interoperability issues and with doing twice the necessary=20 work essentially forever. Ross, Loa, and George (as MPLS WG co-chairs) From huubatwork@gmail.com Tue Jan 18 14:50:00 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2975D28C12B for ; Tue, 18 Jan 2011 14:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZuInuUvIemS for ; Tue, 18 Jan 2011 14:49:59 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 10BCB28C11D for ; Tue, 18 Jan 2011 14:49:58 -0800 (PST) Received: by eyd10 with SMTP id 10so122545eyd.31 for ; Tue, 18 Jan 2011 14:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=20sm6TOLNImw+aaYkqUh66Mm3+BDtJl5EfYr6CNDN9s=; b=wDYkXO+CxxvrECsg/X76jOviUxrkP8Pv0FdXAuE3YiqEri7thdRQzgH0nfOxYaQ+qH 3bcGTFY7DbLBuLMFzCXNltXtLPkIemsOFd/vdu6Q5tBPatDjYdbi4pSFTVIQfgCghEw4 MqiwSshVTNM8vh2SKFTlYNQTLIMA6yYmy0OP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=wlLiyOUziU2+FxwG6If4PPBw7TKgBk15yYiXdFxt0v99Er6n2Avn66//KO9+KApz9p 1n2tzIgH8u4mPcDTNtEJLh7gQF8+Vi1qC5nkuOfEdI+19xweYehI2m56a4by0seUuEGv akxx1CQtE5o+IjbJBiDDwrQD16jF2Fa7/4uRo= Received: by 10.216.35.82 with SMTP id t60mr1809839wea.46.1295391156804; Tue, 18 Jan 2011 14:52:36 -0800 (PST) Received: from McAsterix.local ([81.253.44.162]) by mx.google.com with ESMTPS id 7sm3302400wet.0.2011.01.18.14.52.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 14:52:35 -0800 (PST) Message-ID: <4D3619B1.1090301@gmail.com> Date: Tue, 18 Jan 2011 23:52:33 +0100 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: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:50:00 -0000 Hello Ross, You wrote: > There are at least three questions here: Let me try to answer them > - Do we want one solution for MPLS OAM, or two? I think we want one toolbox with a set of tools. It may happen that there are tools that ook alike but may be different in detail because they are used in a different context. > - Once we make a decision, do we intend to work to make > it happen, or to continue the argument indefinitely? I we agree that there can be different contexts in which dedicated tools from the toolbox can be used the opposition disappears. > - Do we want standards for the IETF TCP/IP/MPLS protocol suite > to be done in one standards body, or independently in two > different groups with incompatible standards resulting? If we agree that there are different contexts, it should be possible to have the context sensitive tools developped by the experts in a particular context/area. Currently I can identify two contexts: -1- packet switched networks, the dedicated tools should behave similar to existing tools -2- packet transport networks, the dedicated tools should behave similar to existing transport technologies. Regards, Huub. -- ***************************************************************** 我爱外点一七三一 From eosborne@cisco.com Tue Jan 18 15:53:45 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22E328C193 for ; Tue, 18 Jan 2011 15:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfKaDvMvEw0a for ; Tue, 18 Jan 2011 15:53:44 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5DBCD28C128 for ; Tue, 18 Jan 2011 15:53:44 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOe2NU2tJV2Z/2dsb2JhbACEDJ9OaHOoC4pXj2CBJIFUgWR0BIRviVk Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2011 23:56:22 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0INuMAT012399; Tue, 18 Jan 2011 23:56:22 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 17:56:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 18 Jan 2011 17:56:21 -0600 Message-ID: In-Reply-To: <4D3619B1.1090301@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3Ym5aBkLUcS5dR9uZ5lr/wPwRygACDEmg References: <4D3619B1.1090301@gmail.com> From: "Eric Osborne (eosborne)" To: "Huub van Helvoort" , X-OriginalArrivalTime: 18 Jan 2011 23:56:22.0287 (UTC) FILETIME=[4EDFE1F0:01CBB76B] Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:53:45 -0000 SGkgSHV1Yi0NCg0KICBJIHRoaW5rIHRoZSBjcnV4IG9mIHlvdXIgcG9pbnRzIGlzIHRoaXM6DQoN Cj4gQ3VycmVudGx5IEkgY2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czoNCj4gLTEtIHBhY2tldCBz d2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ICAg ICAgc2ltaWxhciB0byBleGlzdGluZyB0b29scw0KPiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3 b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ICAgICAgc2ltaWxhciB0 byBleGlzdGluZyB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLg0KDQpJIGRvdWJ0IHdlJ2xsIGV2ZXIg Z2V0IGV2ZXJ5b25lIHRvIGhvbGQgaGFuZHMgYW5kIGFncmVlIGFuZCBzaW5nIGhhcHB5IHNvbmdz IG9uIHRoaXMgcG9pbnQsIGJ1dCBsZXQgbWUgYXNrIGFueXdheXMuICBXaHkgZG8gd2Ugc3RpbGwg bmVlZCBkaWZmZXJlbnQgdG9vbHMgZm9yIHBhY2tldCBzd2l0Y2hlZCB2cyBwYWNrZXQgdHJhbnNw b3J0IG5ldHdvcmtzPyAgVGhlIHR3byB0ZXJtcyBhcmUgc28gc2ltaWxhciB0aGF0IGl0J3Mgbm90 IG9idmlvdXMgb24gaXRzIGZhY2Ugd2hldGhlciB0aGVzZSB0d28gYXJlIGFjdHVhbGx5IGFueSBk aWZmZXJlbnQgYW55IG1vcmUsIGlzIGl0IHJlYWxseSB3b3J0aCBhbGwgdGhlIGhhc3NsZSBmcm9t IGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlPyAgQW5kIGlmIHRoYXQncyB0cnVlIGFuZCB3YXMgdHJ1 ZSBhbGwgYWxvbmcsIHdoeSBkaWQgZXZlcnlvbmUgYWdyZWUgdG8gY29vcGVyYXRlIGluIHRoZSBm aXJzdCBwbGFjZSBbSldUIGFncmVlbWVudF0sIGFuZCBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBv bmx5IGJlIG9uZSBzb2x1dGlvbiBbcmVmLiBSdXNzIEhvdXNlbHkncyBicmllZiB0YWxrIGluIEJl aWppbmddPw0KDQoNCg0KDQoNCmVyaWMNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gSHV1YiB2YW4gSGVsdm9vcnQNCj4gU2VudDogVHVlc2Rh eSwgSmFudWFyeSAxOCwgMjAxMSA1OjUzIFBNDQo+IFRvOiBtcGxzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBH LnRwb2FtIFtSZWYNCj4gMDQzLjAyXQ0KPiANCj4gSGVsbG8gUm9zcywNCj4gDQo+IFlvdSB3cm90 ZToNCj4gDQo+ID4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOg0KPiAN Cj4gTGV0IG1lIHRyeSB0byBhbnN3ZXIgdGhlbQ0KPiANCj4gPiAgICAgIC0gRG8gd2Ugd2FudCBv bmUgc29sdXRpb24gZm9yIE1QTFMgT0FNLCBvciB0d28/DQo+IA0KPiBJIHRoaW5rIHdlIHdhbnQg b25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4NCj4gSXQgbWF5IGhhcHBlbiB0aGF0IHRo ZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBidXQgbWF5IGJlIGRpZmZlcmVudCBpbg0KPiBk ZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2VkIGluIGEgZGlmZmVyZW50IGNvbnRleHQuDQo+IA0K PiA+ICAgICAgLSBPbmNlIHdlIG1ha2UgYSBkZWNpc2lvbiwgZG8gd2UgaW50ZW5kIHRvIHdvcmsg dG8gbWFrZQ0KPiA+ICAgICAgICBpdCBoYXBwZW4sIG9yIHRvIGNvbnRpbnVlIHRoZSBhcmd1bWVu dCBpbmRlZmluaXRlbHk/DQo+IA0KPiBJIHdlIGFncmVlIHRoYXQgdGhlcmUgY2FuIGJlIGRpZmZl cmVudCBjb250ZXh0cyBpbiB3aGljaCBkZWRpY2F0ZWQgdG9vbHMNCj4gZnJvbSB0aGUgdG9vbGJv eCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3NpdGlvbiBkaXNhcHBlYXJzLg0KPiANCj4gPiAgICAgIC0g RG8gd2Ugd2FudCBzdGFuZGFyZHMgZm9yIHRoZSBJRVRGIFRDUC9JUC9NUExTIHByb3RvY29sIHN1 aXRlDQo+ID4gICAgICAgIHRvIGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBpbmRl cGVuZGVudGx5IGluIHR3bw0KPiA+ICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21w YXRpYmxlIHN0YW5kYXJkcyByZXN1bHRpbmc/DQo+IA0KPiBJZiB3ZSBhZ3JlZSB0aGF0IHRoZXJl IGFyZSBkaWZmZXJlbnQgY29udGV4dHMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0bw0KPiBoYXZl IHRoZSBjb250ZXh0IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRzIGlu IGEgcGFydGljdWxhcg0KPiBjb250ZXh0L2FyZWEuDQo+IA0KPiBDdXJyZW50bHkgSSBjYW4gaWRl bnRpZnkgdHdvIGNvbnRleHRzOg0KPiAtMS0gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtzLCB0aGUg ZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCj4gICAgICBzaW1pbGFyIHRvIGV4aXN0aW5n IHRvb2xzDQo+IC0yLSBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRv b2xzIHNob3VsZCBiZWhhdmUNCj4gICAgICBzaW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0 ZWNobm9sb2dpZXMuDQo+IA0KPiBSZWdhcmRzLCBIdXViLg0KPiANCj4gDQo+IC0tDQo+ICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg5oiR54ix5aSW54K55LiA5LiD5LiJ5LiA DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1w bHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From liu.guoman@zte.com.cn Tue Jan 18 21:06:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6A03A6F52 for ; Tue, 18 Jan 2011 21:06:37 -0800 (PST) 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_15=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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJy9iFYFaygS for ; Tue, 18 Jan 2011 21:06:35 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 388753A6EF5 for ; Tue, 18 Jan 2011 21:06:35 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595806486374; Wed, 19 Jan 2011 13:04:48 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 7288.806486374; Wed, 19 Jan 2011 13:01:52 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p0J5940K096543 for ; Wed, 19 Jan 2011 13:09:04 +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 p0J4Y0Pj068827; Wed, 19 Jan 2011 12:34:00 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201101190509.p0J5940K096543@mse02.zte.com.cn> In-Reply-To: To: "Eric Osborne (eosborne)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Wed, 19 Jan 2011 12:34:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-19 12:34:01, Serialize complete at 2011-01-19 12:34:01 Content-Type: multipart/alternative; boundary="=_alternative 001931E54825781D_=" X-MAIL: mse02.zte.com.cn p0J5940K096543 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: mpls@ietf.org, Huub van Helvoort Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 05:06:37 -0000 This is a multipart message in MIME format. --=_alternative 001931E54825781D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksIEh1dWIgYW5kIEVyaWMNCiBtYXliZSBpIHRoaW5rIGl0IGlzIGdvb2Qgc3VnZ2VzdGlvbiB0 byBoYXZlIGFuIHVuaXF1ZSB0b29sIGZvciBwYWNrZXQgDQpzd2l0Y2hlZCBhbmQgdHJhbnNwb3J0 IG5ldHdvcmsuDQpidXQgaW4gZmFjdCwgaW4gbXkgdGhpbmtpbmcsIG5vdyB3ZSBjYW4ndCBmaW5k IGEgdW5pcXVlIHRvb2wgYW5kIHNvbHV0aW9uIA0KdG8gZnVsZmlsIFBTTiBhbmQgUFROIG5ldHdv cmsgcmVxdWlyZW1lbnQuDQppZiB3ZSBoYXZlIGFscmVhZGx5IGZpbmQgdGhlIHVuaXF1ZSBzb2x1 dGlvbiBhbmQgdG9vbCAsd2h5IGRvIHdlIGhhdmUgbm90IA0KYW4gdW5pcXVlIGFncmVlbWVudCBh bmQgYWR2aWNlPw0Kc28gd2UgbmVlZCB0byBjb25zaWRlciAgd2hpY2ggc29sdXRpb24gYW5kIHRv b2wgd2lsbCBiZSBtb3JlIHN1aXRhYmxlIGZvciANCmN1cnJlbnQgUFNOIGFuZCBQVE4gbmV0d29y ayByZXF1aXJlbWVudCBub3cuDQpkb24ndCB3YXN0ZWx5IHRha2UgdG9vIG11Y2ggdGltZSB0byBv dGhlciBub24tdGVjaG5vbG9nbHkgcXVlc3Rpb24uIG9yIA0KZWxzZSAsIHdlIGNhbid0IHNvbHZl IHRoZSBwcm9ibGVtIGZvciBldmVyLg0KDQp0aGFuayB5b3UgDQpsaXUNCg0KDQoNCg0KDQoNCg0K IkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPiANCreivP7Iyzog IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wMS0xOSAwNzo1Ng0KDQrK1bz+yMsNCiJIdXVi IHZhbiBIZWx2b29ydCIgPGh1dWJhdHdvcmtAZ21haWwuY29tPiwgPG1wbHNAaWV0Zi5vcmc+DQqz rcvNDQoNCtb3zOINClJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1l bmRhdGlvbiBHLnRwb2FtIFtSZWYgMDQzLjAyXQ0KDQoNCg0KDQoNCg0KSGkgSHV1Yi0NCg0KICBJ IHRoaW5rIHRoZSBjcnV4IG9mIHlvdXIgcG9pbnRzIGlzIHRoaXM6DQoNCj4gQ3VycmVudGx5IEkg Y2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czoNCj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3Jr cywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ICAgICAgc2ltaWxhciB0byBl eGlzdGluZyB0b29scw0KPiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhlIGRlZGlj YXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ICAgICAgc2ltaWxhciB0byBleGlzdGluZyB0cmFu c3BvcnQgdGVjaG5vbG9naWVzLg0KDQpJIGRvdWJ0IHdlJ2xsIGV2ZXIgZ2V0IGV2ZXJ5b25lIHRv IGhvbGQgaGFuZHMgYW5kIGFncmVlIGFuZCBzaW5nIGhhcHB5IA0Kc29uZ3Mgb24gdGhpcyBwb2lu dCwgYnV0IGxldCBtZSBhc2sgYW55d2F5cy4gIFdoeSBkbyB3ZSBzdGlsbCBuZWVkIA0KZGlmZmVy ZW50IHRvb2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3Jr cz8gIFRoZSB0d28gDQp0ZXJtcyBhcmUgc28gc2ltaWxhciB0aGF0IGl0J3Mgbm90IG9idmlvdXMg b24gaXRzIGZhY2Ugd2hldGhlciB0aGVzZSB0d28gDQphcmUgYWN0dWFsbHkgYW55IGRpZmZlcmVu dCBhbnkgbW9yZSwgaXMgaXQgcmVhbGx5IHdvcnRoIGFsbCB0aGUgaGFzc2xlIA0KZnJvbSBhIHRl Y2huaWNhbCBwZXJzcGVjdGl2ZT8gIEFuZCBpZiB0aGF0J3MgdHJ1ZSBhbmQgd2FzIHRydWUgYWxs IGFsb25nLCANCndoeSBkaWQgZXZlcnlvbmUgYWdyZWUgdG8gY29vcGVyYXRlIGluIHRoZSBmaXJz dCBwbGFjZSBbSldUIGFncmVlbWVudF0sIA0KYW5kIGFncmVlIHRoYXQgdGhlcmUgc2hvdWxkIG9u bHkgYmUgb25lIHNvbHV0aW9uIFtyZWYuIFJ1c3MgSG91c2VseSdzIA0KYnJpZWYgdGFsayBpbiBC ZWlqaW5nXT8NCg0KDQoNCg0KDQplcmljDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEh1dWIgdmFuIEhlbHZvb3J0DQo+IFNlbnQ6IFR1ZXNk YXksIEphbnVhcnkgMTgsIDIwMTEgNTo1MyBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24g Ry50cG9hbSANCltSZWYNCj4gMDQzLjAyXQ0KPiANCj4gSGVsbG8gUm9zcywNCj4gDQo+IFlvdSB3 cm90ZToNCj4gDQo+ID4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOg0K PiANCj4gTGV0IG1lIHRyeSB0byBhbnN3ZXIgdGhlbQ0KPiANCj4gPiAgICAgIC0gRG8gd2Ugd2Fu dCBvbmUgc29sdXRpb24gZm9yIE1QTFMgT0FNLCBvciB0d28/DQo+IA0KPiBJIHRoaW5rIHdlIHdh bnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4NCj4gSXQgbWF5IGhhcHBlbiB0aGF0 IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBidXQgbWF5IGJlIGRpZmZlcmVudCANCmlu DQo+IGRldGFpbCBiZWNhdXNlIHRoZXkgYXJlIHVzZWQgaW4gYSBkaWZmZXJlbnQgY29udGV4dC4N Cj4gDQo+ID4gICAgICAtIE9uY2Ugd2UgbWFrZSBhIGRlY2lzaW9uLCBkbyB3ZSBpbnRlbmQgdG8g d29yayB0byBtYWtlDQo+ID4gICAgICAgIGl0IGhhcHBlbiwgb3IgdG8gY29udGludWUgdGhlIGFy Z3VtZW50IGluZGVmaW5pdGVseT8NCj4gDQo+IEkgd2UgYWdyZWUgdGhhdCB0aGVyZSBjYW4gYmUg ZGlmZmVyZW50IGNvbnRleHRzIGluIHdoaWNoIGRlZGljYXRlZCB0b29scw0KPiBmcm9tIHRoZSB0 b29sYm94IGNhbiBiZSB1c2VkIHRoZSBvcHBvc2l0aW9uIGRpc2FwcGVhcnMuDQo+IA0KPiA+ICAg ICAgLSBEbyB3ZSB3YW50IHN0YW5kYXJkcyBmb3IgdGhlIElFVEYgVENQL0lQL01QTFMgcHJvdG9j b2wgc3VpdGUNCj4gPiAgICAgICAgdG8gYmUgZG9uZSBpbiBvbmUgc3RhbmRhcmRzIGJvZHksIG9y IGluZGVwZW5kZW50bHkgaW4gdHdvDQo+ID4gICAgICAgIGRpZmZlcmVudCBncm91cHMgd2l0aCBp bmNvbXBhdGlibGUgc3RhbmRhcmRzIHJlc3VsdGluZz8NCj4gDQo+IElmIHdlIGFncmVlIHRoYXQg dGhlcmUgYXJlIGRpZmZlcmVudCBjb250ZXh0cywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvDQo+ IGhhdmUgdGhlIGNvbnRleHQgc2Vuc2l0aXZlIHRvb2xzIGRldmVsb3BwZWQgYnkgdGhlIGV4cGVy dHMgaW4gYSANCnBhcnRpY3VsYXINCj4gY29udGV4dC9hcmVhLg0KPiANCj4gQ3VycmVudGx5IEkg Y2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czoNCj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3Jr cywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ICAgICAgc2ltaWxhciB0byBl eGlzdGluZyB0b29scw0KPiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhlIGRlZGlj YXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ICAgICAgc2ltaWxhciB0byBleGlzdGluZyB0cmFu c3BvcnQgdGVjaG5vbG9naWVzLg0KPiANCj4gUmVnYXJkcywgSHV1Yi4NCj4gDQo+IA0KPiAtLQ0K PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIM7SsK7N4rXj0rvG38j90rsN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBs cyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 001931E54825781D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLCBIdXViIGFuZCBFcmljPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDttYXliZSBpIHRo aW5rIGl0IGlzIGdvb2Qgc3VnZ2VzdGlvbg0KdG8gaGF2ZSBhbiB1bmlxdWUgdG9vbCBmb3IgcGFj a2V0IHN3aXRjaGVkIGFuZCB0cmFuc3BvcnQgbmV0d29yay48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJ1dCBpbiBmYWN0LCBpbiBteSB0aGlua2luZywgbm93IHdl DQpjYW4ndCBmaW5kIGEgdW5pcXVlIHRvb2wgYW5kIHNvbHV0aW9uIHRvIGZ1bGZpbCBQU04gYW5k IFBUTiBuZXR3b3JrIHJlcXVpcmVtZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+aWYgd2UgaGF2ZSBhbHJlYWRseSBmaW5kIHRoZSB1bmlxdWUNCnNvbHV0aW9u IGFuZCB0b29sICx3aHkgZG8gd2UgaGF2ZSBub3QgYW4gdW5pcXVlIGFncmVlbWVudCBhbmQgYWR2 aWNlPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+c28gd2UgbmVl ZCB0byBjb25zaWRlciAmbmJzcDt3aGljaCBzb2x1dGlvbg0KYW5kIHRvb2wgd2lsbCBiZSBtb3Jl IHN1aXRhYmxlIGZvciBjdXJyZW50IFBTTiBhbmQgUFROIG5ldHdvcmsgcmVxdWlyZW1lbnQNCm5v dy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRvbid0IHdhc3Rl bHkgdGFrZSB0b28gbXVjaCB0aW1lIHRvDQpvdGhlciBub24tdGVjaG5vbG9nbHkgcXVlc3Rpb24u IG9yIGVsc2UgLCB3ZSBjYW4ndCBzb2x2ZSB0aGUgcHJvYmxlbSBmb3INCmV2ZXIuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFuayB5b3UgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5saXU8YnI+DQo8L2ZvbnQ+DQo8 dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPWNlbnRlcj48L2Rpdj4NCjx0ZD48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZx dW90O0VyaWMgT3Nib3JuZSAoZW9zYm9ybmUpJnF1b3Q7DQombHQ7ZW9zYm9ybmVAY2lzY28uY29t Jmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+ yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDExLTAxLTE5IDA3OjU2PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0h1dWIgdmFuIEhlbHZvb3J0 JnF1b3Q7ICZsdDtodXViYXR3b3JrQGdtYWlsLmNvbSZndDssDQombHQ7bXBsc0BpZXRmLm9yZyZn dDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdA0KUmVjb21tZW5kYXRpb24g Ry50cG9hbSBbUmVmICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzA0My4wMl08L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhpIEh1dWIt PGJyPg0KPGJyPg0KICZuYnNwO0kgdGhpbmsgdGhlIGNydXggb2YgeW91ciBwb2ludHMgaXMgdGhp czo8YnI+DQo8YnI+DQomZ3Q7IEN1cnJlbnRseSBJIGNhbiBpZGVudGlmeSB0d28gY29udGV4dHM6 PGJyPg0KJmd0OyAtMS0gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRv b2xzIHNob3VsZCBiZWhhdmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2ltaWxhciB0 byBleGlzdGluZyB0b29sczxicj4NCiZndDsgLTItIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3Ms IHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtzaW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuPGJyPg0K PGJyPg0KSSBkb3VidCB3ZSdsbCBldmVyIGdldCBldmVyeW9uZSB0byBob2xkIGhhbmRzIGFuZCBh Z3JlZSBhbmQgc2luZyBoYXBweQ0Kc29uZ3Mgb24gdGhpcyBwb2ludCwgYnV0IGxldCBtZSBhc2sg YW55d2F5cy4gJm5ic3A7V2h5IGRvIHdlIHN0aWxsIG5lZWQNCmRpZmZlcmVudCB0b29scyBmb3Ig cGFja2V0IHN3aXRjaGVkIHZzIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3M/ICZuYnNwO1RoZQ0K dHdvIHRlcm1zIGFyZSBzbyBzaW1pbGFyIHRoYXQgaXQncyBub3Qgb2J2aW91cyBvbiBpdHMgZmFj ZSB3aGV0aGVyIHRoZXNlDQp0d28gYXJlIGFjdHVhbGx5IGFueSBkaWZmZXJlbnQgYW55IG1vcmUs IGlzIGl0IHJlYWxseSB3b3J0aCBhbGwgdGhlIGhhc3NsZQ0KZnJvbSBhIHRlY2huaWNhbCBwZXJz cGVjdGl2ZT8gJm5ic3A7QW5kIGlmIHRoYXQncyB0cnVlIGFuZCB3YXMgdHJ1ZSBhbGwNCmFsb25n LCB3aHkgZGlkIGV2ZXJ5b25lIGFncmVlIHRvIGNvb3BlcmF0ZSBpbiB0aGUgZmlyc3QgcGxhY2Ug W0pXVCBhZ3JlZW1lbnRdLA0KYW5kIGFncmVlIHRoYXQgdGhlcmUgc2hvdWxkIG9ubHkgYmUgb25l IHNvbHV0aW9uIFtyZWYuIFJ1c3MgSG91c2VseSdzIGJyaWVmDQp0YWxrIGluIEJlaWppbmddPzxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCmVyaWM8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KT2Y8YnI+DQomZ3Q7IEh1dWIgdmFuIEhlbHZvb3J0PGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDE4LCAyMDExIDU6NTMgUE08YnI+DQomZ3Q7IFRvOiBtcGxzQGlldGYub3JnPGJy Pg0KJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVj b21tZW5kYXRpb24gRy50cG9hbQ0KW1JlZjxicj4NCiZndDsgMDQzLjAyXTxicj4NCiZndDsgPGJy Pg0KJmd0OyBIZWxsbyBSb3NzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Ugd3JvdGU6PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBo ZXJlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBMZXQgbWUgdHJ5IHRvIGFuc3dlciB0aGVtPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstIERvIHdlIHdhbnQgb25l IHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3INCnR3bz88YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0 aGluayB3ZSB3YW50IG9uZSB0b29sYm94IHdpdGggYSBzZXQgb2YgdG9vbHMuPGJyPg0KJmd0OyBJ dCBtYXkgaGFwcGVuIHRoYXQgdGhlcmUgYXJlIHRvb2xzIHRoYXQgb29rIGFsaWtlIGJ1dCBtYXkg YmUgZGlmZmVyZW50DQppbjxicj4NCiZndDsgZGV0YWlsIGJlY2F1c2UgdGhleSBhcmUgdXNlZCBp biBhIGRpZmZlcmVudCBjb250ZXh0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7LSBPbmNlIHdlIG1ha2UgYSBkZWNpc2lvbiwgZG8gd2UgaW50ZW5kIHRvDQp3 b3JrIHRvIG1ha2U8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXQg aGFwcGVuLCBvciB0byBjb250aW51ZSB0aGUgYXJndW1lbnQNCmluZGVmaW5pdGVseT88YnI+DQom Z3Q7IDxicj4NCiZndDsgSSB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQgY29u dGV4dHMgaW4gd2hpY2ggZGVkaWNhdGVkDQp0b29sczxicj4NCiZndDsgZnJvbSB0aGUgdG9vbGJv eCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3NpdGlvbiBkaXNhcHBlYXJzLjxicj4NCiZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSBEbyB3ZSB3YW50IHN0YW5kYXJkcyBmb3Ig dGhlIElFVEYgVENQL0lQL01QTFMNCnByb3RvY29sIHN1aXRlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LA0K b3IgaW5kZXBlbmRlbnRseSBpbiB0d288YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZGlmZmVyZW50IGdyb3VwcyB3aXRoIGluY29tcGF0aWJsZQ0Kc3RhbmRhcmRzIHJl c3VsdGluZz88YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgd2UgYWdyZWUgdGhhdCB0aGVyZSBhcmUg ZGlmZmVyZW50IGNvbnRleHRzLCBpdCBzaG91bGQgYmUgcG9zc2libGUNCnRvPGJyPg0KJmd0OyBo YXZlIHRoZSBjb250ZXh0IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRz IGluIGEgcGFydGljdWxhcjxicj4NCiZndDsgY29udGV4dC9hcmVhLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBDdXJyZW50bHkgSSBjYW4gaWRlbnRpZnkgdHdvIGNvbnRleHRzOjxicj4NCiZndDsgLTEt IHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVo YXZlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NpbWlsYXIgdG8gZXhpc3RpbmcgdG9v bHM8YnI+DQomZ3Q7IC0yLSBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVk IHRvb2xzIHNob3VsZCBiZWhhdmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2ltaWxh ciB0byBleGlzdGluZyB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBSZWdhcmRzLCBIdXViLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tPGJyPg0K Jmd0OyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyDO0rCuzeK149K7xt/I/dK7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBsczxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KPC90dD48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001931E54825781D_=-- From Alexander.Vainshtein@ecitele.com Tue Jan 18 21:51:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DF83A6EF7 for ; Tue, 18 Jan 2011 21:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=-2.186, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZT1GYQcB3cT for ; Tue, 18 Jan 2011 21:51:28 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 5F6B63A6C42 for ; Tue, 18 Jan 2011 21:51:27 -0800 (PST) X-AuditID: 93eaf2e7-b7b6aae00000348b-fe-4d367c7f89a2 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 3D.B7.13451.F7C763D4; Wed, 19 Jan 2011 07:54:07 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 19 Jan 2011 07:55:53 +0200 From: Alexander Vainshtein To: "Eric Osborne (eosborne)" , Huub van Helvoort Date: Wed, 19 Jan 2011 07:54:03 +0200 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3Ym5aBkLUcS5dR9uZ5lr/wPwRygACDEmgAAwvRDA= Message-ID: References: <4D3619B1.1090301@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 05:51:28 -0000 SHV1YiwgRXJpYywgYWxsDQpGV0lXIEkgY29uY3VyIHdpdGggRXJpYy4gSSB3b3VsZCBldmVuIGdv IGZ1cnRoZXIgYW5kIHN0YXRlIHRoYXQ6DQoNCi0gSVAvTVBMUyBhbmQgTVBMUy1UUCBieSBkZXNp Z24gc2hhcmUgdGhlIHNhbWUgZGF0YSBwbGFuZSAgKHJlcXVpcmVkIGluIFJGQyA1NjU0IGFuZCBz dGFuZGFyZGl6ZWQgaW4gUkZDIDU5NjApLiANCkFORA0KLSBUaGUgT0FNIHRvb2xzIGluIHF1ZXN0 aW9uIGFyZSBpbnRlbmRlZCB0byBkZXRlY3QgYW5kIGxvY2FsaXplIGRlZmVjdHMgaW4gdGhpcyBj b21tb24gZGF0YSBwbGFuZS4NCg0KSGVuY2UgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIHR3 byBjb250ZXh0cyBwcm9wb3NlZCBieSBIdXViIHdvdWxkIG5vdCBiZSBhcHBsaWNhYmxlIHRvICB0 aGVzZSB0d28gdGVjaG5vbG9naWVzIA0Kd2hlbiBpdCBjb21lcyB0byB0aGUgT0FNIHRvb2xzZXQg LSBldmVuIGlmIHdlIGFncmVlIHRoYXQgdHdvIGRpZmZlcmVudCBjb250ZXh0cyBleGlzdC4NCg0K TXkgMmMsDQogICAgIFNhc2hhDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbZW9zYm9ybmVAY2lzY28u Y29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE5LCAyMDExIDE6NTYgQU0NClRvOiBIdXVi IHZhbiBIZWx2b29ydDsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBSZXNwb25z ZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZiAgICAgICAwNDMu MDJdDQoNCkhpIEh1dWItDQoNCiAgSSB0aGluayB0aGUgY3J1eCBvZiB5b3VyIHBvaW50cyBpcyB0 aGlzOg0KDQo+IEN1cnJlbnRseSBJIGNhbiBpZGVudGlmeSB0d28gY29udGV4dHM6DQo+IC0xLSBw YWNrZXQgc3dpdGNoZWQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2 ZQ0KPiAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9vbHMNCj4gLTItIHBhY2tldCB0cmFuc3Bv cnQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZQ0KPiAgICAgIHNp bWlsYXIgdG8gZXhpc3RpbmcgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KSSBkb3VidCB3ZSds bCBldmVyIGdldCBldmVyeW9uZSB0byBob2xkIGhhbmRzIGFuZCBhZ3JlZSBhbmQgc2luZyBoYXBw eSBzb25ncyBvbiB0aGlzIHBvaW50LCBidXQgbGV0IG1lIGFzayBhbnl3YXlzLiAgV2h5IGRvIHdl IHN0aWxsIG5lZWQgZGlmZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0 IHRyYW5zcG9ydCBuZXR3b3Jrcz8gIFRoZSB0d28gdGVybXMgYXJlIHNvIHNpbWlsYXIgdGhhdCBp dCdzIG5vdCBvYnZpb3VzIG9uIGl0cyBmYWNlIHdoZXRoZXIgdGhlc2UgdHdvIGFyZSBhY3R1YWxs eSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCByZWFsbHkgd29ydGggYWxsIHRoZSBoYXNz bGUgZnJvbSBhIHRlY2huaWNhbCBwZXJzcGVjdGl2ZT8gIEFuZCBpZiB0aGF0J3MgdHJ1ZSBhbmQg d2FzIHRydWUgYWxsIGFsb25nLCB3aHkgZGlkIGV2ZXJ5b25lIGFncmVlIHRvIGNvb3BlcmF0ZSBp biB0aGUgZmlyc3QgcGxhY2UgW0pXVCBhZ3JlZW1lbnRdLCBhbmQgYWdyZWUgdGhhdCB0aGVyZSBz aG91bGQgb25seSBiZSBvbmUgc29sdXRpb24gW3JlZi4gUnVzcyBIb3VzZWx5J3MgYnJpZWYgdGFs ayBpbiBCZWlqaW5nXT8NCg0KDQoNCg0KDQplcmljDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEh1dWIgdmFuIEhlbHZvb3J0DQo+IFNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMTgsIDIwMTEgNTo1MyBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5k YXRpb24gRy50cG9hbSBbUmVmDQo+IDA0My4wMl0NCj4NCj4gSGVsbG8gUm9zcywNCj4NCj4gWW91 IHdyb3RlOg0KPg0KPiA+IFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJlZSBxdWVzdGlvbnMgaGVyZToN Cj4NCj4gTGV0IG1lIHRyeSB0byBhbnN3ZXIgdGhlbQ0KPg0KPiA+ICAgICAgLSBEbyB3ZSB3YW50 IG9uZSBzb2x1dGlvbiBmb3IgTVBMUyBPQU0sIG9yIHR3bz8NCj4NCj4gSSB0aGluayB3ZSB3YW50 IG9uZSB0b29sYm94IHdpdGggYSBzZXQgb2YgdG9vbHMuDQo+IEl0IG1heSBoYXBwZW4gdGhhdCB0 aGVyZSBhcmUgdG9vbHMgdGhhdCBvb2sgYWxpa2UgYnV0IG1heSBiZSBkaWZmZXJlbnQgaW4NCj4g ZGV0YWlsIGJlY2F1c2UgdGhleSBhcmUgdXNlZCBpbiBhIGRpZmZlcmVudCBjb250ZXh0Lg0KPg0K PiA+ICAgICAgLSBPbmNlIHdlIG1ha2UgYSBkZWNpc2lvbiwgZG8gd2UgaW50ZW5kIHRvIHdvcmsg dG8gbWFrZQ0KPiA+ICAgICAgICBpdCBoYXBwZW4sIG9yIHRvIGNvbnRpbnVlIHRoZSBhcmd1bWVu dCBpbmRlZmluaXRlbHk/DQo+DQo+IEkgd2UgYWdyZWUgdGhhdCB0aGVyZSBjYW4gYmUgZGlmZmVy ZW50IGNvbnRleHRzIGluIHdoaWNoIGRlZGljYXRlZCB0b29scw0KPiBmcm9tIHRoZSB0b29sYm94 IGNhbiBiZSB1c2VkIHRoZSBvcHBvc2l0aW9uIGRpc2FwcGVhcnMuDQo+DQo+ID4gICAgICAtIERv IHdlIHdhbnQgc3RhbmRhcmRzIGZvciB0aGUgSUVURiBUQ1AvSVAvTVBMUyBwcm90b2NvbCBzdWl0 ZQ0KPiA+ICAgICAgICB0byBiZSBkb25lIGluIG9uZSBzdGFuZGFyZHMgYm9keSwgb3IgaW5kZXBl bmRlbnRseSBpbiB0d28NCj4gPiAgICAgICAgZGlmZmVyZW50IGdyb3VwcyB3aXRoIGluY29tcGF0 aWJsZSBzdGFuZGFyZHMgcmVzdWx0aW5nPw0KPg0KPiBJZiB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGFy ZSBkaWZmZXJlbnQgY29udGV4dHMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0bw0KPiBoYXZlIHRo ZSBjb250ZXh0IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRzIGluIGEg cGFydGljdWxhcg0KPiBjb250ZXh0L2FyZWEuDQo+DQo+IEN1cnJlbnRseSBJIGNhbiBpZGVudGlm eSB0d28gY29udGV4dHM6DQo+IC0xLSBwYWNrZXQgc3dpdGNoZWQgbmV0d29ya3MsIHRoZSBkZWRp Y2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZQ0KPiAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9v bHMNCj4gLTItIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMg c2hvdWxkIGJlaGF2ZQ0KPiAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdHJhbnNwb3J0IHRlY2hu b2xvZ2llcy4NCj4NCj4gUmVnYXJkcywgSHV1Yi4NCj4NCj4NCj4gLS0NCj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICDO0rCuzeK149K7xt/I/dK7DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0 DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw== From nurit.sprecher@nsn.com Tue Jan 18 22:10:01 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9333A6EF5; Tue, 18 Jan 2011 22:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[AWL=1.464, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G-UZOkTJjOM; Tue, 18 Jan 2011 22:10:00 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id A9F083A70DE; Tue, 18 Jan 2011 22:09:59 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0J6Ca7U020199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 07:12:36 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0J6CXDX021677; Wed, 19 Jan 2011 07:12:36 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 07:12:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 19 Jan 2011 07:12:21 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640336B555@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D3619B1.1090301@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3YmsCQZE7AOU8RnSu3AuQihnbOwANfHSw References: <4D3619B1.1090301@gmail.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Huub van Helvoort" , , X-OriginalArrivalTime: 19 Jan 2011 06:12:25.0047 (UTC) FILETIME=[D753D670:01CBB79F] Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 06:10:01 -0000 SGkgSHV1YiwNClJGQyA1ODYwIHNwZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBNUExTLVRQ IE9BTSBhbmQgcmVxdWlyZXMgKGFtb25nIHRoZSByZXN0KSB0aGF0IHRoZSBiZWhhdmlvciBhbmQg b3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aWxsIGJlIHNpbWlsYXIgdG8gdGhvc2UgaW4gdHJhbnNw b3J0IG5ldHdvcmtzLiANClRoZSBzb2x1dGlvbnMgY3VycmVudGx5IGJlaW5nIGRlZmluZWQgKGFu ZCBJIHdhcm1seSByZWNvbW1lbmQgeW91IHRvIHJldmlldyB0aGUgbGF0ZXN0IHZlcnNpb25zIGFu ZCBjb21tZW50KSBmdWxseSBzYXRpc2Z5IHRoZXNlIGFuZCBhbGwgdGhlIHJlc3Qgb2YgdGhlIHJl cXVpcmVtZW50cy4gDQpUaGVyZSBpcyBOTyBqdXN0aWZpY2F0aW9uIGZvciBhZGRpdGlvbmFsIHNv bHV0aW9uISBUaGVyZSBpcyBubyBqdXN0aWZpY2F0aW9uIHRvIGNvbmZ1c2UgdGhlIEluZHVzdHJ5 LCB0aGVyZSBpcyBubyBqdXN0aWZpY2F0aW9uIHRvIGJsb2F0IG9wZXJhdGlvbiBhbmQgY2FwaXRh bCBleHBlbnNlcyBhbmQgZXZlbiB0byBoYXZlIGJhZCBpbXBhY3Qgb24gdGhlIGVuZCBjdXN0b21l ciBiZWNhdXNlIG9mIHRoZSBmb3JtZXIgaXNzdWVzIChjb25mdXNpb24sIGNvc3QsIGV0Yy4pLiAN Ckkgb2JqZWN0IHRvIGRlZmluZSB0d28gc3RhbmRhcmQgc29sdXRpb25zIGZvciB0aGUgc2FtZSBw cm9ibGVtLiANClRoZSB0b29sc2V0IGluY2x1ZGVzIGRpZmZlcmVudCB0b29scywgZWFjaCBwcm92 aWRpbmcgYSBkaWZmZXJlbnQgZnVuY3Rpb25hbGl0eSAoc3VjaCBhcyBDViwgcGFja2V0IGxvc3Ms IGV0Yy4pLiB3ZSBkbyBub3QgaGF2ZSB0d28gdG9vbHMgZG9pbmcgdGhlIHNhbWUgdGhpbmcuDQpU aGUgbWFpbiBjb25jZXJuIEkgaGF2ZSB3aXRoIHlvdXIgYXBwcm9hY2gsIGlzIHRoYXQgdGhlIGFk dm9jYXRvcnMgb2YgdGhlIGFsdGVybmF0aXZlIHNvbHV0aW9uIHdlcmUgbmV2ZXIgcmVhZHkgdG8g Z2V0IGludG8gdGVjaG5pY2FsIGRpc2N1c3Npb24gYW5kIGRpc2N1c3MgaXQgdG9vbCBieSB0b29s LCB0byBzaG93IHdoYXQgZnVuY3Rpb25hbGl0eSB0aGUgYWx0ZXJuYXRpdmUgcHJvcG9zYWwgcHJv cG9zZXMgdGhhdCB0aGUgc29sdXRpb24gYmVpbmcgZGVmaW5lZCBkb2VzIG5vdCBwcm92aWRlLCBh bmQgd2h5IHN1Y2ggYSBnYXAgKGlmIGV4aXN0KSBjYW5ub3QgYmUgcmVzb2x2ZWQgaW4gdGhlIGNv bnRleHQgb2YgdGhlIHNvbHV0aW9uIGJlaW5nIGRlZmluZWQuIA0KVGhlIHdvcmRzIHlvdSB1c2Ug YmVsb3cgbG9vayB0byBtZSBzaW1wbHkgYXMgYnV6endvcmRzLi4uLiANCkkgYW0gYWxzbyBleHRy ZW1lbHkgY29uY2VybmVkIGZyb20gdGhlIHRpbWUgYWxsIHRoaXMgZW5kbGVzcyBkaXNjdXNzaW9u IHRha2UuLi4ud2UgY291bGQgdXNlIHRoZSB0aW1lIG11Y2ggbW9yZSBlZmZlY3RpdmVseSBpZiB3 ZSB1c2UgaXQgdG8gcmV2aWV3IHRoZSBXRyBkb2N1bWVudHMsIGNvbW1lbnQgYW5kIG1ha2Ugc3Vy ZSBpdCBhcHByb3ByaWF0ZWx5IHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cy4uLmFuZCBwcm9ncmVz cyB0aGUgZG9jdW1lbnRzIGZhc3QgdG8gc2F0aXNmeSB0aGUgdXJnZW50IHJlcXVpcmVtZW50IGZv ciB0aGUgdG9vbHMuIA0KU28gSSB3YW50IHRvIHdhcm1seSByZWNvbW1lbmQgdGhlIGV4cGVydHMg dG8gcmV2aWV3IHRoZSBkb2N1bWVudHMgYW5kIHByb3ZpZGUgcHJvZHVjdGl2ZSBjb21tZW50cywg YW5kIGVuc3VyZSB0aGF0IHdlIGhhdmUgYSBzaW5nbGUgc29sdXRpb24gdGhhdCBzYXRpc2Z5IGFs bCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBmaXRzIGFsbCBkZXBsb3ltZW50IHNjZW5hcmlvcy4gDQpC ZXN0IHJlZ2FyZHMsDQpOdXJpdA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBleHQgSHV1YiB2YW4gSGVsdm9vcnQNClNlbnQ6IFdlZG5lc2RheSwgSmFudWFy eSAxOSwgMjAxMSAxMjo1MyBBTQ0KVG86IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBs c10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYg MDQzLjAyXQ0KDQpIZWxsbyBSb3NzLA0KDQpZb3Ugd3JvdGU6DQoNCj4gVGhlcmUgYXJlIGF0IGxl YXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOg0KDQpMZXQgbWUgdHJ5IHRvIGFuc3dlciB0aGVtDQoN Cj4gICAgICAtIERvIHdlIHdhbnQgb25lIHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3IgdHdvPw0K DQpJIHRoaW5rIHdlIHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4NCkl0IG1h eSBoYXBwZW4gdGhhdCB0aGVyZSBhcmUgdG9vbHMgdGhhdCBvb2sgYWxpa2UgYnV0IG1heSBiZQ0K ZGlmZmVyZW50IGluIGRldGFpbCBiZWNhdXNlIHRoZXkgYXJlIHVzZWQgaW4gYSBkaWZmZXJlbnQg Y29udGV4dC4NCg0KPiAgICAgIC0gT25jZSB3ZSBtYWtlIGEgZGVjaXNpb24sIGRvIHdlIGludGVu ZCB0byB3b3JrIHRvIG1ha2UNCj4gICAgICAgIGl0IGhhcHBlbiwgb3IgdG8gY29udGludWUgdGhl IGFyZ3VtZW50IGluZGVmaW5pdGVseT8NCg0KSSB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGNhbiBiZSBk aWZmZXJlbnQgY29udGV4dHMgaW4gd2hpY2ggZGVkaWNhdGVkDQp0b29scyBmcm9tIHRoZSB0b29s Ym94IGNhbiBiZSB1c2VkIHRoZSBvcHBvc2l0aW9uIGRpc2FwcGVhcnMuDQoNCj4gICAgICAtIERv IHdlIHdhbnQgc3RhbmRhcmRzIGZvciB0aGUgSUVURiBUQ1AvSVAvTVBMUyBwcm90b2NvbCBzdWl0 ZQ0KPiAgICAgICAgdG8gYmUgZG9uZSBpbiBvbmUgc3RhbmRhcmRzIGJvZHksIG9yIGluZGVwZW5k ZW50bHkgaW4gdHdvDQo+ICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21wYXRpYmxl IHN0YW5kYXJkcyByZXN1bHRpbmc/DQoNCklmIHdlIGFncmVlIHRoYXQgdGhlcmUgYXJlIGRpZmZl cmVudCBjb250ZXh0cywgaXQgc2hvdWxkIGJlDQpwb3NzaWJsZSB0byBoYXZlIHRoZSBjb250ZXh0 IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZQ0KZXhwZXJ0cyBpbiBhIHBhcnRpY3Vs YXIgY29udGV4dC9hcmVhLg0KDQpDdXJyZW50bHkgSSBjYW4gaWRlbnRpZnkgdHdvIGNvbnRleHRz Og0KLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91 bGQgYmVoYXZlDQogICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9vbHMNCi0yLSBwYWNrZXQgdHJh bnNwb3J0IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCiAgICAg c2ltaWxhciB0byBleGlzdGluZyB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLg0KDQpSZWdhcmRzLCBI dXViLg0KDQoNCi0tIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCiAgICAgICAgICAgICAgICAgICAgICAgICAg5oiR54ix 5aSW54K55LiA5LiD5LiJ5LiADQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From mach@huawei.com Tue Jan 18 22:37:29 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7723A6EF5 for ; Tue, 18 Jan 2011 22:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSmOX3DltdE1 for ; Tue, 18 Jan 2011 22:37:28 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1EA853A6C42 for ; Tue, 18 Jan 2011 22:37:28 -0800 (PST) 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 <0LF900EKEBUKR8@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 19 Jan 2011 14:39:57 +0800 (CST) Received: from C55527A ([10.110.98.37]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900M6TBUIFX@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 19 Jan 2011 14:39:56 +0800 (CST) Date: Wed, 19 Jan 2011 14:39:54 +0800 From: Mach Chen In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B02DB54E6@SZXEML514-MBS.china.huawei.com> To: jiangyuanlong Message-id: <9949A5CDDF1443C79FAB43B9F6B34330@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <3B0A1BED22CAD649A1B3E97BE5DDD68B02DB54E6@SZXEML514-MBS.china.huawei.com> Cc: mpls@ietf.org Subject: Re: [mpls] One question about U and F-bit for Status TLV X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 06:37:29 -0000 Yuanlong, Thanks for your response! Please see my reply inline... Best regards, Mach -------------------------------------------------- From: "jiangyuanlong" Sent: Wednesday, January 19, 2011 11:19 AM To: "Mach Chen" Cc: Subject: Re: [mpls] One question about U and F-bit for Status TLV > Mach, > > Please see my comments inline. > > Best regards > Yuanlong > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] ´ú±í Mach > Chen > ·¢ËÍʱ¼ä: 2011Äê1ÔÂ17ÈÕ 17:54 > ÊÕ¼þÈË: Mach Chen; mpls@ietf.org > Ö÷Ìâ: Re: [mpls] One question about U and F-bit for Status TLV > > The question is about RFC5036 > > Best regards, > Mach > > -------------------------------------------------- > From: "Mach Chen" > Sent: Monday, January 17, 2011 5:16 PM > To: > Subject: [mpls] One question about U and F-bit for Status TLV > >> Hi, >> >> I have one question about U and F-bit setting for Status TLV. >> >> In Section 3.3, the F-bit of a TLV is defined as: >> "F-bit >> Forward unknown TLV bit. This bit applies only when the U-bit is >> set >> and the LDP message containing the unknown TLV is to be forwarded. ..." >> >> And in Section 3.4.6. >> The definition of Status TLV says: >> "U-bit >> SHOULD be 0 when the Status TLV is sent in a Notification message. >> SHOULD be 1 when the Status TLV is sent in some other message. >> F-bit >> SHOULD be the same as the setting of the F-bit in the Status Code >> field." >> >> So, for a Notification message contained Status TLV, the F-bit of Status >> TLV should make no sence. And if an LSR receives a Nofication message and >> it does not know the Status TLV, the entrie Notification message MUST be >> ignored. >> >> But following up, the Status Code defines: >> "F-bit >> Forward bit. If set (=1), the notification SHOULD be forwarded to >> the LSR for the next-hop or previous-hop for the LSP, if any, associated >> with the event being signaled. If clear (=0),the notification SHOULD NOT >> be forwarded." >> >> It seems that it wants to use the F-bit to control whether to forward the >> notification messsage, but this should not work since the U-bit is clear. > [JYL] IMO, this "notification" does not mean "Notification message", but > the > "Status Code". Yes, but most of the time, it's the same, because Status TLV is mainly designed to be carried in the Notification message. > >> >> I am not sure which is the intent of the specification. I'd appreciate >> that someone clarify this! >> >> Best regards, >> Mach >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From huubatwork@gmail.com Tue Jan 18 22:58:57 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4F43A6F25 for ; Tue, 18 Jan 2011 22:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAebdanq-4Hn for ; Tue, 18 Jan 2011 22:58:55 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3C7973A6E7E for ; Tue, 18 Jan 2011 22:58:55 -0800 (PST) Received: by wyf23 with SMTP id 23so543147wyf.31 for ; Tue, 18 Jan 2011 23:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=v/oy/0y94w9uxnUmdYexRl5Huqw4H2glJIEbpFdezUs=; b=k4Wfud4P/eZeZ1yz/D/rFN48GTPZrAih8WE1P/HTajN2w+Rxno+x741k8UATygts30 jf53g7Lo6Ieu/KAIPiFH0CZi/rpwT54A4wpI0THj3RONRhNpbQVaFZzn4isrrtHQQ7FH bo0vUD2FdJO4ePdfrrOqnCie4q8UQHfVIUvp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=suraaul2ZRA4H5FAVJh4pxs9eHm8SbFjQ2xz4/fL8A6BGi9nb3wX8J2rC0UrRSnYxw CHLwYOwW9iYMVlx1gEYvYFnBdgkDCsczXsQib9PoDt6BLsvildWltOQ1ORbhdzAaoXSS Cu22h6k/Y2qUjVpcrqP024us5NDXWHVQt/GSE= Received: by 10.216.150.164 with SMTP id z36mr2094897wej.43.1295420479533; Tue, 18 Jan 2011 23:01:19 -0800 (PST) Received: from McAsterix.local ([81.253.44.162]) by mx.google.com with ESMTPS id r6sm3472772weq.20.2011.01.18.23.00.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 23:00:48 -0800 (PST) Message-ID: <4D368C1B.7080106@gmail.com> Date: Wed, 19 Jan 2011 08:00:43 +0100 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: mpls@ietf.org References: <4D3619B1.1090301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 06:58:57 -0000 Hello Eric, You replied: > I think the crux of your points is this: > >> Currently I can identify two contexts: >> -1- packet switched networks, the dedicated tools should behave >> similar to existing tools >> -2- packet transport networks, the dedicated tools should behave >> similar to existing transport technologies. > > I doubt we'll ever get everyone to hold hands and agree and sing > happy songs on this point, but let me ask anyways. Why do we still > need different tools for packet switched vs packet transport networks? > The two terms are so similar that it's not obvious on its face whether > these two are actually any different any more, is it really worth all > the hassle from a technical perspective? If you look at the terms they look similar, but packet transport differs from packet switching in the way packets are transported. In packet transport the objective is to transport packets independend of the technology, so it is important that the OAM for packet transport is the same in all transport technologies. > And if that's true and was true all along, why did everyone agree > to cooperate in the first place [JWT agreement], and agree that there > should only be one solution [ref. Russ Housely's brief talk in Beijing]? Just out of curiosity: When and where was this agreed? Who was present when this agreement was reached? Regards, Huub. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Huub van Helvoort >> Sent: Tuesday, January 18, 2011 5:53 PM >> To: mpls@ietf.org >> Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref >> 043.02] >> >> Hello Ross, >> >> You wrote: >> >>> There are at least three questions here: >> >> Let me try to answer them >> >>> - Do we want one solution for MPLS OAM, or two? >> >> I think we want one toolbox with a set of tools. >> It may happen that there are tools that ook alike but may be different in >> detail because they are used in a different context. >> >>> - Once we make a decision, do we intend to work to make >>> it happen, or to continue the argument indefinitely? >> >> I we agree that there can be different contexts in which dedicated tools >> from the toolbox can be used the opposition disappears. >> >>> - Do we want standards for the IETF TCP/IP/MPLS protocol suite >>> to be done in one standards body, or independently in two >>> different groups with incompatible standards resulting? >> >> If we agree that there are different contexts, it should be possible to >> have the context sensitive tools developped by the experts in a particular >> context/area. >> >> Currently I can identify two contexts: >> -1- packet switched networks, the dedicated tools should behave >> similar to existing tools >> -2- packet transport networks, the dedicated tools should behave >> similar to existing transport technologies. >> >> Regards, Huub. -- ***************************************************************** 我爱外点一七三一 From Alexander.Vainshtein@ecitele.com Tue Jan 18 23:02:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60D93A70E9 for ; Tue, 18 Jan 2011 23:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-2.156, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn26imxJrJHa for ; Tue, 18 Jan 2011 23:02:32 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id F3F213A70E2 for ; Tue, 18 Jan 2011 23:02:31 -0800 (PST) X-AuditID: 93eaf2e7-b7b6aae00000348b-1f-4d368d285688 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 82.FA.13451.82D863D4; Wed, 19 Jan 2011 09:05:12 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 19 Jan 2011 09:06:58 +0200 From: Alexander Vainshtein To: Huub van Helvoort Date: Wed, 19 Jan 2011 09:03:00 +0200 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3prp6lgcZLR32TGWlrn5yDIT/SwAAG9Bo Message-ID: References: <4D3619B1.1090301@gmail.com> , <4D368C1B.7080106@gmail.com> In-Reply-To: <4D368C1B.7080106@gmail.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:02:33 -0000 SHV1YiwNCllvdSd2ZSBzYWlkOg0KDQogICAgICBJbiBwYWNrZXQgdHJhbnNwb3J0IHRoZSBvYmpl Y3RpdmUgaXMgdG8gdHJhbnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbnQgb2YgdGhlIHRlY2hub2xv Z3kuDQoNCklmIHlvdSBtZWFuIHRoYXQgdGhlIG9iamVjdGl2ZSBpcyB0byB0cmFuc3BvcnQgcGFj a2V0cyBpbmRlcGVuZGVudCBvZiB0aGUgZGF0YSBwbGFuZSB0ZWNobm9sb2d5LA0KSSdkIHNheSB0 aGF0IHN1Y2ggYW4gb2JqZWN0aXZlIGlzIElNSE8gdW5yZWFsaXN0aWMuDQoNCk15IDJjLA0KICAg ICBTYXNoYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEh1dWIgdmFuIEhlbHZvb3J0IFtodXViYXR3b3JrQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAxOSwgMjAxMSA5OjAwIEFNDQpUbzogbXBsc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFttcGxzXSBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcu dHBvYW0gW1JlZiAwNDMuMDJdDQoNCkhlbGxvIEVyaWMsDQoNCllvdSByZXBsaWVkOg0KDQo+ICAg IEkgdGhpbmsgdGhlIGNydXggb2YgeW91ciBwb2ludHMgaXMgdGhpczoNCj4NCj4+IEN1cnJlbnRs eSBJIGNhbiBpZGVudGlmeSB0d28gY29udGV4dHM6DQo+PiAtMS0gcGFja2V0IHN3aXRjaGVkIG5l dHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCj4+ICAgICAgIHNpbWls YXIgdG8gZXhpc3RpbmcgdG9vbHMNCj4+IC0yLSBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCB0 aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCj4+ICAgICAgIHNpbWlsYXIgdG8gZXhp c3RpbmcgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCj4NCj4gSSBkb3VidCB3ZSdsbCBldmVyIGdl dCBldmVyeW9uZSB0byBob2xkIGhhbmRzIGFuZCBhZ3JlZSBhbmQgc2luZw0KID4gaGFwcHkgc29u Z3Mgb24gdGhpcyBwb2ludCwgYnV0IGxldCBtZSBhc2sgYW55d2F5cy4gIFdoeSBkbyB3ZSBzdGls bA0KID4gbmVlZCBkaWZmZXJlbnQgdG9vbHMgZm9yIHBhY2tldCBzd2l0Y2hlZCB2cyBwYWNrZXQg dHJhbnNwb3J0IG5ldHdvcmtzPw0KID4gVGhlIHR3byB0ZXJtcyBhcmUgc28gc2ltaWxhciB0aGF0 IGl0J3Mgbm90IG9idmlvdXMgb24gaXRzIGZhY2Ugd2hldGhlcg0KID4gdGhlc2UgdHdvIGFyZSBh Y3R1YWxseSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCByZWFsbHkgd29ydGggYWxsDQog PiB0aGUgaGFzc2xlIGZyb20gYSB0ZWNobmljYWwgcGVyc3BlY3RpdmU/DQoNCklmIHlvdSBsb29r IGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwgYnV0IHBhY2tldCB0cmFuc3BvcnQgZGlm ZmVycw0KZnJvbSBwYWNrZXQgc3dpdGNoaW5nIGluIHRoZSB3YXkgcGFja2V0cyBhcmUgdHJhbnNw b3J0ZWQuIEluIHBhY2tldA0KdHJhbnNwb3J0IHRoZSBvYmplY3RpdmUgaXMgdG8gdHJhbnNwb3J0 IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlDQp0ZWNobm9sb2d5LCBzbyBpdCBpcyBpbXBvcnRh bnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzDQp0aGUgc2FtZSBpbiBhbGwg dHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KPiBBbmQgaWYgdGhhdCdzIHRydWUgYW5kIHdhcyB0 cnVlIGFsbCBhbG9uZywgd2h5IGRpZCBldmVyeW9uZSBhZ3JlZQ0KID4gdG8gY29vcGVyYXRlIGlu IHRoZSBmaXJzdCBwbGFjZSBbSldUIGFncmVlbWVudF0sIGFuZCBhZ3JlZSB0aGF0IHRoZXJlDQog PiBzaG91bGQgb25seSBiZSBvbmUgc29sdXRpb24gW3JlZi4gUnVzcyBIb3VzZWx5J3MgYnJpZWYg dGFsayBpbiBCZWlqaW5nXT8NCg0KSnVzdCBvdXQgb2YgY3VyaW9zaXR5Og0KV2hlbiBhbmQgd2hl cmUgd2FzIHRoaXMgYWdyZWVkPw0KV2hvIHdhcyBwcmVzZW50IHdoZW4gdGhpcyBhZ3JlZW1lbnQg d2FzIHJlYWNoZWQ/DQoNClJlZ2FyZHMsIEh1dWIuDQoNCg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PiBIdXViIHZhbiBIZWx2b29ydA0KPj4gU2Vu dDogVHVlc2RheSwgSmFudWFyeSAxOCwgMjAxMSA1OjUzIFBNDQo+PiBUbzogbXBsc0BpZXRmLm9y Zw0KPj4gU3ViamVjdDogUmU6IFttcGxzXSBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29t bWVuZGF0aW9uIEcudHBvYW0gW1JlZg0KPj4gMDQzLjAyXQ0KPj4NCj4+IEhlbGxvIFJvc3MsDQo+ Pg0KPj4gWW91IHdyb3RlOg0KPj4NCj4+PiBUaGVyZSBhcmUgYXQgbGVhc3QgdGhyZWUgcXVlc3Rp b25zIGhlcmU6DQo+Pg0KPj4gTGV0IG1lIHRyeSB0byBhbnN3ZXIgdGhlbQ0KPj4NCj4+PiAgICAg ICAtIERvIHdlIHdhbnQgb25lIHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3IgdHdvPw0KPj4NCj4+ IEkgdGhpbmsgd2Ugd2FudCBvbmUgdG9vbGJveCB3aXRoIGEgc2V0IG9mIHRvb2xzLg0KPj4gSXQg bWF5IGhhcHBlbiB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBidXQgbWF5IGJl IGRpZmZlcmVudCBpbg0KPj4gZGV0YWlsIGJlY2F1c2UgdGhleSBhcmUgdXNlZCBpbiBhIGRpZmZl cmVudCBjb250ZXh0Lg0KPj4NCj4+PiAgICAgICAtIE9uY2Ugd2UgbWFrZSBhIGRlY2lzaW9uLCBk byB3ZSBpbnRlbmQgdG8gd29yayB0byBtYWtlDQo+Pj4gICAgICAgICBpdCBoYXBwZW4sIG9yIHRv IGNvbnRpbnVlIHRoZSBhcmd1bWVudCBpbmRlZmluaXRlbHk/DQo+Pg0KPj4gSSB3ZSBhZ3JlZSB0 aGF0IHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQgY29udGV4dHMgaW4gd2hpY2ggZGVkaWNhdGVkIHRv b2xzDQo+PiBmcm9tIHRoZSB0b29sYm94IGNhbiBiZSB1c2VkIHRoZSBvcHBvc2l0aW9uIGRpc2Fw cGVhcnMuDQo+Pg0KPj4+ICAgICAgIC0gRG8gd2Ugd2FudCBzdGFuZGFyZHMgZm9yIHRoZSBJRVRG IFRDUC9JUC9NUExTIHByb3RvY29sIHN1aXRlDQo+Pj4gICAgICAgICB0byBiZSBkb25lIGluIG9u ZSBzdGFuZGFyZHMgYm9keSwgb3IgaW5kZXBlbmRlbnRseSBpbiB0d28NCj4+PiAgICAgICAgIGRp ZmZlcmVudCBncm91cHMgd2l0aCBpbmNvbXBhdGlibGUgc3RhbmRhcmRzIHJlc3VsdGluZz8NCj4+ DQo+PiBJZiB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgY29udGV4dHMsIGl0IHNo b3VsZCBiZSBwb3NzaWJsZSB0bw0KPj4gaGF2ZSB0aGUgY29udGV4dCBzZW5zaXRpdmUgdG9vbHMg ZGV2ZWxvcHBlZCBieSB0aGUgZXhwZXJ0cyBpbiBhIHBhcnRpY3VsYXINCj4+IGNvbnRleHQvYXJl YS4NCj4+DQo+PiBDdXJyZW50bHkgSSBjYW4gaWRlbnRpZnkgdHdvIGNvbnRleHRzOg0KPj4gLTEt IHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVo YXZlDQo+PiAgICAgICBzaW1pbGFyIHRvIGV4aXN0aW5nIHRvb2xzDQo+PiAtMi0gcGFja2V0IHRy YW5zcG9ydCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+PiAg ICAgICBzaW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQo+Pg0KPj4g UmVnYXJkcywgSHV1Yi4NCg0KDQotLQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgztKwrs3itePSu8bfyP3Suw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM= From nurit.sprecher@nsn.com Tue Jan 18 23:24:45 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32923A6F90 for ; Tue, 18 Jan 2011 23:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.572 X-Spam-Level: X-Spam-Status: No, score=-4.572 tagged_above=-999 required=5 tests=[AWL=1.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy7MdMzATgJK for ; Tue, 18 Jan 2011 23:24:43 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1BC593A6E7E for ; Tue, 18 Jan 2011 23:24:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0J7RERk000523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 08:27:14 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0J7REJw011052; Wed, 19 Jan 2011 08:27:14 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 08:26:37 +0100 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_01CBB7AA.360D5E4B" Date: Wed, 19 Jan 2011 08:26:29 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640336B5BC@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D368C1B.7080106@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3pr0nWnGAJkoaS32EMgwRas2GVwAAR2rw References: <4D3619B1.1090301@gmail.com> <4D368C1B.7080106@gmail.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Huub van Helvoort" , X-OriginalArrivalTime: 19 Jan 2011 07:26:37.0825 (UTC) FILETIME=[3563D710:01CBB7AA] Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:24:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB7AA.360D5E4B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SHV1YiwNCg0KWW91IHNheToNCg0KIklmIHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sg c2ltaWxhciwgYnV0IHBhY2tldCB0cmFuc3BvcnQgZGlmZmVycyBmcm9tIHBhY2tldCBzd2l0Y2hp bmcgaW4gdGhlIHdheSBwYWNrZXRzIGFyZSB0cmFuc3BvcnRlZC4gSW4gcGFja2V0IHRyYW5zcG9y dCB0aGUgb2JqZWN0aXZlIGlzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRo ZSB0ZWNobm9sb2d5LCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQg dHJhbnNwb3J0IGlzIHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLiINCg0K TnVyaXQ6IERvIHlvdSBzYXkgdGhhdCB0aGUgZm9yd2FyZGluZyBvZiBNUExTIHBhY2tldHMgaXMg ZGlmZmVyZW50IGluIGJvdGggcHJvcG9zYWxzPyBEbyB5b3Ugc2F5IHRoYXQgaW4gdHJhbnNwb3J0 IG5ldHdvcmtzIHRoZSBmb3J3YXJkaW5nIG9mIHRoZSBwYWNrZXRzIGlzIGluZGVwZW5kZW50IG9m IHRoZSBNUExTIGZvcndhcmRpbmcgbWVjaGFuaXNtcz8gSXMgdGhlcmUgYSBtYWdpYyB3YXkgdG8g dHJhbnNtaXQgdGhlIHBhY2tldHMgd2l0aG91dCByZWx5aW5nIG9uIHRoZSB0ZWNobm9sb2d5PyAN Cg0KQWxzbywgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgbG9naWMgYmV0d2VlbiB0aGUgcmVxdWly ZW1lbnQgeW91IHB1dCAidG8gdHJhbnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlIHRl Y2hub2xvZ3kiIGFuZCB0aGUgY29uY2x1c2lvbiB0aGF0ICJpdCBpcyBpbXBvcnRhbnQgdGhhdCB0 aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzIHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQg dGVjaG5vbG9naWVzIg0KDQpUaGUgcmVxdWlyZW1lbnQgaXMgdG8gaGF2ZSBzaW1pbGFyIGZ1bmN0 aW9uYWxpdHkgYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgYXMgaW4gb3RoZXIgdHJhbnNwb3J0 IG5ldHdvcmvigKZ0aGlzIGRvZXMgbm90IG1lYW4gdGhhdCBpdCBoYXMgdG8gYmUgaW1wbGVtZW50 ZWQgdGhlIHNhbWUgd2F54oCmLm9yIHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIHVzZSB0aGUgc2Ft ZSBmcmFtZSBmb3JtYXTigKYuc28gcGxlYXNlIHN0b3AgY29uZnVzaW5nIHRoZSBJbmR1c3RyeSEg VGhlIHdheSBpdCBsb29rcyBhbmQgZmVlbCBkb2VzIG5vdCBkaWN0YXRlIGhvdyBpdCBpcyBpbXBs ZW1lbnRlZCBhbmQgd2hpY2ggZnJhbWUgZm9ybWF0cyBhcmUgdXNlZC4NCg0KSW4gTVBMUy1UUCB0 aGUgZm9yd2FyZGluZyBpcyBiYXNlZCBvbiB0aGUgTVBMUyBmb3J3YXJkaW5nIGNvbnN0cnVjdCBh bmQgdGhlIE9BTSBwYWNrZXRzIG1heSBiZSBzZW50IGluYmFuZCBvdmVyIEctQWNo4oCmLi4NCg0K WW91ciBhcmd1bWVudHMgbWFrZSBtZSB2ZXJ5IG11Y2ggY29uY2VybmVkIG5vd+KApmFuZCB0aGUg bmVlZCB0byBkZWZpbmUgYSB0ZWNobm9sb2d5IGluIHRoZSBwbGFjZSB3aGVyZSB0aGUgZGVzaWdu IGF1dGhvcml0eSBleGlzdHMgc2VlbXMgdG8gYmUgc3Ryb25nZXIgdGhhbiBldmVyIQ0KDQpCUiwN Cg0KTm51cml0DQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGV4dCBIdXViIHZhbiBIZWx2b29ydA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE5LCAy MDExIDk6MDEgQU0NClRvOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFJlc3Bv bnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmIDA0My4wMl0N Cg0KIA0KDQpIZWxsbyBFcmljLA0KDQogDQoNCllvdSByZXBsaWVkOg0KDQogDQoNCj4gICAgSSB0 aGluayB0aGUgY3J1eCBvZiB5b3VyIHBvaW50cyBpcyB0aGlzOg0KDQo+IA0KDQo+PiBDdXJyZW50 bHkgSSBjYW4gaWRlbnRpZnkgdHdvIGNvbnRleHRzOg0KDQo+PiAtMS0gcGFja2V0IHN3aXRjaGVk IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCg0KPj4gICAgICAg c2ltaWxhciB0byBleGlzdGluZyB0b29scw0KDQo+PiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3 b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAgICAgIHNpbWls YXIgdG8gZXhpc3RpbmcgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KPiANCg0KPiBJIGRvdWJ0 IHdlJ2xsIGV2ZXIgZ2V0IGV2ZXJ5b25lIHRvIGhvbGQgaGFuZHMgYW5kIGFncmVlIGFuZCBzaW5n DQoNCj4gaGFwcHkgc29uZ3Mgb24gdGhpcyBwb2ludCwgYnV0IGxldCBtZSBhc2sgYW55d2F5cy4g IFdoeSBkbyB3ZSBzdGlsbA0KDQo+IG5lZWQgZGlmZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dp dGNoZWQgdnMgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3Jrcz8NCg0KPiBUaGUgdHdvIHRlcm1zIGFy ZSBzbyBzaW1pbGFyIHRoYXQgaXQncyBub3Qgb2J2aW91cyBvbiBpdHMgZmFjZSB3aGV0aGVyDQoN Cj4gdGhlc2UgdHdvIGFyZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCBy ZWFsbHkgd29ydGggYWxsDQoNCj4gdGhlIGhhc3NsZSBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0 aXZlPw0KDQogDQoNCklmIHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwg YnV0IHBhY2tldCB0cmFuc3BvcnQgZGlmZmVycw0KDQpmcm9tIHBhY2tldCBzd2l0Y2hpbmcgaW4g dGhlIHdheSBwYWNrZXRzIGFyZSB0cmFuc3BvcnRlZC4gSW4gcGFja2V0DQoNCnRyYW5zcG9ydCB0 aGUgb2JqZWN0aXZlIGlzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRoZQ0K DQp0ZWNobm9sb2d5LCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQg dHJhbnNwb3J0IGlzDQoNCnRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLg0K DQogDQoNCj4gQW5kIGlmIHRoYXQncyB0cnVlIGFuZCB3YXMgdHJ1ZSBhbGwgYWxvbmcsIHdoeSBk aWQgZXZlcnlvbmUgYWdyZWUNCg0KPiB0byBjb29wZXJhdGUgaW4gdGhlIGZpcnN0IHBsYWNlIFtK V1QgYWdyZWVtZW50XSwgYW5kIGFncmVlIHRoYXQgdGhlcmUNCg0KPiBzaG91bGQgb25seSBiZSBv bmUgc29sdXRpb24gW3JlZi4gUnVzcyBIb3VzZWx5J3MgYnJpZWYgdGFsayBpbiBCZWlqaW5nXT8N Cg0KIA0KDQpKdXN0IG91dCBvZiBjdXJpb3NpdHk6DQoNCldoZW4gYW5kIHdoZXJlIHdhcyB0aGlz IGFncmVlZD8NCg0KV2hvIHdhcyBwcmVzZW50IHdoZW4gdGhpcyBhZ3JlZW1lbnQgd2FzIHJlYWNo ZWQ/DQoNCiANCg0KUmVnYXJkcywgSHV1Yi4NCg0KIA0KDQogDQoNCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQoNCj4+IEh1dWIgdmFuIEhlbHZvb3J0 DQoNCj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTgsIDIwMTEgNTo1MyBQTQ0KDQo+PiBUbzog bXBsc0BpZXRmLm9yZw0KDQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0 ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmDQoNCj4+IDA0My4wMl0NCg0KPj4g DQoNCj4+IEhlbGxvIFJvc3MsDQoNCj4+IA0KDQo+PiBZb3Ugd3JvdGU6DQoNCj4+IA0KDQo+Pj4g VGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOg0KDQo+PiANCg0KPj4gTGV0 IG1lIHRyeSB0byBhbnN3ZXIgdGhlbQ0KDQo+PiANCg0KPj4+ICAgICAgIC0gRG8gd2Ugd2FudCBv bmUgc29sdXRpb24gZm9yIE1QTFMgT0FNLCBvciB0d28/DQoNCj4+IA0KDQo+PiBJIHRoaW5rIHdl IHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4NCg0KPj4gSXQgbWF5IGhhcHBl biB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBidXQgbWF5IGJlIGRpZmZlcmVu dCBpbg0KDQo+PiBkZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2VkIGluIGEgZGlmZmVyZW50IGNv bnRleHQuDQoNCj4+IA0KDQo+Pj4gICAgICAgLSBPbmNlIHdlIG1ha2UgYSBkZWNpc2lvbiwgZG8g d2UgaW50ZW5kIHRvIHdvcmsgdG8gbWFrZQ0KDQo+Pj4gICAgICAgICBpdCBoYXBwZW4sIG9yIHRv IGNvbnRpbnVlIHRoZSBhcmd1bWVudCBpbmRlZmluaXRlbHk/DQoNCj4+IA0KDQo+PiBJIHdlIGFn cmVlIHRoYXQgdGhlcmUgY2FuIGJlIGRpZmZlcmVudCBjb250ZXh0cyBpbiB3aGljaCBkZWRpY2F0 ZWQgdG9vbHMNCg0KPj4gZnJvbSB0aGUgdG9vbGJveCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3NpdGlv biBkaXNhcHBlYXJzLg0KDQo+PiANCg0KPj4+ICAgICAgIC0gRG8gd2Ugd2FudCBzdGFuZGFyZHMg Zm9yIHRoZSBJRVRGIFRDUC9JUC9NUExTIHByb3RvY29sIHN1aXRlDQoNCj4+PiAgICAgICAgIHRv IGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBpbmRlcGVuZGVudGx5IGluIHR3bw0K DQo+Pj4gICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21wYXRpYmxlIHN0YW5kYXJk cyByZXN1bHRpbmc/DQoNCj4+IA0KDQo+PiBJZiB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkaWZm ZXJlbnQgY29udGV4dHMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0bw0KDQo+PiBoYXZlIHRoZSBj b250ZXh0IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRzIGluIGEgcGFy dGljdWxhcg0KDQo+PiBjb250ZXh0L2FyZWEuDQoNCj4+IA0KDQo+PiBDdXJyZW50bHkgSSBjYW4g aWRlbnRpZnkgdHdvIGNvbnRleHRzOg0KDQo+PiAtMS0gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtz LCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCg0KPj4gICAgICAgc2ltaWxhciB0 byBleGlzdGluZyB0b29scw0KDQo+PiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhl IGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAgICAgIHNpbWlsYXIgdG8gZXhp c3RpbmcgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KPj4gDQoNCj4+IFJlZ2FyZHMsIEh1dWIu DQoNCiANCg0KIA0KDQotLSANCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICDmiJHniLHlpJbngrnkuIDkuIPkuInkuIANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KbXBscyBtYWlsaW5nIGxpc3QNCg0KbXBsc0BpZXRmLm9y Zw0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K ------_=_NextPart_001_01CBB7AA.360D5E4B Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1T dW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0 DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBj bGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pkh1dWIsPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PllvdSBzYXk6PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0IHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPiZxdW90O0lmIHlvdSBsb29r IGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwgYnV0IDxzcGFuIHN0eWxlPSdiYWNrZ3Jv dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyc+cGFja2V0IHRyYW5zcG9ydCBkaWZmZXJz IGZyb20gcGFja2V0IHN3aXRjaGluZyBpbiB0aGUgd2F5IHBhY2tldHMgYXJlIHRyYW5zcG9ydGVk LiBJbiBwYWNrZXQgdHJhbnNwb3J0IHRoZSBvYmplY3RpdmUgaXMgdG8gdHJhbnNwb3J0IHBhY2tl dHMgaW5kZXBlbmRlbmQgb2YgdGhlIHRlY2hub2xvZ3k8L3NwYW4+LCBzbyBpdCBpcyBpbXBvcnRh bnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzIHRoZSBzYW1lIGluIGFsbCB0 cmFuc3BvcnQgdGVjaG5vbG9naWVzLiZxdW90OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48dT5OdXJpdDwvdT46IDxiPjx1PjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPkRvIHlv dSBzYXkgdGhhdCB0aGUgZm9yd2FyZGluZyBvZiBNUExTIHBhY2tldHMgaXMgZGlmZmVyZW50IGlu IGJvdGggcHJvcG9zYWxzPzwvc3Bhbj48L3U+PC9iPiBEbyB5b3Ugc2F5IHRoYXQgaW4gdHJhbnNw b3J0IG5ldHdvcmtzIHRoZSBmb3J3YXJkaW5nIG9mIHRoZSBwYWNrZXRzIGlzIGluZGVwZW5kZW50 IG9mIHRoZSBNUExTIGZvcndhcmRpbmcgbWVjaGFuaXNtcz8gSXMgdGhlcmUgYSBtYWdpYyB3YXkg dG8gdHJhbnNtaXQgdGhlIHBhY2tldHMgd2l0aG91dCByZWx5aW5nIG9uIHRoZSB0ZWNobm9sb2d5 PyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+QWxzbywgSSBkbyBub3QgdW5k ZXJzdGFuZCB0aGUgbG9naWMgYmV0d2VlbiB0aGUgcmVxdWlyZW1lbnQgeW91IHB1dCAmcXVvdDs8 c3BhbiBzdHlsZT0nYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3cnPnRvIHRy YW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRoZSB0ZWNobm9sb2d5PC9zcGFuPiZxdW90 OyBhbmQgdGhlIGNvbmNsdXNpb24gdGhhdCAmcXVvdDs8c3BhbiBzdHlsZT0nYmFja2dyb3VuZDp5 ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3cnPml0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBPQU0g Zm9yIHBhY2tldCB0cmFuc3BvcnQgaXMgdGhlIHNhbWUgaW4gYWxsIHRyYW5zcG9ydCB0ZWNobm9s b2dpZXM8L3NwYW4+JnF1b3Q7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRo ZSByZXF1aXJlbWVudCBpcyB0byBoYXZlIDxiPjx1PjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPnNp bWlsYXIgZnVuY3Rpb25hbGl0eSBhbmQgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBhcyBpbiBvdGhl ciB0cmFuc3BvcnQgbmV0d29yazwvc3Bhbj48L3U+PC9iPuKApnRoaXMgZG9lcyBub3QgbWVhbiB0 aGF0IGl0IGhhcyB0byBiZSBpbXBsZW1lbnRlZCB0aGUgc2FtZSB3YXnigKYub3IgdGhhdCB0aGVy ZSBpcyBhIG5lZWQgdG8gdXNlIHRoZSBzYW1lIGZyYW1lIGZvcm1hdOKApi48Yj48dT48c3BhbiBz dHlsZT0nY29sb3I6cmVkJz5zbyBwbGVhc2Ugc3RvcCBjb25mdXNpbmcgdGhlIEluZHVzdHJ5ISBU aGUgd2F5IGl0IGxvb2tzIGFuZCBmZWVsIGRvZXMgbm90IGRpY3RhdGUgaG93IGl0IGlzIGltcGxl bWVudGVkIGFuZCB3aGljaCBmcmFtZSBmb3JtYXRzIGFyZSB1c2VkLjwvc3Bhbj48L3U+PG86cD48 L286cD48L2I+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JbiBNUExTLVRQIHRoZSBmb3J3YXJk aW5nIGlzIGJhc2VkIG9uIHRoZSBNUExTIGZvcndhcmRpbmcgY29uc3RydWN0IGFuZCB0aGUgT0FN IHBhY2tldHMgbWF5IGJlIHNlbnQgaW5iYW5kIG92ZXIgRy1BY2jigKYuLjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD5Zb3VyIGFyZ3VtZW50cyBtYWtlIG1lIHZlcnkgbXVjaCBj b25jZXJuZWQgbm934oCmYW5kIHRoZSBuZWVkIHRvIGRlZmluZSBhIHRlY2hub2xvZ3kgaW4gdGhl IHBsYWNlIHdoZXJlIHRoZSBkZXNpZ24gYXV0aG9yaXR5IGV4aXN0cyBzZWVtcyB0byBiZSBzdHJv bmdlciB0aGFuIGV2ZXIhPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkJSLDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5ObnVyaXQ8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPkZyb206IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBI dXViIHZhbiBIZWx2b29ydDxicj5TZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTksIDIwMTEgOTow MSBBTTxicj5UbzogbXBsc0BpZXRmLm9yZzxicj5TdWJqZWN0OiBSZTogW21wbHNdIFJlc3BvbnNl IHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmIDA0My4wMl08bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PkhlbGxvIEVyaWMsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5Zb3Ug cmVwbGllZDo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDvCoMKgwqAgSSB0aGluayB0aGUgY3J1 eCBvZiB5b3VyIHBvaW50cyBpcyB0aGlzOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsm Z3Q7IEN1cnJlbnRseSBJIGNhbiBpZGVudGlmeSB0d28gY29udGV4dHM6PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IC0xLSBwYWNrZXQgc3dpdGNoZWQgbmV0d29y a3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZTxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0O8KgwqDCoMKgwqDCoCBzaW1pbGFyIHRvIGV4aXN0aW5n IHRvb2xzPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IC0yLSBw YWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhh dmU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDvCoMKgwqDCoMKg wqAgc2ltaWxhciB0byBleGlzdGluZyB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgSSBkb3VidCB3ZSdsbCBldmVyIGdldCBldmVyeW9uZSB0byBo b2xkIGhhbmRzIGFuZCBhZ3JlZSBhbmQgc2luZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4gJmd0OyBoYXBweSBzb25ncyBvbiB0aGlzIHBvaW50LCBidXQgbGV0IG1lIGFzayBh bnl3YXlzLsKgIFdoeSBkbyB3ZSBzdGlsbDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4gJmd0OyBuZWVkIGRpZmZlcmVudCB0b29scyBmb3IgcGFja2V0IHN3aXRjaGVkIHZzIHBh Y2tldCB0cmFuc3BvcnQgbmV0d29ya3M/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiAmZ3Q7IFRoZSB0d28gdGVybXMgYXJlIHNvIHNpbWlsYXIgdGhhdCBpdCdzIG5vdCBvYnZp b3VzIG9uIGl0cyBmYWNlIHdoZXRoZXI8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+ICZndDsgdGhlc2UgdHdvIGFyZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBp cyBpdCByZWFsbHkgd29ydGggYWxsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiAmZ3Q7IHRoZSBoYXNzbGUgZnJvbSBhIHRlY2huaWNhbCBwZXJzcGVjdGl2ZT88bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PklmIHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwg YnV0IHBhY2tldCB0cmFuc3BvcnQgZGlmZmVyczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD5mcm9tIHBhY2tldCBzd2l0Y2hpbmcgaW4gdGhlIHdheSBwYWNrZXRzIGFyZSB0cmFu c3BvcnRlZC4gSW4gcGFja2V0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnRy YW5zcG9ydCB0aGUgb2JqZWN0aXZlIGlzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5k IG9mIHRoZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD50ZWNobm9sb2d5LCBz byBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnRoZSBzYW1lIGluIGFsbCB0cmFuc3Bv cnQgdGVjaG5vbG9naWVzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBBbmQgaWYgdGhhdCdz IHRydWUgYW5kIHdhcyB0cnVlIGFsbCBhbG9uZywgd2h5IGRpZCBldmVyeW9uZSBhZ3JlZTxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4gJmd0OyB0byBjb29wZXJhdGUgaW4gdGhl IGZpcnN0IHBsYWNlIFtKV1QgYWdyZWVtZW50XSwgYW5kIGFncmVlIHRoYXQgdGhlcmU8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ICZndDsgc2hvdWxkIG9ubHkgYmUgb25lIHNv bHV0aW9uIFtyZWYuIFJ1c3MgSG91c2VseSdzIGJyaWVmIHRhbGsgaW4gQmVpamluZ10/PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD5KdXN0IG91dCBvZiBjdXJpb3NpdHk6PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PldoZW4gYW5kIHdoZXJlIHdhcyB0aGlzIGFncmVlZD88bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+V2hvIHdhcyBwcmVzZW50IHdoZW4gdGhpcyBh Z3JlZW1lbnQgd2FzIHJlYWNoZWQ/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5SZWdhcmRzLCBIdXVi LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEh1dWIgdmFuIEhlbHZvb3J0PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMTgsIDIwMTEgNTo1MyBQTTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7Jmd0OyBUbzogbXBsc0BpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0 ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IDA0My4wMl08bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyZndDsgSGVsbG8gUm9zcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyZndDsgWW91IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0 OyZndDsgVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBMZXQgbWUgdHJ5IHRvIGFuc3dlciB0aGVtPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0O8KgwqDCoMKgwqDCoCAtIERv IHdlIHdhbnQgb25lIHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3IgdHdvPzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBJIHRoaW5rIHdlIHdhbnQgb25lIHRvb2xib3ggd2l0 aCBhIHNldCBvZiB0b29scy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyZndDsgSXQgbWF5IGhhcHBlbiB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBi dXQgbWF5IGJlIGRpZmZlcmVudCBpbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7Jmd0OyBkZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2VkIGluIGEgZGlmZmVyZW50IGNv bnRleHQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0O8KgwqDCoMKg wqDCoCAtIE9uY2Ugd2UgbWFrZSBhIGRlY2lzaW9uLCBkbyB3ZSBpbnRlbmQgdG8gd29yayB0byBt YWtlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0O8KgwqDC oMKgwqDCoMKgwqAgaXQgaGFwcGVuLCBvciB0byBjb250aW51ZSB0aGUgYXJndW1lbnQgaW5kZWZp bml0ZWx5PzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBJIHdlIGFncmVl IHRoYXQgdGhlcmUgY2FuIGJlIGRpZmZlcmVudCBjb250ZXh0cyBpbiB3aGljaCBkZWRpY2F0ZWQg dG9vbHM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgZnJvbSB0 aGUgdG9vbGJveCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3NpdGlvbiBkaXNhcHBlYXJzLjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDvCoMKgwqDCoMKgwqAgLSBEbyB3ZSB3 YW50IHN0YW5kYXJkcyBmb3IgdGhlIElFVEYgVENQL0lQL01QTFMgcHJvdG9jb2wgc3VpdGU8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7wqDCoMKgwqDCoMKg wqDCoCB0byBiZSBkb25lIGluIG9uZSBzdGFuZGFyZHMgYm9keSwgb3IgaW5kZXBlbmRlbnRseSBp biB0d288bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7wqDC oMKgwqDCoMKgwqDCoCBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21wYXRpYmxlIHN0YW5kYXJk cyByZXN1bHRpbmc/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IElmIHdl IGFncmVlIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCBjb250ZXh0cywgaXQgc2hvdWxkIGJlIHBv c3NpYmxlIHRvPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IGhh dmUgdGhlIGNvbnRleHQgc2Vuc2l0aXZlIHRvb2xzIGRldmVsb3BwZWQgYnkgdGhlIGV4cGVydHMg aW4gYSBwYXJ0aWN1bGFyPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsm Z3Q7IGNvbnRleHQvYXJlYS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsg Q3VycmVudGx5IEkgY2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czo8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3Jrcywg dGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsmZ3Q7wqDCoMKgwqDCoMKgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9v bHM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgLTItIHBhY2tl dCB0cmFuc3BvcnQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZTxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0O8KgwqDCoMKgwqDCoCBz aW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFJlZ2FyZHMsIEh1dWIuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+LS0gPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpTaW1TdW4nPuaIkeeIseWklueC ueS4gOS4g+S4ieS4gDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+bXBscyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+bXBsc0BpZXRmLm9yZzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHM8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CBB7AA.360D5E4B-- From nurit.sprecher@nsn.com Tue Jan 18 23:29:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0170B3A70EA for ; Tue, 18 Jan 2011 23:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.608 X-Spam-Level: X-Spam-Status: No, score=-4.608 tagged_above=-999 required=5 tests=[AWL=1.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el6a1katyANE for ; Tue, 18 Jan 2011 23:29:27 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 4C2173A70E6 for ; Tue, 18 Jan 2011 23:29:26 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0J7W4kJ012606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 08:32:04 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0J7W07I000335; Wed, 19 Jan 2011 08:32:04 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 08:31:53 +0100 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_01CBB7AA.F1D09BAD" Date: Wed, 19 Jan 2011 08:31:50 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640336B5CE@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A532640336B5BC@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref043.02] Thread-Index: Acu3pr0nWnGAJkoaS32EMgwRas2GVwAAR2rwAADCEUA= References: <4D3619B1.1090301@gmail.com><4D368C1B.7080106@gmail.com> <077E41CFFD002C4CAB7DFA4386A532640336B5BC@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Huub van Helvoort" , X-OriginalArrivalTime: 19 Jan 2011 07:31:53.0734 (UTC) FILETIME=[F1AFBA60:01CBB7AA] Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:29:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB7AA.F1D09BAD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IA0KDQpIdXViLA0KDQpZb3Ugc2F5Og0KDQoiSWYgeW91IGxvb2sgYXQgdGhlIHRlcm1zIHRoZXkg bG9vayBzaW1pbGFyLCBidXQgcGFja2V0IHRyYW5zcG9ydCBkaWZmZXJzIGZyb20gcGFja2V0IHN3 aXRjaGluZyBpbiB0aGUgd2F5IHBhY2tldHMgYXJlIHRyYW5zcG9ydGVkLiBJbiBwYWNrZXQgdHJh bnNwb3J0IHRoZSBvYmplY3RpdmUgaXMgdG8gdHJhbnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQg b2YgdGhlIHRlY2hub2xvZ3ksIHNvIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBPQU0gZm9yIHBh Y2tldCB0cmFuc3BvcnQgaXMgdGhlIHNhbWUgaW4gYWxsIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMu Ig0KDQpOdXJpdDogRG8geW91IHNheSB0aGF0IHRoZSBmb3J3YXJkaW5nIG9mIHBhY2tldHMgaXMg ZGlmZmVyZW50IGluIGJvdGggcHJvcG9zYWxzPyBEbyB5b3Ugc2F5IHRoYXQgaW4gdHJhbnNwb3J0 IG5ldHdvcmtzIHRoZSBmb3J3YXJkaW5nIG9mIHRoZSBwYWNrZXRzIGlzIGluZGVwZW5kZW50IG9m IHRoZSBNUExTIGZvcndhcmRpbmcgbWVjaGFuaXNtcz8gSXMgdGhlcmUgYSBtYWdpYyB3YXkgdG8g dHJhbnNtaXQgdGhlIHBhY2tldHMgd2l0aG91dCByZWx5aW5nIG9uIHRoZSB0ZWNobm9sb2d5PyAN Cg0KQWxzbywgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgbG9naWMgYmV0d2VlbiB0aGUgcmVxdWly ZW1lbnQgeW91IHB1dCAidG8gdHJhbnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlIHRl Y2hub2xvZ3kiIGFuZCB0aGUgY29uY2x1c2lvbiB0aGF0ICJpdCBpcyBpbXBvcnRhbnQgdGhhdCB0 aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzIHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQg dGVjaG5vbG9naWVzIg0KDQpUaGUgcmVxdWlyZW1lbnQgaXMgdG8gaGF2ZSBzaW1pbGFyIGZ1bmN0 aW9uYWxpdHkgYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgYXMgaW4gb3RoZXIgdHJhbnNwb3J0 IG5ldHdvcmvigKZ0aGlzIGRvZXMgbm90IG1lYW4gdGhhdCBpdCBoYXMgdG8gYmUgaW1wbGVtZW50 ZWQgdGhlIHNhbWUgd2F54oCmLm9yIHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIHVzZSB0aGUgc2Ft ZSBmcmFtZSBmb3JtYXTigKYuc28gcGxlYXNlIHN0b3AgY29uZnVzaW5nIHRoZSBJbmR1c3RyeSEg VGhlIHdheSBpdCBsb29rcyBhbmQgZmVlbCBkb2VzIG5vdCBkaWN0YXRlIGhvdyBpdCBpcyBpbXBs ZW1lbnRlZCBhbmQgd2hpY2ggZnJhbWUgZm9ybWF0cyBhcmUgdXNlZC4NCg0KSW4gTVBMUy1UUCB0 aGUgZm9yd2FyZGluZyBpcyBiYXNlZCBvbiB0aGUgTVBMUyBmb3J3YXJkaW5nIGNvbnN0cnVjdCBh bmQgdGhlIE9BTSBwYWNrZXRzIG1heSBiZSBzZW50IGluYmFuZCBvdmVyIEctQWNo4oCmLi4NCg0K WW91ciBhcmd1bWVudHMgbWFrZSBtZSB2ZXJ5IG11Y2ggY29uY2VybmVkIG5vd+KApmFuZCB0aGUg bmVlZCB0byBkZWZpbmUgYSB0ZWNobm9sb2d5IGluIHRoZSBwbGFjZSB3aGVyZSB0aGUgZGVzaWdu IGF1dGhvcml0eSBleGlzdHMgc2VlbXMgdG8gYmUgc3Ryb25nZXIgdGhhbiBldmVyIQ0KDQpCUiwN Cg0KTm51cml0DQoNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGV4dCBIdXViIHZhbiBIZWx2b29ydA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDE5LCAy MDExIDk6MDEgQU0NClRvOiBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFJlc3Bv bnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmIDA0My4wMl0N Cg0KIA0KDQpIZWxsbyBFcmljLA0KDQogDQoNCllvdSByZXBsaWVkOg0KDQogDQoNCj4gICAgSSB0 aGluayB0aGUgY3J1eCBvZiB5b3VyIHBvaW50cyBpcyB0aGlzOg0KDQo+IA0KDQo+PiBDdXJyZW50 bHkgSSBjYW4gaWRlbnRpZnkgdHdvIGNvbnRleHRzOg0KDQo+PiAtMS0gcGFja2V0IHN3aXRjaGVk IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCg0KPj4gICAgICAg c2ltaWxhciB0byBleGlzdGluZyB0b29scw0KDQo+PiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3 b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAgICAgIHNpbWls YXIgdG8gZXhpc3RpbmcgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KPiANCg0KPiBJIGRvdWJ0 IHdlJ2xsIGV2ZXIgZ2V0IGV2ZXJ5b25lIHRvIGhvbGQgaGFuZHMgYW5kIGFncmVlIGFuZCBzaW5n DQoNCj4gaGFwcHkgc29uZ3Mgb24gdGhpcyBwb2ludCwgYnV0IGxldCBtZSBhc2sgYW55d2F5cy4g IFdoeSBkbyB3ZSBzdGlsbA0KDQo+IG5lZWQgZGlmZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dp dGNoZWQgdnMgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3Jrcz8NCg0KPiBUaGUgdHdvIHRlcm1zIGFy ZSBzbyBzaW1pbGFyIHRoYXQgaXQncyBub3Qgb2J2aW91cyBvbiBpdHMgZmFjZSB3aGV0aGVyDQoN Cj4gdGhlc2UgdHdvIGFyZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCBy ZWFsbHkgd29ydGggYWxsDQoNCj4gdGhlIGhhc3NsZSBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0 aXZlPw0KDQogDQoNCklmIHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwg YnV0IHBhY2tldCB0cmFuc3BvcnQgZGlmZmVycw0KDQpmcm9tIHBhY2tldCBzd2l0Y2hpbmcgaW4g dGhlIHdheSBwYWNrZXRzIGFyZSB0cmFuc3BvcnRlZC4gSW4gcGFja2V0DQoNCnRyYW5zcG9ydCB0 aGUgb2JqZWN0aXZlIGlzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRoZQ0K DQp0ZWNobm9sb2d5LCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQg dHJhbnNwb3J0IGlzDQoNCnRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLg0K DQogDQoNCj4gQW5kIGlmIHRoYXQncyB0cnVlIGFuZCB3YXMgdHJ1ZSBhbGwgYWxvbmcsIHdoeSBk aWQgZXZlcnlvbmUgYWdyZWUNCg0KPiB0byBjb29wZXJhdGUgaW4gdGhlIGZpcnN0IHBsYWNlIFtK V1QgYWdyZWVtZW50XSwgYW5kIGFncmVlIHRoYXQgdGhlcmUNCg0KPiBzaG91bGQgb25seSBiZSBv bmUgc29sdXRpb24gW3JlZi4gUnVzcyBIb3VzZWx5J3MgYnJpZWYgdGFsayBpbiBCZWlqaW5nXT8N Cg0KIA0KDQpKdXN0IG91dCBvZiBjdXJpb3NpdHk6DQoNCldoZW4gYW5kIHdoZXJlIHdhcyB0aGlz IGFncmVlZD8NCg0KV2hvIHdhcyBwcmVzZW50IHdoZW4gdGhpcyBhZ3JlZW1lbnQgd2FzIHJlYWNo ZWQ/DQoNCiANCg0KUmVnYXJkcywgSHV1Yi4NCg0KIA0KDQogDQoNCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQoNCj4+IEh1dWIgdmFuIEhlbHZvb3J0 DQoNCj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTgsIDIwMTEgNTo1MyBQTQ0KDQo+PiBUbzog bXBsc0BpZXRmLm9yZw0KDQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0 ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVmDQoNCj4+IDA0My4wMl0NCg0KPj4g DQoNCj4+IEhlbGxvIFJvc3MsDQoNCj4+IA0KDQo+PiBZb3Ugd3JvdGU6DQoNCj4+IA0KDQo+Pj4g VGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOg0KDQo+PiANCg0KPj4gTGV0 IG1lIHRyeSB0byBhbnN3ZXIgdGhlbQ0KDQo+PiANCg0KPj4+ICAgICAgIC0gRG8gd2Ugd2FudCBv bmUgc29sdXRpb24gZm9yIE1QTFMgT0FNLCBvciB0d28/DQoNCj4+IA0KDQo+PiBJIHRoaW5rIHdl IHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4NCg0KPj4gSXQgbWF5IGhhcHBl biB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBidXQgbWF5IGJlIGRpZmZlcmVu dCBpbg0KDQo+PiBkZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2VkIGluIGEgZGlmZmVyZW50IGNv bnRleHQuDQoNCj4+IA0KDQo+Pj4gICAgICAgLSBPbmNlIHdlIG1ha2UgYSBkZWNpc2lvbiwgZG8g d2UgaW50ZW5kIHRvIHdvcmsgdG8gbWFrZQ0KDQo+Pj4gICAgICAgICBpdCBoYXBwZW4sIG9yIHRv IGNvbnRpbnVlIHRoZSBhcmd1bWVudCBpbmRlZmluaXRlbHk/DQoNCj4+IA0KDQo+PiBJIHdlIGFn cmVlIHRoYXQgdGhlcmUgY2FuIGJlIGRpZmZlcmVudCBjb250ZXh0cyBpbiB3aGljaCBkZWRpY2F0 ZWQgdG9vbHMNCg0KPj4gZnJvbSB0aGUgdG9vbGJveCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3NpdGlv biBkaXNhcHBlYXJzLg0KDQo+PiANCg0KPj4+ICAgICAgIC0gRG8gd2Ugd2FudCBzdGFuZGFyZHMg Zm9yIHRoZSBJRVRGIFRDUC9JUC9NUExTIHByb3RvY29sIHN1aXRlDQoNCj4+PiAgICAgICAgIHRv IGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBpbmRlcGVuZGVudGx5IGluIHR3bw0K DQo+Pj4gICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21wYXRpYmxlIHN0YW5kYXJk cyByZXN1bHRpbmc/DQoNCj4+IA0KDQo+PiBJZiB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkaWZm ZXJlbnQgY29udGV4dHMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0bw0KDQo+PiBoYXZlIHRoZSBj b250ZXh0IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRzIGluIGEgcGFy dGljdWxhcg0KDQo+PiBjb250ZXh0L2FyZWEuDQoNCj4+IA0KDQo+PiBDdXJyZW50bHkgSSBjYW4g aWRlbnRpZnkgdHdvIGNvbnRleHRzOg0KDQo+PiAtMS0gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtz LCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmUNCg0KPj4gICAgICAgc2ltaWxhciB0 byBleGlzdGluZyB0b29scw0KDQo+PiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhl IGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAgICAgIHNpbWlsYXIgdG8gZXhp c3RpbmcgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KPj4gDQoNCj4+IFJlZ2FyZHMsIEh1dWIu DQoNCiANCg0KIA0KDQotLSANCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICDmiJHniLHlpJbngrnkuIDkuIPkuInkuIANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KbXBscyBtYWlsaW5nIGxpc3QNCg0KbXBsc0BpZXRmLm9y Zw0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K ------_=_NextPart_001_01CBB7AA.F1D09BAD Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1T dW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0 DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0Pkh1dWIsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PllvdSBzYXk6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSdtYXJn aW4tbGVmdDozNi4wcHQnPiZxdW90O0lmIHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sg c2ltaWxhciwgYnV0IDxzcGFuIHN0eWxlPSdiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0 OnllbGxvdyc+cGFja2V0IHRyYW5zcG9ydCBkaWZmZXJzIGZyb20gcGFja2V0IHN3aXRjaGluZyBp biB0aGUgd2F5IHBhY2tldHMgYXJlIHRyYW5zcG9ydGVkLiBJbiBwYWNrZXQgdHJhbnNwb3J0IHRo ZSBvYmplY3RpdmUgaXMgdG8gdHJhbnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlIHRl Y2hub2xvZ3k8L3NwYW4+LCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNr ZXQgdHJhbnNwb3J0IGlzIHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLiZx dW90OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48dT5OdXJpdDwvdT46IDxi Pjx1PjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPkRvIHlvdSBzYXkgdGhhdCB0aGUgZm9yd2FyZGlu ZyBvZiBwYWNrZXRzIGlzIGRpZmZlcmVudCBpbiBib3RoIHByb3Bvc2Fscz88L3NwYW4+PC91Pjwv Yj4gRG8geW91IHNheSB0aGF0IGluIHRyYW5zcG9ydCBuZXR3b3JrcyB0aGUgZm9yd2FyZGluZyBv ZiB0aGUgcGFja2V0cyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgTVBMUyBmb3J3YXJkaW5nIG1lY2hh bmlzbXM/IElzIHRoZXJlIGEgbWFnaWMgd2F5IHRvIHRyYW5zbWl0IHRoZSBwYWNrZXRzIHdpdGhv dXQgcmVseWluZyBvbiB0aGUgdGVjaG5vbG9neT8gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PkFsc28sIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIGxvZ2ljIGJldHdlZW4gdGhl IHJlcXVpcmVtZW50IHlvdSBwdXQgJnF1b3Q7PHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6eWVsbG93 O21zby1oaWdobGlnaHQ6eWVsbG93Jz50byB0cmFuc3BvcnQgcGFja2V0cyBpbmRlcGVuZGVuZCBv ZiB0aGUgdGVjaG5vbG9neTwvc3Bhbj4mcXVvdDsgYW5kIHRoZSBjb25jbHVzaW9uIHRoYXQgJnF1 b3Q7PHNwYW4gc3R5bGU9J2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Jz5p dCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzIHRoZSBz YW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzPC9zcGFuPiZxdW90OzxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UaGUgcmVxdWlyZW1lbnQgaXMgdG8gaGF2ZSA8Yj48 dT48c3BhbiBzdHlsZT0nY29sb3I6cmVkJz5zaW1pbGFyIGZ1bmN0aW9uYWxpdHkgYW5kIG9wZXJh dGlvbmFsIGV4cGVyaWVuY2UgYXMgaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdvcms8L3NwYW4+PC91 PjwvYj7igKZ0aGlzIGRvZXMgbm90IG1lYW4gdGhhdCBpdCBoYXMgdG8gYmUgaW1wbGVtZW50ZWQg dGhlIHNhbWUgd2F54oCmLm9yIHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIHVzZSB0aGUgc2FtZSBm cmFtZSBmb3JtYXTigKYuPGI+PHU+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+c28gcGxlYXNlIHN0 b3AgY29uZnVzaW5nIHRoZSBJbmR1c3RyeSEgVGhlIHdheSBpdCBsb29rcyBhbmQgZmVlbCBkb2Vz IG5vdCBkaWN0YXRlIGhvdyBpdCBpcyBpbXBsZW1lbnRlZCBhbmQgd2hpY2ggZnJhbWUgZm9ybWF0 cyBhcmUgdXNlZC48L3NwYW4+PC91PjxvOnA+PC9vOnA+PC9iPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+SW4gTVBMUy1UUCB0aGUgZm9yd2FyZGluZyBpcyBiYXNlZCBvbiB0aGUgTVBMUyBmb3J3 YXJkaW5nIGNvbnN0cnVjdCBhbmQgdGhlIE9BTSBwYWNrZXRzIG1heSBiZSBzZW50IGluYmFuZCBv dmVyIEctQWNo4oCmLi48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+WW91ciBh cmd1bWVudHMgbWFrZSBtZSB2ZXJ5IG11Y2ggY29uY2VybmVkIG5vd+KApmFuZCB0aGUgbmVlZCB0 byBkZWZpbmUgYSB0ZWNobm9sb2d5IGluIHRoZSBwbGFjZSB3aGVyZSB0aGUgZGVzaWduIGF1dGhv cml0eSBleGlzdHMgc2VlbXMgdG8gYmUgc3Ryb25nZXIgdGhhbiBldmVyITxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD5CUiw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Tm51cml0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj5Gcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgSHV1YiB2YW4gSGVsdm9vcnQ8YnI+U2VudDogV2Vk bmVzZGF5LCBKYW51YXJ5IDE5LCAyMDExIDk6MDEgQU08YnI+VG86IG1wbHNAaWV0Zi5vcmc8YnI+ U3ViamVjdDogUmU6IFttcGxzXSBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0 aW9uIEcudHBvYW0gW1JlZiAwNDMuMDJdPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5IZWxsbyBFcmlj LDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+WW91IHJlcGxpZWQ6PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhlIGNydXggb2YgeW91ciBwb2ludHMg aXMgdGhpczo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBDdXJyZW50bHkgSSBj YW4gaWRlbnRpZnkgdHdvIGNvbnRleHRzOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7Jmd0OyAtMS0gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVk IHRvb2xzIHNob3VsZCBiZWhhdmU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2ltaWxhciB0byBl eGlzdGluZyB0b29sczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0 OyAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91 bGQgYmVoYXZlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpbWlsYXIgdG8gZXhpc3RpbmcgdHJh bnNwb3J0IHRlY2hub2xvZ2llcy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IEkgZG91 YnQgd2UnbGwgZXZlciBnZXQgZXZlcnlvbmUgdG8gaG9sZCBoYW5kcyBhbmQgYWdyZWUgYW5kIHNp bmc8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBoYXBweSBzb25ncyBv biB0aGlzIHBvaW50LCBidXQgbGV0IG1lIGFzayBhbnl3YXlzLiZuYnNwOyBXaHkgZG8gd2Ugc3Rp bGw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBuZWVkIGRpZmZlcmVu dCB0b29scyBmb3IgcGFja2V0IHN3aXRjaGVkIHZzIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3M/ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgVGhlIHR3byB0ZXJtcyBh cmUgc28gc2ltaWxhciB0aGF0IGl0J3Mgbm90IG9idmlvdXMgb24gaXRzIGZhY2Ugd2hldGhlcjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHRoZXNlIHR3byBhcmUgYWN0 dWFsbHkgYW55IGRpZmZlcmVudCBhbnkgbW9yZSwgaXMgaXQgcmVhbGx5IHdvcnRoIGFsbDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHRoZSBoYXNzbGUgZnJvbSBhIHRl Y2huaWNhbCBwZXJzcGVjdGl2ZT88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PklmIHlvdSBsb29rIGF0 IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwgYnV0IHBhY2tldCB0cmFuc3BvcnQgZGlmZmVy czxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5mcm9tIHBhY2tldCBzd2l0Y2hp bmcgaW4gdGhlIHdheSBwYWNrZXRzIGFyZSB0cmFuc3BvcnRlZC4gSW4gcGFja2V0PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PnRyYW5zcG9ydCB0aGUgb2JqZWN0aXZlIGlzIHRv IHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRoZTxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD50ZWNobm9sb2d5LCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUg T0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0IGlzPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PnRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyBBbmQgaWYgdGhhdCdzIHRydWUgYW5kIHdhcyB0cnVlIGFsbCBhbG9u Zywgd2h5IGRpZCBldmVyeW9uZSBhZ3JlZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IHRvIGNvb3BlcmF0ZSBpbiB0aGUgZmlyc3QgcGxhY2UgW0pXVCBhZ3JlZW1lbnRd LCBhbmQgYWdyZWUgdGhhdCB0aGVyZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7IHNob3VsZCBvbmx5IGJlIG9uZSBzb2x1dGlvbiBbcmVmLiBSdXNzIEhvdXNlbHkncyBi cmllZiB0YWxrIGluIEJlaWppbmddPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+SnVzdCBvdXQgb2Yg Y3VyaW9zaXR5OjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5XaGVuIGFuZCB3 aGVyZSB3YXMgdGhpcyBhZ3JlZWQ/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PldobyB3YXMgcHJlc2VudCB3aGVuIHRoaXMgYWdyZWVtZW50IHdhcyByZWFjaGVkPzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+UmVnYXJkcywgSHV1Yi48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 Jmd0OyBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7Jmd0OyBIdXViIHZhbiBIZWx2b29ydDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7Jmd0OyBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE4LCAyMDExIDU6NTMgUE08bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgVG86IG1wbHNAaWV0Zi5v cmc8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgU3ViamVjdDog UmU6IFttcGxzXSBSZXNwb25zZSB0byBVcGRhdGVkIGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBv YW0gW1JlZjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyAwNDMu MDJdPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEhlbGxvIFJvc3MsPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFlvdSB3cm90ZTo8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7IFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJl ZSBxdWVzdGlvbnMgaGVyZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsg TGV0IG1lIHRyeSB0byBhbnN3ZXIgdGhlbTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBEbyB3ZSB3 YW50IG9uZSBzb2x1dGlvbiBmb3IgTVBMUyBPQU0sIG9yIHR3bz88bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgSSB0aGluayB3ZSB3YW50IG9uZSB0b29sYm94IHdpdGggYSBz ZXQgb2YgdG9vbHMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7 IEl0IG1heSBoYXBwZW4gdGhhdCB0aGVyZSBhcmUgdG9vbHMgdGhhdCBvb2sgYWxpa2UgYnV0IG1h eSBiZSBkaWZmZXJlbnQgaW48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyZndDsgZGV0YWlsIGJlY2F1c2UgdGhleSBhcmUgdXNlZCBpbiBhIGRpZmZlcmVudCBjb250ZXh0 LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBPbmNlIHdlIG1ha2UgYSBkZWNpc2lvbiwgZG8gd2Ug aW50ZW5kIHRvIHdvcmsgdG8gbWFrZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaXQgaGFwcGVuLCBvciB0byBjb250aW51ZSB0aGUgYXJndW1lbnQgaW5kZWZpbml0ZWx5 PzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBJIHdlIGFncmVlIHRoYXQg dGhlcmUgY2FuIGJlIGRpZmZlcmVudCBjb250ZXh0cyBpbiB3aGljaCBkZWRpY2F0ZWQgdG9vbHM8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgZnJvbSB0aGUgdG9v bGJveCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3NpdGlvbiBkaXNhcHBlYXJzLjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLSBEbyB3ZSB3YW50IHN0YW5kYXJkcyBmb3IgdGhlIElFVEYgVENQL0lQL01QTFMg cHJvdG9jb2wgc3VpdGU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRv IGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBpbmRlcGVuZGVudGx5IGluIHR3bzxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlmZmVyZW50IGdyb3VwcyB3 aXRoIGluY29tcGF0aWJsZSBzdGFuZGFyZHMgcmVzdWx0aW5nPzxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7Jmd0OyBJZiB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQg Y29udGV4dHMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0bzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBoYXZlIHRoZSBjb250ZXh0IHNlbnNpdGl2ZSB0b29scyBk ZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRzIGluIGEgcGFydGljdWxhcjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBjb250ZXh0L2FyZWEuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEN1cnJlbnRseSBJIGNhbiBpZGVudGlmeSB0d28gY29u dGV4dHM6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IC0xLSBw YWNrZXQgc3dpdGNoZWQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2 ZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaW1pbGFyIHRvIGV4aXN0aW5nIHRvb2xzPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IC0yLSBwYWNrZXQgdHJhbnNw b3J0IG5ldHdvcmtzLCB0aGUgZGVkaWNhdGVkIHRvb2xzIHNob3VsZCBiZWhhdmU8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgc2ltaWxhciB0byBleGlzdGluZyB0cmFuc3BvcnQgdGVjaG5vbG9naWVz LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBSZWdhcmRzLCBIdXViLjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0Pi0tIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OlNpbVN1bic+5oiR54ix5aSW 54K55LiA5LiD5LiJ5LiAPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5tcGxzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5tcGxzQGlldGYub3JnPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBsczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CBB7AA.F1D09BAD-- From huubatwork@gmail.com Tue Jan 18 23:53:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F71C3A6F22 for ; Tue, 18 Jan 2011 23:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYqh4qGWY19D for ; Tue, 18 Jan 2011 23:53:07 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8A10A3A70E6 for ; Tue, 18 Jan 2011 23:53:06 -0800 (PST) Received: by wwa36 with SMTP id 36so554455wwa.13 for ; Tue, 18 Jan 2011 23:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zMhQZtVlzyw2K6qTe5o8aFnIzredeql0U7NBQwmJ/ws=; b=Bo3DYpdMCsTHLtmio5beagdGwNCwcGWmsDNQXgL1jTOmvhgM6LNrDF3b5x7oLXTaTI pFkQO49bP67q3492UzDvFpDyb/XUpGNTz9wMFFQveFaZzNypf7Hh6s2Lto/6Ljj3qIci oWRspCupZgIrdxze0lLCLPC9aTw9XQRS8DOCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=l/1i0xHyp/U0ytoir2MqRF8sKVVuA/FO+1SqxFPkdeTd3cnSAumiUfdLbSJA6vCs15 rbu74/Vq/ZEQHMO5T/KFxhkD6WAMMjGzzdMG9zaOlCFcYv5GotTG03ZRqbuqVTuSbDQI xJwoZwxo3Smcs0kgwHAmq7qzfs7LIyohe8xnM= Received: by 10.227.143.148 with SMTP id v20mr325903wbu.222.1295423744823; Tue, 18 Jan 2011 23:55:44 -0800 (PST) Received: from McAsterix.local ([81.253.44.162]) by mx.google.com with ESMTPS id 11sm4894425wbj.13.2011.01.18.23.55.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 23:55:43 -0800 (PST) Message-ID: <4D3698FD.6060304@gmail.com> Date: Wed, 19 Jan 2011 08:55:41 +0100 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: mpls@ietf.org References: <4D3619B1.1090301@gmail.com> , <4D368C1B.7080106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:53:08 -0000 Hi Sasha, You replied: > In packet transport the objective is to transport packets independent of the technology. > > If you mean that the objective is to transport packets independent of the data plane technology, > I'd say that such an objective is IMHO unrealistic. >From a management point of view it is realistic, you manage the transport of Characteristic Information from ingress to egress. Regards, Huub. > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Huub van Helvoort [huubatwork@gmail.com] > Sent: Wednesday, January 19, 2011 9:00 AM > To: mpls@ietf.org > Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] > > Hello Eric, > > You replied: > >> I think the crux of your points is this: >> >>> Currently I can identify two contexts: >>> -1- packet switched networks, the dedicated tools should behave >>> similar to existing tools >>> -2- packet transport networks, the dedicated tools should behave >>> similar to existing transport technologies. >> >> I doubt we'll ever get everyone to hold hands and agree and sing > > happy songs on this point, but let me ask anyways. Why do we still > > need different tools for packet switched vs packet transport networks? > > The two terms are so similar that it's not obvious on its face whether > > these two are actually any different any more, is it really worth all > > the hassle from a technical perspective? > > If you look at the terms they look similar, but packet transport differs > from packet switching in the way packets are transported. In packet > transport the objective is to transport packets independend of the > technology, so it is important that the OAM for packet transport is > the same in all transport technologies. > >> And if that's true and was true all along, why did everyone agree > > to cooperate in the first place [JWT agreement], and agree that there > > should only be one solution [ref. Russ Housely's brief talk in Beijing]? > > Just out of curiosity: > When and where was this agreed? > Who was present when this agreement was reached? > > Regards, Huub. > > >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Huub van Helvoort >>> Sent: Tuesday, January 18, 2011 5:53 PM >>> To: mpls@ietf.org >>> Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref >>> 043.02] >>> >>> Hello Ross, >>> >>> You wrote: >>> >>>> There are at least three questions here: >>> >>> Let me try to answer them >>> >>>> - Do we want one solution for MPLS OAM, or two? >>> >>> I think we want one toolbox with a set of tools. >>> It may happen that there are tools that ook alike but may be different in >>> detail because they are used in a different context. >>> >>>> - Once we make a decision, do we intend to work to make >>>> it happen, or to continue the argument indefinitely? >>> >>> I we agree that there can be different contexts in which dedicated tools >>> from the toolbox can be used the opposition disappears. >>> >>>> - Do we want standards for the IETF TCP/IP/MPLS protocol suite >>>> to be done in one standards body, or independently in two >>>> different groups with incompatible standards resulting? >>> >>> If we agree that there are different contexts, it should be possible to >>> have the context sensitive tools developped by the experts in a particular >>> context/area. >>> >>> Currently I can identify two contexts: >>> -1- packet switched networks, the dedicated tools should behave >>> similar to existing tools >>> -2- packet transport networks, the dedicated tools should behave >>> similar to existing transport technologies. >>> >>> Regards, Huub. -- ***************************************************************** ÎÒ°®ÍâµãÒ»ÆßÈýÒ» From Alexander.Vainshtein@ecitele.com Wed Jan 19 01:06:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BCB3A6EB1 for ; Wed, 19 Jan 2011 01:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=-2.127, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q1gQyUKSYOe for ; Wed, 19 Jan 2011 01:06:02 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 55B0F3A6E80 for ; Wed, 19 Jan 2011 01:06:01 -0800 (PST) X-AuditID: 93eaf2e7-b7b6aae00000348b-15-4d36aa19411b Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id B9.52.13451.91AA63D4; Wed, 19 Jan 2011 11:08:42 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 19 Jan 2011 11:10:25 +0200 From: Alexander Vainshtein To: Huub van Helvoort Date: Wed, 19 Jan 2011 11:10:23 +0200 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3rktJq5yKl0UBRn+KU8zJ/+in8AABZCug Message-ID: References: <4D3619B1.1090301@gmail.com> , <4D368C1B.7080106@gmail.com> <4D3698FD.6060304@gmail.com> In-Reply-To: <4D3698FD.6060304@gmail.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 09:06:03 -0000 SHV1YiwNClNvcnJ5IHRvIHNheSB0aGF0LCBidXQgSSd2ZSBmYWlsZWQgdG8gdW5kZXJzdGFuZCB5 b3VyIHJlc3BvbnNlIGFuZCBpdHMgbGlua2FnZSB0byB0aGUgb3JpZ2luYWwgdG9waWMgb2YgdGhl IGRpc2N1c3Npb24NCihjb3VsZCBiZSBiZWNhdXNlIEkgYW0gZXhjZXB0aW9uYWxseSBkdW1iIHRv ZGF5Oi0pLg0KDQpPciBjb3VsZCBpdCBiZSB0aGF0IHlvdSd2ZSBtaXN1bmRlcnN0b29kIG15IHN0 YXRlbWVudD8NCg0KUGxlYXNlIGJlYXIgbWUgdG8gcmVtaW5kIHlvdSBhYm91dCBhdCBsZWFzdCB0 aHJlZSB3ZWxsLWtub3duIGRpZmZlcmVuY2VzIGJldHdlZW4gRXRoZXJuZXQgYW5kIE1QTFMvTVBM Uy1UUCBkYXRhIHBsYW5lcyB0aGF0LCBJTUhPLCBkaXJlY3RseSBhZmZlY3QgdGhlIGRhdGEgcGxh bmUgT0FNIHRvb2xzZXRzLg0KDQoxLiBMYXllcmluZy9uZXN0aW5nIDoNCi0gVGhlcmUgaXMgZWZm ZWN0aXZlbHkgbm8gbGF5ZXJpbmcvbmVzdGluZyBpbiB0aGUgRXRoZXJuZXQgZGF0YSBwbGFuZSAo bGV0J3MgcHV0IGFzaWRlIFBCL1BCQiBmb3IgdGhlIG1vbWVudCkuIEhlbmNlDQogIHRoZSBuZWVk IGZvciBlbmNvZGluZyB0aGUgbmVzdGluZyBsZXZlbHMgaW4gdGhlIElFRUUgODAyLjFhZy9ZLjE3 MzEgbWVzc2FnZXMgYW5kIGV4cGxpY2l0IHNwZWNpZmljYXRpb24gb2YgdHJlYXRtZW50DQogIG9m IHRoZXNlIG1lc3NhZ2VzIHdoZW4gcmVjZWl2ZWQgYnkgYSBNRVAgYXQgYSBkaWZmZXJlbnQgbGV2 ZWwNCi0gSW4gTVBMUy9NUExTLVRQIGxheWVyaW5nL25lc3RpbmcgaXMgbWFwcGVkIHRvIHRoZSBl eGlzdGluZyBkYXRhIHBsYW5lIGNvbnN0cnVjdCAodGhlIGxhYmVsIHN0YWNrKS4gQXMgYSBjb25z ZXF1ZW5jZSwNCiAgdGhlcmUgaXMgbm8gbmVlZCB0byBlbmNvZGUgdGhlIGxldmVsIGluIHRoZSBi b2R5IG9mIHRoZSBPQU0gbWVzc2FnZXMsIGJlY2F1c2UgdGhlIG1pc21hdGNoIGRvZXMgbm90IG9j Y3VyLg0KDQoyLiBBZGRyZXNzaW5nOg0KICAtIEV0aGVybmV0IHVzZXMgZ2xvYmFsbHkgdW5pcXVl IHVuaWNhc3QgTUFDIGFkZHJlc3NlcyBhcyB0aGUgaWRlbnRpZmllcnMgb2YgTUVQcyBhbmQgTUlQ cy4gQW5kIHRoZXNlIGFkZHJlc3NlcyBhcmUNCiAgICBpbmhlcmVudGx5IGVuY29kZWQgaW4gdGhl IE9BTSBtZXNzYWdlcyBnZW5lcmF0ZWQgYnkgdGhvc2UsIGFzIFNvdXJjZSBNQUMgYWRkcmVzc2Vz LCBhbmQgYXJlIGludGVycHJldGVkIGJ5IHRoZSANCiAgICBFdGhlcm5ldCBkYXRhIHBsYW5lIGlu IHRoZSBNQUMgbGVhcm5pbmcgcHJvY2Vzcy4gQnkgaW1wbGljYXRpb24sIE1JUCBhZGRyZXNzIGlz IGFsc28gZ2xvYmFsbHkgdW5pcXVlLg0KICAtIFRoZXJlIGlzIG5vIGdsb2JhbCBhZGRyZXNzaW5n IGF0IGFsbCBpbiB0aGUgTVBMUy9NUExTLVRQIGRhdGEgcGxhbmUuIElkZW50aWZpY2F0aW9uIG9m IHRoZSBzb3VyY2UgTUVQcy9NSVBzDQogICAgaW4gdGhlIE9BTSBtZXNzYWdlcyB0aGV5IGdlbmVy YXRlIGlzIGFuIGFydGlmYWN0IHRoYXQgZG9lcyBub3QgYWZmZWN0IHRoZSBkYXRhIHBsYW5lIGlu IGFueSB3YXkuIA0KICAgIEFuZCBNSVAgImFkZHJlc3NlcyIgYXJlIGJhc2VkIG9uIFRUTCwgc28g dGhhdCBhIGNoYW5nZSBpbiB0aGUgbnVtYmVyIG9mIGhvcHMgYmV0d2VlbiBhIE1FUCBhbmQgYSBN SVAgd291bGQNCiAgICBhZmZlY3QgYWRkcmVzc2luZy4gIA0KDQozLiBSZXZlcnNlIFBhdGhzDQog ICAtIFdpdGggRXRoZXJuZXQsIGlmIGEgTUVQIHNlbmRzIGEgbWVzc2FnZSB0byBhbm90aGVyIE1F UC9NSVAsIHRoZSBNQUMgbGVhcm5pbmcgcHJvY2VzcyBjcmVhdGVzIHRoZSByZXZlcnNlIHBhdGgg DQogICAgIGluIHRoZSBkYXRhIHBsYW5lIChhbmQgdGhpcyBwYXRoIHdpbGwgYmUgY28tcm91dGVk IHdpdGggdGhlIGFjdHVhbCBwYXRoIHRyYXZlcnNlZCBieSB0aGUgb3JpZ2luYWwgbWVzc2FnZSku DQogICAgIChJbmNpZGVudGFsbHksIE1BQyBsZWFybmluZyBtYXkgYWxzbyBwcm9kdWNlIHByb2Js ZW1zLCBhbmQgdGhpcyBpcyB3aHkgb25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCBPQU0gdG9vbHMg aW4NCiAgICAgRXRoZXJuZXQgbmV0d29ya3MgaXMgZmx1c2ggb2YgdGhlIEZJQi4gSXQgaXMgbm90 IHBhcnQgb2YgYW55IHN0YW5kYXJkLCBidXQgaXQgaXMgdGhlcmUgbmV2ZXJ0aGVsZXNzLikNCiAg IC0gSW4gTVBMUy9NUExTLVRQLCByZXZlcnNlIHBhdGhzIG11c3QgYmUgY3JlYXRlZCBieSB0aGUg Y29udHJvbCBvciBtYW5hZ2VtZW50IHBsYW5lIGFuZCBtYXkgYmUgY28tcm91dGVkIG9yIG5vdC4N CiAgICAgKFRoaXMgaXMgd2h5IHNvIG1hbnkgTVBMUy1UUCBPQU0gZG9jdW1lbnRzIGNvbnRhaW4g dGhlIGNhdmVhdHMgIk1VU1QgYXBwbGljYWJsZSB0byBjby1yb3V0ZWQgYmktZGlyZWN0aW9uYWwg UDJQICAgIA0KICAgICBMU1AiLCBvciAiTUFZIGJlIGFwcGxpY2FibGUgdG8gYSB1bmlkaXJlY3Rp b25hbCBQMlAvUDJNUCBMU1AgaWYgdGhlIHJldmVyc2UgcGF0aCBleGlzdHMiKS4NCiAgICAgQW5k IEFGQUlLLCB0aGVyZSBpcyBubyBhbmFsb2cgb2YgdGhlIExJQiBmbHVzaCBpbiBNUExTL01QTFMt VFAuDQoNCkkgYW0gbm90IHN1cmUgaWYgYSBodW1hbiBiZWluZyBvcGVyYXRpbmcgcGFja2V0IHRy YW5zcG9ydCBuZXR3b3JrcyBjYW4gaWdub3JlIHRoZXNlIGRpZmZlcmVuY2UgYW5kIHN0aWxsIG9w ZXJhdGUgYm90aCB0aGVzZSBuZXR3b3JrcyBlZmZlY3RpdmVseS4gQnV0IEkgYW0gcHJldHR5IHN1 cmUgdGhhdCB0aGUgT0FNIHByb3RvY29scyB1c2VkIGZvciBkZXRlY3Rpb24gYW5kIGxvY2FsaXph dGlvbiBvZiBkYXRhIHBsYW5lIGRlZmVjdHMgY291bGQgbm90IGlnbm9yZSB0aGVzZSBkaWZmZXJl bmNlcyBhbmQgcmVtYWluIHVzZWZ1bC4NCg0KDQpNeSAyYywNCiAgICAgU2FzaGENCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1dWIgdmFuIEhlbHZvb3J0DQpT ZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTksIDIwMTEgOTo1NiBBTQ0KVG86IG1wbHNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1l bmRhdGlvbiBHLnRwb2FtIFtSZWYgMDQzLjAyXQ0KDQpIaSBTYXNoYSwNCg0KWW91IHJlcGxpZWQ6 DQoNCj4gICAgICAgIEluIHBhY2tldCB0cmFuc3BvcnQgdGhlIG9iamVjdGl2ZSBpcyB0byB0cmFu c3BvcnQgcGFja2V0cyBpbmRlcGVuZGVudCBvZiB0aGUgdGVjaG5vbG9neS4NCj4gDQo+IElmIHlv dSBtZWFuIHRoYXQgdGhlIG9iamVjdGl2ZSBpcyB0byB0cmFuc3BvcnQgcGFja2V0cyBpbmRlcGVu ZGVudCBvZiB0aGUgZGF0YSBwbGFuZSB0ZWNobm9sb2d5LA0KPiBJJ2Qgc2F5IHRoYXQgc3VjaCBh biBvYmplY3RpdmUgaXMgSU1ITyB1bnJlYWxpc3RpYy4NCg0KRnJvbSBhIG1hbmFnZW1lbnQgcG9p bnQgb2YgdmlldyBpdCBpcyByZWFsaXN0aWMsIHlvdSBtYW5hZ2UgdGhlIHRyYW5zcG9ydCBvZg0K Q2hhcmFjdGVyaXN0aWMgSW5mb3JtYXRpb24gZnJvbSBpbmdyZXNzIHRvIGVncmVzcy4NCg0KUmVn YXJkcywgSHV1Yi4NCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBIdXViIHZhbiBIZWx2b29ydCBbaHV1YmF0d29ya0BnbWFpbC5jb21dDQo+IFNl bnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxOSwgMjAxMSA5OjAwIEFNDQo+IFRvOiBtcGxzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNv bW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYgMDQzLjAyXQ0KPiANCj4gSGVsbG8gRXJpYywNCj4gDQo+ IFlvdSByZXBsaWVkOg0KPiANCj4+ICAgICBJIHRoaW5rIHRoZSBjcnV4IG9mIHlvdXIgcG9pbnRz IGlzIHRoaXM6DQo+Pg0KPj4+IEN1cnJlbnRseSBJIGNhbiBpZGVudGlmeSB0d28gY29udGV4dHM6 DQo+Pj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBz aG91bGQgYmVoYXZlDQo+Pj4gICAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9vbHMNCj4+PiAt Mi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQg YmVoYXZlDQo+Pj4gICAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdHJhbnNwb3J0IHRlY2hub2xv Z2llcy4NCj4+DQo+PiBJIGRvdWJ0IHdlJ2xsIGV2ZXIgZ2V0IGV2ZXJ5b25lIHRvIGhvbGQgaGFu ZHMgYW5kIGFncmVlIGFuZCBzaW5nDQo+ICAgPiAgaGFwcHkgc29uZ3Mgb24gdGhpcyBwb2ludCwg YnV0IGxldCBtZSBhc2sgYW55d2F5cy4gIFdoeSBkbyB3ZSBzdGlsbA0KPiAgID4gIG5lZWQgZGlm ZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0IHRyYW5zcG9ydCBuZXR3 b3Jrcz8NCj4gICA+ICBUaGUgdHdvIHRlcm1zIGFyZSBzbyBzaW1pbGFyIHRoYXQgaXQncyBub3Qg b2J2aW91cyBvbiBpdHMgZmFjZSB3aGV0aGVyDQo+ICAgPiAgdGhlc2UgdHdvIGFyZSBhY3R1YWxs eSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCByZWFsbHkgd29ydGggYWxsDQo+ICAgPiAg dGhlIGhhc3NsZSBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlPw0KPiANCj4gSWYgeW91IGxv b2sgYXQgdGhlIHRlcm1zIHRoZXkgbG9vayBzaW1pbGFyLCBidXQgcGFja2V0IHRyYW5zcG9ydCBk aWZmZXJzDQo+IGZyb20gcGFja2V0IHN3aXRjaGluZyBpbiB0aGUgd2F5IHBhY2tldHMgYXJlIHRy YW5zcG9ydGVkLiBJbiBwYWNrZXQNCj4gdHJhbnNwb3J0IHRoZSBvYmplY3RpdmUgaXMgdG8gdHJh bnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlDQo+IHRlY2hub2xvZ3ksIHNvIGl0IGlz IGltcG9ydGFudCB0aGF0IHRoZSBPQU0gZm9yIHBhY2tldCB0cmFuc3BvcnQgaXMNCj4gdGhlIHNh bWUgaW4gYWxsIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQo+IA0KPj4gQW5kIGlmIHRoYXQncyB0 cnVlIGFuZCB3YXMgdHJ1ZSBhbGwgYWxvbmcsIHdoeSBkaWQgZXZlcnlvbmUgYWdyZWUNCj4gICA+ ICB0byBjb29wZXJhdGUgaW4gdGhlIGZpcnN0IHBsYWNlIFtKV1QgYWdyZWVtZW50XSwgYW5kIGFn cmVlIHRoYXQgdGhlcmUNCj4gICA+ICBzaG91bGQgb25seSBiZSBvbmUgc29sdXRpb24gW3JlZi4g UnVzcyBIb3VzZWx5J3MgYnJpZWYgdGFsayBpbiBCZWlqaW5nXT8NCj4gDQo+IEp1c3Qgb3V0IG9m IGN1cmlvc2l0eToNCj4gV2hlbiBhbmQgd2hlcmUgd2FzIHRoaXMgYWdyZWVkPw0KPiBXaG8gd2Fz IHByZXNlbnQgd2hlbiB0aGlzIGFncmVlbWVudCB3YXMgcmVhY2hlZD8NCj4gDQo+IFJlZ2FyZHMs IEh1dWIuDQo+IA0KPiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206 IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+Pj4gSHV1YiB2YW4gSGVsdm9vcnQNCj4+PiBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDE4LCAyMDExIDU6NTMgUE0NCj4+PiBUbzogbXBsc0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6 IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRw b2FtIFtSZWYNCj4+PiAwNDMuMDJdDQo+Pj4NCj4+PiBIZWxsbyBSb3NzLA0KPj4+DQo+Pj4gWW91 IHdyb3RlOg0KPj4+DQo+Pj4+IFRoZXJlIGFyZSBhdCBsZWFzdCB0aHJlZSBxdWVzdGlvbnMgaGVy ZToNCj4+Pg0KPj4+IExldCBtZSB0cnkgdG8gYW5zd2VyIHRoZW0NCj4+Pg0KPj4+PiAgICAgICAg LSBEbyB3ZSB3YW50IG9uZSBzb2x1dGlvbiBmb3IgTVBMUyBPQU0sIG9yIHR3bz8NCj4+Pg0KPj4+ IEkgdGhpbmsgd2Ugd2FudCBvbmUgdG9vbGJveCB3aXRoIGEgc2V0IG9mIHRvb2xzLg0KPj4+IEl0 IG1heSBoYXBwZW4gdGhhdCB0aGVyZSBhcmUgdG9vbHMgdGhhdCBvb2sgYWxpa2UgYnV0IG1heSBi ZSBkaWZmZXJlbnQgaW4NCj4+PiBkZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2VkIGluIGEgZGlm ZmVyZW50IGNvbnRleHQuDQo+Pj4NCj4+Pj4gICAgICAgIC0gT25jZSB3ZSBtYWtlIGEgZGVjaXNp b24sIGRvIHdlIGludGVuZCB0byB3b3JrIHRvIG1ha2UNCj4+Pj4gICAgICAgICAgaXQgaGFwcGVu LCBvciB0byBjb250aW51ZSB0aGUgYXJndW1lbnQgaW5kZWZpbml0ZWx5Pw0KPj4+DQo+Pj4gSSB3 ZSBhZ3JlZSB0aGF0IHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQgY29udGV4dHMgaW4gd2hpY2ggZGVk aWNhdGVkIHRvb2xzDQo+Pj4gZnJvbSB0aGUgdG9vbGJveCBjYW4gYmUgdXNlZCB0aGUgb3Bwb3Np dGlvbiBkaXNhcHBlYXJzLg0KPj4+DQo+Pj4+ICAgICAgICAtIERvIHdlIHdhbnQgc3RhbmRhcmRz IGZvciB0aGUgSUVURiBUQ1AvSVAvTVBMUyBwcm90b2NvbCBzdWl0ZQ0KPj4+PiAgICAgICAgICB0 byBiZSBkb25lIGluIG9uZSBzdGFuZGFyZHMgYm9keSwgb3IgaW5kZXBlbmRlbnRseSBpbiB0d28N Cj4+Pj4gICAgICAgICAgZGlmZmVyZW50IGdyb3VwcyB3aXRoIGluY29tcGF0aWJsZSBzdGFuZGFy ZHMgcmVzdWx0aW5nPw0KPj4+DQo+Pj4gSWYgd2UgYWdyZWUgdGhhdCB0aGVyZSBhcmUgZGlmZmVy ZW50IGNvbnRleHRzLCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8NCj4+PiBoYXZlIHRoZSBjb250 ZXh0IHNlbnNpdGl2ZSB0b29scyBkZXZlbG9wcGVkIGJ5IHRoZSBleHBlcnRzIGluIGEgcGFydGlj dWxhcg0KPj4+IGNvbnRleHQvYXJlYS4NCj4+Pg0KPj4+IEN1cnJlbnRseSBJIGNhbiBpZGVudGlm eSB0d28gY29udGV4dHM6DQo+Pj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRl ZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+Pj4gICAgICAgIHNpbWlsYXIgdG8gZXhpc3Rp bmcgdG9vbHMNCj4+PiAtMi0gcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcywgdGhlIGRlZGljYXRl ZCB0b29scyBzaG91bGQgYmVoYXZlDQo+Pj4gICAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdHJh bnNwb3J0IHRlY2hub2xvZ2llcy4NCj4+Pg0KPj4+IFJlZ2FyZHMsIEh1dWIuDQoNCg0KDQotLSAN CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQogICAgICAgICAgICAgICAgICAgICAgICAgztKwrs3itePSu8bfyP3Suw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCg== From neil.2.harrison@bt.com Wed Jan 19 01:50:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444D83A70E2 for ; Wed, 19 Jan 2011 01:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzhEANSk6xZq for ; Wed, 19 Jan 2011 01:50:24 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 21F1C3A70DE for ; Wed, 19 Jan 2011 01:50:23 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 19 Jan 2011 09:53:03 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.223]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 19 Jan 2011 09:53:02 +0000 From: To: , , Date: Wed, 19 Jan 2011 09:53:00 +0000 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3Ym5aBkLUcS5dR9uZ5lr/wPwRygACDEmgABMC4bA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440114353CE@EMV62-UKRD.domain1.systemhost.net> References: <4D3619B1.1090301@gmail.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 09:50:25 -0000 Eric Osborne wrote 18 January 2011 23:56: > Hi Huub- >=20 > I think the crux of your points is this: >=20 > > Currently I can identify two contexts: > > -1- packet switched networks, the dedicated tools should behave > > similar to existing tools > > -2- packet transport networks, the dedicated tools should behave > > similar to existing transport technologies. >=20 > I doubt we'll ever get everyone to hold hands and agree and=20 > sing happy songs on this point, but let me ask anyways. Why=20 > do we still need different tools for packet switched vs=20 > packet transport networks? The two terms are so similar that=20 > it's not obvious on its face whether these two are actually=20 > any different any more, is it really worth all the hassle=20 > from a technical perspective? And if that's true and was=20 > true all along, why did everyone agree to cooperate in the=20 > first place [JWT agreement], and agree that there should only=20 > be one solution [ref. Russ Housely's brief talk in Beijing]? >=20 Hi Eric, The co-cs mode and co-ps mode are different in many ways...this also plays = through to OAM, eg AIS is a must-have for the co-cs mode but it is an unnec= essary function if included in the co-ps mode. The work on GMPLS also sho= ws that there are important differences...and note we don't have sublayerin= g or PWs here, and the notion of a 'common CP' is largely dead. So we can'= t have identical solutions. If one really wants the co-ps mode to act as a transport network however (w= hich I thought was the main driver for MPLS-TP) then it should have specifi= c architectural behaviours it has to meet (folks can then compromise these = if they so choose, but the technology itself must be capable of delivering = them else it cannot claim to be a transport network). Note - many importan= t customers usually demand transparency of their transport services. A tra= nsport network also should be able to drive an EM wave on metallic/optical/= radio section media..... Transparency is THE major service a transport network must be able to provi= de. I'll spare going over the details of what this means, but here one can= simply note that one of the consequences of this is that a properly design= ed co-ps mode transport network would not have sublayering nor PWs. >From the minimalist defect-handling OAM perspective we need the CV and BDI = messages where the CV message carries a proper source address of the layer = network it is being used in. We do not need AIS nor TCM. One can select C= V and BDI messages from Y.1731 and ignore the ones that are not required. regards, Neil > = From neil.2.harrison@bt.com Wed Jan 19 02:19:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BE53A6E7C for ; Wed, 19 Jan 2011 02:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pZmyYW103GT for ; Wed, 19 Jan 2011 02:19:43 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 6D5563A6FB5 for ; Wed, 19 Jan 2011 02:19:42 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 19 Jan 2011 10:22:16 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.223]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 19 Jan 2011 10:22:21 +0000 From: To: , , Date: Wed, 19 Jan 2011 10:22:24 +0000 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3pr0nWnGAJkoaS32EMgwRas2GVwAAR2rwAAXYPhA= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44011435432@EMV62-UKRD.domain1.systemhost.net> References: <4D3619B1.1090301@gmail.com> <4D368C1B.7080106@gmail.com> <077E41CFFD002C4CAB7DFA4386A532640336B5BC@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A532640336B5BC@DEMUEXC014.nsn-intra.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E44011435432EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 10:19:44 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E44011435432EMV62UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzaGFyZSB5b3VyIGNvbmNlcm5zIE51cml0LiAgT25lIG9mIHRoZSB0aGluZ3MgdGhhdCB3YXMg Y2xlYXIgdG8gbWUgYSBsb25nIHRpbWUgYWdvIHdhcyB0aGUgbWlzZ3VpZGVkIHZpZXcgdGhhdCBt YWtpbmcgdGhlIE9BTSB0aGUgc2FtZSBpbiBNUExTIGFuZCBFdGhlcm5ldCB3b3VsZCBzb21laG93 ICdtYWtlIHRoZW0gdGhlIHNhbWUnIGFuZCBhbGxvdyB0aGVpciBpbnRlcndvcmtpbmcgYXMgcGVl cnMuLi4uLm5vdGhpbmcgY291bGQgYmUgbW9yZSB3cm9uZyEgIE9uZSB3b3VsZCBuZWVkIGZ1bGwg YWxpZ25tZW50IG9mIGFsbCBhc3BlY3RzIG9mIHRoZSBEUCBhbmQgQ1AgdG8gYWNoaWV2ZSB0aGlz Li4uLmluY2x1ZGluZyB0aGUgRFAgbWVzc2FnZS9maWxlL3N0cmVhbSBlbmQtc3lzdGVtIGFwcGxp Y2F0aW9uIGFkYXB0YXRpb24gZnVuY3Rpb25zLi4ud2hpY2ggb2YgY291cnNlIGRvbid0IGV4aXN0 IGFzIG5laXRoZXIgTVBMUyBub3IgRXRoZXJuZXQgaXMgYSBUT1MgbGF5ZXIgbmV0d29yay4gIEFu ZCBpZiBvbmUgcHJvcGVybHkgdW5kZXJzdGFuZHMgYWxsIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhp cyBvYnNlcnZhdGlvbiBpdCB0ZWxscyBvbmUgdGhhdCBwcm92aWRpbmcgTk5JcyBpbiAob3Igd29y c2UgYmV0d2VlbikgdGhlc2UgdGVjaG5vbG9naWVzIGlzIGFuIHVubmVjZXNzYXJ5IGNvc3QuDQoN CnJlZ2FyZHMgTmVpbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog bXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pDQpTZW50OiAx OSBKYW51YXJ5IDIwMTEgMDc6MjYNClRvOiBleHQgSHV1YiB2YW4gSGVsdm9vcnQ7IG1wbHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNv bW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYgMDQzLjAyXQ0KDQoNCkh1dWIsDQoNCllvdSBzYXk6DQoN CiJJZiB5b3UgbG9vayBhdCB0aGUgdGVybXMgdGhleSBsb29rIHNpbWlsYXIsIGJ1dCBwYWNrZXQg dHJhbnNwb3J0IGRpZmZlcnMgZnJvbSBwYWNrZXQgc3dpdGNoaW5nIGluIHRoZSB3YXkgcGFja2V0 cyBhcmUgdHJhbnNwb3J0ZWQuIEluIHBhY2tldCB0cmFuc3BvcnQgdGhlIG9iamVjdGl2ZSBpcyB0 byB0cmFuc3BvcnQgcGFja2V0cyBpbmRlcGVuZGVuZCBvZiB0aGUgdGVjaG5vbG9neSwgc28gaXQg aXMgaW1wb3J0YW50IHRoYXQgdGhlIE9BTSBmb3IgcGFja2V0IHRyYW5zcG9ydCBpcyB0aGUgc2Ft ZSBpbiBhbGwgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4iDQoNCk51cml0OiBEbyB5b3Ugc2F5IHRo YXQgdGhlIGZvcndhcmRpbmcgb2YgTVBMUyBwYWNrZXRzIGlzIGRpZmZlcmVudCBpbiBib3RoIHBy b3Bvc2Fscz8gRG8geW91IHNheSB0aGF0IGluIHRyYW5zcG9ydCBuZXR3b3JrcyB0aGUgZm9yd2Fy ZGluZyBvZiB0aGUgcGFja2V0cyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgTVBMUyBmb3J3YXJkaW5n IG1lY2hhbmlzbXM/IElzIHRoZXJlIGEgbWFnaWMgd2F5IHRvIHRyYW5zbWl0IHRoZSBwYWNrZXRz IHdpdGhvdXQgcmVseWluZyBvbiB0aGUgdGVjaG5vbG9neT8NCg0KQWxzbywgSSBkbyBub3QgdW5k ZXJzdGFuZCB0aGUgbG9naWMgYmV0d2VlbiB0aGUgcmVxdWlyZW1lbnQgeW91IHB1dCAidG8gdHJh bnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlIHRlY2hub2xvZ3kiIGFuZCB0aGUgY29u Y2x1c2lvbiB0aGF0ICJpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJh bnNwb3J0IGlzIHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzIg0KDQpUaGUg cmVxdWlyZW1lbnQgaXMgdG8gaGF2ZSBzaW1pbGFyIGZ1bmN0aW9uYWxpdHkgYW5kIG9wZXJhdGlv bmFsIGV4cGVyaWVuY2UgYXMgaW4gb3RoZXIgdHJhbnNwb3J0IG5ldHdvcmvigKZ0aGlzIGRvZXMg bm90IG1lYW4gdGhhdCBpdCBoYXMgdG8gYmUgaW1wbGVtZW50ZWQgdGhlIHNhbWUgd2F54oCmLm9y IHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIHVzZSB0aGUgc2FtZSBmcmFtZSBmb3JtYXTigKYuc28g cGxlYXNlIHN0b3AgY29uZnVzaW5nIHRoZSBJbmR1c3RyeSEgVGhlIHdheSBpdCBsb29rcyBhbmQg ZmVlbCBkb2VzIG5vdCBkaWN0YXRlIGhvdyBpdCBpcyBpbXBsZW1lbnRlZCBhbmQgd2hpY2ggZnJh bWUgZm9ybWF0cyBhcmUgdXNlZC4NCg0KSW4gTVBMUy1UUCB0aGUgZm9yd2FyZGluZyBpcyBiYXNl ZCBvbiB0aGUgTVBMUyBmb3J3YXJkaW5nIGNvbnN0cnVjdCBhbmQgdGhlIE9BTSBwYWNrZXRzIG1h eSBiZSBzZW50IGluYmFuZCBvdmVyIEctQWNo4oCmLi4NCg0KWW91ciBhcmd1bWVudHMgbWFrZSBt ZSB2ZXJ5IG11Y2ggY29uY2VybmVkIG5vd+KApmFuZCB0aGUgbmVlZCB0byBkZWZpbmUgYSB0ZWNo bm9sb2d5IGluIHRoZSBwbGFjZSB3aGVyZSB0aGUgZGVzaWduIGF1dGhvcml0eSBleGlzdHMgc2Vl bXMgdG8gYmUgc3Ryb25nZXIgdGhhbiBldmVyIQ0KDQpCUiwNCg0KTm51cml0DQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IEh1dWIgdmFuIEhlbHZv b3J0DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTksIDIwMTEgOTowMSBBTQ0KVG86IG1wbHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBS ZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYgMDQzLjAyXQ0KDQoNCg0KSGVsbG8gRXJpYywNCg0K DQoNCllvdSByZXBsaWVkOg0KDQoNCg0KPiAgICBJIHRoaW5rIHRoZSBjcnV4IG9mIHlvdXIgcG9p bnRzIGlzIHRoaXM6DQoNCj4NCg0KPj4gQ3VycmVudGx5IEkgY2FuIGlkZW50aWZ5IHR3byBjb250 ZXh0czoNCg0KPj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0 b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9vbHMN Cg0KPj4gLTItIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMg c2hvdWxkIGJlaGF2ZQ0KDQo+PiAgICAgICBzaW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0 ZWNobm9sb2dpZXMuDQoNCj4NCg0KPiBJIGRvdWJ0IHdlJ2xsIGV2ZXIgZ2V0IGV2ZXJ5b25lIHRv IGhvbGQgaGFuZHMgYW5kIGFncmVlIGFuZCBzaW5nDQoNCj4gaGFwcHkgc29uZ3Mgb24gdGhpcyBw b2ludCwgYnV0IGxldCBtZSBhc2sgYW55d2F5cy4gIFdoeSBkbyB3ZSBzdGlsbA0KDQo+IG5lZWQg ZGlmZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0IHRyYW5zcG9ydCBu ZXR3b3Jrcz8NCg0KPiBUaGUgdHdvIHRlcm1zIGFyZSBzbyBzaW1pbGFyIHRoYXQgaXQncyBub3Qg b2J2aW91cyBvbiBpdHMgZmFjZSB3aGV0aGVyDQoNCj4gdGhlc2UgdHdvIGFyZSBhY3R1YWxseSBh bnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCByZWFsbHkgd29ydGggYWxsDQoNCj4gdGhlIGhh c3NsZSBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlPw0KDQoNCg0KSWYgeW91IGxvb2sgYXQg dGhlIHRlcm1zIHRoZXkgbG9vayBzaW1pbGFyLCBidXQgcGFja2V0IHRyYW5zcG9ydCBkaWZmZXJz DQoNCmZyb20gcGFja2V0IHN3aXRjaGluZyBpbiB0aGUgd2F5IHBhY2tldHMgYXJlIHRyYW5zcG9y dGVkLiBJbiBwYWNrZXQNCg0KdHJhbnNwb3J0IHRoZSBvYmplY3RpdmUgaXMgdG8gdHJhbnNwb3J0 IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlDQoNCnRlY2hub2xvZ3ksIHNvIGl0IGlzIGltcG9y dGFudCB0aGF0IHRoZSBPQU0gZm9yIHBhY2tldCB0cmFuc3BvcnQgaXMNCg0KdGhlIHNhbWUgaW4g YWxsIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQoNCg0KDQo+IEFuZCBpZiB0aGF0J3MgdHJ1ZSBh bmQgd2FzIHRydWUgYWxsIGFsb25nLCB3aHkgZGlkIGV2ZXJ5b25lIGFncmVlDQoNCj4gdG8gY29v cGVyYXRlIGluIHRoZSBmaXJzdCBwbGFjZSBbSldUIGFncmVlbWVudF0sIGFuZCBhZ3JlZSB0aGF0 IHRoZXJlDQoNCj4gc2hvdWxkIG9ubHkgYmUgb25lIHNvbHV0aW9uIFtyZWYuIFJ1c3MgSG91c2Vs eSdzIGJyaWVmIHRhbGsgaW4gQmVpamluZ10/DQoNCg0KDQpKdXN0IG91dCBvZiBjdXJpb3NpdHk6 DQoNCldoZW4gYW5kIHdoZXJlIHdhcyB0aGlzIGFncmVlZD8NCg0KV2hvIHdhcyBwcmVzZW50IHdo ZW4gdGhpcyBhZ3JlZW1lbnQgd2FzIHJlYWNoZWQ/DQoNCg0KDQpSZWdhcmRzLCBIdXViLg0KDQoN Cg0KDQoNCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IG1wbHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m DQoNCj4+IEh1dWIgdmFuIEhlbHZvb3J0DQoNCj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTgs IDIwMTEgNTo1MyBQTQ0KDQo+PiBUbzogbXBsc0BpZXRmLm9yZw0KDQo+PiBTdWJqZWN0OiBSZTog W21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbSBb UmVmDQoNCj4+IDA0My4wMl0NCg0KPj4NCg0KPj4gSGVsbG8gUm9zcywNCg0KPj4NCg0KPj4gWW91 IHdyb3RlOg0KDQo+Pg0KDQo+Pj4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBo ZXJlOg0KDQo+Pg0KDQo+PiBMZXQgbWUgdHJ5IHRvIGFuc3dlciB0aGVtDQoNCj4+DQoNCj4+PiAg ICAgICAtIERvIHdlIHdhbnQgb25lIHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3IgdHdvPw0KDQo+ Pg0KDQo+PiBJIHRoaW5rIHdlIHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4N Cg0KPj4gSXQgbWF5IGhhcHBlbiB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBi dXQgbWF5IGJlIGRpZmZlcmVudCBpbg0KDQo+PiBkZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2Vk IGluIGEgZGlmZmVyZW50IGNvbnRleHQuDQoNCj4+DQoNCj4+PiAgICAgICAtIE9uY2Ugd2UgbWFr ZSBhIGRlY2lzaW9uLCBkbyB3ZSBpbnRlbmQgdG8gd29yayB0byBtYWtlDQoNCj4+PiAgICAgICAg IGl0IGhhcHBlbiwgb3IgdG8gY29udGludWUgdGhlIGFyZ3VtZW50IGluZGVmaW5pdGVseT8NCg0K Pj4NCg0KPj4gSSB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQgY29udGV4dHMg aW4gd2hpY2ggZGVkaWNhdGVkIHRvb2xzDQoNCj4+IGZyb20gdGhlIHRvb2xib3ggY2FuIGJlIHVz ZWQgdGhlIG9wcG9zaXRpb24gZGlzYXBwZWFycy4NCg0KPj4NCg0KPj4+ICAgICAgIC0gRG8gd2Ug d2FudCBzdGFuZGFyZHMgZm9yIHRoZSBJRVRGIFRDUC9JUC9NUExTIHByb3RvY29sIHN1aXRlDQoN Cj4+PiAgICAgICAgIHRvIGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBpbmRlcGVu ZGVudGx5IGluIHR3bw0KDQo+Pj4gICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21w YXRpYmxlIHN0YW5kYXJkcyByZXN1bHRpbmc/DQoNCj4+DQoNCj4+IElmIHdlIGFncmVlIHRoYXQg dGhlcmUgYXJlIGRpZmZlcmVudCBjb250ZXh0cywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvDQoN Cj4+IGhhdmUgdGhlIGNvbnRleHQgc2Vuc2l0aXZlIHRvb2xzIGRldmVsb3BwZWQgYnkgdGhlIGV4 cGVydHMgaW4gYSBwYXJ0aWN1bGFyDQoNCj4+IGNvbnRleHQvYXJlYS4NCg0KPj4NCg0KPj4gQ3Vy cmVudGx5IEkgY2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czoNCg0KPj4gLTEtIHBhY2tldCBzd2l0 Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAg ICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9vbHMNCg0KPj4gLTItIHBhY2tldCB0cmFuc3BvcnQg bmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZQ0KDQo+PiAgICAgICBz aW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQoNCj4+DQoNCj4+IFJl Z2FyZHMsIEh1dWIuDQoNCg0KDQoNCg0KLS0NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICDmiJHniLHlpJbngrnkuIDkuIPkuInkuIANCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbXBscyBtYWlsaW5nIGxpc3QNCg0KbXBs c0BpZXRmLm9yZw0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== --_000_6D3D47CB84BDE349BC23BF1C94E316E44011435432EMV62UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAt NjVCMy0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02 REEzLTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0K InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSAN CiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9 IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVl dCIgeG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4 bWxuczpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24i IHhtbG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpx ID0gDQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0 YyA9IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5T OkQgPSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v cmVwbC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m dC5jb20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5w YXNzcG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6 ZHMgPSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMg PSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSAN CiJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHht bG5zOmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9 IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9 IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6 eHNpID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5z OnVkY3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHht bG5zOnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxm aWxlIiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEv dWRjL3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6 bWRzc2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2 L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3Blbnht bGZvcm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxz ID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxh dGlvbnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC93ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIg eG1sbnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv c29hcC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20v d2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2Ui IA0KWE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+ PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRmLTgiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zNjYwIiBu YW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVT IHZMaW5rPXB1cnBsZSBsaW5rPWJsdWU+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz05OTYwNzU3MDktMTkwMTIwMTE+PEZPTlQgZmFjZT1WZXJkYW5hPkkgDQpzaGFyZSB5b3Vy IGNvbmNlcm5zIE51cml0LiZuYnNwOyBPbmUgb2YgdGhlIHRoaW5ncyB0aGF0IHdhcyBjbGVhciB0 byBtZSBhIGxvbmcgDQp0aW1lIGFnbyB3YXMgdGhlIG1pc2d1aWRlZCB2aWV3IHRoYXQgbWFraW5n IHRoZSBPQU0gdGhlIHNhbWUgaW4gTVBMUyBhbmQgDQpFdGhlcm5ldCB3b3VsZCBzb21laG93ICdt YWtlIHRoZW0gdGhlIHNhbWUnIGFuZCBhbGxvdyB0aGVpciBpbnRlcndvcmtpbmcgYXMgDQpwZWVy cy4uLi4ubm90aGluZyBjb3VsZCBiZSBtb3JlIHdyb25nISZuYnNwOyBPbmUgd291bGQgbmVlZCBm dWxsIGFsaWdubWVudCBvZiANCmFsbCBhc3BlY3RzIG9mIHRoZSBEUCBhbmQgQ1AgdG8gYWNoaWV2 ZSB0aGlzLi4uLmluY2x1ZGluZyB0aGUgRFAgDQptZXNzYWdlL2ZpbGUvc3RyZWFtIGVuZC1zeXN0 ZW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMuLi53aGljaCBvZiANCmNvdXJzZSBk b24ndCBleGlzdCBhcyBuZWl0aGVyIE1QTFMgbm9yIEV0aGVybmV0IGlzIGEgVE9TIGxheWVyIG5l dHdvcmsuJm5ic3A7IA0KQW5kIGlmIG9uZSBwcm9wZXJseSB1bmRlcnN0YW5kcyBhbGwgdGhlIGNv bnNlcXVlbmNlcyBvZiB0aGlzIG9ic2VydmF0aW9uIGl0IA0KdGVsbHMgb25lIHRoYXQgcHJvdmlk aW5nIE5OSXMgaW4gKG9yIHdvcnNlIGJldHdlZW4pIHRoZXNlIHRlY2hub2xvZ2llcyBpcyBhbiAN CnVubmVjZXNzYXJ5IGNvc3QuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTk5NjA3NTcwOS0xOTAxMjAxMT48Rk9OVCANCmZhY2U9VmVyZGFu YT48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9OTk2MDc1NzA5LTE5MDEyMDExPjxGT05UIA0KZmFjZT1WZXJkYW5hPnJlZ2FyZHMg TmVpbDwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxl PSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01l c3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQogIDxIUiB0YWJJbmRl eD0tMT4NCiAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgDQogIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSA8Qj5PbiBCZWhh bGYgT2YgPC9CPlNwcmVjaGVyLCBOdXJpdCAoTlNOIC0gDQogIElML0hvZCBIYVNoYXJvbik8QlI+ PEI+U2VudDo8L0I+IDE5IEphbnVhcnkgMjAxMSAwNzoyNjxCUj48Qj5Ubzo8L0I+IGV4dCBIdXVi IA0KICB2YW4gSGVsdm9vcnQ7IG1wbHNAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBb bXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCANCiAgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9h bSBbUmVmIDA0My4wMl08QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJ ViBjbGFzcz1Xb3JkU2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5IdXViLDxvOnA+ PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+WW91IHNheTo8bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+Iklm IHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IA0KICBsb29rIHNpbWlsYXIsIGJ1dCA8U1BBTiAN CiAgc3R5bGU9IkJBQ0tHUk9VTkQ6IHllbGxvdzsgbXNvLWhpZ2hsaWdodDogeWVsbG93Ij5wYWNr ZXQgdHJhbnNwb3J0IGRpZmZlcnMgDQogIGZyb20gcGFja2V0IHN3aXRjaGluZyBpbiB0aGUgd2F5 IHBhY2tldHMgYXJlIHRyYW5zcG9ydGVkLiBJbiBwYWNrZXQgdHJhbnNwb3J0IA0KICB0aGUgb2Jq ZWN0aXZlIGlzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRoZSB0ZWNobm9s b2d5PC9TUEFOPiwgc28gDQogIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBPQU0gZm9yIHBhY2tl dCB0cmFuc3BvcnQgaXMgdGhlIHNhbWUgaW4gYWxsIHRyYW5zcG9ydCANCiAgdGVjaG5vbG9naWVz LiI8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxVPk51cml0PC9VPjog PEI+PFU+PFNQQU4gc3R5bGU9IkNPTE9SOiByZWQiPkRvIHlvdSBzYXkgDQogIHRoYXQgdGhlIGZv cndhcmRpbmcgb2YgTVBMUyBwYWNrZXRzIGlzIGRpZmZlcmVudCBpbiBib3RoIA0KICBwcm9wb3Nh bHM/PC9TUEFOPjwvVT48L0I+IERvIHlvdSBzYXkgdGhhdCBpbiB0cmFuc3BvcnQgbmV0d29ya3Mg dGhlIGZvcndhcmRpbmcgDQogIG9mIHRoZSBwYWNrZXRzIGlzIGluZGVwZW5kZW50IG9mIHRoZSBN UExTIGZvcndhcmRpbmcgbWVjaGFuaXNtcz8gSXMgdGhlcmUgYSANCiAgbWFnaWMgd2F5IHRvIHRy YW5zbWl0IHRoZSBwYWNrZXRzIHdpdGhvdXQgcmVseWluZyBvbiB0aGUgdGVjaG5vbG9neT8gDQog IDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+QWxzbywgSSBkbyBub3Qg dW5kZXJzdGFuZCB0aGUgbG9naWMgYmV0d2VlbiB0aGUgDQogIHJlcXVpcmVtZW50IHlvdSBwdXQg IjxTUEFOIA0KICBzdHlsZT0iQkFDS0dST1VORDogeWVsbG93OyBtc28taGlnaGxpZ2h0OiB5ZWxs b3ciPnRvIHRyYW5zcG9ydCBwYWNrZXRzIA0KICBpbmRlcGVuZGVuZCBvZiB0aGUgdGVjaG5vbG9n eTwvU1BBTj4iIGFuZCB0aGUgY29uY2x1c2lvbiB0aGF0ICI8U1BBTiANCiAgc3R5bGU9IkJBQ0tH Uk9VTkQ6IHllbGxvdzsgbXNvLWhpZ2hsaWdodDogeWVsbG93Ij5pdCBpcyBpbXBvcnRhbnQgdGhh dCB0aGUgT0FNIA0KICBmb3IgcGFja2V0IHRyYW5zcG9ydCBpcyB0aGUgc2FtZSBpbiBhbGwgdHJh bnNwb3J0IA0KICB0ZWNobm9sb2dpZXM8L1NQQU4+IjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+VGhlIHJlcXVpcmVtZW50IGlzIHRvIGhhdmUgPEI+PFU+PFNQQU4gDQog IHN0eWxlPSJDT0xPUjogcmVkIj5zaW1pbGFyIGZ1bmN0aW9uYWxpdHkgYW5kIG9wZXJhdGlvbmFs IGV4cGVyaWVuY2UgYXMgaW4gDQogIG90aGVyIHRyYW5zcG9ydCBuZXR3b3JrPC9TUEFOPjwvVT48 L0I+4oCmdGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaGFzIHRvIGJlIA0KICBpbXBsZW1lbnRl ZCB0aGUgc2FtZSB3YXnigKYub3IgdGhhdCB0aGVyZSBpcyBhIG5lZWQgdG8gdXNlIHRoZSBzYW1l IGZyYW1lIA0KICBmb3JtYXTigKYuPEI+PFU+PFNQQU4gc3R5bGU9IkNPTE9SOiByZWQiPnNvIHBs ZWFzZSBzdG9wIGNvbmZ1c2luZyB0aGUgSW5kdXN0cnkhIA0KICBUaGUgd2F5IGl0IGxvb2tzIGFu ZCBmZWVsIGRvZXMgbm90IGRpY3RhdGUgaG93IGl0IGlzIGltcGxlbWVudGVkIGFuZCB3aGljaCAN CiAgZnJhbWUgZm9ybWF0cyBhcmUgdXNlZC48L1NQQU4+PC9VPjxvOnA+PC9vOnA+PC9CPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PkluIE1QTFMtVFAgdGhlIGZvcndhcmRpbmcgaXMgYmFz ZWQgb24gdGhlIE1QTFMgDQogIGZvcndhcmRpbmcgY29uc3RydWN0IGFuZCB0aGUgT0FNIHBhY2tl dHMgbWF5IGJlIHNlbnQgaW5iYW5kIG92ZXIgDQogIEctQWNo4oCmLi48bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PllvdXIgYXJndW1lbnRzIG1ha2UgbWUgdmVyeSBtdWNo IGNvbmNlcm5lZCBub3figKZhbmQgdGhlIA0KICBuZWVkIHRvIGRlZmluZSBhIHRlY2hub2xvZ3kg aW4gdGhlIHBsYWNlIHdoZXJlIHRoZSBkZXNpZ24gYXV0aG9yaXR5IGV4aXN0cyANCiAgc2VlbXMg dG8gYmUgc3Ryb25nZXIgdGhhbiBldmVyITxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+QlIsPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5ObnVy aXQ8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08QlI+RnJvbTogDQogIG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBIdXViIHZhbiANCiAgSGVsdm9vcnQ8QlI+U2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDE5LCAyMDExIDk6MDEgQU08QlI+VG86IA0KICBtcGxzQGll dGYub3JnPEJSPlN1YmplY3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBS ZWNvbW1lbmRhdGlvbiANCiAgRy50cG9hbSBbUmVmIDA0My4wMl08bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+SGVsbG8gRXJpYyw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+WW91 IHJlcGxpZWQ6PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmbmJzcDsmbmJzcDsm bmJzcDsgSSB0aGluayB0aGUgY3J1eCBvZiB5b3VyIHBvaW50cyANCiAgaXMgdGhpczo8bzpwPjwv bzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEN1cnJlbnRseSBJIGNhbiBpZGVu dGlmeSB0d28gDQogIGNvbnRleHRzOjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyZndDsgLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRl ZCANCiAgdG9vbHMgc2hvdWxkIGJlaGF2ZTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lt aWxhciB0byANCiAgZXhpc3RpbmcgdG9vbHM8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsmZ3Q7IC0yLSBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzLCB0aGUgZGVk aWNhdGVkIA0KICB0b29scyBzaG91bGQgYmVoYXZlPG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBzaW1pbGFyIHRvIA0KICBleGlzdGluZyB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLjxvOnA+PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBJIGRvdWJ0IHdlJ2xsIGV2ZXIgZ2V0IGV2 ZXJ5b25lIHRvIGhvbGQgaGFuZHMgYW5kIA0KICBhZ3JlZSBhbmQgc2luZzxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBoYXBweSBzb25ncyBvbiB0aGlzIHBvaW50 LCBidXQgbGV0IG1lIGFzayANCiAgYW55d2F5cy4mbmJzcDsgV2h5IGRvIHdlIHN0aWxsPG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG5lZWQgZGlmZmVyZW50IHRv b2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0IA0KICB0cmFuc3BvcnQgbmV0d29ya3M/ PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFRoZSB0d28gdGVy bXMgYXJlIHNvIHNpbWlsYXIgdGhhdCBpdCdzIG5vdCBvYnZpb3VzIA0KICBvbiBpdHMgZmFjZSB3 aGV0aGVyPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHRoZXNl IHR3byBhcmUgYWN0dWFsbHkgYW55IGRpZmZlcmVudCBhbnkgbW9yZSwgaXMgDQogIGl0IHJlYWxs eSB3b3J0aCBhbGw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg dGhlIGhhc3NsZSBmcm9tIGEgdGVjaG5pY2FsIA0KICBwZXJzcGVjdGl2ZT88bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+SWYgeW91IGxvb2sgYXQgdGhlIHRlcm1zIHRoZXkgbG9vayBzaW1p bGFyLCBidXQgcGFja2V0IA0KICB0cmFuc3BvcnQgZGlmZmVyczxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+ZnJvbSBwYWNrZXQgc3dpdGNoaW5nIGluIHRoZSB3YXkgcGFj a2V0cyBhcmUgDQogIHRyYW5zcG9ydGVkLiBJbiBwYWNrZXQ8bzpwPjwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0PnRyYW5zcG9ydCB0aGUgb2JqZWN0aXZlIGlzIHRvIHRyYW5zcG9y dCBwYWNrZXRzIA0KICBpbmRlcGVuZGVuZCBvZiB0aGU8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PnRlY2hub2xvZ3ksIHNvIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBP QU0gZm9yIHBhY2tldCANCiAgdHJhbnNwb3J0IGlzPG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb1BsYWluVGV4dD50aGUgc2FtZSBpbiBhbGwgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy48bzpw PjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBBbmQgaWYgdGhhdCdzIHRydWUgYW5kIHdh cyB0cnVlIGFsbCBhbG9uZywgd2h5IGRpZCANCiAgZXZlcnlvbmUgYWdyZWU8bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgdG8gY29vcGVyYXRlIGluIHRoZSBmaXJz dCBwbGFjZSBbSldUIGFncmVlbWVudF0sIA0KICBhbmQgYWdyZWUgdGhhdCB0aGVyZTxvOnA+PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBzaG91bGQgb25seSBiZSBvbmUg c29sdXRpb24gW3JlZi4gUnVzcyBIb3VzZWx5J3MgDQogIGJyaWVmIHRhbGsgaW4gQmVpamluZ10/ PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0Pkp1c3Qgb3V0IG9mIGN1cmlvc2l0eTo8bzpw PjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PldoZW4gYW5kIHdoZXJlIHdhcyB0 aGlzIGFncmVlZD88bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PldobyB3 YXMgcHJlc2VudCB3aGVuIHRoaXMgYWdyZWVtZW50IHdhcyANCiAgcmVhY2hlZD88bzpwPjwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+UmVnYXJkcywgSHV1Yi48bzpwPjwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIA0K ICBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mPG86cD48L286cD48 L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBIdXViIHZhbiBIZWx2b29ydDxv OnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgU2VudDogVHVl c2RheSwgSmFudWFyeSAxOCwgMjAxMSA1OjUzIA0KICBQTTxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgVG86IG1wbHNAaWV0Zi5vcmc8bzpwPjwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBsc10g UmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCANCiAgUmVjb21tZW5kYXRpb24gRy50cG9hbSBbUmVm PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyAwNDMuMDJd PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgSGVsbG8gUm9z cyw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4m bmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBZb3Ugd3Jv dGU6PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7IFRo ZXJlIGFyZSBhdCBsZWFzdCB0aHJlZSBxdWVzdGlvbnMgDQogIGhlcmU6PG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0K ICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgTGV0IG1lIHRyeSB0byBhbnN3ZXIgdGhl bTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDs8bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIERvIHdlIA0KICB3YW50IG9uZSBzb2x1 dGlvbiBmb3IgTVBMUyBPQU0sIG9yIHR3bz88bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7Jmd0OyBJIHRoaW5rIHdlIHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBv ZiANCiAgdG9vbHMuPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 Jmd0OyBJdCBtYXkgaGFwcGVuIHRoYXQgdGhlcmUgYXJlIHRvb2xzIHRoYXQgb29rIA0KICBhbGlr ZSBidXQgbWF5IGJlIGRpZmZlcmVudCBpbjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyZndDsgZGV0YWlsIGJlY2F1c2UgdGhleSBhcmUgdXNlZCBpbiBhIGRpZmZl cmVudCANCiAgY29udGV4dC48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBPbmNlIA0K ICB3ZSBtYWtlIGEgZGVjaXNpb24sIGRvIHdlIGludGVuZCB0byB3b3JrIHRvIG1ha2U8bzpwPjwv bzpwPjwvUD4NCiAgPFAgDQogIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIGl0IGhhcHBlbiwg b3IgdG8gY29udGludWUgdGhlIGFyZ3VtZW50IGluZGVmaW5pdGVseT88bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L1A+DQog IDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBJIHdlIGFncmVlIHRoYXQgdGhlcmUgY2Fu IGJlIGRpZmZlcmVudCBjb250ZXh0cyANCiAgaW4gd2hpY2ggZGVkaWNhdGVkIHRvb2xzPG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBmcm9tIHRoZSB0b29s Ym94IGNhbiBiZSB1c2VkIHRoZSBvcHBvc2l0aW9uIA0KICBkaXNhcHBlYXJzLjxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwv UD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtIERvIHdlIA0KICB3YW50IHN0YW5kYXJkcyBmb3IgdGhlIElF VEYgVENQL0lQL01QTFMgcHJvdG9jb2wgc3VpdGU8bzpwPjwvbzpwPjwvUD4NCiAgPFAgDQogIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHRvIGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5 LCBvciBpbmRlcGVuZGVudGx5IGluIHR3bzxvOnA+PC9vOnA+PC9QPg0KICA8UCANCiAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgZGlmZmVyZW50IGdyb3VwcyB3aXRoIGluY29tcGF0aWJsZSBz dGFuZGFyZHMgcmVzdWx0aW5nPzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyZndDs8bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsmZ3Q7IElmIHdlIGFncmVlIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCBjb250ZXh0cywg DQogIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0bzxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgaGF2ZSB0aGUgY29udGV4dCBzZW5zaXRpdmUgdG9vbHMgZGV2 ZWxvcHBlZCBieSANCiAgdGhlIGV4cGVydHMgaW4gYSBwYXJ0aWN1bGFyPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBjb250ZXh0L2FyZWEuPG86cD48L286 cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgQ3VycmVudGx5IEkgY2FuIGlk ZW50aWZ5IHR3byANCiAgY29udGV4dHM6PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7Jmd0OyAtMS0gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtzLCB0aGUgZGVkaWNh dGVkIA0KICB0b29scyBzaG91bGQgYmVoYXZlPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz aW1pbGFyIHRvIA0KICBleGlzdGluZyB0b29sczxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgLTItIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MsIHRoZSBk ZWRpY2F0ZWQgDQogIHRvb2xzIHNob3VsZCBiZWhhdmU8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNpbWlsYXIgdG8gDQogIGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuPG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgUmVnYXJkcywgSHV1Yi48 bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD4tLSA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgDQogIGNsYXNzPU1z b1BsYWluVGV4dD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9QPg0KICA8UCANCiAgY2xhc3M9TXNvUGxh aW5UZXh0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPFNQQU4gc3R5 bGU9IkZPTlQtRkFNSUxZOiBTaW1TdW4iPuaIkeeIseWklueCueS4gOS4g+S4ieS4gDwvU1BBTj48 bzpwPjwvbzpwPjwvUD4NCiAgPFAgDQogIGNsYXNzPU1zb1BsYWluVGV4dD5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9QPg0KICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+bXBscyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0Pm1wbHNAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvUD4NCiAgPFAgDQog IGNsYXNzPU1zb1BsYWluVGV4dD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHM8bzpwPjwvbzpwPjwvUD48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --_000_6D3D47CB84BDE349BC23BF1C94E316E44011435432EMV62UKRDdoma_-- From eosborne@cisco.com Wed Jan 19 03:10:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266083A6ECD for ; Wed, 19 Jan 2011 03:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.203 X-Spam-Level: X-Spam-Status: No, score=-10.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJBSGk-JgO0l for ; Wed, 19 Jan 2011 03:10:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C45893A6F22 for ; Wed, 19 Jan 2011 03:10:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIJWNk2tJXG+/2dsb2JhbACED59NaHOmI4pXj2OBJIFUgWR0BIRviVk Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2011 11:13:02 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0JBD1ac024411; Wed, 19 Jan 2011 11:13:02 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 05:13:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 19 Jan 2011 05:12:59 -0600 Message-ID: In-Reply-To: <4D368C1B.7080106@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3psDUsJocgACxSe+MBv73+Fx2QgAIILng References: <4D3619B1.1090301@gmail.com> <4D368C1B.7080106@gmail.com> From: "Eric Osborne (eosborne)" To: "Huub van Helvoort" , X-OriginalArrivalTime: 19 Jan 2011 11:13:01.0603 (UTC) FILETIME=[D5F3DF30:01CBB7C9] Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 11:10:24 -0000 SW5saW5lIHdpdGggRU8jDQoNCi4uLg0KDQo+ID4gSSBkb3VidCB3ZSdsbCBldmVyIGdldCBldmVy eW9uZSB0byBob2xkIGhhbmRzIGFuZCBhZ3JlZSBhbmQgc2luZw0KPiAgPiBoYXBweSBzb25ncyBv biB0aGlzIHBvaW50LCBidXQgbGV0IG1lIGFzayBhbnl3YXlzLiAgV2h5IGRvIHdlIHN0aWxsICA+ DQo+IG5lZWQgZGlmZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0IHRy YW5zcG9ydCBuZXR3b3Jrcz8NCj4gID4gVGhlIHR3byB0ZXJtcyBhcmUgc28gc2ltaWxhciB0aGF0 IGl0J3Mgbm90IG9idmlvdXMgb24gaXRzIGZhY2Ugd2hldGhlcg0KPiA+IHRoZXNlIHR3byBhcmUg YWN0dWFsbHkgYW55IGRpZmZlcmVudCBhbnkgbW9yZSwgaXMgaXQgcmVhbGx5IHdvcnRoIGFsbCAg Pg0KPiB0aGUgaGFzc2xlIGZyb20gYSB0ZWNobmljYWwgcGVyc3BlY3RpdmU/DQo+IA0KPiBJZiB5 b3UgbG9vayBhdCB0aGUgdGVybXMgdGhleSBsb29rIHNpbWlsYXIsIGJ1dCBwYWNrZXQgdHJhbnNw b3J0IGRpZmZlcnMNCj4gZnJvbSBwYWNrZXQgc3dpdGNoaW5nIGluIHRoZSB3YXkgcGFja2V0cyBh cmUgdHJhbnNwb3J0ZWQuIEluIHBhY2tldA0KPiB0cmFuc3BvcnQgdGhlIG9iamVjdGl2ZSBpcyB0 byB0cmFuc3BvcnQgcGFja2V0cyBpbmRlcGVuZGVuZCBvZiB0aGUNCj4gdGVjaG5vbG9neSwgc28g aXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIE9BTSBmb3IgcGFja2V0IHRyYW5zcG9ydCBpcyB0aGUN Cj4gc2FtZSBpbiBhbGwgdHJhbnNwb3J0IHRlY2hub2xvZ2llcy4NCg0KRU8jICBJIGRvbid0IHNl ZSBob3cgeW91IGNvdWxkIHBvc3NpYmx5IGhhdmUgYSBwcm90b2NvbCB0aGF0IHdhcyBpbmRlcGVu ZGVudCBvZiAqYW55KiB0ZWNobm9sb2d5LiAgQW5kIEkgdGhpbmsgd2UndmUgZG9uZSBwcmV0dHkg d2VsbCB3aXRoIHBhY2tldCBuZXR3b3JrcyB3aXRob3V0IGNvbnNpc3RlbnQgT0FNIGJldHdlZW4g SVAvTVBMUyBhbmQgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0LiAgU28gcGVyc29uYWxseSBJIGRv bid0IGFncmVlIHdpdGggeW91ciBjb250ZW50aW9uIHRoYXQgT0FNIG11c3QgYmUgdGhlIHNhbWUu DQoNCkJ1dCBJJ2xsIHN0aXB1bGF0ZSBmb3IgYSBzZWNvbmQgdGhhdCB5b3UncmUgY29ycmVjdCBp biB0aGF0IHRoaXMgdWJpcXVpdHkgb2YgT0FNIGlzIG5vdyBpbXBvcnRhbnQuICAqV2h5KiBpcyBp dCBpbXBvcnRhbnQ/ICBJcyBpdCBvbmx5IGltcG9ydGFudCBmb3IgT0FNPyAgV2hhdCBhYm91dCBz aWduYWxpbmc/ICBQcm90ZWN0aW9uPyAgTWFuYWdlbWVudD8gIEhvdyBtdWNoIGNhbiB0d28gZGlm ZmVyZW50IHRoaW5ncyBzaGFyZSBiZWZvcmUgdGhleSdyZSBubyBsb25nZXIgZGlmZmVyZW50Pw0K DQogDQo+ID4gQW5kIGlmIHRoYXQncyB0cnVlIGFuZCB3YXMgdHJ1ZSBhbGwgYWxvbmcsIHdoeSBk aWQgZXZlcnlvbmUgYWdyZWUNCj4gID4gdG8gY29vcGVyYXRlIGluIHRoZSBmaXJzdCBwbGFjZSBb SldUIGFncmVlbWVudF0sIGFuZCBhZ3JlZSB0aGF0IHRoZXJlDQo+ID4gc2hvdWxkIG9ubHkgYmUg b25lIHNvbHV0aW9uIFtyZWYuIFJ1c3MgSG91c2VseSdzIGJyaWVmIHRhbGsgaW4gQmVpamluZ10/ DQo+IA0KPiBKdXN0IG91dCBvZiBjdXJpb3NpdHk6DQo+IFdoZW4gYW5kIHdoZXJlIHdhcyB0aGlz IGFncmVlZD8NCj4gV2hvIHdhcyBwcmVzZW50IHdoZW4gdGhpcyBhZ3JlZW1lbnQgd2FzIHJlYWNo ZWQ/DQoNCg0KRU8jICBUaGUgbWludXRlcyBhcmUgaGVyZToNCmh0dHA6Ly90b29scy5pZXRmLm9y Zy93Zy9tcGxzL21pbnV0ZXM/aXRlbT1taW51dGVzNzkuaHRtbA0KDQphbmQgaXQncyBiZWVuIGRp c2N1c3NlZCBvbiB0aGlzIGxpc3QgYXMgd2VsbCwgYXMgSSdtIHN1cmUgeW91IGtub3cuICBCdXQg cHV0IHRoYXQgYXNpZGUgLSBpZiB0aGlzIGFncmVlbWVudCB3YXMgbmV2ZXIgcmVhY2hlZCwgc2hv dWxkbid0IHRoZSAidHdvIHRlY2hub2xvZ2llcywgdHdvIHByb3RvY29scyIgYXBwcm9hY2ggaGF2 ZSBiZWVuIHNwZWxsZWQgb3V0IGZyb20gZGF5IG9uZT8gIEkgcmVmZXIgeW91IHRvIHJmYzUzMTcs IHdoaWNoIGNvbnRhaW5zIHBocmFzZXMgbGlrZSAiam9pbnRseSBhZ3JlZSB0byB3b3JrIHRvZ2V0 aGVyIiBhbmQgbm93aGVyZSBjb250YWlucyB0aGUgaWRlYSB0aGF0IHR3byBib2RpZXMgYWdyZWUg dG8gd29yayB0b2dldGhlciB0byBpbnZlbnQgdHdvIHNlcGFyYXRlIGFuZCBpbmNvbXBhdGlibGUg dGhpbmdzLg0KDQoNCg0KZXJpYw0KDQo+IA0KPiBSZWdhcmRzLCBIdXViLg0KPiANCj4gDQo+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4+IE9mIEh1 dWIgdmFuIEhlbHZvb3J0DQo+ID4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTgsIDIwMTEgNTo1 MyBQTQ0KPiA+PiBUbzogbXBsc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIFJl c3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50cG9hbQ0KPiA+PiBbUmVm IDA0My4wMl0NCj4gPj4NCj4gPj4gSGVsbG8gUm9zcywNCj4gPj4NCj4gPj4gWW91IHdyb3RlOg0K PiA+Pg0KPiA+Pj4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0aW9ucyBoZXJlOg0KPiA+ Pg0KPiA+PiBMZXQgbWUgdHJ5IHRvIGFuc3dlciB0aGVtDQo+ID4+DQo+ID4+PiAgICAgICAtIERv IHdlIHdhbnQgb25lIHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3IgdHdvPw0KPiA+Pg0KPiA+PiBJ IHRoaW5rIHdlIHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0b29scy4NCj4gPj4gSXQg bWF5IGhhcHBlbiB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBhbGlrZSBidXQgbWF5IGJl DQo+ID4+IGRpZmZlcmVudCBpbiBkZXRhaWwgYmVjYXVzZSB0aGV5IGFyZSB1c2VkIGluIGEgZGlm ZmVyZW50IGNvbnRleHQuDQo+ID4+DQo+ID4+PiAgICAgICAtIE9uY2Ugd2UgbWFrZSBhIGRlY2lz aW9uLCBkbyB3ZSBpbnRlbmQgdG8gd29yayB0byBtYWtlDQo+ID4+PiAgICAgICAgIGl0IGhhcHBl biwgb3IgdG8gY29udGludWUgdGhlIGFyZ3VtZW50IGluZGVmaW5pdGVseT8NCj4gPj4NCj4gPj4g SSB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQgY29udGV4dHMgaW4gd2hpY2gg ZGVkaWNhdGVkDQo+ID4+IHRvb2xzIGZyb20gdGhlIHRvb2xib3ggY2FuIGJlIHVzZWQgdGhlIG9w cG9zaXRpb24gZGlzYXBwZWFycy4NCj4gPj4NCj4gPj4+ICAgICAgIC0gRG8gd2Ugd2FudCBzdGFu ZGFyZHMgZm9yIHRoZSBJRVRGIFRDUC9JUC9NUExTIHByb3RvY29sIHN1aXRlDQo+ID4+PiAgICAg ICAgIHRvIGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBpbmRlcGVuZGVudGx5IGlu IHR3bw0KPiA+Pj4gICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGggaW5jb21wYXRpYmxlIHN0 YW5kYXJkcyByZXN1bHRpbmc/DQo+ID4+DQo+ID4+IElmIHdlIGFncmVlIHRoYXQgdGhlcmUgYXJl IGRpZmZlcmVudCBjb250ZXh0cywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlDQo+ID4+IHRvIGhhdmUg dGhlIGNvbnRleHQgc2Vuc2l0aXZlIHRvb2xzIGRldmVsb3BwZWQgYnkgdGhlIGV4cGVydHMgaW4g YQ0KPiA+PiBwYXJ0aWN1bGFyIGNvbnRleHQvYXJlYS4NCj4gPj4NCj4gPj4gQ3VycmVudGx5IEkg Y2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czoNCj4gPj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3 b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQo+ID4+ICAgICAgIHNpbWls YXIgdG8gZXhpc3RpbmcgdG9vbHMNCj4gPj4gLTItIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3Ms IHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZQ0KPiA+PiAgICAgICBzaW1pbGFyIHRv IGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQo+ID4+DQo+ID4+IFJlZ2FyZHMsIEh1 dWIuDQo+IA0KPiANCj4gLS0NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICDmiJHniLHlpJbngrnkuIDkuIPkuInkuIANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From Adrian.Farrel@huawei.com Wed Jan 19 06:01:45 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9E93A6F30; Wed, 19 Jan 2011 06:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.541 X-Spam-Level: X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odtP5p87BPYr; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C2B843A712B; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900547WFBZN@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900JX1WF9G9@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Date: Wed, 19 Jan 2011 14:04:20 +0000 From: Adrian Farrel To: mpls@ietf.org, 'CCAMP' , pce@ietf.org Message-id: <070501cbb7e1$c6436020$52ca2060$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu34bm7+lB0frMlTquX736g5RjMjQ== Cc: l2vpn@ietf.org, itu-t-liaisons@iab.org, rtg-bfd@ietf.org, pwe3@ietf.org, opsawg@ietf.org Subject: [mpls] Proposed liaison response on ITU-T Optical transport Network Work Plan X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:01:45 -0000 Hi, We received a liaison "SG15 OTNT standardization work plan" which you can see at https://datatracker.ietf.org/documents/LIAISON/file1054.pdf The document they would like us to review is "Draft Revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 13" visible at https://datatracker.ietf.org/documents/LIAISON/file1055.pdf The liaison is addressed CCAMP, PCE, and MPLS, but it falls to me as liaison on the Optical Control Plane to respond. I am copying this email to BFD, OPSAWG, PWE3, and L2VPN as those WGs are explicitly mentioned in the document. A response is requested by February 1, 2011. Here is a draft of what I plan to send. Please send me any comments by January 28. Thanks, Adrian === The IETF thanks you for your liaison COM15-LS204-E received on 2010-06-24 titled "SG15 OTNT standardization work plan", and thanks you for sharing your plans. We have reviewed the document and have a number of comments. In general, it is becoming less and less clear that the title of this document is accurate! SG15 now embraces a number of non-optical transport technologies including Ethernet and MPLS-TP. Although those packet-based technologies can be transmitted over optical links, they are not limited to that medium. Maybe your document should be titled "Transport Networks & Technologies Standardization Work Plan" or maybe you should remove the non-optical material. The scope text in Section 5 and 5.1 might also need revision. The IETF has not position of this, but simply draws the matter to your attention. Table 5-1 We would like to suggest the inclusion of the MPLS Working Group in this table as that working group is responsible for many elements of the support of Ethernet "carrier-class" pseudowires over MPLS and MPLS-TP networks. Section 5.6.1 begins: "MPLS OAM was originally standardized by ITU-T SG13 (Q.5/13)." Although the section goes on to list IETF standardization of MPLS OAM, it may be considered that this first sentence implies that the ITU-T developed MPLS OAM before any MPLS OAM had been developed within the IETF. This would, of course, be a misrepresentation. Therefore, we suggest that you change this first sentence to read: "Within the ITU-T, MPLS OAM was originally standardized by SG13 (Q.5/13)." Table 5-3 Architectural Aspects of MPLS-TP Add RFC 5921, RFC 5950, RFC 5960 Equipment Functional Characteristics of MPLS-TP Add RFC 5960 OAM and Protection Switching of MPLS-TP Add RFC 5860 Management Aspects of MPLS Add RFC 4221 Management Aspects of MPLS-TP Add RFC 5950, RFC 5951 Performance of ATM Add RFC 3116 Performance of MPLS Add RFC 5695 Table 7-1-2 draft-ietf-mpls-tp-framework is now RFC 5921 draft-ietf-mpls-tp-nm-req is now RFC 5951 draft-ietf-mpls-tp-survive-fwk reached revision -06 and has been approved for publication as an RFC draft-ietf-mpls-tp-oam-framework reached revision -10 and has been approved for publication as an RFC draft-ietf-mpls-tp-nm-framework is now RFC 5950 draft-ietf-mpls-tp-rosetta-stone has reached revision -03 draft-ietf-mpls-tp-data-plane is now RFC 5960 draft-ietf-mpls-tp-identifiers has reached revision -03 draft-ietf-mpls-tp-ach-tlv is now abandoned draft-ietf-ccamp-mpls-tp-cp-framework has reached revision -05 Further relevant Internet-Drafts and RFCs can be found at: http://datatracker.ietf.org/wg/ccamp/ http://datatracker.ietf.org/wg/mpls http://datatracker.ietf.org/wg/pwe3 http://datatracker.ietf.org/wg/bfd http://datatracker.ietf.org/wg/pce Table 7-4-2 draft-ietf-gmpls-ason-routing-ospf is now RFC 5787 Table 7-8 should inherit changes to Table 7-1-2 and be updated according to the document status available at the IETF working group pages as listed above. Table 8-1 entry 3. Please be aware of the work on impairment-aware routing in the CCAMP and PCE working groups. (It may be your intention that this is covered under entry 5.) Annex A might usefully refer readers to RFC 4397 and draft-ietf-mpls-tp-rosetta-stone that provide terminology mapping and have been jointly developed by IETF and ITU-T experts. We would welcome it if you shared any future revisions of this work plan with us. Adrian Farrel IETF Liaison to the IETF on the Optical Control Plane Routing Area Director From lufang@cisco.com Wed Jan 19 06:59:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC743A714F; Wed, 19 Jan 2011 06:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMGE+g8pmweU; Wed, 19 Jan 2011 06:59:53 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 467733A7149; Wed, 19 Jan 2011 06:59:52 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAC6MNk2tJXG8/2dsb2JhbACCQKIHc6VnmjKFUASEb4lZ Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2011 15:02:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p0JF2VK7016974; Wed, 19 Jan 2011 15:02:31 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 09:02:31 -0600 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_01CBB7E9.E57B5E7A" Date: Wed, 19 Jan 2011 09:02:29 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25042A8FA5@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS-TP Security Framework Thread-Index: Acu36eRrzBaDX509RzGnFxOXVsTeLw== From: "Luyuan Fang (lufang)" To: "George Swallow (swallow)" , "Loa Andersson" , "Ross Callon" X-OriginalArrivalTime: 19 Jan 2011 15:02:31.0701 (UTC) FILETIME=[E5921450:01CBB7E9] Cc: mpls@ietf.org, CCAMP Subject: [mpls] MPLS-TP Security Framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:59:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB7E9.E57B5E7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, Loa, and Ross,=20 =20 In Beijing IETF 79, we presented draft-fang-mpls-tp-security-framework-04, and mentioned that we planned to request for the draft to be adopted as WG document after the meeting. The authors like to thank to everyone who provided helpful comments and the general feedback on the needs of the this work. =20 The authors would like to request MPLS WG to adopt this draft as WG document. =20 Thanks, Luyuan ------_=_NextPart_001_01CBB7E9.E57B5E7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi George, Loa, and Ross,

 

In Beijing IETF 79, we presented draft-fang-mpls-tp-security-framework-04, and mentioned that we = planned to request for the draft to be adopted as WG document after the = meeting.

The authors like to = thank to everyone who provided helpful comments and the general feedback on the = needs of the this work.

 

The authors would = like to request MPLS WG to adopt this draft as WG = document.

 

Thanks,

Luyuan=

------_=_NextPart_001_01CBB7E9.E57B5E7A-- From david.i.allan@ericsson.com Wed Jan 19 07:02:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2043A7158 for ; Wed, 19 Jan 2011 07:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=-2.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1beP01azHR8Y for ; Wed, 19 Jan 2011 07:02:53 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 4379B3A7154 for ; Wed, 19 Jan 2011 07:02:53 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0JFidV1011310; Wed, 19 Jan 2011 09:44:41 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 19 Jan 2011 10:05:25 -0500 From: David Allan I To: "neil.2.harrison@bt.com" , "nurit.sprecher@nsn.com" , "huubatwork@gmail.com" , "mpls@ietf.org" Date: Wed, 19 Jan 2011 10:05:23 -0500 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3pr0nWnGAJkoaS32EMgwRas2GVwAAR2rwAAXYPhAACmkvUA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD51CDD10C42@EUSAACMS0703.eamcs.ericsson.se> References: <4D3619B1.1090301@gmail.com> <4D368C1B.7080106@gmail.com> <077E41CFFD002C4CAB7DFA4386A532640336B5BC@DEMUEXC014.nsn-intra.net> <6D3D47CB84BDE349BC23BF1C94E316E44011435432@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E44011435432@EMV62-UKRD.domain1.systemhost.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_60C093A41B5E45409A19D42CF7786DFD51CDD10C42EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:02:55 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD51CDD10C42EUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmVpbDoNCg0KWW91IGhhdmUgd2lsZCBhZ3JlZW1lbnQgZnJvbSB0aGlzIGVuZC4NCg0KVGhl IERQIGhpZXJhcmNoaWNhbCBtb2RlbHMgYXJlIHN1ZmZpY2llbnRseSBkaWZmZXJlbnQgdG8gc3Vn Z2VzdCB0aGF0IHRoZSBvbmx5ICJwcmFjdGljYWwiIGludGVyd29ya2luZyBtb2RlbCBpcyBvdmVy bGF5LiBTb210aGluZyB0aGF0IHdvcmtzIGZpbmUgdG9kYXkuIEEgcGVlciBpbnRlcndvcmtpbmcg c2NlbmFyaW8gd291bGQgYmUgYSBob3JyaWJsZSBtaXN0YWtlIHRvIGFjdHVhbGx5IGFzcGlyZSB0 byENCg0KbXkgMiBjZW50cw0KQlINCkRhdmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIG5laWwuMi5oYXJyaXNvbkBidC5jb20NClNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAxOSwgMjAxMSAyOjIyIEFNDQpUbzogbnVyaXQuc3ByZWNoZXJAbnNuLmNv bTsgaHV1YmF0d29ya0BnbWFpbC5jb207IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBs c10gUmVzcG9uc2UgdG8gVXBkYXRlZCBkcmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYg MDQzLjAyXQ0KDQpJIHNoYXJlIHlvdXIgY29uY2VybnMgTnVyaXQuICBPbmUgb2YgdGhlIHRoaW5n cyB0aGF0IHdhcyBjbGVhciB0byBtZSBhIGxvbmcgdGltZSBhZ28gd2FzIHRoZSBtaXNndWlkZWQg dmlldyB0aGF0IG1ha2luZyB0aGUgT0FNIHRoZSBzYW1lIGluIE1QTFMgYW5kIEV0aGVybmV0IHdv dWxkIHNvbWVob3cgJ21ha2UgdGhlbSB0aGUgc2FtZScgYW5kIGFsbG93IHRoZWlyIGludGVyd29y a2luZyBhcyBwZWVycy4uLi4ubm90aGluZyBjb3VsZCBiZSBtb3JlIHdyb25nISAgT25lIHdvdWxk IG5lZWQgZnVsbCBhbGlnbm1lbnQgb2YgYWxsIGFzcGVjdHMgb2YgdGhlIERQIGFuZCBDUCB0byBh Y2hpZXZlIHRoaXMuLi4uaW5jbHVkaW5nIHRoZSBEUCBtZXNzYWdlL2ZpbGUvc3RyZWFtIGVuZC1z eXN0ZW0gYXBwbGljYXRpb24gYWRhcHRhdGlvbiBmdW5jdGlvbnMuLi53aGljaCBvZiBjb3Vyc2Ug ZG9uJ3QgZXhpc3QgYXMgbmVpdGhlciBNUExTIG5vciBFdGhlcm5ldCBpcyBhIFRPUyBsYXllciBu ZXR3b3JrLiAgQW5kIGlmIG9uZSBwcm9wZXJseSB1bmRlcnN0YW5kcyBhbGwgdGhlIGNvbnNlcXVl bmNlcyBvZiB0aGlzIG9ic2VydmF0aW9uIGl0IHRlbGxzIG9uZSB0aGF0IHByb3ZpZGluZyBOTklz IGluIChvciB3b3JzZSBiZXR3ZWVuKSB0aGVzZSB0ZWNobm9sb2dpZXMgaXMgYW4gdW5uZWNlc3Nh cnkgY29zdC4NCg0KcmVnYXJkcyBOZWlsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJv bikNClNlbnQ6IDE5IEphbnVhcnkgMjAxMSAwNzoyNg0KVG86IGV4dCBIdXViIHZhbiBIZWx2b29y dDsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBSZXNwb25zZSB0byBVcGRhdGVk IGRyYWZ0IFJlY29tbWVuZGF0aW9uIEcudHBvYW0gW1JlZiAwNDMuMDJdDQoNCg0KSHV1YiwNCg0K WW91IHNheToNCg0KIklmIHlvdSBsb29rIGF0IHRoZSB0ZXJtcyB0aGV5IGxvb2sgc2ltaWxhciwg YnV0IHBhY2tldCB0cmFuc3BvcnQgZGlmZmVycyBmcm9tIHBhY2tldCBzd2l0Y2hpbmcgaW4gdGhl IHdheSBwYWNrZXRzIGFyZSB0cmFuc3BvcnRlZC4gSW4gcGFja2V0IHRyYW5zcG9ydCB0aGUgb2Jq ZWN0aXZlIGlzIHRvIHRyYW5zcG9ydCBwYWNrZXRzIGluZGVwZW5kZW5kIG9mIHRoZSB0ZWNobm9s b2d5LCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0 IGlzIHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLiINCg0KTnVyaXQ6IERv IHlvdSBzYXkgdGhhdCB0aGUgZm9yd2FyZGluZyBvZiBNUExTIHBhY2tldHMgaXMgZGlmZmVyZW50 IGluIGJvdGggcHJvcG9zYWxzPyBEbyB5b3Ugc2F5IHRoYXQgaW4gdHJhbnNwb3J0IG5ldHdvcmtz IHRoZSBmb3J3YXJkaW5nIG9mIHRoZSBwYWNrZXRzIGlzIGluZGVwZW5kZW50IG9mIHRoZSBNUExT IGZvcndhcmRpbmcgbWVjaGFuaXNtcz8gSXMgdGhlcmUgYSBtYWdpYyB3YXkgdG8gdHJhbnNtaXQg dGhlIHBhY2tldHMgd2l0aG91dCByZWx5aW5nIG9uIHRoZSB0ZWNobm9sb2d5Pw0KDQpBbHNvLCBJ IGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBsb2dpYyBiZXR3ZWVuIHRoZSByZXF1aXJlbWVudCB5b3Ug cHV0ICJ0byB0cmFuc3BvcnQgcGFja2V0cyBpbmRlcGVuZGVuZCBvZiB0aGUgdGVjaG5vbG9neSIg YW5kIHRoZSBjb25jbHVzaW9uIHRoYXQgIml0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBPQU0gZm9y IHBhY2tldCB0cmFuc3BvcnQgaXMgdGhlIHNhbWUgaW4gYWxsIHRyYW5zcG9ydCB0ZWNobm9sb2dp ZXMiDQoNClRoZSByZXF1aXJlbWVudCBpcyB0byBoYXZlIHNpbWlsYXIgZnVuY3Rpb25hbGl0eSBh bmQgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBhcyBpbiBvdGhlciB0cmFuc3BvcnQgbmV0d29ya6Gt dGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaGFzIHRvIGJlIGltcGxlbWVudGVkIHRoZSBzYW1l IHdheaGtLm9yIHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIHVzZSB0aGUgc2FtZSBmcmFtZSBmb3Jt YXShrS5zbyBwbGVhc2Ugc3RvcCBjb25mdXNpbmcgdGhlIEluZHVzdHJ5ISBUaGUgd2F5IGl0IGxv b2tzIGFuZCBmZWVsIGRvZXMgbm90IGRpY3RhdGUgaG93IGl0IGlzIGltcGxlbWVudGVkIGFuZCB3 aGljaCBmcmFtZSBmb3JtYXRzIGFyZSB1c2VkLg0KDQpJbiBNUExTLVRQIHRoZSBmb3J3YXJkaW5n IGlzIGJhc2VkIG9uIHRoZSBNUExTIGZvcndhcmRpbmcgY29uc3RydWN0IGFuZCB0aGUgT0FNIHBh Y2tldHMgbWF5IGJlIHNlbnQgaW5iYW5kIG92ZXIgRy1BY2ihrS4uDQoNCllvdXIgYXJndW1lbnRz IG1ha2UgbWUgdmVyeSBtdWNoIGNvbmNlcm5lZCBub3ehrWFuZCB0aGUgbmVlZCB0byBkZWZpbmUg YSB0ZWNobm9sb2d5IGluIHRoZSBwbGFjZSB3aGVyZSB0aGUgZGVzaWduIGF1dGhvcml0eSBleGlz dHMgc2VlbXMgdG8gYmUgc3Ryb25nZXIgdGhhbiBldmVyIQ0KDQpCUiwNCg0KTm51cml0DQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IEh1dWIgdmFu IEhlbHZvb3J0DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTksIDIwMTEgOTowMSBBTQ0KVG86 IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gUmVzcG9uc2UgdG8gVXBkYXRlZCBk cmFmdCBSZWNvbW1lbmRhdGlvbiBHLnRwb2FtIFtSZWYgMDQzLjAyXQ0KDQoNCg0KSGVsbG8gRXJp YywNCg0KDQoNCllvdSByZXBsaWVkOg0KDQoNCg0KPiAgICBJIHRoaW5rIHRoZSBjcnV4IG9mIHlv dXIgcG9pbnRzIGlzIHRoaXM6DQoNCj4NCg0KPj4gQ3VycmVudGx5IEkgY2FuIGlkZW50aWZ5IHR3 byBjb250ZXh0czoNCg0KPj4gLTEtIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGlj YXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoNCj4+ICAgICAgIHNpbWlsYXIgdG8gZXhpc3Rpbmcg dG9vbHMNCg0KPj4gLTItIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQg dG9vbHMgc2hvdWxkIGJlaGF2ZQ0KDQo+PiAgICAgICBzaW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5z cG9ydCB0ZWNobm9sb2dpZXMuDQoNCj4NCg0KPiBJIGRvdWJ0IHdlJ2xsIGV2ZXIgZ2V0IGV2ZXJ5 b25lIHRvIGhvbGQgaGFuZHMgYW5kIGFncmVlIGFuZCBzaW5nDQoNCj4gaGFwcHkgc29uZ3Mgb24g dGhpcyBwb2ludCwgYnV0IGxldCBtZSBhc2sgYW55d2F5cy4gIFdoeSBkbyB3ZSBzdGlsbA0KDQo+ IG5lZWQgZGlmZmVyZW50IHRvb2xzIGZvciBwYWNrZXQgc3dpdGNoZWQgdnMgcGFja2V0IHRyYW5z cG9ydCBuZXR3b3Jrcz8NCg0KPiBUaGUgdHdvIHRlcm1zIGFyZSBzbyBzaW1pbGFyIHRoYXQgaXQn cyBub3Qgb2J2aW91cyBvbiBpdHMgZmFjZSB3aGV0aGVyDQoNCj4gdGhlc2UgdHdvIGFyZSBhY3R1 YWxseSBhbnkgZGlmZmVyZW50IGFueSBtb3JlLCBpcyBpdCByZWFsbHkgd29ydGggYWxsDQoNCj4g dGhlIGhhc3NsZSBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlPw0KDQoNCg0KSWYgeW91IGxv b2sgYXQgdGhlIHRlcm1zIHRoZXkgbG9vayBzaW1pbGFyLCBidXQgcGFja2V0IHRyYW5zcG9ydCBk aWZmZXJzDQoNCmZyb20gcGFja2V0IHN3aXRjaGluZyBpbiB0aGUgd2F5IHBhY2tldHMgYXJlIHRy YW5zcG9ydGVkLiBJbiBwYWNrZXQNCg0KdHJhbnNwb3J0IHRoZSBvYmplY3RpdmUgaXMgdG8gdHJh bnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlDQoNCnRlY2hub2xvZ3ksIHNvIGl0IGlz IGltcG9ydGFudCB0aGF0IHRoZSBPQU0gZm9yIHBhY2tldCB0cmFuc3BvcnQgaXMNCg0KdGhlIHNh bWUgaW4gYWxsIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQoNCg0KDQo+IEFuZCBpZiB0aGF0J3Mg dHJ1ZSBhbmQgd2FzIHRydWUgYWxsIGFsb25nLCB3aHkgZGlkIGV2ZXJ5b25lIGFncmVlDQoNCj4g dG8gY29vcGVyYXRlIGluIHRoZSBmaXJzdCBwbGFjZSBbSldUIGFncmVlbWVudF0sIGFuZCBhZ3Jl ZSB0aGF0IHRoZXJlDQoNCj4gc2hvdWxkIG9ubHkgYmUgb25lIHNvbHV0aW9uIFtyZWYuIFJ1c3Mg SG91c2VseSdzIGJyaWVmIHRhbGsgaW4gQmVpamluZ10/DQoNCg0KDQpKdXN0IG91dCBvZiBjdXJp b3NpdHk6DQoNCldoZW4gYW5kIHdoZXJlIHdhcyB0aGlzIGFncmVlZD8NCg0KV2hvIHdhcyBwcmVz ZW50IHdoZW4gdGhpcyBhZ3JlZW1lbnQgd2FzIHJlYWNoZWQ/DQoNCg0KDQpSZWdhcmRzLCBIdXVi Lg0KDQoNCg0KDQoNCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQoNCj4+IEh1dWIgdmFuIEhlbHZvb3J0DQoNCj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgMTgsIDIwMTEgNTo1MyBQTQ0KDQo+PiBUbzogbXBsc0BpZXRmLm9yZw0KDQo+PiBTdWJqZWN0 OiBSZTogW21wbHNdIFJlc3BvbnNlIHRvIFVwZGF0ZWQgZHJhZnQgUmVjb21tZW5kYXRpb24gRy50 cG9hbSBbUmVmDQoNCj4+IDA0My4wMl0NCg0KPj4NCg0KPj4gSGVsbG8gUm9zcywNCg0KPj4NCg0K Pj4gWW91IHdyb3RlOg0KDQo+Pg0KDQo+Pj4gVGhlcmUgYXJlIGF0IGxlYXN0IHRocmVlIHF1ZXN0 aW9ucyBoZXJlOg0KDQo+Pg0KDQo+PiBMZXQgbWUgdHJ5IHRvIGFuc3dlciB0aGVtDQoNCj4+DQoN Cj4+PiAgICAgICAtIERvIHdlIHdhbnQgb25lIHNvbHV0aW9uIGZvciBNUExTIE9BTSwgb3IgdHdv Pw0KDQo+Pg0KDQo+PiBJIHRoaW5rIHdlIHdhbnQgb25lIHRvb2xib3ggd2l0aCBhIHNldCBvZiB0 b29scy4NCg0KPj4gSXQgbWF5IGhhcHBlbiB0aGF0IHRoZXJlIGFyZSB0b29scyB0aGF0IG9vayBh bGlrZSBidXQgbWF5IGJlIGRpZmZlcmVudCBpbg0KDQo+PiBkZXRhaWwgYmVjYXVzZSB0aGV5IGFy ZSB1c2VkIGluIGEgZGlmZmVyZW50IGNvbnRleHQuDQoNCj4+DQoNCj4+PiAgICAgICAtIE9uY2Ug d2UgbWFrZSBhIGRlY2lzaW9uLCBkbyB3ZSBpbnRlbmQgdG8gd29yayB0byBtYWtlDQoNCj4+PiAg ICAgICAgIGl0IGhhcHBlbiwgb3IgdG8gY29udGludWUgdGhlIGFyZ3VtZW50IGluZGVmaW5pdGVs eT8NCg0KPj4NCg0KPj4gSSB3ZSBhZ3JlZSB0aGF0IHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQgY29u dGV4dHMgaW4gd2hpY2ggZGVkaWNhdGVkIHRvb2xzDQoNCj4+IGZyb20gdGhlIHRvb2xib3ggY2Fu IGJlIHVzZWQgdGhlIG9wcG9zaXRpb24gZGlzYXBwZWFycy4NCg0KPj4NCg0KPj4+ICAgICAgIC0g RG8gd2Ugd2FudCBzdGFuZGFyZHMgZm9yIHRoZSBJRVRGIFRDUC9JUC9NUExTIHByb3RvY29sIHN1 aXRlDQoNCj4+PiAgICAgICAgIHRvIGJlIGRvbmUgaW4gb25lIHN0YW5kYXJkcyBib2R5LCBvciBp bmRlcGVuZGVudGx5IGluIHR3bw0KDQo+Pj4gICAgICAgICBkaWZmZXJlbnQgZ3JvdXBzIHdpdGgg aW5jb21wYXRpYmxlIHN0YW5kYXJkcyByZXN1bHRpbmc/DQoNCj4+DQoNCj4+IElmIHdlIGFncmVl IHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCBjb250ZXh0cywgaXQgc2hvdWxkIGJlIHBvc3NpYmxl IHRvDQoNCj4+IGhhdmUgdGhlIGNvbnRleHQgc2Vuc2l0aXZlIHRvb2xzIGRldmVsb3BwZWQgYnkg dGhlIGV4cGVydHMgaW4gYSBwYXJ0aWN1bGFyDQoNCj4+IGNvbnRleHQvYXJlYS4NCg0KPj4NCg0K Pj4gQ3VycmVudGx5IEkgY2FuIGlkZW50aWZ5IHR3byBjb250ZXh0czoNCg0KPj4gLTEtIHBhY2tl dCBzd2l0Y2hlZCBuZXR3b3JrcywgdGhlIGRlZGljYXRlZCB0b29scyBzaG91bGQgYmVoYXZlDQoN Cj4+ICAgICAgIHNpbWlsYXIgdG8gZXhpc3RpbmcgdG9vbHMNCg0KPj4gLTItIHBhY2tldCB0cmFu c3BvcnQgbmV0d29ya3MsIHRoZSBkZWRpY2F0ZWQgdG9vbHMgc2hvdWxkIGJlaGF2ZQ0KDQo+PiAg ICAgICBzaW1pbGFyIHRvIGV4aXN0aW5nIHRyYW5zcG9ydCB0ZWNobm9sb2dpZXMuDQoNCj4+DQoN Cj4+IFJlZ2FyZHMsIEh1dWIuDQoNCg0KDQoNCg0KLS0NCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICDO0rCuzeK149K7xt/I/dK7DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm1wbHMgbWFpbGluZyBsaXN0DQoNCm1wbHNA aWV0Zi5vcmcNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_60C093A41B5E45409A19D42CF7786DFD51CDD10C42EUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Neil:
 
You have wild agreement from this end.
 
The DP hierarchical models are sufficiently differ= ent to=20 suggest that the only "practical" interworking model is overlay. Somthing t= hat=20 works fine today. A peer interworking scenario would be a horrible mistake = to=20 actually aspire to!
 
my 2 cents
BR
Dave

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of=20 neil.2.harrison@bt.com
Sent: Wednesday, January 19, 2011 2:22= =20 AM
To: nurit.sprecher@nsn.com; huubatwork@gmail.com;=20 mpls@ietf.org
Subject: Re: [mpls] Response to Updated draft=20 Recommendation G.tpoam [Ref 043.02]

I=20 share your concerns Nurit.  One of the things that was clear to me a l= ong=20 time ago was the misguided view that making the OAM the same in MPLS and=20 Ethernet would somehow 'make them the same' and allow their interworking as= =20 peers.....nothing could be more wrong!  One would need full alignment = of=20 all aspects of the DP and CP to achieve this....including the DP=20 message/file/stream end-system application adaptation functions...which of= =20 course don't exist as neither MPLS nor Ethernet is a TOS layer network.&nbs= p;=20 And if one properly understands all the consequences of this observation it= =20 tells one that providing NNIs in (or worse between) these technologies is a= n=20 unnecessary cost.
 
regards Neil

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN -= =20 IL/Hod HaSharon)
Sent: 19 January 2011 07:26
To: ext = Huub=20 van Helvoort; mpls@ietf.org
Subject: Re: [mpls] Response to Upd= ated=20 draft Recommendation G.tpoam [Ref 043.02]

Huub,

You say:

"If you look at the t= erms they=20 look similar, but packet transport diff= ers=20 from packet switching in the way packets are transported. In packet trans= port=20 the objective is to transport packets independend of the technology, so=20 it is important that the OAM for packet transport is the same in all tran= sport=20 technologies."

Nurit: Do= you say=20 that the forwarding of MPLS packets is different in both=20 proposals? Do you say that in transport networks the forwa= rding=20 of the packets is independent of the MPLS forwarding mechanisms? Is there= a=20 magic way to transmit the packets without relying on the technology?=20

Also, I do not understand the logic between the=20 requirement you put "to transport packets= =20 independend of the technology" and the conclusion that "it is important that = the OAM=20 for packet transport is the same in all transport=20 technologies"

The requirement is to have similar functionality and operational experience as = in=20 other transport network=A1=ADthis does not mean that it ha= s to be=20 implemented the same way=A1=AD.or that there is a need to use the same fr= ame=20 format=A1=AD.so please stop confusing th= e Industry!=20 The way it looks and feel does not dictate how it is implemented and whic= h=20 frame formats are used.

In MPLS-TP the forwarding is based on the MPLS=20 forwarding construct and the OAM packets may be sent inband over=20 G-Ach=A1=AD..

Your arguments make me very much concerned now=A1= =ADand the=20 need to define a technology in the place where the design authority exist= s=20 seems to be stronger than ever!

BR,

Nnurit

 

-----Original Message-----
From:=20 mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Huu= b van=20 Helvoort
Sent: Wednesday, January 19, 2011 9:01 AM
To:=20 mpls@ietf.org
Subject: Re: [mpls] Response to Updated draft Recommenda= tion=20 G.tpoam [Ref 043.02]

 

Hello Eric,

 

You replied:

 

>    I think the crux of your p= oints=20 is this:

> 

>> Currently I can identify two=20 contexts:

>> -1- packet switched networks, the dedica= ted=20 tools should behave

>>       simi= lar to=20 existing tools

>> -2- packet transport networks, the dedic= ated=20 tools should behave

>>       simi= lar to=20 existing transport technologies.

> 

> I doubt we'll ever get everyone to hold hand= s and=20 agree and sing

> happy songs on this point, but let me ask=20 anyways.  Why do we still

> need different tools for packet switched vs = packet=20 transport networks?

> The two terms are so similar that it's not o= bvious=20 on its face whether

> these two are actually any different any mor= e, is=20 it really worth all

> the hassle from a technical=20 perspective?

 

If you look at the terms they look similar, but p= acket=20 transport differs

from packet switching in the way packets are=20 transported. In packet

transport the objective is to transport packets=20 independend of the

technology, so it is important that the OAM for p= acket=20 transport is

the same in all transport technologies.

 

> And if that's true and was true all along, w= hy did=20 everyone agree

> to cooperate in the first place [JWT agreeme= nt],=20 and agree that there

> should only be one solution [ref. Russ House= ly's=20 brief talk in Beijing]?

 

Just out of curiosity:

When and where was this agreed?

Who was present when this agreement was=20 reached?

 

Regards, Huub.

 

 

>> -----Original Message-----

>> From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of

>> Huub van Helvoort

>> Sent: Tuesday, January 18, 2011 5:53=20 PM

>> To: mpls@ietf.org

>> Subject: Re: [mpls] Response to Updated = draft=20 Recommendation G.tpoam [Ref

>> 043.02]

>> 

>> Hello Ross,

>> 

>> You wrote:

>> 

>>> There are at least three questions=20 here:

>> 

>> Let me try to answer them

>> 

>>>       = - Do we=20 want one solution for MPLS OAM, or two?

>> 

>> I think we want one toolbox with a set o= f=20 tools.

>> It may happen that there are tools that = ook=20 alike but may be different in

>> detail because they are used in a differ= ent=20 context.

>> 

>>>       = - Once=20 we make a decision, do we intend to work to make

>>>      &nbs= p; =20 it happen, or to continue the argument indefinitely?

>> 

>> I we agree that there can be different c= ontexts=20 in which dedicated tools

>> from the toolbox can be used the opposit= ion=20 disappears.

>> 

>>>       = - Do we=20 want standards for the IETF TCP/IP/MPLS protocol suite

>>>      &nbs= p; =20 to be done in one standards body, or independently in two

>>>      &nbs= p; =20 different groups with incompatible standards resulting?

>> 

>> If we agree that there are different con= texts,=20 it should be possible to

>> have the context sensitive tools develop= ped by=20 the experts in a particular

>> context/area.

>> 

>> Currently I can identify two=20 contexts:

>> -1- packet switched networks, the dedica= ted=20 tools should behave

>>       simi= lar to=20 existing tools

>> -2- packet transport networks, the dedic= ated=20 tools should behave

>>       simi= lar to=20 existing transport technologies.

>> 

>> Regards, Huub.

 

 

--

****************************************************= *************

        &nbs= p;            &= nbsp;   =20 =CE=D2=B0=AE=CD=E2=B5=E3=D2=BB=C6=DF= =C8=FD=D2=BB

_______________________________________________=

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls

--_000_60C093A41B5E45409A19D42CF7786DFD51CDD10C42EUSAACMS0703e_-- From jdrake@juniper.net Wed Jan 19 08:05:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99F83A7020 for ; Wed, 19 Jan 2011 08:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGcZPmxFdL3n for ; Wed, 19 Jan 2011 08:05:55 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 126F83A701D for ; Wed, 19 Jan 2011 08:05:55 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTTcMgYanesESywkv4LKLEqb20OBXHeXS@postini.com; Wed, 19 Jan 2011 08:08:35 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 19 Jan 2011 08:06:58 -0800 From: John E Drake To: Huub van Helvoort , "mpls@ietf.org" Date: Wed, 19 Jan 2011 08:08:59 -0800 Thread-Topic: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] Thread-Index: Acu3poGFqV+XVn6PTgmJT58qugGbGQAR9FHg Message-ID: <5E893DB832F57341992548CDBB33316398C734A1AC@EMBX01-HQ.jnpr.net> References: <4D3619B1.1090301@gmail.com> <4D368C1B.7080106@gmail.com> In-Reply-To: <4D368C1B.7080106@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 16:05:56 -0000 U25pcHBlZCwgY29tbWVudHMgaW5saW5lDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiANCj4g SWYgeW91IGxvb2sgYXQgdGhlIHRlcm1zIHRoZXkgbG9vayBzaW1pbGFyLCBidXQgcGFja2V0IHRy YW5zcG9ydA0KPiBkaWZmZXJzDQo+IGZyb20gcGFja2V0IHN3aXRjaGluZyBpbiB0aGUgd2F5IHBh Y2tldHMgYXJlIHRyYW5zcG9ydGVkLiBJbiBwYWNrZXQNCj4gdHJhbnNwb3J0IHRoZSBvYmplY3Rp dmUgaXMgdG8gdHJhbnNwb3J0IHBhY2tldHMgaW5kZXBlbmRlbmQgb2YgdGhlDQo+IHRlY2hub2xv Z3kNCg0KSkQ6ICBJIGdldCB0aGUgc2Vuc2UgdGhhdCB5b3UncmUgbm90IHZlcnkgZmFtaWxpYXIg d2l0aCB0aGUgd2F5IHRoYXQgcGFja2V0IHN3aXRjaGluZywgYW5kIGluIHBhcnRpY3VsYXIgSVAg YW5kIE1QTFMsIHdvcmsuICBJbiB0aGVzZSBuZXR3b3JrcywgdGhlIHN3aXRjaGluZyBvZiBwYWNr ZXRzIGlzIGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgb2YgdGhlIHVuZGVybHlpbmcgTDEvTDIgdGVj aG5vbG9neSBvZiB0aGUgbGlua3MgYmV0d2VlbiBwYWNrZXQgc3dpdGNoaW5nIG5vZGVzLiAgDQoN Cj4gLCBzbyBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgT0FNIGZvciBwYWNrZXQgdHJhbnNwb3J0 IGlzDQo+IHRoZSBzYW1lIGluIGFsbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzLg0KDQpKRDogIFRo aXMgc291bmRzIGxpa2UgYSBxdW90ZSBmcm9tIFByb2Zlc3NvciBJcndpbiBDb3JleS4gIEl0IGlz IGltcG9ydGFudCB0aGF0IHRoZSBNUExTIG5ldHdvcmsgaGFzIGFuIE9BTSBjYXBhYmlsaXR5IHRo YXQgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIE9BTSBjYXBhYmlsaXRpZXMgb2YgdGhlIHVuZGVybHlp bmcgTDEvTDIgdGVjaG5vbG9naWVzLiAgSXQgaXMgbm90IGltcG9ydGFudCB0aGF0IHRoZSBNUExT IG5ldHdvcmsgdXNlcyB0aGUgc2FtZSBPQU0gcHJvdG9jb2xzIGFzIGEgcGFydGljdWxhciBMMS9M MiB0ZWNobm9sb2d5LCBzaW1wbHkgYmVjYXVzZSB0aGVyZSBhcmUgc28gbWFueSBkaWZmZXJlbnQg b25lcy4gIEkgdGhpbmsgTmVpbCBIYXJyaXNvbiB3b3VsZCBjYWxsIHRoaXMgY2xpZW50L3NlcnZl ciAxMDEuIA0KDQo= From tnadeau@lucidvision.com Wed Jan 19 10:35:19 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0E328C133 for ; Wed, 19 Jan 2011 10:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwVOiNBpjaIK for ; Wed, 19 Jan 2011 10:35:18 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 3869128C130 for ; Wed, 19 Jan 2011 10:35:18 -0800 (PST) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 366E218D92CA; Wed, 19 Jan 2011 13:37:58 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <5E893DB832F57341992548CDBB33316398C734A1AC@EMBX01-HQ.jnpr.net> Date: Wed, 19 Jan 2011 13:37:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4654296E-B087-4F8A-B338-5FECBF572142@lucidvision.com> References: <4D3619B1.1090301@gmail.com> <4D368C1B.7080106@gmail.com> <5E893DB832F57341992548CDBB33316398C734A1AC@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1082) Cc: "mpls@ietf.org" , Huub van Helvoort Subject: Re: [mpls] Response to Updated draft Recommendation G.tpoam [Ref 043.02] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:35:19 -0000 On Jan 19, 2011, at 11:08 AM, John E Drake wrote: > Snipped, comments inline >=20 > Sent from my iPhone >=20 >>=20 >> If you look at the terms they look similar, but packet transport >> differs >> from packet switching in the way packets are transported. In packet >> transport the objective is to transport packets independend of the >> technology >=20 > JD: I get the sense that you're not very familiar with the way that = packet switching, and in particular IP and MPLS, work. In these = networks, the switching of packets is completely independent of the = underlying L1/L2 technology of the links between packet switching nodes. = =20 To add to the point you made above, that independence is done = *intentionally* and for very good reasons. >> , so it is important that the OAM for packet transport is >> the same in all transport technologies. >=20 > JD: This sounds like a quote from Professor Irwin Corey. It is = important that the MPLS network has an OAM capability that is = independent of the OAM capabilities of the underlying L1/L2 = technologies. It is not important that the MPLS network uses the same = OAM protocols as a particular L1/L2 technology, simply because there are = so many different ones. I think Neil Harrison would call this = client/server 101.=20 As I recall, the original intent of the requirements was to have = the same operational "look and feel" for operators familiar with optical = transport technologies. The intent was that operational activities such = as provisioning and troubleshooting be designed in such a way as to be = familiar to what operators were used to. I don't think this translates = into requiring that identical technologies are used. And as you say, it = it not a good idea to have them intimately linked for the same good = network layering design principles. --Tom >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From mach@huawei.com Thu Jan 20 00:04:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BCB3A6F25 for ; Thu, 20 Jan 2011 00:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM0cErozArIp for ; Thu, 20 Jan 2011 00:04:48 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7B71F3A6E7E for ; Thu, 20 Jan 2011 00:04:48 -0800 (PST) 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 <0LFB00I8DAGUAA@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 20 Jan 2011 16:05:18 +0800 (CST) Received: from C55527A ([10.110.98.37]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFB0048WAGSR0@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 20 Jan 2011 16:05:18 +0800 (CST) Date: Thu, 20 Jan 2011 16:05:15 +0800 From: Mach Chen In-reply-to: <3B0A1BED22CAD649A1B3E97BE5DDD68B02DB6648@SZXEML514-MBS.china.huawei.com> To: jiangyuanlong Message-id: <8A61371564534069B2C4E8C36FAF4DF8@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <3B0A1BED22CAD649A1B3E97BE5DDD68B02DB6648@SZXEML514-MBS.china.huawei.com> Cc: mpls@ietf.org Subject: Re: [mpls] One question about U and F-bit for Status TLV X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:04:49 -0000 Yuanlong, >>> >>> It seems that it wants to use the F-bit to control whether to forward >>> the >>> notification messsage, but this should not work since the U-bit is >>> clear. >> [JYL] IMO, this "notification" does not mean "Notification message", but >> the >> "Status Code". > > Yes, but most of the time, it's the same, because Status TLV is mainly > designed to be carried in the Notification message. > > [JYL] At the end of Sec.3.4.6: > "Note that use of the Status TLV is not limited to Notification > messages. A message other than a Notification message may carry a > Status TLV as an Optional Parameter. When a message other than a > Notification carries a Status TLV, the U-bit of the Status TLV SHOULD > be set to 1 to indicate that the receiver SHOULD silently discard the > TLV if unprepared to handle it." > From this note, it seems to me F=1 in the Status TLV only applies to > a message other than a Notification message. This is one reasonable explanation. And that means an LSR can not forward the Status TLV received in a Notification message to other LSRs. Best regards, Mach From Lothar.Zier@t-systems.com Thu Jan 20 06:54:48 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342EE3A7120 for ; Thu, 20 Jan 2011 06:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atIquGgq3530 for ; Thu, 20 Jan 2011 06:54:46 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id A4B923A7124 for ; Thu, 20 Jan 2011 06:54:45 -0800 (PST) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jan 2011 15:56:17 +0100 Received: from HE111524.emea1.cds.t-internal.com ([169.254.2.149]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Thu, 20 Jan 2011 15:56:17 +0100 From: To: Date: Thu, 20 Jan 2011 15:56:17 +0100 Thread-Topic: mpls Digest, Vol 81, Issue 33 Thread-Index: Acu0JiWOQMwUEemuSdCBA4VrI2OJhQEjAtHe Message-ID: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] mpls Digest, Vol 81, Issue 33 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 14:54:48 -0000 sent by T-Systems mobility solutions ----- Urspr=FCngliche Nachricht ----- Von: mpls-request@ietf.org Gesendet: Freitag, 14. Januar 2011 21:03 An: mpls@ietf.org Betreff: mpls Digest, Vol 81, Issue 33 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/mpls Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send mpls mailing list submissions to mpls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/mpls or, via email, send a message with subject or body 'help' to mpls-request@ietf.org You can reach the person managing the list at mpls-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mpls digest..." Today's Topics: 1. Re: R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] (Luyuan Fang (lufang)) 2. Re: R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] (Thomas Walsh) 3. Re: R: Draft: Response to Updated draftRecommendationG.tpoam [Ref 043.02] (Luyuan Fang (lufang)) 4. Re: R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] (John E Drake) ---------------------------------------------------------------------- Message: 1 Date: Fri, 14 Jan 2011 09:28:16 -0600 From: "Luyuan Fang (lufang)" Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] To: "Eric Rosen (erosen)" , "Christopher LILJENSTOLPE" Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Message-ID: <238542D917511A45B6B8AA806E875E25041C5007@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=3D"iso-8859-1" In fact, no MPLS or any other IETF protocol extensions/modifications can be= standardized outside of IETF in any case. Other SDOs can develop technologies independently as long as not extending/= modifying IETF protocols on their own. Luyuan -----Original Message----- From: Luyuan Fang (lufang) Sent: 14 January 2011 10:19 To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport requirements, = IETF defines the protocols. Option 2: IETF and ITU-T each develop separately, in that case, no MPLS pro= tocol extensions/modifications can be standardized outside of IETF, nor the= use of MPLS naming. The consequences of breaching the joint agreement would lead to Option 2. References: [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural Considera= tions for a Transport Profile, Feb. 2009. [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and Gen= eralized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and > IETF processes. ?It does not say that the IETF will not meet it's > obligations under the JWT if the request is made the correct way. > It's not a "bugger off" it's a "please work with us in the manner > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained (wishy-was= hy). Since the ITU-T has breached the agreement, I don't see why the IETF = should be thought to have any further obligations under the JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 2 Date: Fri, 14 Jan 2011 10:53:50 -0500 From: Thomas Walsh Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpoam [Ref 043.02] To: "Luyuan Fang (lufang)" , "Eric Rosen (erosen)" , Christopher LILJENSTOLPE Cc: "mpls@ietf.org" , "Stewart Bryant \(stbryant\)" Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" The problem is only at the Rapporteur level. It isn't an official ITU-T ac= tion until and unless its is confirmed at the Working Party meeting in Gene= va in February. There is an interesting liaison (TD-563 GEN) from IETF to SG 11 meeting thi= s month explaining what needs to be done if ITU-T wants to develop a new pr= otocol rather than use IETF protocol. "In particular, different identifiers= , formats, protocol names, and protocol component names be used at all leve= ls of the protocol stack implied by the design." MPLS can not be modified without IETF approval and ITU-T would need to crea= te an entire new suite of protocols with new identifiers, formats, names, e= tc. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Luy= uan Fang (lufang) Sent: Friday, January 14, 2011 7:28 AM To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] In fact, no MPLS or any other IETF protocol extensions/modifications can be= standardized outside of IETF in any case. Other SDOs can develop technologies independently as long as not extending/= modifying IETF protocols on their own. Luyuan -----Original Message----- From: Luyuan Fang (lufang) Sent: 14 January 2011 10:19 To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport requirements, = IETF defines the protocols. Option 2: IETF and ITU-T each develop separately, in that case, no MPLS pro= tocol extensions/modifications can be standardized outside of IETF, nor the= use of MPLS naming. The consequences of breaching the joint agreement would lead to Option 2. References: [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural Considera= tions for a Transport Profile, Feb. 2009. [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and Gen= eralized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and > IETF processes. ?It does not say that the IETF will not meet it's > obligations under the JWT if the request is made the correct way. > It's not a "bugger off" it's a "please work with us in the manner > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained (wishy-was= hy). Since the ITU-T has breached the agreement, I don't see why the IETF = should be thought to have any further obligations under the JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 3 Date: Fri, 14 Jan 2011 10:20:16 -0600 From: "Luyuan Fang (lufang)" Subject: Re: [mpls] R: Draft: Response to Updated draftRecommendationG.tpoam [Ref 043.02] To: "Thomas Walsh" , "Eric Rosen (erosen)" , "Christopher LILJENSTOLPE" Cc: mpls@ietf.org, "Stewart Bryant \(stbryant\)" Message-ID: <238542D917511A45B6B8AA806E875E25041C5078@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=3D"iso-8859-1" > MPLS can not be modified without IETF approval and ITU-T would need to cr= eate an entire new suite of protocols with new identifiers, formats, names,= etc. Yep, if that is the route folks like to take. -----Original Message----- From: Thomas Walsh [mailto:twalsh@juniper.net] Sent: 14 January 2011 10:54 To: Luyuan Fang (lufang); Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draftRecommendationG.tpoa= m [Ref 043.02] The problem is only at the Rapporteur level. It isn't an official ITU-T ac= tion until and unless its is confirmed at the Working Party meeting in Gene= va in February. There is an interesting liaison (TD-563 GEN) from IETF to SG 11 meeting thi= s month explaining what needs to be done if ITU-T wants to develop a new pr= otocol rather than use IETF protocol. "In particular, different identifiers= , formats, protocol names, and protocol component names be used at all leve= ls of the protocol stack implied by the design." MPLS can not be modified without IETF approval and ITU-T would need to crea= te an entire new suite of protocols with new identifiers, formats, names, e= tc. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Luy= uan Fang (lufang) Sent: Friday, January 14, 2011 7:28 AM To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] In fact, no MPLS or any other IETF protocol extensions/modifications can be= standardized outside of IETF in any case. Other SDOs can develop technologies independently as long as not extending/= modifying IETF protocols on their own. Luyuan -----Original Message----- From: Luyuan Fang (lufang) Sent: 14 January 2011 10:19 To: Eric Rosen (erosen); Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: RE: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] Agree with Eric. This brought us back to 2008 with two options on the table again. Option 1: IETF/ITU-T work jointly - ITU-T provides transport requirements, = IETF defines the protocols. Option 2: IETF and ITU-T each develop separately, in that case, no MPLS pro= tocol extensions/modifications can be standardized outside of IETF, nor the= use of MPLS naming. The consequences of breaching the joint agreement would lead to Option 2. References: [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural Considera= tions for a Transport Profile, Feb. 2009. [RFC 4775]: Procedures for Protocol Extensions and Variations, Dec. 2006. [RFC 4929]: Change Process for Multiprotocol Label Switching (MPLS) and Gen= eralized MPLS (GMPLS) Protocols and Procedures, June 2007. Luyuan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen (erosen) Sent: 14 January 2011 09:19 To: Christopher LILJENSTOLPE Cc: mpls@ietf.org; Stewart Bryant (stbryant) Subject: Re: [mpls] R: Draft: Response to Updated draft RecommendationG.tpo= am [Ref 043.02] > It is a statement that identifies that the ITU-T did not follow the > JWT agreement between the IETF and the ITU-T, nor internal ITU-T and > IETF processes. ?It does not say that the IETF will not meet it's > obligations under the JWT if the request is made the correct way. > It's not a "bugger off" it's a "please work with us in the manner > previously agreed and respect our process" I don't understand why the Liaison is so measured and restrained (wishy-was= hy). Since the ITU-T has breached the agreement, I don't see why the IETF = should be thought to have any further obligations under the JWT. Shouldn't the liaison state the consequences of this breach? _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 4 Date: Fri, 14 Jan 2011 10:01:47 -0800 From: John E Drake Subject: Re: [mpls] R: Draft: Response to Updated draft Recommendation G.tpoam [Ref 043.02] To: "erosen@cisco.com" , Christopher LILJENSTOLPE Cc: "mpls@ietf.org" , "stbryant@cisco.com" Message-ID: <5E893DB832F57341992548CDBB33316398C702ACF2@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=3D"iso-8859-1" And actually, given the situation, asking the IETF to review this document = is really an act of disrespect. Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Rosen > Sent: Friday, January 14, 2011 6:19 AM > To: Christopher LILJENSTOLPE > Cc: mpls@ietf.org; stbryant@cisco.com > Subject: Re: [mpls] R: Draft: Response to Updated draft Recommendation > G.tpoam [Ref 043.02] > > > > It is a statement that identifies that the ITU-T did not follow the > JWT > > agreement between the IETF and the ITU-T, nor internal ITU-T and IETF > > processes. ?It does not say that the IETF will not meet it's > obligations > > under the JWT if the request is made the correct way. ?It's not a > "bugger > > off" it's a "please work with us in the manner previously agreed and > > respect our process" > > I don't understand why the Liaison is so measured and restrained > (wishy-washy). Since the ITU-T has breached the agreement, I don't see > why > the IETF should be thought to have any further obligations under the > JWT. > Shouldn't the liaison state the consequences of this breach? > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 81, Issue 33 ************************************ From loa@pi.nu Sat Jan 22 11:29:07 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B313A69F7; Sat, 22 Jan 2011 11:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFc+ZsMAg0bI; Sat, 22 Jan 2011 11:29:06 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id B12223A69A2; Sat, 22 Jan 2011 11:29:06 -0800 (PST) Received: from [172.17.113.226] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 20F182A8001; Sat, 22 Jan 2011 20:31:52 +0100 (CET) Message-ID: <4D3B30A3.1030607@pi.nu> Date: Sat, 22 Jan 2011 11:31:47 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-fang-mpls-tp-security-framework@tools.ietf.org, "mpls@ietf.org" , Ross Callon , MPLS-TP ad hoc team Subject: [mpls] poll on making draft-fang-mpls-tp-security-framework-04 a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 19:29:07 -0000 Working Group, this is to start a two week poll on making draft-fang-mpls-tp-security-framework-04 an MPLS working group document! Please send your responses to the mpls-tp@ietf.org mailing list. The poll ends Feb 6, 2011. Loa, George and Ross mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From mach@huawei.com Sun Jan 23 16:34:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F9A3A69E6; Sun, 23 Jan 2011 16:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1jm80auolIf; Sun, 23 Jan 2011 16:34:04 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 671C23A69E0; Sun, 23 Jan 2011 16:34:04 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFI000QD4DBLW@szxga05-in.huawei.com>; Mon, 24 Jan 2011 08:36:47 +0800 (CST) Received: from C55527A ([10.110.98.37]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFI00AJI4D515@szxga05-in.huawei.com>; Mon, 24 Jan 2011 08:36:47 +0800 (CST) Date: Mon, 24 Jan 2011 08:36:41 +0800 From: Mach Chen In-reply-to: <4D3B30A3.1030607@pi.nu> To: 'Loa Andersson' , mpls-tp@ietf.org Message-id: <007001cbbb5e$c614e850$523eb8f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acu6axEFS+70VuPcQkC5cD4yKvVxNgA85nzw References: <4D3B30A3.1030607@pi.nu> Cc: mpls@ietf.org, 'MPLS-TP ad hoc team' , draft-fang-mpls-tp-security-framework@tools.ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-fang-mpls-tp-security-framework-04 a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 00:34:05 -0000 Support. Mach > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: Sunday, January 23, 2011 3:32 AM > To: mpls-tp@ietf.org > Cc: draft-fang-mpls-tp-security-framework@tools.ietf.org; mpls@ietf.org; > MPLS-TP ad hoc team > Subject: [mpls-tp] poll on making draft-fang-mpls-tp-security-framework-04 a > working group document > > Working Group, > > this is to start a two week poll on making > > draft-fang-mpls-tp-security-framework-04 > > an MPLS working group document! > > Please send your responses to the mpls-tp@ietf.org mailing list. > > The poll ends Feb 6, 2011. > > Loa, George and Ross > mpls wg co-chairs > > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From wei.hongbo@zte.com.cn Sun Jan 23 16:38:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1631B3A69FC; Sun, 23 Jan 2011 16:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.111 X-Spam-Level: X-Spam-Status: No, score=-97.111 tagged_above=-999 required=5 tests=[AWL=-0.965, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYEDJzvrAaBv; Sun, 23 Jan 2011 16:38:01 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 4F5BD3A69F9; Sun, 23 Jan 2011 16:38:00 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951911657480; Mon, 24 Jan 2011 08:36:22 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 53678.5153815725; Mon, 24 Jan 2011 08:33:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0O0ehSX098841; Mon, 24 Jan 2011 08:40:43 +0800 (GMT-8) (envelope-from wei.hongbo@zte.com.cn) In-Reply-To: <4D3B30A3.1030607@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.hongbo@zte.com.cn Date: Mon, 24 Jan 2011 08:37:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-24 08:40:43, Serialize complete at 2011-01-24 08:40:43 Content-Type: multipart/alternative; boundary="=_alternative 0003BBC048257822_=" X-MAIL: mse02.zte.com.cn p0O0ehSX098841 Cc: draft-fang-mpls-tp-security-framework@tools.ietf.org, "mpls@ietf.org" , MPLS-TP ad hoc team , mpls-tp-bounces@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] poll on making draft-fang-mpls-tp-security-framework-04 a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 00:38:02 -0000 This is a multipart message in MIME format. --=_alternative 0003BBC048257822_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCByZWdhcmRzLA0Kc3RldmVuDQoNCg0KDQoNCg0KTG9hIEFuZGVyc3Nv biA8bG9hQHBpLm51PiANCreivP7IyzogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0w MS0yMyAwMzozMQ0KDQrK1bz+yMsNCiJtcGxzLXRwQGlldGYub3JnIiA8bXBscy10cEBpZXRmLm9y Zz4NCrOty80NCmRyYWZ0LWZhbmctbXBscy10cC1zZWN1cml0eS1mcmFtZXdvcmtAdG9vbHMuaWV0 Zi5vcmcsICJtcGxzQGlldGYub3JnIiANCjxtcGxzQGlldGYub3JnPiwgTVBMUy1UUCBhZCBob2Mg dGVhbSA8YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ+DQrW98ziDQpbbXBscy10cF0gcG9sbCBvbiBt YWtpbmcgZHJhZnQtZmFuZy1tcGxzLXRwLXNlY3VyaXR5LWZyYW1ld29yay0wNCBhIA0Kd29ya2lu ZyBncm91cCBkb2N1bWVudA0KDQoNCg0KDQoNCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBpcyB0 byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQoNCmRyYWZ0LWZhbmctbXBscy10cC1z ZWN1cml0eS1mcmFtZXdvcmstMDQNCg0KYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50IQ0K DQpQbGVhc2Ugc2VuZCB5b3VyIHJlc3BvbnNlcyB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWls aW5nIGxpc3QuDQoNClRoZSBwb2xsIGVuZHMgRmViIDYsIDIwMTEuDQoNCkxvYSwgR2VvcmdlIGFu ZCBSb3NzDQptcGxzIHdnIGNvLWNoYWlycw0KDQoNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQpT ciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVy aWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIg MTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3 IDcyIDkyIDEzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbXBscy10cCBtYWlsaW5nIGxpc3QNCm1wbHMtdHBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cA0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0003BBC048257822_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0K c3RldmVuPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjxiPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZndDs8L2I+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBs cy10cC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjIwMTEtMDEtMjMgMDM6MzE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBscy10cEBpZXRmLm9yZyZxdW90OyAmbHQ7 bXBscy10cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRyYWZ0LWZhbmctbXBscy10 cC1zZWN1cml0eS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcsDQomcXVvdDttcGxzQGlldGYub3Jn JnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OywgTVBMUy1UUCBhZCBob2MgdGVhbSAmbHQ7YWht cGxzLXRwQGxpc3RzLml0dS5pbnQmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbXBscy10cF0gcG9s bCBvbiBtYWtpbmcgZHJhZnQtZmFuZy1tcGxzLXRwLXNlY3VyaXR5LWZyYW1ld29yay0wNA0KYSB3 b3JraW5nIGdyb3VwIGRvY3VtZW50PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5Xb3JraW5nIEdyb3VwLDxicj4NCjxicj4NCnRoaXMgaXMg dG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZzxicj4NCjxicj4NCmRyYWZ0LWZhbmct bXBscy10cC1zZWN1cml0eS1mcmFtZXdvcmstMDQ8YnI+DQo8YnI+DQphbiBNUExTIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQhPGJyPg0KPGJyPg0KUGxlYXNlIHNlbmQgeW91ciByZXNwb25zZXMgdG8g dGhlIG1wbHMtdHBAaWV0Zi5vcmcgbWFpbGluZyBsaXN0Ljxicj4NCjxicj4NClRoZSBwb2xsIGVu ZHMgRmViIDYsIDIwMTEuPGJyPg0KPGJyPg0KTG9hLCBHZW9yZ2UgYW5kIFJvc3M8YnI+DQptcGxz IHdnIGNvLWNoYWlyczxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBB bmRlcnNzb24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOiBsb2EuYW5kZXJzc29u QGVyaWNzc29uLmNvbTxicj4NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvYUBwaS5udTxicj4NCkVyaWNz c29uIEluYyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICs0NiAxMCA3 MTcgNTIgMTM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7KzQ2IDc2NyA3MiA5MiAxMzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbXBscy10cCBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzLXRw QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz LXRwPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJ bmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9y bWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lz Jm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidz Jm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZu YnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZu YnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJz cDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3Ro aXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1h aWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0 aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5k ZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZu YnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDto YXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9y Jm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3Nl ZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNz YWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2Vz Jm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7 c3lzdGVtLg0KPC9wcmU+ --=_alternative 0003BBC048257822_=-- From iesg-secretary@ietf.org Mon Jan 24 09:23:56 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1B23A6403; Mon, 24 Jan 2011 09:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys6Ob9MbQu-r; Mon, 24 Jan 2011 09:23:55 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93E23A6B17; Mon, 24 Jan 2011 09:23:54 -0800 (PST) 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.10 Message-ID: <20110124172354.22294.96893.idtracker@localhost> Date: Mon, 24 Jan 2011 09:23:54 -0800 Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Document Action: 'MPLS Transport Profile User-to-Network and Network-to-Network Interfaces' to Informational RFC (draft-ietf-mpls-tp-uni-nni-03.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:23:56 -0000 The IESG has approved the following document: - 'MPLS Transport Profile User-to-Network and Network-to-Network Interfaces' (draft-ietf-mpls-tp-uni-nni-03.txt) as an Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-uni-nni/ Technical Summary The transport service interfaces for MPLS-TP are defined in Section 3.4.3 of [RFC5921]. These definitions are illustrated by showing MPLS-TP PEs containing a UNI and an NNI. The figures illustrate the UNI and the NNI as a span. However, it is more conventional to illustrate these interfaces as reference points. Furthermore, in the case of a UNI, it is useful to illustrate the distribution of UNI functions between the CE side and the PE side of the UNI (the UNI-C and UNI-N). This document provides updated illustrations of the MPLS-TP UNI and MPLS-TP NNI to show these additional details. These illustrations are intended to obsolete the corresponding ones in [RFC5921]. This document also defines additional terminology referenced in the illustrations. No other updates are proposed by this document. Working Group Summary Since the document is an output from the MPLS-TP project it is the joint output of IETF MPLS working group and Qustion 9, 10, 12 and 14 of ITU-T SG15. Document Quality The document is well reviewed in all the groups mentioned above. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From zhang.fei3@zte.com.cn Mon Jan 24 16:22:22 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0D63A69BF; Mon, 24 Jan 2011 16:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.963 X-Spam-Level: X-Spam-Status: No, score=-96.963 tagged_above=-999 required=5 tests=[AWL=-1.742, BAYES_40=-0.185, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJTj3ZoYL2c4; Mon, 24 Jan 2011 16:22:21 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D923A3A69C0; Mon, 24 Jan 2011 16:22:20 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205952548420933; Tue, 25 Jan 2011 08:20:45 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96520.5943168287; Tue, 25 Jan 2011 08:25:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p0P0P632087349; Tue, 25 Jan 2011 08:25:06 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4D3B30A3.1030607@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 25 Jan 2011 08:25:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-25 08:25:06, Serialize complete at 2011-01-25 08:25:06 Content-Type: multipart/alternative; boundary="=_alternative 0002BA4148257823_=" X-MAIL: mse01.zte.com.cn p0P0P632087349 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , draft-fang-mpls-tp-security-framework@tools.ietf.org, "mpls-tp@ietf.org" , mpls-bounces@ietf.org, Ross Callon Subject: Re: [mpls] poll on making draft-fang-mpls-tp-security-framework-04 a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:22:22 -0000 This is a multipart message in MIME format. --=_alternative 0002BA4148257823_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydA0KDQpGZWkNCg0KDQoNCkxvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4gDQq3orz+yMs6 ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDEtMjMgMDM6MzENCg0KytW8/sjLDQoibXBs cy10cEBpZXRmLm9yZyIgPG1wbHMtdHBAaWV0Zi5vcmc+DQqzrcvNDQpkcmFmdC1mYW5nLW1wbHMt dHAtc2VjdXJpdHktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnLCAibXBsc0BpZXRmLm9yZyIgDQo8 bXBsc0BpZXRmLm9yZz4sIFJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PiwgTVBMUy1U UCBhZCBob2MgdGVhbSANCjxhaG1wbHMtdHBAbGlzdHMuaXR1LmludD4NCtb3zOINClttcGxzXSBw b2xsIG9uIG1ha2luZyBkcmFmdC1mYW5nLW1wbHMtdHAtc2VjdXJpdHktZnJhbWV3b3JrLTA0IGEg d29ya2luZyANCmdyb3VwIGRvY3VtZW50DQoNCg0KDQoNCg0KDQpXb3JraW5nIEdyb3VwLA0KDQp0 aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCg0KZHJhZnQtZmFuZy1t cGxzLXRwLXNlY3VyaXR5LWZyYW1ld29yay0wNA0KDQphbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQhDQoNClBsZWFzZSBzZW5kIHlvdXIgcmVzcG9uc2VzIHRvIHRoZSBtcGxzLXRwQGlldGYu b3JnIG1haWxpbmcgbGlzdC4NCg0KVGhlIHBvbGwgZW5kcyBGZWIgNiwgMjAxMS4NCg0KTG9hLCBH ZW9yZ2UgYW5kIFJvc3MNCm1wbHMgd2cgY28tY2hhaXJzDQoNCg0KLS0gDQoNCg0KTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nv bi5jb20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBw aS5udQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEw IDcxNyA1MiAxMw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQo= --=_alternative 0002BA4148257823_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQ8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb2EgQW5kZXJzc29uICZsdDts b2FAcGkubnUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTAxLTIzIDAzOjMxPC9mb250Pg0KPHRkIHdp ZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O21wbHMtdHBA aWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5kcmFmdC1mYW5nLW1wbHMtdHAtc2VjdXJpdHktZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnLA0K JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIFJvc3MgQ2Fs bG9uICZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OywNCk1QTFMtVFAgYWQgaG9jIHRlYW0gJmx0 O2FobXBscy10cEBsaXN0cy5pdHUuaW50Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21wbHNdIHBv bGwgb24gbWFraW5nIGRyYWZ0LWZhbmctbXBscy10cC1zZWN1cml0eS1mcmFtZXdvcmstMDQNCmEg d29ya2luZyBncm91cCBkb2N1bWVudDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+V29ya2luZyBHcm91cCw8YnI+DQo8YnI+DQp0aGlzIGlz IHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmc8YnI+DQo8YnI+DQpkcmFmdC1mYW5n LW1wbHMtdHAtc2VjdXJpdHktZnJhbWV3b3JrLTA0PGJyPg0KPGJyPg0KYW4gTVBMUyB3b3JraW5n IGdyb3VwIGRvY3VtZW50ITxicj4NCjxicj4NClBsZWFzZSBzZW5kIHlvdXIgcmVzcG9uc2VzIHRv IHRoZSBtcGxzLXRwQGlldGYub3JnIG1haWxpbmcgbGlzdC48YnI+DQo8YnI+DQpUaGUgcG9sbCBl bmRzIEZlYiA2LCAyMDExLjxicj4NCjxicj4NCkxvYSwgR2VvcmdlIGFuZCBSb3NzPGJyPg0KbXBs cyB3ZyBjby1jaGFpcnM8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2Eg QW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmlj c3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAg NzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOys0NiA3NjcgNzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4N Cjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 0002BA4148257823_=-- From venkatflex@gmail.com Mon Jan 24 16:30:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA2A28B23E; Mon, 24 Jan 2011 16:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.649 X-Spam-Level: * X-Spam-Status: No, score=1.649 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDYyzhAgS2Fz; Mon, 24 Jan 2011 16:30:04 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2901D3A6B05; Mon, 24 Jan 2011 16:30:03 -0800 (PST) Received: by pvc21 with SMTP id 21so1066857pvc.31 for ; Mon, 24 Jan 2011 16:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=okWmM4PohYmAfU6BYUH6DJDpZCGzrpRhh4u9WFw2Arc=; b=YwPintqairuMBQsG/TopZxQY1UWE5T0WSahcUfa43W5RFug67ZM8RZxxZAl4yM+WYo bZKzYhTVVw6KVDzGJ0qqU78ZlHtmLL6eb2xn5hmLBOpSSRKxmhmM6sh+wCrcDueLpBlC e7z3Y+hYvQ17/tDnauxlYfo8xhKB5yIGL2aiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Iw6fFVOceTTrqLdQ08MmEO4g2qzpgL8MmxNLTjfurvIoQCKzpqQ1Ytq3rdX71WnnGb 1hH7sCdazWeNMSnyHuNqpDPr1h41uicxdwInNx0YHy+dGVYuT95cITMBIgfR3Rjo6nu5 D3NX+HGoAW+ZMbiYehQH98x7ACRaGahh2Ie90= MIME-Version: 1.0 Received: by 10.142.161.11 with SMTP id j11mr4558583wfe.60.1295915577930; Mon, 24 Jan 2011 16:32:57 -0800 (PST) Received: by 10.142.76.10 with HTTP; Mon, 24 Jan 2011 16:32:57 -0800 (PST) In-Reply-To: References: <4D3B30A3.1030607@pi.nu> Date: Mon, 24 Jan 2011 19:32:57 -0500 Message-ID: From: venkatesan mahalingam To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , draft-fang-mpls-tp-security-framework@tools.ietf.org, "mpls-tp@ietf.org" , mpls-bounces@ietf.org, Ross Callon Content-Type: multipart/alternative; boundary=000e0cd32a10ae76f7049aa0db9b Subject: Re: [mpls] poll on making draft-fang-mpls-tp-security-framework-04 a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:30:08 -0000 --000e0cd32a10ae76f7049aa0db9b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Support. Regards, Venkat. 2011/1/24 > > Support > > Fei > > > *Loa Andersson * > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > > 2011-01-23 03:31 > =CA=D5=BC=FE=C8=CB > "mpls-tp@ietf.org" > =B3=AD=CB=CD > draft-fang-mpls-tp-security-framework@tools.ietf.org, "mpls@ietf.org" < > mpls@ietf.org>, Ross Callon , MPLS-TP ad hoc team < > ahmpls-tp@lists.itu.int> > =D6=F7=CC=E2 > [mpls] poll on making draft-fang-mpls-tp-security-framework-04 a working > group document > > > > > Working Group, > > this is to start a two week poll on making > > draft-fang-mpls-tp-security-framework-04 > > an MPLS working group document! > > Please send your responses to the mpls-tp@ietf.org mailing list. > > The poll ends Feb 6, 2011. > > Loa, George and Ross > mpls wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Best Regards, Venkatesan Mahalingam. <#> <#> <#> <#> --000e0cd32a10ae76f7049aa0db9b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Support.

Regards,
Venkat.

2011/= 1/24 <zhang.= fei3@zte.com.cn>

Support

Fei


Loa Andersson <loa@pi.nu= >
=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.= org

2011-01-23 03= :31
=CA=D5=BC=FE=C8= =CB
"mpls-tp@ietf.org"= <mpls-tp@ietf.org= >
=B3=AD=CB=CD
draft-fang-mpl= s-tp-security-framework@tools.ietf.org, "mpls@ietf.org&= quot; <mpls@ietf.org<= /a>>, Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>
=D6=F7=CC=E2
[mpls] poll on making draft-f= ang-mpls-tp-security-framework-04 a working group document





Working Group,

this is to start a two week poll on making

draft-fang-mpls-tp-security-framework-04

an MPLS working group document!

Please send your responses to the mpls-tp@ietf.org mailing list.

The poll ends Feb 6, 2011.

Loa, George and Ross
mpls wg co-chairs


--


Loa Andersson                  = ;       email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            = loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                         = ;    +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

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




--
Best Regards,
Ve= nkatesan Mahalingam.
3D""
=20 =20
  &n= bsp;
=20
&nbs= p;
3D""   3D""      
=20
 
 
=
=20
=20
=20
<= a id=3D"DOSSIER_LINK1d66kfm" href=3D"#" target=3D"_blank" style=3D"text-dec= oration: underline; color: rgb(0, 0, 222);">
=20 = =20 = =20 = =20
= =20
=20
<= img src=3D"sacore:empty.gif" width=3D"1px" height=3D"1px">
=20
--000e0cd32a10ae76f7049aa0db9b-- From michelg@upperside.fr Tue Jan 25 08:07:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397E23A67FF for ; Tue, 25 Jan 2011 08:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7xthgBDyNmw for ; Tue, 25 Jan 2011 08:07:36 -0800 (PST) Received: from smtp04.msg.oleane.net (smtp04.msg.oleane.net [62.161.4.4]) by core3.amsl.com (Postfix) with ESMTP id F22F43A67ED for ; Tue, 25 Jan 2011 08:07:35 -0800 (PST) Received: from MichelGosseDel (AAubervilliers-752-1-17-56.w90-61.abo.wanadoo.fr [90.61.48.56]) (authenticated) by smtp04.msg.oleane.net (MSA) with ESMTP id p0PGAU5J007441 for ; Tue, 25 Jan 2011 17:10:30 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 25 Jan 2011 17:10:30 +0100 Message-ID: <000b01cbbcaa$638a2090$2a9e61b0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CBBCB2.C54FE820" X-Mailer: Microsoft Outlook 14.0 Thread-index: Acu8qkB8/JrDfosJQ+CadMgM+W1dkA== Content-Language: fr X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.25.160015 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Paris 2011 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:07:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000C_01CBBCB2.C54FE820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MPLS & Ethernet World 2011 will begin in two weeks. Optical layer integration, mobile backhaul, data center interconnection: the main technical issues will be covered by well-known specialists. The debate will cover MPLS-TP OAM issues. There is still time to register at: http://www.upperside.fr/ ------=_NextPart_000_000C_01CBBCB2.C54FE820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS & = Ethernet World 2011 will begin in two weeks.

 

Optical = layer integration, mobile backhaul, data center interconnection: the = main technical issues will be covered by well-known = specialists.

The debate = will cover MPLS-TP OAM issues.

 

There is = still time to register at: http://www.upperside.fr/

 

------=_NextPart_000_000C_01CBBCB2.C54FE820-- From Internet-Drafts@ietf.org Tue Jan 25 11:00:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BB03A6851; Tue, 25 Jan 2011 11:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mGoZXKDEfYm; Tue, 25 Jan 2011 11:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A7D3A683D; Tue, 25 Jan 2011 11:00:02 -0800 (PST) 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.10 Message-ID: <20110125190002.8071.30514.idtracker@localhost> Date: Tue, 25 Jan 2011 11:00:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping Author(s) : S. Yasukawa, et al. Filename : draft-ietf-mpls-p2mp-lsp-ping-14.txt Pages : 27 Date : 2011-01-25 Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment.Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-14.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-mpls-p2mp-lsp-ping-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-25105343.I-D@ietf.org> --NextPart-- From ssaxena@cisco.com Tue Jan 25 13:19:27 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4943B3A68A8 for ; Tue, 25 Jan 2011 13:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6i1KrI4W2HL for ; Tue, 25 Jan 2011 13:19:26 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 655DE3A68A2 for ; Tue, 25 Jan 2011 13:19:26 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8JAE7NPk2tJXG//2dsb2JhbACCQJQShgUBiBlzoVybOIVPBIUXil0 Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2011 21:22:24 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0PLMO7Q006383 for ; Tue, 25 Jan 2011 21:22:24 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 15:22:24 -0600 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_01CBBCD5.F5792414" Date: Tue, 25 Jan 2011 15:22:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mpls-p2mp-lsp-ping-14.txt Thread-Index: Acu81fUDH253gMMxQuKwmcUkEWRoiA== From: "Shaleen Saxena (ssaxena)" To: X-OriginalArrivalTime: 25 Jan 2011 21:22:24.0190 (UTC) FILETIME=[F56E65E0:01CBBCD5] Subject: [mpls] draft-ietf-mpls-p2mp-lsp-ping-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:19:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBCD5.F5792414 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have posted the new version 14 of the P2MP LSP Ping draft.=20 http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-14=20 =20 Changes are: - A minor edit, - updated IANA section and added reference to RFC 4020, - updated the copyright to 2011. =20 Regards, Shaleen =20 ------_=_NextPart_001_01CBBCD5.F5792414 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

I have posted the new version 14 of the P2MP LSP = Ping draft.

http= ://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-14 =

 

Changes are:

= - A minor edit,

- updated IANA = section and added reference to RFC 4020,

- updated the copyright to 2011.

 

Regards,

Shaleen

 

------_=_NextPart_001_01CBBCD5.F5792414-- From Internet-Drafts@ietf.org Wed Jan 26 17:30:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE3D28C0E4; Wed, 26 Jan 2011 17:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xNGD6PGzy-o; Wed, 26 Jan 2011 17:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFF13A68F8; Wed, 26 Jan 2011 17:30:01 -0800 (PST) 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.10 Message-ID: <20110127013001.11594.11916.idtracker@localhost> Date: Wed, 26 Jan 2011 17:30:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-mib-management-overview-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 01: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 Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-tp-mib-management-overview-02.txt Pages : 22 Date : 2011-01-26 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based management architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules would be required. 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 as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] King & Venkatesan, et al. [page 1] draft-ietf-mpls-tp-mib-management-overview-01.txt January 2011 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overview-02.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-mpls-tp-mib-management-overview-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-26171802.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Jan 26 19:15:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B52D3A6A67; Wed, 26 Jan 2011 19:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVgeciHo6YPn; Wed, 26 Jan 2011 19:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB053A6867; Wed, 26 Jan 2011 19:15:02 -0800 (PST) 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.10 Message-ID: <20110127031502.5886.48804.idtracker@localhost> Date: Wed, 26 Jan 2011 19:15:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-15.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 03:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping Author(s) : S. Yasukawa, et al. Filename : draft-ietf-mpls-p2mp-lsp-ping-15.txt Pages : 27 Date : 2011-01-26 Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-15.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-mpls-p2mp-lsp-ping-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-26190032.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Jan 27 00:45:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D18C3A6B08; Thu, 27 Jan 2011 00:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwtMFwR05c04; Thu, 27 Jan 2011 00:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BFE63A6AE0; Thu, 27 Jan 2011 00:45:02 -0800 (PST) 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.10 Message-ID: <20110127084502.3662.96209.idtracker@localhost> Date: Thu, 27 Jan 2011 00:45:02 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-linear-protection-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 08:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Linear Protection Author(s) : S. Bryant, et al. Filename : draft-ietf-mpls-tp-linear-protection-04.txt Pages : 37 Date : 2011-01-27 The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications 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 as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-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-mpls-tp-linear-protection-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-27004453.I-D@ietf.org> --NextPart-- From yaacov.weingarten@nsn.com Thu Jan 27 00:50:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955AF28C113; Thu, 27 Jan 2011 00:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.617 X-Spam-Level: X-Spam-Status: No, score=-4.617 tagged_above=-999 required=5 tests=[AWL=1.981, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRlWq7d-xJyb; Thu, 27 Jan 2011 00:50:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1FA4F28C114; Thu, 27 Jan 2011 00:50:07 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0R8r9JA022482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jan 2011 09:53:09 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0R8r7dG013114; Thu, 27 Jan 2011 09:53:08 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jan 2011 09:53:02 +0100 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_01CBBDFF.9A652EDF" Date: Thu, 27 Jan 2011 09:53:00 +0100 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D0341CB65@DEMUEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of Linear Protection draft thread-index: Acu9/5lU5bWoA+wJRx6rfwyPltTfoA== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 27 Jan 2011 08:53:02.0191 (UTC) FILETIME=[9AD14FF0:01CBBDFF] Cc: mpls-chairs@tools.ietf.org Subject: [mpls] New version of Linear Protection draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 08:50:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBDFF.9A652EDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have just uploaded a new version of draft-ietf-mpls-tp-linear-protection. This draft includes some small changes to the text to reflect comments that were received by the editors. In addition, there is a new appendix to the document that includes a State Machine table that reflects the description of the PSC operation (as described in section 4.3.3). This state machine table is informative, with the text in section 4.3.3 being the normative description. Any comments or suggestions for improvements are welcome. Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_001_01CBBDFF.9A652EDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of Linear Protection draft

Hi all,

I have = just uploaded a new version of = draft-ietf-mpls-tp-linear-protection.  This draft includes = some small changes to the text to reflect comments that were received by = the editors.  In addition, there is a new appendix to the document = that includes a State Machine table that reflects the description of = the PSC operation (as described in section 4.3.3).  This state = machine table is informative, with the text in section 4.3.3 being the = normative description.

Any = comments or suggestions for improvements are welcome.

Best = regards,

Yaacov = Weingarten

Nokia Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 0977

------_=_NextPart_001_01CBBDFF.9A652EDF-- From Internet-Drafts@ietf.org Thu Jan 27 12:15:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9EC3A6878; Thu, 27 Jan 2011 12:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVhvhpX96JFv; Thu, 27 Jan 2011 12:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D773A6A3F; Thu, 27 Jan 2011 12:15:01 -0800 (PST) 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.10 Message-ID: <20110127201501.28169.38430.idtracker@localhost> Date: Thu, 27 Jan 2011 12:15:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-return-path-specified-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Return Path Specified LSP Ping Author(s) : M. Chen, S. Ning, F. JOUNAY, S. Delord, X. Guo, W. Cao Filename : draft-ietf-mpls-return-path-specified-lsp-ping-02.txt Pages : 22 Date : 2011-1-27 This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-lsp-ping-02.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-mpls-return-path-specified-lsp-ping-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-27121447.I-D@ietf.org> --NextPart-- From lmartini@cisco.com Thu Jan 27 15:06:07 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFA93A6A93 for ; Thu, 27 Jan 2011 15:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBUq+s5VacuC for ; Thu, 27 Jan 2011 15:06:07 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by core3.amsl.com (Postfix) with ESMTP id 0EFF33A69F1 for ; Thu, 27 Jan 2011 15:06:06 -0800 (PST) Received: from seven.monoski.com ([128.107.115.247]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p0RN91lI003588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 16:09:03 -0700 (MST) Message-ID: <4D41FB08.9050503@cisco.com> Date: Thu, 27 Jan 2011 16:08:56 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sami Boutros Subject: [mpls] Problem in IANA consideration section of draft-ietf-mpls-ldp-p2mp-12.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 23:06:08 -0000 WG, In this document the following section : "12. IANA considerations This document creates a new name space (the LDP MP Opaque Value Element type) that is to be managed by IANA, and the allocation of the value 1 for the type of Generic LSP Identifier. " Can someone please update the document , and clearly specify the name of the namespace , and the values allocation policy ? Thanks. Luca From ice@cisco.com Thu Jan 27 23:44:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305313A6BA3 for ; Thu, 27 Jan 2011 23:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBckCohSIyLD for ; Thu, 27 Jan 2011 23:44:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0A8FA3A6B98 for ; Thu, 27 Jan 2011 23:44:26 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0S7cZhL002084 for ; Fri, 28 Jan 2011 08:38:35 +0100 (CET) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0S7cYaC023455; Fri, 28 Jan 2011 08:38:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: <4D41FB08.9050503@cisco.com> Date: Fri, 28 Jan 2011 08:38:34 +0100 Content-Transfer-Encoding: 7bit Message-Id: <54725A12-8D1D-4DC4-BE3D-DB1AA4512FFD@cisco.com> References: <4D41FB08.9050503@cisco.com> To: Luca Martini X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, Sami Boutros Subject: Re: [mpls] Problem in IANA consideration section of draft-ietf-mpls-ldp-p2mp-12.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 07:44:28 -0000 Hi Luca, It will be in the next revision of the draft. Thx, Ice. On 28 Jan 2011, at 00:08, Luca Martini wrote: > WG, > > In this document the following section : > > "12. IANA considerations > > This document creates a new name space (the LDP MP Opaque Value > Element type) that is to be managed by IANA, and the allocation of > the value 1 for the type of Generic LSP Identifier. > " > > > Can someone please update the document , and clearly specify the name > of the namespace , and the values allocation policy ? > > Thanks. > Luca > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From ben@niven-jenkins.co.uk Fri Jan 28 03:57:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E423A67F6; Fri, 28 Jan 2011 03:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjaxLSGk--2i; Fri, 28 Jan 2011 03:57:41 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 6B4C13A67C0; Fri, 28 Jan 2011 03:57:41 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pin0P-0005t8-QT; Fri, 28 Jan 2011 12:00:46 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <00bc01cbb1c9$8ceac4d0$790c7c0a@china.huawei.com> Date: Fri, 28 Jan 2011 12:00:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002901cbadf8$66783640$790c7c0a@china.huawei.com> <20110107112641.GA20790@cisco.com> <014901cbaebf$4fc5f0f0$790c7c0a@china.huawei.com> <9BCECFE9-04D8-4E8F-A01A-55D76C0E64C9@niven-jenkins.co.uk> <009501cbb0e3$665cbe90$790c7c0a@china.huawei.com> <48AA81F4-C02E-48F5-95BF-0159CFAB682C@niven-jenkins.co.uk> <00bc01cbb1c9$8ceac4d0$790c7c0a@china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: mpls-tp@ietf.org, mpls@ietf.org Subject: Re: [mpls] [mpls-tp] Questions on "draft-ietf-mpls-loss-delay-00" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 11:57:43 -0000 Linda, On 11 Jan 2011, at 19:55, Linda Dunbar wrote: > Ben and colleagues: >=20 > You said " But you suggest edit does not suggest a slower transmission = rate it states the querier should stop transmission", >=20 > Two comments: >=20 > 1. I think =93slower transmission rate by querier=94 should be = included in the text. >=20 So the model would be that a querier starts with a slow transmission = rate and they increase its transmission rate to the actual desired = transmission rate over time? I don't see the need for that. Your concerns that lead to wanting such behaviour (if I have understood = them correctly) are: 1) There is a processing cost on the receiver and that cost may be too = high for a given receiver (e.g. rate is faster than it supports) 2) The sender may waste resources counting before the receiving end is = ready. (1) is common in a number of situations (e.g. control packets that need = to be sent to a central CPU and therefore take a slow path through a = router) and is generally dealt with by applying a rate limit on that = particular traffic on the slow path. I'd argue such an approach is = sufficient for LM. (2) is a local implementation decision on the querier so let's not bog = the document down with implementation specifics. I would therefore suggest the following: When initiating an LM operation, the far end may require a period of = time to become ready for the requested measurement operation or the far = end may not be able to support the requested measurement. Under those = circumstances, LM queries MAY simply be discarded, and the querier = expecting a response SHOULD be prepared for this situation. = Alternatively, the receiver MAY respond, possibly in a rate-limited = manner, to queries received during this period with an appropriate = notification code. The querier should abort the measurement after not = receiving any positive feedback when a specified timer expires. =20 Your proposed text for 2.7.10 on LM interval looks OK to me. Ben > 2. I suggested that querier may choose not starting counting (not = transmission) until a positive feedback from Far End has been received. >=20 >=20 > Based on the discussion over this email thread, do people think the = following text is more appropriate? >=20 >=20 > When initiating an LM operation, the far end may require a period of = time to become ready for the requested measurement operation or the far = end may not be able to support the requested measurement. During this = period Under those circumstances, LM queries MAY simply be discarded, = and the querier expecting a response SHOULD be prepared for this = situation. The frequency of the initial LM for requesting starting the = measurement should be slow, so that there is enough time for far end to = check if the requested measurement can be done. The querier should abort = the measurement after not receiving any positive feedback when a = specified timer expires. setting a timer to differentiate between an = acceptable initialization delay and a permanent unavailability condition = at the far end. Alternatively, the receiver MAY respond, possibly in a = rate-limited manner, to queries received during this period with an = appropriate notification code. Since counting transmitted packets at = querier side will cost extra resources (or is not free), the querier = doesn=92t need to start counting its transmitted packets until receiving = a positive feedback from the far-end. >=20 >=20 >=20 > Suggested text for LM/DM Interval: >=20 >=20 > 2.7.10: LM Interval >=20 >=20 > The interval may affect the accuracy of the packet loss count. =46rom = implementation point of view, the shorter the interval, the higher the = processing cost to equipment. Querier should encode its intended = interval in its LM Message. If the interval specified by the LM message = can=92t be supported by the far end, the far end can simply ignore the = LM requests by not responding anything or respond with an appropriate = notification code indicating its minimum allowed LM interval. =20 >=20 >=20 > In the Section 3.1 LM Message Format, add an 8 (or 16) bits field for = LM Interval. The Interval Unit should be in ms. >=20 >=20 > Linda Dunbar >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Monday, January 10, 2011 11:29 AM > To: Linda Dunbar > Cc: 'Greg Mirsky'; mpls@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [mpls] Questions on = "draft-ietf-mpls-loss-delay-00" >=20 > Linda, >=20 > On 10 Jan 2011, at 16:28, Linda Dunbar wrote: >=20 > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >=20 > > >=20 > > 1) The edits suggested by Linda change the semantics from suggesting = a querier maintain a timer to allow for the receiving end to "get its = act together" to if the receiving end doesn't get its act together = within X packets stop sending LM. Is that really what's intended? I = would expect the time taken for the receiving end "to get its act = together" would not be a function of the LM transmission rate and = therefore using transmission rate to guess whether the receiving end is = dead Vs getting itself ready doesn't sound sensible. >=20 > > >=20 > > >=20 > > [Linda] The reason for suggesting Initiator to have slower = transmission rate is to minimize processing needed at the Initiator = before Far End committing to the counting. >=20 > > >=20 > But you suggest edit does not suggest a slower transmission rate it = states the querier should stop transmission! >=20 > > We have considered implementing this feature on our products and = discovered that it DOES take some time for the Central CPU to receive = the Counting Request (as LM in this draft), check if the requested = Counting can be supported, pass the request to the corresponding line = card, and get confirmation from the Line card. Sometimes, the Far End = can't perform the requested Counting because it is performing counting = for requests from other nodes. >=20 > > >=20 > I accept that a receiver may take some time to configure itself for = counting and that the time it takes may be a function of other things it = is doing. What I am saying is that the time it takes is never a function = of the interval being configured. >=20 > > 2) I don't like the final sentence suggesting queriers should delay = counting transmitted packets until receiving a positive response because = doing so costs resources. It sounds like an internal implementation = decision that has nothing to do with interoperability and therefore = irrelevant. >=20 > > >=20 > > >=20 > > [Linda]I agree with your point that that the Source Node performing = or not performing the counting before receiving the positive feedback = from Far End is not interoperability issue. Maybe it can be a = recommendation? >=20 > > >=20 > > But it is necessary for Source node to abort the effort after not = receiving the positive feedback after sometime (like X number of LM or = timer expires). >=20 > > >=20 > At some point, if the querier has not received a positive response it = must abort the operation. The original text suggest maintaing a timer. = Your edit suggested making ti a function of packets sent. I am saying = the former seems more sensible than the latter to me. >=20 > > 4) Giving the receiving end the opportunity to reply with "I can;t = support the rate you're asking for it's too fast for me" sounds = attractive but I am not sure it is in practice if one thinks how such = functionality is likely to be used. If an operator is going to turn it = on with the thinking that performing LM of some sort is important = regardless of the LM interval then negotiating a shorter interval may = have value. However I don't expect that to be the case. I would expect = an operator to pre-plan what interval they need given their knowledge of = their network and the accuracy they desire, having the network change = that may well cause unexpected consequences. In such a scenario I think = it's better to let the receiver "hard fail" and the operator can = investigate rather than have the network re-configure and the = re-configuration go unnoticed, after all LM failing does not impact the = ability of the network to actually forward packets. >=20 > > >=20 > > >=20 > > [Linda] Do you mean that Receiver can ignore the LMs if the Interval = specified in the message is more than it can handle? >=20 > That is one option. >=20 > The background to my thinking is: >=20 > I assume that LM will be turned on explicitly (i.e. it will not be on = by default) >=20 > I assume that LM is turned on for a reason, e.g. because an operator = needs to support an SLA involving packet loss. >=20 > The interval may affect the accuracy of the packet loss count. >=20 > I expect operators would rather LM "hard fail" rather than have the = network re-configure automatically to a different interval because an = SLA calculation (or whatever else is relying on the LM) could become = inaccurate and no-one would know unless they really dug deep into what = the network was doing. >=20 > The network re-configuring itself in order to repair itself so it can = continue to forward packets is one thing. >=20 > The network reconfiguring non-forwarding related features itself = because it believes it knows what to do better than the person who = designed & configured it could lead to all sorts of trouble in the field = IMO. >=20 > Ben >=20 > =20 >=20 From Internet-Drafts@ietf.org Sat Jan 29 21:00:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277823A6B07; Sat, 29 Jan 2011 21:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apdkNn+nTUPw; Sat, 29 Jan 2011 21:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001A23A6B02; Sat, 29 Jan 2011 21:00:01 -0800 (PST) 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.11 Message-ID: <20110130050001.30284.22021.idtracker@localhost> Date: Sat, 29 Jan 2011 21:00:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-lsp-ping-enhanced-dsmap-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 05:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Mechanism for performing LSP-Ping over MPLS tunnels Author(s) : N. Bahadur, et al. Filename : draft-ietf-mpls-lsp-ping-enhanced-dsmap-08.txt Pages : 22 Date : 2011-01-29 This document describes methods for performing lsp-ping traceroute over mpls tunnels and for traceroute of stitched mpls LSPs. The techniques outlined in RFC 4379 are insufficient to perform traceroute FEC validation and path discovery for a LSP that goes over other mpls tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-08.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-mpls-lsp-ping-enhanced-dsmap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-29205726.I-D@ietf.org> --NextPart-- From Adrian.Farrel@huawei.com Mon Jan 31 04:46:19 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC9B3A6BEC; Mon, 31 Jan 2011 04:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s71+ngA3MBkK; Mon, 31 Jan 2011 04:46:18 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0737B3A6BF0; Mon, 31 Jan 2011 04:46:18 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFW002UP0YJHX@usaga01-in.huawei.com>; Mon, 31 Jan 2011 04:49:32 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFW00GBZ0YHV7@usaga01-in.huawei.com>; Mon, 31 Jan 2011 04:49:31 -0800 (PST) Date: Mon, 31 Jan 2011 12:49:30 +0000 From: Adrian Farrel To: statements@ietf.org, greg.jones@itu.int Message-id: <053201cbc145$4ec727d0$ec557770$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcvBRUUBwyLJKIqtQ8+sYanHj6pLeA== Cc: itu-t-liaisons@iab.org, pce@ietf.org, 'CCAMP' , mpls@ietf.org Subject: [mpls] Liaison to SG15 : Comments on SG15 OTNT standardization work plan X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:46:19 -0000 From: IETF To: ITU-T SG15 (Attention Q3/15) Point of Contact: Greg Jones (greg.jones@itu.int) Cc: Yoshinori Koike (koike.yoshinori@lab.ntt.co.jp) CCAMP Working Group (ccamp@ietf.org) PCE Working Group (pce@ietf.org) MPLS Working Group (mpls@ietf.org) IETF ITU-T Liaisons (itu-t-liaisons@iab.org) Reply To: Adrian Farrel