From nobody Tue Jul 1 09:08:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344C11A0387 for ; Tue, 1 Jul 2014 09:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5f-5ZpvXRYL for ; Tue, 1 Jul 2014 09:08:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0494D1A0386 for ; Tue, 1 Jul 2014 09:08:11 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB093.namprd05.prod.outlook.com (10.242.38.13) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 1 Jul 2014 16:08:09 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.172]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.172]) with mapi id 15.00.0969.007; Tue, 1 Jul 2014 16:08:08 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Ross Callon , "Aissaoui, Mustapha (Mustapha)" , "jeremy.whittaker@verizon.com" , Harish Sitaraman , Kapil Arora Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAK1repg Date: Tue, 1 Jul 2014 16:08:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(189002)(199002)(377454003)(77096002)(21056001)(85306003)(99286002)(95666004)(50986999)(76176999)(54356999)(4396001)(79102001)(76482001)(76576001)(46102001)(77982001)(19580405001)(83322001)(15975445006)(19580395003)(15202345003)(81542001)(64706001)(80022001)(20776003)(66066001)(86362001)(106356001)(101416001)(85852003)(87936001)(2656002)(83072002)(74316001)(74662001)(105586002)(74502001)(81342001)(33646001)(107046002)(99396002)(55754002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB093; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_e02e587f33fd46b3b27bf917b809e28fBY2PR05MB079namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/hXjulo_wGa1PZP30XN08qTiw10c Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 16:08:15 -0000 --_000_e02e587f33fd46b3b27bf917b809e28fBY2PR05MB079namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed the draft and believe it is ready for WG adoption considera= tion. I do have one suggestion - could we allow multiple return paths to be speci= fied via multiple "Replay Mode 5" in the new "Reply Mode Order TLV" and mul= tiple Reply Path TLVs (currently it is not allowed). Thanks. Jeffrey _____________________________________________ From: Ross Callon Sent: Tuesday, June 17, 2014 4:52 PM To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); jeremy.wh= ittaker@verizon.com Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls-= chairs@tools.ietf.org; Martin Vigoureux Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simpl= e-02 Jeff, Mustapha, Jeremy; You have been selected as MPLS Review team reviewers for draft-akiya-= mpls-lsp-ping-reply-mode-simple-02. Note to authors: You have been CC'd on this email so that you can kno= w that this review is going on. However, please do not review your own docu= ment. Also please don't update the draft while the reviews are in progress = (we would like the reviewers to all review the same version). Reviews should comment on whether the document is coherent, is it use= ful (ie, is it likely to be actually useful in operational networks), and i= s the document technically sound? Also, is the text and grammar understand= able (it doesn't need to be perfect at this point, but should be reasonably= clear). We are interested in knowing whether the document is ready to be c= onsidered for WG adoption (ie, it doesn't have to be perfect at this point,= but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG s= ecretary, and CC'd to the MPLS WG email list. If necessary, Comments may be= sent privately to only the WG chairs. Are you able to review this draft by July 2, 2014? Thanks, Ross (as MPLS WG chair) --_000_e02e587f33fd46b3b27bf917b809e28fBY2PR05MB079namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have reviewed the draft and believe it is re= ady for WG adoption consideration.
 
I do have one suggestion – could we allo= w multiple return paths to be specified via multiple “Replay Mode 5&#= 8221; in the new “Reply Mode Order TLV”= and multiple Reply Path TLVs (currently it is not allowed).
 
Thanks.
Jeffrey=
_________________________________________= ____
From: Ross Callon
Sent: Tuesday, June 17, 2014 4:52 PM
To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); jeremy.w= hittaker@verizon.com
Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls= -chairs@tools.ietf.org; Martin Vigoureux
Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simp= le-02
 
 
Jeff, Mustapha, Jeremy;
 
You have been selected as MPLS Review tea= m reviewers for draft-akiya-mpls-lsp-ping-reply-mode-simple-02.
 
Note to authors: You have been CC'd on th= is email so that you can know that this review is going on. However, please= do not review your own document. Also please don’t update the draft = while the reviews are in progress (we would like the reviewers to all review the same version).
 
Reviews should comment on whether the doc= ument is coherent, is it useful (ie, is it likely to be actually useful in = operational networks), and is the document technically sound?  Also, i= s the text and grammar understandable (it doesn't need to be perfect at this point, but should be reasonably clear). = We are interested in knowing whether the document is ready to be considered= for WG adoption (ie, it doesn't have to be perfect at this point, but shou= ld be a good start).
 
Reviews should be sent to the document au= thors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. I= f necessary, Comments may be sent privately to only the WG chairs.
 
Are you able to review this draft by July= 2, 2014?
 
Thanks, Ross
(as MPLS WG chair)
 
--_000_e02e587f33fd46b3b27bf917b809e28fBY2PR05MB079namprd05pro_-- From nobody Tue Jul 1 11:19:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55F1B288C; Tue, 1 Jul 2014 11:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3b52wmQPXXe; Tue, 1 Jul 2014 11:19:06 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0907E1B2891; Tue, 1 Jul 2014 11:19:04 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-9c-53b2a7513929 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EF.8A.25146.157A2B35; Tue, 1 Jul 2014 14:19:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 14:19:02 -0400 From: Gregory Mirsky To: "mpls@ietf.org" , "rtg-bfd@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYg Date: Tue, 1 Jul 2014 18:19:01 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> In-Reply-To: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPuG7g8k3BBr/WKlrcWrqS1eLzn22M DkweS5b8ZApgjOKySUnNySxLLdK3S+DK2NJ3la1gj3DF8U372RoY/wh1MXJySAiYSLRtWMEI YYtJXLi3nq2LkYtDSOAoo8SNB13sIAkhgWWMEl8O54HYbAJGEi829oDFRQS8JJrmPAVrFhYI lFi2/w8TRDxIYuHCXjYI20hiydzXLCA2i4CKxMYr11hBbF4BX4m71x+zQMy3l3g/swmsnlPA QeLkiXPMIDYj0EHfT60Bm8ksIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaU2Nc/Heg2DqB6 TYn1u/QhWhUlpnQ/ZIdYKyhxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMXKUFqeW5aYbGW5i BIb/MQk2xx2MCz5ZHmIU4GBU4uFVMN0YLMSaWFZcmXuIUZqDRUmcV7N6XrCQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxtbHyr6/OG4fM/9wc1L3XQ7vW0app72DEia6lh8pZN50rciqVPak PF+B7f6vrkIzzGYw6n//bqI3L6HF8w7/2rCevs27Lc6/FJhdE2/7f2rcrc4zegnl3Q8Lo9Ml 20LWMokHTvp2t99c+YXZEYbc7mMZMQf/TGerZTnt9HWSpYfB3ud2Ze3blViKMxINtZiLihMB Ih6NuWACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-yrdQ9KHVXnlmKeu5NJy4duRi7E Subject: [mpls] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:19:08 -0000 RGVhciBBbGwsDQp3ZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQuIExTUCBQaW5nIGFscmVhZHkgaXMg dXNlZCB0byBib290c3RyYXAgYSBCRkQgc2Vzc2lvbiB3aXRoIEJGRCBEaXNjcmltaW5hdG9yIFRM Vi4gQSBuZXcgQkZEIFJldmVyc2UgUGF0aCBUTFYgaXMgaW50cm9kdWNlZCBpbiBvcmRlciB0byBp bnN0cnVjdCBhIGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHBhcnRpY3VsYXIgcGF0aCBmb3IgcmV2 ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9uLiANCg0KR3JlYXRseSBhcHByZWNpYXRl IHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cy4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bmUgMzAsIDIw MTQgNDoxNSBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBJbHlhIFZhcmxhc2hraW47IEplZmYgVGFu dHN1cmE7IEdyZWdvcnkgTWlyc2t5OyBKZWZmIFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1wbHMtYmZk LWRpcmVjdGVkLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3kt bXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KUmV2aXNpb246CTAwDQpUaXRsZToJ CUJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGlyZWN0ZWQgUmV0dXJu IFBhdGgNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDYtMzANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMA0KDQoNCkFic3RyYWN0Og0K ICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBpcyBleHBlY3RlZCB0 byBtb25pdG9yIGJpLQ0KICAgZGlyZWN0aW9uYWwgcGF0aHMuICBXaGVuIGZvcndhcmQgZGlyZWN0 aW9uIG9mIGEgQkZEIHNlc3Npb24gaXMgdG8NCiAgIG1vbml0b3IgZXhwbGljaXRseSByb3V0ZWQg cGF0aCB0aGVyZSBpc1wgYSBuZWVkIHRvIGJlIGFibGUgdG8gZGlyZWN0DQogICBmYXItZW5kIEJG RCBwZWVyIHRvIHVzZSBzcGVjaWZpYyBwYXRoIGFzIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBC RkQNCiAgIHNlc3Npb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jul 1 11:48:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394771B27F3 for ; Tue, 1 Jul 2014 09:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKL2tquqoN8P for ; Tue, 1 Jul 2014 09:41:41 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7CE1A0527 for ; Tue, 1 Jul 2014 09:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=jeremy.whittaker@verizon.com; q=dns/txt; s=corp; t=1404232901; x=1435768901; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version; bh=iCbV1KbdjdxHUh4R39miAMEkbeEgDM07+8lWi78OqZI=; b=GaObtdjddNb8s2ehhkimcTSs3y3szH4/zdrivmPXDLlV0aKvx3Dv/VAu qVlV+ItFpSOjrpY9vOHgjiXrnuQeCy0I5dZV8jv6vWcfBYgXjC2LUYk4h VLDgZ3sJSoTllxQFZpr+uV35my/68UnBVD+LpLpNnLopUz/GpyfgqdWyv Y=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 01 Jul 2014 16:41:40 +0000 From: "Whittaker, Jeremy M" X-IronPort-AV: E=Sophos;i="5.01,582,1400025600"; d="scan'208,217";a="788626131" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi01.verizon.com with ESMTP; 01 Jul 2014 16:41:40 +0000 Received: from FHDP1LUMXC7V32.us.one.verizon.com ([166.68.125.33]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Tue, 1 Jul 2014 12:41:40 -0400 To: "Jeffrey (Zhaohui) Zhang" , Ross Callon , "Aissaoui, Mustapha (Mustapha)" , Harish Sitaraman , Kapil Arora Date: Tue, 1 Jul 2014 12:41:38 -0400 Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAK1repgAAF2lXA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F312D51FDA29C84E96CFF955523C124B0152D726B7FHDP1LUMXC7V3_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LFHq2xopwMNCZLUf7N8a_v6T1y4 X-Mailman-Approved-At: Tue, 01 Jul 2014 11:48:39 -0700 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 16:41:44 -0000 --_000_F312D51FDA29C84E96CFF955523C124B0152D726B7FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have also reviewed this draft, and in my opinion it is coherent and usefu= l. One additional suggestion is that the reverse LSP sections (3.1 and 6.1) mi= ght benefit from more explanation of the LSP types included or not included= . Nevertheless, I would recommend it move forward as well. Regards, Jeremy Whittaker From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, July 01, 2014 11:08 AM To: Ross Callon; Aissaoui, Mustapha (Mustapha); Whittaker, Jeremy M; Harish= Sitaraman; Kapil Arora Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls-chairs= @tools.ietf.org; Martin Vigoureux; mpls@ietf.org Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-= 02 I have reviewed the draft and believe it is ready for WG adoption considera= tion. I do have one suggestion - could we allow multiple return paths to be speci= fied via multiple "Replay Mode 5" in the new "Reply Mode Order TLV" and mul= tiple Reply Path TLVs (currently it is not allowed). Thanks. Jeffrey _____________________________________________ From: Ross Callon Sent: Tuesday, June 17, 2014 4:52 PM To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); jeremy.whittake= r@verizon.com Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls-chairs@tools.i= etf.org; Martin Vigoureux Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Jeff, Mustapha, Jeremy; You have been selected as MPLS Review team reviewers for draft-akiya-mpls-l= sp-ping-reply-mode-simple-02. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. = Also please don't update the draft while the reviews are in progress (we wo= uld like the reviewers to all review the same version). Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? Also, is the text and grammar understandable (= it doesn't need to be perfect at this point, but should be reasonably clear= ). We are interested in knowing whether the document is ready to be conside= red for WG adoption (ie, it doesn't have to be perfect at this point, but s= hould be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, Comments may be sent = privately to only the WG chairs. Are you able to review this draft by July 2, 2014? Thanks, Ross (as MPLS WG chair) --_000_F312D51FDA29C84E96CFF955523C124B0152D726B7FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have al= so reviewed this draft, and in my opinion it is coherent and useful.  =

 <= /p>

One additional suggestion is that the revers= e LSP sections (3.1 and 6.1) might benefit from more explanation of the LSP= types included or not included.  Nevertheless, I would recommend it m= ove forward as well.

 

Regards,

Jeremy Whittaker<= /p>

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper= .net]
Sent: Tuesday, July 01, 2014 11:08 AM
To: Ross C= allon; Aissaoui, Mustapha (Mustapha); Whittaker, Jeremy M; Harish Sitaraman= ; Kapil Arora
Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@too= ls.ietf.org; mpls-chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.orgSubject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode= -simple-02

 = ;

I have reviewed the draft and b= elieve it is ready for WG adoption consideration.

 

<= p class=3DMsoNormal>I do have one suggestion – could we allow = multiple return paths to be specified via multiple “Replay Mode 5R= 21; in the new “Reply Mode Order TLV” and multipl= e Reply Path TLVs (currently it is not allowed).<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>

 

Thanks.

Jeffrey=

___________________________________= __________
From: Ross Callon
Sent: Tuesday, June 17, 2= 014 4:52 PM
To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Must= apha); jeremy.whittaker@ver= izon.com
Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@t= ools.ietf.org; mpls-chair= s@tools.ietf.org; Martin Vigoureux
Subject: MPLS-RT review of= draft-akiya-mpls-lsp-ping-reply-mode-simple-02

=

 

&nb= sp;

Jeff, Mustapha, Jeremy;

 

You have been selected as MPLS Review team reviewers= for draft-akiya-mpls-lsp-ping-reply-mode-simple-02.

<= /div>

 

Note to authors: You have been CC'd on this email so that you can know th= at this review is going on. However, please do not review your own document= . Also please don’t update the draft while the reviews are in progres= s (we would like the reviewers to all review the same version).<= /span>

 

<= p class=3DMsoNormal>Reviews should comment on whether the document is coherent, is= it useful (ie, is it likely to be actually useful in operational networks)= , and is the document technically sound?  Also, is the text and gramma= r understandable (it doesn't need to be perfect at this point, but should b= e reasonably clear). We are interested in knowing whether the document is r= eady to be considered for WG adoption (ie, it doesn't have to be perfect at= this point, but should be a good start).

<= p class=3DMsoNormal> 

Reviews s= hould be sent to the document authors, WG co-chairs and WG secretary, and C= C'd to the MPLS WG email list. If necessary, Comments may be sent privately= to only the WG chairs.

 = ;

Are you able to review this= draft by July 2, 2014?

 = ;

Thanks, Ross

(as MPLS WG chair)

 

= --_000_F312D51FDA29C84E96CFF955523C124B0152D726B7FHDP1LUMXC7V3_-- From nobody Tue Jul 1 17:58:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2E1B27B6 for ; Tue, 1 Jul 2014 17:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGxSBtT-_1jw for ; Tue, 1 Jul 2014 17:58:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88561B27B4 for ; Tue, 1 Jul 2014 17:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4243; q=dns/txt; s=iport; t=1404262685; x=1405472285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mIPvYaSZ/qH0OxVOFJd72pMtIHFXluALccq1c2W3SWc=; b=VYcFXZJxaakLiDn2QtgUkXkMwjRvDwcefK2h/d/SchqI6nMCrlUk0cMb 5RLD1oy8m6OUEWS4NAyyuKtaF5cvOb/7E4Su60hfidK/YcAdkEGRWGHcj aqIVEbDXT5BAnSnJWPzVkFtEN4eH1FuAZ8ojbIvFjJYfXnZxr+xG9TUP4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAK1Ys1OtJV2a/2dsb2JhbABagmkkgSzGCwGBEBZ1hAMBAQEDASdSBQcEAgEIEQQBAQsdBzIUCQgCBAENBQiIJgMJCAHFFBeMeIFFEQEfMQcGgyeBFgEEihCMP5gag0KBdzk X-IronPort-AV: E=Sophos;i="5.01,585,1400025600"; d="scan'208";a="336929379" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jul 2014 00:58:05 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s620w42F014163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 00:58:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 19:58:03 -0500 From: "Nobo Akiya (nobo)" To: "Jeffrey (Zhaohui) Zhang" , Ross Callon , "Aissaoui, Mustapha (Mustapha)" , "jeremy.whittaker@verizon.com" , Harish Sitaraman , Kapil Arora Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPlUa95Ejp2shyyECvEuCXXDZC9JuL84fA Date: Wed, 2 Jul 2014 00:58:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JxRwK7lO8u8pF1Q00yeiYLM2u3s Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 00:58:14 -0000 Hi Jeffrey, Thank you for reviewing this document. > I do have one suggestion - could we allow multiple return paths to be > specified via multiple "Replay Mode 5" in the new "Reply Mode Order TLV" > and multiple Reply Path TLVs (currently it is not allowed). Interesting, I do find what you suggested to be useful. I went back to RFC7= 110 and read up on the Reply Path TLV definition. The TLV can contain zero,= one or more FECs. Reply Path: It is used to describe the return path that an echo reply will be send along. It is variable in length and can contain zero, one or more Target FEC sub-TLVs [RFC4379]. =20 So it appears that "Reply Mode 5" can be one of the entries in the "Reply M= ode Order TLV", and "Reply Path TLV" can contain multiple FECs. (1) What is possible as is: Pref#1: Reply Mode 4 Reply via application level control channel Pref#2a: Reply Mode 5 Reply via Specified Path -> First FEC listed Pref#2b: Reply Mode 5 Reply via Specified Path -> Second FEC listed Pref#3: Reply Mode 2 Reply via an IPv4/IPv6 UDP packet (2) What is not possible as is: Pref#1: Reply Mode 4 Reply via application level control channel Pref#2: Reply Mode 5 Reply via Specified Path -> First FEC listed Pref#3: Reply Mode 2 Reply via an IPv4/IPv6 UDP packet Pref#4: Reply Mode 5 Reply via Specified Path -> Second FEC listed Granularity of really mixing up Reply Modes and return FECs like (2) cannot= be accomplished, but I'm not sure if we need such granularity and I believ= e (1) is reasonable. If you are ok with this, then I think it's worth addin= g texts to describe this usages. Do let us know you preference. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) > Zhang > Sent: Tuesday, July 01, 2014 12:08 PM > To: Ross Callon; Aissaoui, Mustapha (Mustapha); > jeremy.whittaker@verizon.com; Harish Sitaraman; Kapil Arora > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-akiya-mpls-lsp-ping- > reply-mode-simple@tools.ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply- > mode-simple-02 >=20 > I have reviewed the draft and believe it is ready for WG adoption > consideration. >=20 > I do have one suggestion - could we allow multiple return paths to be > specified via multiple "Replay Mode 5" in the new "Reply Mode Order TLV" > and multiple Reply Path TLVs (currently it is not allowed). >=20 > Thanks. > Jeffrey > _____________________________________________ > From: Ross Callon > Sent: Tuesday, June 17, 2014 4:52 PM > To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); > jeremy.whittaker@verizon.com > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; Martin Vigoureux > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple- > 02 >=20 >=20 > Jeff, Mustapha, Jeremy; >=20 > You have been selected as MPLS Review team reviewers for draft-akiya- > mpls-lsp-ping-reply-mode-simple-02. >=20 > Note to authors: You have been CC'd on this email so that you can know th= at > this review is going on. However, please do not review your own document. > Also please don't update the draft while the reviews are in progress (we > would like the reviewers to all review the same version). >=20 > Reviews should comment on whether the document is coherent, is it useful > (ie, is it likely to be actually useful in operational networks), and is = the > document technically sound?=A0 Also, is the text and grammar understandab= le > (it doesn't need to be perfect at this point, but should be reasonably cl= ear). > We are interested in knowing whether the document is ready to be > considered for WG adoption (ie, it doesn't have to be perfect at this poi= nt, > but should be a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, Comments may > be sent privately to only the WG chairs. >=20 > Are you able to review this draft by July 2, 2014? >=20 > Thanks, Ross > (as MPLS WG chair) >=20 From nobody Tue Jul 1 18:31:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0861B27A5 for ; Tue, 1 Jul 2014 18:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaP4Mz0IhM3B for ; Tue, 1 Jul 2014 18:31:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173B61B27A0 for ; Tue, 1 Jul 2014 18:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3828; q=dns/txt; s=iport; t=1404264675; x=1405474275; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0qlRp3VJlNXotksOMvujZZQ0DgqZSu5rGrmyFaF+s/Y=; b=FUxiPhtrWqaNgV3UksppvGJlG1d5xW6f+JccbV73Tje6LQrrP5fMs57y jj1KfcjxbhWeljXfuEJyijyUi4YpLZhl+qbFPt9/OCHyFighzQFToVI+R IcSzplV+sJUtxxoihwu/hlwBdW9p2IJcANFR8bXUmlC6HHSZwRO2Nog6D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAGlgs1OtJV2d/2dsb2JhbABagmkkgSzGDAGBEBZ1hAMBAQEDAXkFBwQCAQgRBAEBCx0HMhQJCAIEAQ0FCIgmAwkIAcUVF4x4gUURAR8xBwaDJ4EWBYoQjD+YGoNCgXc5 X-IronPort-AV: E=Sophos;i="5.01,585,1400025600"; d="scan'208";a="337152751" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 02 Jul 2014 01:31:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s621VEJE031375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jul 2014 01:31:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 20:31:13 -0500 From: "Nobo Akiya (nobo)" To: "Whittaker, Jeremy M" , "Jeffrey (Zhaohui) Zhang" , Ross Callon , "Aissaoui, Mustapha (Mustapha)" , Harish Sitaraman , Kapil Arora Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPlUti1OENGA+t0ESUHzyMwGQ6BpuL9uUw Date: Wed, 2 Jul 2014 01:31:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qD9uCqlb7PvCMpQs9Kcciek-O-0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 01:31:17 -0000 Hi Jeremy, Thank you for reviewing this document. > One additional suggestion is that the reverse LSP sections (3.1 and 6.1) > might benefit from more explanation of the LSP types included or not > included. Nevertheless, I would recommend it move forward as well. Agree, that will improve the readability of this document. We certain do no= t want to list LSPs restrict the term "reverse LSP" to be applicable only f= or them, but we will list associated RSVP LSPs and TP LSPs as examples. Wou= ld this be ok with you? Thanks! -Nobo > -----Original Message----- > From: Whittaker, Jeremy M [mailto:jeremy.whittaker@verizon.com] > Sent: Tuesday, July 01, 2014 12:42 PM > To: Jeffrey (Zhaohui) Zhang; Ross Callon; Aissaoui, Mustapha (Mustapha); > Harish Sitaraman; Kapil Arora > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.org > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > simple-02 >=20 > I have also reviewed this draft, and in my opinion it is coherent and use= ful. >=20 > One additional suggestion is that the reverse LSP sections (3.1 and 6.1) > might benefit from more explanation of the LSP types included or not > included.=A0 Nevertheless, I would recommend it move forward as well. >=20 > Regards, > Jeremy Whittaker >=20 > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Tuesday, July 01, 2014 11:08 AM > To: Ross Callon; Aissaoui, Mustapha (Mustapha); Whittaker, Jeremy M; > Harish Sitaraman; Kapil Arora > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.org > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > simple-02 >=20 > I have reviewed the draft and believe it is ready for WG adoption > consideration. >=20 > I do have one suggestion - could we allow multiple return paths to be > specified via multiple "Replay Mode 5" in the new "Reply Mode Order TLV" > and multiple Reply Path TLVs (currently it is not allowed). >=20 > Thanks. > Jeffrey > _____________________________________________ > From: Ross Callon > Sent: Tuesday, June 17, 2014 4:52 PM > To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); > jeremy.whittaker@verizon.com > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; Martin Vigoureux > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple- > 02 >=20 >=20 > Jeff, Mustapha, Jeremy; >=20 > You have been selected as MPLS Review team reviewers for draft-akiya- > mpls-lsp-ping-reply-mode-simple-02. >=20 > Note to authors: You have been CC'd on this email so that you can know th= at > this review is going on. However, please do not review your own document. > Also please don't update the draft while the reviews are in progress (we > would like the reviewers to all review the same version). >=20 > Reviews should comment on whether the document is coherent, is it useful > (ie, is it likely to be actually useful in operational networks), and is = the > document technically sound?=A0 Also, is the text and grammar understandab= le > (it doesn't need to be perfect at this point, but should be reasonably cl= ear). > We are interested in knowing whether the document is ready to be > considered for WG adoption (ie, it doesn't have to be perfect at this poi= nt, > but should be a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and WG > secretary, and CC'd to the MPLS WG email list. If necessary, Comments may > be sent privately to only the WG chairs. >=20 > Are you able to review this draft by July 2, 2014? >=20 > Thanks, Ross > (as MPLS WG chair) >=20 From nobody Wed Jul 2 10:15:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06921A01BD; Wed, 2 Jul 2014 10:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_XYIWxZzWOx; Wed, 2 Jul 2014 10:15:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1BC1B284C; Wed, 2 Jul 2014 10:15:32 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-6c-53b3ec47dc74 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 76.87.05330.74CE3B35; Wed, 2 Jul 2014 13:25:59 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 13:15:24 -0400 From: Gregory Mirsky To: Mach Chen , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIA== Date: Wed, 2 Jul 2014 17:15:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPgq77m83BBs+W2VhcWCtscWvpSlaL z3+2MTowe7QcecvqsWTJT6YApigum5TUnMyy1CJ9uwSujCdT7rIXPJKvmNG4gb2B8YdcFyMn h4SAicSBu8sZIWwxiQv31rOB2EICRxklbr/0g7CXMUo8WisCYrMJGEm82NjDDmKLCLhKzNm4 mRXEZhbQlGg68RksLiwQKLGt8zIbRE2QxMKFvVC2k8TNS5PBbBYBFYlH3/rBbF4BX4mnH38A zeEC2nWeUWLq3UNggzgFwiT6Lx8AsxmBjvt+ag0TxDJxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/ rBC2osS+/ulAvRxgx63fpQ/RqigxpfshO8ReQYmTM5+wTGAUm4Vk6iyEjllIOmYh6VjAyLKK kaO0OLUsN93IYBMjMFKOSbDp7mDc89LyEKMAB6MSD++DfZuChVgTy4orcw8xSnOwKInzzqqd FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMWvXpU/WcyotqqKZPG+3d2jcNvC1/l9vcKWF QX7KeT3RTYH7V25u2fBaXc/Mt/vRrm2Z8hw8WtazFlk6feXZ06Cqmv/fy0JmxYFMrfIVn5yO 5rYVLM4KlhKJ9bbLe7dx0tWvU35wc/G59L9vN9LOmXnpysNH09/E73VhEHl0csMk+YTZhtPW K7EUZyQaajEXFScCADxjwSF1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/P8fZbOeI57B64wz9LrHzAX4NiJE Cc: "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:15:36 -0000 SGkgTWFjaCwNCnRoYW5rIHlvdSBmb3IgeW91ciBmZWVkYmFjay4NCkluZGVlZCwgYm90aCBkcmFm dHMgaGF2ZSBjb21tb25hbGl0aWVzLg0KSSdtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgZGlzY3Vz c2lvbiBpbiBUb3JvbnRvIGFuZCBob3cgd2UgY2FuIGJyaW5nIHRoaXMgaWRlYSBmdXJ0aGVyLg0K DQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21dIA0KU2VudDogVHVlc2RheSwg SnVseSAwMSwgMjAxNCA2OjU3IFBNDQpUbzogR3JlZ29yeSBNaXJza3kNCkNjOiBydGctYmZkQGll dGYub3JnDQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t aXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQoNCkhpIEdyZWcsDQoNCkkgaGF2ZSBhIHF1 aWNrIHJldmlldyBvbiB0aGUgZHJhZnQsIHdlbGwgd3JpdHRlbiBhbmQgdXNlZnVsIGRyYWZ0IQ0K DQpDb3VwbGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCAoaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtY2hlbi1tcGxzLWJmZC1lbmhhbmNlbWVudC0wMSkgdGhhdCBpbnRl bmQgdG8gc29sdmUgdGhlIHNpbWlsYXIgaXNzdWUsIGdsYWQgd2UgaGF2ZSB0aGUgc2ltaWxhciB0 aG91Z2h0Oi0pLg0KDQpJdCBhbHNvIGRlZmluZXMgZXh0ZW5zaW9ucyB0byBMU1AgUGluZyB0byBk aXJlY3QgdGhlIGNob29zZSBvZiB0aGUgcmV0dXJuIHBhdGggb2YgQkZEIGNvbnRyb2wgcGFja2V0 cy4gUGxlYXNlIHRha2UgYSBsb29rLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdvcnkgDQo+IE1pcnNreQ0KPiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMDIsIDIwMTQgMjoxOSBBTQ0KPiBUbzogbXBsc0BpZXRmLm9yZzsgcnRn LWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCj4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiANCj4gRGVhciBB bGwsDQo+IHdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdC4gTFNQIFBpbmcgYWxyZWFkeSBpcyB1c2Vk IHRvIGJvb3RzdHJhcCBhIEJGRCANCj4gc2Vzc2lvbiB3aXRoIEJGRCBEaXNjcmltaW5hdG9yIFRM Vi4gQSBuZXcgQkZEIFJldmVyc2UgUGF0aCBUTFYgaXMgDQo+IGludHJvZHVjZWQgaW4gb3JkZXIg dG8gaW5zdHJ1Y3QgYSBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSBwYXJ0aWN1bGFyIA0KPiBwYXRo IGZvciByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgQkZEIHNlc3Npb24uDQo+IA0KPiBHcmVhdGx5 IGFwcHJlY2lhdGUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLg0KPiANCj4gCVJlZ2FyZHMsDQo+ IAkJR3JlZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBT ZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgNDoxNSBQTQ0KPiBUbzogR3JlZ29yeSBNaXJza3k7 IElseWEgVmFybGFzaGtpbjsgSmVmZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJza3k7IA0KPiBKZWZm IFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCj4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiAN Cj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0 ZWQtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJz a3kgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlk cmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJ QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXJlY3RlZCBSZXR1cm4g UGF0aA0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA2LTMwDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQo+IFBhZ2VzOgkJOA0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC4NCj4gdHh0DQo+ IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwDQo+IA0KPiANCj4gQWJz dHJhY3Q6DQo+ICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMg ZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0NCj4gICAgZGlyZWN0aW9uYWwgcGF0aHMuICBXaGVuIGZv cndhcmQgZGlyZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gaXMgdG8NCj4gICAgbW9uaXRvciBleHBs aWNpdGx5IHJvdXRlZCBwYXRoIHRoZXJlIGlzXCBhIG5lZWQgdG8gYmUgYWJsZSB0byBkaXJlY3QN Cj4gICAgZmFyLWVuZCBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyByZXZlcnNlIGRp cmVjdGlvbiBvZiB0aGUgQkZEDQo+ICAgIHNlc3Npb24uDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiANCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Wed Jul 2 11:10:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3491B29F3; Wed, 2 Jul 2014 11:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-LFQYxzJG2M; Wed, 2 Jul 2014 11:10:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C22A81B29EC; Wed, 2 Jul 2014 11:10:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702181000.1341.72023.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 11:10:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/AQEg2bG9v7132dN2ZA80Dt9pJf4 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:10:02 -0000 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 : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-14.txt Pages : 42 Date : 2014-07-02 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 2 12:02:48 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C681B2A21 for ; Wed, 2 Jul 2014 12:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6OymgctpunH for ; Wed, 2 Jul 2014 12:02:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FBB1B2A31 for ; Wed, 2 Jul 2014 12:02:41 -0700 (PDT) Received: from BY2PR05CA006.namprd05.prod.outlook.com (10.242.32.36) by BL2PR05MB113.namprd05.prod.outlook.com (10.255.232.20) with Microsoft SMTP Server (TLS) id 15.0.980.8; Wed, 2 Jul 2014 19:02:39 +0000 Received: from BY2FFO11FD026.protection.gbl (2a01:111:f400:7c0c::144) by BY2PR05CA006.outlook.office365.com (2a01:111:e400:2c2a::36) with Microsoft SMTP Server (TLS) id 15.0.980.8 via Frontend Transport; Wed, 2 Jul 2014 19:02:39 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD026.mail.protection.outlook.com (10.1.15.215) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Wed, 2 Jul 2014 19:02:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 2 Jul 2014 12:02:37 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s62J2Un58570 for ; Wed, 2 Jul 2014 12:02:33 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201407021902.s62J2Un58570@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15271.1404327748.1@juniper.net> Date: Wed, 2 Jul 2014 12:02:29 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(37854004)(189002)(199002)(377424004)(97756001)(97736001)(99396002)(50986999)(64706001)(20776003)(47776003)(81156004)(106466001)(107046002)(46406003)(229853001)(107886001)(2351001)(54356999)(50466002)(92566001)(23726002)(74502001)(31966008)(4396001)(102836001)(16796002)(83072002)(85852003)(15202345003)(84676001)(79102001)(74662001)(92726001)(86362001)(80022001)(95666004)(21056001)(85306003)(87936001)(76482001)(77982001)(69596002)(81342001)(105596002)(44976005)(19580405001)(15975445006)(83322001)(81542001)(6806004)(19580395003)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB113; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0260457E99 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OCzqMYNDOtBxovr4PnzwBtWQl6A Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 19:02:44 -0000 Folks, The revised version (-14) reflects all the comments received during the WG LC. Yakov. ------- Forwarded Message Date: Wed, 02 Jul 2014 11:10:00 -0700 From: To: cc: Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-14.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 o f the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-14.txt Pages : 42 Date : 2014-07-02 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------- End of Forwarded Message From nobody Wed Jul 2 17:15:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A021A0AC7; Wed, 2 Jul 2014 17:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCH8HVUrJj9M; Wed, 2 Jul 2014 17:15:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFCA1A0AC6; Wed, 2 Jul 2014 17:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7386; q=dns/txt; s=iport; t=1404346510; x=1405556110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gBJBtnUfQSM1nPSg6a2HFOoHM9S0e/oSXTizf+q3+lY=; b=hDICCV7N3KNekAuXFsuPT4dTk2y8j96ZvJ9aUjq16bMnnQu3ITb1nIVe /6U950g/c/xCv/2l7dulqyR+CbQgZaU2fRzhQydbx/X6p3WkKGQp0PO5b LyC6NE7+srawWE66/JB733Ebm0Atg3Y6YLYMKLYg9CkV4CVYwCqlqtLM4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABagtFOtJA2I/2dsb2JhbABagmkkUlqCbsM1ARlwFnWEAwEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEICAIEAQ0FCAESiCcBDKtXnBEXgSyNRTEHBoJxNoEWBZZVhWCSQoNDgjA X-IronPort-AV: E=Sophos;i="5.01,591,1400025600"; d="scan'208";a="337366936" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2014 00:15:09 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s630F8YI019039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 00:15:09 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 19:15:08 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Mach Chen , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8Zg Date: Thu, 3 Jul 2014 00:15:08 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2djlcapk7-4v5ROp3h1lNRLna2w Cc: "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 00:15:12 -0000 SGkgR3JlZywgZXQgYWwsDQoNCkkgYWdyZWUgd2l0aCB0aGUgdG9waWMgYW5kIHVzZWZ1bG5lc3Mg b2YgY29udHJvbGxpbmcgdGhlIEJGRCByZXR1cm4gcGF0aCwgZXNwZWNpYWxseSBpbiBTZWdtZW50 IFJvdXRpbmcuDQoNCkEgcXVlc3Rpb24gYW5kIGNvdXBsZSBjb21tZW50cy4NCg0KT25lIHdheSB0 byBhY2hpZXZlIHRoZSBzYW1lIHNlbWF0aWMgaXMgdG8gaW50cm9kdWNlICJTZWdtZW50IFJvdXRp bmcgTVBMUyBUdW5uZWwgc3ViLVRMViIgYW5kICJTZWdtZW50IFJvdXRpbmcgSVB2NiBUdW5uZWwg c3ViLVRMViIgdW5kZXIgUmVwbHkgUGF0aCAoUlApIFRMViBkZWZpbmVkIGluIFJGQzcxMTAuIElz IHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgbmV3IFRMViB3YXMgaW50cm9kdWNlZD8g SSdtIG1haW5seSBqdXN0IGN1cmlvdXMgOikNCg0KVGhlcmUgYXJlIGNvdXBsZSBvZiB0aGluZ3Mg d29ydGggaGlnaGxpZ2h0aW5nIGFib3V0IHRoZSBCRkQgRGlzY3JpbWluYXRvciBUTFYgKGRlZmlu ZWQgaW4gUkZDNTg4NCksIG5vdCBkaXJlY3RseSBpbiB0aGUgc2NvcGUgb2YgeW91ciBkb2N1bWVu dCBidXQgdmVyeSByZWxldmFudCB3aGVuIGxvb2tpbmcgYXQgdXNpbmcgeW91ciBwcm9wb3NhbCBp biBTZWdtZW50IFJvdXRpbmcuDQoNCjEuIFRoZSBCRkQgRGlzY3JpbWluYXRvciBUTFYgYWxsb3dz IGJvb3RzdHJhcHBpbmcgb2Ygb25lIEJGRCBzZXNzaW9uIHBlciBGRUMuIFdoZW4gYm9vdHN0cmFw cGluZyBtb3JlIHRoYW4gb25lIEJGRCBzZXNzaW9uIHBlciBGRUMsIGl0IGlzIGRpZmZpY3VsdCB0 byBkbyBzbyB3aXRob3V0IG1ha2luZyBhc3N1bXB0aW9ucywgYXMgdGhlcmUgaXMgbm8gZGVmaW5l ZCBmaWVsZHMvcHJvY2VkdXJlcyB0byBkbyBzby4gVGhpcyB3aWxsIGJlY29tZSBtb3JlIG9mIGFu IGlzc3VlIHdpdGggU2VnbWVudCBSb3V0aW5nLCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBleHBs aWNpdCBwYXRocyBjcmVhdGVkIGJldHdlZW4gYSBwYWlyIG9mIG5vZGVzLg0KDQoyLiBNYWludGVu YW5jZSBvZiBib290c3RyYXBwZWQgQkZEIHNlc3Npb25zIGlzIGZ1enp5LCBtZWFuaW5nIHdoZW4g c2hvdWxkIHRoZSBlZ3Jlc3MgZGVsZXRlIGJvb3RzdHJhcHBlZCBCRkQgc2Vzc2lvbnMuIE9uZSBj b3VsZCBpbXBsZW1lbnQgc3VjaCB0aGF0IHRoZSBlZ3Jlc3MgZGVsZXRlcyBCRkQgc2Vzc2lvbnMg d2hlbiBjb3JyZXNwb25kaW5nIEZFQyBpcyBkZWxldGVkLCBvciBYIGFtb3VudCBvZiB0aW1lIGFm dGVyIHNlc3Npb25zIGdvICJkb3duIi4gVGhlcmUncyBubyBGRUMvc3RhdGUgb24gdGhlIGVncmVz cyBmb3IgU2VnbWVudCBSb3V0aW5nLiAgVGh1cyBvbmx5IHJlbWFpbmluZyBvcHRpb24gdG9kYXkg aXMgdG8gZGVsZXRlIHRoZSBzZXNzaW9uIGFmdGVyIFggc2Vjb25kcy9taW51dGVzIG9uY2UgdGhl IHNlc3Npb24gaXMgaW4gImRvd24iIHN0YXRlLiBQZXJoYXBzIHRoaXMgZnV6emluZXNzIGlzIHJl YXNvbmFibGUsIG9yIHBlcmhhcHMgd2Ugd2FudCBleHBsaWNpdCAiZGVsZXRlIiBpbnN0cnVjdGlv biBmcm9tIHRoZSBpbmdyZXNzIHRvIHRoZSBlZ3Jlc3MuDQoNCkkgYmVsaWV2ZSBteSBjb2xsZWFn dWUgaXMgYWJvdXQgdG8gcm9sbCBvdXQgYSBkb2N1bWVudCBmb3IgRXh0ZW5kZWQgQkZEIERpc2Ny aW1pbmF0b3IgVExWIHdoaWNoIGFkZHJlc3NlcyAoMSkgYW5kICgyKSBhYm92ZS4gUHJpbWFyeSBt b3RpdmF0aW9uIG9mIHRoYXQgZG9jdW1lbnQgaXMgRVZQTiBCRkQsIGJ1dCBpdCBsb29rcyB2ZXJ5 IGFwcGxpY2FibGUgdG8gU2VnbWVudCBSb3V0aW5nIGFzIHdlbGwuDQoNCkxhc3RseSwgaG93IGRv IHdlIHVzZSB0aGlzIGZvciBTLUJGRD8gOikNCg0KTGV0J3MgZGlzY3VzcyBpbiBUb3JvbnRvIG9u IGhvdyB3ZSBjYW4gYmVzdCBkZWZpbmUgdGhlIG1vc3QgdXNlZnVsIHNvbHV0aW9uLg0KDQpUaGFu a3MhDQoNCi1Ob2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRn LWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdv cnkNCj4gTWlyc2t5DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCAxOjE1IFBNDQo+ IFRvOiBNYWNoIENoZW47IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4g U3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1w bHMtYmZkLWRpcmVjdGVkLQ0KPiAwMC50eHQNCj4gDQo+IEhpIE1hY2gsDQo+IHRoYW5rIHlvdSBm b3IgeW91ciBmZWVkYmFjay4NCj4gSW5kZWVkLCBib3RoIGRyYWZ0cyBoYXZlIGNvbW1vbmFsaXRp ZXMuDQo+IEknbSBsb29raW5nIGZvcndhcmQgdG8gdGhlIGRpc2N1c3Npb24gaW4gVG9yb250byBh bmQgaG93IHdlIGNhbiBicmluZyB0aGlzDQo+IGlkZWEgZnVydGhlci4NCj4gDQo+IAlSZWdhcmRz LA0KPiAJCUdyZWcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1h Y2ggQ2hlbiBbbWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBK dWx5IDAxLCAyMDE0IDY6NTcgUE0NCj4gVG86IEdyZWdvcnkgTWlyc2t5DQo+IENjOiBydGctYmZk QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0NCj4gMDAudHh0DQo+IA0KPiBIaSBHcmVnLA0K PiANCj4gSSBoYXZlIGEgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0dGVuIGFu ZCB1c2VmdWwgZHJhZnQhDQo+IA0KPiBDb3VwbGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBk cmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtDQo+IGNoZW4tbXBscy1iZmQt ZW5oYW5jZW1lbnQtMDEpIHRoYXQgaW50ZW5kIHRvIHNvbHZlIHRoZSBzaW1pbGFyIGlzc3VlLCBn bGFkDQo+IHdlIGhhdmUgdGhlIHNpbWlsYXIgdGhvdWdodDotKS4NCj4gDQo+IEl0IGFsc28gZGVm aW5lcyBleHRlbnNpb25zIHRvIExTUCBQaW5nIHRvIGRpcmVjdCB0aGUgY2hvb3NlIG9mIHRoZSBy ZXR1cm4gcGF0aA0KPiBvZiBCRkQgY29udHJvbCBwYWNrZXRzLiBQbGVhc2UgdGFrZSBhIGxvb2su DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeQ0KPiA+IE1pcnNreQ0KPiA+IFNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAwMiwgMjAxNCAyOjE5IEFNDQo+ID4gVG86IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0K PiA+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gPg0KPiA+IERlYXIg QWxsLA0KPiA+IHdlJ3ZlIHBvc3RlZCBhIG5ldyBkcmFmdC4gTFNQIFBpbmcgYWxyZWFkeSBpcyB1 c2VkIHRvIGJvb3RzdHJhcCBhIEJGRA0KPiA+IHNlc3Npb24gd2l0aCBCRkQgRGlzY3JpbWluYXRv ciBUTFYuIEEgbmV3IEJGRCBSZXZlcnNlIFBhdGggVExWIGlzDQo+ID4gaW50cm9kdWNlZCBpbiBv cmRlciB0byBpbnN0cnVjdCBhIGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHBhcnRpY3VsYXINCj4g PiBwYXRoIGZvciByZXZlcnNlIGRpcmVjdGlvbiBvZiB0aGUgQkZEIHNlc3Npb24uDQo+ID4NCj4g PiBHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLg0KPiA+DQo+ID4g CVJlZ2FyZHMsDQo+ID4gCQlHcmVnDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCj4gPiBTZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgNDoxNSBQTQ0K PiA+IFRvOiBHcmVnb3J5IE1pcnNreTsgSWx5YSBWYXJsYXNoa2luOyBKZWZmIFRhbnRzdXJhOyBH cmVnb3J5IE1pcnNreTsNCj4gPiBKZWZmIFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NCj4gPiBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtbWlyc2t5LW1w bHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgSUVU Rg0KPiA+IHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1lOgkJZHJhZnQtbWlyc2t5LW1wbHMtYmZk LWRpcmVjdGVkDQo+ID4gUmV2aXNpb246CTAwDQo+ID4gVGl0bGU6CQlCaWRpcmVjdGlvbmFsIEZv cndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIERpcmVjdGVkIFJldHVybg0KPiBQYXRoDQo+ID4gRG9j dW1lbnQgZGF0ZToJMjAxNC0wNi0zMA0KPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4gUGFnZXM6CQk4DQo+ID4gVVJMOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC4NCj4gPiB0eHQNCj4g PiBTdGF0dXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWly c2t5LW1wbHMtYmZkLWRpcmVjdGVkLw0KPiA+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDANCj4gPg0KPiA+ DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlv biAoQkZEKSBpcyBleHBlY3RlZCB0byBtb25pdG9yIGJpLQ0KPiA+ICAgIGRpcmVjdGlvbmFsIHBh dGhzLiAgV2hlbiBmb3J3YXJkIGRpcmVjdGlvbiBvZiBhIEJGRCBzZXNzaW9uIGlzIHRvDQo+ID4g ICAgbW9uaXRvciBleHBsaWNpdGx5IHJvdXRlZCBwYXRoIHRoZXJlIGlzXCBhIG5lZWQgdG8gYmUg YWJsZSB0byBkaXJlY3QNCj4gPiAgICBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSBzcGVjaWZpYyBw YXRoIGFzIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBCRkQNCj4gPiAgICBzZXNzaW9uLg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5v cmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Jul 2 20:23:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5001B27A1 for ; Wed, 2 Jul 2014 20:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5rBm_x4xPAt for ; Wed, 2 Jul 2014 20:23:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149D31B279F for ; Wed, 2 Jul 2014 20:23:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGS78738; Thu, 03 Jul 2014 03:23:22 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 04:23:21 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 11:23:17 +0800 From: Mach Chen To: "mpls@ietf.org" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPe1o/FzzLYOran0u7hpVpoFCIa5terSvAgC8lRiA= Date: Thu, 3 Jul 2014 03:23:16 +0000 Message-ID: References: Your message of Fri, 16 May 2014 06:46:52 -0000. <30111.1401380562@erosen-lnx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kGlZYjc4oXZfnqdFVY5RqpgklJ8 Cc: "mpls-chairs@tools.ietf.org" , Lizhong Jin , Eric Osborne Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 03:23:27 -0000 Hi Yimin, Eric(s) and Lizhong, Thanks for your comments! We just uploaded two updates (Version 4 and 5) to address your comments.=20 Version 4 solved most of your comments, changes include: 1) Add text to discuss how to prevent SL from leaking to unintended domains= ; (according to Eric Rosen's comments) 2) Remove RSPV-TP related part (according to Lizhong and Eric Osborne's com= ments) 3) Add text to allow one or more SLs that can be allocated to an LSR(accord= ing to Yimin's comments); 4) Refine the Security Consideration; Here is diff from Version 03 to 04 (http://www.ietf.org/rfcdiff?url2=3Ddraf= t-chen-mpls-source-label-04), please refer. Version 5 solved one comment from Eric Rosen, add text to discuss how to pr= event LDP based SLC from leaking SLC outside SLAD. Here is diff from 04 to 05 (http://www.ietf.org/rfcdiff?url2=3Ddraft-chen-m= pls-source-label-05 ) The authors believe that the latest version has solved the received comment= s so far and is ready to be considered as an WG document. Thanks, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Tuesday, June 03, 2014 11:17 AM > To: erosen@cisco.com > Cc: mpls@ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label >=20 > Hi Eric, >=20 > Thanks for your comments! >=20 > We are preparing an update to address the comments from the MPLS-RT > reviewers and you. >=20 > Regarding how to prevent SLC and LS leaking outside to the unintended nod= es > and/or domains, we have the following thoughts: >=20 > 1) Naturally, IGP based SLC negotiation and SL distribution will not leak= the SLC > and SL outside an IGP domain, should be no more concerns here; >=20 > 2) LDP based LSC negotiation, normally LDP is running within an AS, altho= ugh as > you said, technically, it may running across domains and leak the SLC out= side > domain. As you suggested, we will add some text to the LDP based SLC part= to > discuss this. >=20 > 3) For inter-AS scenario, presumably, BGP will be used for SLC negotiatio= n and SL > distribution, we are considering to use non-transitive attribute + policy= control > (e.g., as the way AIGP uses ) to prevent SLC and SL leaking outside to th= e > unintended domain(s). >=20 >=20 > Thanks, > Mach >=20 > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Friday, May 30, 2014 12:23 AM > > To: Mach Chen > > Cc: mpls@ietf.org > > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label > > > > Mach> My point is that the distribution mechanisms should be defined > > Mach> in separate documents > > > > I don't think anyone is really concerned right now with the number of > > documents used to define the "source label" mechanisms. The issue at > > hand is whether the "source label" proposal is architecturally sound. > > Any proposal that uses scoped identifiers has to provide mechanisms > > that prevent the identifiers from leaking out of their intended scope, = either via > the control plane or the data plane. > > Right now there is no draft or set of drafts that we can look at to > > see how the scoping is enforced. The source-label draft is just one > > piece of the architecture, and I don't think it can be accepted until > > we can determine whether the architecture can be completed. > > > > If one looks at the two proposed distribution mechanisms for which > > there are internet drafts (draft-chen-isis-source-label and > > draft-chen-ospf-source-label), we see that these two proposals only > > distribute the labels within a single IGP domain. Since the scope of > > a source label is not restricted to a single IGP domain, we can > > conclude that these two proposals are not, by themselves, adequate. > > > > The drafts also don't seem to have any procedures for dealing with the > > case where two nodes advertise the same source label. > > > > Mach> There may need other solutions (e.g., BGP extensions) for the > > Mach> distribution in that case. This should be discussed when we > > Mach> start to define the distribution mechanisms. > > > > I think we need to see the proposal for the BGP extensions before the > > source-label draft can be considered. That is, I don't think the WG > > should accept the SL draft until some progress has been made in > > defining the distribution mechanisms. > > > > Xiaohu> the SL advertisement could be done by a centralized mapping > > Xiaohu> server > > > > Sure, one could imagine a provisioning system that knows exactly which > > egress LSRs need to know the source labels for which ingress LSRs, and > > would provision the LSR accordingly. However, unless the draft is > > going to say that source labels MUST NOT be used unless there is such > > provisioning system, this doesn't really help. Also, this doesn't > > address the issue of source labels in the data plane leaking outside th= e domain. > > > > Eric> The ingress would have know, not only that the egress is capable > > Eric> of processing the source label, but that the egress will > > Eric> interpret the source label in the proper scope. The draft > > Eric> doesn't address the issue of how to ensure that ingress and > > Eric> egress agree on the intended scope of the label. > > > > Mach> For single domain case, the SLC will be only exchanged among the > > Mach> LSRs within the domain, when the ingress knows the egress can > > Mach> support SLC, it implicit indicates that the egress will > > Mach> interpret the SL in the same scope of itself. > > > > Mach> Actually, even for multiple domains, it is still the case, since > > Mach> SL will be used across domains, the SL space should be shared by > > Mach> the domains. > > > > The question is, how does the ingress LSR know that the egress LSR is > > in the same domain, or in a domain that shares the same SL space? I > > think you're assuming that the capability advertisement from the > > egress will not cross the domain boundary. Given that assumption, if > > an ingress LSR sees an SL capability advertisement from an egress LSR, > > the ingress could assume that the egress is in the same domain. > > However, the SLC signaling mechanisms described in the draft do not pre= vent > the SL Capability signal from crossing a domain boundary. > > On the contrary, the mechanisms described in the draft will cause the > > SLC to be signaled from egress to ingress with no regard for domain > boundaries. > > > > Consider, for instance, the LDP extensions. From section 6.1.1: > > > > "If all the advertised Mappings for F include the SLC TLV, then X > > MUST advertise its Mapping for F with the SLC TLV." > > > > This will cause the SLC to go from egress to ingress, with no regard fo= r > > domain boundaries. Perhaps the above should say "MAY advertise", and > > should have some discussion of policy. > > > > Section 6.1.2 proposes a BGP path attribute to signal the SL Capability= : > > > > "When Border Gateway Protocol (BGP) [RFC4271] is used for distribut= ing > > Network Layer Reachability Information (NLRI) as described in, for > > example, [RFC3107], [RFC4364], the BGP UPDATE message may include > the > > SLC attribute as part of the Path Attributes. This is an optional, > > transitive BGP attribute of value TBD3. The inclusion of this attr= ibute > > with an NLRI indicates that the advertising BGP router can process > > Source Labels as an egress LSR for all routes in that NLRI. > > > > ... > > > > Suppose a BGP speaker T receives an UPDATE U with the SLC attribute= . T > > has two choices. T can simply re-advertise U with the SLC attribut= e if > > either of the following is true: > > > > B1: T does not change the NEXT_HOP attribute OR > > > > B2: T simply swaps labels without popping the entire label stack an= d > > processing the payload below." > > > > Note that if the SLC attribute is an optional transitive attribute, > > then if T does not understand this attribute, T will pass it along > > even if conditions B1 and B2 do not hold. (Perhaps the attribute > > needs to be > > non-transitive.) > > > > B2 is a little hard to understand. Let P be the prefix in the NLRI of > > update U. I think the intention is that the SLC attribute be left on > > by T if each of T's installed routes to P has the SLC attribute. (B2 > > as written seems to be about the data plane, but the context of this > > section is the control plane.) > > > > Even if B1 does hold, it may still be incorrect for router T to pass al= ong the SLC. > > For example, suppose the data path from R1 to R2 is as follows: > > > > R1---ASBR1---ASBR2---R2 > > > > but suppose that R1 and R2 exchange VPN routes through a different path= : > > > > R1---T1---T2---R2 > > > > where T1 and T2 aren't in the data path at all. This could occur in an= "option C" > > type of interconnect. (RFC4364 section 10 option c.) Suppose that R1 > > and R2 are in different domains. T1 and T2 would leave the next hop > > unchanged. When > > R1 has data to send to P, it would find R2 to be the next hop, and > > then would do recursive route resolution to find that ASBR1 is its > > next hop to R2. In this scenario, R1's route to P would have the SLC > > attribute, but R2 would not properly interpret R1's source label. > > > > To make this work at all, you'd have to mandate that the SLC attribute > > be attached to a route that travels along the data path (i.e., goes > > through the ASBRs), and there would have to be policy at the ASBRs > > that strips off the SLC if the ASBRs are at a domain boundary. The > > proper behavior when recursive route resolution is done would also have= to be > specified. > > > > I'm having some trouble understanding the following paragraph from the = draft: > > > > "However, if T changes the NEXT_HOP attribute for U and in the data = plane > > pops the entire label stack to process the payload, T MAY include an= SLC > > attribute for UPDATE U' if both of the following are true:" > > > > C1: T sets the NEXT_HOP attribute of U' to itself AND > > > > C2: T can process source labels. Otherwise, T MUST remove the SLC > > attribute." > > > > The term UPDATE U' doesn't appear to have been defined anywhere, > > though I assume this is meant to be the update you get when you take > > Update U and change the next hop. Does the phrase "and in the data > > plane pops the entire label stack to process the payload" mean that T > > is the egress LSR for the prefix in U's NLRI? If so, I don't think > > this entire paragraph is needed, as T will be originating an Update > > for that prefix, and will include the SLC attribute if necessary. > > > > Eric> With no structure and no "domain identifier" in the source > > Eric> label, it is very easy end up with non-unique labels within a dom= ain. > > > > Mach> There are also many non-structure cases, for example, Router ID, > > Mach> Segment ID, VE ID of BGP VPLS > > Mach> (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), they work fi= ne. > > > > I have to admit that I have always regarded the VPLS VE IDs as a very b= ad idea. > > However, they do have a well-defined scope, namely a single VPLS. > > RT-based mechanisms are used to constrain their distribution so that > > they don't leak unintentionally into other VPLSes. And the VE IDs do > > not appear in the data packets. These characteristics make it > > possible to get away with an unstructured identifier space. SLs don't > > seem to have a well-defined scope, or a well-defined distribution mecha= nism, > and they do get carried by data packets. > > Leakage out of the intended domain is thus much more of a problem. So > > I don't think SLs can be compared to VPLS VE IDs. > > > > With regard to router ids, if you've ever followed any of the > > vituperative discussions that arise when router ids are discussed > > (e.g., when discussing whether a 32-bit id is appropriate for an > > IPv6-based protocol), you'll see that there are quite a few issues in t= he > management of that numbering space. > > > > Mach> In addition, even for your RT example, for L3VPN inter-AS > > Mach> scenario, the RT has to be considered as single space, the > > Mach> domain identifier does not help here. > > > > RTs are structured so that a SP can allocate RT values that are > > globally unique, not just unique within a domain. So a "domain > > identifier" is not needed. I believe it is true that some SPs use > > RTs that are not globally unique, but that is a choice they have made > > for themselves, not a choice that is forced upon them by the architectu= re. > > > > Eric> One might also ask why there is a need to use a 20-bit label to > > Eric> identify a node, instead of using some other format. > > > > Mach> We are talking about identifying the source of an LSP, and the > > Mach> label stack is the MPLS header and there are only labels, then > > Mach> seems that a label to identify the ingress LSR is a naturally cho= ice. > > > > A couple of other possibilities come readily to mind: > > > > - Treat the SLI as the bottom of the stack, and follow it with a 32-bit > > address (or even a 128-bit address) of the ingress. (Or maybe use > > something based on the "generic associated channel".) > > > > - Use two label stack entries and stuff a 32-bit "router id" in them, > > using more per-packet overhead but eliminating the need to manage a > 20-bit > > domain-wide numbering space. > > > > But perhaps the use case is easier to implement if the SL fits into > > the same > > 20 bits usually used for labels. If so, that would be worth mentioning= . > > > > With regard to the name, > > > > Xiaohu> What about IIL (Ingress Identification Label)? > > > > I do like that better. > > > > However, getting all the details right is going to be a lot of work, > > especially for something that has only one use case, and a controversia= l one at > that. > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 2 22:50:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B941A0A94; Wed, 2 Jul 2014 22:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaQBcm3ud0kx; Wed, 2 Jul 2014 22:50:17 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E1D1A0336; Wed, 2 Jul 2014 22:50:17 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-24-53b49abf3e05 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 52.F0.25146.FBA94B35; Thu, 3 Jul 2014 01:50:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Thu, 3 Jul 2014 01:50:15 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Mach Chen , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLA= Date: Thu, 3 Jul 2014 05:50:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPlO7+WVuCDTpmy1lcWCtscWvpSlaL 2R3xFp//bGN0YPGY8nsjq0fLkbesHkuW/GQKYI7isklJzcksSy3St0vgyjjf/Iq1YIpXxe4F k1kbGBd4dDFyckgImEi0X2tmhbDFJC7cW88GYgsJHGWUmNJb28XIBWQvY5Q4tGg7E0iCTcBI 4sXGHnYQW0QgV+Jb+1ZmEJtZQFOi6cRnsLiwQKDEts7LbBA1QRILF/ZC2X4S5/6/ArNZBFQk NjxdBtbLK+ArsWnZSjaIZdeYJA53tTGCJDiBEhvWnAQrYgS67vupNUwQy8Qlbj2ZzwRxtYDE kj3nmSFsUYmXj/9BfaMk8fH3fKCDOMCOW79LH6JVUWJK90N2iL2CEidnPmGZwCg2C8nUWQgd s5B0zELSsYCRZRUjR2lxalluupHhJkZg9ByTYHPcwbjgk+UhRgEORiUe3gSBLcFCrIllxZW5 hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcfLvGelO0CN+lvda5c1xc nrIfZLniX9AqZTbBYEuEyL1wwwy/qID4fV2OSVeXtqlni8q71/OrT78xa1vrilkbGbfbLN1t yXC9tcOiZOWSs/4uGrOvLpm9J+DIxurYOr5i5fP9gYXhR19WLNwSNktU0D4xZ+sbrx3zZG68 KpzamvPZagqjmKgSS3FGoqEWc1FxIgABUh6ofwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/f6oczCVjdtY0mTeqYnD0xib0txQ Cc: "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 05:50:19 -0000 SGkgTm9ibywNCm1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgdGhvdWdodGZ1bCBjb21t ZW50cy4gUGxlYXNlIGZpbmQgbXkgYW5zd2VycyBhbmQgbm90ZXMgaW4tbGluZWQgYW5kIHRhZ2dl ZCB3aXRoIEdJTT4+Lg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTm9ibyBBa2l5YSAobm9ibykgW21haWx0bzpub2JvQGNpc2NvLmNvbV0g DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDIsIDIwMTQgNToxNSBQTQ0KVG86IEdyZWdvcnkgTWly c2t5OyBNYWNoIENoZW47IG1wbHNAaWV0Zi5vcmcNCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktbXBscy1i ZmQtZGlyZWN0ZWQtMDAudHh0DQoNCkhpIEdyZWcsIGV0IGFsLA0KDQpJIGFncmVlIHdpdGggdGhl IHRvcGljIGFuZCB1c2VmdWxuZXNzIG9mIGNvbnRyb2xsaW5nIHRoZSBCRkQgcmV0dXJuIHBhdGgs IGVzcGVjaWFsbHkgaW4gU2VnbWVudCBSb3V0aW5nLg0KDQpBIHF1ZXN0aW9uIGFuZCBjb3VwbGUg Y29tbWVudHMuDQoNCk9uZSB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBzZW1hdGljIGlzIHRvIGlu dHJvZHVjZSAiU2VnbWVudCBSb3V0aW5nIE1QTFMgVHVubmVsIHN1Yi1UTFYiIGFuZCAiU2VnbWVu dCBSb3V0aW5nIElQdjYgVHVubmVsIHN1Yi1UTFYiIHVuZGVyIFJlcGx5IFBhdGggKFJQKSBUTFYg ZGVmaW5lZCBpbiBSRkM3MTEwLiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IG5l dyBUTFYgd2FzIGludHJvZHVjZWQ/IEknbSBtYWlubHkganVzdCBjdXJpb3VzIDopDQpHSU0+PiBU aG91Z2ggaXQgaXMgdW5saWtlbHkgdGhhdCBib3RoIEJGRCBEaXNjcmltaW5hdG9yIFRMViBhbmQg UlAgVExWIHdvdWxkIGJlIHVzZWQgaW4gdGhlIHNhbWUgTFNQIHBpbmcsIHdlIGRpZG4ndCB3YW50 IHRvIHJ1bGUgdGhpcyBvdXQgYW5kIHRob3VnaHQgdGhhdCBvdmVybG9hZGluZyBSUCB3aXRoIGFu b3RoZXIgcm9sZSwgY29uZGl0aW9uYWwgdG8gcHJlc2VuY2Ugb2YgQkZEIFRMViBtYXkgYm90IHN1 Y2ggYSBnb29kIGlkZWEuIEJ1dCB3aGF0IHdlIGRpc2N1c3NlZCB3YXMgaW50cm9kdWN0aW9uIG9m IEJGRCBDb250cm9sIFRMViB0byBoYXZlIG9wdGlvbmFsIHN1Yi1UTFY6IEJGRCBEaXNjcmltaW5h dG9yIHN1Yi1UTFYsIFJldHVybiBQYXRoIHN1Yi1UTFYsIGV0Yy4gSXQgbWF5IGJlIHRoYXQgdGhh dCB3YXMgbm90IGEgYmFkIGlkZWEgYWZ0ZXIgYWxsLg0KDQpUaGVyZSBhcmUgY291cGxlIG9mIHRo aW5ncyB3b3J0aCBoaWdobGlnaHRpbmcgYWJvdXQgdGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMViAo ZGVmaW5lZCBpbiBSRkM1ODg0KSwgbm90IGRpcmVjdGx5IGluIHRoZSBzY29wZSBvZiB5b3VyIGRv Y3VtZW50IGJ1dCB2ZXJ5IHJlbGV2YW50IHdoZW4gbG9va2luZyBhdCB1c2luZyB5b3VyIHByb3Bv c2FsIGluIFNlZ21lbnQgUm91dGluZy4NCg0KMS4gVGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMViBh bGxvd3MgYm9vdHN0cmFwcGluZyBvZiBvbmUgQkZEIHNlc3Npb24gcGVyIEZFQy4gV2hlbiBib290 c3RyYXBwaW5nIG1vcmUgdGhhbiBvbmUgQkZEIHNlc3Npb24gcGVyIEZFQywgaXQgaXMgZGlmZmlj dWx0IHRvIGRvIHNvIHdpdGhvdXQgbWFraW5nIGFzc3VtcHRpb25zLCBhcyB0aGVyZSBpcyBubyBk ZWZpbmVkIGZpZWxkcy9wcm9jZWR1cmVzIHRvIGRvIHNvLiBUaGlzIHdpbGwgYmVjb21lIG1vcmUg b2YgYW4gaXNzdWUgd2l0aCBTZWdtZW50IFJvdXRpbmcsIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxl IGV4cGxpY2l0IHBhdGhzIGNyZWF0ZWQgYmV0d2VlbiBhIHBhaXIgb2Ygbm9kZXMuDQoNCjIuIE1h aW50ZW5hbmNlIG9mIGJvb3RzdHJhcHBlZCBCRkQgc2Vzc2lvbnMgaXMgZnV6enksIG1lYW5pbmcg d2hlbiBzaG91bGQgdGhlIGVncmVzcyBkZWxldGUgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucy4g T25lIGNvdWxkIGltcGxlbWVudCBzdWNoIHRoYXQgdGhlIGVncmVzcyBkZWxldGVzIEJGRCBzZXNz aW9ucyB3aGVuIGNvcnJlc3BvbmRpbmcgRkVDIGlzIGRlbGV0ZWQsIG9yIFggYW1vdW50IG9mIHRp bWUgYWZ0ZXIgc2Vzc2lvbnMgZ28gImRvd24iLiBUaGVyZSdzIG5vIEZFQy9zdGF0ZSBvbiB0aGUg ZWdyZXNzIGZvciBTZWdtZW50IFJvdXRpbmcuICBUaHVzIG9ubHkgcmVtYWluaW5nIG9wdGlvbiB0 b2RheSBpcyB0byBkZWxldGUgdGhlIHNlc3Npb24gYWZ0ZXIgWCBzZWNvbmRzL21pbnV0ZXMgb25j ZSB0aGUgc2Vzc2lvbiBpcyBpbiAiZG93biIgc3RhdGUuIFBlcmhhcHMgdGhpcyBmdXp6aW5lc3Mg aXMgcmVhc29uYWJsZSwgb3IgcGVyaGFwcyB3ZSB3YW50IGV4cGxpY2l0ICJkZWxldGUiIGluc3Ry dWN0aW9uIGZyb20gdGhlIGluZ3Jlc3MgdG8gdGhlIGVncmVzcy4NCkdJTT4+IEJGRCAoc2hvdWxk IHdlIHJlZmVyIHRvIGl0IG5vdyBhcyAiY2xhc3NpY2FsIiBCRkQpIG11c3QgYmUgY29uZmlndXJl ZCBiZWZvcmUgaXQgYmUgYm9vdHN0cmFwcGVkIGJ5IExTUCBwaW5nLiBUbyBjbGVhbiB1cCBhbnkg cmVzaWR1YWwgc3RhdGUgaW4gdGhlIGRhdGEgcGxhbmUgb3BlcmF0b3Igd291bGQgbmVlZCBqdXN0 IHRvIHJlbW92ZSBjb3JyZXNwb25kaW5nICBCRkQgc2Vzc2lvbiBjb25maWd1cmF0aW9uLiBTLUJG RCB3b3VsZCBiZSBkaWZmZXJlbnQgY2FzZS4gVGhlIGZhci1lbmQgQkZEIHBlZXIgaXMsIGluIGEg d2F5LCBzdGF0ZWxlc3MgYnV0IGlmIHdhcyBpbnN0cnVjdGVkIHRvIHVzZSBzcGVjaWZpYyBwYXRo IHZpYSBCRkQgUmV2ZXJzZSBQYXRoIFRMViwgdGhlbiB0aGF0IHdpbGwgY3JlYXRlIGEgc3RhdGUg aW4gdGhlIGRhdGEgcGxhbmUuIENsZWFuaW5nIGl0IHVwIG1heSBiZSByZXF1aXJlZCB0byBwcmV2 ZW50IGV4aGF1c3Rpb24gb2YgYSByZXNvdXJjZSBpbiB0aGUgZGF0YSBwbGFuZS4gQ2VydGFpbmx5 IGdyZWF0IHRvcGljIGZvciBkaXNjdXNzaW9uIGluIFRvcm9udG8uIA0KDQpJIGJlbGlldmUgbXkg Y29sbGVhZ3VlIGlzIGFib3V0IHRvIHJvbGwgb3V0IGEgZG9jdW1lbnQgZm9yIEV4dGVuZGVkIEJG RCBEaXNjcmltaW5hdG9yIFRMViB3aGljaCBhZGRyZXNzZXMgKDEpIGFuZCAoMikgYWJvdmUuIFBy aW1hcnkgbW90aXZhdGlvbiBvZiB0aGF0IGRvY3VtZW50IGlzIEVWUE4gQkZELCBidXQgaXQgbG9v a3MgdmVyeSBhcHBsaWNhYmxlIHRvIFNlZ21lbnQgUm91dGluZyBhcyB3ZWxsLg0KR0lNPj4gVmVy eSBpbnRlcmVzdGluZyBpbmRlZWQuIExvb2tpbmcgZm9yd2FyZCB0byByZWFkIHRoZSBwcm9wb3Nh bC4NCg0KTGFzdGx5LCBob3cgZG8gd2UgdXNlIHRoaXMgZm9yIFMtQkZEPyA6KQ0KDQpMZXQncyBk aXNjdXNzIGluIFRvcm9udG8gb24gaG93IHdlIGNhbiBiZXN0IGRlZmluZSB0aGUgbW9zdCB1c2Vm dWwgc29sdXRpb24uDQpHSU0+PiBUaGFuayB5b3UhDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJm ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeSANCj4gTWlyc2t5DQo+IFNl bnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCAxOjE1IFBNDQo+IFRvOiBNYWNoIENoZW47IG1w bHNAaWV0Zi5vcmcNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0gMDAudHh0DQo+IA0KPiBIaSBNYWNoLA0KPiB0aGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2su DQo+IEluZGVlZCwgYm90aCBkcmFmdHMgaGF2ZSBjb21tb25hbGl0aWVzLg0KPiBJJ20gbG9va2lu ZyBmb3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9uIGluIFRvcm9udG8gYW5kIGhvdyB3ZSBjYW4gYnJp bmcgDQo+IHRoaXMgaWRlYSBmdXJ0aGVyLg0KPiANCj4gCVJlZ2FyZHMsDQo+IAkJR3JlZw0KPiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86 bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIwMTQgNjo1 NyBQTQ0KPiBUbzogR3JlZ29yeSBNaXJza3kNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LW1pcnNreS1t cGxzLWJmZC1kaXJlY3RlZC0gMDAudHh0DQo+IA0KPiBIaSBHcmVnLA0KPiANCj4gSSBoYXZlIGEg cXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0dGVuIGFuZCB1c2VmdWwgZHJhZnQh DQo+IA0KPiBDb3VwbGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCANCj4gKGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiBjaGVuLW1wbHMtYmZkLWVuaGFuY2VtZW50 LTAxKSB0aGF0IGludGVuZCB0byBzb2x2ZSB0aGUgc2ltaWxhciBpc3N1ZSwgDQo+IGdsYWQgd2Ug aGF2ZSB0aGUgc2ltaWxhciB0aG91Z2h0Oi0pLg0KPiANCj4gSXQgYWxzbyBkZWZpbmVzIGV4dGVu c2lvbnMgdG8gTFNQIFBpbmcgdG8gZGlyZWN0IHRoZSBjaG9vc2Ugb2YgdGhlIA0KPiByZXR1cm4g cGF0aCBvZiBCRkQgY29udHJvbCBwYWNrZXRzLiBQbGVhc2UgdGFrZSBhIGxvb2suDQo+IA0KPiBC ZXN0IHJlZ2FyZHMsDQo+IE1hY2gNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgR3JlZ29yeSANCj4gPiBNaXJza3kNCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg MDIsIDIwMTQgMjoxOSBBTQ0KPiA+IFRvOiBtcGxzQGlldGYub3JnOyBydGctYmZkQGlldGYub3Jn DQo+ID4gU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ID4gZHJh ZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+DQo+ID4gRGVhciBBbGwsDQo+ ID4gd2UndmUgcG9zdGVkIGEgbmV3IGRyYWZ0LiBMU1AgUGluZyBhbHJlYWR5IGlzIHVzZWQgdG8g Ym9vdHN0cmFwIGEgDQo+ID4gQkZEIHNlc3Npb24gd2l0aCBCRkQgRGlzY3JpbWluYXRvciBUTFYu IEEgbmV3IEJGRCBSZXZlcnNlIFBhdGggVExWIA0KPiA+IGlzIGludHJvZHVjZWQgaW4gb3JkZXIg dG8gaW5zdHJ1Y3QgYSBmYXItZW5kIEJGRCBwZWVyIHRvIHVzZSANCj4gPiBwYXJ0aWN1bGFyIHBh dGggZm9yIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSBCRkQgc2Vzc2lvbi4NCj4gPg0KPiA+IEdy ZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMuDQo+ID4NCj4gPiAJUmVn YXJkcywNCj4gPiAJCUdyZWcNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAzMCwgMjAxNCA0OjE1IFBNDQo+ID4g VG86IEdyZWdvcnkgTWlyc2t5OyBJbHlhIFZhcmxhc2hraW47IEplZmYgVGFudHN1cmE7IEdyZWdv cnkgTWlyc2t5OyANCj4gPiBKZWZmIFRhbnRzdXJhOyBJbHlhIFZhcmxhc2hraW4NCj4gPiBTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiA+IGRyYWZ0LW1pcnNreS1tcGxz LWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIA0KPiA+ IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC1taXJza3ktbXBscy1iZmQt ZGlyZWN0ZWQNCj4gPiBSZXZpc2lvbjoJMDANCj4gPiBUaXRsZToJCUJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGlyZWN0ZWQgUmV0dXJuDQo+IFBhdGgNCj4gPiBEb2N1 bWVudCBkYXRlOgkyMDE0LTA2LTMwDQo+ID4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4gPiBQYWdlczoJCTgNCj4gPiBVUkw6DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLg0KPiA+IHR4dA0KPiA+ IFN0YXR1czoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJz a3ktbXBscy1iZmQtZGlyZWN0ZWQvDQo+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMA0KPiA+DQo+ID4N Cj4gPiBBYnN0cmFjdDoNCj4gPiAgICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9u IChCRkQpIGlzIGV4cGVjdGVkIHRvIG1vbml0b3IgYmktDQo+ID4gICAgZGlyZWN0aW9uYWwgcGF0 aHMuICBXaGVuIGZvcndhcmQgZGlyZWN0aW9uIG9mIGEgQkZEIHNlc3Npb24gaXMgdG8NCj4gPiAg ICBtb25pdG9yIGV4cGxpY2l0bHkgcm91dGVkIHBhdGggdGhlcmUgaXNcIGEgbmVlZCB0byBiZSBh YmxlIHRvIGRpcmVjdA0KPiA+ICAgIGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHNwZWNpZmljIHBh dGggYXMgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRA0KPiA+ICAgIHNlc3Npb24uDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gdG9vbHMuaWV0Zi5v cmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jul 3 03:17:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990A21B2821; Thu, 3 Jul 2014 03:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIjZIm4lChVC; Thu, 3 Jul 2014 03:17:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42931B2815; Thu, 3 Jul 2014 03:17:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT14870; Thu, 03 Jul 2014 10:17:34 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014 11:17:33 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 3 Jul 2014 18:17:25 +0800 From: Mach Chen To: Gregory Mirsky , "Nobo Akiya (nobo)" , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAEjfoA== Date: Thu, 3 Jul 2014 10:17:25 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Btas7fKV_Wx4Ah1grX0D3D7RvUw Cc: "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 10:17:38 -0000 SGkgR3JlZywNCg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuLi4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMDMsIDIwMTQg MTo1MCBQTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibyk7IE1hY2ggQ2hlbjsgbXBsc0BpZXRmLm9y Zw0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQo+IA0K PiBIaSBOb2JvLA0KPiBtYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIHRob3VnaHRmdWwg Y29tbWVudHMuIFBsZWFzZSBmaW5kIG15IGFuc3dlcnMNCj4gYW5kIG5vdGVzIGluLWxpbmVkIGFu ZCB0YWdnZWQgd2l0aCBHSU0+Pi4NCj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5vYm8gQWtpeWEgKG5vYm8pIFttYWls dG86bm9ib0BjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCA1OjE1 IFBNDQo+IFRvOiBHcmVnb3J5IE1pcnNreTsgTWFjaCBDaGVuOyBtcGxzQGlldGYub3JnDQo+IENj OiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCj4gDQo+IEhpIEdy ZWcsIGV0IGFsLA0KPiANCj4gSSBhZ3JlZSB3aXRoIHRoZSB0b3BpYyBhbmQgdXNlZnVsbmVzcyBv ZiBjb250cm9sbGluZyB0aGUgQkZEIHJldHVybiBwYXRoLA0KPiBlc3BlY2lhbGx5IGluIFNlZ21l bnQgUm91dGluZy4NCj4gDQo+IEEgcXVlc3Rpb24gYW5kIGNvdXBsZSBjb21tZW50cy4NCj4gDQo+ IE9uZSB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBzZW1hdGljIGlzIHRvIGludHJvZHVjZSAiU2Vn bWVudCBSb3V0aW5nIE1QTFMNCj4gVHVubmVsIHN1Yi1UTFYiIGFuZCAiU2VnbWVudCBSb3V0aW5n IElQdjYgVHVubmVsIHN1Yi1UTFYiIHVuZGVyIFJlcGx5IFBhdGgNCj4gKFJQKSBUTFYgZGVmaW5l ZCBpbiBSRkM3MTEwLiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IG5ldyBUTFYg d2FzDQo+IGludHJvZHVjZWQ/IEknbSBtYWlubHkganVzdCBjdXJpb3VzIDopDQo+IEdJTT4+IFRo b3VnaCBpdCBpcyB1bmxpa2VseSB0aGF0IGJvdGggQkZEIERpc2NyaW1pbmF0b3IgVExWIGFuZCBS UCBUTFYgd291bGQgYmUNCj4gdXNlZCBpbiB0aGUgc2FtZSBMU1AgcGluZywgd2UgZGlkbid0IHdh bnQgdG8gcnVsZSB0aGlzIG91dCBhbmQgdGhvdWdodCB0aGF0DQo+IG92ZXJsb2FkaW5nIFJQIHdp dGggYW5vdGhlciByb2xlLCBjb25kaXRpb25hbCB0byBwcmVzZW5jZSBvZiBCRkQgVExWIG1heSBi b3QNCg0KSSBtYXkgaGF2ZSBkaWZmZXJlbnQgdmlldyBoZXJlLCB0aGlua2luZyBhYm91dCB0aGUg Y3VycmVudCBMU1AgUGluZyBiYXNlZCBib290c3RyYXBwaW5nLCB0aGUgZWNobyByZXF1ZXN0IHdp bGwgY2FycnkgYm90aCBUYXJnZXQgc3RhY2sgRkVDIFRMViBhbmQgQkZEIERpc2NyaW1pbmF0b3Ig VExWLCBUYXJnZXQgc3RhY2sgRkVDIFRMViBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBMU1AgdG8g d2hpY2ggdGhhdCB0aGUgQkZEIHNlc3Npb24gaXMgYm91bmQsIEJGRCBEaXNjcmltaW5hdG9yIFRM ViBpcyB1c2VkIHRvIGluZGljYXRlIHRoaXMgaXMgYSBCRkQgYm9vdHN0cmFwcGluZyBpbnN0ZWFk IG9mIGEgbm9ybWFsIExTUCBQaW5nLiBBbmFsb2cgdG8gdGhpcywgaWYgd2Ugd2FudCB0byBzcGVj aWZ5IHRoZSByZXR1cm4gcGF0aCBvZiBCRkQgc2Vzc2lvbiwgc2VlbXMgYWRkIHRoZSBSUCBUTFYg dG8gaWRlbnRpZnkgdGhlIHJldHVybiBwYXRoIGlzIG5hdHVyYWwgY2hvaWNlLiBBbmQgZm9yIHRo ZSBzZWdtZW50IHJvdXRpbmcsIHdlIGp1c3QgbmVlZCBkZWZpbmUgbmV3IHN1Yi1UTFZzLiANCg0K PiBzdWNoIGEgZ29vZCBpZGVhLiBCdXQgd2hhdCB3ZSBkaXNjdXNzZWQgd2FzIGludHJvZHVjdGlv biBvZiBCRkQgQ29udHJvbCBUTFYgdG8NCj4gaGF2ZSBvcHRpb25hbCBzdWItVExWOiBCRkQgRGlz Y3JpbWluYXRvciBzdWItVExWLCBSZXR1cm4gUGF0aCBzdWItVExWLCBldGMuIEl0DQo+IG1heSBi ZSB0aGF0IHRoYXQgd2FzIG5vdCBhIGJhZCBpZGVhIGFmdGVyIGFsbC4NCg0KQ3VycmVudGx5LCBU YXJnZXQgU3RhY2sgRkVDIFRMViBhbmQgUmVwbHkgUGF0aCBUTFYgc2hhcmUgdGhlIHNhbWUgc3Vi LVRMVnMuIEF0IHRoZSBiZWdpbm5pbmcsIFJlcGx5IFBhdGggVExWIHdhbnRzIGl0cyBvd24gcmVn aXN0cnkgYW5kIGhvcGUgdG8gYm9ycm93IHNvbWUgc3ViLVRMVnMgZnJvbSB0aGUgVGFyZ2V0IFN0 YWNrIEZFQyBUTFYsIGJ1dCBpdCB0dXJuZWQgb3V0IHRvIGJlIGFuIHVuc3VjY2Vzc2Z1bCBjaG9p Y2UsIGFuZCBpdCB3YXMgdmVyeSBwYWluZnVsIHRvIGRldGVybWluZSBob3cgdG8gcHJvY2VzcyB0 aGUgcmVnaXN0cnksIHRoZXJlIHdhcyBhIGxvbmcgbG9uZyBkaXNjdXNzaW9uIGFib3V0IHdoZW4g cHVibGlzaCBSRkM3MTEwLiANCg0KU28sIGlmIHlvdSBpbnRyb2R1Y2UgdGhlIG5ldyBCRkQgQ29u dHJvbCBUTFYsIHRoZSBzYW1lIHNpdHVhdGlvbiB3aWxsIG9jY3VyIGFnYWluLCB5b3UgaGF2ZSBt YWtlIGEgZGVjaXNpb24gd2hldGhlciBCRkQgQ29udHJvbCBUTFYgaGFzIGl0cyBvd24gcmVnaXN0 cnksIHdoaWNoIHN1Yi1UTFZzIGNhbiBiZSBjYXJyaWVkIGluIEJGRCBDb250cm9sIFRMViwgaG93 IHRvIHByb2Nlc3MgdGhlIGZ1dHVyZSBkZWZpbmVkIFJlcGx5IFBhdGggc3ViLVRMVnMsIGV0Yy4g IA0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo+IA0KPiBUaGVyZSBhcmUgY291cGxlIG9mIHRoaW5n cyB3b3J0aCBoaWdobGlnaHRpbmcgYWJvdXQgdGhlIEJGRCBEaXNjcmltaW5hdG9yIFRMVg0KPiAo ZGVmaW5lZCBpbiBSRkM1ODg0KSwgbm90IGRpcmVjdGx5IGluIHRoZSBzY29wZSBvZiB5b3VyIGRv Y3VtZW50IGJ1dCB2ZXJ5DQo+IHJlbGV2YW50IHdoZW4gbG9va2luZyBhdCB1c2luZyB5b3VyIHBy b3Bvc2FsIGluIFNlZ21lbnQgUm91dGluZy4NCj4gDQo+IDEuIFRoZSBCRkQgRGlzY3JpbWluYXRv ciBUTFYgYWxsb3dzIGJvb3RzdHJhcHBpbmcgb2Ygb25lIEJGRCBzZXNzaW9uIHBlciBGRUMuDQo+ IFdoZW4gYm9vdHN0cmFwcGluZyBtb3JlIHRoYW4gb25lIEJGRCBzZXNzaW9uIHBlciBGRUMsIGl0 IGlzIGRpZmZpY3VsdCB0byBkbyBzbw0KPiB3aXRob3V0IG1ha2luZyBhc3N1bXB0aW9ucywgYXMg dGhlcmUgaXMgbm8gZGVmaW5lZCBmaWVsZHMvcHJvY2VkdXJlcyB0byBkbyBzby4NCj4gVGhpcyB3 aWxsIGJlY29tZSBtb3JlIG9mIGFuIGlzc3VlIHdpdGggU2VnbWVudCBSb3V0aW5nLCB3aGVuIHRo ZXJlIGFyZQ0KPiBtdWx0aXBsZSBleHBsaWNpdCBwYXRocyBjcmVhdGVkIGJldHdlZW4gYSBwYWly IG9mIG5vZGVzLg0KPiANCj4gMi4gTWFpbnRlbmFuY2Ugb2YgYm9vdHN0cmFwcGVkIEJGRCBzZXNz aW9ucyBpcyBmdXp6eSwgbWVhbmluZyB3aGVuIHNob3VsZCB0aGUNCj4gZWdyZXNzIGRlbGV0ZSBi b290c3RyYXBwZWQgQkZEIHNlc3Npb25zLiBPbmUgY291bGQgaW1wbGVtZW50IHN1Y2ggdGhhdCB0 aGUNCj4gZWdyZXNzIGRlbGV0ZXMgQkZEIHNlc3Npb25zIHdoZW4gY29ycmVzcG9uZGluZyBGRUMg aXMgZGVsZXRlZCwgb3IgWCBhbW91bnQgb2YNCj4gdGltZSBhZnRlciBzZXNzaW9ucyBnbyAiZG93 biIuIFRoZXJlJ3Mgbm8gRkVDL3N0YXRlIG9uIHRoZSBlZ3Jlc3MgZm9yIFNlZ21lbnQNCj4gUm91 dGluZy4gIFRodXMgb25seSByZW1haW5pbmcgb3B0aW9uIHRvZGF5IGlzIHRvIGRlbGV0ZSB0aGUg c2Vzc2lvbiBhZnRlciBYDQo+IHNlY29uZHMvbWludXRlcyBvbmNlIHRoZSBzZXNzaW9uIGlzIGlu ICJkb3duIiBzdGF0ZS4gUGVyaGFwcyB0aGlzIGZ1enppbmVzcyBpcw0KPiByZWFzb25hYmxlLCBv ciBwZXJoYXBzIHdlIHdhbnQgZXhwbGljaXQgImRlbGV0ZSIgaW5zdHJ1Y3Rpb24gZnJvbSB0aGUg aW5ncmVzcyB0bw0KPiB0aGUgZWdyZXNzLg0KPiBHSU0+PiBCRkQgKHNob3VsZCB3ZSByZWZlciB0 byBpdCBub3cgYXMgImNsYXNzaWNhbCIgQkZEKSBtdXN0IGJlIGNvbmZpZ3VyZWQNCj4gYmVmb3Jl IGl0IGJlIGJvb3RzdHJhcHBlZCBieSBMU1AgcGluZy4gVG8gY2xlYW4gdXAgYW55IHJlc2lkdWFs IHN0YXRlIGluIHRoZSBkYXRhDQo+IHBsYW5lIG9wZXJhdG9yIHdvdWxkIG5lZWQganVzdCB0byBy ZW1vdmUgY29ycmVzcG9uZGluZyAgQkZEIHNlc3Npb24NCj4gY29uZmlndXJhdGlvbi4gUy1CRkQg d291bGQgYmUgZGlmZmVyZW50IGNhc2UuIFRoZSBmYXItZW5kIEJGRCBwZWVyIGlzLCBpbiBhIHdh eSwNCj4gc3RhdGVsZXNzIGJ1dCBpZiB3YXMgaW5zdHJ1Y3RlZCB0byB1c2Ugc3BlY2lmaWMgcGF0 aCB2aWEgQkZEIFJldmVyc2UgUGF0aCBUTFYsIHRoZW4NCj4gdGhhdCB3aWxsIGNyZWF0ZSBhIHN0 YXRlIGluIHRoZSBkYXRhIHBsYW5lLiBDbGVhbmluZyBpdCB1cCBtYXkgYmUgcmVxdWlyZWQgdG8N Cj4gcHJldmVudCBleGhhdXN0aW9uIG9mIGEgcmVzb3VyY2UgaW4gdGhlIGRhdGEgcGxhbmUuIENl cnRhaW5seSBncmVhdCB0b3BpYyBmb3INCj4gZGlzY3Vzc2lvbiBpbiBUb3JvbnRvLg0KPiANCj4g SSBiZWxpZXZlIG15IGNvbGxlYWd1ZSBpcyBhYm91dCB0byByb2xsIG91dCBhIGRvY3VtZW50IGZv ciBFeHRlbmRlZCBCRkQNCj4gRGlzY3JpbWluYXRvciBUTFYgd2hpY2ggYWRkcmVzc2VzICgxKSBh bmQgKDIpIGFib3ZlLiBQcmltYXJ5IG1vdGl2YXRpb24gb2YgdGhhdA0KPiBkb2N1bWVudCBpcyBF VlBOIEJGRCwgYnV0IGl0IGxvb2tzIHZlcnkgYXBwbGljYWJsZSB0byBTZWdtZW50IFJvdXRpbmcg YXMgd2VsbC4NCj4gR0lNPj4gVmVyeSBpbnRlcmVzdGluZyBpbmRlZWQuIExvb2tpbmcgZm9yd2Fy ZCB0byByZWFkIHRoZSBwcm9wb3NhbC4NCj4gDQo+IExhc3RseSwgaG93IGRvIHdlIHVzZSB0aGlz IGZvciBTLUJGRD8gOikNCj4gDQo+IExldCdzIGRpc2N1c3MgaW4gVG9yb250byBvbiBob3cgd2Ug Y2FuIGJlc3QgZGVmaW5lIHRoZSBtb3N0IHVzZWZ1bCBzb2x1dGlvbi4NCj4gR0lNPj4gVGhhbmsg eW91IQ0KPiANCj4gVGhhbmtzIQ0KPiANCj4gLU5vYm8NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeQ0KPiA+IE1pcnNreQ0KPiA+IFNlbnQ6IFdlZG5l c2RheSwgSnVseSAwMiwgMjAxNCAxOjE1IFBNDQo+ID4gVG86IE1hY2ggQ2hlbjsgbXBsc0BpZXRm Lm9yZw0KPiA+IENjOiBydGctYmZkQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQt IDAwLnR4dA0KPiA+DQo+ID4gSGkgTWFjaCwNCj4gPiB0aGFuayB5b3UgZm9yIHlvdXIgZmVlZGJh Y2suDQo+ID4gSW5kZWVkLCBib3RoIGRyYWZ0cyBoYXZlIGNvbW1vbmFsaXRpZXMuDQo+ID4gSSdt IGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgZGlzY3Vzc2lvbiBpbiBUb3JvbnRvIGFuZCBob3cgd2Ug Y2FuIGJyaW5nDQo+ID4gdGhpcyBpZGVhIGZ1cnRoZXIuDQo+ID4NCj4gPiAJUmVnYXJkcywNCj4g PiAJCUdyZWcNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog TWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+ID4gU2VudDogVHVlc2Rh eSwgSnVseSAwMSwgMjAxNCA2OjU3IFBNDQo+ID4gVG86IEdyZWdvcnkgTWlyc2t5DQo+ID4gQ2M6 IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiA+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0gMDAudHh0DQo+ID4N Cj4gPiBIaSBHcmVnLA0KPiA+DQo+ID4gSSBoYXZlIGEgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFm dCwgd2VsbCB3cml0dGVuIGFuZCB1c2VmdWwgZHJhZnQhDQo+ID4NCj4gPiBDb3VwbGUgeWVhcnMg YWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdA0KPiA+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC0NCj4gPiBjaGVuLW1wbHMtYmZkLWVuaGFuY2VtZW50LTAxKSB0aGF0IGludGVuZCB0 byBzb2x2ZSB0aGUgc2ltaWxhciBpc3N1ZSwNCj4gPiBnbGFkIHdlIGhhdmUgdGhlIHNpbWlsYXIg dGhvdWdodDotKS4NCj4gPg0KPiA+IEl0IGFsc28gZGVmaW5lcyBleHRlbnNpb25zIHRvIExTUCBQ aW5nIHRvIGRpcmVjdCB0aGUgY2hvb3NlIG9mIHRoZQ0KPiA+IHJldHVybiBwYXRoIG9mIEJGRCBj b250cm9sIHBhY2tldHMuIFBsZWFzZSB0YWtlIGEgbG9vay4NCj4gPg0KPiA+IEJlc3QgcmVnYXJk cywNCj4gPiBNYWNoDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR3JlZ29yeQ0KPiA+ID4gTWlyc2t5DQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg MDIsIDIwMTQgMjoxOSBBTQ0KPiA+ID4gVG86IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0Zi5v cmcNCj4gPiA+IFN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4g PiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAudHh0DQo+ID4gPg0KPiA+ID4gRGVh ciBBbGwsDQo+ID4gPiB3ZSd2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQuIExTUCBQaW5nIGFscmVhZHkg aXMgdXNlZCB0byBib290c3RyYXAgYQ0KPiA+ID4gQkZEIHNlc3Npb24gd2l0aCBCRkQgRGlzY3Jp bWluYXRvciBUTFYuIEEgbmV3IEJGRCBSZXZlcnNlIFBhdGggVExWDQo+ID4gPiBpcyBpbnRyb2R1 Y2VkIGluIG9yZGVyIHRvIGluc3RydWN0IGEgZmFyLWVuZCBCRkQgcGVlciB0byB1c2UNCj4gPiA+ IHBhcnRpY3VsYXIgcGF0aCBmb3IgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9u Lg0KPiA+ID4NCj4gPiA+IEdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHF1ZXN0aW9ucywgY29tbWVu dHMuDQo+ID4gPg0KPiA+ID4gCVJlZ2FyZHMsDQo+ID4gPiAJCUdyZWcNCj4gPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+ID4gU2VudDogTW9u ZGF5LCBKdW5lIDMwLCAyMDE0IDQ6MTUgUE0NCj4gPiA+IFRvOiBHcmVnb3J5IE1pcnNreTsgSWx5 YSBWYXJsYXNoa2luOyBKZWZmIFRhbnRzdXJhOyBHcmVnb3J5IE1pcnNreTsNCj4gPiA+IEplZmYg VGFudHN1cmE7IElseWEgVmFybGFzaGtpbg0KPiA+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPiA+ID4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4 dA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBHcmVnIE1pcnNreSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+ID4gSUVURiByZXBv c2l0b3J5Lg0KPiA+ID4NCj4gPiA+IE5hbWU6CQlkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0 ZWQNCj4gPiA+IFJldmlzaW9uOgkwMA0KPiA+ID4gVGl0bGU6CQlCaWRpcmVjdGlvbmFsIEZvcndh cmRpbmcgRGV0ZWN0aW9uIChCRkQpIERpcmVjdGVkIFJldHVybg0KPiA+IFBhdGgNCj4gPiA+IERv Y3VtZW50IGRhdGU6CTIwMTQtMDYtMzANCj4gPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+ID4gPiBQYWdlczoJCTgNCj4gPiA+IFVSTDoNCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC4NCj4g PiA+IHR4dA0KPiA+ID4gU3RhdHVzOg0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLw0KPiA+ID4gSHRtbGl6ZWQ6DQo+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0wMA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBYnN0cmFjdDoNCj4gPiA+ICAgIEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0N Cj4gPiA+ICAgIGRpcmVjdGlvbmFsIHBhdGhzLiAgV2hlbiBmb3J3YXJkIGRpcmVjdGlvbiBvZiBh IEJGRCBzZXNzaW9uIGlzIHRvDQo+ID4gPiAgICBtb25pdG9yIGV4cGxpY2l0bHkgcm91dGVkIHBh dGggdGhlcmUgaXNcIGEgbmVlZCB0byBiZSBhYmxlIHRvIGRpcmVjdA0KPiA+ID4gICAgZmFyLWVu ZCBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyByZXZlcnNlIGRpcmVjdGlvbiBvZiB0 aGUgQkZEDQo+ID4gPiAgICBzZXNzaW9uLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4g PiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9yZy4NCj4gPiA+DQo+ ID4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jul 3 06:09:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E4F1B296A; Thu, 3 Jul 2014 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbZfbyWdv8I4; Thu, 3 Jul 2014 06:09:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A71A1B2965; Thu, 3 Jul 2014 06:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7214; q=dns/txt; s=iport; t=1404392953; x=1405602553; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aqNVZwMMzEtDpZuWH49fyytuwQwsZmHqFEk/xORz7iE=; b=VKxdDLKYNJ8L+1ZFpN1DQ0ey45MjOGWmVSAHvJ5vk55fyrzMYhqMgX7R 5Q6+L4hnwxPyR7M/+z+HUVb8Cc6RbtmfYn73MTc//czMpXgFUGFceEYM6 c+RdkqLx4+NYo016aYTo2ptcfiv1Ht2nSf7wyxbPM9BmYAgzWJnaRrsEX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAJBUtVOtJV2S/2dsb2JhbABQCoJpJIEsgm/DLwEZbBZ1hAMBAQEDASMRMxACEAIBCBoCBiACAgIwFRACBAENDYgyCAGtA5tyF4EsiDmEYSsxB4J3NoEWAQSud4NDgjA X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="337527660" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jul 2014 13:09:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s63D9BaF009404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 13:09:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 08:09:11 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , Gregory Mirsky , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAEjfoIAAME/A Date: Thu, 3 Jul 2014 13:09:10 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DFzGKzP-JJ4kcn6XZRNlcZyXGsQ Cc: "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:09:15 -0000 SGkgR3JlZywgTWFjaCwNCg0KPiA+IE9uZSB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBzZW1hdGlj IGlzIHRvIGludHJvZHVjZSAiU2VnbWVudCBSb3V0aW5nDQo+ID4gTVBMUyBUdW5uZWwgc3ViLVRM ViIgYW5kICJTZWdtZW50IFJvdXRpbmcgSVB2NiBUdW5uZWwgc3ViLVRMViIgdW5kZXINCj4gPiBS ZXBseSBQYXRoDQo+ID4gKFJQKSBUTFYgZGVmaW5lZCBpbiBSRkM3MTEwLiBJcyB0aGVyZSBhbnkg cGFydGljdWxhciByZWFzb24gd2h5IG5ldw0KPiA+IFRMViB3YXMgaW50cm9kdWNlZD8gSSdtIG1h aW5seSBqdXN0IGN1cmlvdXMgOikNCj4gPiBHSU0+PiBUaG91Z2ggaXQgaXMgdW5saWtlbHkgdGhh dCBib3RoIEJGRCBEaXNjcmltaW5hdG9yIFRMViBhbmQgUlAgVExWDQo+ID4gR0lNPj4gd291bGQg YmUNCj4gPiB1c2VkIGluIHRoZSBzYW1lIExTUCBwaW5nLCB3ZSBkaWRuJ3Qgd2FudCB0byBydWxl IHRoaXMgb3V0IGFuZCB0aG91Z2h0DQo+ID4gdGhhdCBvdmVybG9hZGluZyBSUCB3aXRoIGFub3Ro ZXIgcm9sZSwgY29uZGl0aW9uYWwgdG8gcHJlc2VuY2Ugb2YgQkZEDQo+ID4gVExWIG1heSBib3QN Cj4gDQo+IEkgbWF5IGhhdmUgZGlmZmVyZW50IHZpZXcgaGVyZSwgdGhpbmtpbmcgYWJvdXQgdGhl IGN1cnJlbnQgTFNQIFBpbmcgYmFzZWQNCj4gYm9vdHN0cmFwcGluZywgdGhlIGVjaG8gcmVxdWVz dCB3aWxsIGNhcnJ5IGJvdGggVGFyZ2V0IHN0YWNrIEZFQyBUTFYgYW5kIEJGRA0KPiBEaXNjcmlt aW5hdG9yIFRMViwgVGFyZ2V0IHN0YWNrIEZFQyBUTFYgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUg TFNQIHRvIHdoaWNoDQo+IHRoYXQgdGhlIEJGRCBzZXNzaW9uIGlzIGJvdW5kLCBCRkQgRGlzY3Jp bWluYXRvciBUTFYgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGlzDQo+IGlzIGEgQkZEIGJvb3RzdHJh cHBpbmcgaW5zdGVhZCBvZiBhIG5vcm1hbCBMU1AgUGluZy4gQW5hbG9nIHRvIHRoaXMsIGlmIHdl DQo+IHdhbnQgdG8gc3BlY2lmeSB0aGUgcmV0dXJuIHBhdGggb2YgQkZEIHNlc3Npb24sIHNlZW1z IGFkZCB0aGUgUlAgVExWIHRvDQo+IGlkZW50aWZ5IHRoZSByZXR1cm4gcGF0aCBpcyBuYXR1cmFs IGNob2ljZS4gQW5kIGZvciB0aGUgc2VnbWVudCByb3V0aW5nLCB3ZQ0KPiBqdXN0IG5lZWQgZGVm aW5lIG5ldyBzdWItVExWcy4NCg0KSSBzZWUgd2hlcmUgeW91IGFyZSBjb21pbmcgZnJvbSBNYWNo LCBidXQgbGV0IGNvdW50ZXItYXJndWUgZm9yIHRoZSBzYWtlIG9mIGRpc2N1c3Npb24gOikNCg0K VGFyZ2V0IEZFQyBTdGFjayBUTFYgKFRGUykgaXMgYSBUTFYgdGhhdCBpcyBhbHdheXMgcHJlc2Vu dCBpbiBhbiBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlLg0KDQpbU2VjdGlvbiAzLjIgb2YgUkZD NDM3OV0NCiAgIEFuIE1QTFMgZWNobyByZXF1ZXN0IE1VU1QgaGF2ZSBhIFRhcmdldCBGRUMgU3Rh Y2sgdGhhdCBkZXNjcmliZXMgdGhlDQogICBGRUMgU3RhY2sgYmVpbmcgdGVzdGVkLg0KDQpTbyBt b3N0IG90aGVyIFRMVnMgaW4gdGhlIE1QTFMgZWNobyByZXF1ZXN0IGFzc3VtZXMgdGhhdCBURlMg aXMgcHJlc2VudCBhbmQgaGFzIGluc3RydWN0aW9ucyB0byBkbyBmb28gZm9yIHRoZSBGRUMgZGVz Y3JpYmVkIGluIHRoZSBURlMsIHdoaWNoIGlzIHBlcmZlY3RseSBmaW5lIElNTy4gU28gSSB0aGlu ayBpdCBpcyBzdGlsbCBhcmd1YWJsZSB0aGF0IGlmIHdlIHdlcmUgdG8gaGF2ZSBCRkQtZm9vLTEs IEJGRC1mb28tMiBhbmQgQkZELWZvby0zIGluc3RydWN0aW9ucywgdGhlbiBwZXJoYXBzIGl0IGlz IG1vcmUgYmVuZWZpY2lhbCB0byBidW5kbGUgdGhlbSBpbnRvIGEgc2luZ2xlIEJGRC1mb28tVExW LCBhbmQgbWFrZSBlYWNoIGludG8gc3ViLVRMVnMgLi4uIGluc3RlYWQgb2YgaGF2aW5nIHNlcGFy YXRlIFRMVnMgZm9yIDEvMi8zLg0KDQo+IA0KPiA+IHN1Y2ggYSBnb29kIGlkZWEuIEJ1dCB3aGF0 IHdlIGRpc2N1c3NlZCB3YXMgaW50cm9kdWN0aW9uIG9mIEJGRA0KPiA+IENvbnRyb2wgVExWIHRv IGhhdmUgb3B0aW9uYWwgc3ViLVRMVjogQkZEIERpc2NyaW1pbmF0b3Igc3ViLVRMViwNCj4gPiBS ZXR1cm4gUGF0aCBzdWItVExWLCBldGMuIEl0IG1heSBiZSB0aGF0IHRoYXQgd2FzIG5vdCBhIGJh ZCBpZGVhIGFmdGVyIGFsbC4NCj4gDQo+IEN1cnJlbnRseSwgVGFyZ2V0IFN0YWNrIEZFQyBUTFYg YW5kIFJlcGx5IFBhdGggVExWIHNoYXJlIHRoZSBzYW1lIHN1Yi1UTFZzLg0KPiBBdCB0aGUgYmVn aW5uaW5nLCBSZXBseSBQYXRoIFRMViB3YW50cyBpdHMgb3duIHJlZ2lzdHJ5IGFuZCBob3BlIHRv IGJvcnJvdw0KPiBzb21lIHN1Yi1UTFZzIGZyb20gdGhlIFRhcmdldCBTdGFjayBGRUMgVExWLCBi dXQgaXQgdHVybmVkIG91dCB0byBiZSBhbg0KPiB1bnN1Y2Nlc3NmdWwgY2hvaWNlLCBhbmQgaXQg d2FzIHZlcnkgcGFpbmZ1bCB0byBkZXRlcm1pbmUgaG93IHRvIHByb2Nlc3MNCj4gdGhlIHJlZ2lz dHJ5LCB0aGVyZSB3YXMgYSBsb25nIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB3aGVuIHB1Ymxpc2gg UkZDNzExMC4NCj4gDQo+IFNvLCBpZiB5b3UgaW50cm9kdWNlIHRoZSBuZXcgQkZEIENvbnRyb2wg VExWLCB0aGUgc2FtZSBzaXR1YXRpb24gd2lsbCBvY2N1cg0KPiBhZ2FpbiwgeW91IGhhdmUgbWFr ZSBhIGRlY2lzaW9uIHdoZXRoZXIgQkZEIENvbnRyb2wgVExWIGhhcyBpdHMgb3duDQo+IHJlZ2lz dHJ5LCB3aGljaCBzdWItVExWcyBjYW4gYmUgY2FycmllZCBpbiBCRkQgQ29udHJvbCBUTFYsIGhv dyB0byBwcm9jZXNzDQo+IHRoZSBmdXR1cmUgZGVmaW5lZCBSZXBseSBQYXRoIHN1Yi1UTFZzLCBl dGMuDQoNClRoYXQncyBhIGdvb2QgcG9pbnQuIElmIEdyZWcncyBSZXZlcnNlIFBhdGggVExWIGFs c28gbmVlZHMgdG8gZGVzY3JpYmUgRkVDcyBvdGhlciB0aGFuIFNlZ21lbnRzLCB0aGVuIHdlIHBy b2JhYmx5IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgdHlwZSBkb2VzIG5vdCBjb2xsaWRlIHdpdGgg RkVDIHR5cGVzIGluIHRoZSBURlMuDQoNCj4gPiAyLiBNYWludGVuYW5jZSBvZiBib290c3RyYXBw ZWQgQkZEIHNlc3Npb25zIGlzIGZ1enp5LCBtZWFuaW5nIHdoZW4NCj4gPiBzaG91bGQgdGhlIGVn cmVzcyBkZWxldGUgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucy4gT25lIGNvdWxkDQo+ID4gaW1w bGVtZW50IHN1Y2ggdGhhdCB0aGUgZWdyZXNzIGRlbGV0ZXMgQkZEIHNlc3Npb25zIHdoZW4gY29y cmVzcG9uZGluZw0KPiA+IEZFQyBpcyBkZWxldGVkLCBvciBYIGFtb3VudCBvZiB0aW1lIGFmdGVy IHNlc3Npb25zIGdvICJkb3duIi4gVGhlcmUncw0KPiA+IG5vIEZFQy9zdGF0ZSBvbiB0aGUgZWdy ZXNzIGZvciBTZWdtZW50IFJvdXRpbmcuICBUaHVzIG9ubHkgcmVtYWluaW5nDQo+ID4gb3B0aW9u IHRvZGF5IGlzIHRvIGRlbGV0ZSB0aGUgc2Vzc2lvbiBhZnRlciBYIHNlY29uZHMvbWludXRlcyBv bmNlIHRoZQ0KPiA+IHNlc3Npb24gaXMgaW4gImRvd24iIHN0YXRlLiBQZXJoYXBzIHRoaXMgZnV6 emluZXNzIGlzIHJlYXNvbmFibGUsIG9yDQo+ID4gcGVyaGFwcyB3ZSB3YW50IGV4cGxpY2l0ICJk ZWxldGUiIGluc3RydWN0aW9uIGZyb20gdGhlIGluZ3Jlc3MgdG8gdGhlDQo+IGVncmVzcy4NCj4g PiBHSU0+PiBCRkQgKHNob3VsZCB3ZSByZWZlciB0byBpdCBub3cgYXMgImNsYXNzaWNhbCIgQkZE KSBtdXN0IGJlDQo+ID4gR0lNPj4gY29uZmlndXJlZA0KPiA+IGJlZm9yZSBpdCBiZSBib290c3Ry YXBwZWQgYnkgTFNQIHBpbmcuIFRvIGNsZWFuIHVwIGFueSByZXNpZHVhbCBzdGF0ZQ0KPiA+IGlu IHRoZSBkYXRhIHBsYW5lIG9wZXJhdG9yIHdvdWxkIG5lZWQganVzdCB0byByZW1vdmUgY29ycmVz cG9uZGluZw0KPiA+IEJGRCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIFMtQkZEIHdvdWxkIGJlIGRp ZmZlcmVudCBjYXNlLiBUaGUgZmFyLWVuZA0KPiA+IEJGRCBwZWVyIGlzLCBpbiBhIHdheSwgc3Rh dGVsZXNzIGJ1dCBpZiB3YXMgaW5zdHJ1Y3RlZCB0byB1c2Ugc3BlY2lmaWMNCj4gPiBwYXRoIHZp YSBCRkQgUmV2ZXJzZSBQYXRoIFRMViwgdGhlbiB0aGF0IHdpbGwgY3JlYXRlIGEgc3RhdGUgaW4g dGhlDQo+ID4gZGF0YSBwbGFuZS4gQ2xlYW5pbmcgaXQgdXAgbWF5IGJlIHJlcXVpcmVkIHRvIHBy ZXZlbnQgZXhoYXVzdGlvbiBvZiBhDQo+ID4gcmVzb3VyY2UgaW4gdGhlIGRhdGEgcGxhbmUuIENl cnRhaW5seSBncmVhdCB0b3BpYyBmb3IgZGlzY3Vzc2lvbiBpbiBUb3JvbnRvLg0KDQpbQ2xhc3Np Y2FsIEJGRF0NCldlbGwsIHllcyBjbGFzc2ljYWwgQkZEIHNlc3Npb25zIGFyZSBjb25maWd1cmVk IG9uIHRoZSBpbmdyZXNzLCBidXQgbm90IGV4cGxpY2l0bHkgY29uZmlndXJlZCBvbiB0aGUgZWdy ZXNzLCBoZW5jZSB0aGUgbmVlZCBmb3IgYm9vdHN0cmFwcGluZy4gTGlrZWx5LCBlZ3Jlc3Mgd2ls bCBoYXZlIGNvbmZpZ3VyYXRpb24gbGlrZSAiYWxsb3cgQkZEIGJvb3N0cmFwIHJlcXVlc3QgZnJv bSB0aGVzZSBub2RlcyIgYnV0IG5vdCAiYWxsb3cgQkZEIGJvb3RzdHJhcCByZXF1ZXN0IGZvciB0 aGVzZSBGRUNzIGZyb20gdGhlc2Ugbm9kZXMiLCBiZWNhdXNlIHRoZSBsYXR0ZXIgd2lsbCBiZSB2 ZXJ5IGRpZmZpY3VsdCB0byBtYWludGFpbiBub3QgdG8gbWVudGlvbiBpdCBnb2VzIGFnYWluc3Qg dGhlIHN0YXRlbGVzcyBuYXR1cmUgb2YgU2VnbWVudCBSb3V0aW5nIGF0IHRoZSBjb25maWd1cmF0 aW9uIGxldmVsLiBQb3NzaWJseToNCmEuIEJGRCBUTFYgY2FuIGluc3RydWN0IGVncmVzcyB0byBk ZWxldGUgdGhlIHNlc3Npb24uDQpiLiBCRkQgVExWIGhhcyAicHVyZ2UgdGltZXIiIGZpZWxkIHdo ZXJlIGVncmVzcyBpcyBleHBlY3RlZCB0byBkZWxldGUgdGhlIHNlc3Npb24gYWZ0ZXIgInB1cmdl IHRpbWVyIiBvbmNlIHRoZSBzZXNzaW9uIGdvZXMgZG93bi4NCmMuIEp1c3QgZGVzY3JpYmUgcHJv Y2VkdXJlcyBmb3IgZWdyZXNzIHRoYXQgaXQgY2FuIGRlbGV0ZSB0aGUgc2Vzc2lvbiBhZnRlciBz b21ldGltZSBvbmNlIHRoZSBzZXNzaW9uIGdvZXMgZG93bi4NCg0KW1MtQkZEXQ0KQWdyZWUsIEkg ZG9uJ3Qgc2VlIGhvdyB3ZSBjYW4gYWRkcmVzcyB0aGlzIHdpdGhvdXQgZWdyZXNzIGJlY29taW5n IGEgbGl0dGxlIHN0YXRlZnVsLiBBdCB0aGUgbGVhc3QsIGFuIFNCRkRSZWZsZWN0b3IgbmVlZHMg dG8ga2VlcCBbcmVtb3RlIElQIGFkZHJlc3MsIHJlbW90ZSBCRkQgZGlzY3JpbWluYXRvcl0gPSBy ZXR1cm4gcGF0aC4gQW5kIGluZ3Jlc3MgbmVlZHMgdG8gYmUgYWJsZSB0byBtYWludGFpbiB0aGlz Lg0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNCg== From nobody Thu Jul 3 09:50:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543021B294B; Thu, 3 Jul 2014 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K0uPp8eQkEz; Thu, 3 Jul 2014 09:50:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2663F1B2810; Thu, 3 Jul 2014 09:50:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703165010.10993.1977.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 09:50:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Sz4Vvpnb8J27ODyiXa5HRFbhyGE Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-bryant-mpls-oam-udp-return-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:50:11 -0000 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 Performance Measurement UDP Return Path Authors : Stewart Bryant Siva Sivabalan Sagar Soni Filename : draft-bryant-mpls-oam-udp-return-02.txt Pages : 8 Date : 2014-07-03 Abstract: This document specifies the proceedure to be used by the Packet Loss and Delay Measurement for MPLS Networks protocol defined in RFC6374 when sending and processing MPLS performance management out-of-band responses for delay and loss measurements over an IP/UDP return path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bryant-mpls-oam-udp-return/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-bryant-mpls-oam-udp-return-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-oam-udp-return-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 11:21:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957DB1A03B1 for ; Thu, 3 Jul 2014 11:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYmI-jGhYP0n for ; Thu, 3 Jul 2014 11:21:20 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810F11B2B28 for ; Thu, 3 Jul 2014 11:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12069; q=dns/txt; s=iport; t=1404411682; x=1405621282; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uVPF+xoq8k/fVSdACsR8P6ekY1YBnUmVdCiUN4ILZ1M=; b=PqAzqluNaCdrnvxEMjwAu38W9UW2Yksfw+MA1HMrMa+Wsi2ctYYLzx9z 37K7bK7lytNZzD5nJ766AVl7VuRtm3P94dx5T7wJQ/+C2OyDW+GLfw9ZO N6mIlSWhWipEUPF4MeCvC1h24AVNQRsCnMI+LUDkIRj1MtNncwvBvFRMK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAKOetVOtJV2T/2dsb2JhbABagw1SvzaHPwGBDBZ1hAMBAQEDAQEBASQLAQUvBAMKAQwCAgsRAQMBAQEJFggHCQMCAQIBCQwfAwYIBgEMAQUCAQGINggNyU4TBASJYYRbEQEdMwcGhD0BBJp2hw+MfINfIYE6 X-IronPort-AV: E=Sophos;i="5.01,596,1400025600"; d="scan'208";a="58145801" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 03 Jul 2014 18:21:21 +0000 Received: from [10.98.73.155] (bxb-vlim-88110.cisco.com [10.98.73.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s63ILHAS010877; Thu, 3 Jul 2014 18:21:17 GMT Message-ID: <53B59F1F.3000706@cisco.com> Date: Thu, 03 Jul 2014 14:21:19 -0400 From: Vanson Lim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Sam Aldrin , Mach Chen , Qin Wu References: <52C795FE.7060801@pi.nu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/988-nx_c5VX0SqTfICA3AwqO7FM Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 18:21:23 -0000 Just an update for everyone. Sam will be posting an update to the draft today/tomorrow with the changes to address the comments below. My annotated comments inline. Search for ###VLIM: The only thing remaining is a future update with the IANA assignments. Regards, -Vanson On 5/28/14, 9:04 PM, Sam Aldrin wrote: > Hi Mach and Qin, > > Please find response to comments embedded with ##RESP. > Sorry it took a while to respond but here it is anyway. > Let know if you have any further questions. We would like to make edits, close all open items and submit a new version of the draft to complete LC. > > > Comments from Qin: > > #1 > Hi, authors: > Have a quick look at this draft, It is not clear to me why proxy LSR doesn't need to wait for > The result of MPLS echo rely and then send MPLS proxy ping reply? > I know the draft says the receivers process the MPLS echo request, sending their > MPLS echo replies directly back to the initiator, however why bypass proxy LSR? > What about MPLS echo request initiating by proxy LSR is lost? How does the initiator > know the lost of MPLS echo request or reply? > What am I missing? > > ##RESP: LSP ping is designed with initiator initiating the request and maintaining the state for the same. All the transit or responding router do not maintain any state. Requiring Proxy LSRs to manage relaying the response would require it to maintain state for the entire transaction, including requiring the a timeout to be supplied by the initiator. This will require the change in architecture, which this draft is definitely not intending to do. > > > #2 > Also it is not very clear to me how to use reply mode 5, although the draft says > " > If the Reply Mode of the message header is 1 or is 5 and no errors or > modifications have occurred no MPLS proxy ping reply is sent. > " > ##RESP: There is no mention of reply mode 5. Which document are you referring to? The document refers only to mode 1, where, no reply SHOULD be sent for that mode. > > If the Reply Mode of the Proxy Request message header is "1 - do not > reply", no MPLS proxy ping reply is sent. Otherwise an MPLS proxy > ping reply message or MPLS echo request should be sent as described > below. > > #3 > It looks to me if no MPLS proxy ping rely needs to be sent, why define reply mode 5? > ###RESP: No mention of reply mode 5. If you are referring to reply mode 1, the question is for RFC4379. All I can say is, it is there to check unidirectional errors. > > #4 > Also there are a lot of nits and typos that need to be fixed, > s/ limiting the the number/ limiting the number > s/ motivaton/ motivation > s/ and and all autho-rization/ and all authorization > s/ Pprocedures/ Procedures > s/ sub-objexts/ sub-objects > s/ modificatons /modifications > s/ decribed/ described > s/ assigments/assignments > > ##RESP: Ack ###VLIM: Issue resolved. > > #5 > In section 5.2, there is no definition of reply to address field, I think it should be defined as initiator address > > ##RESP: This is the address the echo reply should be sent to, most likely the initiator, but could be something else. We will add text for the field. > > #6 > For Downstream Mapping objects, it is better to add a reference to RFC4379. > The references [McstPing] [mLDP] are now outdated and need to be updated to the corresponding RFC. > ##RESP - Ack. Will add references. ###VLIM: Changed all references of mDP to Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [RFC 6388] > > Regards! > -Qin > > > > ====== > > > 2) From Mach Chen > > Hi Authors, > > I just reviewed the draft, here are my comments, hope this help. > > General comments: > It would be better if you could adjust the structure of the draft to put Section 3 behind Section 5. Then the reader will not need to check definitions of the Messages and TLVs in the back and then return back keep reading the document. > > ##RESP - I feel it is good to have description before the actual format definition. Either case, one has to go back and forth to understand completely. Is there any hard preference to your suggestion? > > Specific comments: > > > 1. Section 2 > > If the source address of the MPLS echo request is not to be > set to the Proxy Request source address, the initiator must include a > Reply-to Address TLV containing the source address to use in the MPLS > echo request. > > Why we need the Reply-to Address TLV? Which address will be included in the Reply-to Address TLV? If the address is neither the initiror or the proxy LSR, this may import some security isses? > > ##RESP: We added this TLV for a reason, which at that time, was needed. From what we see now, the requestor IP will be used. Hence, this TLV will be removed. > > 2. Section 3.1 > > 2.1 > "The message MUST contain a Target FEC Stack that describes the FEC > being tested. The topmost FEC in the target FEC stack is used at the > Proxy LSR to lookup the MPLS label stack that will be used to > encapsulate the MPLS echo request packet. > " > Seems that it only needs to carry the topmost FEC, and no need to carry other FECs. And even if carried, it does not make sense. Right? > > > ##RESP: reused existing target fec stack, dont want to restrict to topmost FEC in case there are future uses. > > > 2.2 > s /MPLS Proxy Ping message/MPLS proxy ping request message, need to look through the document to make them consistent. > ##RESP - Ack. ###VLIM: One occurrence found in section 3.1, second paragraph, Also went through the entire document and changed all occurrences of Proxy Request/Reply, MPLS Proxy Ping/Proxy Reply, etc to MPLS proxy ping request and MPLS proxy ping reply. > > > 3. Section 3.1 the sixth paragraph: > "The Proxy Request reply mode is set with one of the reply modes > defined in [RFC4379] as appropriate." > > Is the reply mode here referred to the reply mode of the MPLS proxy request, or the reply mode of the Proxy Echo Parameter. I think it's the former, right? > > And section 5.1 said: > "The MPLS Proxy Echo request echo header's Reply Mode should be set to "Reply with Proxy Info"." > > Seems they are self-contradictory here. > > ##RESP - Not really. Sec 3 is describing the reply mode should use one of the modes defined in RFC4379. While Sec 5.1 is talking about the request to query info from proxy LSR. > > 4. Section 3.1 the last second paragraph: > > s /DDSMAP)/(DDSMAP) > > ##RESP - Ack ###VLIM: Found, changed DDSMAP) -> (DDMAP) > > 5. Section 3.2, in the middle of the fourth paragraph. > > "Other filters on FECs or MPLS echo request contents MAY be applied." > > > For a Proxy LSR, it will not receive any MPLS echo request, should it be the MPLS proxy ping request here? > > > ##RESP: The sentence is talking about proxy LSR sending MPLS echo request, not receiving. > > 6. Section 3.2.1 > > 6.1 In the middle of third paragraph: > > "If the Proxy LSR is a Budnode but not > requested to return a Proxy reply, the Proxy LSR should send packets > to the downstream neighbors (no Echo reply is sent to the Proxy > Initiator to indicate that the Proxy LSR is an egress). > " > > What packets will be sent to the downstream neighbors? > > ##RESP: MPLS Echo Request ###VLIM: Updated from send packets to send MPLS Echo Request packets ###VLIM: Update all occurrences of Proxy Reply, to MPLS proxy ping reply, ###VLIM: Update all occurrences of "MPLS echo request", to "MPLS Echo Request" > > 6.2 > If there is no DS/DDMAPs returned, how does the initiator determine the proxy LSR is budnode or egress? > > ##RESP: wanted to have the same behavior when injecting a LSP Ping at an egress. When we ping from a bud node, if we dont typically get an echo reply from ourselves, so we wanted to provide the ability for the Proxy requester to decide whether they want a proxy reply to by send back in response to a proxy request. is_egress return code used to indicate proxy lsr also an egress. > > > > 6.3 Last paragraph, last sentence > > s / M2MP leaf /MP2MP leaf > > ##RESP - ack ###VLIM: Updated > > 7. Section 3.2.4.1 > > 7.1 What's is "base MPLS echo request"? I suggest to remove the "base" here. > > ##RESP: Seems fine to remove. ###VLIM: 4 occurrences found, base removed. > > 7.2 > > "If the Explicit Differentiated Services Code Point (DSCP) flag is > set, the Requested DSCP byte is examined. If the setting is > permitted then the DSCP byte of the IP header of the MPLS Echo > Request message is set to that value. If the Proxy LSR does not > permit explicit control for the DSCP byte, the MPLS Proxy Echo > Parameters with the Explicit DSCP flag cleared MUST be included in > any MPLS proxy ping reply message to indicate why an Echo Request was > not sent. The return code MUST be set to , "Proxy ping > parameters need to be modified". If the Explicit DSCP flag is not > set, the Proxy LSR should set the Echo Request DSCP settings to the > value normally used to source LSP ping packets." > > I am not sure whether this is the right choice to let the Proxy LSR to control whether the DSCP is permitted or not. IMO, this permission should be controlled by the Receiver or Responder. > > ##RESP: This section is referring to the DSCP settings in the MPLS echo request label stack and ip header not the reply dscp. When initiating LSP pings, the sender of the lsp ping controls this setting, so it was felt that it be valuable to allow the sender of the proxy request to control this subject to restrictions imposed at the Proxy LSR. > > > > 8. Section 3.2.4.2 > > "If any additional labels are pushed > onto the stack, their TTLs are set to 255." > > what's this case? Can you clarify more about the case? > > ##RESP: Dont want to requester have have control of the ttls for tunnels not relevant to the FEC being tested. ###VLIM: Sam worked with Mach to address his concern with wording in this section. > > 9. Section 4.2 > " > The MPLS proxy ping request message MAY contain the following > TLVs: > " > You may also need to contain the Type 21 and 22 TLV. > > ##RESP: okay, well add these tlvs to the list of tlvs to be included in the proxy request for including into the echo requests. ###VLIM: Added 21 Reply Path [RFC7110] 22 Reply TC [RFC7110] > > 10.Section 5.1 > > s /MPLS Proxy Echo Request message /MPLS proxy ping request message, same as the above comment 2.2 > ##RESP - ack ###VLIM: Changed. > > > Best regards, > Mach > > Cheers > -sam > > >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >>> Sent: Saturday, January 04, 2014 1:03 PM >>> To: mpls@ietf.org >>> Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org >>> Subject: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping >>> >>> Working Group, >>> >>> this is to start a two week working group last call on >>> draft-ietf-mpls-proxy-lsp-ping-01.txt >>> >>> Please send your comments to working group mailing lists (mpls@ietf.org). >>> >>> We will do an IPR poll on this document in parallel thee wglc. >>> >>> There are three IPRs disclosures that relates to this document. >>> >>> The working group last call will end Friday January 20, 2914. >>> >>> /Loa >>> mpls wg co-chair >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > . > From nobody Thu Jul 3 12:29:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7056B1B2B2E; Thu, 3 Jul 2014 12:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6V5YYyFYCVJ; Thu, 3 Jul 2014 12:29:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2021A0398; Thu, 3 Jul 2014 12:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703192921.12414.93629.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 12:29:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VU2iWUZom81TlE54sd4IM3eOyxI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-proxy-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:29:23 -0000 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 : Proxy MPLS Echo Request Authors : George Swallow Vanson Lim Sam Aldrin Filename : draft-ietf-mpls-proxy-lsp-ping-02.txt Pages : 24 Date : 2014-07-03 Abstract: This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/root tracing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-proxy-lsp-ping-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-proxy-lsp-ping-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 12:31:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AB71B2B71 for ; Thu, 3 Jul 2014 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCzcsiofZxlu for ; Thu, 3 Jul 2014 12:31:20 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10261B2B61 for ; Thu, 3 Jul 2014 12:31:19 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id fp1so708120pdb.2 for ; Thu, 03 Jul 2014 12:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=G5EkQFfARqZPo/hcFbtgCz9745WgRkBNl+jPWFX5Wfc=; b=g57cDFnw7o6GQWHFKFJsNLIzUWkVLgFHZX5481256oe082NI9+mdcV6LKNTCfJi4Bf 0Ni7Tq9DUy2e2JSLhru7+xBixh1XbYATG1u53uTKXBuHcf8j9G4Dgp2TSEj8tlT+wwPo X8tlOVwwwWjM57fAIYqpFhhraA8DbTniDNvL6wYRZ2CkgByn1d8kolwU9eR154DhPai0 WUSa+vCPKo+CmWSM5+RbqYpEo1kxgtireTdFWJkNhZ4qQR+5Ld+F4m//GdwVw0EXHIur gaOwVIyL5TVzUfgjR0nmhssMSjHbzKM6jGDhTvLw5M9IEjQdHF8+mSc7JX/JtMcNfwfP tdjw== X-Received: by 10.70.118.99 with SMTP id kl3mr5827468pdb.110.1404415878689; Thu, 03 Jul 2014 12:31:18 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id u8sm5846593pds.92.2014.07.03.12.31.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 12:31:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CDC22017-A46A-406F-8525-2F44DEE4434D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sam Aldrin In-Reply-To: <53B59F1F.3000706@cisco.com> Date: Thu, 3 Jul 2014 12:31:15 -0700 Message-Id: References: <52C795FE.7060801@pi.nu> <53B59F1F.3000706@cisco.com> To: Vanson Lim X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vSBGEonqMH8CrdLSDAVzi6DzP2k Cc: "mpls@ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:31:23 -0000 --Apple-Mail=_CDC22017-A46A-406F-8525-2F44DEE4434D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Loa, We have posted a new version of the draft. It addressed comments raised by Mach and Qin. One pending item remaining is IANA assignments.=20 Kindly advise how to proceed in this matter and we could take care of = it. thanks -sam On Jul 3, 2014, at 11:21 AM, Vanson Lim wrote: > Just an update for everyone. Sam will be posting an update to the = draft today/tomorrow with the changes to address the comments below. = My annotated comments inline. Search for ###VLIM: >=20 > The only thing remaining is a future update with the IANA assignments. >=20 > Regards, >=20 > -Vanson >=20 >=20 >=20 > On 5/28/14, 9:04 PM, Sam Aldrin wrote: >> Hi Mach and Qin, >>=20 >> Please find response to comments embedded with ##RESP. >> Sorry it took a while to respond but here it is anyway. >> Let know if you have any further questions. We would like to make = edits, close all open items and submit a new version of the draft to = complete LC. >>=20 >>=20 >> Comments from Qin: >>=20 >> #1 >> Hi, authors: >> Have a quick look at this draft, It is not clear to me why proxy LSR = doesn't need to wait for >> The result of MPLS echo rely and then send MPLS proxy ping reply? >> I know the draft says the receivers process the MPLS echo request, = sending their >> MPLS echo replies directly back to the initiator, however why bypass = proxy LSR? >> What about MPLS echo request initiating by proxy LSR is lost? How = does the initiator >> know the lost of MPLS echo request or reply? >> What am I missing? >>=20 >> ##RESP: LSP ping is designed with initiator initiating the request = and maintaining the state for the same. All the transit or responding = router do not maintain any state. Requiring Proxy LSRs to manage = relaying the response would require it to maintain state for the entire = transaction, including requiring the a timeout to be supplied by the = initiator. This will require the change in architecture, which this = draft is definitely not intending to do. >>=20 >>=20 >> #2 >> Also it is not very clear to me how to use reply mode 5, although the = draft says >> " >> If the Reply Mode of the message header is 1 or is 5 and no errors or >> modifications have occurred no MPLS proxy ping reply is sent. >> " >> ##RESP: There is no mention of reply mode 5. Which document are you = referring to? The document refers only to mode 1, where, no reply SHOULD = be sent for that mode. >>=20 >> If the Reply Mode of the Proxy Request message header is "1 - do = not >> reply", no MPLS proxy ping reply is sent. Otherwise an MPLS proxy >> ping reply message or MPLS echo request should be sent as = described >> below. >>=20 >> #3 >> It looks to me if no MPLS proxy ping rely needs to be sent, why = define reply mode 5? >> ###RESP: No mention of reply mode 5. If you are referring to reply = mode 1, the question is for RFC4379. All I can say is, it is there to = check unidirectional errors. >>=20 >> #4 >> Also there are a lot of nits and typos that need to be fixed, >> s/ limiting the the number/ limiting the number >> s/ motivaton/ motivation >> s/ and and all autho-rization/ and all authorization >> s/ Pprocedures/ Procedures >> s/ sub-objexts/ sub-objects >> s/ modificatons /modifications >> s/ decribed/ described >> s/ assigments/assignments >>=20 >> ##RESP: Ack >=20 > ###VLIM: Issue resolved. >>=20 >> #5 >> In section 5.2, there is no definition of reply to address field, I = think it should be defined as initiator address >>=20 >> ##RESP: This is the address the echo reply should be sent to, most = likely the initiator, but could be something else. We will add text for = the field. >>=20 >> #6 >> For Downstream Mapping objects, it is better to add a reference to = RFC4379. >> The references [McstPing] [mLDP] are now outdated and need to be = updated to the corresponding RFC. >> ##RESP - Ack. Will add references. >=20 > ###VLIM: Changed all references of mDP to =93Label Distribution = Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint = Label Switched Paths [RFC 6388] >>=20 >> Regards! >> -Qin >>=20 >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D >>=20 >>=20 >> 2) =46rom Mach Chen >>=20 >> Hi Authors, >>=20 >> I just reviewed the draft, here are my comments, hope this help. >>=20 >> General comments: >> It would be better if you could adjust the structure of the draft to = put Section 3 behind Section 5. Then the reader will not need to check = definitions of the Messages and TLVs in the back and then return back = keep reading the document. >>=20 >> ##RESP - I feel it is good to have description before the actual = format definition. Either case, one has to go back and forth to = understand completely. Is there any hard preference to your suggestion? >>=20 >> Specific comments: >>=20 >>=20 >> 1. Section 2 >>=20 >> If the source address of the MPLS echo request is not to be >> set to the Proxy Request source address, the initiator must = include a >> Reply-to Address TLV containing the source address to use in the = MPLS >> echo request. >>=20 >> Why we need the Reply-to Address TLV? Which address will be included = in the Reply-to Address TLV? If the address is neither the initiror or = the proxy LSR, this may import some security isses? >>=20 >> ##RESP: We added this TLV for a reason, which at that time, was = needed. =46rom what we see now, the requestor IP will be used. Hence, = this TLV will be removed. >>=20 >> 2. Section 3.1 >>=20 >> 2.1 >> "The message MUST contain a Target FEC Stack that describes the FEC >> being tested. The topmost FEC in the target FEC stack is used at = the >> Proxy LSR to lookup the MPLS label stack that will be used to >> encapsulate the MPLS echo request packet. >> " >> Seems that it only needs to carry the topmost FEC, and no need to = carry other FECs. And even if carried, it does not make sense. Right? >>=20 >>=20 >> ##RESP: reused existing target fec stack, don=92t want to restrict = to topmost FEC in case there are future uses. >>=20 >>=20 >> 2.2 >> s /MPLS Proxy Ping message/MPLS proxy ping request message, need to = look through the document to make them consistent. >> ##RESP - Ack. >=20 > ###VLIM: One occurrence found in section 3.1, second paragraph, Also = went through the entire document and changed all occurrences of Proxy = Request/Reply, MPLS Proxy Ping/Proxy Reply, etc to =93MPLS proxy ping = request=94 and =93MPLS proxy ping reply=94. >=20 >=20 >>=20 >>=20 >> 3. Section 3.1 the sixth paragraph: >> "The Proxy Request reply mode is set with one of the reply modes >> defined in [RFC4379] as appropriate." >>=20 >> Is the reply mode here referred to the reply mode of the MPLS proxy = request, or the reply mode of the Proxy Echo Parameter. I think it's the = former, right? >>=20 >> And section 5.1 said: >> "The MPLS Proxy Echo request echo header's Reply Mode should be set = to "Reply with Proxy Info"." >>=20 >> Seems they are self-contradictory here. >>=20 >> ##RESP - Not really. Sec 3 is describing the reply mode should use = one of the modes defined in RFC4379. While Sec 5.1 is talking about the = request to query info from proxy LSR. >>=20 >> 4. Section 3.1 the last second paragraph: >>=20 >> s /DDSMAP)/(DDSMAP) >>=20 >> ##RESP - Ack >=20 > ###VLIM: Found, changed =93DDSMAP)=94 -> =93(DDMAP)=94 >=20 >>=20 >> 5. Section 3.2, in the middle of the fourth paragraph. >>=20 >> "Other filters on FECs or MPLS echo request contents MAY be applied." >>=20 >>=20 >> For a Proxy LSR, it will not receive any MPLS echo request, should it = be the MPLS proxy ping request here? >>=20 >>=20 >> ##RESP: The sentence is talking about proxy LSR sending MPLS echo = request, not receiving. >>=20 >> 6. Section 3.2.1 >>=20 >> 6.1 In the middle of third paragraph: >>=20 >> "If the Proxy LSR is a Budnode but not >> requested to return a Proxy reply, the Proxy LSR should send = packets >> to the downstream neighbors (no Echo reply is sent to the Proxy >> Initiator to indicate that the Proxy LSR is an egress). >> " >>=20 >> What packets will be sent to the downstream neighbors? >>=20 >> ##RESP: =93MPLS Echo Request=94 >=20 > ###VLIM: Updated from =93send packets=94 to =93send MPLS Echo Request = packets=94 > ###VLIM: Update all occurrences of Proxy Reply, to MPLS proxy ping = reply, > ###VLIM: Update all occurrences of "MPLS echo request", to "MPLS Echo = Request" >>=20 >> 6.2 >> If there is no DS/DDMAPs returned, how does the initiator determine = the proxy LSR is budnode or egress? >>=20 >> ##RESP: wanted to have the same behavior when injecting a LSP Ping at = an egress. When we ping from a bud node, if we don=92t typically get = an echo reply from ourselves, so we wanted to provide the ability for = the Proxy requester to decide whether they want a proxy reply to by send = back in response to a proxy request. is_egress return code used to = indicate proxy lsr also an egress. >>=20 >>=20 >>=20 >> 6.3 Last paragraph, last sentence >>=20 >> s / M2MP leaf /MP2MP leaf >>=20 >> ##RESP - ack >=20 > ###VLIM: Updated >>=20 >> 7. Section 3.2.4.1 >>=20 >> 7.1 What's is "base MPLS echo request"? I suggest to remove the = "base" here. >>=20 >> ##RESP: Seems fine to remove. > ###VLIM: 4 occurrences found, =93base=94 removed. >=20 >=20 >>=20 >> 7.2 >>=20 >> "If the Explicit Differentiated Services Code Point (DSCP) flag is >> set, the Requested DSCP byte is examined. If the setting is >> permitted then the DSCP byte of the IP header of the MPLS Echo >> Request message is set to that value. If the Proxy LSR does not >> permit explicit control for the DSCP byte, the MPLS Proxy Echo >> Parameters with the Explicit DSCP flag cleared MUST be included in >> any MPLS proxy ping reply message to indicate why an Echo Request = was >> not sent. The return code MUST be set to , "Proxy ping >> parameters need to be modified". If the Explicit DSCP flag is not >> set, the Proxy LSR should set the Echo Request DSCP settings to = the >> value normally used to source LSP ping packets." >>=20 >> I am not sure whether this is the right choice to let the Proxy LSR = to control whether the DSCP is permitted or not. IMO, this permission = should be controlled by the Receiver or Responder. >>=20 >> ##RESP: This section is referring to the DSCP settings in the MPLS = echo request label stack and ip header not the reply dscp. When = initiating LSP pings, the sender of the lsp ping controls this setting, = so it was felt that it be valuable to allow the sender of the proxy = request to control this subject to restrictions imposed at the Proxy = LSR. >>=20 >>=20 >>=20 >> 8. Section 3.2.4.2 >>=20 >> "If any additional labels are pushed >> onto the stack, their TTLs are set to 255." >>=20 >> what's this case? Can you clarify more about the case? >>=20 >> ##RESP: Don=92t want to requester have have control of the ttls for = tunnels not relevant to the FEC being tested. > ###VLIM: Sam worked with Mach to address his concern with wording in = this section. >=20 >=20 >>=20 >> 9. Section 4.2 >> " >> The MPLS proxy ping request message MAY contain the following >> TLVs: >> " >> You may also need to contain the Type 21 and 22 TLV. >>=20 >> ##RESP: okay, we=92ll add these tlv=92s to the list of tlv=92s to be = included in the proxy request for including into the echo requests. >=20 > ###VLIM: Added > 21 Reply Path [RFC7110] > 22 Reply TC [RFC7110] >>=20 >> 10.Section 5.1 >>=20 >> s /MPLS Proxy Echo Request message /MPLS proxy ping request message, = same as the above comment 2.2 >> ##RESP - ack >=20 > ###VLIM: Changed. >=20 >>=20 >>=20 >> Best regards, >> Mach >>=20 >> Cheers >> -sam >>=20 >>=20 >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa = Andersson >>>> Sent: Saturday, January 04, 2014 1:03 PM >>>> To: mpls@ietf.org >>>> Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org >>>> Subject: [mpls] Working group last call on = draft-ietf-mpls-proxy-lsp-ping >>>>=20 >>>> Working Group, >>>>=20 >>>> this is to start a two week working group last call on >>>> draft-ietf-mpls-proxy-lsp-ping-01.txt >>>>=20 >>>> Please send your comments to working group mailing lists = (mpls@ietf.org). >>>>=20 >>>> We will do an IPR poll on this document in parallel thee wglc. >>>>=20 >>>> There are three IPRs disclosures that relates to this document. >>>>=20 >>>> The working group last call will end Friday January 20, 2914. >>>>=20 >>>> /Loa >>>> mpls wg co-chair >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> . --Apple-Mail=_CDC22017-A46A-406F-8525-2F44DEE4434D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Loa,

We have posted a new version of the = draft.
It addressed comments raised by Mach and = Qin.

One pending item remaining is IANA = assignments. 
Kindly advise how to proceed in this matter = and we could take care of = it.

thanks
-sam
On Jul = 3, 2014, at 11:21 AM, Vanson Lim <vlim@cisco.com> wrote:

Just an update for everyone.  Sam = will be posting an update to the draft today/tomorrow with the changes = to address the comments below.   My annotated comments inline. = Search for ###VLIM:

The only thing remaining is a future update = with the IANA = assignments.

Regards,

-Vanson



On 5/28/14, = 9:04 PM, Sam Aldrin wrote:
Hi Mach and = Qin,

Please find response to comments embedded with = ##RESP.
Sorry it took a while to respond but here it is = anyway.
Let know if you have any further questions. We would like to = make edits, close all open items and submit a new version of the draft = to complete LC.


Comments from Qin:

#1
Hi, = authors:
Have a quick look at this draft, It is not clear to me why = proxy LSR doesn't need to wait for
The result of MPLS echo rely and = then send MPLS proxy ping reply?
I know the draft says the receivers = process the MPLS echo request, sending their
MPLS echo replies = directly back to the initiator, however why bypass proxy LSR?
What = about MPLS echo request initiating by proxy LSR is lost? How does the = initiator
know the lost of MPLS echo request or reply?
What am I = missing?

##RESP:   LSP ping is designed with initiator = initiating the request and maintaining the state for the same. All the = transit or responding router do not maintain any state. Requiring Proxy = LSRs to manage relaying the response would require it to maintain state = for the entire transaction, including requiring the a timeout to be = supplied by the initiator. This will require the change in architecture, = which this draft is definitely not intending to = do.


#2
Also it is not very clear to me how to use reply = mode 5, although the draft says
"
If the Reply Mode of the message = header is 1 or is 5 and no errors or
modifications have occurred no = MPLS proxy ping reply is sent.
"
##RESP:  There is no mention = of reply mode 5. Which document are you referring to? The document = refers only to mode 1, where, no reply SHOULD be sent for that = mode.

   If the Reply Mode of the Proxy Request = message header is "1 - do not
   reply", no MPLS proxy = ping reply is sent.  Otherwise an MPLS = proxy
   ping reply message or MPLS echo request = should be sent as described
   below.

#3
It = looks to me if no MPLS proxy ping rely needs to be sent, why define = reply mode 5?
###RESP:  No mention of reply mode 5. If you are = referring to reply mode 1, the question is for RFC4379. All I can say = is, it is there to check unidirectional errors.

#4
Also there = are a lot of nits and typos that need to be fixed,
s/ limiting the = the number/ limiting the number
s/ motivaton/ motivation
s/ and = and all autho-rization/ and all authorization
s/ Pprocedures/ = Procedures
s/ sub-objexts/ sub-objects
s/ modificatons = /modifications
s/ decribed/ described
s/ = assigments/assignments

##RESP: Ack

###VLIM: =  Issue resolved.

#5
In section = 5.2, there is no definition of reply to address field, I think it should = be defined as initiator address

##RESP:  This is the address = the echo reply should be sent to,  most likely the initiator, but = could be something else. We will add text for the = field.

#6
For Downstream Mapping objects, it is better to add = a reference to RFC4379.
The references [McstPing] [mLDP] are now = outdated and need to be updated to the corresponding RFC.
##RESP - = Ack. Will add references.

###VLIM: Changed all = references of mDP to =93Label Distribution Protocol Extensions for = Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths = [RFC 6388]

Regards!
-Qin



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

2) =46rom Mach Chen

Hi Authors,

I just reviewed the = draft, here are my comments, hope this help.

General = comments:
It would be better if you could adjust the structure of the = draft to put Section 3 behind Section 5. Then the reader will not need = to check definitions of the Messages and TLVs in the back and then = return back keep reading the document.

##RESP - I feel it is good = to have description before the actual format definition. Either case, = one has to go back and forth to understand completely. Is there any hard = preference to your suggestion?

Specific comments:


1. = Section 2

If the source address of the MPLS echo request is not = to be
   set to the Proxy Request source address, the = initiator must include a
   Reply-to Address TLV = containing the source address to use in the = MPLS
   echo request.

Why we need the Reply-to = Address TLV? Which address will be included in the Reply-to Address TLV? = If the address is neither the initiror or the proxy LSR, this may import = some security isses?

##RESP: We added this TLV for a reason, = which at that time, was needed. =46rom what we see now, the requestor IP = will be used. Hence, this TLV will be removed.

2. Section = 3.1

2.1
"The message MUST contain a Target FEC Stack that = describes the FEC
   being tested.  The topmost = FEC in the target FEC stack is used at the
   Proxy = LSR to lookup the MPLS label stack that will be used = to
   encapsulate the MPLS echo request = packet.
"
Seems that it only needs to carry the topmost FEC, and = no need to carry other FECs. And even if carried, it does not make = sense. Right?


##RESP:  reused existing target fec stack, =  don=92t want to restrict to topmost FEC in case there are future = uses.


2.2
s /MPLS Proxy Ping message/MPLS proxy ping = request message, need to look through the document to make them = consistent.
##RESP - Ack.

###VLIM:  One = occurrence found in section 3.1, second paragraph, Also went through the = entire document and changed all occurrences of Proxy Request/Reply, =  MPLS Proxy Ping/Proxy Reply, etc to =93MPLS proxy ping request=94 = and =93MPLS proxy ping reply=94.




3. Section 3.1 the sixth paragraph:
"The Proxy = Request reply mode is set with one of the reply = modes
   defined in [RFC4379] as = appropriate."

Is the reply mode here referred to the reply mode = of the MPLS proxy request, or the reply mode of the Proxy Echo = Parameter. I think it's the former, right?

And section 5.1 = said:
"The MPLS Proxy Echo request echo header's Reply Mode should be = set to "Reply with Proxy Info"."

Seems they are = self-contradictory here.

##RESP - Not really. Sec 3 is describing = the reply mode should use one of the modes defined in RFC4379. While Sec = 5.1 is talking about the request to query info from proxy LSR.

4. = Section 3.1 the last second paragraph:

s = /DDSMAP)/(DDSMAP)

##RESP - Ack

###VLIM: = Found, changed =93DDSMAP)=94 -> =93(DDMAP)=94


5. Section 3.2, in the middle of the fourth = paragraph.

"Other filters on FECs or MPLS echo request contents = MAY be applied."


For a Proxy LSR, it will not receive any = MPLS echo request, should it be the MPLS proxy ping request = here?


##RESP:  The sentence is talking about proxy LSR = sending MPLS echo request, not receiving.

6. Section = 3.2.1

6.1 In the middle of third paragraph:

"If the Proxy = LSR is a Budnode but not
   requested to return a = Proxy reply, the Proxy LSR should send packets
   to = the downstream neighbors (no Echo reply is sent to the = Proxy
   Initiator to indicate that the Proxy LSR is = an egress).
"

What packets will be sent to the downstream = neighbors?

##RESP:  =93MPLS Echo = Request=94

###VLIM:  Updated from =93send = packets=94 to =93send MPLS Echo Request packets=94
###VLIM: =  Update all occurrences of Proxy Reply, to MPLS proxy ping = reply,
###VLIM:  Update all occurrences of "MPLS echo request", = to "MPLS Echo Request"

6.2
If there = is no DS/DDMAPs returned, how does the initiator determine the proxy LSR = is budnode or egress?

##RESP: wanted to have the same behavior = when injecting a LSP Ping at an egress.  When we ping from a bud = node,  if we  don=92t typically get an echo reply from = ourselves,  so we wanted to provide the ability for the Proxy = requester to decide whether they want a proxy reply to by send back in = response to a proxy request.  is_egress return code used to = indicate proxy lsr also an egress.



6.3 Last paragraph, = last sentence

s / M2MP leaf /MP2MP leaf

##RESP - = ack

###VLIM:  Updated

7. Section 3.2.4.1

7.1 What's is "base MPLS = echo request"? I suggest to remove the "base" here.

##RESP: Seems = fine to remove.
###VLIM:  4 occurrences found, =  =93base=94 removed.



7.2

"If the Explicit Differentiated Services = Code Point (DSCP) flag is
   set, the Requested DSCP = byte is examined.  If the setting is
   permitted = then the DSCP byte of the IP header of the MPLS = Echo
   Request message is set to that value.  If = the Proxy LSR does not
   permit explicit control for = the DSCP byte, the MPLS Proxy Echo
   Parameters with = the Explicit DSCP flag cleared MUST be included = in
   any MPLS proxy ping reply message to indicate = why an Echo Request was
   not sent.  The return = code MUST be set to <tba>, "Proxy = ping
   parameters need to be modified".  If the = Explicit DSCP flag is not
   set, the Proxy LSR should = set the Echo Request DSCP settings to the
   value = normally used to source LSP ping packets."

I am not sure whether = this is the right choice to let the Proxy LSR to control whether the = DSCP is permitted or not. IMO, this permission should be controlled by = the Receiver or Responder.

##RESP:  This section is = referring to the DSCP settings in the MPLS echo request label stack and = ip header not the reply dscp.   When initiating LSP pings, the = sender of the lsp ping controls this setting, so it was felt that it be = valuable to allow the sender of the proxy request to control this = subject to restrictions imposed at the Proxy LSR.



8. =  Section 3.2.4.2

"If any additional labels are = pushed
   onto the stack, their TTLs are set to = 255."

what's this case? Can you clarify more about the = case?

##RESP:  Don=92t want to requester have have control = of the ttls for tunnels not relevant to the FEC being = tested.
###VLIM:  Sam worked with Mach to address = his concern with wording in this section.



9. Section 4.2
"
 The MPLS proxy ping = request message MAY contain the = following
   TLVs:
"
You may also need to = contain the Type 21 and 22 TLV.

##RESP:  okay, we=92ll add = these tlv=92s to the list of tlv=92s to be included in the proxy request = for including into the echo requests.

###VLIM: = Added
21    Reply Path =    [RFC7110]
22    Reply TC =    [RFC7110]

10.Section = 5.1

s /MPLS Proxy Echo Request message /MPLS proxy ping request = message, same as the above comment 2.2
##RESP - = ack

###VLIM:   Changed.



Best = regards,
Mach

Cheers
-sam


-----Original = Message-----
From: mpls [mailto:mpls-bounces@ietf.org] = On Behalf Of Loa Andersson
Sent: Saturday, January 04, 2014 1:03 = PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org;= draft-ietf-m= pls-proxy-lsp-ping@tools.ietf.org
Subject: [mpls] Working group = last call on draft-ietf-mpls-proxy-lsp-ping

Working = Group,

this is to start a two week working group last call = on
draft-ietf-mpls-proxy-lsp-ping-01.txt

Please send your = comments to working group mailing lists (mpls@ietf.org).

We will do an = IPR poll on this document in parallel thee wglc.

There are three = IPRs disclosures that relates to this document.

The working group = last call will end Friday January 20, 2914.

/Loa
mpls wg = co-chair

--


Loa Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior = MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu
Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls
.

= --Apple-Mail=_CDC22017-A46A-406F-8525-2F44DEE4434D-- From nobody Thu Jul 3 15:48:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9371A0496 for ; Thu, 3 Jul 2014 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eUy6X8cotbB for ; Thu, 3 Jul 2014 15:48:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA721A045D for ; Thu, 3 Jul 2014 15:48:01 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s63MlwcL010048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jul 2014 17:47:59 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s63Mlwn5018720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 18:47:58 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 3 Jul 2014 18:47:58 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAA= Date: Thu, 3 Jul 2014 22:47:57 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340D946C86F6US70UWXCHMBA01z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/S6fnJZuyp0bXJ9bCOAmIZXM05pM Cc: "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:48:04 -0000 --_000_4A79394211F1AF4EB57D998426C9340D946C86F6US70UWXCHMBA01z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I was asked to review this draft and I think it describes valid issues to b= e resolved. I however have a couple of comments about the way the authors w= ent about to address them. 1. Relation to RFC 7110 - Return Path Specified Label Switched Path (LSP= ) Ping. Section 4.1 argues the reason why a separate reply mode is needed is for wa= nting to omit the Reply Path TLV defined in RFC 7110 when the sender of the= echo request just wanted to use the return path of the tested LSP. I do no= t see this as a strong justification. In many cases, the LSP is unidirectio= nal or the responder node is a transit LSR and may not be able to inject th= e reply in the reverse direction of that LSP. In that case, I can see that = providing a specific return LSP which is different than the tested LSP is r= equired and the Reply Path TLV is needed. Assuming this is still an important issue for the authors, I would suggest = to relax the rule in RFC 7110 such that if the echo request includes reply = mode 5 "Reply via Specified Path" and the Reply Path TLV is not included, t= he responder node will interpret this as an implicit request to reply via t= he reverse direction of the tested LSP. 2. Reply Mode Order TLV I am not convinced of the need for this TLV. There is not much reply modes = which are usable today together. Only reply mode 2 can be concurrently used= with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not very po= pular as far as I know. Also, most applications would reply with mode 2 if = the requested mode is not available. So, I can't see how this new TLV will = be useful in practice. Regards, Mustapha. --_000_4A79394211F1AF4EB57D998426C9340D946C86F6US70UWXCHMBA01z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

I was asked to review this draft and I th= ink it describes valid issues to be resolved. I however have a couple of co= mments about the way the authors went about to address them.

 

1.<= span style=3D"font:7.0pt "Times New Roman"">    Relation to RFC 7110 - Return Pat= h Specified Label Switched Path (LSP) Ping.

Section 4.1 argues the reason why = a separate reply mode is needed is for wanting to omit the Reply Path TLV d= efined in RFC 7110 when the sender of the echo request just wanted to use the return path of the tested LSP. I do not see this as a st= rong justification. In many cases, the LSP is unidirectional or the respond= er node is a transit LSR and may not be able to inject the reply in the rev= erse direction of that LSP. In that case, I can see that providing a specific return LSP which is different th= an the tested LSP is required and the Reply Path TLV is needed.<= /span>

Assuming this is still an importan= t issue for the authors, I would suggest to relax the rule in RFC 7110 such= that if the echo request includes reply mode 5 “Reply via Specified Path” and the Reply Path TLV is not included, the responde= r node will interpret this as an implicit request to reply via the reverse = direction of the tested LSP.

 

2.<= span style=3D"font:7.0pt "Times New Roman"">    Reply Mode Order TLV

I am not convinced of the need for= this TLV. There is not much reply modes which are usable today together. O= nly reply mode 2 can be concurrently used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not very popular as far as = I know. Also, most applications would reply with mode 2 if the requested mo= de is not available. So, I can’t see how this new TLV will be useful = in practice.

 

Regards,

Mustapha.

--_000_4A79394211F1AF4EB57D998426C9340D946C86F6US70UWXCHMBA01z_-- From nobody Thu Jul 3 16:16:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3E31B2ABA for ; Thu, 3 Jul 2014 16:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWZJLlfQWab5 for ; Thu, 3 Jul 2014 16:16:20 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF641B2AAC for ; Thu, 3 Jul 2014 16:16:20 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kq14so961022pab.34 for ; Thu, 03 Jul 2014 16:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=zT9Ert3DXt+JyM/GU8owuVggBl+z6cFdEGGiWcCO6V8=; b=b9XvjD65bhjJSCA0qzMukkjB/mngU4zkoNLL00akzUapDSyBp/zhP4I9U0HFT2D9Z7 7phgTaCO+AliZauCHZbd8vtVhf4TSUo9KtgMYCS/n5O+EnGXf6nKoeJzsP+wsJoK8zi1 NkCsy1RWbl/iNWEdnvPl6K88PbZCJjfnKPgJO9PMPFIMuCbcIOhxjKvq9K5Y0thRjx4Q OD0fKhZ8iQ5X5T+mwSggCgFi2J7jfYjf+3JHu+8saMWnw9oQao9c4HaOnuC3fNznQ/1d A1TPsF/DfdywXAvmBcc2AJbvxuCzLXW1q/xJo3qoopY/olqGX/1OwkFK5Cx5jB2vYYgs aKWQ== X-Received: by 10.66.132.36 with SMTP id or4mr7522322pab.42.1404429379875; Thu, 03 Jul 2014 16:16:19 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id w16sm6297644pdl.36.2014.07.03.16.16.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 16:16:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F446718F-1F29-456C-B3D4-58739C0962CE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sam Aldrin In-Reply-To: <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> Date: Thu, 3 Jul 2014 16:16:16 -0700 Message-Id: <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> To: "Aissaoui, Mustapha (Mustapha)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/GEXwyFl-nZr70dscNkvgrcfRUI4 Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 23:16:23 -0000 --Apple-Mail=_F446718F-1F29-456C-B3D4-58739C0962CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Authors, I too raised the below points highlighted by Mustapha, earlier. In = addition I have a more high-level question. In the Introduction it says=20 "However, it is becoming increasingly difficult for an initiator to select a valid return path to encode in the MPLS LSP echo request packets. If the initiator does not select a valid return path, the MPLS LSP echo reply will not get back to the initiator. This results in a false failure of MPLS LSP Ping and Traceroute operation. In an effort to minimize such false failures, different implementations have chosen different default return path encoding for different LSP types and LSP operations. The problem with implementations having different default return path encoding is that the MPLS echo reply will not work in many cases, and the default value may not be the preferred choice by the operators. " The problems I have is regarding the need for this ID are 1. Can we solve the problem without the need for this ID/solution?=20 Answer is yes, albeit it takes one or more requests. If you say, it is = solving a problem which was couldn=92t be solved earlier, I would like = to see. 2. The proposal still cannot identify the problem even with multiple = reply modes. If reply cannot be received, adding more reply types may = not solve the issue. 3. This proposed solution works only if the problem is on the replying = node. But if the problem is on the transit node of the reply path, this = solution will not work either. 4. As I mentioned earlier, for this new proposal to work effectively, = the responding device has to support this new TLV. Which means, whole of = the network has to support at one point of time of the other. 5. With the proposed solution, to determine the problem, one also needs = to read the =91reply mode=92 used by the replying device. IOW, return = code + reply mode used will actually define the behavior. This changes = the definition of RFC4379.=20 6. Specific to the text above, I do not agree that the problem is due to = implementation. It is the user choice which ever reply mode he/she wants = to use. If using CLI, could chose different reply mode. If it is = application, he/she could select it there.=20 The point is, why to introduce this optimization solution, where one = could solve the problem without any of this new upgrade? Alternatively, for ex: If the reply was being received with reply mode = =915, but now I don=92t receive it now, send a new request with reply = mode 1.=20 This is more simple than the proposed solution without needing any = change. I=92d be open to hearing the strong reason, this ID is solving, which = couldn=92t be solved with RFC4379. cheers -sam On Jul 3, 2014, at 3:47 PM, Aissaoui, Mustapha (Mustapha) = wrote: > Dear all, > I was asked to review this draft and I think it describes valid issues = to be resolved. I however have a couple of comments about the way the = authors went about to address them. > =20 > 1. Relation to RFC 7110 - Return Path Specified Label Switched Path = (LSP) Ping. > Section 4.1 argues the reason why a separate reply mode is needed is = for wanting to omit the Reply Path TLV defined in RFC 7110 when the = sender of the echo request just wanted to use the return path of the = tested LSP. I do not see this as a strong justification. In many cases, = the LSP is unidirectional or the responder node is a transit LSR and may = not be able to inject the reply in the reverse direction of that LSP. In = that case, I can see that providing a specific return LSP which is = different than the tested LSP is required and the Reply Path TLV is = needed. > Assuming this is still an important issue for the authors, I would = suggest to relax the rule in RFC 7110 such that if the echo request = includes reply mode 5 =93Reply via Specified Path=94 and the Reply Path = TLV is not included, the responder node will interpret this as an = implicit request to reply via the reverse direction of the tested LSP. > =20 > 2. Reply Mode Order TLV > I am not convinced of the need for this TLV. There is not much reply = modes which are usable today together. Only reply mode 2 can be = concurrently used with reply mode 5 in RFC 7110 or reply mode 4. Reply = mode 3 is not very popular as far as I know. Also, most applications = would reply with mode 2 if the requested mode is not available. So, I = can=92t see how this new TLV will be useful in practice. > =20 > Regards, > Mustapha. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_F446718F-1F29-456C-B3D4-58739C0962CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Authors,

I too raised the below = points highlighted by Mustapha, earlier. In addition I have a more = high-level question.

In the Introduction it = says 
"However, it is becoming increasingly difficult for an initiator = to
   select a valid return path to =
encode in the MPLS LSP echo request
   packets.  If the initiator does not select a valid return path, the
   MPLS LSP echo reply will not get back to the initiator.  This results
   in a false failure of MPLS LSP Ping and Traceroute operation.  In an
   effort to minimize such false failures, different implementations
   have chosen different default return path encoding for different LSP
   types and LSP operations.  The problem with implementations having
   different default return path encoding is that the MPLS echo reply
   will not work in many cases, and the default value may not be the
   preferred choice by the =
operators.
"

The problems I have is = regarding the need for this ID are
1. Can we solve the problem = without the need for this ID/solution? 
Answer is yes, = albeit it takes one or more requests. If you say, it is solving a = problem which was couldn=92t be solved earlier, I would like to = see.
2. The proposal still cannot identify the problem even = with multiple reply modes. If reply cannot be received, adding more = reply types may not solve the issue.
3. This proposed solution = works only if the problem is on the replying node. But if the problem is = on the transit node of the reply path, this solution will not work = either.
4. As I mentioned earlier, for this new proposal to = work effectively, the responding device has to support this new TLV. = Which means, whole of the network has to support at one point of time of = the other.
5. With the proposed solution, to determine the = problem, one also needs to read the =91reply mode=92 used by the = replying device. IOW, return code + reply mode used will actually define = the behavior. This changes the definition of RFC4379. 
6. = Specific to the text above, I do not agree that the problem is due to = implementation. It is the user choice which ever reply mode he/she wants = to use. If using CLI, could chose different reply mode. If it is = application, he/she could select it = there. 

The point is, why to introduce = this optimization solution, where one could solve the problem without = any of this new upgrade?
Alternatively, for ex: If the reply = was being received with reply mode =915, but now I don=92t receive it = now, send a new request with reply mode 1. 
This is more = simple than the proposed solution without needing any = change.
I=92d be open to hearing the strong reason, this ID is = solving, which couldn=92t be solved with = RFC4379.

cheers
-sam


On Jul 3, 2014, at 3:47 PM, Aissaoui, Mustapha = (Mustapha) <mustapha.aissaoui@alc= atel-lucent.com> wrote:

Dear = all,
I was asked = to review this draft and I think it describes valid issues to be = resolved. I however have a couple of comments about the way the authors = went about to address them.
 
1.    Relation to = RFC 7110 - Return Path Specified Label Switched Path (LSP) = Ping.
Section 4.1 = argues the reason why a separate reply mode is needed is for wanting to = omit the Reply Path TLV defined in RFC 7110 when the sender of the echo = request just wanted to use the return path of the tested LSP. I do not = see this as a strong justification. In many cases, the LSP is = unidirectional or the responder node is a transit LSR and may not be = able to inject the reply in the reverse direction of that LSP. In that = case, I can see that providing a specific return LSP which is different = than the tested LSP is required and the Reply Path TLV is = needed.
Assuming this is still an important issue for the authors, = I would suggest to relax the rule in RFC 7110 such that if the echo = request includes reply mode 5 =93Reply via Specified Path=94 and the = Reply Path TLV is not included, the responder node will interpret this = as an implicit request to reply via the reverse direction of the tested = LSP.
 
2.    Reply Mode = Order TLV
I am not = convinced of the need for this TLV. There is not much reply modes which = are usable today together. Only reply mode 2 can be concurrently used = with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not very = popular as far as I know. Also, most applications would reply with mode = 2 if the requested mode is not available. So, I can=92t see how this new = TLV will be useful in practice.
 
Regards,
Mustapha.
______________________= _________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

= --Apple-Mail=_F446718F-1F29-456C-B3D4-58739C0962CE-- From nobody Thu Jul 3 17:53:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8A1B2B83; Thu, 3 Jul 2014 17:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.57 X-Spam-Level: X-Spam-Status: No, score=-101.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISTFv925PTj4; Thu, 3 Jul 2014 17:52:59 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239461B2B5B; Thu, 3 Jul 2014 17:52:58 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 4 Jul 2014 09:52:53 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Fri, 4 Jul 2014 09:52:51 +0900 From: Jeong Ryoo To: Lou Berger , "rtg-ads@tools.ietf.org" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+ Date: Fri, 4 Jul 2014 00:52:50 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> In-Reply-To: <53A5ABED.9080408@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.48] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uZn5vmXY6_0JlO2Li1v5elbYP4s Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 00:53:06 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBMb3UsDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCg0K VGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBoYXZlIGRpc2N1c3NlZCB5b3VyIGNvbW1lbnRzLCBh bmQgYXJlIHByb3Bvc2luZyBvdXIgcmVzb2x1dGlvbnMgdG8geW91ciBjb21tZW50cy4gUGxlYXNl LCBsZXQgdXMga25vdyBpZiB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8gYWRkcmVzcyB5 b3VyIGNvbW1lbnRzIGFuZCBjb25jZXJucy4NCg0KQmVzdCByZWdhcmRzLA0KDQpBdXRob3JzIG9m IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzIGRyYWZ0DQoNCioqKioqKiBCZWdpbm5p bmcgb2YgQ29tbWVudCBSZXNvbHV0aW9uICoqKioqKg0KDQotIERvY3VtZW50J3MgdXNhZ2Ugb2Yg ImNvbW1pdHRlZCIgdnMgImFsbG9jYXRlZCIgcmVzb3VyY2VzOg0KDQpJbiBzZWN0aW9uIDEgdGhl IGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZQ0KZGlzdGluY3Rpb24gYmV0 d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBiYXNlZCBvbiB3aGVuDQpyZXNvdXJj ZXMgYXJlICJjb21taXR0ZWQiLiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0DQpkZWZpbml0aW9u LiBSRkM0NDI3IGFuZCA2MzcyIG1ha2UgdGhlIGRpc3RpbmN0aW9uIHRoYXQgcHJvdGVjdGlvbg0K YW5kIHJlc3RvcmF0aW9uIGRpZmZlciBiYXNlZCBvbiB3aGVuIHJlc291cmNlcyBhcmUgKmFsbG9j YXRlZCogbm90DQoqY29tbWl0dGVkKi4gVG8gcXVvdGUgUkZDIDQ0Mjc6DQoNClRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQNCm9u IHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uIGRvbmUgZHVyaW5nIHRoZSByZWNvdmVyeSBMU1Avc3Bh bg0KZXN0YWJsaXNobWVudC4gVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gZGlmZmVyZW50IHR5cGVz IG9mDQpyZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkIG9uIHRoZSBsZXZlbCBvZiByb3V0ZSBjb21w dXRhdGlvbiwNCnNpZ25hbGluZywgYW5kIHJlc291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSBy ZXN0b3JhdGlvbg0KTFNQL3NwYW4gZXN0YWJsaXNobWVudC4NCg0KVGhpcyBkaWZmZXJlbmNlIGFs c28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZQ0KZG9jdW1lbnQgYXMg d2VsbCBhcyBhbWJpZ3VpdHkgaW4gdGhlIHRleHQsIGkuZS4gY29uZnVzaW9uIGJ5IHRoZQ0KcmVh ZGVyLiBUaGUgdGVybSAiY29tbWl0dGVkIiBpcyBub3QgdGlnaHRseSBkZWZpbmVkIGluIHRoaXMN CmRvY3VtZW50IChvciBlYXJsaWVyIHdvcmspIGFuZCBpcyB1c2VkIGRpZmZlcmVudGx5IHRoYW4g aG93DQoiYWxsb2NhdGVkIiBoYXMgYmVlbiB1c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJl IGZvdW5kIGluDQpTZWN0aW9uIDMuMSB3aGljaCBzdGF0ZXM6DQoNCkhvd2V2ZXIsIHRoZSBjb21t aXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGUNCnNoYXJlZCBzZWdtZW50 cywgd2lsbCBvbmx5IGJlIGZpbmFsaXplZCB3aGVuIHRoZSBwcm90ZWN0aW9uDQpwYXRoIGlzIGFj dHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3JlLCBmb3IgdGhlIHB1cmlzdHMgLQ0KcmVnYXJkaW5n IHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBiZXR3ZWVuDQpwcm90ZWN0aW9u IGFuZCByZXN0b3JhdGlvbi4NCg0KQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0 aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG8NCmNvdmVyIGEgInByb3RlY3Rpb24gc3dpdGNo IiB3b3VsZCAiY29ubmVjdCIgdGhlIHByb3RlY3Rpb24gcGF0aA0KYnV0IG5vdCB0aGUgZWFybGll ciAiYWxsb2NhdGlvbiIgb2YgcmVzb3VyY2VzLiAoUXVvdGVkIHRlcm1zIGFyZQ0KdXNlZCBpbiBl YXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQgb24gdGhlIG5ldw0K ZGlzdGluY3Rpb24gb2YgcHJvdGVjdGlvbiB2cy4gcmVzdG9yYXRpb24gYW5kIGlzIHVubmVjZXNz YXJ5IHdpdGgNCnRoZSBleGlzdGluZyBkaXN0aW5jdGlvbi4NCg0KVGhpcyBpc3N1ZSBleGlzdHMg aW4gbXVsdGlwbGUgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZQ0KImNvbW1pdHRlZCIgaXMg dXNlZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkDQp3aXRo IHRlcm1pbm9sb2d5IHVzZWQgaW4gdGhlIHJlZmVyZW5jZWQgUkZDcywgaS5lLiwgImFsbG9jYXRp b24iLA0KImNvbm5lY3Rpb24iLCAiY3Jvc3MtY29ubmVjdCIsICJwcm90ZWN0aW9uIHN3aXRjaChv dmVyKSIsIC4uLg0KDQpOb3RlIEknbSAqbm90KiBoaWdobGlnaHRpbmcgYWxsIGNhc2VzIHdoZXJl IHRoZXJlIGFyZSBwcm9ibGVtcyBpbiB0aGUNCmRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1 ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyBpbiB0aGUNCmRvY3VtZW50IHdoZXJlIEkg dGhpbmsgaXQncyBwb3NzaWJsZSB0aGF0IG9uY2UgdGhpcyB0ZXJtaW5vbG9neQ0KYW1iaWd1aXR5 IGlzIGNvcnJlY3RlZCB0aGF0IEknbGwgaGF2ZSBvdGhlciBzdWJzdGFudGl2ZSBjb21tZW50cy4N Cg0KW0F1dGhvcnNdIEFmdGVyIHJldmlld2luZyBSRkNzIDQ0MjcsIDYzNzIsIDM5NDUsIDQ0MjYs IGFuZCA0NDI4LCB3ZSBjb25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90 ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBzaG91bGQgYmUgYWxpZ25lZCB3aXRoIHRoZSBleGl0aW5n IGRvY3VtZW50cyBub3JtYXRpdmVseSByZWZlcmVuY2VkIGJ5IHRoaXMgZG9jdW1lbnQuIEFjY29y ZGluZ2x5LCB0aGUgZm9sbG93aW5nIDE2IG1vZGlmaWNhdGlvbnMgd2lsbCBiZSBkb25lIGluIHJl dmlzaW9uOg0KDQooMSkgU2VjdGlvbiAxLCB0aGUgdGhpcmQgcGFyYWdyYXBoDQpPTEQ6DQpBcyBw b2ludGVkIG91dA0KaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQyOF0sIGFwcGx5aW5nIDErMSBsaW5l YXIgcHJvdGVjdGlvbiByZXF1aXJlcw0KdGhhdCByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCBmb3Ig dXNlIGJ5IGJvdGggdGhlIHdvcmtpbmcgYW5kDQpwcm90ZWN0aW9uIHBhdGhzLiBBcHBseWluZyAx OjEgcHJvdGVjdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBzYW1lDQpyZXNvdXJjZXMgYXJlIGNvbW1p dHRlZCwgYnV0IGFsbG93cyB0aGUgcmVzb3VyY2VzIG9mIHRoZSBwcm90ZWN0aW9uDQpwYXRoIHRv IGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUgZXh0cmEgdHJhZmZpYy4NCk5FVzoNCkFzIHBv aW50ZWQgb3V0DQppbiBbUkZDNjM3Ml0gYW5kIFtSRkM0NDI4XSwgYXBwbHlpbmcgMSsxIHByb3Rl Y3Rpb24gcmVxdWlyZXMNCnRoYXQgcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQgZm9yIHVzZSBieSBi b3RoIHRoZSB3b3JraW5nIGFuZA0KcHJvdGVjdGlvbiBwYXRocy4gQXBwbHlpbmcgMToxIHByb3Rl Y3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZQ0KcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQsIGJ1 dCBhbGxvd3MgdGhlIHJlc291cmNlcyBvZiB0aGUgcHJvdGVjdGlvbg0KcGF0aCB0byBiZSB1dGls aXplZCBmb3IgcHJlLWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQoNCigyKSBUaGUgd2hvbGUgdGV4 dCBpbiBTZWN0aW9uIDMuMSB3aWxsIGJlIHJlcGxhY2VkIHdpdGg6DQpbUkZDNjM3Ml0sIGJhc2Vk IHVwb24gdGhlIGRlZmluaXRpb25zIGluIFtSRkM0NDI3XSwgZGlmZmVyZW50aWF0ZXMgYmV0d2Vl biAicHJvdGVjdGlvbiIgYW5kICJyZXN0b3JhdGlvbiIgZGVwZW5kZW50IHVwb24gdGhlIGR5bmFt aXNtIG9mIHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uLiBUaGUgc2FtZSBkaXN0aW5jdGlvbiBpcyB1 c2VkIGluIFtSRkMzOTQ1XSwgW1JGQzQ0MjZdLCBhbmQgW1JGQzQ0MjhdLiBUaGlzIGRvY3VtZW50 IGFsc28gdXNlcyB0aGUgc2FtZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJl c3RvcmF0aW9uIGFzIHN0YXRlZCBpbiBbUkZDNjM3Ml0uDQoNCigzKSBJbiBwYWdlIDYsDQpPTEQ6 DQpUaGUgdXNlIG9mIHByZWVtcHRpb24gaW4gdGhlIG5ldHdvcmsgaXMgdHlwaWNhbGx5IGEgYnVz aW5lc3Mgb3INCnBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291 cmNlcyBhcmUgY29udGVuZGVkLA0KcHJpb3JpdHkgY2FuIGJlIGFwcGxpZWQgdG8gZGV0ZXJtaW5l IHRvIHdoaWNoIHBhcnRpZXMgdGhlIHByb3RlY3Rpb24NCnJlc291cmNlcyBhcmUgY29tbWl0dGVk Lg0KTkVXOg0KVGhlIHVzZSBvZiBwcmVlbXB0aW9uIGluIHRoZSBuZXR3b3JrIGlzIHR5cGljYWxs eSBhIGJ1c2luZXNzIG9yDQpwb2xpY3kgZGVjaXNpb24gc3VjaCB0aGF0IHdoZW4gcHJvdGVjdGlv biByZXNvdXJjZXMgYXJlIGNvbnRlbmRlZCwNCnByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRvIGRl dGVybWluZSB3aGljaCBwYXJ0aWVzIHV0aWxpemUgdGhlIHByb3RlY3Rpb24NCnJlc291cmNlcy4N Cg0KKDQpIFBhZ2UgNywgdGhlIGZpcnN0IHBhcmFncmFwaDoNCk9MRDoNCnRoZSByZXNvdXJjZXMg Zm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGNvbW1pdHRlZCwNCk5FVw0KdGhlIHJl c291cmNlcyBmb3IgdGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgZGVkaWNhdGVkLA0KDQpP TEQ6DQpyZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxkIG5vdCBiZSBjb21taXR0ZWQg dW50aWwg4oCmDQpORVc6DQpyZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxkIG5vdCBi ZSB1dGlsaXplZCB1bnRpbCDigKYNCg0KKDUpIEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHBh Z2UgNywNCk9MRDoNCiJIYXJkIFByZWVtcHRpb24iIHJlcXVpcmVzIHRoZSBwcm9ncmFtbWluZyBv ZiBzZWxlY3RvcnMgYXQgdGhlIGluZ3Jlc3Mgb2YgZWFjaCBzaGFyZWQgc2VnbWVudCB0byBzcGVj aWZ5IHdoaWNoIGJhY2t1cCBwYXRoIGhhcyB0aGUgaGlnaGVzdCBwcmlvcml0eSB3aGVuIGNvbW1p dHRpbmcgcHJvdGVjdGlvbiByZXNvdXJjZXMsIHRoZSBvdGhlcnMgYmVpbmcgcHJlZW1wdGVkLg0K TkVXDQoiSGFyZCBQcmVlbXB0aW9uIiByZXF1aXJlcyB0aGUgcHJvZ3JhbW1pbmcgb2Ygc2VsZWN0 b3JzIGF0IHRoZSBpbmdyZXNzIG9mIGVhY2ggc2hhcmVkIHNlZ21lbnQgdG8gc3BlY2lmeSB0aGUg cHJpb3JpdGllcyBvZiBiYWNrdXAgcGF0aHMsIHNvIHRoYXQgdHJhZmZpYyBvZiBsb3dlciBwcmlv cml0eSBwYXRocyBjYW4gYmUgcHJlZW1wdGVkLg0KDQooNikgVGhlIGZpcnN0IHBhcmFncmFwaCBv ZiBTZWN0aW9uIDQuMToNCk9MRDoNCuKApiBhbmQgY29tbWl0IHRoZSBhc3NvY2lhdGVkIHJlc291 cmNlcy4gVGhlIGNvbW1pdG1lbnQgb2YgcmVzb3VyY2VzDQppcyBkZXBlbmRlbnQgdXBvbiDigKYN Ck5FVzoNCuKApiBhbmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIGFzc29jaWF0 ZWQgc2hhcmVkIHJlc291cmNlcy4NClRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRp b24gaXMgZGVwZW5kZW50IHVwb24g4oCmDQoNCig3KSBUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBT ZWN0aW9uIDQuMToNCk9MRDoNCldoZW4gdGhlIHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hh cmVkIHNlZ21lbnRzIGFyZSBjb21taXR0ZWQgdG8gYQ0KcGFydGljdWxhciBwcm90ZWN0aW9uIHBh dGgsIHRoZXJlIG1heSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCmF2YWlsYWJsZSBmb3Ig YW4gYWRkaXRpb25hbCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCmlm IGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVj dGlvbg0Kc3dpdGNoLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgcmVzb3VyY2VzIG1heSBmYWlsLiBJ biBvcmRlciB0bw0Kb3B0aW1pemUgdGhlIG9wZXJhdGlvbiBvZiB0aGUgY29tbWl0bWVudCBhbmQg cHJlcGFyaW5nIGZvciBjYXNlcyBvZg0KbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0 aGUgY29tbWl0bWVudCBvZiB0aGUgc2hhcmVkDQpyZXNvdXJjZXMgYXJlIGJlIGNvb3JkaW5hdGVk IGJldHdlZW4gdGhlIGRpZmZlcmVudCB3b3JraW5nIHBhdGhzIGluDQp0aGUgU01QIG5ldHdvcmsu DQpORVc6DQpXaGVuIHRoZSByZXNlcnZlZCByZXNvdXJjZXMgb2YgdGhlIHNoYXJlZCBzZWdtZW50 cyBhcmUgdXRpbGl6ZWQgYnkgYQ0KcGFydGljdWxhciBwcm90ZWN0aW9uIHBhdGgsIHRoZXJlIG1h eSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCmF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25h bCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCmlmIGFub3RoZXIgd29y a2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbg0Kc3dpdGNo LCB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIG1heSBmYWlsLiBUaGUgZGlm ZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4NCnRoZSBTTVAgbmV0d29yayBhcmUgaW52b2x2ZWQgaW4g dGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbi4NCi4NCg0KKDgpIFNlY3Rpb24g NS4xLA0KT0xEOg0K4oCmIGFuZCBjb21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzLg0KTkVX DQrigKYgYW5kIGNvb3JkaW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBhc3NvY2lhdGVkIHNo YXJlZCByZXNvdXJjZXMuDQoNCig5KSBJbiBTZWN0aW9uIDUuMSwNCk9MRDoNCkluIHRoZSBjYXNl IG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFpbGluZywgdGhlIGNvbW1pdG1lbnQgb2YgdGhl DQpzaGFyZWQgcmVzb3VyY2VzIFNIQUxMIGJlIGNvb3JkaW5hdGVkIGJldHdlZW4gdGhlIGRpZmZl cmVudCB3b3JraW5nDQpwYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuDQpORVc6DQpJbiB0aGUgY2Fz ZSBvZiBtdWx0aXBsZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRoZSBzaGFyZWQgcmVzb3VyY2Ug dXRpbGl6YXRpb24NCmNvb3JkaW5hdGlvbiBTSEFMTCBiZSBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQg d29ya2luZw0KcGF0aHMgaW4gdGhlIFNNUCBuZXR3b3JrLg0KDQooMTApIFNlY3Rpb24gNS4xLjEu DQpPTEQ6DQrigKYgYmVjYXVzZSB0aGV5IGFscmVhZHkgaGF2ZSBiZWVuIGNvbW1pdHRlZCB0byB0 aGUgcHJvdGVjdGlvbiBvZiwgZm9yIGV4YW1wbGUsIGEgaGlnaGVyIHByaW9yaXR5IHdvcmtpbmcg cGF0aC4NCk5FVzoNCuKApiBiZWNhdXNlIHRoZXkgYWxyZWFkeSBoYXZlIGJlZW4gdXRpbGl6ZWQg Zm9yIHRoZSBwcm90ZWN0aW9uIG9mLCBmb3IgZXhhbXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29y a2luZyBwYXRoLg0KDQooMTEpIFNlY3Rpb24gNS4yLCB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0K T0xEOg0KUmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgU0hBTEwgYmUgY29tbWl0dGVk IHRvIHRoZQ0KcHJvdGVjdGlvbiBwYXRoIOKApg0KTkVXOg0KUmVzb3VyY2VzIG9mIHRoZSBzaGFy ZWQgc2VnbWVudHMgU0hBTEwgYmUgdXRpbGl6ZWQgYnkgdGhlDQpwcm90ZWN0aW9uIHBhdGgg4oCm DQoNCigxMikgU2VjdGlvbiA1LjIsIHRoZSB0aGlyZCBidWxsZXQgaXRlbToNCk9MRDoNCklmIG11 bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcN CmFsbG9jYXRpb24gb2YgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxE IGJlDQpjb21taXR0ZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBiYXNpcy4NCk5FVzoN CklmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVl c3RpbmcNCnRoZSBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNIT1VMRCBiZQ0KYXNz aWduZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBiYXNpcy4NCg0KKDEzKSBTZWN0aW9u IDUuMiwgdGhlIGZvdXJ0aCBidWxsZXQgaXRlbToNCk9MRDoNCklmIHRoZSBwcm90ZWN0aW9uIHJl c291cmNlcyBhcmUgY29tbWl0dGVkIHRvIGEgcHJvdGVjdGlvbiBwYXRoLA0Kd2hvc2Ugd29ya2lu ZyBwYXRoIGhhcyBhIGxvd2VyIHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yDQp0aGUg aGlnaGVyIHByaW9yaXR5IHBhdGggU0hBTEwgYmUgY29tbWl0dGVkIHRvIHRoZSBoaWdoZXIgcHJp b3JpdHkNCnBhdGguDQpORVc6DQpJZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIHV0aWxp emVkIGJ5IGEgcHJvdGVjdGlvbiBwYXRoLA0Kd2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxvd2Vy IHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yDQp0aGUgaGlnaGVyIHByaW9yaXR5IHBh dGggU0hBTEwgYmUgYXNzaWduZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KcGF0aC4NCg0KDQoo MTQpIFNlY3Rpb24gNS4yLiB0aGUgc2V2ZW50aCBidWxsZXQgaXRlbQ0KT0xEOg0KT25jZSByZXNv dXJjZXMgb2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgY29tbWl0dGVk DQp0byBhIHByb3RlY3Rpb24gcGF0aCwg4oCmDQpORVc6DQpPbmNlIHJlc291cmNlcyBvZiBzaGFy ZWQgc2VnbWVudHMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSB1dGlsaXplZA0KYnkgYSBwcm90ZWN0 aW9uIHBhdGgsIOKApg0KDQooMTUpIFNlY3Rpb24gNS4zLCB0aGUgZmlyc3QgcGFyYWdyYXBoLA0K T0xEOg0K4oCmIHJlcXVlc3QgdGhlIGNvbW1pdG1lbnQgb2YgcHJvdGVjdGlvbiByZXNvdXJjZXMu IElmIHRoZSBuZWNlc3NhcnkNCnNoYXJlZCByZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlIHRvIGJl IGNvbW1pdHRlZCB0byB0aGUgcHJvdGVjdGlvbg0KcGF0aCwgdGhlIGVuZHBvaW50cyDigKYNCg0K TkVXOg0K4oCmIHJlcXVlc3QgdGhlIGNvb3JkaW5hdGlvbiBvZiB0aGUgc2hhcmVkIHJlc291cmNl IHV0aWxpemF0aW9uLiBJZiB0aGUgbmVjZXNzYXJ5DQpzaGFyZWQgcmVzb3VyY2VzIGFyZSB1bmF2 YWlsYWJsZSwgdGhlIGVuZHBvaW50cyDigKYNCg0KKDE2KSBTZWN0aW9uIDUuMywgdGhlIHNlY29u ZCBwYXJhZ3JhcGgsDQpPTEQ6DQpTaW1pbGFybHksIGlmIHByZWVtcHRpb24gaXMgc3VwcG9ydGVk IGFuZCB0aGUgcmVzb3VyY2VzIGN1cnJlbnRseQ0KY29tbWl0dGVkIGZvciBhIHBhcnRpY3VsYXIg d29ya2luZyBwYXRoIGFyZSDigKYNCk5FVzoNClNpbWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBz dXBwb3J0ZWQgYW5kIHRoZSByZXNvdXJjZXMgY3VycmVudGx5DQp1dGlsaXplZCBieSBhIHBhcnRp Y3VsYXIgd29ya2luZyBwYXRoIGFyZSDigKYNCg0KDQotIFNlY3Rpb24gMiwgMXN0IHBhcmFncmFw aCwgbGFzdCBzZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkgZGVmaW5lcw0KdGhlIHNjb3Bl L3B1cnBvc2Ugb2YgdGhlIGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlv bnMNCnRvIHByb3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNm eSB0aGUNCnJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJ J2QgcmVwZWF0IHRoaXMgaW4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJv bm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yDQozKS4NCg0KW0F1dGhvcnNdIFdlIGNhbiBh ZGQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDE6DQrigJxU aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGNsYXJpZnkgdGhlIGluc3RydWN0aW9ucyB0byBw cm90b2NvbCBkZXNpZ25lcnMgcHJvZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlIHJl cXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQu4oCdDQoNCg0KLSBHZW5lcmFsIGNv bW1lbnQ6IGZhdGUtc2hhcmluZyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQpwcm90 ZWN0aW9uOiBIb3cgaXMgY28tcm91dGluZyBwcmVzZXJ2ZWQgZm9yIHRoZSByZXZlcnNlIHBhdGgg aW4gU01QPw0KSSdkIGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBw cm90b2NvbCB3b3VsZCBiZQ0KcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhl IHJldmVyc2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCmNhc2UsIGJ1dCBkb24ndCBzZWUgdGhpcyBp biB0aGUgZG9jdW1lbnQuDQoNCltBdXRob3JzXSBGYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVk IGJ5IHRoaXMgZG9jdW1lbnQuIEV2ZW4gaW4gdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcsIHN1Y2ggYXMgUkZDIDYzNzggKFBTQykgYW5kIFJGQyA3MjcxIChQU0MgaW4gQVBTIG1v ZGUpLCBmYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGFzIHVuaWRpcmVjdGlvbmFsIHN3aXRj aGluZyBpcyBhbGxvd2VkLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGltcG9zZSBhbnkgcmVzdHJp Y3Rpb24gb24gY28tcm91dGluZywgZWl0aGVyLg0KDQoNCi0gSW4gc2VjdGlvbiA0IGFuZCA1LjIg eW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmluaW5nDQpwcmVlbXB0aW9uIHRlcm1p bm9sb2d5IGFuZCBiZWhhdmlvci4gSSB0aGluayA2MzcyIGlzIHRoZSByaWdodA0KcmVmZXJlbmNl IGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBjb250ZXh0IG9mIHN1cnZpdmFiaWxpdHkg YW5kDQppbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFuZS4NCg0KW0F1dGhvcnNdIE9uZSBjb25j ZXJuIGlzIHRoYXQgUkZDIDYzNzIgZGVzY3JpYmVzIGJvdGggc29mdCBhbmQgaGFyZCBwcmVlbXB0 aW9ucyBpbiB0aGUgY29udGV4dCBvZiBleHRyYSB0cmFmZmljLCB3aGljaCBpcyBub3QgZXhhY3Rs eSB0aGUgY2FzZSBmb3IgU01QLg0KDQoNCi0gSW4gc2VjdGlvbiA0LjIgeW91IHNheSAiVGhlcmVm b3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlDQpjYXJyaWVkIG91dCB1bmRlciB0aGUg Y29udHJvbCBvZiBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSBzaW1pbGFyIHRvDQpHTVBMUyBbUkZD Mzk0NV0uIiBwZXJoYXBzIHlvdSBtZWFuICJiYXNlZCBvbiBHTVBMUyI/IElmIHNvLCBncmVhdCwN CnBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBv ZiB3aGljaA0KY29udHJvbCBwcm90b2NvbCBpcyB1c2VkIGZvciBNUExTLVRQIGlzIHdheSBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoaXMNCmRvY3VtZW50Lg0KDQpbQXV0aG9yc10gWWVzLCB3ZSB3aWxs IG1ha2UgdGhlIGNvcnJlY3Rpb24uDQoNCg0KLSBTZWN0aW9uIDUuMSwgcGFyYWdyYXBoIDEuIFdo eSBhcmUgeW91IHVzaW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0KcmVmZXJyaW5nIHRvIHNvbHV0 aW9ucyBjb25mb3JtYW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVzZSBhcmUNCmluZm9y bWF0aXZlIHN0YXRlbWVudHMsICJhbmQgYSBub24tY29udHJvbCBwbGFuZSBiYXNlZCBTTVAgc3dp dGNob3Zlcg0KbWVjaGFuaXNtIGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNIQUxMIE5PVCAu Li4iLiBJZiByZWZlcnJpbmcgdG8NCmFuIG9wZXJhdG9yJ3MvdXNlcidzIGNob2ljZSBvZiBwcm90 ZWN0aW9uIG1lY2hhbmlzbSwgSSB0aGluayB0aGUgbW9zdA0KeW91IGNhbiBzYXkgaXMgTUFZLg0K DQpbQXV0aG9yc10gVGhlIGZpcnN0IGNhc2UgaXMgdGhlIG9uZSB3ZSBhcmUgYWltaW5nIGF0LiBX ZSB3aWxsIHVzZSBTSEFMTCBOT1QuDQoNCg0KLSBTZWN0aW9uIDUuMi4gIlRpZS1icmVha2luZyBy dWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNNUA0KZG9tYWluLiIgQXMgdGhp cyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0aWUtYnJlYWtpbmcNCnJ1bGVz IiBzaG91bGQgYmUgZGVmaW5lZCBkaXJlY3RseSBvciBieSByZWZlcmVuY2UuDQoNCltBdXRob3Jz XSBUaGUgc2VudGVuY2UgY2FuIGJlIHJld3JpdHRlbiBhczoNCk9MRDoNClRpZS1icmVha2luZyBy dWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNNUCBkb21haW4uDQpORVc6DQpJ biBvcmRlciB0byBjb3ZlciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0 IHNlcnZlZCBwcmluY2lwbGUgY2Fubm90IHJlc29sdmUgdGhlIGNvbnRlbnRpb24gYW1vbmcgbXVs dGlwbGUgZXF1YWwgcHJpb3JpdHkgcmVxdWVzdHMsIGkuZS4sIHdoZW4gdGhlIHJlcXVlc3RzIG9j Y3VyIHNpbXVsdGFuZW91c2x5LCwgdGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQg aW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCg0KDQoNCi0gU2VjdGlvbiA1LjMuIFJGQzYzNzIg dGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb24NCmxldmVyYWdl cyB0aGUgc3RhbmRhcmQgTVBMUy1UUCBPQU0gbWVjaGFuaXNtcywgaXMgdGhlcmUgYW55IHJlYXNv biB0bw0KZG8gbW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0KDQpbQXV0aG9yc10gV2UgY2Fu IGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGF0IHRoZSBlbmQ6DQrigJxBcyBkZXNjcmliZWQg aW4gW1JGQzYzNzJdLCB0aGUgZXZlbnQgb2YgcHJlZW1wdGlvbiBtYXkgYmUgZGV0ZWN0ZWQgYnkg T0FNIGFuZCByZXBvcnRlZCBhcyBhIGZhdWx0IG9yIGEgZGVncmFkYXRpb24gb2YgdHJhZmZpYyBk ZWxpdmVyeS7igJ0NCg0KLSBTZWN0aW9uIDUuNy4gVGhlcmUgbWF5IGJlIGNvb3JkaW5hdGlvbiBy ZXF1aXJlZCBvbiBzb2Z0LXByZWVtcHRpb24gYXMNCndlbGwgKGRlcGVuZGluZyBvbiB0aGUgY3Jv c3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExTUA0KZXN0YWJsaXNobWVudCkgc28gY29v cmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQNCmluZGVwZW5kZW50IG9mIHBy ZWVtcHRpb24gbW9kZS4NCg0KW0F1dGhvcnNdIFllcywgd2Ugd2lsbCBjaGFuZ2UgdGhlIHNlY29u ZCBwYXJhZ3JhcGggZnJvbSDigJxTTVAgaW4gaGFyZC1wcmVlbXB0aW9uIG1vZGUgU0hPVUxEIOKA puKAnSB0byDigJxTTVAgU0hPVUxEIOKApuKAnSBhbmQgbW92ZSB0aGUgY2hhbmdlZCBwYXJhZ3Jh cGggYWJvdmUgdGhlIGZpcnN0IHBhcmFncmFwaC4NCg0KDQpOaXRzOg0KDQotIEFic3RyYWN0OiBJ IGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0aXZlIGFjdGlvbiIgYmVpbmcgdXNlZCBpbiBh bnkNCmVhcmxpZXIgcmVsYXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhlciB0aGFuIGludHJvZHVj ZSBhIG5ldyAoYW5kDQp1bmRlZmluZWQpIHRlcm0sIHBlcmhhcHMgeW91IGNhbiB1c2UgYW4gZXhp c3Rpbmcgb25lLCBlLmcuLA0KInByb3RlY3Rpb24gc3dpdGNoIj8NCg0KW0F1dGhvcnNdIFllcywg dGhlIHRlcm0gd2lsbCBiZSBjaGFuZ2VkIGFzIHlvdSBzdWdnZXN0ZWQuDQoNCg0KLSBTZWN0aW9u IDEsIHBhcmFncmFwaCAxLiBEbyB3ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YN Ck1QTFMtVFAgdG8gZGViYXRlPyBJIHN1Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9y aXRlIE1QTFMtVFANCmRvY3VtZW50KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50 ZW5jZXMuDQoNClRoZSBsYXN0IHNlbnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZlIHN0YXRl bWVudC4gV2hldGhlciBpdCBpcw0KY3JpdGljYWwgb3Igbm8gaXMgdW5uZWNlc3NhcnkuIFlvdSBj YW4ganVzdCBzYXkgc29tZXRoaW5nIGxpa2UgNjM3Mg0KcHJvdmlkZXMgYSBzdXJ2aXZhYmlsaXR5 IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZvdW5kYXRpb24NCmZvciB0aGlzIGRv Y3VtZW50Lg0KDQpbQXV0aG9yc10gVGhlIHByb3Bvc2VkIHRleHQgZm9yIHRoZSBwYXJhZ3JhcGgg MSBpczoNCuKAnFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBpcyBkZXNjcmli ZWQgaW4gW1JGQzU5MjFdLA0KYW5kIFtSRkM2MzcyXSBwcm92aWRlcyBhIHN1cnZpdmFiaWxpdHkg ZnJhbWV3b3JrIGZvciBNUExTLVRQDQphbmQgaXMgdGhlIGZvdW5kYXRpb24gZm9yIHRoaXMgZG9j dW1lbnQu4oCdDQoNCg0KLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAzLiBJc24ndCB0aGUgcmlnaHQg cmVmZXJlbmNlIDQ0Mjcgbm90IDQ0Mjg/DQpBbHNvIGRyb3AgdGhlIHdvcmQgbGluZWFyLCBhcyBp dCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kDQo0NDI3LzQ0MjggZG9uJ3QgdXNlIGl0 Lg0KDQpbQXV0aG9yc10gT0suDQoNCg0KDQotIFNlY3Rpb25zIDMgKGFuZCB0byBhIGxlc3NlciBk ZWdyZWUgc2VjdGlvbiAyKSBhcmUgcmVhbGx5IGludHJvZHVjdG9yeQ0KdGV4dC4gSSdtIHVuc3Vy ZSBhcyB0byB3aHkgdGhleSBhcmVuJ3QgcGFydCBvZiBzZWN0aW9uIDEuDQoNCltBdXRob3JzXSBT ZWN0aW9uIDMgd2FzIGludGVuZGVkIHRvIHByZXNlbnQgYSByZWZlcmVuY2UgbW9kZWwgZm9yIFNN UC4gU29tZSB0ZXh0IG9mIFNlY3Rpb24gMiBpcyByZXBlYXRlZCBpbiBTZWN0aW9uIDEgYXMgeW91 IHN1Z2dlc3RlZCBlYXJsaWVyLg0KDQoNCg0KLSBTZWN0aW9uIDMuMiBzaG91bGQgaGF2ZSBhIHJl ZmVyZW5jZSBmb3IgImV4aXN0aW5nIGNvbnRyb2wgcGxhbmUNCnNvbHV0aW9ucyBmb3IgU01QIHdp dGhpbiBNUExTIi4NCg0KW0F1dGhvcnNdIFtSRkM0MjA2XSB3aWxsIGJlIGFkZGVkIGFzIGEgcmVm ZXJlbmNlDQoNCi0gU2VjdGlvbiAzLjIgYWdhaW4gdXNlcyB0aGUgImV4ZWN1dGl2ZSBhY3Rpb24i IHRlcm0uDQoNCltBdXRob3JzXSBPSywgdGhlIHRlcm0gd2lsbCBiZSBjaGFuZ2VkLg0KDQoNCi0g U2VjdGlvbiA0LjEuIFlvdSBzYXkgInR3byBvcGVyYXRpb25zIHNpbXVsdGFuZW91c2x5Ii4gRG8g eW91IHJlYWxseQ0KbWVhbiAic2ltdWx0YW5lb3VzbHkiIG9yIG1lcmVseSB0aGF0IHRoZXkgbXVz dCBib3RoIG9jY3VyIGZvcg0KcHJvdGVjdGlvbiB0byBiZSBwcm92aWRlZD8gKFNhbWUgY29tbWVu dCBpbiBzZWN0aW9uIDUuMS4NCg0KW0F1dGhvcnNdIEJvdGggYWN0aW9ucyBzaG91bGQgb2NjdXIg YXQgdGhlIHNhbWUgdGltZSwgb3IgYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0byBwcm92aWRlIGZh c3QgcHJvdGVjdGlvbi4NCg0KDQotIFNlY3Rpb24gNS4yLiBJIHN1Z2dlc3QgbnVtYmVyaW5nIHRo ZSBjdXJyZW50bHkgYnVsbGV0dGVkIHJlcXVpcmVtZW50cw0KbGlzdC4NCg0KW0F1dGhvcnNdIE9L LCB3ZSB3aWxsIHVzZSBudW1iZXJzLg0KDQoNCi0gU2VjdGlvbiA1LjI6IEZpcnN0IHBhcmFncmFw aCBhbmQgZm9ydGggYnVsbGV0IGxhc3Qgc2VudGVuY2UuIFRoZXNlDQpib3RoIGJhc2ljYWxseSBj b3ZlciB0aGUgc2FtZSB0b3BpYyAocHJlZW1wdGlvbikgYW5kIGFjdHVhbGx5IHNheQ0Kc2xpZ2h0 bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZQ0KcmVx dWlyZW1lbnQgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBmdWxsIGNvdmVyYWdlIG9mIHRoZSB0 b3BpYy4NCg0KW0F1dGhvcnNdIFRoZSBmaXJzdCBwYXJhZ3JhcGggaXMgZm9yIHNvZnQtcHJlZW1w dGlvbiwgd2hpbGUgdGhlIGZvdXJ0aCBidWxsZXQgYmVsb25ncyB0byB0aGUgcmVxdWlyZW1lbnRz IG9mIGhhcmQtcHJlZW1wdGlvbi4NCg0KLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRo aXMgcmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3QNCnRoZSB0b3BpY3MgcmVsYXRlZCB0 byB0aW1pbmcgYmUgY29uc29saWRhdGVkPw0KDQpbQXV0aG9yc10gWWVzLCByZXEgNSBjYW4gYmUg bW92ZWQgdG8gU2VjdGlvbiA1LjUuDQoNCg0KLSBTZWN0aW9uIDUuMjogcmVxdWlyZW1lbnQgNiBz ZWVtcyB0byBiZSBhIHN1YnNldCBvZiA3LCBzbyBpdCBzaG91bGQgYmUNCmRyb3BwZWQuDQoNCltB dXRob3JzXSBZZXMsIGl0IHdpbGwgYmUgZGVsZXRlZC4NCg0KLSBTZWN0aW9uIDUuMiwgcmVxdWly ZW1lbnQgOC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCmp1c3QgdGhp cyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/DQoNCltBdXRob3JzXSBS ZXEuIDkgd2lsbCBiZSBkZWxldGVkIGFzIGl0IHNlZW1zIHRvIHJlcXVpcmUgY29udHJvbCBwbGFu ZSBzdXBwb3J0cy4NCg0KDQotIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQoNCltBdXRob3JzXSBP Sy4NCg0KDQotIHNlY3Rpb24gNS40OiAiIFdoZW4gdGhlIHdvcmtpbmcgcGF0aCBkZXRlY3RzLi4i IGRldGVjdGlvbiBpcyBieSB0aGUNCm5vZGUgbm90IHRoZSBwYXRoLg0KDQpbQXV0aG9yc10gWWVz LiBXZSB3aWxsIHNpbXBseSBzYXkgdGhhdCDigJxXaGVuIHRoZSBjb25kaXRpb24gdGhhdCB0cmln Z2VyZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGNsZWFyZWQsIOKApuKAnQ0KDQotIFNl Y3Rpb24gNS40LCBsYXN0IHNlbnRlbmNlLiBUaGlzIGlzIG9ubHkgdGhlIDJuZCB0aW1lIHlvdSBp bXBseSB0aGF0DQp0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90 b2NvbC4gSSB0aGluayB0aGlzDQpwb2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBpbiB0aGUg ZG9jdW1lbnQuIChUaGlzIHBvaW50IHdhcyBhbHNvDQptYWRlIGFzIGEgbWlub3IgY29tbWVudC4p DQoNCltBdXRob3JzXSBBcyBpbiBvdGhlciBwcm90ZWN0aW9uIHN3aXRjaGluZyB0ZWNobm9sb2dp ZXMsIHR3byBtb2RlcyBvZiBvcGVyYXRpb25zIChyZXZlcnRpdmUgYW5kIG5vbi1yZXZlcnRpdmUp IGFyZSByZXF1aXJlZC4NCg0KDQotIHNlY3Rpb24gNS42LiBSRkMgNjM3MiBzaG91bGQgYmUgcmVm ZXJlbmNlZA0KW0F1dGhvcnNdIFdlIHdpbGwgYWRkIOKAnGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3 Ml3igJ0gdG8gdGhlIGVuZHMgb2YgdHdvIHBhcmFncmFwaHMgZm9yIFdUUiB0aW1lciBhbmQgaG9s ZC1vZmYgdGltZXIuDQoNCioqKioqIEVuZCBvZiBDb21tZW50IHJlc29sdXRpb24gKioqKioNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K67O064K4IOyCrOuejCA6 ICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4NCuuztOuCuCDrgqDsp5wgOiAyMDE0LTA2 LTIyIDAxOjAwOjQ4ICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiBydGctYWRzQHRvb2xzLmll dGYub3JnIDxydGctYWRzQHRvb2xzLmlldGYub3JnPg0K7LC47KGwIDogcnRnLWRpckBpZXRmLm9y ZyA8cnRnLWRpckBpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFs bEB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRv b2xzLmlldGYub3JnPiwgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4NCuygnOuqqSA6IFtt cGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50 eHQNCg0KDQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCmRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCnJvdXRpbmctcmVsYXRlZCBkcmFmdHMg YXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cNCnJldmlldywgYW5k IHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcg aXMNCnRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IHRoZQ0KUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRo b3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0 aW5nIEFEcywgaXQNCndvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0g YWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURg0KTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJl Y2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gNCmRpc2N1c3Npb24gb3Ig YnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMtMDYudHh0DQpSZXZpZXdlcjogTG91IEJlcmdlcg0KUmV2aWV3IERhdGU6IEp1 bmUgMjEgMjAxNA0KSUVURiBMQyBFbmQgRGF0ZTogMjAxNC0wNi0yMw0KSW50ZW5kZWQgU3RhdHVz OiBJbmZvcm1hdGlvbmFsDQoNClN1bW1hcnk6DQpJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBh Ym91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluaw0Kc2hvdWxkIChtdXN0LCBhY3R1YWxseSkg YmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KDQpDb21tZW50czoNCg0KSSB0aGluayB0 aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCwgb3RoZXIgdGhhbiBhIGNvdXBsZSBvZg0K dGVybWlub2xvZ3kgcmVsYXRlZCBpc3N1ZXMsIGVhc2lseSB1bmRlcnN0b29kLiBUaGUgZG9jdW1l bnQgZG9lcw0KaGF2ZSBhIG51bWJlciBvZiB0ZXJtaW5vbG9neSBhbmQgdGVjaG5pY2FsIGlzc3Vl cyB3aGljaCBzaG91bGQgYmUNCnJlYWRpbHkgcmVzb2x2ZWQgcHJpb3IgdG8gcHVibGljYXRpb24u DQoNCk1ham9yIElzc3VlczoNCg0KTWFqb3IgaXNzdWVzIGFyZSB0aGUgdHlwZSBvZiBjb25jZXJu cyB0aGF0IHdpbGwgcmVzdWx0IGluIHRoZQ0KZG9jdW1lbnQgYmVpbmcgYmxvY2tlZCB1bnRpbCB0 aGV5IGFyZSByZXNvbHZlZC4gVGhlIFJvdXRpbmcgQURzIHdpbGwNCmJlY29tZSBpbnZvbHZlZC4g UGxlYXNlIGluY2x1ZGUgYWxsIG9mIHRoZSBtYWpvciBpc3N1ZXMgeW91IGhhdmUNCmZvdW5kLiBH aXZlIGFzIG11Y2ggY29udGV4dCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSAoZS5nLiwgc2VjdGlv bg0KbnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuIElmIHlvdSBmaW5kIG5vIG1ham9yIGlzc3Vl cywgcGxlYXNlDQp3cml0ZTogIk5vIG1ham9yIGlzc3VlcyBmb3VuZC4iDQoNCi0gTm8gbWFqb3Ig aXNzdWVzIGZvdW5kLiBJbiBwYXJ0aWN1bGFyLCBJIGV4cGVjdCBhbGwgaXNzdWVzIGNhbiBiZQ0K cmVzb2x2ZWQgd2l0aG91dCBBRCBpbnRlcnZlbnRpb24uIFNvbWUgb2YgdGhlIG1pbm9yIGlzc3Vl cywgaWYgbm90DQpyZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRlZCB0byB0aGUgQUQvbWFqb3IgaXNz dWUgY2F0ZWdvcnkuDQoNCk1pbm9yIElzc3VlczoNCg0KTWlub3IgaXNzdWVzIGFyZSBjb25jZXJu cyBhYm91dCBjbGFyaXR5IG9yIHRlY2huaWNhbCBhY2N1cmFjeSB0aGF0DQpzaG91bGQgYmUgZGlz Y3Vzc2VkIGFuZCByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24sIGJ1dCB3aGljaCB3b3VsZA0K bm9ybWFsbHkgYmUgcmVzb2x2ZWQgYmV0d2VlbiB0aGUgYXV0aG9ycyBhbmQgdGhlIHJldmlld2Vy cy4gUGxlYXNlDQppbmNsdWRlIGFsbCBvZiB0aGUgbWlub3IgaXNzdWVzIHlvdSBoYXZlIGZvdW5k LiBHaXZlIGFzIG11Y2ggY29udGV4dA0KaW5mb3JtYXRpb24gYXMgcG9zc2libGUgKGUuZy4sIHNl Y3Rpb24gbnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuDQpJZiB5b3UgZmluZCBubyBtaW5vciBp c3N1ZXMsIHBsZWFzZSB3cml0ZTogIk5vIG1pbm9yIGlzc3VlcyBmb3VuZC4iDQoNCi0gRG9jdW1l bnQncyB1c2FnZSBvZiAiY29tbWl0dGVkIiB2cyAiYWxsb2NhdGVkIiByZXNvdXJjZXM6DQoNCklu IHNlY3Rpb24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgbm90aW9uIHRoYXQgdGhlDQpk aXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIGJhc2VkIG9u IHdoZW4NCnJlc291cmNlcyBhcmUgImNvbW1pdHRlZCIuIFRoaXMgZGlmZmVyZW5jZSBmcm9tIHBh c3QNCmRlZmluaXRpb24uIFJGQzQ0MjcgYW5kIDYzNzIgbWFrZSB0aGUgZGlzdGluY3Rpb24gdGhh dCBwcm90ZWN0aW9uDQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3Vy Y2VzIGFyZSAqYWxsb2NhdGVkKiBub3QNCipjb21taXR0ZWQqLiBUbyBxdW90ZSBSRkMgNDQyNzoN Cg0KVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gaXMg bWFkZSBiYXNlZA0Kb24gdGhlIHJlc291cmNlIGFsbG9jYXRpb24gZG9uZSBkdXJpbmcgdGhlIHJl Y292ZXJ5IExTUC9zcGFuDQplc3RhYmxpc2htZW50LiBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBk aWZmZXJlbnQgdHlwZXMgb2YNCnJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQgb24gdGhlIGxldmVs IG9mIHJvdXRlIGNvbXB1dGF0aW9uLA0Kc2lnbmFsaW5nLCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlv biBkdXJpbmcgdGhlIHJlc3RvcmF0aW9uDQpMU1Avc3BhbiBlc3RhYmxpc2htZW50Lg0KDQpUaGlz IGRpZmZlcmVuY2UgYWxzbyBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0YXRlbWVudHMgaW4gdGhl DQpkb2N1bWVudCBhcyB3ZWxsIGFzIGFtYmlndWl0eSBpbiB0aGUgdGV4dCwgaS5lLiBjb25mdXNp b24gYnkgdGhlDQpyZWFkZXIuIFRoZSB0ZXJtICJjb21taXR0ZWQiIGlzIG5vdCB0aWdodGx5IGRl ZmluZWQgaW4gdGhpcw0KZG9jdW1lbnQgKG9yIGVhcmxpZXIgd29yaykgYW5kIGlzIHVzZWQgZGlm ZmVyZW50bHkgdGhhbiBob3cNCiJhbGxvY2F0ZWQiIGhhcyBiZWVuIHVzZWQuIEFuIGV4YW1wbGUg b2YgdGhpcyBjYW4gYmUgZm91bmQgaW4NClNlY3Rpb24gMy4xIHdoaWNoIHN0YXRlczoNCg0KSG93 ZXZlciwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcywgYXQgbGVhc3QgZm9yIHRoZQ0K c2hhcmVkIHNlZ21lbnRzLCB3aWxsIG9ubHkgYmUgZmluYWxpemVkIHdoZW4gdGhlIHByb3RlY3Rp b24NCnBhdGggaXMgYWN0dWFsbHkgYWN0aXZhdGVkLiBUaGVyZWZvcmUsIGZvciB0aGUgcHVyaXN0 cyAtDQpyZWdhcmRpbmcgdGhlIHRlcm1pbm9sb2d5IC0gU01QIGxpZXMgc29tZXdoZXJlIGJldHdl ZW4NCnByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uLg0KDQpCb3RoIHNlbnRlbmNlcyBhcmUgcHJv YmxlbWF0aWMuIEluIHRoZSBmaXJzdCwgY29tbWl0bWVudCBzZWVtcyB0bw0KY292ZXIgYSAicHJv dGVjdGlvbiBzd2l0Y2giIHdvdWxkICJjb25uZWN0IiB0aGUgcHJvdGVjdGlvbiBwYXRoDQpidXQg bm90IHRoZSBlYXJsaWVyICJhbGxvY2F0aW9uIiBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMg YXJlDQp1c2VkIGluIGVhcmxpZXIgUkZDcy4pIFRoZSBzZWNvbmQgY29uY2x1c2lvbiBpcyBiYXNl ZCBvbiB0aGUgbmV3DQpkaXN0aW5jdGlvbiBvZiBwcm90ZWN0aW9uIHZzLiByZXN0b3JhdGlvbiBh bmQgaXMgdW5uZWNlc3Nhcnkgd2l0aA0KdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLg0KDQpUaGlz IGlzc3VlIGV4aXN0cyBpbiBtdWx0aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlDQoi Y29tbWl0dGVkIiBpcyB1c2VkIGFuZCBJJ2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91bGQgYmUg cmVwbGFjZWQNCndpdGggdGVybWlub2xvZ3kgdXNlZCBpbiB0aGUgcmVmZXJlbmNlZCBSRkNzLCBp LmUuLCAiYWxsb2NhdGlvbiIsDQoiY29ubmVjdGlvbiIsICJjcm9zcy1jb25uZWN0IiwgInByb3Rl Y3Rpb24gc3dpdGNoKG92ZXIpIiwgLi4uDQoNCk5vdGUgSSdtICpub3QqIGhpZ2hsaWdodGluZyBh bGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZQ0KZG9jdW1lbnQgcmVsYXRl ZCB0byB0aGlzIGlzc3VlLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGxhY2VzIGluIHRoZQ0KZG9j dW1lbnQgd2hlcmUgSSB0aGluayBpdCdzIHBvc3NpYmxlIHRoYXQgb25jZSB0aGlzIHRlcm1pbm9s b2d5DQphbWJpZ3VpdHkgaXMgY29ycmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0YW50 aXZlIGNvbW1lbnRzLg0KDQotIFNlY3Rpb24gMiwgMXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5j ZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkgZGVmaW5lcw0KdGhlIHNjb3BlL3B1cnBvc2Ugb2YgdGhl IGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlvbnMNCnRvIHByb3RvY29s IGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGUNCnJlcXVpcmVt ZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJJ2QgcmVwZWF0IHRoaXMg aW4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJvbm91bmNlZCBwbGFjZSBp biBzZWN0aW9uIDEgKG9yDQozKS4NCg0KLSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBm b3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQpwcm90ZWN0aW9uOiBIb3cgaXMgY28tcm91 dGluZyBwcmVzZXJ2ZWQgZm9yIHRoZSByZXZlcnNlIHBhdGggaW4gU01QPw0KSSdkIGFzc3VtZWQg dGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3b3VsZCBiZQ0KcmVx dWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVyc2UgTFNQIGluIHRoZSBj by1yb3V0ZWQNCmNhc2UsIGJ1dCBkb24ndCBzZWUgdGhpcyBpbiB0aGUgZG9jdW1lbnQuDQoNCi0g SW4gc2VjdGlvbiA0IGFuZCA1LjIgeW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmlu aW5nDQpwcmVlbXB0aW9uIHRlcm1pbm9sb2d5IGFuZCBiZWhhdmlvci4gSSB0aGluayA2MzcyIGlz IHRoZSByaWdodA0KcmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBjb250 ZXh0IG9mIHN1cnZpdmFiaWxpdHkgYW5kDQppbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFuZS4N Cg0KLSBJbiBzZWN0aW9uIDQuMiB5b3Ugc2F5ICJUaGVyZWZvcmUsIGl0IGlzIHN1Z2dlc3RlZCB0 aGF0IHRoaXMgYmUNCmNhcnJpZWQgb3V0IHVuZGVyIHRoZSBjb250cm9sIG9mIGEgZHluYW1pYyBj b250cm9sIHBsYW5lIHNpbWlsYXIgdG8NCkdNUExTIFtSRkMzOTQ1XS4iIHBlcmhhcHMgeW91IG1l YW4gImJhc2VkIG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KcGxlYXNlIG1ha2UgdGhlIGNvcnJl Y3Rpb24uIElmIG5vdCwgSSB0aGluayB0aGUgZGViYXRlIG9mIHdoaWNoDQpjb250cm9sIHByb3Rv Y29sIGlzIHVzZWQgZm9yIE1QTFMtVFAgaXMgd2F5IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcw0K ZG9jdW1lbnQuDQoNCi0gU2VjdGlvbiA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlvdSB1c2lu ZyAiU0hPVUxEIE5PVCIgaGVyZT8gSWYNCnJlZmVycmluZyB0byBzb2x1dGlvbnMgY29uZm9ybWFu dCB3aXRoIHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlc2UgYXJlDQppbmZvcm1hdGl2ZSBzdGF0ZW1l bnRzLCAiYW5kIGEgbm9uLWNvbnRyb2wgcGxhbmUgYmFzZWQgU01QIHN3aXRjaG92ZXINCm1lY2hh bmlzbSBpcyB1c2VkLCB0aGUgY29udHJvbCBwbGFuZSBTSEFMTCBOT1QgLi4uIi4gSWYgcmVmZXJy aW5nIHRvDQphbiBvcGVyYXRvcidzL3VzZXIncyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNoYW5p c20sIEkgdGhpbmsgdGhlIG1vc3QNCnlvdSBjYW4gc2F5IGlzIE1BWS4NCg0KLSBTZWN0aW9uIDUu Mi4gIlRpZS1icmVha2luZyBydWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNN UA0KZG9tYWluLiIgQXMgdGhpcyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0 aWUtYnJlYWtpbmcNCnJ1bGVzIiBzaG91bGQgYmUgZGVmaW5lZCBkaXJlY3RseSBvciBieSByZWZl cmVuY2UuDQoNCi0gU2VjdGlvbiA1LjMuIFJGQzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUg cHJlZW1wdGlvbiBub3RpZmljYXRpb24NCmxldmVyYWdlcyB0aGUgc3RhbmRhcmQgTVBMUy1UUCBP QU0gbWVjaGFuaXNtcywgaXMgdGhlcmUgYW55IHJlYXNvbiB0bw0KZG8gbW9yZSAvIG5vdCBqdXN0 IGZvbGxvdyA2MzcyPw0KDQotIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9u IHJlcXVpcmVkIG9uIHNvZnQtcHJlZW1wdGlvbiBhcw0Kd2VsbCAoZGVwZW5kaW5nIG9uIHRoZSBj cm9zcy1jb25uZWN0cyBlc3RhYmxpc2hlZCBkdXJpbmcgTFNQDQplc3RhYmxpc2htZW50KSBzbyBj b29yZGluYXRlZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1cHBvcnRlZA0KaW5kZXBlbmRlbnQgb2Yg cHJlZW1wdGlvbiBtb2RlLg0KDQpOaXRzOg0KDQotIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0 aGUgdGVybSAiZXhlY3V0aXZlIGFjdGlvbiIgYmVpbmcgdXNlZCBpbiBhbnkNCmVhcmxpZXIgcmVs YXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhlciB0aGFuIGludHJvZHVjZSBhIG5ldyAoYW5kDQp1 bmRlZmluZWQpIHRlcm0sIHBlcmhhcHMgeW91IGNhbiB1c2UgYW4gZXhpc3Rpbmcgb25lLCBlLmcu LA0KInByb3RlY3Rpb24gc3dpdGNoIj8NCg0KLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBEbyB3 ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YNCk1QTFMtVFAgdG8gZGViYXRlPyBJ IHN1Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9yaXRlIE1QTFMtVFANCmRvY3VtZW50 KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQoNClRoZSBsYXN0IHNl bnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZlIHN0YXRlbWVudC4gV2hldGhlciBpdCBpcw0K Y3JpdGljYWwgb3Igbm8gaXMgdW5uZWNlc3NhcnkuIFlvdSBjYW4ganVzdCBzYXkgc29tZXRoaW5n IGxpa2UgNjM3Mg0KcHJvdmlkZXMgYSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1U UCBhbmQgaXMgdGhlIGZvdW5kYXRpb24NCmZvciB0aGlzIGRvY3VtZW50Lg0KDQotIFNlY3Rpb24g MSwgcGFyYWdyYXBoIDMuIElzbid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD8N CkFsc28gZHJvcCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0IGlzIGFuIHVubmVjZXNzYXJ5IHF1YWxp ZmllciBhbmQNCjQ0MjcvNDQyOCBkb24ndCB1c2UgaXQuDQoNCi0gU2VjdGlvbnMgMyAoYW5kIHRv IGEgbGVzc2VyIGRlZ3JlZSBzZWN0aW9uIDIpIGFyZSByZWFsbHkgaW50cm9kdWN0b3J5DQp0ZXh0 LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5IGFyZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS4NCg0K LSBTZWN0aW9uIDMuMiBzaG91bGQgaGF2ZSBhIHJlZmVyZW5jZSBmb3IgImV4aXN0aW5nIGNvbnRy b2wgcGxhbmUNCnNvbHV0aW9ucyBmb3IgU01QIHdpdGhpbiBNUExTIi4NCg0KLSBTZWN0aW9uIDMu MiBhZ2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCg0KLSBTZWN0aW9uIDQu MS4gWW91IHNheSAidHdvIG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5 DQptZWFuICJzaW11bHRhbmVvdXNseSIgb3IgbWVyZWx5IHRoYXQgdGhleSBtdXN0IGJvdGggb2Nj dXIgZm9yDQpwcm90ZWN0aW9uIHRvIGJlIHByb3ZpZGVkPyAoU2FtZSBjb21tZW50IGluIHNlY3Rp b24gNS4xLg0KDQotIFNlY3Rpb24gNS4yLiBJIHN1Z2dlc3QgbnVtYmVyaW5nIHRoZSBjdXJyZW50 bHkgYnVsbGV0dGVkIHJlcXVpcmVtZW50cw0KbGlzdC4NCg0KLSBTZWN0aW9uIDUuMjogRmlyc3Qg cGFyYWdyYXBoIGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50ZW5jZS4gVGhlc2UNCmJvdGggYmFz aWNhbGx5IGNvdmVyIHRoZSBzYW1lIHRvcGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5 DQpzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzLiBJIHN1Z2dlc3QgY29tYmluZSBpbnRvIGEgc2lu Z2xlDQpyZXF1aXJlbWVudCB0byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJhZ2Ug b2YgdGhlIHRvcGljLg0KDQotIFNlY3Rpb24gNS4yLCByZXEgNS4gSG93IGRvZXMgdGhpcyByZWxh dGUgdG8gc2VjdGlvbiA1LjU/IFNob3VsZG4ndA0KdGhlIHRvcGljcyByZWxhdGVkIHRvIHRpbWlu ZyBiZSBjb25zb2xpZGF0ZWQ/DQoNCi0gU2VjdGlvbiA1LjI6IHJlcXVpcmVtZW50IDYgc2VlbXMg dG8gYmUgYSBzdWJzZXQgb2YgNywgc28gaXQgc2hvdWxkIGJlDQpkcm9wcGVkLg0KDQotIFNlY3Rp b24gNS4yLCByZXF1aXJlbWVudCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/IFdoeSBjYWxs IG91dA0KanVzdCB0aGlzIG9uZSB0cmFmZmljIHRyZWF0bWVudCAoc3ViKSByZXF1aXJlbWVudD8N Cg0KLSBTZWN0aW9uIDUuMy4gcy9NQVkvd2lsbA0KDQotIHNlY3Rpb24gNS40OiAiIFdoZW4gdGhl IHdvcmtpbmcgcGF0aCBkZXRlY3RzLi4iIGRldGVjdGlvbiBpcyBieSB0aGUNCm5vZGUgbm90IHRo ZSBwYXRoLg0KDQotIFNlY3Rpb24gNS40LCBsYXN0IHNlbnRlbmNlLiBUaGlzIGlzIG9ubHkgdGhl IDJuZCB0aW1lIHlvdSBpbXBseSB0aGF0DQp0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50 cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGluayB0aGlzDQpwb2ludCBpcyBjdXJyZW50bHkgdG9v IHN1YnRsZSBpbiB0aGUgZG9jdW1lbnQuIChUaGlzIHBvaW50IHdhcyBhbHNvDQptYWRlIGFzIGEg bWlub3IgY29tbWVudC4pDQoNCi0gc2VjdGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZl cmVuY2VkDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIw cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPkRlYXIgTG91LDwvZm9udD48L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciB2YWx1YWJsZSBj b21tZW50cy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+VGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBoYXZlIGRpc2N1c3NlZCB5b3VyIGNv bW1lbnRzLCBhbmQgYXJlIHByb3Bvc2luZyBvdXIgcmVzb2x1dGlvbnMgdG8geW91ciBjb21tZW50 cy4gUGxlYXNlLCBsZXQgdXMga25vdyBpZiB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8g YWRkcmVzcyB5b3VyIGNvbW1lbnRzIGFuZCBjb25jZXJucy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QmVzdCByZWdhcmRzLDwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj5BdXRob3Jz IG9mIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzIGRyYWZ0PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj4qKioqKiogQmVnaW5uaW5nIG9mIENvbW1lbnQgUmVzb2x1 dGlvbiAqKioqKio8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gRG9jdW1l bnQncyB1c2FnZSBvZiAmcXVvdDtjb21taXR0ZWQmcXVvdDsgdnMgJnF1b3Q7YWxsb2NhdGVkJnF1 b3Q7IHJlc291cmNlczo8YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDEgdGhlIGRvY3VtZW50IGludHJv ZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZTxicj4NCmRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVj dGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgYmFzZWQgb24gd2hlbjxicj4NCnJlc291cmNlcyBhcmUg JnF1b3Q7Y29tbWl0dGVkJnF1b3Q7LiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0PGJyPg0KZGVm aW5pdGlvbi4gUkZDNDQyNyBhbmQgNjM3MiBtYWtlIHRoZSBkaXN0aW5jdGlvbiB0aGF0IHByb3Rl Y3Rpb248YnI+DQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3VyY2Vz IGFyZSAqYWxsb2NhdGVkKiBub3Q8YnI+DQoqY29tbWl0dGVkKi4gVG8gcXVvdGUgUkZDIDQ0Mjc6 PGJyPg0KPGJyPg0KVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9y YXRpb24gaXMgbWFkZSBiYXNlZDxicj4NCm9uIHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uIGRvbmUg ZHVyaW5nIHRoZSByZWNvdmVyeSBMU1Avc3Bhbjxicj4NCmVzdGFibGlzaG1lbnQuIFRoZSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZjxicj4NCnJlc3RvcmF0aW9uIGlzIG1h ZGUgYmFzZWQgb24gdGhlIGxldmVsIG9mIHJvdXRlIGNvbXB1dGF0aW9uLDxicj4NCnNpZ25hbGlu ZywgYW5kIHJlc291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSByZXN0b3JhdGlvbjxicj4NCkxT UC9zcGFuIGVzdGFibGlzaG1lbnQuPGJyPg0KPGJyPg0KVGhpcyBkaWZmZXJlbmNlIGFsc28gbGVh ZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZTxicj4NCmRvY3VtZW50IGFzIHdl bGwgYXMgYW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNvbmZ1c2lvbiBieSB0aGU8YnI+DQpy ZWFkZXIuIFRoZSB0ZXJtICZxdW90O2NvbW1pdHRlZCZxdW90OyBpcyBub3QgdGlnaHRseSBkZWZp bmVkIGluIHRoaXM8YnI+DQpkb2N1bWVudCAob3IgZWFybGllciB3b3JrKSBhbmQgaXMgdXNlZCBk aWZmZXJlbnRseSB0aGFuIGhvdzxicj4NCiZxdW90O2FsbG9jYXRlZCZxdW90OyBoYXMgYmVlbiB1 c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGluPGJyPg0KU2VjdGlvbiAzLjEg d2hpY2ggc3RhdGVzOjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSBjb21taXRtZW50IG9mIHRoZSBy ZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGU8YnI+DQpzaGFyZWQgc2VnbWVudHMsIHdpbGwgb25s eSBiZSBmaW5hbGl6ZWQgd2hlbiB0aGUgcHJvdGVjdGlvbjxicj4NCnBhdGggaXMgYWN0dWFsbHkg YWN0aXZhdGVkLiBUaGVyZWZvcmUsIGZvciB0aGUgcHVyaXN0cyAtPGJyPg0KcmVnYXJkaW5nIHRo ZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBiZXR3ZWVuPGJyPg0KcHJvdGVjdGlv biBhbmQgcmVzdG9yYXRpb24uPGJyPg0KPGJyPg0KQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1h dGljLiBJbiB0aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG88YnI+DQpjb3ZlciBhICZxdW90 O3Byb3RlY3Rpb24gc3dpdGNoJnF1b3Q7IHdvdWxkICZxdW90O2Nvbm5lY3QmcXVvdDsgdGhlIHBy b3RlY3Rpb24gcGF0aDxicj4NCmJ1dCBub3QgdGhlIGVhcmxpZXIgJnF1b3Q7YWxsb2NhdGlvbiZx dW90OyBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMgYXJlPGJyPg0KdXNlZCBpbiBlYXJsaWVy IFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQgb24gdGhlIG5ldzxicj4NCmRp c3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9uIGFuZCBpcyB1bm5lY2Vzc2Fy eSB3aXRoPGJyPg0KdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLjxicj4NCjxicj4NClRoaXMgaXNz dWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQgd2hlcmU8YnI+DQom cXVvdDtjb21taXR0ZWQmcXVvdDsgaXMgdXNlZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0IGVhY2gg c2hvdWxkIGJlIHJlcGxhY2VkPGJyPg0Kd2l0aCB0ZXJtaW5vbG9neSB1c2VkIGluIHRoZSByZWZl cmVuY2VkIFJGQ3MsIGkuZS4sICZxdW90O2FsbG9jYXRpb24mcXVvdDssPGJyPg0KJnF1b3Q7Y29u bmVjdGlvbiZxdW90OywgJnF1b3Q7Y3Jvc3MtY29ubmVjdCZxdW90OywgJnF1b3Q7cHJvdGVjdGlv biBzd2l0Y2gob3ZlcikmcXVvdDssIC4uLjxicj4NCjxicj4NCk5vdGUgSSdtICpub3QqIGhpZ2hs aWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZTxicj4NCmRv Y3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNl cyBpbiB0aGU8YnI+DQpkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhhdCBv bmNlIHRoaXMgdGVybWlub2xvZ3k8YnI+DQphbWJpZ3VpdHkgaXMgY29ycmVjdGVkIHRoYXQgSSds bCBoYXZlIG90aGVyIHN1YnN0YW50aXZlIGNvbW1lbnRzLjwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9S OiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5bQXV0aG9yc10gQWZ0ZXIgcmV2aWV3 aW5nIFJGQ3MgNDQyNywgNjM3MiwgMzk0NSwgNDQyNiwgYW5kIDQ0MjgsIHdlIGNvbmNsdWRlZCB0 aGF0IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIHNo b3VsZCBiZSBhbGlnbmVkIHdpdGggdGhlIGV4aXRpbmcgZG9jdW1lbnRzIG5vcm1hdGl2ZWx5IHJl ZmVyZW5jZWQNCiBieSB0aGlzIGRvY3VtZW50LiBBY2NvcmRpbmdseSwgdGhlIGZvbGxvd2luZyAx NiBtb2RpZmljYXRpb25zIHdpbGwgYmUgZG9uZSBpbiByZXZpc2lvbjo8L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+KDEpIFNlY3Rpb24gMSwg dGhlIHRoaXJkIHBhcmFncmFwaDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5BcyBwb2ludGVkIG91dDwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPmluIFtSRkM2MzcyXSBhbmQgW1JGQzQ0MjhdLCBhcHBseWluZyAxJiM0MzsxIGxpbmVh ciBwcm90ZWN0aW9uIHJlcXVpcmVzPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhhdCByZXNvdXJjZXMgYXJlIGNvbW1pdHRl ZCBmb3IgdXNlIGJ5IGJvdGggdGhlIHdvcmtpbmcgYW5kPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJvdGVjdGlvbiBwYXRo cy4gQXBwbHlpbmcgMToxIHByb3RlY3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZTwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnJlc291cmNlcyBhcmUgY29tbWl0dGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhl IHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj5wYXRoIHRvIGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUg ZXh0cmEgdHJhZmZpYy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QXMgcG9pbnRlZCBvdXQ8L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVw LWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SV Ij5pbiBbUkZDNjM3Ml0gYW5kIFtSRkM0NDI4XSwgYXBwbHlpbmcgMSYjNDM7MSBwcm90ZWN0aW9u IHJlcXVpcmVzPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i V09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBu b3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+dGhhdCByZXNvdXJjZXMgYXJlIGFsbG9jYXRlZCBmb3IgdXNlIGJ5 IGJvdGggdGhlIHdvcmtpbmcgYW5kPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJvdGVjdGlvbiBwYXRocy4gQXBwbHlpbmcg MToxIHByb3RlY3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZTwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnJlc291cmNlcyBh cmUgYWxsb2NhdGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhlIHByb3RlY3Rpb248 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5wYXRoIHRvIGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUgZXh0cmEgdHJhZmZp Yy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+KDIpIFRoZSB3aG9sZSB0ZXh0IGluIFNlY3Rpb24gMy4xIHdpbGwgYmUgcmVwbGFjZWQgd2l0 aDoNCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPltSRkM2MzcyXSwgYmFzZWQgdXBvbiB0aGUgZGVmaW5pdGlvbnMgaW4gW1JG QzQ0MjddLCBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuICZxdW90O3Byb3RlY3Rpb24mcXVvdDsgYW5k ICZxdW90O3Jlc3RvcmF0aW9uJnF1b3Q7IGRlcGVuZGVudCB1cG9uIHRoZSBkeW5hbWlzbSBvZiB0 aGUgcmVzb3VyY2UgYWxsb2NhdGlvbi4gVGhlIHNhbWUgZGlzdGluY3Rpb24gaXMgdXNlZCBpbiBb UkZDMzk0NV0sDQogW1JGQzQ0MjZdLCBhbmQgW1JGQzQ0MjhdLiBUaGlzIGRvY3VtZW50IGFsc28g dXNlcyB0aGUgc2FtZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0 aW9uIGFzIHN0YXRlZCBpbiBbUkZDNjM3Ml0uPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigzKSBJbiBwYWdlIDYsPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPlRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBpbiB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkg YSBidXNpbmVzcyBvcjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdI VDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPnBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90 ZWN0aW9uIHJlc291cmNlcyBhcmUgY29udGVuZGVkLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Q09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnByaW9yaXR5IGNhbiBiZSBh cHBsaWVkIHRvIGRldGVybWluZSB0byB3aGljaCBwYXJ0aWVzIHRoZSBwcm90ZWN0aW9uPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+cmVzb3VyY2VzIGFyZSBjb21taXR0ZWQuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoZSB1c2Ug b2YgcHJlZW1wdGlvbiBpbiB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPnBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291cmNl cyBhcmUgY29udGVuZGVkLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPnByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRvIGRldGVy bWluZSB3aGljaCBwYXJ0aWVzIHV0aWxpemUgdGhlIHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5yZXNvdXJj ZXMuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPig0KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6PC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGNvbW1pdHRl ZCw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5ORVc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj50aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBw YXRoIGFyZSBmdWxseSBkZWRpY2F0ZWQsPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5yZXNvdXJjZXMgbWF5IGJlIHBs YW5uZWQgYnV0IHdvdWxkIG5vdCBiZSBjb21taXR0ZWQgdW50aWwg4oCmDQo8L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6 PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+cmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBub3QgYmUgdXRpbGl6 ZWQgdW50aWwg4oCmDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+KDUpIEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHBhZ2UgNywNCjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj4mcXVvdDtIYXJkIFByZWVtcHRpb24mcXVvdDsgcmVxdWlyZXMg dGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUgaW5ncmVzcyBvZiBlYWNoIHNoYXJl ZCBzZWdtZW50IHRvIHNwZWNpZnkgd2hpY2ggYmFja3VwIHBhdGggaGFzIHRoZSBoaWdoZXN0IHBy aW9yaXR5IHdoZW4gY29tbWl0dGluZyBwcm90ZWN0aW9uIHJlc291cmNlcywgdGhlIG90aGVycyBi ZWluZw0KIHByZWVtcHRlZC48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4mcXVvdDtIYXJkIFByZWVtcHRp b24mcXVvdDsgcmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUgaW5n cmVzcyBvZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgdGhlIHByaW9yaXRpZXMgb2Yg YmFja3VwIHBhdGhzLCBzbyB0aGF0IHRyYWZmaWMgb2YgbG93ZXIgcHJpb3JpdHkgcGF0aHMgY2Fu IGJlIHByZWVtcHRlZC4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj4oNikgVGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMTo8 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5PTEQ6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIGFuZCBjb21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3Vy Y2VzLiBUaGUgY29tbWl0bWVudCBvZiByZXNvdXJjZXM8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5pcyBkZXBlbmRlbnQgdXBv biDigKY8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjog bm9uZSIgYWxpZ249ImxlZnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIGFuZCA8L2ZvbnQ+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg Q09MT1I6IGJsdWU7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZm9udC1rZXJuaW5n OiAwcHQiPmNvb3JkaW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mDQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhl IGFzc29jaWF0ZWQgc2hhcmVkIHJlc291cmNlcy4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBs ZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGF5b3V0 LWdyaWQtYWxpZ246IG5vbmUiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoZSA8L2ZvbnQ+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJzsgQ09MT1I6IGJsdWU7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZm9u dC1rZXJuaW5nOiAwcHQiPnJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuunkeyd gCDqs6DrlJUiPmlzIGRlcGVuZGVudCB1cG9uIOKApjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg TElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBi bHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4oNykgVGhlIHNlY29uZCBwYXJhZ3JhcGgg b2YgU2VjdGlvbiA0LjE6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20g MHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09M T1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPldoZW4gdGhlIHJlc2VydmVkIHJl c291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSBjb21taXR0ZWQgdG8gYTwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQg cmVzb3VyY2VzPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i V09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBu b3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+YXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24g cGF0aC4gVGhpcyB0aGVuIGltcGxpZXMgdGhhdDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20g MHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09M T1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPmlmIGFub3RoZXIgd29ya2luZyBw YXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnN3aXRj aCwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcyBtYXkgZmFpbC4gSW4gb3JkZXIgdG88 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5vcHRpbWl6ZSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBjb21taXRtZW50IGFuZCBwcmVw YXJpbmcgZm9yIGNhc2VzIG9mPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+bXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5n LCB0aGUgY29tbWl0bWVudCBvZiB0aGUgc2hhcmVkPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cmVzb3VyY2VzIGFyZSBiZSBj b29yZGluYXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZyBwYXRocyBpbjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnRoZSBTTVAgbmV0d29yay48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+V2hlbiB0aGUgcmVzZXJ2ZWQg cmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIHV0aWxpemVkIGJ5IGE8L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVw LWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SV Ij5wYXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50 IHJlc291cmNlczwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPmF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9u IHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQ8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5pZiBhbm90aGVyIHdvcmtpbmcg cGF0aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2VycyBhIHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5zd2l0 Y2gsIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24gbWF5IGZhaWwuIFRoZSBk aWZmZXJlbnQgd29ya2luZyBwYXRocyBpbjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6 IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnRoZSBTTVAgbmV0d29yayBhcmUgaW52 b2x2ZWQgaW4gdGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbi48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOw0KPC9zcGFuPg0KPD94bWw6bmFtZXNwYWNlIHBy ZWZpeCA9ICJvIiBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2Ui IC8+DQo8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPi48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgVEVYVC1BTElHTjogbGVmdDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgbXNvLWxheW91dC1ncmlk LWFsaWduOiBub25lIiBhbGlnbj0ibGVmdCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+KDgpIFNlY3Rpb24gNS4xLDwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxs OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9M RDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj7igKYgYW5kIGNvbW1pdCB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+TkVXPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgYWxpZ249 ImxlZnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+4oCmIGFuZCA8L2ZvbnQ+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsdWU7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPmNvb3Jk aW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhlIGFzc29jaWF0ZWQg c2hhcmVkIHJlc291cmNlcy4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj4oOSkgSW4gU2VjdGlvbiA1LjEsPC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPkluIHRoZSBjYXNlIG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFpbGluZywgdGhlIGNv bW1pdG1lbnQgb2YgdGhlPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+c2hhcmVkIHJlc291cmNlcyBTSEFMTCBiZSBjb29yZGlu YXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZzwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnBhdGhzIGluIHRoZSBT TVAgbmV0d29yay48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjog Ymx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+SW4gdGhlIGNhc2Ugb2YgbXVsdGlwbGUg d29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgc2hhcmVkIHJlc291cmNlIHV0aWxpemF0aW9uPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzog a2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+Y29vcmRpbmF0aW9uIFNIQUxMIGJlIGJldHdlZW4gdGhlIGRpZmZlcmVudCB3b3JraW5n DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5wYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20g MHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09M T1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigxMCkgU2VjdGlvbiA1LjEuMS48 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5PTEQ6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIGJlY2F1c2UgdGhleSBhbHJlYWR5IGhhdmUgYmVlbiBj b21taXR0ZWQgdG8gdGhlIHByb3RlY3Rpb24gb2YsIGZvciBleGFtcGxlLCBhIGhpZ2hlciBwcmlv cml0eSB3b3JraW5nIHBhdGguPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Q09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPuKApiBiZWNhdXNlIHRoZXkg YWxyZWFkeSBoYXZlIGJlZW4gdXRpbGl6ZWQgZm9yIHRoZSBwcm90ZWN0aW9uIG9mLCBmb3IgZXhh bXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29ya2luZyBwYXRoLjwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4oMTEpIFNlY3Rpb24gNS4yLCB0 aGUgc2Vjb25kIGJ1bGxldCBpdGVtOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBM SU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJs dWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5SZXNvdXJjZXMgb2Yg dGhlIHNoYXJlZCBzZWdtZW50cyBTSEFMTCBiZSBjb21taXR0ZWQgdG8gdGhlPC9mb250Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJv dGVjdGlvbiBwYXRoIOKApjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsOyB0YWItc3RvcHM6IDg3LjZwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PHNwYW4gc3R5 bGU9Im1zby10YWItY291bnQ6IDEiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjog Ymx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+UmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQg c2VnbWVudHMgU0hBTEwgYmUgdXRpbGl6ZWQgYnkgdGhlPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJvdGVjdGlvbiBwYXRo IOKApiA8L2ZvbnQ+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj4oMTIpIFNlY3Rpb24gNS4yLCB0aGUgdGhpcmQgYnVsbGV0IGl0ZW06PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1h bGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ T0xEOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPklmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3Jp dHkgYXJlIHJlcXVlc3Rpbmc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5hbGxvY2F0aW9uIG9mIHRoZSBzaGFyZWQgcmVzb3Vy Y2VzLCB0aGUgcmVzb3VyY2VzIFNIT1VMRCBiZQ0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+Y29tbWl0dGVkIG9uIGEgZmly c3QgY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPklmIG11bHRp cGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3Rpbmc8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj50aGUgc2hhcmVkIHJlc291cmNlcywgdGhlIHJlc291cmNlcyBTSE9VTEQgYmUNCjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPmFzc2lnbmVkIG9uIGEgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuPC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1h bGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigxMykgU2Vj dGlvbiA1LjIsIHRoZSBmb3VydGggYnVsbGV0IGl0ZW06PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxs OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPklm IHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgY29tbWl0dGVkIHRvIGEgcHJvdGVjdGlvbiBw YXRoLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPndob3NlIHdvcmtpbmcgcGF0aCBoYXMgYSBsb3dlciBwcmlvcml0eSwgcmVz b3VyY2VzIHJlcXVpcmVkIGZvcjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnRoZSBoaWdoZXIgcHJpb3JpdHkgcGF0aCBTSEFM TCBiZSBjb21taXR0ZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eTwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnBhdGguPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+TkVXOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPklmIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgdXRpbGl6ZWQg YnkgYSBwcm90ZWN0aW9uIHBhdGgsPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+d2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxv d2VyIHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhlIGhpZ2hlciBw cmlvcml0eSBwYXRoIFNIQUxMIGJlIGFzc2lnbmVkIHRvIHRoZSBoaWdoZXIgcHJpb3JpdHk8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj5wYXRoLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+KDE0KSBTZWN0aW9uIDUuMi4gdGhlIHNldmVudGggYnVsbGV0IGl0ZW08L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5PTEQ6 PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+T25jZSByZXNvdXJjZXMgb2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNj ZXNzZnVsbHkgY29tbWl0dGVkPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dG8gYSBwcm90ZWN0aW9uIHBhdGgsIOKApjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPk5FVzo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5PbmNlIHJlc291cmNlcyBvZiBzaGFyZWQgc2VnbWVudHMgaGF2ZSBi ZWVuIHN1Y2Nlc3NmdWxseSB1dGlsaXplZDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6 IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPmJ5IGEgcHJvdGVjdGlvbiBwYXRoLCDi gKY8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+KDE1KSBTZWN0aW9uIDUuMywgdGhlIGZpcnN0IHBhcmFncmFwaCw8L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5PTEQ6PC9m b250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzog a2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+4oCmIHJlcXVlc3QgdGhlIGNvbW1pdG1lbnQgb2YgcHJvdGVjdGlvbiByZXNvdXJjZXMu IElmIHRoZSBuZWNlc3Nhcnk8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5zaGFyZWQgcmVzb3VyY2VzIGFyZSB1bmF2YWlsYWJs ZSB0byBiZSBjb21taXR0ZWQgdG8gdGhlIHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5wYXRoLCB0aGUgZW5k cG9pbnRzIOKApjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIHJlcXVlc3QgdGhlIGNvb3JkaW5hdGlvbiBvZiB0 aGUgc2hhcmVkIHJlc291cmNlIHV0aWxpemF0aW9uLiBJZiB0aGUgbmVjZXNzYXJ5PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1h bGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ c2hhcmVkIHJlc291cmNlcyBhcmUgdW5hdmFpbGFibGUsIHRoZSBlbmRwb2ludHMg4oCmPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigxNikg U2VjdGlvbiA1LjMsIHRoZSBzZWNvbmQgcGFyYWdyYXBoLDwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFs bDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5T aW1pbGFybHksIGlmIHByZWVtcHRpb24gaXMgc3VwcG9ydGVkIGFuZCB0aGUgcmVzb3VyY2VzIGN1 cnJlbnRseTwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPmNvbW1pdHRlZCBmb3IgYSBwYXJ0aWN1bGFyIHdvcmtpbmcgcGF0aCBh cmUg4oCmPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlNpbWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBz dXBwb3J0ZWQgYW5kIHRoZSByZXNvdXJjZXMgY3VycmVudGx5PC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dXRpbGl6ZWQgYnkg YSBwYXJ0aWN1bGFyIHdvcmtpbmcgcGF0aCBhcmUg4oCmPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+LSBTZWN0aW9uIDIsIDFzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2UuIFRoaXMgc2Vu dGVuY2UgcmVhbGx5IGRlZmluZXM8YnI+DQp0aGUgc2NvcGUvcHVycG9zZSBvZiB0aGUgZG9jdW1l bnQsIGkuZS4sICZxdW90O2NsYXJpZmllcyB0aGUgaW5zdHJ1Y3Rpb25zPGJyPg0KdG8gcHJvdG9j b2wgZGVzaWduZXJzIHByb2R1Y2luZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZTxicj4NCnJl cXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuJnF1b3Q7IEFzIHN1Y2gsIEknZCBy ZXBlYXQgdGhpcyBpbjxicj4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJv bm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yPGJyPg0KMykuPGJyIHN0eWxlPSJtc28tc3Bl Y2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFy YWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFdlIGNhbiBhZGQgdGhlIGZv bGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDE6PC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCcVGhp cyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBjbGFyaWZ5IHRoZSBpbnN0cnVjdGlvbnMgdG8gcHJv dG9jb2wgZGVzaWduZXJzIHByb2R1Y2luZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZSByZXF1 aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzIGRvY3VtZW50LuKAnTwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBm b3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQPGJyPg0KcHJvdGVjdGlvbjogSG93IGlzIGNv LXJvdXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD88YnI+DQpJJ2Qg YXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggY29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxk IGJlPGJyPg0KcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVyc2Ug TFNQIGluIHRoZSBjby1yb3V0ZWQ8YnI+DQpjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhl IGRvY3VtZW50LjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4N CjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi PltBdXRob3JzXSBGYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGJ5IHRoaXMgZG9jdW1lbnQu IEV2ZW4gaW4gdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIHN1Y2ggYXMgUkZD IDYzNzggKFBTQykgYW5kIFJGQyA3MjcxIChQU0MgaW4gQVBTIG1vZGUpLCBmYXRlLXNoYXJpbmcg aXMgbm90IHJlcXVpcmVkIGFzIHVuaWRpcmVjdGlvbmFsDQogc3dpdGNoaW5nIGlzIGFsbG93ZWQu IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW1wb3NlIGFueSByZXN0cmljdGlvbiBvbiBjby1yb3V0 aW5nLCBlaXRoZXIuDQo8L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi Pi0gSW4gc2VjdGlvbiA0IGFuZCA1LjIgeW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRl ZmluaW5nPGJyPg0KcHJlZW1wdGlvbiB0ZXJtaW5vbG9neSBhbmQgYmVoYXZpb3IuIEkgdGhpbmsg NjM3MiBpcyB0aGUgcmlnaHQ8YnI+DQpyZWZlcmVuY2UgaGVyZSBhcyBpdCBkZWZpbmVzIGJvdGgg aW4gdGhlIGNvbnRleHQgb2Ygc3Vydml2YWJpbGl0eSBhbmQ8YnI+DQppbiBkZXBlbmRlbnQgb2Yg Y29udHJvbCBwbGFuZS48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVh ayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBi bHVlIj5bQXV0aG9yc10gT25lIGNvbmNlcm4gaXMgdGhhdCBSRkMgNjM3MiBkZXNjcmliZXMgYm90 aCBzb2Z0IGFuZCBoYXJkIHByZWVtcHRpb25zIGluIHRoZSBjb250ZXh0IG9mIGV4dHJhIHRyYWZm aWMsIHdoaWNoIGlzIG5vdCBleGFjdGx5IHRoZSBjYXNlIGZvciBTTVAuPC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIEluIHNlY3Rpb24gNC4yIHlvdSBzYXkgJnF1 b3Q7VGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlPGJyPg0KY2FycmllZCBv dXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2ltaWxhciB0 bzxicj4NCkdNUExTIFtSRkMzOTQ1XS4mcXVvdDsgcGVyaGFwcyB5b3UgbWVhbiAmcXVvdDtiYXNl ZCBvbiBHTVBMUyZxdW90Oz8gSWYgc28sIGdyZWF0LDxicj4NCnBsZWFzZSBtYWtlIHRoZSBjb3Jy ZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBvZiB3aGljaDxicj4NCmNvbnRyb2wg cHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBpcyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGlzPGJyPg0KZG9jdW1lbnQuPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUt YnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0K PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+W0F1dGhvcnNdIFllcywgd2Ugd2lsbCBtYWtlIHRoZSBjb3JyZWN0aW9uLjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUuMSwgcGFy YWdyYXBoIDEuIFdoeSBhcmUgeW91IHVzaW5nICZxdW90O1NIT1VMRCBOT1QmcXVvdDsgaGVyZT8g SWY8YnI+DQpyZWZlcnJpbmcgdG8gc29sdXRpb25zIGNvbmZvcm1hbnQgd2l0aCB0aGlzIGRvY3Vt ZW50LCB0aGVuIHRoZXNlIGFyZTxicj4NCmluZm9ybWF0aXZlIHN0YXRlbWVudHMsICZxdW90O2Fu ZCBhIG5vbi1jb250cm9sIHBsYW5lIGJhc2VkIFNNUCBzd2l0Y2hvdmVyPGJyPg0KbWVjaGFuaXNt IGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNIQUxMIE5PVCAuLi4mcXVvdDsuIElmIHJlZmVy cmluZyB0bzxicj4NCmFuIG9wZXJhdG9yJ3MvdXNlcidzIGNob2ljZSBvZiBwcm90ZWN0aW9uIG1l Y2hhbmlzbSwgSSB0aGluayB0aGUgbW9zdDxicj4NCnlvdSBjYW4gc2F5IGlzIE1BWS48YnIgc3R5 bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1z cGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5bQXV0aG9yc10gVGhlIGZp cnN0IGNhc2UgaXMgdGhlIG9uZSB3ZSBhcmUgYWltaW5nIGF0LiBXZSB3aWxsIHVzZSBTSEFMTCBO T1QuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24g NS4yLiAmcXVvdDtUaWUtYnJlYWtpbmcgcnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBv ZiBhbiBTTVA8YnI+DQpkb21haW4uJnF1b3Q7IEFzIHRoaXMgaXMgYSByZXF1aXJlbWVudCwgd2hh dCB5b3UgbWVhbiBieSAmcXVvdDt0aWUtYnJlYWtpbmc8YnI+DQpydWxlcyZxdW90OyBzaG91bGQg YmUgZGVmaW5lZCBkaXJlY3RseSBvciBieSByZWZlcmVuY2UuPGJyIHN0eWxlPSJtc28tc3BlY2lh bC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0 ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFRoZSBzZW50ZW5jZSBjYW4gYmUg cmV3cml0dGVuIGFzOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdI VDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9S OiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5UaWUtYnJlYWtpbmcgcnVsZXMgU0hB TEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk5FVzo8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBi bHVlOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+SW4gb3JkZXIgdG8gY292ZXIgdGhlJm5i c3A7c2l0dWF0aW9uIHdoZXJlJm5ic3A7dGhlIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIHByaW5j aXBsZSBjYW5ub3QgcmVzb2x2ZSB0aGUgY29udGVudGlvbiBhbW9uZyBtdWx0aXBsZSBlcXVhbCBw cmlvcml0eSByZXF1ZXN0cywgaS5lLiwgd2hlbiB0aGUgcmVxdWVzdHMgb2NjdXINCiBzaW11bHRh bmVvdXNseSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+LCB0 aWUtYnJlYWtpbmcgcnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9t YWluLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gU2VjdGlvbiA1LjMuIFJG QzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb248YnI+ DQpsZXZlcmFnZXMgdGhlIHN0YW5kYXJkIE1QTFMtVFAgT0FNIG1lY2hhbmlzbXMsIGlzIHRoZXJl IGFueSByZWFzb24gdG88YnI+DQpkbyBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYzNzI/PGJyIHN0 eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28t c3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFdlIGNh biBhZGQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBhdCB0aGUgZW5kOg0KPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCcQXMg ZGVzY3JpYmVkIGluIFtSRkM2MzcyXSwgdGhlIGV2ZW50IG9mIHByZWVtcHRpb24gbWF5IGJlIGRl dGVjdGVkIGJ5IE9BTSBhbmQgcmVwb3J0ZWQgYXMgYSBmYXVsdCBvciBhIGRlZ3JhZGF0aW9uIG9m IHRyYWZmaWMgZGVsaXZlcnku4oCdPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBM SU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9u IHJlcXVpcmVkIG9uIHNvZnQtcHJlZW1wdGlvbiBhczxicj4NCndlbGwgKGRlcGVuZGluZyBvbiB0 aGUgY3Jvc3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExTUDxicj4NCmVzdGFibGlzaG1l bnQpIHNvIGNvb3JkaW5hdGVkIHN3aXRjaGluZyBzaG91bGQgYmUgc3VwcG9ydGVkPGJyPg0KaW5k ZXBlbmRlbnQgb2YgcHJlZW1wdGlvbiBtb2RlLjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFj dGVyOiBsaW5lLWJyZWFrIj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5l LWJyZWFrIj4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPltBdXRob3JzXSBZZXMsIHdlIHdpbGwgY2hhbmdlIHRoZSBzZWNv bmQgcGFyYWdyYXBoIGZyb20g4oCcU01QIGluIGhhcmQtcHJlZW1wdGlvbiBtb2RlIFNIT1VMRCDi gKbigJ0gdG8g4oCcU01QIFNIT1VMRCDigKbigJ0gYW5kIG1vdmUgdGhlIGNoYW5nZWQgcGFyYWdy YXBoIGFib3ZlIHRoZSBmaXJzdCBwYXJhZ3JhcGguPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBM SU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5OaXRzOjxicj4NCjxicj4NCi0gQWJzdHJhY3Q6IEkgZG9uJ3QgcmVj YWxsIHRoZSB0ZXJtICZxdW90O2V4ZWN1dGl2ZSBhY3Rpb24mcXVvdDsgYmVpbmcgdXNlZCBpbiBh bnk8YnI+DQplYXJsaWVyIHJlbGF0ZWQvcmVmZXJlbmNlZCBSRkNzLiBSYXRoZXIgdGhhbiBpbnRy b2R1Y2UgYSBuZXcgKGFuZDxicj4NCnVuZGVmaW5lZCkgdGVybSwgcGVyaGFwcyB5b3UgY2FuIHVz ZSBhbiBleGlzdGluZyBvbmUsIGUuZy4sPGJyPg0KJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2gmcXVv dDs/PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0 eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhv cnNdIFllcywgdGhlIHRlcm0gd2lsbCBiZSBjaGFuZ2VkIGFzIHlvdSBzdWdnZXN0ZWQuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gMSwgcGFyYWdy YXBoIDEuIERvIHdlIHJlYWxseSBuZWVkIGFub3RoZXIgZGVmaW5pdGlvbiBvZjxicj4NCk1QTFMt VFAgdG8gZGViYXRlPyBJIHN1Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9yaXRlIE1Q TFMtVFA8YnI+DQpkb2N1bWVudChzKSBhbmQgZHJvcHBpbmcgdGhlIGZpcnN0IGZvdXIgc2VudGVu Y2VzLjxicj4NCjxicj4NClRoZSBsYXN0IHNlbnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZl IHN0YXRlbWVudC4gV2hldGhlciBpdCBpczxicj4NCmNyaXRpY2FsIG9yIG5vIGlzIHVubmVjZXNz YXJ5LiBZb3UgY2FuIGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlIDYzNzI8YnI+DQpwcm92aWRlcyBh IHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBNUExTLVRQIGFuZCBpcyB0aGUgZm91bmRhdGlv bjxicj4NCmZvciB0aGlzIGRvY3VtZW50LjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVy OiBsaW5lLWJyZWFrIj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJy ZWFrIj4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPltBdXRob3JzXSBUaGUgcHJvcG9zZWQgdGV4dCBmb3IgdGhlIHBhcmFn cmFwaCAxIGlzOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPuKAnFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQ KSBpcyBkZXNjcmliZWQgaW4gW1JGQzU5MjFdLA0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+YW5kIFtSRkM2MzcyXSBwcm92 aWRlcyBhIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBNUExTLVRQDQo8L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5hbmQg aXMgdGhlIGZvdW5kYXRpb24gZm9yIHRoaXMgZG9jdW1lbnQu4oCdPC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElzbid0 IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD88YnI+DQpBbHNvIGRyb3AgdGhlIHdv cmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kPGJyPg0KNDQy Ny80NDI4IGRvbid0IHVzZSBpdC48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGlu ZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+ DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5bQXV0aG9yc10gT0suPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+LSBTZWN0aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJlIHJl YWxseSBpbnRyb2R1Y3Rvcnk8YnI+DQp0ZXh0LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5IGFy ZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3Rlcjog bGluZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVh ayI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj5bQXV0aG9yc10gU2VjdGlvbiAzIHdhcyBpbnRlbmRlZCB0byBwcmVzZW50 IGEgcmVmZXJlbmNlIG1vZGVsIGZvciBTTVAuIFNvbWUgdGV4dCBvZiBTZWN0aW9uIDIgaXMgcmVw ZWF0ZWQgaW4gU2VjdGlvbiAxIGFzIHlvdSBzdWdnZXN0ZWQgZWFybGllci4NCjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxs OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lO OiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gU2VjdGlvbiAzLjIgc2hvdWxkIGhhdmUgYSByZWZl cmVuY2UgZm9yICZxdW90O2V4aXN0aW5nIGNvbnRyb2wgcGxhbmU8YnI+DQpzb2x1dGlvbnMgZm9y IFNNUCB3aXRoaW4gTVBMUyZxdW90Oy48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3Rlcjog bGluZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVh ayI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj5bQXV0aG9yc10gW1JGQzQyMDZdIHdpbGwgYmUgYWRkZWQgYXMgYSByZWZl cmVuY2U8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ LSBTZWN0aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAmcXVvdDtleGVjdXRpdmUgYWN0aW9uJnF1b3Q7 IHRlcm0uPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJy IHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1 dGhvcnNdIE9LLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lO OiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gU2VjdGlvbiA0LjEuIFlvdSBzYXkgJnF1b3Q7dHdv IG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkmcXVvdDsuIERvIHlvdSByZWFsbHk8YnI+DQptZWFu ICZxdW90O3NpbXVsdGFuZW91c2x5JnF1b3Q7IG9yIG1lcmVseSB0aGF0IHRoZXkgbXVzdCBib3Ro IG9jY3VyIGZvcjxicj4NCnByb3RlY3Rpb24gdG8gYmUgcHJvdmlkZWQ/IChTYW1lIGNvbW1lbnQg aW4gc2VjdGlvbiA1LjEuPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJl YWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzog a2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+W0F1dGhvcnNdIEJvdGggYWN0aW9ucyBzaG91bGQgb2NjdXIgYXQgdGhlIHNhbWUgdGlt ZSwgb3IgYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0byBwcm92aWRlIGZhc3QgcHJvdGVjdGlvbi4N CjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJF QUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4N CiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVw LWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUu Mi4gSSBzdWdnZXN0IG51bWJlcmluZyB0aGUgY3VycmVudGx5IGJ1bGxldHRlZCByZXF1aXJlbWVu dHM8YnI+DQpsaXN0LjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFr Ij4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPltBdXRob3JzXSBPSywgd2Ugd2lsbCB1c2UgbnVtYmVycy4NCjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUuMjogRmlyc3QgcGFyYWdyYXBo IGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50ZW5jZS4gVGhlc2U8YnI+DQpib3RoIGJhc2ljYWxs eSBjb3ZlciB0aGUgc2FtZSB0b3BpYyAocHJlZW1wdGlvbikgYW5kIGFjdHVhbGx5IHNheTxicj4N CnNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MuIEkgc3VnZ2VzdCBjb21iaW5lIGludG8gYSBzaW5n bGU8YnI+DQpyZXF1aXJlbWVudCB0byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJh Z2Ugb2YgdGhlIHRvcGljLjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJy ZWFrIj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPltBdXRob3JzXSBUaGUgZmlyc3QgcGFyYWdyYXBoIGlzIGZvciBzb2Z0LXByZWVtcHRp b24sIHdoaWxlIHRoZSBmb3VydGggYnVsbGV0IGJlbG9uZ3MgdG8gdGhlIHJlcXVpcmVtZW50cyBv ZiBoYXJkLXByZWVtcHRpb24uDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElO RS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMgcmVsYXRl IHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3Q8YnI+DQp0aGUgdG9waWNzIHJlbGF0ZWQgdG8gdGlt aW5nIGJlIGNvbnNvbGlkYXRlZD88YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGlu ZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+ DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5bQXV0aG9yc10gWWVzLCByZXEgNSBjYW4gYmUgbW92ZWQgdG8gU2VjdGlvbiA1 LjUuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24g NS4yOiByZXF1aXJlbWVudCA2IHNlZW1zIHRvIGJlIGEgc3Vic2V0IG9mIDcsIHNvIGl0IHNob3Vs ZCBiZTxicj4NCmRyb3BwZWQuPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUt YnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0K PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+W0F1dGhvcnNdIFllcywgaXQgd2lsbCBiZSBkZWxldGVkLjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gNS4yLCByZXF1 aXJlbWVudCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/IFdoeSBjYWxsIG91dDxicj4NCmp1 c3QgdGhpcyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/PGJyIHN0eWxl PSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3Bl Y2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFJlcS4gOSB3 aWxsIGJlIGRlbGV0ZWQgYXMgaXQgc2VlbXMgdG8gcmVxdWlyZSBjb250cm9sIHBsYW5lIHN1cHBv cnRzLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj4tIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFy YWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxp bmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIE9LLjwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBzZWN0aW9uIDUuNDogJnF1b3Q7IFdoZW4gdGhlIHdvcmtp bmcgcGF0aCBkZXRlY3RzLi4mcXVvdDsgZGV0ZWN0aW9uIGlzIGJ5IHRoZTxicj4NCm5vZGUgbm90 IHRoZSBwYXRoLjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4N CjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PltBdXRob3JzXSBZZXMuIFdlIHdpbGwgc2ltcGx5IHNheSB0aGF0IOKAnFdoZW4gdGhlIGNvbmRp dGlvbiB0aGF0IHRyaWdnZXJlZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgY2xlYXJlZCwg 4oCm4oCdPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi Pi0gU2VjdGlvbiA1LjQsIGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5kIHRpbWUg eW91IGltcGx5IHRoYXQ8YnI+DQp0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBh IG5ldyBwcm90b2NvbC4gSSB0aGluayB0aGlzPGJyPg0KcG9pbnQgaXMgY3VycmVudGx5IHRvbyBz dWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3YXMgYWxzbzxicj4NCm1hZGUgYXMg YSBtaW5vciBjb21tZW50Lik8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1i cmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5bQXV0aG9yc10gQXMgaW4gb3RoZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGVjaG5v bG9naWVzLCB0d28gbW9kZXMgb2Ygb3BlcmF0aW9ucyAocmV2ZXJ0aXZlIGFuZCBub24tcmV2ZXJ0 aXZlKSBhcmUgcmVxdWlyZWQuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElO RS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPi0gc2VjdGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+W0F1dGhvcnNdIFdlIHdpbGwgYWRkIOKAnGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml3igJ0g dG8gdGhlIGVuZHMgb2YgdHdvIHBhcmFncmFwaHMgZm9yIFdUUiB0aW1lciBhbmQgaG9sZC1vZmYg dGltZXIuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPioqKioqIEVuZCBv ZiBDb21tZW50IHJlc29sdXRpb24gKioqKio8L2ZvbnQ+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDIwcHQiPjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iTWFpbFNpZ25TZW50 IiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iT1JHTUFJ TF9DT05URU5UIiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPg0KPGhyIHRhYmluZGV4PSItMSI+ DQo8Yj7rs7Trgrgg7IKs656MIDogPC9iPiZxdW90O0xvdSBCZXJnZXImcXVvdDsgJmx0O2xiZXJn ZXJAbGFibi5uZXQmZ3Q7PGJyPg0KPGI+67O064K4IOuCoOynnCA6IDwvYj4yMDE0LTA2LTIyIDAx OjAwOjQ4ICggJiM0MzswOTowMCApPGJyPg0KPGI+67Cb64qUIOyCrOuejCA6IDwvYj5ydGctYWRz QHRvb2xzLmlldGYub3JnICZsdDtydGctYWRzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPuyw uOyhsCA6IDwvYj5ydGctZGlyQGlldGYub3JnICZsdDtydGctZGlyQGlldGYub3JnJmd0OywgZHJh ZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnICZsdDtkcmFm dC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBtcGxz QGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPuygnOuqqSA6IDwvYj5bbXBs c10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0 PGJyPg0KPGJyPg0KPGJyPg0KSGVsbG8sPGJyPg0KPGJyPg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXM8YnI+DQpkcmFmdC4g VGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yPGJy Pg0Kcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3Qg Y2FsbCBhbmQgSUVTRzxicj4NCnJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVl c3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXM8YnI+DQp0byBwcm92aWRlIGFzc2lzdGFu Y2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGU8YnI+ DQpSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlPGJyPg0KaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcjxicj4NCjxicj4NCkFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURz LCBpdDxicj4NCndvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURjxicj4NCkxhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSBy ZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoPGJyPg0KZGlzY3Vzc2lv biBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KRG9jdW1lbnQ6IGRyYWZ0LWll dGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dDxicj4NClJldmlld2VyOiBMb3UgQmVyZ2Vy PGJyPg0KUmV2aWV3IERhdGU6IEp1bmUgMjEgMjAxNDxicj4NCklFVEYgTEMgRW5kIERhdGU6IDIw MTQtMDYtMjM8YnI+DQpJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWw8YnI+DQo8YnI+DQpT dW1tYXJ5Ojxicj4NCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1l bnQgdGhhdCBJIHRoaW5rPGJyPg0Kc2hvdWxkIChtdXN0LCBhY3R1YWxseSkgYmUgcmVzb2x2ZWQg YmVmb3JlIHB1YmxpY2F0aW9uLjxicj4NCjxicj4NCkNvbW1lbnRzOjxicj4NCjxicj4NCkkgdGhp bmsgdGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQsIG90aGVyIHRoYW4gYSBjb3VwbGUg b2Y8YnI+DQp0ZXJtaW5vbG9neSByZWxhdGVkIGlzc3VlcywgZWFzaWx5IHVuZGVyc3Rvb2QuIFRo ZSBkb2N1bWVudCBkb2VzPGJyPg0KaGF2ZSBhIG51bWJlciBvZiB0ZXJtaW5vbG9neSBhbmQgdGVj aG5pY2FsIGlzc3VlcyB3aGljaCBzaG91bGQgYmU8YnI+DQpyZWFkaWx5IHJlc29sdmVkIHByaW9y IHRvIHB1YmxpY2F0aW9uLjxicj4NCjxicj4NCk1ham9yIElzc3Vlczo8YnI+DQo8YnI+DQpNYWpv ciBpc3N1ZXMgYXJlIHRoZSB0eXBlIG9mIGNvbmNlcm5zIHRoYXQgd2lsbCByZXN1bHQgaW4gdGhl PGJyPg0KZG9jdW1lbnQgYmVpbmcgYmxvY2tlZCB1bnRpbCB0aGV5IGFyZSByZXNvbHZlZC4gVGhl IFJvdXRpbmcgQURzIHdpbGw8YnI+DQpiZWNvbWUgaW52b2x2ZWQuIFBsZWFzZSBpbmNsdWRlIGFs bCBvZiB0aGUgbWFqb3IgaXNzdWVzIHlvdSBoYXZlPGJyPg0KZm91bmQuIEdpdmUgYXMgbXVjaCBj b250ZXh0IGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0aW9uPGJyPg0KbnVtYmVy cywgcGFyYWdyYXBoIGNvdW50cykuIElmIHlvdSBmaW5kIG5vIG1ham9yIGlzc3VlcywgcGxlYXNl PGJyPg0Kd3JpdGU6ICZxdW90O05vIG1ham9yIGlzc3VlcyBmb3VuZC4mcXVvdDs8YnI+DQo8YnI+ DQotIE5vIG1ham9yIGlzc3VlcyBmb3VuZC4gSW4gcGFydGljdWxhciwgSSBleHBlY3QgYWxsIGlz c3VlcyBjYW4gYmU8YnI+DQpyZXNvbHZlZCB3aXRob3V0IEFEIGludGVydmVudGlvbi4gU29tZSBv ZiB0aGUgbWlub3IgaXNzdWVzLCBpZiBub3Q8YnI+DQpyZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRl ZCB0byB0aGUgQUQvbWFqb3IgaXNzdWUgY2F0ZWdvcnkuPGJyPg0KPGJyPg0KTWlub3IgSXNzdWVz Ojxicj4NCjxicj4NCk1pbm9yIGlzc3VlcyBhcmUgY29uY2VybnMgYWJvdXQgY2xhcml0eSBvciB0 ZWNobmljYWwgYWNjdXJhY3kgdGhhdDxicj4NCnNob3VsZCBiZSBkaXNjdXNzZWQgYW5kIHJlc29s dmVkIGJlZm9yZSBwdWJsaWNhdGlvbiwgYnV0IHdoaWNoIHdvdWxkPGJyPg0Kbm9ybWFsbHkgYmUg cmVzb2x2ZWQgYmV0d2VlbiB0aGUgYXV0aG9ycyBhbmQgdGhlIHJldmlld2Vycy4gUGxlYXNlPGJy Pg0KaW5jbHVkZSBhbGwgb2YgdGhlIG1pbm9yIGlzc3VlcyB5b3UgaGF2ZSBmb3VuZC4gR2l2ZSBh cyBtdWNoIGNvbnRleHQ8YnI+DQppbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSAoZS5nLiwgc2VjdGlv biBudW1iZXJzLCBwYXJhZ3JhcGggY291bnRzKS48YnI+DQpJZiB5b3UgZmluZCBubyBtaW5vciBp c3N1ZXMsIHBsZWFzZSB3cml0ZTogJnF1b3Q7Tm8gbWlub3IgaXNzdWVzIGZvdW5kLiZxdW90Ozxi cj4NCjxicj4NCi0gRG9jdW1lbnQncyB1c2FnZSBvZiAmcXVvdDtjb21taXR0ZWQmcXVvdDsgdnMg JnF1b3Q7YWxsb2NhdGVkJnF1b3Q7IHJlc291cmNlczo8YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDEg dGhlIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZTxicj4NCmRpc3RpbmN0 aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgYmFzZWQgb24gd2hlbjxi cj4NCnJlc291cmNlcyBhcmUgJnF1b3Q7Y29tbWl0dGVkJnF1b3Q7LiBUaGlzIGRpZmZlcmVuY2Ug ZnJvbSBwYXN0PGJyPg0KZGVmaW5pdGlvbi4gUkZDNDQyNyBhbmQgNjM3MiBtYWtlIHRoZSBkaXN0 aW5jdGlvbiB0aGF0IHByb3RlY3Rpb248YnI+DQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2Vk IG9uIHdoZW4gcmVzb3VyY2VzIGFyZSAqYWxsb2NhdGVkKiBub3Q8YnI+DQoqY29tbWl0dGVkKi4g VG8gcXVvdGUgUkZDIDQ0Mjc6PGJyPg0KPGJyPg0KVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJv dGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgbWFkZSBiYXNlZDxicj4NCm9uIHRoZSByZXNvdXJj ZSBhbGxvY2F0aW9uIGRvbmUgZHVyaW5nIHRoZSByZWNvdmVyeSBMU1Avc3Bhbjxicj4NCmVzdGFi bGlzaG1lbnQuIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZjxicj4N CnJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQgb24gdGhlIGxldmVsIG9mIHJvdXRlIGNvbXB1dGF0 aW9uLDxicj4NCnNpZ25hbGluZywgYW5kIHJlc291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSBy ZXN0b3JhdGlvbjxicj4NCkxTUC9zcGFuIGVzdGFibGlzaG1lbnQuPGJyPg0KPGJyPg0KVGhpcyBk aWZmZXJlbmNlIGFsc28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZTxi cj4NCmRvY3VtZW50IGFzIHdlbGwgYXMgYW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNvbmZ1 c2lvbiBieSB0aGU8YnI+DQpyZWFkZXIuIFRoZSB0ZXJtICZxdW90O2NvbW1pdHRlZCZxdW90OyBp cyBub3QgdGlnaHRseSBkZWZpbmVkIGluIHRoaXM8YnI+DQpkb2N1bWVudCAob3IgZWFybGllciB3 b3JrKSBhbmQgaXMgdXNlZCBkaWZmZXJlbnRseSB0aGFuIGhvdzxicj4NCiZxdW90O2FsbG9jYXRl ZCZxdW90OyBoYXMgYmVlbiB1c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGlu PGJyPg0KU2VjdGlvbiAzLjEgd2hpY2ggc3RhdGVzOjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSBj b21taXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGU8YnI+DQpzaGFyZWQg c2VnbWVudHMsIHdpbGwgb25seSBiZSBmaW5hbGl6ZWQgd2hlbiB0aGUgcHJvdGVjdGlvbjxicj4N CnBhdGggaXMgYWN0dWFsbHkgYWN0aXZhdGVkLiBUaGVyZWZvcmUsIGZvciB0aGUgcHVyaXN0cyAt PGJyPg0KcmVnYXJkaW5nIHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBiZXR3 ZWVuPGJyPg0KcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24uPGJyPg0KPGJyPg0KQm90aCBzZW50 ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG88 YnI+DQpjb3ZlciBhICZxdW90O3Byb3RlY3Rpb24gc3dpdGNoJnF1b3Q7IHdvdWxkICZxdW90O2Nv bm5lY3QmcXVvdDsgdGhlIHByb3RlY3Rpb24gcGF0aDxicj4NCmJ1dCBub3QgdGhlIGVhcmxpZXIg JnF1b3Q7YWxsb2NhdGlvbiZxdW90OyBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMgYXJlPGJy Pg0KdXNlZCBpbiBlYXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQg b24gdGhlIG5ldzxicj4NCmRpc3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9u IGFuZCBpcyB1bm5lY2Vzc2FyeSB3aXRoPGJyPg0KdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLjxi cj4NCjxicj4NClRoaXMgaXNzdWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgZG9j dW1lbnQgd2hlcmU8YnI+DQomcXVvdDtjb21taXR0ZWQmcXVvdDsgaXMgdXNlZCBhbmQgSSdkIHJl Y29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkPGJyPg0Kd2l0aCB0ZXJtaW5vbG9n eSB1c2VkIGluIHRoZSByZWZlcmVuY2VkIFJGQ3MsIGkuZS4sICZxdW90O2FsbG9jYXRpb24mcXVv dDssPGJyPg0KJnF1b3Q7Y29ubmVjdGlvbiZxdW90OywgJnF1b3Q7Y3Jvc3MtY29ubmVjdCZxdW90 OywgJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2gob3ZlcikmcXVvdDssIC4uLjxicj4NCjxicj4NCk5v dGUgSSdtICpub3QqIGhpZ2hsaWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2Js ZW1zIGluIHRoZTxicj4NCmRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJl IGEgY291cGxlIG9mIHBsYWNlcyBpbiB0aGU8YnI+DQpkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0 J3MgcG9zc2libGUgdGhhdCBvbmNlIHRoaXMgdGVybWlub2xvZ3k8YnI+DQphbWJpZ3VpdHkgaXMg Y29ycmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0YW50aXZlIGNvbW1lbnRzLjxicj4N Cjxicj4NCi0gU2VjdGlvbiAyLCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLiBUaGlzIHNl bnRlbmNlIHJlYWxseSBkZWZpbmVzPGJyPg0KdGhlIHNjb3BlL3B1cnBvc2Ugb2YgdGhlIGRvY3Vt ZW50LCBpLmUuLCAmcXVvdDtjbGFyaWZpZXMgdGhlIGluc3RydWN0aW9uczxicj4NCnRvIHByb3Rv Y29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGU8YnI+DQpy ZXF1aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzIGRvY3VtZW50LiZxdW90OyBBcyBzdWNoLCBJJ2Qg cmVwZWF0IHRoaXMgaW48YnI+DQp0aGUgYWJzdHJhY3QgYW5kIG1vdmUgaXQgdG8gYSBtb3JlIHBy b25vdW5jZWQgcGxhY2UgaW4gc2VjdGlvbiAxIChvcjxicj4NCjMpLjxicj4NCjxicj4NCi0gR2Vu ZXJhbCBjb21tZW50OiBmYXRlLXNoYXJpbmcgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExT UDxicj4NCnByb3RlY3Rpb246IEhvdyBpcyBjby1yb3V0aW5nIHByZXNlcnZlZCBmb3IgdGhlIHJl dmVyc2UgcGF0aCBpbiBTTVA/PGJyPg0KSSdkIGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNo IGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3b3VsZCBiZTxicj4NCnJlcXVpcmVkIHRvIHRyaWdnZXIg YSBzd2l0Y2hvdmVyIG9mIHRoZSByZXZlcnNlIExTUCBpbiB0aGUgY28tcm91dGVkPGJyPg0KY2Fz ZSwgYnV0IGRvbid0IHNlZSB0aGlzIGluIHRoZSBkb2N1bWVudC48YnI+DQo8YnI+DQotIEluIHNl Y3Rpb24gNCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBkZWZpbmluZzxi cj4NCnByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMg dGhlIHJpZ2h0PGJyPg0KcmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBj b250ZXh0IG9mIHN1cnZpdmFiaWxpdHkgYW5kPGJyPg0KaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wg cGxhbmUuPGJyPg0KPGJyPg0KLSBJbiBzZWN0aW9uIDQuMiB5b3Ugc2F5ICZxdW90O1RoZXJlZm9y ZSwgaXQgaXMgc3VnZ2VzdGVkIHRoYXQgdGhpcyBiZTxicj4NCmNhcnJpZWQgb3V0IHVuZGVyIHRo ZSBjb250cm9sIG9mIGEgZHluYW1pYyBjb250cm9sIHBsYW5lIHNpbWlsYXIgdG88YnI+DQpHTVBM UyBbUkZDMzk0NV0uJnF1b3Q7IHBlcmhhcHMgeW91IG1lYW4gJnF1b3Q7YmFzZWQgb24gR01QTFMm cXVvdDs/IElmIHNvLCBncmVhdCw8YnI+DQpwbGVhc2UgbWFrZSB0aGUgY29ycmVjdGlvbi4gSWYg bm90LCBJIHRoaW5rIHRoZSBkZWJhdGUgb2Ygd2hpY2g8YnI+DQpjb250cm9sIHByb3RvY29sIGlz IHVzZWQgZm9yIE1QTFMtVFAgaXMgd2F5IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpczxicj4NCmRv Y3VtZW50Ljxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlv dSB1c2luZyAmcXVvdDtTSE9VTEQgTk9UJnF1b3Q7IGhlcmU/IElmPGJyPg0KcmVmZXJyaW5nIHRv IHNvbHV0aW9ucyBjb25mb3JtYW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVzZSBhcmU8 YnI+DQppbmZvcm1hdGl2ZSBzdGF0ZW1lbnRzLCAmcXVvdDthbmQgYSBub24tY29udHJvbCBwbGFu ZSBiYXNlZCBTTVAgc3dpdGNob3Zlcjxicj4NCm1lY2hhbmlzbSBpcyB1c2VkLCB0aGUgY29udHJv bCBwbGFuZSBTSEFMTCBOT1QgLi4uJnF1b3Q7LiBJZiByZWZlcnJpbmcgdG88YnI+DQphbiBvcGVy YXRvcidzL3VzZXIncyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNoYW5pc20sIEkgdGhpbmsgdGhl IG1vc3Q8YnI+DQp5b3UgY2FuIHNheSBpcyBNQVkuPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuMi4g JnF1b3Q7VGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4g U01QPGJyPg0KZG9tYWluLiZxdW90OyBBcyB0aGlzIGlzIGEgcmVxdWlyZW1lbnQsIHdoYXQgeW91 IG1lYW4gYnkgJnF1b3Q7dGllLWJyZWFraW5nPGJyPg0KcnVsZXMmcXVvdDsgc2hvdWxkIGJlIGRl ZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLjxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjMu IFJGQzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb248 YnI+DQpsZXZlcmFnZXMgdGhlIHN0YW5kYXJkIE1QTFMtVFAgT0FNIG1lY2hhbmlzbXMsIGlzIHRo ZXJlIGFueSByZWFzb24gdG88YnI+DQpkbyBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYzNzI/PGJy Pg0KPGJyPg0KLSBTZWN0aW9uIDUuNy4gVGhlcmUgbWF5IGJlIGNvb3JkaW5hdGlvbiByZXF1aXJl ZCBvbiBzb2Z0LXByZWVtcHRpb24gYXM8YnI+DQp3ZWxsIChkZXBlbmRpbmcgb24gdGhlIGNyb3Nz LWNvbm5lY3RzIGVzdGFibGlzaGVkIGR1cmluZyBMU1A8YnI+DQplc3RhYmxpc2htZW50KSBzbyBj b29yZGluYXRlZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1cHBvcnRlZDxicj4NCmluZGVwZW5kZW50 IG9mIHByZWVtcHRpb24gbW9kZS48YnI+DQo8YnI+DQpOaXRzOjxicj4NCjxicj4NCi0gQWJzdHJh Y3Q6IEkgZG9uJ3QgcmVjYWxsIHRoZSB0ZXJtICZxdW90O2V4ZWN1dGl2ZSBhY3Rpb24mcXVvdDsg YmVpbmcgdXNlZCBpbiBhbnk8YnI+DQplYXJsaWVyIHJlbGF0ZWQvcmVmZXJlbmNlZCBSRkNzLiBS YXRoZXIgdGhhbiBpbnRyb2R1Y2UgYSBuZXcgKGFuZDxicj4NCnVuZGVmaW5lZCkgdGVybSwgcGVy aGFwcyB5b3UgY2FuIHVzZSBhbiBleGlzdGluZyBvbmUsIGUuZy4sPGJyPg0KJnF1b3Q7cHJvdGVj dGlvbiBzd2l0Y2gmcXVvdDs/PGJyPg0KPGJyPg0KLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBE byB3ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2Y8YnI+DQpNUExTLVRQIHRvIGRl YmF0ZT8gSSBzdWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcgeW91ciBmYXZvcml0ZSBNUExTLVRQPGJy Pg0KZG9jdW1lbnQocykgYW5kIGRyb3BwaW5nIHRoZSBmaXJzdCBmb3VyIHNlbnRlbmNlcy48YnI+ DQo8YnI+DQpUaGUgbGFzdCBzZW50ZW5jZSBhbHNvIG1ha2VzIGEgc3ViamVjdGl2ZSBzdGF0ZW1l bnQuIFdoZXRoZXIgaXQgaXM8YnI+DQpjcml0aWNhbCBvciBubyBpcyB1bm5lY2Vzc2FyeS4gWW91 IGNhbiBqdXN0IHNheSBzb21ldGhpbmcgbGlrZSA2MzcyPGJyPg0KcHJvdmlkZXMgYSBzdXJ2aXZh YmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZvdW5kYXRpb248YnI+DQpm b3IgdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+DQotIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElz bid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD88YnI+DQpBbHNvIGRyb3AgdGhl IHdvcmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kPGJyPg0K NDQyNy80NDI4IGRvbid0IHVzZSBpdC48YnI+DQo8YnI+DQotIFNlY3Rpb25zIDMgKGFuZCB0byBh IGxlc3NlciBkZWdyZWUgc2VjdGlvbiAyKSBhcmUgcmVhbGx5IGludHJvZHVjdG9yeTxicj4NCnRl eHQuIEknbSB1bnN1cmUgYXMgdG8gd2h5IHRoZXkgYXJlbid0IHBhcnQgb2Ygc2VjdGlvbiAxLjxi cj4NCjxicj4NCi0gU2VjdGlvbiAzLjIgc2hvdWxkIGhhdmUgYSByZWZlcmVuY2UgZm9yICZxdW90 O2V4aXN0aW5nIGNvbnRyb2wgcGxhbmU8YnI+DQpzb2x1dGlvbnMgZm9yIFNNUCB3aXRoaW4gTVBM UyZxdW90Oy48YnI+DQo8YnI+DQotIFNlY3Rpb24gMy4yIGFnYWluIHVzZXMgdGhlICZxdW90O2V4 ZWN1dGl2ZSBhY3Rpb24mcXVvdDsgdGVybS48YnI+DQo8YnI+DQotIFNlY3Rpb24gNC4xLiBZb3Ug c2F5ICZxdW90O3R3byBvcGVyYXRpb25zIHNpbXVsdGFuZW91c2x5JnF1b3Q7LiBEbyB5b3UgcmVh bGx5PGJyPg0KbWVhbiAmcXVvdDtzaW11bHRhbmVvdXNseSZxdW90OyBvciBtZXJlbHkgdGhhdCB0 aGV5IG11c3QgYm90aCBvY2N1ciBmb3I8YnI+DQpwcm90ZWN0aW9uIHRvIGJlIHByb3ZpZGVkPyAo U2FtZSBjb21tZW50IGluIHNlY3Rpb24gNS4xLjxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjIuIEkg c3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQgcmVxdWlyZW1lbnRzPGJy Pg0KbGlzdC48YnI+DQo8YnI+DQotIFNlY3Rpb24gNS4yOiBGaXJzdCBwYXJhZ3JhcGggYW5kIGZv cnRoIGJ1bGxldCBsYXN0IHNlbnRlbmNlLiBUaGVzZTxicj4NCmJvdGggYmFzaWNhbGx5IGNvdmVy IHRoZSBzYW1lIHRvcGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5PGJyPg0Kc2xpZ2h0 bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZTxicj4N CnJlcXVpcmVtZW50IHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBhbmQgZnVsbCBjb3ZlcmFnZSBvZiB0 aGUgdG9waWMuPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMg cmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3Q8YnI+DQp0aGUgdG9waWNzIHJlbGF0ZWQg dG8gdGltaW5nIGJlIGNvbnNvbGlkYXRlZD88YnI+DQo8YnI+DQotIFNlY3Rpb24gNS4yOiByZXF1 aXJlbWVudCA2IHNlZW1zIHRvIGJlIGEgc3Vic2V0IG9mIDcsIHNvIGl0IHNob3VsZCBiZTxicj4N CmRyb3BwZWQuPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1lbnQgOC4gSXNuJ3Qg dGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQ8YnI+DQpqdXN0IHRoaXMgb25lIHRyYWZm aWMgdHJlYXRtZW50IChzdWIpIHJlcXVpcmVtZW50Pzxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjMu IHMvTUFZL3dpbGw8YnI+DQo8YnI+DQotIHNlY3Rpb24gNS40OiAmcXVvdDsgV2hlbiB0aGUgd29y a2luZyBwYXRoIGRldGVjdHMuLiZxdW90OyBkZXRlY3Rpb24gaXMgYnkgdGhlPGJyPg0Kbm9kZSBu b3QgdGhlIHBhdGguPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuNCwgbGFzdCBzZW50ZW5jZS4gVGhp cyBpcyBvbmx5IHRoZSAybmQgdGltZSB5b3UgaW1wbHkgdGhhdDxicj4NCnRoZSBkb2N1bWVudCBj b3ZlcnMgcmVxdWlyZW1lbnRzIG9uIGEgbmV3IHByb3RvY29sLiBJIHRoaW5rIHRoaXM8YnI+DQpw b2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBpbiB0aGUgZG9jdW1lbnQuIChUaGlzIHBvaW50 IHdhcyBhbHNvPGJyPg0KbWFkZSBhcyBhIG1pbm9yIGNvbW1lbnQuKTxicj4NCjxicj4NCi0gc2Vj dGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxz IG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_-- From nobody Thu Jul 3 17:56:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0631B2BA8 for ; Thu, 3 Jul 2014 17:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA8LVVBQ1h8U for ; Thu, 3 Jul 2014 17:56:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C8C1B2B9B for ; Thu, 3 Jul 2014 17:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3907; q=dns/txt; s=iport; t=1404435366; x=1405644966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8FE3IF52eAzM02luRNwAkP8rtkPSDC2JDFmFcYybl08=; b=gqdkYaAiciCz6u8MLYUK8BQZWOHp8YJw38zuyhhZ34qUPeFZOtq6H4Rd +joF7JRzob+i7/+c/EdtvtOcoYa/z6Ej3FNz8MhX2tS3+s61h9AvPMcbC U2mpuS2xRkMb2F0BkXNmDXvMWO+2CbnlVGM7vdh+elyjZI2V6azXbgI0n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAEj6tVOtJV2b/2dsb2JhbABagmkkUlrGIAGBDBZ1hAMBAQEDATo4BwwEAgEIEQQBAQsUCQcyFAkIAQEEAQ0FCIgmAwkIAck3F4x6gXcxBwaDJ4EWAQSWXIVikkODQ4Iw X-IronPort-AV: E=Sophos;i="5.01,598,1400025600"; d="scan'208";a="337695307" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jul 2014 00:56:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s640u5qP024401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 00:56:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 19:56:05 -0500 From: "Nobo Akiya (nobo)" To: "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAArCcJUA== Date: Fri, 4 Jul 2014 00:56:04 +0000 Message-ID: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/WdH8Mk5sgEMsbum4XM8U8EomupE Cc: "Jeffrey \(Zhaohui\) Zhang" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 00:56:08 -0000 Hello Mustapha, Thank you for reviewing this document! Let me provide my individual reply (not speaking for all the authors). > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Thursday, July 03, 2014 6:48 PM > To: mpls@ietf.org > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Aissaoui, Mustapha > (Mustapha); Ross Callon; Jeffrey (Zhaohui) Zhang; > jeremy.whittaker@verizon.com > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > simple-02 >=20 > Dear all, > I was asked to review this draft and I think it describes valid issues to= be > resolved. I however have a couple of comments about the way the authors > went about to address them. >=20 > 1. Relation to RFC 7110 - Return Path Specified Label Switched Path (LSP) > Ping. > Section 4.1 argues the reason why a separate reply mode is needed is for > wanting to omit the Reply Path TLV defined in RFC 7110 when the sender of > the echo request just wanted to use the return path of the tested LSP. I = do > not see this as a strong justification. In many cases, the LSP is unidire= ctional > or the responder node is a transit LSR and may not be able to inject the = reply > in the reverse direction of that LSP. In that case, I can see that provid= ing a > specific return LSP which is different than the tested LSP is required an= d the > Reply Path TLV is needed. >=20 > Assuming this is still an important issue for the authors, I would sugges= t to > relax the rule in RFC 7110 such that if the echo request includes reply m= ode > 5 "Reply via Specified Path" and the Reply Path TLV is not included, the > responder node will interpret this as an implicit request to reply via th= e > reverse direction of the tested LSP. If that's more desired by the WG, I have no objection to that as long as it= doesn't require a TLV to indicate reverse LSP :) >=20 > 2. Reply Mode Order TLV > I am not convinced of the need for this TLV. There is not much reply mode= s > which are usable today together. Only reply mode 2 can be concurrently > used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not > very popular as far as I know. Also, most applications would reply with > mode 2 if the requested mode is not available. So, I can't see how this n= ew > TLV will be useful in practice. You are absolutely correct, not all combinations of the reply modes in the = Reply Mode TLV is realistic. Value Meaning ----- ------- 1 Do not reply 2 Reply via an IPv4/IPv6 UDP packet 3 Reply via an IPv4/IPv6 UDP packet with Router Alert 4 Reply via application level control channel 5 Reply via Specified Path=20 6 Reply via reverse LSP=20 Ping is simple, but let's talk about traceroute. I can imagine following example usage: (1) User prefers IP return path: If (LSP_w_reverse_LSP) { ReplyModeTLV{2, 6} } else if (LSP_w_control_channel) { ReplyModeTLV{2, 4} } else { ReplyMode{2} } (2) User does not prefer IP return path: If (LSP_w_reverse_LSP) { ReplyModeTLV{6, 2} } else if (LSP_w_control_channel) { ReplyModeTLV{4, 2} } else { ReplyMode{2} } Or user can specify a preference to be used for all LSP types (those who wa= nts to make sure response is received back one way or another). (3) User prefers IP return path: If (all_LSP_types) { ReplyModeTLV{2, 6, 4} } else { ReplyMode{2} } (4) User does not prefer IP return path: If (all_LSP_types) { ReplyModeTLV{4, 6, 2} } else { ReplyMode{2} } I hope this answers your comments/concerns a bit :) Thanks! -Nobo >=20 > Regards, > Mustapha. From nobody Thu Jul 3 18:25:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640391B28B8 for ; Thu, 3 Jul 2014 18:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhu061AcQB39 for ; Thu, 3 Jul 2014 18:25:51 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFBA1B27FA for ; Thu, 3 Jul 2014 18:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7219; q=dns/txt; s=iport; t=1404437151; x=1405646751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9ygH8/lMFfZxA8gNwP1xRGQ9npHRTeASsDplXXkQZMw=; b=hphw6dboxT7FR7Hp66ON2QobKz/xjjYMt9wKSqbIhnyGFXyZh7J0Q/83 YBq3oNCS0PjYyFC2yLzClKx0yyB4Any+um9iojOHJEradY9/e4EoEurC3 oE/7oVJFSyHo5GvZGahMQ0ghB56b/s3ykJZeyzz4wbMIILbCm1hCBiymh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEUCtlOtJA2D/2dsb2JhbABQCoJpJFJavmKHPwGBDBZ1hAMBAQEDAQEBAWsEBwUHBAIBCBEEAQEBCh0HJwsUCQgBAQQOBQgTiBMDCQgBDMkrEwSMeoFMKzEHBoMngRYFiheMRZglg0OCMA X-IronPort-AV: E=Sophos;i="5.01,598,1400025600"; d="scan'208";a="58222897" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 04 Jul 2014 01:25:50 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s641PoF3012848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 01:25:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 20:25:50 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin , "Aissaoui, Mustapha (Mustapha)" Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAAtFWXAAAHKr7g Date: Fri, 4 Jul 2014 01:25:49 +0000 Message-ID: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> In-Reply-To: <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.158] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/qtI92VC_QNdl-KFkqZ8WKrCUJxY Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 01:25:55 -0000 Hi again Sam :) Please see in-line. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, July 03, 2014 7:16 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Jeffrey (Zhaohui) Zhang; draft-akiya-mpls-lsp-ping-rep= ly- > mode-simple@tools.ietf.org; Ross Callon; mpls-chairs@tools.ietf.org; > jeremy.whittaker@verizon.com > Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply- > mode-simple-02 >=20 > Authors, >=20 > I too raised the below points highlighted by Mustapha, earlier. In additi= on I > have a more high-level question. >=20 > In the Introduction it says > "However, it is becoming increasingly difficult for an initiator to > select a valid return path to encode in the MPLS LSP echo request > packets. If the initiator does not select a valid return path, the > MPLS LSP echo reply will not get back to the initiator. This results > in a false failure of MPLS LSP Ping and Traceroute operation. In an > effort to minimize such false failures, different implementations > have chosen different default return path encoding for different LSP > types and LSP operations. The problem with implementations having > different default return path encoding is that the MPLS echo reply > will not work in many cases, and the default value may not be the > preferred choice by the operators. > " >=20 > The problems I have is regarding the need for this ID are 1. Can we solve= the > problem without the need for this ID/solution? Answer is yes, albeit it t= akes > one or more requests. If you say, it is solving a problem which was could= n't > be solved earlier, I would like to see. The problem can be addressed with vendors iterating the operation with mult= iple Return Paths when the previous try didn't work. And exact behavior bei= ng well document and operators fully understanding potentially different be= havior per LSP types, per ping/trace operation type and deviating behaviors= across multiple vendors/products. If you implement this, with user prefere= nce knob (yes some prefers IP return path while other do not prefer IP retu= rn path), imagine yourself trying to explain to users how things work, and = imagine yourself trying to explain why vendors/products behave differently.= I sure wouldn't want to :) It's indeed not a problem that cannot be solved= , but it's an aspect of LSP Ping/Trace that can be simplified in terms of i= mplementations and especially operations! > 2. The proposal still cannot identify the problem even with multiple repl= y > modes. If reply cannot be received, adding more reply types may not solve > the issue. That is not what the document is trying to achieve. > 3. This proposed solution works only if the problem is on the replying no= de. > But if the problem is on the transit node of the reply path, this solutio= n will > not work either. Again, that is not what the document is trying to achieve. > 4. As I mentioned earlier, for this new proposal to work effectively, the > responding device has to support this new TLV. Which means, whole of the > network has to support at one point of time of the other. Correct, those transit LSRs not understanding this procedure will simply us= e the Reply Mode field in the MPLS echo request. > 5. With the proposed solution, to determine the problem, one also needs t= o > read the 'reply mode' used by the replying device. IOW, return code + rep= ly > mode used will actually define the behavior. This changes the definition = of > RFC4379. 6. Specific to the text above, I do not agree that the problem i= s due > to implementation. It is the user choice which ever reply mode he/she > wants to use. If using CLI, could chose different reply mode. If it is > application, he/she could select it there. User prefers control channel for operations on TP tunnels. traceroute mpls ... [default reply mode 4 used] Timeout Timeout Timeout Timeout ... Success Operator: What the heck! <20 minutes later> Operator: Oh man, there is no problem! This is tunnel 100 and is not 200, i= t's not co-routed! Just an example :) If possible (and yes it is), the tool should provide better experience to u= sers. >=20 > The point is, why to introduce this optimization solution, where one coul= d > solve the problem without any of this new upgrade? Well, this is my 3rd or 4th attempt to convince you on this topic, so I'll = skip this question :) > Alternatively, for ex: If the reply was being received with reply mode '5= , but > now I don't receive it now, send a new request with reply mode 1. This is > more simple than the proposed solution without needing any change. > I'd be open to hearing the strong reason, this ID is solving, which could= n't be > solved with RFC4379. Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply via Sp= ecified Path) starts timing out? That sounds a very silly, but maybe I'm mi= ssing something. Thanks! -Nobo =20 >=20 > cheers > -sam >=20 >=20 > On Jul 3, 2014, at 3:47 PM, Aissaoui, Mustapha (Mustapha) > wrote: >=20 >=20 > Dear all, > I was asked to review this draft and I think it describes valid issues to= be > resolved. I however have a couple of comments about the way the authors > went about to address them. >=20 > 1.=A0=A0=A0=A0Relation to RFC 7110 - Return Path Specified Label Switched= Path (LSP) > Ping. > Section 4.1 argues the reason why a separate reply mode is needed is for > wanting to omit the Reply Path TLV defined in RFC 7110 when the sender of > the echo request just wanted to use the return path of the tested LSP. I = do > not see this as a strong justification. In many cases, the LSP is unidire= ctional > or the responder node is a transit LSR and may not be able to inject the = reply > in the reverse direction of that LSP. In that case, I can see that provid= ing a > specific return LSP which is different than the tested LSP is required an= d the > Reply Path TLV is needed. > Assuming this is still an important issue for the authors, I would sugges= t to > relax the rule in RFC 7110 such that if the echo request includes reply m= ode > 5 "Reply via Specified Path" and the Reply Path TLV is not included, the > responder node will interpret this as an implicit request to reply via th= e > reverse direction of the tested LSP. >=20 > 2.=A0=A0=A0=A0Reply Mode Order TLV > I am not convinced of the need for this TLV. There is not much reply mode= s > which are usable today together. Only reply mode 2 can be concurrently > used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is not > very popular as far as I know. Also, most applications would reply with > mode 2 if the requested mode is not available. So, I can't see how this n= ew > TLV will be useful in practice. >=20 > Regards, > Mustapha. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 3 19:33:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4321D1B297B for ; Thu, 3 Jul 2014 19:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBSS67rsMBlU for ; Thu, 3 Jul 2014 19:32:55 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAF51B296C for ; Thu, 3 Jul 2014 19:32:55 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id ft15so1175145pdb.21 for ; Thu, 03 Jul 2014 19:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5zVLVW8eCAfsZRFmtJhWUgFTPu9m3LnEU7/q+V46Oi8=; b=QnpYvl/5P8rn33RGso7sCWC6iypCOAaOesoeUKrqvRs5TL6AkLfhrK1fhXMrIPXIqb wGeeN/SThIRs731XEN4emTXM0Z3MiP+ZvywtzQuvllOkKRV/5WarJWSk5vR/3JGFeHEX O154egOAO4uQJLShkSo6N550sh1TvtvKMrG3Jol4aW0VigTpTBGfG9ki/TBB7YsdaQyY fGZSq7wLY6Wlv2jjaWemzrQP5TeyvkPLai1QknAYcU2nkgpgmiJYzLMlmbZkfVWa5itk 2TNy31sdhdz+ycB7L2rvRRzrYC5cj7pS22CctgywJWguwhIDQtTFgPtZgrJyzW4F8hu2 3AIA== X-Received: by 10.68.239.73 with SMTP id vq9mr78923266pbc.99.1404441174993; Thu, 03 Jul 2014 19:32:54 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id fs3sm17033507pac.44.2014.07.03.19.32.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 19:32:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5BB00B7E-A319-4B70-B905-61E09A7169C7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Thu, 3 Jul 2014 19:32:50 -0700 Message-Id: <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/F3kzKv5iUkevoM_Gvnvlcy2dTco Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:32:58 -0000 --Apple-Mail=_5BB00B7E-A319-4B70-B905-61E09A7169C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Nobo, thanks again :D Inline for my comments. On Jul 3, 2014, at 6:25 PM, Nobo Akiya (nobo) wrote: > Hi again Sam :) >=20 > Please see in-line. >=20 >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sam Aldrin >> Sent: Thursday, July 03, 2014 7:16 PM >> To: Aissaoui, Mustapha (Mustapha) >> Cc: mpls@ietf.org; Jeffrey (Zhaohui) Zhang; = draft-akiya-mpls-lsp-ping-reply- >> mode-simple@tools.ietf.org; Ross Callon; mpls-chairs@tools.ietf.org; >> jeremy.whittaker@verizon.com >> Subject: Re: [mpls] MPLS-RT review of = draft-akiya-mpls-lsp-ping-reply- >> mode-simple-02 >>=20 >> Authors, >>=20 >> I too raised the below points highlighted by Mustapha, earlier. In = addition I >> have a more high-level question. >>=20 >> In the Introduction it says >> "However, it is becoming increasingly difficult for an initiator to >> select a valid return path to encode in the MPLS LSP echo request >> packets. If the initiator does not select a valid return path, the >> MPLS LSP echo reply will not get back to the initiator. This = results >> in a false failure of MPLS LSP Ping and Traceroute operation. In = an >> effort to minimize such false failures, different implementations >> have chosen different default return path encoding for different = LSP >> types and LSP operations. The problem with implementations having >> different default return path encoding is that the MPLS echo reply >> will not work in many cases, and the default value may not be the >> preferred choice by the operators. >> " >>=20 >> The problems I have is regarding the need for this ID are 1. Can we = solve the >> problem without the need for this ID/solution? Answer is yes, albeit = it takes >> one or more requests. If you say, it is solving a problem which was = couldn't >> be solved earlier, I would like to see. >=20 > The problem can be addressed with vendors iterating the operation with = multiple Return Paths when the previous try didn't work. > And exact behavior being well document and operators fully = understanding potentially different behavior per LSP types, per = ping/trace operation type and deviating behaviors across multiple = vendors/products. If you implement this, with user preference knob (yes = some prefers IP return path while other do not prefer IP return path), = imagine yourself trying to explain to users how things work, and imagine = yourself trying to explain why vendors/products behave differently. I = sure wouldn't want to :) It's indeed not a problem that cannot be = solved, but it's an aspect of LSP Ping/Trace that can be simplified in = terms of implementations and especially operations! %sam - You say it didn=92t work. Could you provide info why it didn=92t = work? In the last sentence you say it simplifies. So does it simplify or = is it fixing something which was not working earlier? LSP ping itself is full of knobs and it has to be explained. You could = find that in every vendors documentation and it is nothing knew. I know = it because I have authored much of the documentation. >=20 >> 2. The proposal still cannot identify the problem even with multiple = reply >> modes. If reply cannot be received, adding more reply types may not = solve >> the issue. >=20 > That is not what the document is trying to achieve. %sam - ok. we agree. >=20 >> 3. This proposed solution works only if the problem is on the = replying node. >> But if the problem is on the transit node of the reply path, this = solution will >> not work either. >=20 > Again, that is not what the document is trying to achieve. %sam - so, we agree that this enhancement is for replying node only. >=20 >> 4. As I mentioned earlier, for this new proposal to work effectively, = the >> responding device has to support this new TLV. Which means, whole of = the >> network has to support at one point of time of the other. >=20 > Correct, those transit LSRs not understanding this procedure will = simply use the Reply Mode field in the MPLS echo request. %sam - nod. >=20 >> 5. With the proposed solution, to determine the problem, one also = needs to >> read the 'reply mode' used by the replying device. IOW, return code + = reply >> mode used will actually define the behavior. This changes the = definition of >> RFC4379. 6. Specific to the text above, I do not agree that the = problem is due >> to implementation. It is the user choice which ever reply mode he/she >> wants to use. If using CLI, could chose different reply mode. If it = is >> application, he/she could select it there. >=20 > User prefers control channel for operations on TP tunnels. >=20 > traceroute mpls ... [default reply mode 4 used] >=20 > Timeout > Timeout > Timeout > Timeout > ... > Success >=20 > Operator: What the heck! >=20 > <20 minutes later> >=20 > Operator: Oh man, there is no problem! This is tunnel 100 and is not = 200, it's not co-routed! >=20 > Just an example :) >=20 > If possible (and yes it is), the tool should provide better experience = to users. Here is a counter example and response to your example, below. traceroute mpls =85[new tlv - reply mode 5, 2] /* reply mode 5 or 4, I = am just illustrating with 5 here */ success success success success 1hr later, oh shoot, return path is broken but I am getting success = because replies are in the ip path and not on reverse LSP. this is much more harmful than not receiving reply. And to your example, few very important points I=92d like to make 1. getting a timeout is not an issue, when lsp ping command is = incorrectly issued. Infact it is correct. No one can set that right, = when user issues wrong command. 2. What I fail to understand is, how does your proposed solution make it = right? Just because you get the reply all is well? what if the return = path is indeed broken (as illustrated in my example above), you will not = be able to infer something is wrong, (strictly interpreting RFC4379) = because return code received is =913/8/5/6=92.=20 3. Specific to your example, when you perform trace on non-corouted TP = tunnels, timeout SHOULD be returned when there is no return lsp for in = band reply from p1 and p2, because the return path chosen is =91reply = mode 4=92. In order to give =91better experience=92 what command will = you issue and how different the o/p will be, assuming there is no ip on = intermediate nodes.(p1, p2,p3,p4) Sample topology below /=97=97=97=97P1=97=97P2=97=97=97\ PE1=97=97=97 PE2 \=97=97=97=97P3=97=97P4--=97=97-/ PE1->PE2 lsp is via p1, p2 PE2->PE1 lsp is via p4,p3 >=20 >>=20 >> The point is, why to introduce this optimization solution, where one = could >> solve the problem without any of this new upgrade? >=20 > Well, this is my 3rd or 4th attempt to convince you on this topic, so = I'll skip this question :) %sam - That is fine. Point remains though :D >=20 >> Alternatively, for ex: If the reply was being received with reply = mode '5, but >> now I don't receive it now, send a new request with reply mode 1. = This is >> more simple than the proposed solution without needing any change. >> I'd be open to hearing the strong reason, this ID is solving, which = couldn't be >> solved with RFC4379. >=20 > Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply = via Specified Path) starts timing out? That sounds a very silly, but = maybe I'm missing something. typo. Meant to say reply mode 2.=20 >=20 > Thanks! >=20 > -Nobo >=20 >>=20 >> cheers >> -sam >>=20 >>=20 >> On Jul 3, 2014, at 3:47 PM, Aissaoui, Mustapha (Mustapha) >> wrote: >>=20 >>=20 >> Dear all, >> I was asked to review this draft and I think it describes valid = issues to be >> resolved. I however have a couple of comments about the way the = authors >> went about to address them. >>=20 >> 1. Relation to RFC 7110 - Return Path Specified Label Switched = Path (LSP) >> Ping. >> Section 4.1 argues the reason why a separate reply mode is needed is = for >> wanting to omit the Reply Path TLV defined in RFC 7110 when the = sender of >> the echo request just wanted to use the return path of the tested = LSP. I do >> not see this as a strong justification. In many cases, the LSP is = unidirectional >> or the responder node is a transit LSR and may not be able to inject = the reply >> in the reverse direction of that LSP. In that case, I can see that = providing a >> specific return LSP which is different than the tested LSP is = required and the >> Reply Path TLV is needed. >> Assuming this is still an important issue for the authors, I would = suggest to >> relax the rule in RFC 7110 such that if the echo request includes = reply mode >> 5 "Reply via Specified Path" and the Reply Path TLV is not included, = the >> responder node will interpret this as an implicit request to reply = via the >> reverse direction of the tested LSP. >>=20 >> 2. Reply Mode Order TLV >> I am not convinced of the need for this TLV. There is not much reply = modes >> which are usable today together. Only reply mode 2 can be = concurrently >> used with reply mode 5 in RFC 7110 or reply mode 4. Reply mode 3 is = not >> very popular as far as I know. Also, most applications would reply = with >> mode 2 if the requested mode is not available. So, I can't see how = this new >> TLV will be useful in practice. >>=20 >> Regards, >> Mustapha. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_5BB00B7E-A319-4B70-B905-61E09A7169C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Nobo,

thanks again :D
Inline for my = comments.
On Jul 3, 2014, at 6:25 PM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:

Hi again Sam :)

Please see = in-line.

-----Original = Message-----
From: mpls [mailto:mpls-bounces@ietf.org] = On Behalf Of Sam Aldrin
Sent: Thursday, July 03, 2014 7:16 PM
To: = Aissaoui, Mustapha (Mustapha)
Cc: mpls@ietf.org; Jeffrey (Zhaohui) = Zhang; draft-akiya-mpls-lsp-ping-reply-
mode-simple@tools.ietf.org;= Ross Callon; mpls-chairs@tools.ietf.org;=
jeremy.whittaker@verizon.com<= /a>
Subject: Re: [mpls] MPLS-RT review of = draft-akiya-mpls-lsp-ping-reply-
mode-simple-02

Authors,

= I too raised the below points highlighted by Mustapha, earlier. In = addition I
have a more high-level question.

In the = Introduction it says
"However, it is becoming increasingly difficult = for an initiator to
  select a valid return path to encode = in the MPLS LSP echo request
  packets.  If the = initiator does not select a valid return path, the
  MPLS = LSP echo reply will not get back to the initiator.  This = results
  in a false failure of MPLS LSP Ping and = Traceroute operation.  In an
  effort to minimize such = false failures, different implementations
  have chosen = different default return path encoding for different = LSP
  types and LSP operations.  The problem with = implementations having
  different default return path = encoding is that the MPLS echo reply
  will not work in = many cases, and the default value may not be = the
  preferred choice by the operators.
"

The = problems I have is regarding the need for this ID are 1. Can we solve = the
problem without the need for this ID/solution? Answer is yes, = albeit it takes
one or more requests. If you say, it is solving a = problem which was couldn't
be solved earlier, I would like to = see.

The problem can be addressed with vendors = iterating the operation with multiple Return Paths when the previous try = didn't work.
%sam - You say it didn=92t work. Could = you provide info why it didn=92t work? In the last sentence you say it = simplifies. So does it simplify or is it fixing something which was not = working earlier?
LSP ping itself is full of knobs and it has = to be explained. You could find that in every vendors documentation and = it is nothing knew. I know it because I have authored much of the = documentation.

2. The proposal still cannot = identify the problem even with multiple reply
modes. If reply cannot = be received, adding more reply types may not solve
the = issue.

That is not what the document is trying to = achieve.
%sam - ok. we agree.

3. = This proposed solution works only if the problem is on the replying = node.
But if the problem is on the transit node of the reply path, = this solution will
not work either.

Again, that = is not what the document is trying to = achieve.
%sam - so, we agree that this enhancement = is for replying node only.

4. As I = mentioned earlier, for this new proposal to work effectively, = the
responding device has to support this new TLV. Which means, whole = of the
network has to support at one point of time of the = other.

Correct, those transit LSRs not understanding = this procedure will simply use the Reply Mode field in the MPLS echo = request.
%sam - nod.

5. = With the proposed solution, to determine the problem, one also needs = to
read the 'reply mode' used by the replying device. IOW, return = code + reply
mode used will actually define the behavior. This = changes the definition of
RFC4379. 6. Specific to the text above, I = do not agree that the problem is due
to implementation. It is the = user choice which ever reply mode he/she
wants to use. If using CLI, = could chose different reply mode. If it is
application, he/she could = select it there.

User prefers control channel for = operations on TP tunnels.

traceroute mpls ... [default reply mode = 4 = used]

Timeout
Timeout
Timeout
Timeout
...
Success
Operator: What the heck!

<20 minutes = later>

Operator: Oh man, there is no problem! This is tunnel = 100 and is not 200, it's not co-routed!

Just an example = :)

If possible (and yes it is), the tool should provide better = experience to users.
Here is a counter example and = response to your example, below.


success
success

1hr later, oh shoot, return = path is broken but I am getting success because replies are in the ip = path and not on reverse LSP.

this is much more = harmful than not receiving reply.

And to your = example, few very important points I=92d like to make
1. = getting a timeout is not an issue, when lsp ping command is incorrectly = issued. Infact it is correct. No one can set that right, when user = issues wrong command.
2. What I fail to understand is, how = does your proposed solution make it right? Just because you get the = reply all is well? what if the return path is indeed broken (as = illustrated in my example above), you will not be able to infer = something is wrong, (strictly interpreting RFC4379) because return code = received is =913/8/5/6=92. 
3. Specific to your example, = when you perform trace on non-corouted TP tunnels, timeout SHOULD be = returned when there is no return lsp for in band reply from p1 and p2, = because the return path chosen is =91reply mode 4=92. In order to give = =91better experience=92 what command will you issue and how different = the o/p will be, assuming there is no ip on intermediate nodes.(p1, = p2,p3,p4) Sample topology below

    =           =  /=97=97=97=97P1=97=97P2=97=97=97\
PE1=97=97=97   =                     =                   = PE2
              = \=97=97=97=97P3=97=97P4--=97=97-/

PE1->PE2 = lsp is via p1, p2
PE2->PE1 lsp is via p4,p3


The point is, why to introduce this optimization = solution, where one could
solve the problem without any of this new = upgrade?

Well, this is my 3rd or 4th attempt to = convince you on this topic, so I'll skip this question = :)
%sam - That is fine. Point remains though = :D

Alternatively, for ex: If the reply = was being received with reply mode '5, but
now I don't receive it = now, send a new request with reply mode 1. This is
more simple than = the proposed solution without needing any change.
I'd be open to = hearing the strong reason, this ID is solving, which couldn't = be
solved with RFC4379.

Why would you send reply = mode 1 (Do no reply) if reply mode 5 (Reply via Specified Path) starts = timing out? That sounds a very silly, but maybe I'm missing = something.
typo. Meant to say reply mode = 2. 

Thanks!

-Nobo


cheers
-sam


On Jul 3, 2014, at 3:47 PM, = Aissaoui, Mustapha (Mustapha)
<
mustapha.aissaoui@alc= atel-lucent.com> wrote:


Dear all,
I was asked to = review this draft and I think it describes valid issues to = be
resolved. I however have a couple of comments about the way the = authors
went about to address = them.

1.    Relation to RFC 7110 - Return = Path Specified Label Switched Path (LSP)
Ping.
Section 4.1 argues = the reason why a separate reply mode is needed is for
wanting to omit = the Reply Path TLV defined in RFC 7110 when the sender of
the echo = request just wanted to use the return path of the tested LSP. I = do
not see this as a strong justification. In many cases, the LSP is = unidirectional
or the responder node is a transit LSR and may not be = able to inject the reply
in the reverse direction of that LSP. In = that case, I can see that providing a
specific return LSP which is = different than the tested LSP is required and the
Reply Path TLV is = needed.
Assuming this is still an important issue for the authors, I = would suggest to
relax the rule in RFC 7110 such that if the echo = request includes reply mode
5 "Reply via Specified Path" and the = Reply Path TLV is not included, the
responder node will interpret = this as an implicit request to reply via the
reverse direction of the = tested LSP.

2.    Reply Mode Order TLV
I = am not convinced of the need for this TLV. There is not much reply = modes
which are usable today together. Only reply mode 2 can be = concurrently
used with reply mode 5 in RFC 7110 or reply mode 4. = Reply mode 3 is not
very popular as far as I know. Also, most = applications would reply with
mode 2 if the requested mode is not = available. So, I can't see how this new
TLV will be useful in = practice.

Regards,
Mustapha.
________________________________= _______________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mpls

= = --Apple-Mail=_5BB00B7E-A319-4B70-B905-61E09A7169C7-- From nobody Thu Jul 3 20:34:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E11D1B28BC; Thu, 3 Jul 2014 20:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqEmhYmL0hEc; Thu, 3 Jul 2014 20:33:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB821B2B41; Thu, 3 Jul 2014 20:33:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704033359.25242.62506.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 20:33:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0CjZRD3iyj9Y7rd1naj5wvK-LFQ Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-egress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:34:01 -0000 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 : Extensions to RSVP-TE for LSP Egress Local Protection Authors : Huaimo Chen Zhenbin Li Ning So Autumn Liu Fengman Xu Mehmet Toy Lu Huang Lei Liu Filename : draft-ietf-mpls-rsvp-egress-protection-01.txt Pages : 15 Date : 2014-07-03 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-egress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rsvp-egress-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-egress-protection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 20:38:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7CF1B2B93; Thu, 3 Jul 2014 20:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqcBxq5mpD3S; Thu, 3 Jul 2014 20:38:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EF81B28BC; Thu, 3 Jul 2014 20:38:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704033842.25277.2511.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 20:38:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0uEPFKnAXy_gud9IftEADaquJvI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-ingress-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:38:47 -0000 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 : Extensions to RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-mpls-rsvp-ingress-protection-01.txt Pages : 24 Date : 2014-07-03 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-rsvp-ingress-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-ingress-protection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 22:15:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8525C1B2BDB; Thu, 3 Jul 2014 22:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmAjv0bqZiwb; Thu, 3 Jul 2014 22:15:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631D01B2BA8; Thu, 3 Jul 2014 22:15:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT95787; Fri, 04 Jul 2014 05:15:03 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 06:15:02 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 13:14:56 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , Gregory Mirsky , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAEjfoIAAME/AgAERiwA= Date: Fri, 4 Jul 2014 05:14:56 +0000 Message-ID: References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.28.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/81_DLeC2I3pcxWpqrhamOGounz8 Cc: "rtg-bfd@ietf.org" Subject: [mpls] =?utf-8?b?562U5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-mirsky-mpls-bfd-directed-00=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 05:15:06 -0000 SGkgTm9ibyBhbmQgR3JlZywNCg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu2 5Lq6OiBOb2JvIEFraXlhIChub2JvKSBbbWFpbHRvOm5vYm9AY2lzY28uY29tXQ0KPiDlj5HpgIHm l7bpl7Q6IDIwMTTlubQ35pyIM+aXpSAyMTowOQ0KPiDmlLbku7bkuro6IE1hY2ggQ2hlbjsgR3Jl Z29yeSBNaXJza3k7IG1wbHNAaWV0Zi5vcmcNCj4g5oqE6YCBOiBydGctYmZkQGlldGYub3JnDQo+ IOS4u+mimDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1w bHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiANCj4gSGkgR3JlZywgTWFjaCwNCj4gDQo+ID4gPiBP bmUgd2F5IHRvIGFjaGlldmUgdGhlIHNhbWUgc2VtYXRpYyBpcyB0byBpbnRyb2R1Y2UgIlNlZ21l bnQgUm91dGluZw0KPiA+ID4gTVBMUyBUdW5uZWwgc3ViLVRMViIgYW5kICJTZWdtZW50IFJvdXRp bmcgSVB2NiBUdW5uZWwgc3ViLVRMViIgdW5kZXINCj4gPiA+IFJlcGx5IFBhdGgNCj4gPiA+IChS UCkgVExWIGRlZmluZWQgaW4gUkZDNzExMC4gSXMgdGhlcmUgYW55IHBhcnRpY3VsYXIgcmVhc29u IHdoeSBuZXcNCj4gPiA+IFRMViB3YXMgaW50cm9kdWNlZD8gSSdtIG1haW5seSBqdXN0IGN1cmlv dXMgOikNCj4gPiA+IEdJTT4+IFRob3VnaCBpdCBpcyB1bmxpa2VseSB0aGF0IGJvdGggQkZEIERp c2NyaW1pbmF0b3IgVExWIGFuZCBSUA0KPiA+ID4gR0lNPj4gVExWIHdvdWxkIGJlDQo+ID4gPiB1 c2VkIGluIHRoZSBzYW1lIExTUCBwaW5nLCB3ZSBkaWRuJ3Qgd2FudCB0byBydWxlIHRoaXMgb3V0 IGFuZA0KPiA+ID4gdGhvdWdodCB0aGF0IG92ZXJsb2FkaW5nIFJQIHdpdGggYW5vdGhlciByb2xl LCBjb25kaXRpb25hbCB0bw0KPiA+ID4gcHJlc2VuY2Ugb2YgQkZEIFRMViBtYXkgYm90DQo+ID4N Cj4gPiBJIG1heSBoYXZlIGRpZmZlcmVudCB2aWV3IGhlcmUsIHRoaW5raW5nIGFib3V0IHRoZSBj dXJyZW50IExTUCBQaW5nDQo+ID4gYmFzZWQgYm9vdHN0cmFwcGluZywgdGhlIGVjaG8gcmVxdWVz dCB3aWxsIGNhcnJ5IGJvdGggVGFyZ2V0IHN0YWNrIEZFQw0KPiA+IFRMViBhbmQgQkZEIERpc2Ny aW1pbmF0b3IgVExWLCBUYXJnZXQgc3RhY2sgRkVDIFRMViBpcyB1c2VkIHRvDQo+ID4gaWRlbnRp ZnkgdGhlIExTUCB0byB3aGljaCB0aGF0IHRoZSBCRkQgc2Vzc2lvbiBpcyBib3VuZCwgQkZEDQo+ ID4gRGlzY3JpbWluYXRvciBUTFYgaXMgdXNlZCB0byBpbmRpY2F0ZSB0aGlzIGlzIGEgQkZEIGJv b3RzdHJhcHBpbmcNCj4gPiBpbnN0ZWFkIG9mIGEgbm9ybWFsIExTUCBQaW5nLiBBbmFsb2cgdG8g dGhpcywgaWYgd2Ugd2FudCB0byBzcGVjaWZ5DQo+ID4gdGhlIHJldHVybiBwYXRoIG9mIEJGRCBz ZXNzaW9uLCBzZWVtcyBhZGQgdGhlIFJQIFRMViB0byBpZGVudGlmeSB0aGUNCj4gPiByZXR1cm4g cGF0aCBpcyBuYXR1cmFsIGNob2ljZS4gQW5kIGZvciB0aGUgc2VnbWVudCByb3V0aW5nLCB3ZSBq dXN0IG5lZWQNCj4gZGVmaW5lIG5ldyBzdWItVExWcy4NCj4gDQo+IEkgc2VlIHdoZXJlIHlvdSBh cmUgY29taW5nIGZyb20gTWFjaCwgYnV0IGxldCBjb3VudGVyLWFyZ3VlIGZvciB0aGUgc2FrZSBv Zg0KPiBkaXNjdXNzaW9uIDopDQo+IA0KPiBUYXJnZXQgRkVDIFN0YWNrIFRMViAoVEZTKSBpcyBh IFRMViB0aGF0IGlzIGFsd2F5cyBwcmVzZW50IGluIGFuIE1QTFMgZWNobw0KPiByZXF1ZXN0IG1l c3NhZ2UuDQo+IA0KPiBbU2VjdGlvbiAzLjIgb2YgUkZDNDM3OV0NCj4gICAgQW4gTVBMUyBlY2hv IHJlcXVlc3QgTVVTVCBoYXZlIGEgVGFyZ2V0IEZFQyBTdGFjayB0aGF0IGRlc2NyaWJlcyB0aGUN Cj4gICAgRkVDIFN0YWNrIGJlaW5nIHRlc3RlZC4NCj4gDQo+IFNvIG1vc3Qgb3RoZXIgVExWcyBp biB0aGUgTVBMUyBlY2hvIHJlcXVlc3QgYXNzdW1lcyB0aGF0IFRGUyBpcyBwcmVzZW50IGFuZA0K PiBoYXMgaW5zdHJ1Y3Rpb25zIHRvIGRvIGZvbyBmb3IgdGhlIEZFQyBkZXNjcmliZWQgaW4gdGhl IFRGUywgd2hpY2ggaXMgcGVyZmVjdGx5DQo+IGZpbmUgSU1PLiBTbyBJIHRoaW5rIGl0IGlzIHN0 aWxsIGFyZ3VhYmxlIHRoYXQgaWYgd2Ugd2VyZSB0byBoYXZlIEJGRC1mb28tMSwNCj4gQkZELWZv by0yIGFuZCBCRkQtZm9vLTMgaW5zdHJ1Y3Rpb25zLCB0aGVuIHBlcmhhcHMgaXQgaXMgbW9yZSBi ZW5lZmljaWFsIHRvDQo+IGJ1bmRsZSB0aGVtIGludG8gYSBzaW5nbGUgQkZELWZvby1UTFYsIGFu ZCBtYWtlIGVhY2ggaW50byBzdWItVExWcyAuLi4gaW5zdGVhZA0KPiBvZiBoYXZpbmcgc2VwYXJh dGUgVExWcyBmb3IgMS8yLzMuDQoNClllcywgSSBhZ3JlZSB0aGUgcHJpbmNpcGxlLiBMZXQnIGNv bnRpbnVlIGRpc2N1c3NpbmcgOi0pDQoNCj4gDQo+ID4NCj4gPiA+IHN1Y2ggYSBnb29kIGlkZWEu IEJ1dCB3aGF0IHdlIGRpc2N1c3NlZCB3YXMgaW50cm9kdWN0aW9uIG9mIEJGRA0KPiA+ID4gQ29u dHJvbCBUTFYgdG8gaGF2ZSBvcHRpb25hbCBzdWItVExWOiBCRkQgRGlzY3JpbWluYXRvciBzdWIt VExWLA0KPiA+ID4gUmV0dXJuIFBhdGggc3ViLVRMViwgZXRjLiBJdCBtYXkgYmUgdGhhdCB0aGF0 IHdhcyBub3QgYSBiYWQgaWRlYSBhZnRlciBhbGwuDQo+ID4NCj4gPiBDdXJyZW50bHksIFRhcmdl dCBTdGFjayBGRUMgVExWIGFuZCBSZXBseSBQYXRoIFRMViBzaGFyZSB0aGUgc2FtZSBzdWItVExW cy4NCj4gPiBBdCB0aGUgYmVnaW5uaW5nLCBSZXBseSBQYXRoIFRMViB3YW50cyBpdHMgb3duIHJl Z2lzdHJ5IGFuZCBob3BlIHRvDQo+ID4gYm9ycm93IHNvbWUgc3ViLVRMVnMgZnJvbSB0aGUgVGFy Z2V0IFN0YWNrIEZFQyBUTFYsIGJ1dCBpdCB0dXJuZWQgb3V0DQo+ID4gdG8gYmUgYW4gdW5zdWNj ZXNzZnVsIGNob2ljZSwgYW5kIGl0IHdhcyB2ZXJ5IHBhaW5mdWwgdG8gZGV0ZXJtaW5lIGhvdw0K PiA+IHRvIHByb2Nlc3MgdGhlIHJlZ2lzdHJ5LCB0aGVyZSB3YXMgYSBsb25nIGxvbmcgZGlzY3Vz c2lvbiBhYm91dCB3aGVuIHB1Ymxpc2gNCj4gUkZDNzExMC4NCj4gPg0KPiA+IFNvLCBpZiB5b3Ug aW50cm9kdWNlIHRoZSBuZXcgQkZEIENvbnRyb2wgVExWLCB0aGUgc2FtZSBzaXR1YXRpb24gd2ls bA0KPiA+IG9jY3VyIGFnYWluLCB5b3UgaGF2ZSBtYWtlIGEgZGVjaXNpb24gd2hldGhlciBCRkQg Q29udHJvbCBUTFYgaGFzIGl0cw0KPiA+IG93biByZWdpc3RyeSwgd2hpY2ggc3ViLVRMVnMgY2Fu IGJlIGNhcnJpZWQgaW4gQkZEIENvbnRyb2wgVExWLCBob3cgdG8NCj4gPiBwcm9jZXNzIHRoZSBm dXR1cmUgZGVmaW5lZCBSZXBseSBQYXRoIHN1Yi1UTFZzLCBldGMuDQo+IA0KPiBUaGF0J3MgYSBn b29kIHBvaW50LiBJZiBHcmVnJ3MgUmV2ZXJzZSBQYXRoIFRMViBhbHNvIG5lZWRzIHRvIGRlc2Ny aWJlIEZFQ3MNCj4gb3RoZXIgdGhhbiBTZWdtZW50cywgdGhlbiB3ZSBwcm9iYWJseSB3YW50IHRv IG1ha2Ugc3VyZSB0aGF0IHR5cGUgZG9lcyBub3QNCj4gY29sbGlkZSB3aXRoIEZFQyB0eXBlcyBp biB0aGUgVEZTLg0KDQpFeGFjdGx5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo+IA0KPiA+ID4g Mi4gTWFpbnRlbmFuY2Ugb2YgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucyBpcyBmdXp6eSwgbWVh bmluZyB3aGVuDQo+ID4gPiBzaG91bGQgdGhlIGVncmVzcyBkZWxldGUgYm9vdHN0cmFwcGVkIEJG RCBzZXNzaW9ucy4gT25lIGNvdWxkDQo+ID4gPiBpbXBsZW1lbnQgc3VjaCB0aGF0IHRoZSBlZ3Jl c3MgZGVsZXRlcyBCRkQgc2Vzc2lvbnMgd2hlbg0KPiA+ID4gY29ycmVzcG9uZGluZyBGRUMgaXMg ZGVsZXRlZCwgb3IgWCBhbW91bnQgb2YgdGltZSBhZnRlciBzZXNzaW9ucyBnbw0KPiA+ID4gImRv d24iLiBUaGVyZSdzIG5vIEZFQy9zdGF0ZSBvbiB0aGUgZWdyZXNzIGZvciBTZWdtZW50IFJvdXRp bmcuDQo+ID4gPiBUaHVzIG9ubHkgcmVtYWluaW5nIG9wdGlvbiB0b2RheSBpcyB0byBkZWxldGUg dGhlIHNlc3Npb24gYWZ0ZXIgWA0KPiA+ID4gc2Vjb25kcy9taW51dGVzIG9uY2UgdGhlIHNlc3Np b24gaXMgaW4gImRvd24iIHN0YXRlLiBQZXJoYXBzIHRoaXMNCj4gPiA+IGZ1enppbmVzcyBpcyBy ZWFzb25hYmxlLCBvciBwZXJoYXBzIHdlIHdhbnQgZXhwbGljaXQgImRlbGV0ZSINCj4gPiA+IGlu c3RydWN0aW9uIGZyb20gdGhlIGluZ3Jlc3MgdG8gdGhlDQo+ID4gZWdyZXNzLg0KPiA+ID4gR0lN Pj4gQkZEIChzaG91bGQgd2UgcmVmZXIgdG8gaXQgbm93IGFzICJjbGFzc2ljYWwiIEJGRCkgbXVz dCBiZQ0KPiA+ID4gR0lNPj4gY29uZmlndXJlZA0KPiA+ID4gYmVmb3JlIGl0IGJlIGJvb3RzdHJh cHBlZCBieSBMU1AgcGluZy4gVG8gY2xlYW4gdXAgYW55IHJlc2lkdWFsDQo+ID4gPiBzdGF0ZSBp biB0aGUgZGF0YSBwbGFuZSBvcGVyYXRvciB3b3VsZCBuZWVkIGp1c3QgdG8gcmVtb3ZlDQo+ID4g PiBjb3JyZXNwb25kaW5nIEJGRCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIFMtQkZEIHdvdWxkIGJl IGRpZmZlcmVudA0KPiA+ID4gY2FzZS4gVGhlIGZhci1lbmQgQkZEIHBlZXIgaXMsIGluIGEgd2F5 LCBzdGF0ZWxlc3MgYnV0IGlmIHdhcw0KPiA+ID4gaW5zdHJ1Y3RlZCB0byB1c2Ugc3BlY2lmaWMg cGF0aCB2aWEgQkZEIFJldmVyc2UgUGF0aCBUTFYsIHRoZW4gdGhhdA0KPiA+ID4gd2lsbCBjcmVh dGUgYSBzdGF0ZSBpbiB0aGUgZGF0YSBwbGFuZS4gQ2xlYW5pbmcgaXQgdXAgbWF5IGJlDQo+ID4g PiByZXF1aXJlZCB0byBwcmV2ZW50IGV4aGF1c3Rpb24gb2YgYSByZXNvdXJjZSBpbiB0aGUgZGF0 YSBwbGFuZS4gQ2VydGFpbmx5DQo+IGdyZWF0IHRvcGljIGZvciBkaXNjdXNzaW9uIGluIFRvcm9u dG8uDQo+IA0KPiBbQ2xhc3NpY2FsIEJGRF0NCj4gV2VsbCwgeWVzIGNsYXNzaWNhbCBCRkQgc2Vz c2lvbnMgYXJlIGNvbmZpZ3VyZWQgb24gdGhlIGluZ3Jlc3MsIGJ1dCBub3QgZXhwbGljaXRseQ0K PiBjb25maWd1cmVkIG9uIHRoZSBlZ3Jlc3MsIGhlbmNlIHRoZSBuZWVkIGZvciBib290c3RyYXBw aW5nLiBMaWtlbHksIGVncmVzcyB3aWxsDQo+IGhhdmUgY29uZmlndXJhdGlvbiBsaWtlICJhbGxv dyBCRkQgYm9vc3RyYXAgcmVxdWVzdCBmcm9tIHRoZXNlIG5vZGVzIiBidXQgbm90DQo+ICJhbGxv dyBCRkQgYm9vdHN0cmFwIHJlcXVlc3QgZm9yIHRoZXNlIEZFQ3MgZnJvbSB0aGVzZSBub2RlcyIs IGJlY2F1c2UgdGhlDQo+IGxhdHRlciB3aWxsIGJlIHZlcnkgZGlmZmljdWx0IHRvIG1haW50YWlu IG5vdCB0byBtZW50aW9uIGl0IGdvZXMgYWdhaW5zdCB0aGUNCj4gc3RhdGVsZXNzIG5hdHVyZSBv ZiBTZWdtZW50IFJvdXRpbmcgYXQgdGhlIGNvbmZpZ3VyYXRpb24gbGV2ZWwuIFBvc3NpYmx5Og0K PiBhLiBCRkQgVExWIGNhbiBpbnN0cnVjdCBlZ3Jlc3MgdG8gZGVsZXRlIHRoZSBzZXNzaW9uLg0K PiBiLiBCRkQgVExWIGhhcyAicHVyZ2UgdGltZXIiIGZpZWxkIHdoZXJlIGVncmVzcyBpcyBleHBl Y3RlZCB0byBkZWxldGUgdGhlDQo+IHNlc3Npb24gYWZ0ZXIgInB1cmdlIHRpbWVyIiBvbmNlIHRo ZSBzZXNzaW9uIGdvZXMgZG93bi4NCj4gYy4gSnVzdCBkZXNjcmliZSBwcm9jZWR1cmVzIGZvciBl Z3Jlc3MgdGhhdCBpdCBjYW4gZGVsZXRlIHRoZSBzZXNzaW9uIGFmdGVyDQo+IHNvbWV0aW1lIG9u Y2UgdGhlIHNlc3Npb24gZ29lcyBkb3duLg0KPiANCj4gW1MtQkZEXQ0KPiBBZ3JlZSwgSSBkb24n dCBzZWUgaG93IHdlIGNhbiBhZGRyZXNzIHRoaXMgd2l0aG91dCBlZ3Jlc3MgYmVjb21pbmcgYSBs aXR0bGUNCj4gc3RhdGVmdWwuIEF0IHRoZSBsZWFzdCwgYW4gU0JGRFJlZmxlY3RvciBuZWVkcyB0 byBrZWVwIFtyZW1vdGUgSVAgYWRkcmVzcywNCj4gcmVtb3RlIEJGRCBkaXNjcmltaW5hdG9yXSA9 IHJldHVybiBwYXRoLiBBbmQgaW5ncmVzcyBuZWVkcyB0byBiZSBhYmxlIHRvDQo+IG1haW50YWlu IHRoaXMuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiAtTm9ibw0KDQo= From nobody Fri Jul 4 06:28:40 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5291B2CE9; Fri, 4 Jul 2014 06:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFrDfaTEvprY; Fri, 4 Jul 2014 06:28:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DA91B2CA3; Fri, 4 Jul 2014 06:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10412; q=dns/txt; s=iport; t=1404480516; x=1405690116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZCc+02sgpype8WtQV8SmIGDTA6JOrXzzvsMsDf9ek3c=; b=B7TY8ZQTy4Z751VJ1CiGDBTMMLbaIMgcMNXTacLpCY57Zrz3nlp84qJd 1F8sA4zb0joz4lALcIdav8InJO10tMnfta7qu5APjTJJ+8DpVwZUDguF5 xQxpyZW7Nvf8nTfX7pXBtOj6eXxd/tXS7tLpGrRsp8a9kkx+ehLFkIew8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHertlOtJA2D/2dsb2JhbABagw5SWoJvwzoBGXEWdYQDAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQBDQUIARKIJw2vD5shF4EsiDmFDBYbBwaCcTaBFgWWXIVikkSDQ2yBRA X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="337583825" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jul 2014 13:28:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s64DSZiB005605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 13:28:35 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 08:28:35 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Gregory Mirsky , "Nobo Akiya (nobo)" , Mach Chen , "mpls@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt Thread-Index: AQHPlLkmcHLo4kmCjEWzfUskF7x6bpuLglYggAB+rECAAQbgIIAAZ8ZggABmrLCAAheN8A== Date: Fri, 4 Jul 2014 13:28:34 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D34623DD1@xmb-rcd-x15.cisco.com> References: <20140630231508.5203.4775.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B7E50F6@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E5B9B@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E61F9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XS_nTt4e2YofB75qpJfs0SPskJk Cc: "rtg-bfd@ietf.org" Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-directed-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 13:28:38 -0000 SGVsbG8gYWxsLCANCiBQbGVhc2UgZmluZCB0aGUgc3VibWlzc2lvbiBOb2JvIHJlZmVycyB0byBi ZWxvdyBhdDoNCg0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12 Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYvDQpIdG1saXplZDogICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZk LWRpc2MtdGx2LTAwDQoNClRoYW5rcw0KUHJhc2FkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgR3JlZ29yeSBNaXJza3kNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDAzLCAyMDE0IDEx OjIwIEFNDQpUbzogTm9ibyBBa2l5YSAobm9ibyk7IE1hY2ggQ2hlbjsgbXBsc0BpZXRmLm9yZw0K Q2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMC50eHQNCg0KSGkgTm9ibywN Cm1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgdGhvdWdodGZ1bCBjb21tZW50cy4gUGxl YXNlIGZpbmQgbXkgYW5zd2VycyBhbmQgbm90ZXMgaW4tbGluZWQgYW5kIHRhZ2dlZCB3aXRoIEdJ TT4+Lg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTm9ibyBBa2l5YSAobm9ibykgW21haWx0bzpub2JvQGNpc2NvLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSnVseSAwMiwgMjAxNCA1OjE1IFBNDQpUbzogR3JlZ29yeSBNaXJza3k7IE1hY2gg Q2hlbjsgbXBsc0BpZXRmLm9yZw0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0wMC50eHQNCg0KSGkgR3JlZywgZXQgYWwsDQoNCkkgYWdyZWUgd2l0aCB0aGUgdG9waWMgYW5k IHVzZWZ1bG5lc3Mgb2YgY29udHJvbGxpbmcgdGhlIEJGRCByZXR1cm4gcGF0aCwgZXNwZWNpYWxs eSBpbiBTZWdtZW50IFJvdXRpbmcuDQoNCkEgcXVlc3Rpb24gYW5kIGNvdXBsZSBjb21tZW50cy4N Cg0KT25lIHdheSB0byBhY2hpZXZlIHRoZSBzYW1lIHNlbWF0aWMgaXMgdG8gaW50cm9kdWNlICJT ZWdtZW50IFJvdXRpbmcgTVBMUyBUdW5uZWwgc3ViLVRMViIgYW5kICJTZWdtZW50IFJvdXRpbmcg SVB2NiBUdW5uZWwgc3ViLVRMViIgdW5kZXIgUmVwbHkgUGF0aCAoUlApIFRMViBkZWZpbmVkIGlu IFJGQzcxMTAuIElzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgbmV3IFRMViB3YXMg aW50cm9kdWNlZD8gSSdtIG1haW5seSBqdXN0IGN1cmlvdXMgOikNCkdJTT4+IFRob3VnaCBpdCBp cyB1bmxpa2VseSB0aGF0IGJvdGggQkZEIERpc2NyaW1pbmF0b3IgVExWIGFuZCBSUCBUTFYgd291 bGQgYmUgdXNlZCBpbiB0aGUgc2FtZSBMU1AgcGluZywgd2UgZGlkbid0IHdhbnQgdG8gcnVsZSB0 aGlzIG91dCBhbmQgdGhvdWdodCB0aGF0IG92ZXJsb2FkaW5nIFJQIHdpdGggYW5vdGhlciByb2xl LCBjb25kaXRpb25hbCB0byBwcmVzZW5jZSBvZiBCRkQgVExWIG1heSBib3Qgc3VjaCBhIGdvb2Qg aWRlYS4gQnV0IHdoYXQgd2UgZGlzY3Vzc2VkIHdhcyBpbnRyb2R1Y3Rpb24gb2YgQkZEIENvbnRy b2wgVExWIHRvIGhhdmUgb3B0aW9uYWwgc3ViLVRMVjogQkZEIERpc2NyaW1pbmF0b3Igc3ViLVRM ViwgUmV0dXJuIFBhdGggc3ViLVRMViwgZXRjLiBJdCBtYXkgYmUgdGhhdCB0aGF0IHdhcyBub3Qg YSBiYWQgaWRlYSBhZnRlciBhbGwuDQoNClRoZXJlIGFyZSBjb3VwbGUgb2YgdGhpbmdzIHdvcnRo IGhpZ2hsaWdodGluZyBhYm91dCB0aGUgQkZEIERpc2NyaW1pbmF0b3IgVExWIChkZWZpbmVkIGlu IFJGQzU4ODQpLCBub3QgZGlyZWN0bHkgaW4gdGhlIHNjb3BlIG9mIHlvdXIgZG9jdW1lbnQgYnV0 IHZlcnkgcmVsZXZhbnQgd2hlbiBsb29raW5nIGF0IHVzaW5nIHlvdXIgcHJvcG9zYWwgaW4gU2Vn bWVudCBSb3V0aW5nLg0KDQoxLiBUaGUgQkZEIERpc2NyaW1pbmF0b3IgVExWIGFsbG93cyBib290 c3RyYXBwaW5nIG9mIG9uZSBCRkQgc2Vzc2lvbiBwZXIgRkVDLiBXaGVuIGJvb3RzdHJhcHBpbmcg bW9yZSB0aGFuIG9uZSBCRkQgc2Vzc2lvbiBwZXIgRkVDLCBpdCBpcyBkaWZmaWN1bHQgdG8gZG8g c28gd2l0aG91dCBtYWtpbmcgYXNzdW1wdGlvbnMsIGFzIHRoZXJlIGlzIG5vIGRlZmluZWQgZmll bGRzL3Byb2NlZHVyZXMgdG8gZG8gc28uIFRoaXMgd2lsbCBiZWNvbWUgbW9yZSBvZiBhbiBpc3N1 ZSB3aXRoIFNlZ21lbnQgUm91dGluZywgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgZXhwbGljaXQg cGF0aHMgY3JlYXRlZCBiZXR3ZWVuIGEgcGFpciBvZiBub2Rlcy4NCg0KMi4gTWFpbnRlbmFuY2Ug b2YgYm9vdHN0cmFwcGVkIEJGRCBzZXNzaW9ucyBpcyBmdXp6eSwgbWVhbmluZyB3aGVuIHNob3Vs ZCB0aGUgZWdyZXNzIGRlbGV0ZSBib290c3RyYXBwZWQgQkZEIHNlc3Npb25zLiBPbmUgY291bGQg aW1wbGVtZW50IHN1Y2ggdGhhdCB0aGUgZWdyZXNzIGRlbGV0ZXMgQkZEIHNlc3Npb25zIHdoZW4g Y29ycmVzcG9uZGluZyBGRUMgaXMgZGVsZXRlZCwgb3IgWCBhbW91bnQgb2YgdGltZSBhZnRlciBz ZXNzaW9ucyBnbyAiZG93biIuIFRoZXJlJ3Mgbm8gRkVDL3N0YXRlIG9uIHRoZSBlZ3Jlc3MgZm9y IFNlZ21lbnQgUm91dGluZy4gIFRodXMgb25seSByZW1haW5pbmcgb3B0aW9uIHRvZGF5IGlzIHRv IGRlbGV0ZSB0aGUgc2Vzc2lvbiBhZnRlciBYIHNlY29uZHMvbWludXRlcyBvbmNlIHRoZSBzZXNz aW9uIGlzIGluICJkb3duIiBzdGF0ZS4gUGVyaGFwcyB0aGlzIGZ1enppbmVzcyBpcyByZWFzb25h YmxlLCBvciBwZXJoYXBzIHdlIHdhbnQgZXhwbGljaXQgImRlbGV0ZSIgaW5zdHJ1Y3Rpb24gZnJv bSB0aGUgaW5ncmVzcyB0byB0aGUgZWdyZXNzLg0KR0lNPj4gQkZEIChzaG91bGQgd2UgcmVmZXIg dG8gaXQgbm93IGFzICJjbGFzc2ljYWwiIEJGRCkgbXVzdCBiZSBjb25maWd1cmVkIGJlZm9yZSBp dCBiZSBib290c3RyYXBwZWQgYnkgTFNQIHBpbmcuIFRvIGNsZWFuIHVwIGFueSByZXNpZHVhbCBz dGF0ZSBpbiB0aGUgZGF0YSBwbGFuZSBvcGVyYXRvciB3b3VsZCBuZWVkIGp1c3QgdG8gcmVtb3Zl IGNvcnJlc3BvbmRpbmcgIEJGRCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uIFMtQkZEIHdvdWxkIGJl IGRpZmZlcmVudCBjYXNlLiBUaGUgZmFyLWVuZCBCRkQgcGVlciBpcywgaW4gYSB3YXksIHN0YXRl bGVzcyBidXQgaWYgd2FzIGluc3RydWN0ZWQgdG8gdXNlIHNwZWNpZmljIHBhdGggdmlhIEJGRCBS ZXZlcnNlIFBhdGggVExWLCB0aGVuIHRoYXQgd2lsbCBjcmVhdGUgYSBzdGF0ZSBpbiB0aGUgZGF0 YSBwbGFuZS4gQ2xlYW5pbmcgaXQgdXAgbWF5IGJlIHJlcXVpcmVkIHRvIHByZXZlbnQgZXhoYXVz dGlvbiBvZiBhIHJlc291cmNlIGluIHRoZSBkYXRhIHBsYW5lLiBDZXJ0YWlubHkgZ3JlYXQgdG9w aWMgZm9yIGRpc2N1c3Npb24gaW4gVG9yb250by4gDQoNCkkgYmVsaWV2ZSBteSBjb2xsZWFndWUg aXMgYWJvdXQgdG8gcm9sbCBvdXQgYSBkb2N1bWVudCBmb3IgRXh0ZW5kZWQgQkZEIERpc2NyaW1p bmF0b3IgVExWIHdoaWNoIGFkZHJlc3NlcyAoMSkgYW5kICgyKSBhYm92ZS4gUHJpbWFyeSBtb3Rp dmF0aW9uIG9mIHRoYXQgZG9jdW1lbnQgaXMgRVZQTiBCRkQsIGJ1dCBpdCBsb29rcyB2ZXJ5IGFw cGxpY2FibGUgdG8gU2VnbWVudCBSb3V0aW5nIGFzIHdlbGwuDQpHSU0+PiBWZXJ5IGludGVyZXN0 aW5nIGluZGVlZC4gTG9va2luZyBmb3J3YXJkIHRvIHJlYWQgdGhlIHByb3Bvc2FsLg0KDQpMYXN0 bHksIGhvdyBkbyB3ZSB1c2UgdGhpcyBmb3IgUy1CRkQ/IDopDQoNCkxldCdzIGRpc2N1c3MgaW4g VG9yb250byBvbiBob3cgd2UgY2FuIGJlc3QgZGVmaW5lIHRoZSBtb3N0IHVzZWZ1bCBzb2x1dGlv bi4NCkdJTT4+IFRoYW5rIHlvdSENCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5IA0KPiBNaXJza3kNCj4gU2VudDogV2VkbmVz ZGF5LCBKdWx5IDAyLCAyMDE0IDE6MTUgUE0NCj4gVG86IE1hY2ggQ2hlbjsgbXBsc0BpZXRmLm9y Zw0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtIDAwLnR4dA0K PiANCj4gSGkgTWFjaCwNCj4gdGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrLg0KPiBJbmRlZWQs IGJvdGggZHJhZnRzIGhhdmUgY29tbW9uYWxpdGllcy4NCj4gSSdtIGxvb2tpbmcgZm9yd2FyZCB0 byB0aGUgZGlzY3Vzc2lvbiBpbiBUb3JvbnRvIGFuZCBob3cgd2UgY2FuIGJyaW5nIA0KPiB0aGlz IGlkZWEgZnVydGhlci4NCj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hY2ggQ2hlbiBbbWFpbHRvOm1hY2guY2hlbkBo dWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDY6NTcgUE0NCj4gVG86 IEdyZWdvcnkgTWlyc2t5DQo+IENjOiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJl Y3RlZC0gMDAudHh0DQo+IA0KPiBIaSBHcmVnLA0KPiANCj4gSSBoYXZlIGEgcXVpY2sgcmV2aWV3 IG9uIHRoZSBkcmFmdCwgd2VsbCB3cml0dGVuIGFuZCB1c2VmdWwgZHJhZnQhDQo+IA0KPiBDb3Vw bGUgeWVhcnMgYWdvLCB3ZSBzdWJtaXR0ZWQgYSBkcmFmdA0KPiAoaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtDQo+IGNoZW4tbXBscy1iZmQtZW5oYW5jZW1lbnQtMDEpIHRoYXQgaW50 ZW5kIHRvIHNvbHZlIHRoZSBzaW1pbGFyIGlzc3VlLCANCj4gZ2xhZCB3ZSBoYXZlIHRoZSBzaW1p bGFyIHRob3VnaHQ6LSkuDQo+IA0KPiBJdCBhbHNvIGRlZmluZXMgZXh0ZW5zaW9ucyB0byBMU1Ag UGluZyB0byBkaXJlY3QgdGhlIGNob29zZSBvZiB0aGUgDQo+IHJldHVybiBwYXRoIG9mIEJGRCBj b250cm9sIHBhY2tldHMuIFBsZWFzZSB0YWtlIGEgbG9vay4NCj4gDQo+IEJlc3QgcmVnYXJkcywN Cj4gTWFjaA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJ0 Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVn b3J5IA0KPiA+IE1pcnNreQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCAyOjE5 IEFNDQo+ID4gVG86IG1wbHNAaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0 OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gPiBkcmFmdC1taXJza3ktbXBs cy1iZmQtZGlyZWN0ZWQtMDAudHh0DQo+ID4NCj4gPiBEZWFyIEFsbCwNCj4gPiB3ZSd2ZSBwb3N0 ZWQgYSBuZXcgZHJhZnQuIExTUCBQaW5nIGFscmVhZHkgaXMgdXNlZCB0byBib290c3RyYXAgYSAN Cj4gPiBCRkQgc2Vzc2lvbiB3aXRoIEJGRCBEaXNjcmltaW5hdG9yIFRMVi4gQSBuZXcgQkZEIFJl dmVyc2UgUGF0aCBUTFYgDQo+ID4gaXMgaW50cm9kdWNlZCBpbiBvcmRlciB0byBpbnN0cnVjdCBh IGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIA0KPiA+IHBhcnRpY3VsYXIgcGF0aCBmb3IgcmV2ZXJz ZSBkaXJlY3Rpb24gb2YgdGhlIEJGRCBzZXNzaW9uLg0KPiA+DQo+ID4gR3JlYXRseSBhcHByZWNp YXRlIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cy4NCj4gPg0KPiA+IAlSZWdhcmRzLA0KPiA+IAkJ R3JlZw0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ ID4gU2VudDogTW9uZGF5LCBKdW5lIDMwLCAyMDE0IDQ6MTUgUE0NCj4gPiBUbzogR3JlZ29yeSBN aXJza3k7IElseWEgVmFybGFzaGtpbjsgSmVmZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJza3k7IA0K PiA+IEplZmYgVGFudHN1cmE7IElseWEgVmFybGFzaGtpbg0KPiA+IFN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+ID4gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVk LTAwLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgDQo+ID4gSUVURiByZXBvc2l0 b3J5Lg0KPiA+DQo+ID4gTmFtZToJCWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KPiA+ IFJldmlzaW9uOgkwMA0KPiA+IFRpdGxlOgkJQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVj dGlvbiAoQkZEKSBEaXJlY3RlZCBSZXR1cm4NCj4gUGF0aA0KPiA+IERvY3VtZW50IGRhdGU6CTIw MTQtMDYtMzANCj4gPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOgkJ OA0KPiA+IFVSTDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDAuDQo+ID4gdHh0DQo+ID4gU3RhdHVzOg0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1k aXJlY3RlZC8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAwDQo+ID4NCj4gPg0KPiA+IEFic3RyYWN0 Og0KPiA+ICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgZXhw ZWN0ZWQgdG8gbW9uaXRvciBiaS0NCj4gPiAgICBkaXJlY3Rpb25hbCBwYXRocy4gIFdoZW4gZm9y d2FyZCBkaXJlY3Rpb24gb2YgYSBCRkQgc2Vzc2lvbiBpcyB0bw0KPiA+ICAgIG1vbml0b3IgZXhw bGljaXRseSByb3V0ZWQgcGF0aCB0aGVyZSBpc1wgYSBuZWVkIHRvIGJlIGFibGUgdG8gZGlyZWN0 DQo+ID4gICAgZmFyLWVuZCBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyByZXZlcnNl IGRpcmVjdGlvbiBvZiB0aGUgQkZEDQo+ID4gICAgc2Vzc2lvbi4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIA0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Jul 4 07:10:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6CD1B29A1; Fri, 4 Jul 2014 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2tq2u_724-K; Fri, 4 Jul 2014 07:09:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7A81B2971; Fri, 4 Jul 2014 07:09:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704140959.2946.45830.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 07:09:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/swzhDnVZW6p1T8OKathMd8z3H0g Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:10:01 -0000 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 : Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Network using Entropy Labels (EL) Authors : Nobo Akiya George Swallow Carlos Pignataro Andrew G. Malis Sam Aldrin Filename : draft-akiya-mpls-entropy-lsp-ping-02.txt Pages : 22 Date : 2014-07-04 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute are used to exercise specific paths of Equal-Cost Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) described in RFC6790, the ability for LSP Ping and Traceroute operation to discover and exercise ECMP paths has been lost in scenarios which LSRs apply deviating load balance techniques. One such scenario is when some LSRs apply EL based load balancing while other LSRs apply non-EL based load balancing (ex: IP). Another scenario is when EL based LSP is stitched with another LSP which can be EL based or non-EL based. This document extends the MPLS LSP Ping and Traceroute mechanisms to restore the ability of exercising specific paths of ECMP over LSP which make use of Entropy Label. This document updates RFC4379, RFC6424 and RFC6790. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-akiya-mpls-entropy-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-akiya-mpls-entropy-lsp-ping-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 07:18:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75A1B29B1 for ; Fri, 4 Jul 2014 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTH1LGXaZGjq for ; Fri, 4 Jul 2014 07:18:52 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257CE1B2850 for ; Fri, 4 Jul 2014 07:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3212; q=dns/txt; s=iport; t=1404483532; x=1405693132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MaCYjwQpHw7laedqmcEsRAZWdV0dk6g6Ogz+8xndv+U=; b=fFVs2q1f0G3BOd9larS8ga80/jhs6mDWY3yW0LiwyhoukOHnxRH8QDBD ISxoT+Z//8Qoorga+VuJeFNfIQhs/PQ4RCLNqK0U0fttGk+MGKlGmGpZ4 vXQaluXog9Fz2NQYRSibcG8+9ih9NFhHgEkjdaMZ4hGTcogJluGac5SNc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMKAPG2tlOtJA2M/2dsb2JhbABagmokUlMHvmqHPwGBChZ1hAMBAQEEAQEBCywrCQsMBAIBCBEEAQELFAkHJwsUCQgCBA4FCAGIOQEHBcpBF45xMQcGgyeBFgWcPpJEg0OCMA X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58357897" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 04 Jul 2014 14:18:51 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s64EIos0001945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 14:18:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 09:18:50 -0500 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-02.txt Thread-Index: AQHPl5GuUEDzIzlKNE+FaV9fjbKA+JuP9lnQ Date: Fri, 4 Jul 2014 14:18:49 +0000 Message-ID: References: <20140704140959.2946.45830.idtracker@ietfa.amsl.com> In-Reply-To: <20140704140959.2946.45830.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Cam01EP_1JmXgq2oms5Oo1jNc5k Cc: "Nagendra Kumar Nainar \(naikumar\)" Subject: Re: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:18:54 -0000 Many thanks to Daniel King and Sriganesh Kini for reviewing and providing c= omments. Special thanks for Curtis Villamizar for providing number of valuable comme= nts and discussing many points patiently. Dear MPLS WG, We have incorporated comments provided, and published a revision. We will be asking the Shepherd to take this document through the WG adoptio= n process shortly. Thoughts, comments and questions are most welcome! Thanks! -Nobo, on behalf of authors > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, July 04, 2014 10:10 AM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-akiya-mpls-entropy-lsp-ping-02.txt >=20 >=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 > Title : Label Switched Path (LSP) and Pseudowire (PW) P= ing/Trace > over MPLS Network using Entropy Labels (EL) > Authors : Nobo Akiya > George Swallow > Carlos Pignataro > Andrew G. Malis > Sam Aldrin > Filename : draft-akiya-mpls-entropy-lsp-ping-02.txt > Pages : 22 > Date : 2014-07-04 >=20 > Abstract: > The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) > Ping and Traceroute are used to exercise specific paths of Equal-Cost > Multipath (ECMP). When LSP is signaled to use Entropy Label (EL) > described in RFC6790, the ability for LSP Ping and Traceroute > operation to discover and exercise ECMP paths has been lost in > scenarios which LSRs apply deviating load balance techniques. One > such scenario is when some LSRs apply EL based load balancing while > other LSRs apply non-EL based load balancing (ex: IP). Another > scenario is when EL based LSP is stitched with another LSP which can > be EL based or non-EL based. >=20 > This document extends the MPLS LSP Ping and Traceroute mechanisms to > restore the ability of exercising specific paths of ECMP over LSP > which make use of Entropy Label. This document updates RFC4379, > RFC6424 and RFC6790. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-mpls-entropy-lsp-ping/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-mpls-entropy-lsp-ping-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-mpls-entropy-lsp-ping-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Jul 4 09:40:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3C21A0B0A for ; Fri, 4 Jul 2014 09:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyMecVKeqUkU for ; Fri, 4 Jul 2014 09:39:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AA81A0342 for ; Fri, 4 Jul 2014 09:39:57 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s64GdsK7025412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jul 2014 11:39:54 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s64GdrRf015749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 12:39:53 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.233]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 4 Jul 2014 12:39:53 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "Nobo Akiya (nobo)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAArCcJUAAhdPpQ Date: Fri, 4 Jul 2014 16:39:52 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D946C8F07@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/d4iRUP_EBF5_eAcKB_YSuYjdzi4 Cc: "Jeffrey \(Zhaohui\) Zhang" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:39:59 -0000 Hi Nobo, Regarding the combinations of reply modes, my point is that usually type 2 = is treated as the default mode which the responder node will usually attemp= t if say type 4 or type 5 were requested in the echo request message but we= re not available. What would be a use case where you want to prefer type 2 = over types 4 or 5? I would have thought the latter being very specific retu= rn paths, the user would first try them and in case they are not available = then resort to type 2. Not the other way around. Also, do you have a use case for requesting types 4 and 5 together for the = same target FEC stack? I would have thought these not to be compatible. For= example, type 4 could be the return path of the tested PW but the responde= r node would not normally use type 5 and send the reply to the VCC ping usi= ng some other LSP. Mustapha. > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Thursday, July 03, 2014 8:56 PM > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Ross Callon; Jeffrey > (Zhaohui) Zhang; jeremy.whittaker@verizon.com > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simpl= e-02 >=20 > Hello Mustapha, >=20 > Thank you for reviewing this document! >=20 > Let me provide my individual reply (not speaking for all the authors). >=20 > > -----Original Message----- > > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > > lucent.com] > > Sent: Thursday, July 03, 2014 6:48 PM > > To: mpls@ietf.org > > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Aissaoui, Mustapha > > (Mustapha); Ross Callon; Jeffrey (Zhaohui) Zhang; > > jeremy.whittaker@verizon.com > > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > > simple-02 > > > > Dear all, > > I was asked to review this draft and I think it describes valid issues > > to be resolved. I however have a couple of comments about the way the > > authors went about to address them. > > > > 1. Relation to RFC 7110 - Return Path Specified Label Switched Path > > (LSP) Ping. > > Section 4.1 argues the reason why a separate reply mode is needed is > > for wanting to omit the Reply Path TLV defined in RFC 7110 when the > > sender of the echo request just wanted to use the return path of the > > tested LSP. I do not see this as a strong justification. In many > > cases, the LSP is unidirectional or the responder node is a transit > > LSR and may not be able to inject the reply in the reverse direction > > of that LSP. In that case, I can see that providing a specific return > > LSP which is different than the tested LSP is required and the Reply Pa= th TLV is > needed. > > > > Assuming this is still an important issue for the authors, I would > > suggest to relax the rule in RFC 7110 such that if the echo request > > includes reply mode > > 5 "Reply via Specified Path" and the Reply Path TLV is not included, > > the responder node will interpret this as an implicit request to reply > > via the reverse direction of the tested LSP. >=20 > If that's more desired by the WG, I have no objection to that as long as = it doesn't > require a TLV to indicate reverse LSP :) >=20 > > > > 2. Reply Mode Order TLV > > I am not convinced of the need for this TLV. There is not much reply > > modes which are usable today together. Only reply mode 2 can be > > concurrently used with reply mode 5 in RFC 7110 or reply mode 4. Reply > > mode 3 is not very popular as far as I know. Also, most applications > > would reply with mode 2 if the requested mode is not available. So, I > > can't see how this new TLV will be useful in practice. >=20 > You are absolutely correct, not all combinations of the reply modes in th= e Reply > Mode TLV is realistic. >=20 > Value Meaning > ----- ------- > 1 Do not reply > 2 Reply via an IPv4/IPv6 UDP packet > 3 Reply via an IPv4/IPv6 UDP packet with Router Alert > 4 Reply via application level control channel > 5 Reply via Specified Path > 6 Reply via reverse LSP >=20 > Ping is simple, but let's talk about traceroute. >=20 > I can imagine following example usage: >=20 > (1) User prefers IP return path: >=20 > If (LSP_w_reverse_LSP) { > ReplyModeTLV{2, 6} > } else if (LSP_w_control_channel) { > ReplyModeTLV{2, 4} > } else { > ReplyMode{2} > } >=20 > (2) User does not prefer IP return path: >=20 > If (LSP_w_reverse_LSP) { > ReplyModeTLV{6, 2} > } else if (LSP_w_control_channel) { > ReplyModeTLV{4, 2} > } else { > ReplyMode{2} > } >=20 > Or user can specify a preference to be used for all LSP types (those who = wants to > make sure response is received back one way or another). >=20 > (3) User prefers IP return path: >=20 > If (all_LSP_types) { > ReplyModeTLV{2, 6, 4} > } else { > ReplyMode{2} > } >=20 > (4) User does not prefer IP return path: >=20 > If (all_LSP_types) { > ReplyModeTLV{4, 6, 2} > } else { > ReplyMode{2} > } >=20 > I hope this answers your comments/concerns a bit :) >=20 > Thanks! >=20 > -Nobo >=20 > > > > Regards, > > Mustapha. From nobody Fri Jul 4 10:21:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BA51B2B22 for ; Fri, 4 Jul 2014 10:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZWxV6-j8Ig8 for ; Fri, 4 Jul 2014 10:21:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B811B2B11 for ; Fri, 4 Jul 2014 10:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7099; q=dns/txt; s=iport; t=1404494488; x=1405704088; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FFyMTqRNFvR91Y7ih+2GH5ulcZJLwGoHu4FI2tIn1VE=; b=bJNpkQWbWA5+WCOeH5eCEj19NNHz8H4Sm2mKIgRkwVp6kYsFLG6PEYNw jE9LQbdoQ/0ZjsXHv0H5y+0x+yluK1gPDAg2a3nGnPuP4lBJmU77JLuGo Ik3C5bQRmCuRDbDaTQAkaPr5/mTDxdOiLOOHbrN5SCAzYUUNPTphlgiyD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJbhtlOtJV2a/2dsb2JhbABagmokUlrGKwGBCxZ1hAMBAQEDATo4BwUHBAIBCBEEAQELFAkHMhQJCAEBBAENBQiIJgMJCAHKWheMeoF3MQcGgyeBFgEEllyFYpJEg0OBbgc7 X-IronPort-AV: E=Sophos;i="5.01,602,1400025600"; d="scan'208";a="337782644" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 04 Jul 2014 17:21:27 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s64HLR0S011301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 17:21:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 12:21:26 -0500 From: "Nobo Akiya (nobo)" To: "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAArCcJUAAhdPpQAAG2acA= Date: Fri, 4 Jul 2014 17:21:26 +0000 Message-ID: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C8F07@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D946C8F07@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QWdJ00dLkmDVqjzwMAQUnle1inU Cc: "Jeffrey \(Zhaohui\) Zhang" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 17:21:30 -0000 Hi Mustapha, > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Friday, July 04, 2014 12:40 PM > To: Nobo Akiya (nobo); mpls@ietf.org > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Ross Callon; Jeffrey > (Zhaohui) Zhang; jeremy.whittaker@verizon.com > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > simple-02 >=20 > Hi Nobo, > Regarding the combinations of reply modes, my point is that usually type = 2 > is treated as the default mode which the responder node will usually > attempt if say type 4 or type 5 were requested in the echo request messag= e > but were not available. LSP ping/trace is design such that behavior is strictly controlled by the i= nitiator. I'd say any behavior which the responder does not comply to the i= nstruction in received MPLS echo request and starts to decide its own behav= ior on reply contents or how to reply is a bad idea. > What would be a use case where you want to prefer > type 2 over types 4 or 5? > I would have thought the latter being very specific > return paths, the user would first try them and in case they are not avai= lable > then resort to type 2. Not the other way around. Ask operators :) There are some operators who prefer (2 > (4 or 5)) and there are some opera= tors who prefer ((4 or 5) > 2). This is exactly one of the items which lead the authors to coming up with t= his document. >=20 > Also, do you have a use case for requesting types 4 and 5 together for th= e > same target FEC stack? I would have thought these not to be compatible. F= or > example, type 4 could be the return path of the tested PW but the > responder node would not normally use type 5 and send the reply to the > VCC ping using some other LSP. Correct. Whether 4 or 5 can be used is LSP dependant, meaning the tool or u= ser have to know that. For those users who are only concerned about ping/tr= ace succeeding in the forward path, users can configure (5, 4, 2) (or whate= ver) and tools can default to that for all LSP types, ping or trace or ping= w/ specific TTL. Thanks! -Nobo >=20 > Mustapha. >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Thursday, July 03, 2014 8:56 PM > > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > > chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Ross Callon; > > Jeffrey > > (Zhaohui) Zhang; jeremy.whittaker@verizon.com > > Subject: RE: MPLS-RT review of > > draft-akiya-mpls-lsp-ping-reply-mode-simple-02 > > > > Hello Mustapha, > > > > Thank you for reviewing this document! > > > > Let me provide my individual reply (not speaking for all the authors). > > > > > -----Original Message----- > > > From: Aissaoui, Mustapha (Mustapha) > > > [mailto:mustapha.aissaoui@alcatel- > > > lucent.com] > > > Sent: Thursday, July 03, 2014 6:48 PM > > > To: mpls@ietf.org > > > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > > mpls- chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Aissaoui, > > > Mustapha (Mustapha); Ross Callon; Jeffrey (Zhaohui) Zhang; > > > jeremy.whittaker@verizon.com > > > Subject: RE: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > > > simple-02 > > > > > > Dear all, > > > I was asked to review this draft and I think it describes valid > > > issues to be resolved. I however have a couple of comments about the > > > way the authors went about to address them. > > > > > > 1. Relation to RFC 7110 - Return Path Specified Label Switched Path > > > (LSP) Ping. > > > Section 4.1 argues the reason why a separate reply mode is needed is > > > for wanting to omit the Reply Path TLV defined in RFC 7110 when the > > > sender of the echo request just wanted to use the return path of the > > > tested LSP. I do not see this as a strong justification. In many > > > cases, the LSP is unidirectional or the responder node is a transit > > > LSR and may not be able to inject the reply in the reverse direction > > > of that LSP. In that case, I can see that providing a specific > > > return LSP which is different than the tested LSP is required and > > > the Reply Path TLV is > > needed. > > > > > > Assuming this is still an important issue for the authors, I would > > > suggest to relax the rule in RFC 7110 such that if the echo request > > > includes reply mode > > > 5 "Reply via Specified Path" and the Reply Path TLV is not included, > > > the responder node will interpret this as an implicit request to > > > reply via the reverse direction of the tested LSP. > > > > If that's more desired by the WG, I have no objection to that as long > > as it doesn't require a TLV to indicate reverse LSP :) > > > > > > > > 2. Reply Mode Order TLV > > > I am not convinced of the need for this TLV. There is not much reply > > > modes which are usable today together. Only reply mode 2 can be > > > concurrently used with reply mode 5 in RFC 7110 or reply mode 4. > > > Reply mode 3 is not very popular as far as I know. Also, most > > > applications would reply with mode 2 if the requested mode is not > > > available. So, I can't see how this new TLV will be useful in practic= e. > > > > You are absolutely correct, not all combinations of the reply modes in > > the Reply Mode TLV is realistic. > > > > Value Meaning > > ----- ------- > > 1 Do not reply > > 2 Reply via an IPv4/IPv6 UDP packet > > 3 Reply via an IPv4/IPv6 UDP packet with Router Alert > > 4 Reply via application level control channel > > 5 Reply via Specified Path > > 6 Reply via reverse LSP > > > > Ping is simple, but let's talk about traceroute. > > > > I can imagine following example usage: > > > > (1) User prefers IP return path: > > > > If (LSP_w_reverse_LSP) { > > ReplyModeTLV{2, 6} > > } else if (LSP_w_control_channel) { > > ReplyModeTLV{2, 4} > > } else { > > ReplyMode{2} > > } > > > > (2) User does not prefer IP return path: > > > > If (LSP_w_reverse_LSP) { > > ReplyModeTLV{6, 2} > > } else if (LSP_w_control_channel) { > > ReplyModeTLV{4, 2} > > } else { > > ReplyMode{2} > > } > > > > Or user can specify a preference to be used for all LSP types (those > > who wants to make sure response is received back one way or another). > > > > (3) User prefers IP return path: > > > > If (all_LSP_types) { > > ReplyModeTLV{2, 6, 4} > > } else { > > ReplyMode{2} > > } > > > > (4) User does not prefer IP return path: > > > > If (all_LSP_types) { > > ReplyModeTLV{4, 6, 2} > > } else { > > ReplyMode{2} > > } > > > > I hope this answers your comments/concerns a bit :) > > > > Thanks! > > > > -Nobo > > > > > > > > Regards, > > > Mustapha. From nobody Fri Jul 4 11:12:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618111B2DED for ; Fri, 4 Jul 2014 11:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZCVfg3htLv8 for ; Fri, 4 Jul 2014 11:12:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE33C1B2DBA for ; Fri, 4 Jul 2014 11:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8239; q=dns/txt; s=iport; t=1404497556; x=1405707156; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TJgrXmIv8kcKDBPx9HwCgKfy5FQJPkkJg2dPDIjle1c=; b=Zx8v4pSodeFAKIJkNnFYJ3YHLt2HKlw+i83Z+2FaNZin2VviKV6HBw+h +uZTbI9SxojNimYqPSj/bTU0fLA9YFI38HZKMTYteG9p6VR5Y4I69I3fw EZbZNOaI63o9EVtGfYQAw2o/xncEnRj9sKP/98edhUkVrr9OR/+wXmDdJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFDttlOtJA2N/2dsb2JhbABagmokgSzGKwGBCxZ1hAMBAQEDASdSBQsCAQgiJDIlAgQODROIHwgBylsXjnExB4MtgRYBBIoXjEWYJoNDgjA X-IronPort-AV: E=Sophos;i="5.01,602,1400025600"; d="scan'208";a="58392601" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 04 Jul 2014 18:12:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s64ICXic012616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 18:12:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 13:12:33 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAAtFWXAAAHKr7g///9lQD//1TMQA== Date: Fri, 4 Jul 2014 18:12:32 +0000 Message-ID: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> In-Reply-To: <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/V1PuMqv531AR8ZhfMyCJ1cF2Zzw Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 18:12:38 -0000 Hi Sam, > In the Introduction it says > "However, it is becoming increasingly difficult for an initiator to > =A0=A0select a valid return path to encode in the MPLS LSP echo request > =A0=A0packets. =A0If the initiator does not select a valid return path, t= he > =A0=A0MPLS LSP echo reply will not get back to the initiator. =A0This res= ults > =A0=A0in a false failure of MPLS LSP Ping and Traceroute operation. =A0In= an > =A0=A0effort to minimize such false failures, different implementations > =A0=A0have chosen different default return path encoding for different LS= P > =A0=A0types and LSP operations. =A0The problem with implementations havin= g > =A0=A0different default return path encoding is that the MPLS echo reply > =A0=A0will not work in many cases, and the default value may not be the > =A0=A0preferred choice by the operators. > " >=20 > The problems I have is regarding the need for this ID are 1. Can we solve= the > problem without the need for this ID/solution? Answer is yes, albeit it t= akes > one or more requests. If you say, it is solving a problem which was could= n't > be solved earlier, I would like to see. >=20 > The problem can be addressed with vendors iterating the operation with > multiple Return Paths when the previous try didn't work. > And exact behavior being well document and operators fully understanding > potentially different behavior per LSP types, per ping/trace operation ty= pe > and deviating behaviors across multiple vendors/products. If you > implement this, with user preference knob (yes some prefers IP return pat= h > while other do not prefer IP return path), imagine yourself trying to exp= lain > to users how things work, and imagine yourself trying to explain why > vendors/products behave differently. I sure wouldn't want to :) It's inde= ed > not a problem that cannot be solved, but it's an aspect of LSP Ping/Trace= that > can be simplified in terms of implementations and especially operations! > %sam - You say it didn't work. Could you provide info why it didn't work?= In > the last sentence you say it simplifies. So does it simplify or is it fix= ing > something which was not working earlier? Perhaps the right thing to say is, it doesn't work with one MPLS echo reque= st message today. Sure the initiating device can, automatically or user ini= tiated, issue 2 or 3 MPLS echo request to the same target, cycling through = list of Reply Modes. With the change, it now works with one MPLS echo reque= st message, and it is simplified because you only need one MPLS echo reques= t vs. few that you needed before. > LSP ping itself is full of knobs and it has to be explained. You could fi= nd that > in every vendors documentation and it is nothing knew. I know it because = I > have authored much of the documentation. Yup, I am well aware of that Sam, and which is why this discussion is so wo= rth the effort! I am hoping, one of these replies, I'll get a message saying "yes this is a= reasonable extension" :) > 5. With the proposed solution, to determine the problem, one also needs t= o > read the 'reply mode' used by the replying device. IOW, return code + rep= ly > mode used will actually define the behavior. This changes the definition = of > RFC4379. 6. Specific to the text above, I do not agree that the problem i= s due > to implementation. It is the user choice which ever reply mode he/she > wants to use. If using CLI, could chose different reply mode. If it is > application, he/she could select it there. >=20 > User prefers control channel for operations on TP tunnels. >=20 > traceroute mpls ... [default reply mode 4 used] >=20 > Timeout > Timeout > Timeout > Timeout > ... > Success >=20 > Operator: What the heck! >=20 > <20 minutes later> >=20 > Operator: Oh man, there is no problem! This is tunnel 100 and is not 200,= it's > not co-routed! >=20 > Just an example :) >=20 > If possible (and yes it is), the tool should provide better experience to= users. > Here is a counter example and response to your example, below. >=20 > traceroute mpls .[new tlv - reply mode 5, 2] /* reply mode 5 or 4, I am j= ust > illustrating with 5 here */ >=20 > success > success > success > success >=20 > 1hr later, oh shoot, return path is broken but I am getting success becau= se > replies are in the ip path and not on reverse LSP. >=20 > this is much more harmful than not receiving reply. No no no, the output should be: success [Reply Mode: IPv4 UDP] success [Reply Mode: IPv4 UDP] success [Reply Mode: IPv4 UDP] success [Reply Mode: application level control channel] So that it's obvious to users that what is working and what is not working. Maybe not exactly in that output format, but you get the idea. And with that, there is absolutely no harm, rather you are providing much m= ore information back to the user than what is available today. Not to mention the command will finish right away instead of waiting [timeo= ut] from every LSR. Imagine if this was an application running the command, do you really want = the application to take 5 seconds or few tens of milliseconds? And do you w= ant the application to run the same command again to get the information wh= ich would've been possible to get in the first try? >=20 > And to your example, few very important points I'd like to make > 1. getting a timeout is not an issue, when lsp ping command is incorrectl= y > issued. Infact it is correct. No one can set that right, when user issues= wrong > command. How "timeout" contributes to the usability has been answered above. > 2. What I fail to understand is, how does your proposed solution make it > right? Just because you get the reply all is well? what if the return pat= h is > indeed broken (as illustrated in my example above), you will not be able = to > infer something is wrong, (strictly interpreting RFC4379) because return > code received is '3/8/5/6'. Ok this one is already answered above as well. > 3. Specific to your example, when you perform trace on non-corouted TP > tunnels, timeout SHOULD be returned when there is no return lsp for in > band reply from p1 and p2, because the return path chosen is 'reply mode = 4'. > In order to give 'better experience' what command will you issue and how > different the o/p will be, assuming there is no ip on intermediate nodes.= (p1, > p2,p3,p4) Sample topology below No, it's not the timeout that user is interested in seeing. If control channel is preferred: - responder uses the control channel. If timeout is seen with this, then th= at's a good thing (as you indicated, and I fully agree). - if there is no control channel at the responder node, then that should be= notified by the responder to the initiator via alternate path (instead of = just timing out). >=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/----P1--P2---\ > PE1--- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 PE2 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 \----P3--P4-----/ >=20 > PE1->PE2 lsp is via p1, p2 > PE2->PE1 lsp is via p4,p3 >=20 >=20 >=20 >=20 > The point is, why to introduce this optimization solution, where one coul= d > solve the problem without any of this new upgrade? If you are saying don't introduce extension to improve the tool because the= re's a way to do the same even if that's inefficient, then there isn't much= more I can say. However, I do believe in a good extension if inefficiency = can be made efficient. > Alternatively, for ex: If the reply was being received with reply mode '5= , but > now I don't receive it now, send a new request with reply mode 1. This is > more simple than the proposed solution without needing any change. > I'd be open to hearing the strong reason, this ID is solving, which could= n't be > solved with RFC4379. >=20 > Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply via > Specified Path) starts timing out? That sounds a very silly, but maybe I'= m > missing something. > typo. Meant to say reply mode 2. Ah lol. Thanks! -Nobo From nobody Fri Jul 4 15:40:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4886B1A01BA; Fri, 4 Jul 2014 15:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k58B7uTQ3N5i; Fri, 4 Jul 2014 15:40:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33801A017F; Fri, 4 Jul 2014 15:40:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704224025.4253.72163.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 15:40:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3Vp1ekGvLKZJLjiC-B36F3ZnMo4 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ipv6-13.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 22:40:27 -0000 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 : Updates to LDP for IPv6 Authors : Rajiv Asati Vishwas Manral Rajiv Papneja Carlos Pignataro Filename : draft-ietf-mpls-ldp-ipv6-13.txt Pages : 22 Date : 2014-07-04 Abstract: The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-ipv6-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 5 00:21:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4691A0369 for ; Sat, 5 Jul 2014 00:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_MEDS=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHd7vNlmFKEY for ; Sat, 5 Jul 2014 00:21:09 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9F91A035C for ; Sat, 5 Jul 2014 00:21:09 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id v10so2789840pde.6 for ; Sat, 05 Jul 2014 00:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JzXy88m/A3DprTiFTyPFKaM8WljT+H07lgcVK1Iqxvs=; b=iNNEYaZjZD0pbhN0Q+NvPC/YsNzJBTtQQ0Q+WX1cVNmISJo7PAWqdUXs+Y/3JoAg6v 6Ygj+QJxRcn3M6PS4ki4L5vYkDvCMRGdvHYyfG3LzyzDdd6vb+Sx4z2au5bFtIY7MGFY UEZHoTziC4wjrbzBphfEL9OnvDkOJqTkCPxKXqDEOpnj8obdU4h73KsP/BNgUeMnrV98 89KQ8adxw1/It3juuxctYMO71vZ48y2lMdQzkYzSHnnkx0uNOfqXmVutQUke6cW1JKkj /3Q1k2xKdFMaiCUgN9hDZ9VoYL0Wul/hrB4MBpjoa4shZ0y+3KWIlP1vVxenLeLgiUgJ 1k5w== X-Received: by 10.66.146.199 with SMTP id te7mr833807pab.106.1404544868861; Sat, 05 Jul 2014 00:21:08 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id st5sm32448725pbc.68.2014.07.05.00.21.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Jul 2014 00:21:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Sat, 5 Jul 2014 00:21:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jYdw-O7ahh1AyNXopKpZNcjU_CU Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 07:21:10 -0000 Hi Nobo, Thank you for the reply. Please find my replies inline. On Jul 4, 2014, at 11:12 AM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 >> In the Introduction it says >> "However, it is becoming increasingly difficult for an initiator to >> select a valid return path to encode in the MPLS LSP echo request >> packets. If the initiator does not select a valid return path, the >> MPLS LSP echo reply will not get back to the initiator. This = results >> in a false failure of MPLS LSP Ping and Traceroute operation. In = an >> effort to minimize such false failures, different implementations >> have chosen different default return path encoding for different = LSP >> types and LSP operations. The problem with implementations having >> different default return path encoding is that the MPLS echo reply >> will not work in many cases, and the default value may not be the >> preferred choice by the operators. >> " >>=20 >> The problems I have is regarding the need for this ID are 1. Can we = solve the >> problem without the need for this ID/solution? Answer is yes, albeit = it takes >> one or more requests. If you say, it is solving a problem which was = couldn't >> be solved earlier, I would like to see. >>=20 >> The problem can be addressed with vendors iterating the operation = with >> multiple Return Paths when the previous try didn't work. >> And exact behavior being well document and operators fully = understanding >> potentially different behavior per LSP types, per ping/trace = operation type >> and deviating behaviors across multiple vendors/products. If you >> implement this, with user preference knob (yes some prefers IP return = path >> while other do not prefer IP return path), imagine yourself trying to = explain >> to users how things work, and imagine yourself trying to explain why >> vendors/products behave differently. I sure wouldn't want to :) It's = indeed >> not a problem that cannot be solved, but it's an aspect of LSP = Ping/Trace that >> can be simplified in terms of implementations and especially = operations! >> %sam - You say it didn't work. Could you provide info why it didn't = work? In >> the last sentence you say it simplifies. So does it simplify or is it = fixing >> something which was not working earlier? >=20 > Perhaps the right thing to say is, it doesn't work with one MPLS echo = request message today. Sure the initiating device can, automatically or = user initiated, issue 2 or 3 MPLS echo request to the same target, = cycling through list of Reply Modes. With the change, it now works with = one MPLS echo request message, and it is simplified because you only = need one MPLS echo request vs. few that you needed before. As you can see, my argument, just like every other argument made at IETF = is, why one more extra option, when it already works, albeit with extra = request. Also this requires all nodes to be upgraded to supported to = fully functional as you describe. The extra cost is not worth it, when = you could achieve the same with small cost in workflow but no upgrade or = protocol/TLV change. >=20 >> LSP ping itself is full of knobs and it has to be explained. You = could find that >> in every vendors documentation and it is nothing knew. I know it = because I >> have authored much of the documentation. >=20 > Yup, I am well aware of that Sam, and which is why this discussion is = so worth the effort! > I am hoping, one of these replies, I'll get a message saying "yes this = is a reasonable extension" :) My anticipation is that we need not make this one more addition when = there is no real need and hope WG agrees with me :D Reason is, I feel is, cost outweigh any benefit it brings. More details = in the below responses. >=20 >> 5. With the proposed solution, to determine the problem, one also = needs to >> read the 'reply mode' used by the replying device. IOW, return code + = reply >> mode used will actually define the behavior. This changes the = definition of >> RFC4379. 6. Specific to the text above, I do not agree that the = problem is due >> to implementation. It is the user choice which ever reply mode he/she >> wants to use. If using CLI, could chose different reply mode. If it = is >> application, he/she could select it there. >>=20 >> User prefers control channel for operations on TP tunnels. >>=20 >> traceroute mpls ... [default reply mode 4 used] >>=20 >> Timeout >> Timeout >> Timeout >> Timeout >> ... >> Success >>=20 >> Operator: What the heck! >>=20 >> <20 minutes later> >>=20 >> Operator: Oh man, there is no problem! This is tunnel 100 and is not = 200, it's >> not co-routed! >>=20 >> Just an example :) >>=20 >> If possible (and yes it is), the tool should provide better = experience to users. >> Here is a counter example and response to your example, below. >>=20 >> traceroute mpls .[new tlv - reply mode 5, 2] /* reply mode 5 or 4, I = am just >> illustrating with 5 here */ >>=20 >> success >> success >> success >> success >>=20 >> 1hr later, oh shoot, return path is broken but I am getting success = because >> replies are in the ip path and not on reverse LSP. >>=20 >> this is much more harmful than not receiving reply. >=20 > No no no, the output should be: >=20 > success [Reply Mode: IPv4 UDP] > success [Reply Mode: IPv4 UDP] > success [Reply Mode: IPv4 UDP] > success [Reply Mode: application level control channel] >=20 > So that it's obvious to users that what is working and what is not = working. >=20 > Maybe not exactly in that output format, but you get the idea. >=20 > And with that, there is absolutely no harm, rather you are providing = much more information back to the user than what is available today. >=20 > Not to mention the command will finish right away instead of waiting = [timeout] from every LSR. >=20 > Imagine if this was an application running the command, do you really = want the application to take 5 seconds or few tens of milliseconds? And = do you want the application to run the same command again to get the = information which would've been possible to get in the first try? Usually, when ping fails, trace is used. Trace is not really used like = ping as it causes lot of extra traffic. and with network running with = huge number of LSP=92s and load balanced paths, trace is performed to = further diagnosed when ping fails. Having said that, two things we need to see. 1. What are the LSP types it will be really useful to have multiple = reply modes at the same time. Resp> At present, TP and PW are only LSP=92s which are bidirectional .=20= With PW VCCV, you cannot do trace for intermediate nodes anyway. So, = trace is not an option.=20 With TP, one could have IP enabled and non-ip enabled P routers With = non-IP enabled, you can only use reply mode 5(or 4, not sure what diff = vendors implemented). IOW, you cannot use reply mode 3 or 2. So, that leaves with TP LSP=92s with IP enabled P routers. And within = that, this is really useful only if the LSP=92s are non-corouted.=20 Let me know if which other LSP=92s missed out here. 2.=20 For the above trace example, in order for the output to receive = =91success' from all hops, you need to have all devices supporting this = TLV.=20 Let us take this, you send the this new TLV with reply modes [5,2], if = you receive all timeouts, what do you conclude? in-band reply mode is = broken + IP path also broken OR nodes do not support this TLV? >>=20 >> And to your example, few very important points I'd like to make >> 1. getting a timeout is not an issue, when lsp ping command is = incorrectly >> issued. Infact it is correct. No one can set that right, when user = issues wrong >> command. >=20 > How "timeout" contributes to the usability has been answered above. >=20 >> 2. What I fail to understand is, how does your proposed solution make = it >> right? Just because you get the reply all is well? what if the return = path is >> indeed broken (as illustrated in my example above), you will not be = able to >> infer something is wrong, (strictly interpreting RFC4379) because = return >> code received is '3/8/5/6'. >=20 > Ok this one is already answered above as well. >=20 >> 3. Specific to your example, when you perform trace on non-corouted = TP >> tunnels, timeout SHOULD be returned when there is no return lsp for = in >> band reply from p1 and p2, because the return path chosen is 'reply = mode 4'. >> In order to give 'better experience' what command will you issue and = how >> different the o/p will be, assuming there is no ip on intermediate = nodes.(p1, >> p2,p3,p4) Sample topology below >=20 > No, it's not the timeout that user is interested in seeing. >=20 > If control channel is preferred: > - responder uses the control channel. If timeout is seen with this, = then that's a good thing (as you indicated, and I fully agree). > - if there is no control channel at the responder node, then that = should be notified by the responder to the initiator via alternate path = (instead of just timing out). Solution is there and very simple. If there is IP reply path and no control channel as you say, just use = reply mode 2 for Trace and use reply mode =914=92 for Ping. Why is that a problem? If I am missing something here, could you clarify with real lsp example = and how this TLV is solving that existing solution is not able to, will = clarify things better. =20 >=20 >>=20 >> /----P1--P2---\ >> PE1--- PE2 >> \----P3--P4-----/ >>=20 >> PE1->PE2 lsp is via p1, p2 >> PE2->PE1 lsp is via p4,p3 >>=20 >>=20 >>=20 >>=20 >> The point is, why to introduce this optimization solution, where one = could >> solve the problem without any of this new upgrade? >=20 > If you are saying don't introduce extension to improve the tool = because there's a way to do the same even if that's inefficient, then = there isn't much more I can say. However, I do believe in a good = extension if inefficiency can be made efficient. That is where I disagree. what you say is efficient, is not true, = because of the cost this solution for this to work and that too only for = a corner case lsp type. We could debate this point, but I doubt we could converge on the = efficiency part. It is like the debate, more vs less. :D cheers -sam >=20 >> Alternatively, for ex: If the reply was being received with reply = mode '5, but >> now I don't receive it now, send a new request with reply mode 1. = This is >> more simple than the proposed solution without needing any change. >> I'd be open to hearing the strong reason, this ID is solving, which = couldn't be >> solved with RFC4379. >>=20 >> Why would you send reply mode 1 (Do no reply) if reply mode 5 (Reply = via >> Specified Path) starts timing out? That sounds a very silly, but = maybe I'm >> missing something. >> typo. Meant to say reply mode 2. >=20 > Ah lol. >=20 > Thanks! >=20 > -Nobo >=20 From nobody Sat Jul 5 05:56:52 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901441A050E for ; Sat, 5 Jul 2014 05:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNnDD7Ai8suB for ; Sat, 5 Jul 2014 05:56:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025CC1A0505 for ; Sat, 5 Jul 2014 05:56:47 -0700 (PDT) Received: from [2.71.59.33] (2.71.59.33.mobile.tre.se [2.71.59.33]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9E6901802B24; Sat, 5 Jul 2014 14:56:45 +0200 (CEST) Message-ID: <53B7F60D.3090004@pi.nu> Date: Sat, 05 Jul 2014 14:56:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yakov Rekhter , mpls@ietf.org, "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" References: <201407021902.s62J2Un58570@magenta.juniper.net> In-Reply-To: <201407021902.s62J2Un58570@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wxiFmDvDmXdIFFZrCVWg9zmltBA Subject: Re: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-14.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:56:50 -0000 Working Group, Sorry for the late responses, I have a backlog after relocating for the summer back to Sweden. Yakov is right - all comments are addressed and the draft is ready for publication request. However there is one small caveat, the draft uses a IANA registry (based on advice from chairs and ADs) that is not yet in place. The new registry will be created based on draft-ietf-l3vpn-pmsi-registry which is in AD evaluation. I'd like to wait for the AD comments before sending the publication request for this draft. I hope I will be able to do that early next week. /Loa mpls co-chair On 2014-07-02 21:02, Yakov Rekhter wrote: > Folks, > > The revised version (-14) reflects all the comments received > during the WG LC. > > Yakov. > ------- Forwarded Message > > Date: Wed, 02 Jul 2014 11:10:00 -0700 > From: > To: > cc: > Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-14.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 o > f the IETF. > > Title : Inter-Area P2MP Segmented LSPs > Authors : Yakov Rekhter > Rahul Aggarwal > Filename : draft-ietf-mpls-seamless-mcast-14.txt > Pages : 42 > Date : 2014-07-02 > > Abstract: > This document describes procedures for building inter-area point-to- > multipoint (P2MP) segmented service LSPs by partitioning such LSPs > into intra-area segments and using BGP as the inter-area routing and > label distribution protocol. Within each IGP area the intra-area > segments are either carried over intra-area P2MP LSPs, using P2MP LSP > hierarchy, or instantiated using ingress replication. The intra-area > P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress > replication is used within an IGP area, then (multipoint-to-point) > LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP > area. The applications/services that use such inter-area service LSPs > may be BGP Multicast VPN, VPLS multicast, or global table multicast > over MPLS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-14 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > ------- End of Forwarded Message > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jul 5 08:26:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703771A0B05 for ; Sat, 5 Jul 2014 08:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUr6nu_ntOKw for ; Sat, 5 Jul 2014 08:26:27 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 4CA571A0B08 for ; Sat, 5 Jul 2014 08:26:27 -0700 (PDT) Received: (qmail 14178 invoked by uid 0); 5 Jul 2014 15:26:24 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 5 Jul 2014 15:26:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id NlSC1o00G2SSUrH01lSFpz; Sat, 05 Jul 2014 15:26:23 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=zqHLjNqbk_wA:10 a=HFCU6gKsb0MA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=OL2PBTLkfaxC3BG2_xIA:9 a=oCPxG4c3oC-NghgG:21 a=qpmMj8mtTLQwsh6o:21 a=QEXdDO2ut3YA:10 a=3463uW3UAAAA:8 a=fO5YdYd42CcL8vAdCKQA:9 a=dfi9gUwGQP4ljbUr:21 a=3XlLnZWhqq-_Rh3e:21 a=zcfGFlIuNhHJS6MY:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=L7g7tM0swGBUz9W39Tl1NMjgAHCo/TLXjzVUv9NZQ3A=; b=AJGpMRbGz/BeQibLUKeFKDRmzonnWUZTXWy41w0q2h781NN3vncDiCIbXPknzejy+c+ROULoMfY5EeXkjrVY3OeCMr9tEGVYcuRjcqNXMUywdDXnE0SlVauDNp2XhQsf; Received: from box313.bluehost.com ([69.89.31.113]:46310 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X3Rqv-0007Fu-34; Sat, 05 Jul 2014 09:26:13 -0600 Message-ID: <53B8190E.6080505@labn.net> Date: Sat, 05 Jul 2014 11:26:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeong Ryoo , "rtg-ads@tools.ietf.org" References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------020809060909070305050609" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_wQ83KxPnLtKt7YDJ660XQusWrc Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 15:26:30 -0000 This is a multi-part message in MIME format. --------------020809060909070305050609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Jeong/Authors, Thank you for the response. Most of the changes look good. I still have a few questions and open comments. Please see below. Lou On 7/3/2014 8:52 PM, Jeong Ryoo wrote: > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are > proposing our resolutions to your comments. Please, let us know if the > proposal is appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > ... > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we > concluded that the distinction between protection and restoration > should be aligned with the exiting documents normatively referenced by > this document. Accordingly, the following 16 modifications will be > done in revision: > ... (deleted changes looked fine.) > > > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > Dedicated is also an ambiguous term, how about: OLD the resources for the protection path are fully committed, the protection path in the case of SMP consists of segments that are dedicated to the protection of the related working path and also NEW the resources for the protection path are fully allocated, the protection path in the case of SMP consists of segments that are allocated to the protection of the related working path and also > OLD: > > resources may be planned but would not be committed until … > > NEW: > > resources may be planned but would not be utilized until … > How about: OLD resources may be planned but would not be committed until requested NEW resources may be allocated but would not be utilized until requested ... > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The different > working paths in > > the SMP network are involved in the resource utilization coordination. > > . > This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.) ... > > > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > why use a new term "assigned" vs the previous term "utilized"? If there is no distinction being made the same term should be used (either term is fine, but choose one). If there is a distinction, it should be made explicit (i.e., explained). > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > same comment. ... > > > > > - Section 2, 1st paragraph, last sentence. This sentence really defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > “This document is intended to clarify the instructions to protocol > designers producing solutions that satisfy the requirements set out in > this document.” > > > > How about being even more explicit (in both the abstract and section 1): This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane. > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in the > PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 > (PSC in APS mode), fate-sharing is not required as unidirectional > switching is allowed. This document does not impose any restriction on > co-routing, either. > > > Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic. Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG. (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".) > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and hard > preemptions in the context of extra traffic, which is not exactly the > case for SMP. > Then 6372 should be referenced and the difference should be described. Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies. 6372 is after all titled "MPLS-TP Survivability Framework"... > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > okay > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use > SHALL NOT. > > > > okay. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal priority > requests, i.e., when the requests occur simultaneously,, tie-breaking > rules SHALL be defined in scope of an SMP domain. > > > > > good enough (i.e., states that the definition of tie-breaking is FFS.) > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > “As described in [RFC6372], the event of preemption may be detected by > OAM and reported as a fault or a degradation of traffic delivery.” > okay. > > > - Section 5.7. There may be coordination required on soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from “SMP in > hard-preemption mode SHOULD …” to “SMP SHOULD …” and move the changed > paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > great. > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > “The MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.” > > > okay. > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for SMP. > Some text of Section 2 is repeated in Section 1 as you suggested earlier. > > > We're in the domain of style, so is your call. > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as closely as > possible to provide fast protection. > > > What text change is planned? > > - Section 5.2. I suggest numbering the currently bulletted requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the fourth > bullet belongs to the requirements of hard-preemption. > Do you plan a text change? (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.) > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > okay. > > - Section 5.2: requirement 6 seems to be a subset of 7, so it should be > dropped. > > [Authors] Yes, it will be deleted. > > great. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control plane > supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that “When the condition that > triggered the protection switching is cleared, …” > > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes of > operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add “as described in [RFC6372]” to the ends of two > paragraphs for WTR timer and hold-off timer. > > > Okay. > ***** End of Comment resolution ***** > ... --------------020809060909070305050609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Jeong/Authors,
    Thank you for the response.  Most of the changes look good.  I still have a few questions and open comments.  Please see below.

Lou

On 7/3/2014 8:52 PM, Jeong Ryoo wrote:
Dear Lou,

 

Thanks a lot for your valuable comments.

 

The authors of this draft have discussed your comments, and are proposing our resolutions to your comments. Please, let us know if the proposal is appropriate to address your comments and concerns.

 

Best regards,

 

Authors of draft-ietf-mpls-smp-requirements draft

 

****** Beginning of Comment Resolution ******

 

- Document's usage of "committed" vs "allocated" resources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:


...

 

[Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we concluded that the distinction between protection and restoration should be aligned with the exiting documents normatively referenced by this document. Accordingly, the following 16 modifications will be done in revision:

... (deleted changes looked fine.)

 

 

(4) Page 7, the first paragraph:

OLD:

the resources for the protection path are fully committed,

NEW

the resources for the protection path are fully dedicated,

 

Dedicated is also an ambiguous term, how about:
OLD
   the resources for the protection path are fully committed, the
   protection path in the case of SMP consists of segments that are
   dedicated to the protection of the related working path and also
NEW
   the resources for the protection path are fully allocated, the
   protection path in the case of SMP consists of segments that are
   allocated to the protection of the related working path and also


OLD:

resources may be planned but would not be committed until …

NEW:

resources may be planned but would not be utilized until …

How about:
OLD
   resources may be planned but would not be committed until requested
NEW

   resources may be allocated but would not be utilized until requested

...
 

(7) The second paragraph of Section 4.1:

OLD:

When the reserved resources of the shared segments are committed to a

particular protection path, there may not be sufficient resources

available for an additional protection path. This then implies that

if another working path of the SMP domain triggers a protection

switch, the commitment of the resources may fail. In order to

optimize the operation of the commitment and preparing for cases of

multiple working paths failing, the commitment of the shared

resources are be coordinated between the different working paths in

the SMP network.

NEW:

When the reserved resources of the shared segments are utilized by a

particular protection path, there may not be sufficient resources

available for an additional protection path. This then implies that

if another working path of the SMP domain triggers a protection

switch, the resource utilization coordination may fail. The different working paths in

the SMP network are involved in the resource utilization coordination. 

.


This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.)

...

 

  

(12) Section 5.2, the third bullet item:

OLD:

If multiple protection paths of equal priority are requesting

allocation of the shared resources, the resources SHOULD be

committed on a first come first served basis.

NEW:

If multiple protection paths of equal priority are requesting

the shared resources, the resources SHOULD be

assigned on a first come first served basis.


why use a new term "assigned" vs the previous term "utilized"?  If there is no distinction being made the same term should be used (either term is fine, but choose one). If there is a distinction, it should be made explicit (i.e., explained).

 

(13) Section 5.2, the fourth bullet item:

OLD:

If the protection resources are committed to a protection path,

whose working path has a lower priority, resources required for

the higher priority path SHALL be committed to the higher priority

path.

NEW:

If the protection resources are utilized by a protection path,

whose working path has a lower priority, resources required for

the higher priority path SHALL be assigned to the higher priority

path.

 

 

same comment.

...
 

 

- Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions
to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this in
the abstract and move it to a more pronounced place in section 1 (or
3).

[Authors] We can add the following paragraph at the end of Section 1:

“This document is intended to clarify the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.”

 



How about being even more explicit (in both the abstract and section 1):
   This document provides requirements  for  any
   mechanism that would be used to implement SMP for MPLS-TP data paths,
   in networks that delegate protection switch coordination to the data
   plane.

- General comment: fate-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

[Authors] Fate-sharing is not required by this document. Even in the PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-routing, either.

 


Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic.  Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG.  (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".)


- In section 4 and 5.2 you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

[Authors] One concern is that RFC 6372 describes both soft and hard preemptions in the context of extra traffic, which is not exactly the case for SMP.


Then 6372 should be referenced and the difference should be described.  Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies.  6372 is after all titled "MPLS-TP Survivability Framework"...

 


- In section 4.2 you say "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

[Authors] Yes, we will make the correction.

okay

 


- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover
mechanism is used, the control plane SHALL NOT ...". If referring to
an operator's/user's choice of protection mechanism, I think the most
you can say is MAY.

[Authors] The first case is the one we are aiming at. We will use SHALL NOT.

 


okay.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
domain." As this is a requirement, what you mean by "tie-breaking
rules" should be defined directly or by reference.

[Authors] The sentence can be rewritten as:

OLD:

Tie-breaking rules SHALL be defined in scope of an SMP domain.

NEW:

In order to cover the situation where the first come first served principle cannot resolve the contention among multiple equal priority requests, i.e., when the requests occur simultaneously,, tie-breaking rules SHALL be defined in scope of an SMP domain.

 

 


good enough (i.e., states that the definition of tie-breaking is FFS.)


- Section 5.3. RFC6372 takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

[Authors] We can add the following sentence at the end:

“As described in [RFC6372], the event of preemption may be detected by OAM and reported as a fault or a degradation of traffic delivery.” 


okay.


- Section 5.7. There may be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

[Authors] Yes, we will change the second paragraph from “SMP in hard-preemption mode SHOULD …” to “SMP SHOULD …” and move the changed paragraph above the first paragraph.

 


Nits:

- Abstract: I don't recall the term "executive action" being used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

[Authors] Yes, the term will be changed as you suggested.

 


great.

- Section 1, paragraph 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

[Authors] The proposed text for the paragraph 1 is:

“The MPLS Transport Profile (MPLS-TP) is described in [RFC5921],

and [RFC6372] provides a survivability framework for MPLS-TP

and is the foundation for this document.”

 

okay.


- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

[Authors] OK.

 

 


- Sections 3 (and to a lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

[Authors] Section 3 was intended to present a reference model for SMP. Some text of Section 2 is repeated in Section 1 as you suggested earlier.

 

We're in the domain of style, so is your call.

 


- Section 3.2 should have a reference for "existing control plane
solutions for SMP within MPLS".

[Authors] [RFC4206] will be added as a reference


- Section 3.2 again uses the "executive action" term.

[Authors] OK, the term will be changed.

 


- Section 4.1. You say "two operations simultaneously". Do you really
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

[Authors] Both actions should occur at the same time, or as closely as possible to provide fast protection.

 

What text change is planned?


- Section 5.2. I suggest numbering the currently bulletted requirements
list.

[Authors] OK, we will use numbers.

 


- Section 5.2: First paragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

[Authors] The first paragraph is for soft-preemption, while the fourth bullet belongs to the requirements of hard-preemption.


Do you plan a text change?  (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.)


- Section 5.2, req 5. How does this relate to section 5.5? Shouldn't
the topics related to timing be consolidated?

[Authors] Yes, req 5 can be moved to Section 5.5.

 

okay.


- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
dropped.

[Authors] Yes, it will be deleted.


great.

- Section 5.2, requirement 8. Isn't this a subset of 9? Why call out
just this one traffic treatment (sub) requirement?

[Authors] Req. 9 will be deleted as it seems to require control plane supports.



- Section 5.3. s/MAY/will

[Authors] OK.

 


- section 5.4: " When the working path detects.." detection is by the
node not the path.

[Authors] Yes. We will simply say that “When the condition that triggered the protection switching is cleared, …”


- Section 5.4, last sentence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

[Authors] As in other protection switching technologies, two modes of operations (revertive and non-revertive) are required.

 


- section 5.6. RFC 6372 should be referenced

[Authors] We will add “as described in [RFC6372]” to the ends of two paragraphs for WTR timer and hold-off timer.

 

Okay.

***** End of Comment resolution *****

...

--------------020809060909070305050609-- From nobody Sat Jul 5 12:49:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B327D1B27F9; Sat, 5 Jul 2014 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Navhswq0g-ZE; Sat, 5 Jul 2014 12:49:13 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7224B1B27F7; Sat, 5 Jul 2014 12:49:12 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2772477wgg.8 for ; Sat, 05 Jul 2014 12:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d2OPxjwHtG2nCvWcyHhr+qTWIP46UyzAk5W3F89ES4k=; b=LQisED0lEZhVVg5BMcsRjEv50lP4htBUSx7dk/xlfThlWEeopUaCGTFmn3ARlHoTCz AlV0NfIStfYlitNII437yKIj1+sg5UVYxGNCuCCmjqWqEcoFIN2sTK9o5bMj72lgtVfb FqjH39583r8HrFLzKSX4cDk0QE1MPPtubfWIc3NEeyeYea/vAGPQNm6bMoVNIU/yS3bM LjR5kxiAc4/rIOxEW/ZmjC5TeyPcWpPnFPQVnN2vVFLJ6yuXc6FN1qaHp+faRwmHIfD/ mhbxQAZamqJsCAXf1uo85iVEKqyO22KpOxZLhwBs/pBhYIw5KRosAwmvxUanzh0tCHC5 rc6A== MIME-Version: 1.0 X-Received: by 10.180.86.7 with SMTP id l7mr12607785wiz.55.1404589750937; Sat, 05 Jul 2014 12:49:10 -0700 (PDT) Received: by 10.194.191.163 with HTTP; Sat, 5 Jul 2014 12:49:10 -0700 (PDT) Received: by 10.194.191.163 with HTTP; Sat, 5 Jul 2014 12:49:10 -0700 (PDT) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> Date: Sat, 5 Jul 2014 22:49:10 +0300 Message-ID: From: Yaacov Weingarten To: Jeong Ryoo Content-Type: multipart/alternative; boundary=f46d04428e02290ddc04fd778926 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/pTiynzFBSiTyccL_ayPA1FH1GK4 Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:49:18 -0000 --f46d04428e02290ddc04fd778926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lou, hi I would like to address two of your comments, in your follow-up message, since I am the source of the change in terminology. Regarding the two occurences of "assigned" in place of "utilized" - when I read the proposed changes,as discussed amongst the authors, I felt that in those two instances the use of "utilized" could lead to some ambiguity. If we state that "resources SHOULD be utilized on a first come first served basis" this could be interpreted (IMO) as referring to the packet level, rather than utilized by a specific path, such that packets from different paths could be interspersed along the shared segments. Therefore,I suggested that or this context it would be better to use a word that meant that the first-come first served basis was at the level of assigning (or allocating) the resources rather than utilizing them. Hope this clarifies this point. I am certain that I speak for the other authors in saying that I am open to other suggestions. BR, yaacov On Jul 4, 2014 3:53 AM, "Jeong Ryoo" wrote: > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are proposing > our resolutions to your comments. Please, let us know if the proposal is > appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we > concluded that the distinction between protection and restoration should = be > aligned with the exiting documents normatively referenced by this documen= t. > Accordingly, the following 16 modifications will be done in revision: > > > > (1) Section 1, the third paragraph > > OLD: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 linear protection requires > > that resources are committed for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are committed, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > NEW: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 protection requires > > that resources are allocated for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are allocated, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > > > (2) The whole text in Section 3.1 will be replaced with: > > [RFC6372], based upon the definitions in [RFC4427], differentiates betwee= n > "protection" and "restoration" dependent upon the dynamism of the resourc= e > allocation. The same distinction is used in [RFC3945], [RFC4426], and > [RFC4428]. This document also uses the same distinction between protectio= n > and restoration as stated in [RFC6372]. > > > > (3) In page 6, > > OLD: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine to which parties the protection > > resources are committed. > > NEW: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine which parties utilize the protection > > resources. > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > > OLD: > > resources may be planned but would not be committed until =E2=80=A6 > > NEW: > > resources may be planned but would not be utilized until =E2=80=A6 > > > > (5) In the second paragraph in page 7, > > OLD: > > "Hard Preemption" requires the programming of selectors at the ingress of > each shared segment to specify which backup path has the highest priority > when committing protection resources, the others being preempted. > > NEW > > "Hard Preemption" requires the programming of selectors at the ingress of > each shared segment to specify the priorities of backup paths, so that > traffic of lower priority paths can be preempted. > > > > (6) The first paragraph of Section 4.1: > > OLD: > > =E2=80=A6 and commit the associated resources. The commitment of resource= s > > is dependent upon =E2=80=A6 > > NEW: > > =E2=80=A6 and coordinate the utilization of the associated shared resourc= es. > > The resource utilization coordination is dependent upon =E2=80=A6 > > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The different > working paths in > > the SMP network are involved in the resource utilization coordination. > > . > > > > (8) Section 5.1, > > OLD: > > =E2=80=A6 and commit the associated resources. > > NEW > > =E2=80=A6 and coordinate the utilization of the associated shared resourc= es. > > > > (9) In Section 5.1, > > OLD: > > In the case of multiple working paths failing, the commitment of the > > shared resources SHALL be coordinated between the different working > > paths in the SMP network. > > NEW: > > In the case of multiple working paths failing, the shared resource > utilization > > coordination SHALL be between the different working > > paths in the SMP network. > > > > (10) Section 5.1.1. > > OLD: > > =E2=80=A6 because they already have been committed to the protection of, = for > example, a higher priority working path. > > NEW: > > =E2=80=A6 because they already have been utilized for the protection of, = for > example, a higher priority working path. > > > > (11) Section 5.2, the second bullet item: > > OLD: > > Resources of the shared segments SHALL be committed to the > > protection path =E2=80=A6 > > NEW: > > Resources of the shared segments SHALL be utilized by the > > protection path =E2=80=A6 > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > > (14) Section 5.2. the seventh bullet item > > OLD: > > Once resources of shared segments have been successfully committed > > to a protection path, =E2=80=A6 > > NEW: > > Once resources of shared segments have been successfully utilized > > by a protection path, =E2=80=A6 > > > > (15) Section 5.3, the first paragraph, > > OLD: > > =E2=80=A6 request the commitment of protection resources. If the necessar= y > > shared resources are unavailable to be committed to the protection > > path, the endpoints =E2=80=A6 > > > > NEW: > > =E2=80=A6 request the coordination of the shared resource utilization. If= the > necessary > > shared resources are unavailable, the endpoints =E2=80=A6 > > > > (16) Section 5.3, the second paragraph, > > OLD: > > Similarly, if preemption is supported and the resources currently > > committed for a particular working path are =E2=80=A6 > > NEW: > > Similarly, if preemption is supported and the resources currently > > utilized by a particular working path are =E2=80=A6 > > > > > > - Section 2, 1st paragraph, last sentence. This sentence really defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > =E2=80=9CThis document is intended to clarify the instructions to protoco= l > designers producing solutions that satisfy the requirements set out in th= is > document.=E2=80=9D > > > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in the PSC > linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in > APS mode), fate-sharing is not required as unidirectional switching is > allowed. This document does not impose any restriction on co-routing, > either. > > > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and hard > preemptions in the context of extra traffic, which is not exactly the cas= e > for SMP. > > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use SHALL > NOT. > > > > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal priority > requests, i.e., when the requests occur simultaneously,, tie-breaking > rules SHALL be defined in scope of an SMP domain. > > > > > > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > =E2=80=9CAs described in [RFC6372], the event of preemption may be detect= ed by OAM > and reported as a fault or a degradation of traffic delivery.=E2=80=9D > > > - Section 5.7. There may be coordination required on soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from =E2=80=9CSMP in > hard-preemption mode SHOULD =E2=80=A6=E2=80=9D to =E2=80=9CSMP SHOULD =E2= =80=A6=E2=80=9D and move the changed > paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > =E2=80=9CThe MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.=E2=80=9D > > > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for SMP. > Some text of Section 2 is repeated in Section 1 as you suggested earlier. > > > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as closely as > possible to provide fast protection. > > > > > - Section 5.2. I suggest numbering the currently bulletted requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the fourth > bullet belongs to the requirements of hard-preemption. > > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > > > - Section 5.2: requirement 6 seems to be a subset of 7, so it should be > dropped. > > [Authors] Yes, it will be deleted. > > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control plane > supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that =E2=80=9CWhen the condition that > triggered the protection switching is cleared, =E2=80=A6=E2=80=9D > > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes of > operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add =E2=80=9Cas described in [RFC6372]=E2=80=9D to the = ends of two > paragraphs for WTR timer and hold-off timer. > > > > ***** End of Comment resolution ***** > > > > > > ------------------------------ > *=EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C : *"Lou Berger" > *=EB=B3=B4=EB=82=B8 =EB=82=A0=EC=A7=9C : *2014-06-22 01:00:48 ( +09:00 ) > *=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C : *rtg-ads@tools.ietf.org > *=EC=B0=B8=EC=A1=B0 : *rtg-dir@ietf.org , > draft-ietf-mpls-smp-requirements.all@tools.ietf.org < > draft-ietf-mpls-smp-requirements.all@tools.ietf.org>, mpls@ietf.org < > mpls@ietf.org> > *=EC=A0=9C=EB=AA=A9 : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirem= ents-06.txt > > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about the > Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-mpls-smp-requirements-06.txt > Reviewer: Lou Berger > Review Date: June 21 2014 > IETF LC End Date: 2014-06-23 > Intended Status: Informational > > Summary: > I have some minor concerns about this document that I think > should (must, actually) be resolved before publication. > > Comments: > > I think the document is well written and, other than a couple of > terminology related issues, easily understood. The document does > have a number of terminology and technical issues which should be > readily resolved prior to publication. > > Major Issues: > > Major issues are the type of concerns that will result in the > document being blocked until they are resolved. The Routing ADs will > become involved. Please include all of the major issues you have > found. Give as much context information as possible (e.g., section > numbers, paragraph counts). If you find no major issues, please > write: "No major issues found." > > - No major issues found. In particular, I expect all issues can be > resolved without AD intervention. Some of the minor issues, if not > resolved will be escalated to the AD/major issue category. > > Minor Issues: > > Minor issues are concerns about clarity or technical accuracy that > should be discussed and resolved before publication, but which would > normally be resolved between the authors and the reviewers. Please > include all of the minor issues you have found. Give as much context > information as possible (e.g., section numbers, paragraph counts). > If you find no minor issues, please write: "No minor issues found." > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > - Section 2, 1st paragraph, last sentence. This sentence really defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > - Section 5.7. There may be coordination required on soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > Nits: > > - Abstract: I don't recall the term "executive action" being used in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > - Sections 3 (and to a lesser degree section 2) are really introductory > text. I'm unsure as to why they aren't part of section 1. > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > - Section 3.2 again uses the "executive action" term. > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > - Section 5.2. I suggest numbering the currently bulletted requirements > list. > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > - Section 5.2: requirement 6 seems to be a subset of 7, so it should be > dropped. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > - Section 5.3. s/MAY/will > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > - section 5.6. RFC 6372 should be referenced > > > _______________________________________________ > 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 > > --f46d04428e02290ddc04fd778926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Lou, hi
I would like to address two of your comments, in your follow-up message, s= ince I am the source of the change in terminology.

Regarding the two occurences of "assigned" in place of "u= tilized" - when I read the proposed changes,as discussed amongst the a= uthors, I felt that in those two instances the use of "utilized" = could lead to some ambiguity.

If we state that "resources SHOULD be utilized on a first come firs= t served basis" this could be interpreted (IMO) as referring to the pa= cket level, rather than=C2=A0 utilized by a specific path, such that packet= s from different paths could be interspersed along the shared segments. The= refore,I suggested that or this context it would be better to use a word th= at meant that the first-come first served basis was at the level of assigni= ng (or allocating) the resources rather than utilizing them.

Hope this clarifies this point. I am certain that I speak for the other = authors in=C2=A0 saying that I am open to other suggestions.

BR,
yaacov

On Jul 4, 2014 3:53 AM, "Jeong Ryoo" &= lt;ryoo@etri.re.kr> wrote:
<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Dear Lou,=

=C2=A0

Thanks a lot for your valuable comments.<= /p>

=C2=A0

The authors of this draft have discussed your comments,= and are proposing our resolutions to your comments. Please, let us know if= the proposal is appropriate to address your comments and concerns.<= /span>

=C2=A0

Best regards,

=C2=A0

Authors of draft-ietf-mpls-smp-requirements draft

=C2=A0

*= ***** Beginning of Comment Resolution ******

=C2=A0

-= Document's usage of "committed" vs "allocated" res= ources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:

The distinction between protection and restoration is made based
on the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of
restoration is made based on the level of route computation,
signaling, and resource allocation during the restoration
LSP/span establishment.

This difference also leads to come confused statements in the
document as well as ambiguity in the text, i.e. confusion by the
reader. The term "committed" is not tightly defined in this
document (or earlier work) and is used differently than how
"allocated" has been used. An example of this can be found in
Section 3.1 which states:

However, the commitment of the resources, at least for the
shared segments, will only be finalized when the protection
path is actually activated. Therefore, for the purists -
regarding the terminology - SMP lies somewhere between
protection and restoration.

Both sentences are problematic. In the first, commitment seems to
cover a "protection switch" would "connect" the protect= ion path
but not the earlier "allocation" of resources. (Quoted terms are<= br> used in earlier RFCs.) The second conclusion is based on the new
distinction of protection vs. restoration and is unnecessary with
the existing distinction.

This issue exists in multiple places in the document where
"committed" is used and I'd recommend that each should be rep= laced
with terminology used in the referenced RFCs, i.e., "allocation",=
"connection", "cross-connect", "protection switch(= over)", ...

Note I'm *not* highlighting all cases where there are problems in the document related to this issue. There are a couple of places in the
document where I think it's possible that once this terminology
ambiguity is corrected that I'll have other substantive comments.

=C2=A0

[Authors] After reviewing RFCs 4427, 6372, 3945, 4426, = and 4428, we concluded that the distinction between protection and restorat= ion should be aligned with the exiting documents normatively referenced by this document. Accordingly, the following 16 modifications will be done= in revision:

=C2=A0

(1) Section 1, the third paragraph

OLD:

As pointed out

in [RFC6372] and [RFC4428], applying 1+1 linear protect= ion requires

that resources are committed for use by both the workin= g and

protection paths. Applying 1:1 protection requires that= the same

resources are committed, but allows the resources of th= e protection

path to be utilized for pre-emptible extra traffic.

NEW:

As pointed out

in [RFC6372] and [RFC4428], applying 1+1 protection req= uires

that resources are allocated for use by both the workin= g and

protection paths. Applying 1:1 protection requires that= the same

resources are allocated, but allows the resources of th= e protection

path to be utilized for pre-emptible extra traffic.

=C2=A0

(2) The whole text in Section 3.1 will be replaced with= :

[RFC6372], based upon the definitions in [RFC4427], dif= ferentiates between "protection" and "restoration" depe= ndent upon the dynamism of the resource allocation. The same distinction is= used in [RFC3945], [RFC4426], and [RFC4428]. This document also uses the same distinction bet= ween protection and restoration as stated in [RFC6372].

=C2=A0

(3) In page 6,

OLD:

The use of preemption in the network is typically a bus= iness or

policy decision such that when protection resources are= contended,

priority can be applied to determine to which parties t= he protection

resources are committed.

NEW:

The use of preemption in the network is typically a bus= iness or

policy decision such that when protection resources are= contended,

priority can be applied to determine which parties util= ize the protection

resources.

=C2=A0

(4) Page 7, the first paragraph:

OLD:

the resources for the protection path are fully committ= ed,

NEW

the resources for the protection path are fully dedicat= ed,

=C2=A0

OLD:

resources may be planned but would not be committed unt= il =E2=80=A6

NEW:

resources may be planned but would not be utilized unti= l =E2=80=A6

=C2=A0

(5) In the second paragraph in page 7,

OLD:

"Hard Preemption" requires the programming of= selectors at the ingress of each shared segment to specify which backup pa= th has the highest priority when committing protection resources, the other= s being preempted.

NEW

"Hard Preemption" requires the programming of= selectors at the ingress of each shared segment to specify the priorities = of backup paths, so that traffic of lower priority paths can be preempted.

=C2=A0

(6) The first paragraph of Section 4.1:

OLD:

=E2=80=A6 and commit the associated resources. The comm= itment of resources

is dependent upon =E2=80=A6

NEW:

=E2=80=A6 and coordinat= e the utilization of the associated shared resources.

The resource utilization= coordination is dependent upon =E2=80=A6

=C2=A0

(7) The second paragraph of Section 4.1:<= /p>

OLD:

When the reserved resources of the shared segments are = committed to a

particular protection path, there may not be sufficient= resources

available for an additional protection path. This then = implies that

if another working path of the SMP domain triggers a pr= otection

switch, the commitment of the resources may fail. In or= der to

optimize the operation of the commitment and preparing = for cases of

multiple working paths failing, the commitment of the s= hared

resources are be coordinated between the different work= ing paths in

the SMP network.

NEW:

When the reserved resources of the shared segments are = utilized by a

particular protection path, there may not be sufficient= resources

available for an additional protection path. This then = implies that

if another working path of the SMP domain triggers a pr= otection

switch, the resource utilization coordination may fail.= The different working paths in

the SMP network are involved in the resource utilizatio= n coordination.=C2=A0

.

=C2=A0

(8) Section 5.1,

OLD:

=E2=80=A6 and commit the associated resources.

NEW

=E2=80=A6 and coordinat= e the utilization of the associated shared resources.

=C2=A0

(9) In Section 5.1,

OLD:

In the case of multiple working paths failing, the comm= itment of the

shared resources SHALL be coordinated between the diffe= rent working

paths in the SMP network.

NEW:

In the case of multiple working paths failing, the shar= ed resource utilization

coordination SHALL be between the different working

paths in the SMP network.

=C2=A0

(10) Section 5.1.1.

OLD:

=E2=80=A6 because they already have been committed to t= he protection of, for example, a higher priority working path.

NEW:

=E2=80=A6 because they already have been utilized for t= he protection of, for example, a higher priority working path.

=C2=A0

(11) Section 5.2, the second bullet item:=

OLD:

Resources of the shared segments SHALL be committed to = the

protection path =E2=80=A6

NEW:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

Resources of the shared segments SHALL be utilized by t= he

protection path =E2=80=A6

=C2=A0

(12) Section 5.2, the third bullet item:<= /p>

OLD:

If multiple protection paths of equal priority are requ= esting

allocation of the shared resources, the resources SHOUL= D be

committed on a first come first served basis.

NEW:

If multiple protection paths of equal priority are requ= esting

the shared resources, the resources SHOULD be

assigned on a first come first served basis.

=C2=A0

(13) Section 5.2, the fourth bullet item:=

OLD:

If the protection resources are committed to a protecti= on path,

whose working path has a lower priority, resources requ= ired for

the higher priority path SHALL be committed to the high= er priority

path.

NEW:

If the protection resources are utilized by a protectio= n path,

whose working path has a lower priority, resources requ= ired for

the higher priority path SHALL be assigned to the highe= r priority

path.

=C2=A0

=C2=A0

(14) Section 5.2. the seventh bullet item=

OLD:

Once resources of shared segments have been successfull= y committed

to a protection path, =E2=80=A6

NEW:

Once resources of shared segments have been successfull= y utilized

by a protection path, =E2=80=A6

=C2=A0

(15) Section 5.3, the first paragraph,

OLD:

=E2=80=A6 request the commitment of protection resource= s. If the necessary

shared resources are unavailable to be committed to the= protection

path, the endpoints =E2=80=A6

=C2=A0

NEW:

=E2=80=A6 request the coordination of the shared resour= ce utilization. If the necessary

shared resources are unavailable, the endpoints =E2=80= =A6

=C2=A0

(16) Section 5.3, the second paragraph,

OLD:

Similarly, if preemption is supported and the resources= currently

committed for a particular working path are =E2=80=A6

NEW:

Similarly, if preemption is supported and the resources= currently

utilized by a particular working path are =E2=80=A6

=C2=A0

=C2=A0

-= Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this i= n
the abstract and move it to a more pronounced place in section 1 (or
3).

[Authors] We can add the following paragraph at the end= of Section 1:

=E2=80=9CThis document is intended to clarify the instr= uctions to protocol designers producing solutions that satisfy the requirem= ents set out in this document.=E2=80=9D

=C2=A0


- General comment: fat= e-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

[Authors] Fate-sharing is not required by this document= . Even in the PSC linear protection switching, such as RFC 6378 (PSC) and R= FC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-= routing, either.

=C2=A0


- In section 4 and 5.2= you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

[Authors] One concern is that RFC 6372 describes both s= oft and hard preemptions in the context of extra traffic, which is not exac= tly the case for SMP.

=C2=A0


- In section 4.2 you s= ay "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, = great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

[Authors] Yes, we will make the correction.

=C2=A0


- Section 5.1, paragra= ph 1. Why are you using "SHOULD NOT" here? If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover<= br> mechanism is used, the control plane SHALL NOT ...". If referring to an operator's/user's choice of protection mechanism, I think the mo= st
you can say is MAY.

[Authors] The first case is the one we are aiming at. W= e will use SHALL NOT.

=C2=A0


- Section 5.2. "T= ie-breaking rules SHALL be defined in scope of an SMP
domain." As this is a requirement, what you mean by "tie-breaking=
rules" should be defined directly or by reference.

[Authors] The sentence can be rewritten as:

OLD:

Tie-breaking rules SHALL be defined in scope of an SMP = domain.

NEW:

In order to cover the=C2=A0situation where=C2=A0the fir= st come first served principle cannot resolve the contention among multiple= equal priority requests, i.e., when the requests occur simultaneously,, tie-brea= king rules SHALL be defined in scope of an SMP domain.

=C2=A0

=C2=A0


- Section 5.3. RFC6372= takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

[Authors] We can add the following sentence at the end:

=E2=80=9CAs described in [RFC6372], the event of preemp= tion may be detected by OAM and reported as a fault or a degradation of tra= ffic delivery.=E2=80=9D=C2=A0


- Section 5.7. There m= ay be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

[Authors] Yes, we will change the second paragraph from= =E2=80=9CSMP in hard-preemption mode SHOULD =E2=80=A6=E2=80=9D to =E2=80= =9CSMP SHOULD =E2=80=A6=E2=80=9D and move the changed paragraph above the f= irst paragraph.

=C2=A0


Nits:

- Abstract: I don't recall the term "executive action" being = used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

[Authors] Yes, the term will be changed as you suggeste= d.

=C2=A0


- Section 1, paragraph= 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

[Authors] The proposed text for the paragraph 1 is:

=E2=80=9CThe MPLS Transport Profile (MPLS-TP) is descri= bed in [RFC5921],

and [RFC6372] provides a survivability framework for MP= LS-TP

and is the foundation for this document.=E2=80=9D

=C2=A0


- Section 1, paragraph= 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

[Authors] OK.

=C2=A0

=C2=A0


- Sections 3 (and to a= lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

[Authors] Section 3 was intended to present a reference= model for SMP. Some text of Section 2 is repeated in Section 1 as you sugg= ested earlier.

=C2=A0

=C2=A0


- Section 3.2 should h= ave a reference for "existing control plane
solutions for SMP within MPLS".

[Authors] [RFC4206] will be added as a reference=


- Section 3.2 again us= es the "executive action" term.

[Authors] OK, the term will be changed.

=C2=A0


- Section 4.1. You say= "two operations simultaneously". Do you really
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

[Authors] Both actions should occur at the same time, o= r as closely as possible to provide fast protection.

=C2=A0


- Section 5.2. I sugge= st numbering the currently bulletted requirements
list.

[Authors] OK, we will use numbers.

=C2=A0


- Section 5.2: First p= aragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

[Authors] The first paragraph is for soft-preemption, w= hile the fourth bullet belongs to the requirements of hard-preemption.


- Section 5.2, req 5. = How does this relate to section 5.5? Shouldn't
the topics related to timing be consolidated?

[Authors] Yes, req 5 can be moved to Section 5.5.

=C2=A0


- Section 5.2: require= ment 6 seems to be a subset of 7, so it should be
dropped.

[Authors] Yes, it will be deleted.


- Section 5.2, require= ment 8. Isn't this a subset of 9? Why call out
just this one traffic treatment (sub) requirement?

[Authors] Req. 9 will be deleted as it seems to require= control plane supports.



- Section 5.3. s/MAY/w= ill

[Authors] OK.

=C2=A0


- section 5.4: " = When the working path detects.." detection is by the
node not the path.

[Authors] Yes. We will simply say that =E2=80=9CWhen th= e condition that triggered the protection switching is cleared, =E2=80=A6= =E2=80=9D


- Section 5.4, last se= ntence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

[Authors] As in other protection switching technologies= , two modes of operations (revertive and non-revertive) are required.

=C2=A0


- section 5.6. RFC 637= 2 should be referenced

[Authors] We will add =E2=80=9Cas described in [RFC6372= ]=E2=80=9D to the ends of two paragraphs for WTR timer and hold-off timer.

=C2=A0

*= **** End of Comment resolution *****

=C2=A0
=C2=A0




=EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C : "Lou Berger" <<= a href=3D"mailto:lberger@labn.net" target=3D"_blank">lberger@labn.net&g= t;
=EB=B3=B4=EB=82=B8 =EB=82=A0=EC=A7=9C : 2014-06-22 01:00:48 ( +09:00= )
=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C : rtg-ads@tools.ietf.org <rtg-ads@tools.ietf.org&= gt;
=EC=B0=B8=EC=A1=B0 : rtg-dir@ietf.org <rtg-dir@ietf.org>, draft-ietf-mpls-smp-req= uirements.all@tools.ietf.org <draft-ietf-mpls-smp-requ= irements.all@tools.ietf.org>, mpls@ietf.org <mpls@ietf.org>
=EC=A0=9C=EB=AA=A9 : [mpls] RtgDir review: draft-ietf-mpls-smp-requi= rements-06.txt


Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-mpls-smp-requirements-06.txt
Reviewer: Lou Berger
Review Date: June 21 2014
IETF LC End Date: 2014-06-23
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think
should (must, actually) be resolved before publication.

Comments:

I think the document is well written and, other than a couple of
terminology related issues, easily understood. The document does
have a number of terminology and technical issues which should be
readily resolved prior to publication.

Major Issues:

Major issues are the type of concerns that will result in the
document being blocked until they are resolved. The Routing ADs will
become involved. Please include all of the major issues you have
found. Give as much context information as possible (e.g., section
numbers, paragraph counts). If you find no major issues, please
write: "No major issues found."

- No major issues found. In particular, I expect all issues can be
resolved without AD intervention. Some of the minor issues, if not
resolved will be escalated to the AD/major issue category.

Minor Issues:

Minor issues are concerns about clarity or technical accuracy that
should be discussed and resolved before publication, but which would
normally be resolved between the authors and the reviewers. Please
include all of the minor issues you have found. Give as much context
information as possible (e.g., section numbers, paragraph counts).
If you find no minor issues, please write: "No minor issues found.&quo= t;

- Document's usage of "committed" vs "allocated" re= sources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:

The distinction between protection and restoration is made based
on the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of
restoration is made based on the level of route computation,
signaling, and resource allocation during the restoration
LSP/span establishment.

This difference also leads to come confused statements in the
document as well as ambiguity in the text, i.e. confusion by the
reader. The term "committed" is not tightly defined in this
document (or earlier work) and is used differently than how
"allocated" has been used. An example of this can be found in
Section 3.1 which states:

However, the commitment of the resources, at least for the
shared segments, will only be finalized when the protection
path is actually activated. Therefore, for the purists -
regarding the terminology - SMP lies somewhere between
protection and restoration.

Both sentences are problematic. In the first, commitment seems to
cover a "protection switch" would "connect" the protect= ion path
but not the earlier "allocation" of resources. (Quoted terms are<= br> used in earlier RFCs.) The second conclusion is based on the new
distinction of protection vs. restoration and is unnecessary with
the existing distinction.

This issue exists in multiple places in the document where
"committed" is used and I'd recommend that each should be rep= laced
with terminology used in the referenced RFCs, i.e., "allocation",=
"connection", "cross-connect", "protection switch(= over)", ...

Note I'm *not* highlighting all cases where there are problems in the document related to this issue. There are a couple of places in the
document where I think it's possible that once this terminology
ambiguity is corrected that I'll have other substantive comments.

- Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this i= n
the abstract and move it to a more pronounced place in section 1 (or
3).

- General comment: fate-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

- In section 4 and 5.2 you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

- In section 4.2 you say "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, = great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? = If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover<= br> mechanism is used, the control plane SHALL NOT ...". If referring to an operator's/user's choice of protection mechanism, I think the mo= st
you can say is MAY.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP=
domain." As this is a requirement, what you mean by "tie-breaking=
rules" should be defined directly or by reference.

- Section 5.3. RFC6372 takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

- Section 5.7. There may be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

Nits:

- Abstract: I don't recall the term "executive action" being = used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

- Section 1, paragraph 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

- Sections 3 (and to a lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

- Section 3.2 should have a reference for "existing control plane
solutions for SMP within MPLS".

- Section 3.2 again uses the "executive action" term.

- Section 4.1. You say "two operations simultaneously". Do you re= ally
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

- Section 5.2. I suggest numbering the currently bulletted requirements
list.

- Section 5.2: First paragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

- Section 5.2, req 5. How does this relate to section 5.5? Shouldn't the topics related to timing be consolidated?

- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
dropped.

- Section 5.2, requirement 8. Isn't this a subset of 9? Why call out just this one traffic treatment (sub) requirement?

- Section 5.3. s/MAY/will

- section 5.4: " When the working path detects.." detection is by= the
node not the path.

- Section 5.4, last sentence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

- section 5.6. RFC 6372 should be referenced


_______________________________________________
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

--f46d04428e02290ddc04fd778926-- From nobody Sun Jul 6 06:04:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83FE1A016A for ; Sun, 6 Jul 2014 06:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ3Uj9sMKrsR for ; Sun, 6 Jul 2014 06:03:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8174B1A017C for ; Sun, 6 Jul 2014 06:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1508; q=dns/txt; s=iport; t=1404651839; x=1405861439; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NTBhNVmkwCsUy2AoAKtU4s7v8022xmI69Imus6xMcKg=; b=Vx3raPbwNBvBqkSzHVpIZOfg/29iCqAO1ghAWyHX+ZAbUjsk/ZS6rrSh /73i5JF8ZXyLoMbukKsGAC8QklWu9AcVjjCgFG0APKShIh9TQvYOXTAHE aZUVelvzCRZqSroOnq5CVN7CwW1jIOXkwHE3M+Vn74z/NgkMeuqP9keDm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJtIuVOtJA2F/2dsb2JhbABagmokgSzGKwGBCRZ1hAMBAQEDATo/BQsCAQgiFBAyJQIEDg2IMggByV8XjmARMQeDLYEWAQSWFphsg0OBcEA X-IronPort-AV: E=Sophos;i="5.01,611,1400025600"; d="scan'208";a="338105664" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jul 2014 13:03:57 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s66D3vvc020551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Jul 2014 13:03:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Sun, 6 Jul 2014 08:03:57 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAAtFWXAAAHKr7g///9lQD//1TMQIACjhEA//5nzTA= Date: Sun, 6 Jul 2014 13:03:56 +0000 Message-ID: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/O7Kpk9l6XWAgnmivFMJeIEonWrQ Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 13:04:01 -0000 Hi Sam, Let me cut most of our discussions, and try to bring this to closure. If you feel that we should continue our discussion, feel free to revive the= m. > As you can see, my argument, just like every other argument made at IETF = is, > why one more extra option, when it already works, albeit with extra > request. Also this requires all nodes to be upgraded to supported to full= y > functional as you describe. The extra cost is not worth it, when you coul= d > achieve the same with small cost in workflow but no upgrade or > protocol/TLV change. I agree that it is important to ask "why is this required". And this is whe= re we seem to have different scale to measure (at least this for this one). As for this extension, it's not just "extra request" that I'm concerned abo= ut, but they are: 1. Extra request =3D more system/network resources. 2. Users/tools requiring to put up with timeout from many LSRs =3D bad usab= ility. 3. Users/tools requiring to know which Reply Mode timed out and what to use= next =3D bad usability. 4. Every product/vendor having [more] vastly different behavior =3D bad usa= bility. So to me, it's worth the effort to do something about it. If above results = in "not worth it" on your scale, then that's that. We can conclude that our= scales are different, but that's IETF :) As always, thanks for the discussions Sam. Despite the fact we couldn't converge, I do appreciate your time and effort= . Thanks! -Nobo From nobody Sun Jul 6 13:14:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76ED1A0A95 for ; Sun, 6 Jul 2014 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G970lSfwGT-T for ; Sun, 6 Jul 2014 13:14:13 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707B21A0A8C for ; Sun, 6 Jul 2014 13:14:13 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so4267103pab.18 for ; Sun, 06 Jul 2014 13:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bt9Lvrn/qldnSXujZhZ39s6r6KAZ911GeYHQOfZmduo=; b=uCo75YKkRIv6ArDzCsCVOKu1GJSQv1xEOgYl/xHCB9tvCRFxqjpHHpZ2hFwvg0SGkT lToQy3Ou0xfFWGfGRhgzpIie1zrOVZJU1jihhAnJ3uSgKKMwRT4RmZFZ5EJG9nDJ968u zRnkqkVirALDfJSW0c3kK1aMUUo6se2x97s5ooqeSsuzkg7SOWShF6Iasc8NOosS95ex 5JibYnJ6t8kVYS9S3Y0hKVuKnO8QOO4wk3/bwzuabfz9e7eN0O/qoLnZCDbjfc9tlWNY ABYTAxs7ffgwKjGBE5Tg9Vm97/ENOvRheP5waSk9glwFQ9KzStFG6hN+OjeQWmFiuifs ivVQ== X-Received: by 10.70.92.9 with SMTP id ci9mr23940468pdb.24.1404677653104; Sun, 06 Jul 2014 13:14:13 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id g6sm182432827pat.2.2014.07.06.13.14.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Jul 2014 13:14:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Sun, 6 Jul 2014 13:14:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3C2z_JvKt5ikd0pGbkZ7wKk1cyw Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 20:14:18 -0000 Hi Nobo, Not sure if the email you send was with reply mode 1 or with new TLV :D.=20= Sending my response as top post. :D I do not think we could converge on efficiency or which is bad/good, = neither would I like to debate about bad usability. My previous questions remain unanswered. Will leave it to you and = co-authors, whether to respond or not. As far as my concerns regarding the ID is concerned, would be good to = illustrate with example lsp's, be it TP or LDP or something else, it is = solving. And quantifying the solution to show it really is required that = existing solutions could not solve it, would help WG. At this point of time, I could not change my conclusion. Sorry. -sam On Jul 6, 2014, at 6:03 AM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 > Let me cut most of our discussions, and try to bring this to closure. > If you feel that we should continue our discussion, feel free to = revive them. >=20 >> As you can see, my argument, just like every other argument made at = IETF is, >> why one more extra option, when it already works, albeit with extra >> request. Also this requires all nodes to be upgraded to supported to = fully >> functional as you describe. The extra cost is not worth it, when you = could >> achieve the same with small cost in workflow but no upgrade or >> protocol/TLV change. >=20 > I agree that it is important to ask "why is this required". And this = is where we seem to have different scale to measure (at least this for = this one). >=20 > As for this extension, it's not just "extra request" that I'm = concerned about, but they are: >=20 > 1. Extra request =3D more system/network resources. > 2. Users/tools requiring to put up with timeout from many LSRs =3D bad = usability. > 3. Users/tools requiring to know which Reply Mode timed out and what = to use next =3D bad usability. > 4. Every product/vendor having [more] vastly different behavior =3D = bad usability. >=20 > So to me, it's worth the effort to do something about it. If above = results in "not worth it" on your scale, then that's that. We can = conclude that our scales are different, but that's IETF :) >=20 > As always, thanks for the discussions Sam. > Despite the fact we couldn't converge, I do appreciate your time and = effort. >=20 > Thanks! >=20 > -Nobo >=20 From nobody Sun Jul 6 13:21:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604F51A0A9E for ; Sun, 6 Jul 2014 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoFDvO-LVIfq for ; Sun, 6 Jul 2014 13:21:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350451A0A9C for ; Sun, 6 Jul 2014 13:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=613; q=dns/txt; s=iport; t=1404678084; x=1405887684; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=alr9WYQ4Uoj0WRGbnN6DqQmjUczLMwdAltP+88ijFLo=; b=V9WRqI+bt9kIr4FEe3GjmP69BspaVcB5dt7/wR44LiQNweCX8Z/KLfTf yH9cAJ66xurfFaW6074y8GGrGV7+SuSUcqIjjTYPIedB1VltABQdGIEfz dIT8pnoXBCZM/BwqXTKzHJ0XYU1RaBWWfHO229S47rXYZLpZuC7DHBjkN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAAKvuVOtJA2H/2dsb2JhbABagmokgSzGLAGBDBZ1hAMBAQEDATo/BQsCAQgiFBAyJQIEDg0TiB8IAck+F45AEQEfMQeDLYEWAQSWXJgmg0OBbgcCFyI X-IronPort-AV: E=Sophos;i="5.01,613,1400025600"; d="scan'208";a="338072732" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jul 2014 20:21:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s66KLNKZ014967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Jul 2014 20:21:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 6 Jul 2014 15:21:23 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: Ac+Kbg0JI45wiuB+QkmRpWOTfjvnXAAAEROQAn/CxAAAtFWXAAAHKr7g///9lQD//1TMQIACjhEA//5nzTCABAKJgIAAUzVQ Date: Sun, 6 Jul 2014 20:21:22 +0000 Message-ID: References: <4A79394211F1AF4EB57D998426C9340D946A9035@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340D946C86F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <9EB527EE-2C56-405D-9340-88A3184A48CA@gmail.com> <3ECD02EE-71E6-4AC5-BBB5-CC0C354219B0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.185] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/NvjyB2QXpa8BpTPgc50X9wEGp_M Cc: "mpls@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , Ross Callon , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "jeremy.whittaker@verizon.com" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 20:21:25 -0000 Hi Sam, > Not sure if the email you send was with reply mode 1 or with new TLV :D. It was actually a Reply Mode Order TLV containing [new TLV, reply mode 1], = so you did the right thing :) > As far as my concerns regarding the ID is concerned, would be good to > illustrate with example lsp's, be it TP or LDP or something else, it is s= olving. > And quantifying the solution to show it really is required that existing > solutions could not solve it, would help WG. That will indeed be a good addition to this document. We will add texts for= this in the next revision. Thanks! -Nobo From nobody Mon Jul 7 05:59:55 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00BF1A0008 for ; Mon, 7 Jul 2014 05:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhZN41-sHFPp for ; Mon, 7 Jul 2014 05:59:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423301A0016 for ; Mon, 7 Jul 2014 05:59:38 -0700 (PDT) Received: from BL2PR05MB066.namprd05.prod.outlook.com (10.255.232.19) by BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 7 Jul 2014 12:59:37 +0000 Received: from BL2PR05MB066.namprd05.prod.outlook.com ([169.254.1.235]) by BL2PR05MB066.namprd05.prod.outlook.com ([169.254.1.235]) with mapi id 15.00.0980.000; Mon, 7 Jul 2014 12:59:36 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Nobo Akiya (nobo)" , Ross Callon , "Aissaoui, Mustapha (Mustapha)" , "jeremy.whittaker@verizon.com" , "Harish Sitaraman" , Kapil Arora Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPlZCybt2Cc0J7zEWW/WrS22Yy6JuUmreA Date: Mon, 7 Jul 2014 12:59:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(199002)(189002)(51704005)(41574002)(164054003)(77096002)(85306003)(19580395003)(80022001)(64706001)(76482001)(83322001)(66066001)(19580405001)(21056001)(99286002)(74502001)(105586002)(106116001)(81542001)(4396001)(107046002)(106356001)(101416001)(86362001)(50986999)(81342001)(87936001)(54356999)(77982001)(33646001)(99396002)(76176999)(20776003)(46102001)(2656002)(85852003)(76576001)(79102001)(83072002)(74316001)(95666004)(55754002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB066.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BPG4KR-HHvPamymuajkq4Ch_-u0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:59:48 -0000 Nobo, Sorry for the late response. Holidays. I am not sure if it is necessary to have the flexibility of (2), but it is = always good to have the flexibility if it does not introduce much complexit= y. If we allow multiple mode 5, then (2) is achieved. I'll leave this up to you. Jeffrey > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Tuesday, July 01, 2014 8:58 PM > To: Jeffrey (Zhaohui) Zhang; Ross Callon; Aissaoui, Mustapha (Mustapha); > jeremy.whittaker@verizon.com; Harish Sitaraman; Kapil Arora > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-akiya-mpls-lsp- > ping-reply-mode-simple@tools.ietf.org > Subject: RE: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply- > mode-simple-02 >=20 > Hi Jeffrey, >=20 > Thank you for reviewing this document. >=20 > > I do have one suggestion - could we allow multiple return paths to be > > specified via multiple "Replay Mode 5" in the new "Reply Mode Order > TLV" > > and multiple Reply Path TLVs (currently it is not allowed). >=20 > Interesting, I do find what you suggested to be useful. I went back to > RFC7110 and read up on the Reply Path TLV definition. The TLV can > contain zero, one or more FECs. >=20 > Reply Path: It is used to describe the return path that an echo > reply will be send along. It is variable in length and can > contain zero, one or more Target FEC sub-TLVs [RFC4379]. >=20 > So it appears that "Reply Mode 5" can be one of the entries in the > "Reply Mode Order TLV", and "Reply Path TLV" can contain multiple FECs. >=20 > (1) What is possible as is: > Pref#1: Reply Mode 4 Reply via application level control channel > Pref#2a: Reply Mode 5 Reply via Specified Path -> First FEC listed > Pref#2b: Reply Mode 5 Reply via Specified Path -> Second FEC listed > Pref#3: Reply Mode 2 Reply via an IPv4/IPv6 UDP packet >=20 > (2) What is not possible as is: > Pref#1: Reply Mode 4 Reply via application level control channel > Pref#2: Reply Mode 5 Reply via Specified Path -> First FEC listed > Pref#3: Reply Mode 2 Reply via an IPv4/IPv6 UDP packet > Pref#4: Reply Mode 5 Reply via Specified Path -> Second FEC listed >=20 > Granularity of really mixing up Reply Modes and return FECs like (2) > cannot be accomplished, but I'm not sure if we need such granularity and > I believe (1) is reasonable. If you are ok with this, then I think it's > worth adding texts to describe this usages. Do let us know you > preference. >=20 > Thanks! >=20 > -Nobo >=20 >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeffrey > (Zhaohui) > > Zhang > > Sent: Tuesday, July 01, 2014 12:08 PM > > To: Ross Callon; Aissaoui, Mustapha (Mustapha); > > jeremy.whittaker@verizon.com; Harish Sitaraman; Kapil Arora > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-akiya-mpls-lsp- > ping- > > reply-mode-simple@tools.ietf.org > > Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply- > > mode-simple-02 > > > > I have reviewed the draft and believe it is ready for WG adoption > > consideration. > > > > I do have one suggestion - could we allow multiple return paths to be > > specified via multiple "Replay Mode 5" in the new "Reply Mode Order > TLV" > > and multiple Reply Path TLVs (currently it is not allowed). > > > > Thanks. > > Jeffrey > > _____________________________________________ > > From: Ross Callon > > Sent: Tuesday, June 17, 2014 4:52 PM > > To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); > > jeremy.whittaker@verizon.com > > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; mpls- > > chairs@tools.ietf.org; Martin Vigoureux > > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > simple- > > 02 > > > > > > Jeff, Mustapha, Jeremy; > > > > You have been selected as MPLS Review team reviewers for draft-akiya- > > mpls-lsp-ping-reply-mode-simple-02. > > > > Note to authors: You have been CC'd on this email so that you can know > that > > this review is going on. However, please do not review your own > document. > > Also please don't update the draft while the reviews are in progress > (we > > would like the reviewers to all review the same version). > > > > Reviews should comment on whether the document is coherent, is it > useful > > (ie, is it likely to be actually useful in operational networks), and > is the > > document technically sound?=A0 Also, is the text and grammar > understandable > > (it doesn't need to be perfect at this point, but should be reasonably > clear). > > We are interested in knowing whether the document is ready to be > > considered for WG adoption (ie, it doesn't have to be perfect at this > point, > > but should be a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and WG > > secretary, and CC'd to the MPLS WG email list. If necessary, Comments > may > > be sent privately to only the WG chairs. > > > > Are you able to review this draft by July 2, 2014? > > > > Thanks, Ross > > (as MPLS WG chair) > > From nobody Mon Jul 7 06:59:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC01A006D for ; Mon, 7 Jul 2014 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZXeEq6ejVMR for ; Mon, 7 Jul 2014 06:59:24 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CA11A00E6 for ; Mon, 7 Jul 2014 06:59:23 -0700 (PDT) Received: from [192.168.0.111] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 19EC81802B24; Mon, 7 Jul 2014 15:59:21 +0200 (CEST) Message-ID: <53BAA7BA.2060903@pi.nu> Date: Mon, 07 Jul 2014 15:59:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/INX0GVGY4wxxduLBNMYdZFsMbaw Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Subject: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:59:26 -0000 Working Group, The authors of draft-bryant-mpls-oam-udp-return has informed us that the draft is ready to be polled to see if we have consensus to make it a working group document. This mail starts a two week adoption poll. We have not yet done the IPR poll, it will be done in parallel to the adoption poll. There are no IPR disclosed against this draft. Please send your comments to the mpls working group mailing list (mpls@ietf.org) This adoption poll ends Juli 21, 2014! /Loa for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jul 7 07:12:53 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DB1A01A8 for ; Mon, 7 Jul 2014 07:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dPmyIZun6El for ; Mon, 7 Jul 2014 07:12:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664821A0163 for ; Mon, 7 Jul 2014 07:12:50 -0700 (PDT) Received: from [192.168.0.111] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1E85C1802B24; Mon, 7 Jul 2014 16:12:49 +0200 (CEST) Message-ID: <53BAAAE2.2020206@pi.nu> Date: Mon, 07 Jul 2014 16:12:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Si0waLluoFei1yGP0k--52NHEt0 Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 14:12:51 -0000 Working Group, This is to start an IPR poll on draft-bryant-mpls-oam-udp-return. Are you aware of any IPR that applies to draft-bryant-mpls-oam-udp-return? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are no IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jul 7 08:23:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CBB1A0166 for ; Mon, 7 Jul 2014 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQqJmMYjWWe4 for ; Mon, 7 Jul 2014 08:23:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B2E1A0066 for ; Mon, 7 Jul 2014 08:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13904; q=dns/txt; s=iport; t=1404746631; x=1405956231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=57Y6dpb2SiDisRtT7J+eHgPC2P+399oMhlbpflnL4Us=; b=YZkelMNvOTo51u0sdtX7Ko1o3GRhNfob2aJ6IdYRgRkEV9S4Y9C014r5 /igF+rI306QW9U6x5jafvO4c/leL56k+I6+DDae5sU+jHogA/r1hx9Gqk 2hkTD8vGzp+hPTrPru9Z7QC3BdDkHBXiwD89IgZujh/oo5OvyX2tapFCL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAOu6ulOtJV2S/2dsb2JhbABQCoMOUk0NvneHRQGBFhZ1hAMBAQEEAQEBawkCDAQCAQgRBAEBAScHJwsUCQgCBA4FCYg5DcoJF45GKQgrBwIEhD0FiheQX4FIkkSDQ4FwJBw X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="338190877" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2014 15:23:50 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s67FNoNG024492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jul 2014 15:23:50 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.65]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 10:23:49 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Nobo Akiya (nobo)" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgAAGuSCAAWXvgIAMTauggBet8gA= Date: Mon, 7 Jul 2014 15:23:49 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.146.59] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <77EED41B03345348AAD01A10848EBD0D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/OSk1871qbbYhkx1bOWil7d9KbO4 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:23:54 -0000 Hi Nobo, Apologies for the delay. Please see below: >Hi Nagendra, > >> -----Original Message----- >> From: Nagendra Kumar Nainar (naikumar) >> Sent: Saturday, June 14, 2014 1:54 PM >> To: Nobo Akiya (nobo) >> Subject: Re: New Version Notification for draft-akiya-mpls-lsp-ping-lag- >> multipath-00.txt >>=20 >> Hi Nobo, >>=20 >> As usual, interesting draft. Please see below for initial comments, > >Thank you for comments, and thank you for agreeing to allow me to include >the MPLS WG in this response. > >I'm glad you found this document to be interesting. Although it became a >bit more complicated that I was originally hoping. However, this >extension add a great value to a tool which can be part of the something >larger to "fight" the traffic black hole happening on MPLS networks :) >=20 >>=20 >> From section 3, It appears that responder MUST set the LAG Info TLV. Is >>it the >> case even if the downstream is not LAG?. Or did you meant that if the >> responder have LAG based donwstream interface, then it MUST include the >> TLV?. > >First bullet in the last portion of the Section 3 was exactly to explain >why this is a MUST, but clearly additional text will be helpful. How >about we update the bullet: > >[old] > o Identify whether responder LSR understands this mechanism. > >[new] > o Mandating the responder to always add the LAG Interface Info TLV > in the MPLS echo reply allows the initiating LSR to identify > whether responder LSR understands this mechanism. I am trying to understand the behavior when a responder wants back to echo received with LAG Interface Info TLV. In figure 1, assume there is one more node connected to E (say F) and A wants to trace the path from A to F (via A-B-LAG-C-E-F). When C receives thhe echo with LAG interface Info TLV, since it doenst have any upstream/downstream LAG interface, will it still include the TLV in reply?. If so, is it like it unset both U/D bit?. > >>=20 >>=20 >> In Section, I am trying to understand what does the below means, >>=20 >> "All fields and Sub-TLVs, except for Multipath Data Sub-TLV and >> Interface Index Sub-TLV, are set/added to DDMAP to describe >> this LAG interface, as per [RFC6424]. >> " >>=20 >> The above statement followed by statement to add "Interface Index Sub- >> TLV" >> appears to be confusing. > >I see. Perhaps re-wording it can help clarify things. How about something >like this? > >[old] > * All fields and Sub-TLVs, except for Multipath Data Sub-TLV and > Interface Index Sub-TLV, are set/added to DDMAP to describe > this LAG interface, as per [RFC6424]. > >[new] > * In the DDMAP, Multipath Data Sub-TLV and Interface Index Sub- > TLV are to describe each LAG member link. All other fields of > the DDMAP are to describe the LAG interface. Sounds good. > >>=20 >>=20 >> In section 3, the below 2 statements appears to be redundant. Do we >>really >> need both?. >>=20 >> "* For each LAG member link of this LAG interface: >>=20 >> + MUST add Interface Index Sub-TLV (described in Section 7) >> with LAG Member Link Indicator flag set in Interface Index >> Flags, describing this LAG member link. >>=20 >> + MUST add Multipath Data Sub-TLV for this LAG member link, if >> received DDMAP requested multipath information. >>=20 >> Each LAG member link is described with Interface Index Sub-TLV and >> conditionally with Multipath Data Sub-TLV (if multipath information >> is requested). " > >True. Let me re-word this one too. > >[old] > Each LAG member link is described with Interface Index Sub-TLV and > conditionally with Multipath Data Sub-TLV (if multipath information > is requested). If both Sub-TLVs are placed in the DDMAP to describe > a LAG member link, Interface Index Sub-TLV MUST be added first with > Multipath Data Sub-TLV immediately following. > >[new] > When both the Interface Index Sub-TLV and the Multipath Data Sub-TLV > is placed in the DDMAP to describe a LAG member link, Interface Index > Sub-TLV MUST be added first with Multipath Data Sub-TLV immediately > following. Sounds good. > >>=20 >>=20 >> Section 4 says the inclusion of Detailed interface TLV is a MUST while >> section 8 sys it is a MAY statement as below, >>=20 >> section 4: >> " >> Responder LSR MUST: >>=20 >> o Add LAG Interface Info TLV in the MPLS echo reply to provide >> acknowledgement back to the initiator. Upstream LAG Info >> Accommodation flag MUST be set in LAG Interface Info Flags. >>=20 >> o Add the Detailed Interface and Label Stack TLV (described in >> Section 8) in the MPLS echo reply. >> " >>=20 >> section 8: >> "The Detailed Interface and Label Stack object is a TLV that MAY be >> included in a MPLS echo reply message to report the interface on >> which the MPLS echo request message was received and the label stack >> that was on the packet when it was received. A responder LSR MUST >> NOT insert more than one instance of this TLV. " >>=20 > >Right, perhaps above snippet being preceded by the initiating LSR sending >the MPLS echo request with DS Flags I bit set is not sufficient to elude >that responder is functioning with an assumption that it needs to include >interface/label-stack TLV. Let me change some texts: > >[old] > o Add the Detailed Interface and Label Stack TLV (described in > Section 8) in the MPLS echo reply. > > o Add the Incoming Interface Index Sub-TLV (described in > Section 8.1.2) for LAG interfaces. The LAG Member Link Indicator > flag MUST be set in Interface Index Flags, and the incoming > Interface Index set to LAG member link which received the MPLS > echo request. > >[new] > o When the received DDMAP had DS Flags I set, add the Detailed > Interface and Label Stack TLV (described in Section 8) in the MPLS > echo reply. > > o When the received DDMAP had DS Flags I set, add the Incoming > Interface Index Sub-TLV (described in Section 8.1.2) for LAG > interfaces. The LAG Member Link Indicator flag MUST be set in > Interface Index Flags, and the incoming Interface Index set to LAG > member link which received the MPLS echo request. Ok. > >>=20 >>=20 >> Section 7 specifies as below, >> "The Interface Index Sub-TLV describes the index assigned by the >> upstream LSR to the interface." >>=20 >> Can you also point some reference to what type of index is it?. Is it >> something assigned and advertised by LAG protocol like LACP or PAGP?. > >It's a locally allocated persistent index for local interfaces. It may or >may not be advertised, and that's not really important for this context. >We are just interested in getting a unique value (local to that node) >that identifies a specific interface. I could add more texts, but the >description on this sub-TLV was mostly ported from RFC4379. I think it's >ok as is. Ok. So the responder will include the locally assigned index value (of the egress interface) to this Sub-TLV and reply back. So should we modify the below statement?, "The Interface Index Sub-TLV describes the index assigned by the upstream LSR to the interface.=B2 I think it is not the upstream LSR to the interface right?. > >>=20 >> In association to above, Section 4 states the below, >>=20 >> "Note that defined procedures will provide a deterministic result for >> LAG interfaces that are back-to-back connected between routers (i.e. >> no L2 switch in between). If there is a L2 switch between LSR at >> TTL=3Dn and LSR at TTL=3Dn+1, there is no guarantee that traversal of >> every LAG member link at TTL=3Dn will result in reaching different >> interface index at TTL=3Dn+1." >>=20 >> When there is L2 switch(es) in between, the LAG termination/negotiation >> wil be between the LSR and L2 switch and so we may need some way to >> exchange the Interface Index for each LAG member via L2 switch to be >> exchanged between the LSRs. I am not aware of such exchange. If I am >> missing something, I think it is worth referring the same for clarity :) > >That is exactly why L2-in-between is outside the scope of this document >:) Appendix A describes various flavors and why it is complicated to >extend support for those flavors. Ok. > >>=20 >> Does the below sounds like a (direct) SHOULD statement? >>=20 >> "If the responder LSR is able to accommodate this request, >> then the LAG Interface Info object MUST be included in the MPLS echo >> reply message." >>=20 >> In the below topology, >>=20 >> +-------+ >> | | >> A-------B=3D=3D=3D=3D=3D=3D=3DC-------E >> | | | >> +-------D-------G >>=20 >> Assume A is validating all ECMP paths from A to G. Assume the metric >>from >> B to D is 2 and rest all link are 1. So it will be >>=20 >> A-B-LAG-C-E-G >> A-B-LAG-C-D-G >> A-B-D-G >>=20 >> Assume the list of multipath data is (1-10) >>=20 >> Now B will reply as below, >>=20 >> (1,2,3) - {Link1, Downstream:C} >> (4,5,6) - {Link2 Downstream:C} >> (7,8,9,10) - {LinkBC, Downstream:D} >>=20 >> A will then send 2 request as below: >>=20 >> Echo1 (to C) - (multipath:1,2,3,4,5,6), >> Echo2 (to D) - (multipath:7,8,9,10) >>=20 >> C will reply back with >>=20 >> (1,2,3) - {LinkCE, Downstream E} >> (4,5,6) - {LinkCD, Downstream D} >>=20 >> So we dont have anything common between Link2 of LAG and downtream E. >> Similarly we dont have anyhting common between Link1 of LAG and >> downstream D (from C). I think we need the downstream node of LAG to >> reply back with multipath info for each downstream from each LAG range. >> Any thoughts?. > >The main problem with above example is that the range of multipath info >is too small, thus you ran out of intersect in the downstream. >Additionally, if I was to implement this, then I would not carry over >treating each LAG member link separately in the LSP Tree Trace >operations, once TTL=3Dn+1 is reached. Once LAG merges to a same downstrea= m >node, then I would aggregate the result and move forward in the >downstream (i.e. treat the LAG as one logical interface). Ok. Let me check this. Thanks, Nagendra > >Thanks! > >-Nobo > >>=20 >> Thanks, >> Nagendra >>=20 >>=20 >>=20 >>=20 >> On 6/13/14, 5:33 PM, "Nobo Akiya (nobo)" wrote: >>=20 >> >FYI, new LSP Ping extension draft. >> > >> >> -----Original Message----- >> >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya >> >> (nobo) >> >> Sent: Friday, June 13, 2014 5:15 PM >> >> To: mpls@ietf.org >> >> Subject: [mpls] FW: New Version Notification for >> >>draft-akiya-mpls-lsp-ping- >> >> lag-multipath-00.txt >> >> >> >> Dear MPLS WG, >> >> >> >> On MPLS data plane, one aspect which OAM is blind to traffic black >> >>holing is when LSPs are traversing over LAG interfaces. We would like >> >>to propose an extension to RFC4379 to provide the tool an ability to >> >>discover and traverse LAG members. >> >> >> >> It will be very helpful if you could review this document, provide >> >>comments and help us standardize this extension. >> >> >> >> Thanks! >> >> >> >> -Nobo, on behalf of authors >> >> >> >> > -----Original Message----- >> >> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >> > Sent: Friday, June 13, 2014 5:04 PM >> >> > To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow); >> >> > George Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno >> >> > Decraene; Nobo Akiya (nobo); John Drake; Stephane Litkowski >> >> > Subject: New Version Notification for >> >> > draft-akiya-mpls-lsp-ping-lag- multipath-00.txt >> >> > >> >> > >> >> > A new version of I-D, >> >> > draft-akiya-mpls-lsp-ping-lag-multipath-00.txt >> >> > has been successfully submitted by Nobo Akiya and posted to the >> >> > IETF repository. >> >> > >> >> > Name: draft-akiya-mpls-lsp-ping-lag-multipath >> >> > Revision: 00 >> >> > Title: Label Switched Path (LSP) Ping/Trace Multipath >> Support for >> >> > Link Aggregation Group (LAG) Interfaces >> >> > Document date: 2014-06-13 >> >> > Group: Individual Submission >> >> > Pages: 18 >> >> > URL: >> >>http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping- >> >> > lag-multipath-00.txt >> >> > Status: >> >>https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag- >> >> > multipath/ >> >> > Htmlized: >> >>http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag- >> >> > multipath-00 >> >> > >> >> > >> >> > Abstract: >> >> > This document defines an extension to the Multiprotocol Label >> >> > Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute >>to >> >> > describe Multipath Information for Link Aggregation (LAG) member >> >> > links separately, thus allowing MPLS LSP Ping and Traceroute to >> >> > discover and exercise specific paths of layer 2 Equal-Cost >> >>Multipath >> >> > (ECMP) over LAG interfaces. >> >> > >> >> > This document updates RFC4379 and RFC6424. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Please note that it may take a couple of minutes from the time of >> >> > submission until the htmlized version and diff are available at >> >> tools.ietf.org. >> >> > >> >> > The IETF Secretariat >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls > From nobody Mon Jul 7 08:27:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5184D1A0104 for ; Mon, 7 Jul 2014 08:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsIsXhuhNdti for ; Mon, 7 Jul 2014 08:26:59 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF091A01EA for ; Mon, 7 Jul 2014 08:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1208; q=dns/txt; s=iport; t=1404746818; x=1405956418; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1il5aMlkRdE0zRtAXnxYzGHN+WZD3U8nkn6FNY8FczY=; b=U54W2vvRWCsKPeNHeyTp2cYfjsREyCfHzgeDfRT1TEGa7tUiCc3JRUjc oXTedvz2cdY8RPEiiMRQLOl0v4jhh1IYKTLRgAij+cQqlAPycTupPrY07 91WV6EvqaxRbFcyOHM+R0njVerH5qpOgkfk8l3+GWRUQ9LZSFx+sd06qA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEABS8ulOtJssW/2dsb2JhbABag2DHFgGBLXWEAwEBAQQ4NgYEARALGAkWDwkDAgECAUUGAQwBBwEBiD4NtyGSZxeOQBEBUAeEQwEEmnaUDINEa4EL X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="106051591" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 07 Jul 2014 15:26:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s67FQuBD001063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 15:26:56 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s67FQsMk017305; Mon, 7 Jul 2014 16:26:54 +0100 (BST) Message-ID: <53BABC3E.6020702@cisco.com> Date: Mon, 07 Jul 2014 16:26:54 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" References: <53BAAAE2.2020206@pi.nu> In-Reply-To: <53BAAAE2.2020206@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/C2s-ZBA1JZfCP9EeY8W2TqRLM3I Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 15:27:00 -0000 I am not aware of any relevant IPR. Stewart On 07/07/2014 15:12, Loa Andersson wrote: > Working Group, > > This is to start an IPR poll on draft-bryant-mpls-oam-udp-return. > > Are you aware of any IPR that applies to > draft-bryant-mpls-oam-udp-return? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are no IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Mon Jul 7 08:33:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D7D1A0303 for ; Mon, 7 Jul 2014 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJQuXz4l9Wpt for ; Mon, 7 Jul 2014 08:33:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AD71A01EA for ; Mon, 7 Jul 2014 08:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2006; q=dns/txt; s=iport; t=1404747235; x=1405956835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MiFb+8oabvYln1GnKpJUSi+diTp0HF6wzwoG7/qWwPM=; b=bEipeY63GGFdbQdPguzJ+5nPIbd1o0EoAC0I+poD/cPTucnrAYCn7jhr 93I56HvRK3cvOrpS/UsZ2wIcVOARMCfbMC7lki2VjIbJHhnzKS70/HsSx DDIOfm6ELSzEJWt9l2FsIHnoznwFJvdJuzCsHoYqpY5Gk1pMZ01n9r5Rd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIm9ulOtJA2G/2dsb2JhbABagw5SWsY8AYEXFnWEAwEBAQQ6NAYFDAQCAQgRBAEBAQoUEDIdCAIEAQ0FCIg6DcoLF45AEQEfDyICBQaDJ4EWBa8Cg0NsgQs5 X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="338194638" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2014 15:33:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s67FXrsw004470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 15:33:53 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 10:33:53 -0500 From: "Siva Sivabalan (msiva)" To: "Sagar Soni (sagsoni)" , "Stewart Bryant (stbryant)" , Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPme2LE+xfcyNUEkCclZVctJtRGZuVD7oAgAABlQD//6xlIA== Date: Mon, 7 Jul 2014 15:33:52 +0000 Message-ID: References: <53BAAAE2.2020206@pi.nu> <53BABC3E.6020702@cisco.com> <5A656B747213994CB6A9D09D7B4AA9C519A4DD3A@xmb-rcd-x13.cisco.com> In-Reply-To: <5A656B747213994CB6A9D09D7B4AA9C519A4DD3A@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zc_whdSQF6mM6gKXEWxQ6hIZUis Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:33:55 -0000 I am not aware of any IPR related to this draft. Thanks, Siva -----Original Message----- From: Sagar Soni (sagsoni)=20 Sent: Monday, July 07, 2014 11:33 AM To: Stewart Bryant (stbryant); Loa Andersson; mpls@ietf.org Cc: draft-bryant-mpls-oam-udp-return@tools.ietf.org; mpls-chairs@tools.ietf= .org; VIGOUREUX, MARTIN (MARTIN) Subject: RE: IPR poll on draft-bryant-mpls-oam-udp-return I am also not aware of IPR related to this draft. Thanks, Sagar -----Original Message----- From: Stewart Bryant (stbryant) Sent: Monday, July 07, 2014 11:27 AM To: Loa Andersson; mpls@ietf.org Cc: draft-bryant-mpls-oam-udp-return@tools.ietf.org; mpls-chairs@tools.ietf= .org; VIGOUREUX, MARTIN (MARTIN) Subject: Re: IPR poll on draft-bryant-mpls-oam-udp-return I am not aware of any relevant IPR. Stewart On 07/07/2014 15:12, Loa Andersson wrote: > Working Group, > > This is to start an IPR poll on draft-bryant-mpls-oam-udp-return. > > Are you aware of any IPR that applies to=20 > draft-bryant-mpls-oam-udp-return? > > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are no IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond=20 > to this email regardless of whether or not you are aware of any=20 > relevant IPR. *The response needs to be sent to the MPLS wg mailing > list.* The document will not advance to the next stage until a=20 > response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author=20 > or contributor, then please explicitly respond only if you are aware=20 > of any IPR that has not yet been disclosed in conformance with IETF rules= . > > Thanks, Loa > (as MPLS WG co-chair) -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Mon Jul 7 11:03:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1661A0535 for ; Mon, 7 Jul 2014 11:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W-8xdglZUjw for ; Mon, 7 Jul 2014 11:03:27 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC0A1A03C0 for ; Mon, 7 Jul 2014 11:03:27 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so4114449qcx.27 for ; Mon, 07 Jul 2014 11:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zoX9rgk7afGZUZGA4s0b4/ps+STHfvUXLnSuo1mba0A=; b=PWbhNJjPrnOuB/OgRbrggXdWIcQApscduRkwE7j9wDcuZhl55T/YGVqRAY5+jB60rM EcqT1ldEbDlWoA+Py6D81CAzPIuqmZvFxMIeHHZZi+nhDWiYw+Jt2I/U4iDL4/N+MU6Q vFfE/krRXUPkv0IhUKO1mIMwEVtDkOxevdoZpAyOlPVyBp2fJLW6Tu8fFasArw24kA9q fGO9WxlMC5xLfsntMaL5ByRJElLH5SVztk9ck32cr1L6Tenz8KJfaSbzoeWzEArEkG8T oFDrTv+Bg/mAUA7CfAbZPQBcAOpS9fB24mSzypMP67mXqDrU4pxjOcUh54gwJmHIsL86 A5kA== X-Received: by 10.140.34.201 with SMTP id l67mr6132203qgl.61.1404756206735; Mon, 07 Jul 2014 11:03:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.47.150 with HTTP; Mon, 7 Jul 2014 11:03:06 -0700 (PDT) In-Reply-To: <53BAA7BA.2060903@pi.nu> References: <53BAA7BA.2060903@pi.nu> From: "Andrew G. Malis" Date: Mon, 7 Jul 2014 14:03:06 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c0a466b2d7f604fd9e4ad8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/C5yfdpAsu2-VFzDSyKwyoPH7f5A Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:03:30 -0000 --001a11c0a466b2d7f604fd9e4ad8 Content-Type: text/plain; charset=UTF-8 Loa, My positive opinion on this draft has not changed since my previous email on it. I support it as a WG document. Cheers, Andy On Mon, Jul 7, 2014 at 9:59 AM, Loa Andersson wrote: > Working Group, > > > The authors of draft-bryant-mpls-oam-udp-return has informed us > that the draft is ready to be polled to see if we have consensus > to make it a working group document. > > This mail starts a two week adoption poll. > > We have not yet done the IPR poll, it will be done in parallel to the > adoption poll. > > There are no IPR disclosed against this draft. > > Please send your comments to the mpls working group mailing list > (mpls@ietf.org) > > This adoption poll ends Juli 21, 2014! > > /Loa > for the mpls wg co-chairs > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c0a466b2d7f604fd9e4ad8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

My positive opinion on this draft = has not changed since my previous email on it. I support it as a WG documen= t.

Cheers,
Andy


On Mon, Jul 7, 2014 at 9:59 AM, Loa Ande= rsson <= loa@pi.nu> wrote:
Working Group,


The authors of draft-bryant-mpls-oam-udp-return has informed us
that the draft is ready to be polled to see if we have consensus
to make it a working group document.

This mail starts a two week adoption poll.

We have not yet done the IPR poll, it will be done in parallel to the
adoption poll.

There are no IPR disclosed against this draft.

Please send your comments to the mpls working group mailing list
(mpls@ietf.org)

This adoption poll ends Juli 21, 2014!

/Loa
for the mpls wg co-chairs
--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

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

--001a11c0a466b2d7f604fd9e4ad8-- From nobody Mon Jul 7 14:29:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FCF1B2938; Mon, 7 Jul 2014 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OZBObihcAJZ; Mon, 7 Jul 2014 14:29:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5110E1B2933; Mon, 7 Jul 2014 14:29:27 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-c7-53babf0dbb87 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.CF.05330.D0FBAB35; Mon, 7 Jul 2014 17:38:53 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 7 Jul 2014 17:29:26 -0400 From: Gregory Mirsky To: "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Thread-Topic: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Index: AQHPl4mFNgiJ7lBGzEawoL9A5AVhppuQCexwgAUYmzA= Date: Mon, 7 Jul 2014 21:29:25 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E7AC7@eusaamb103.ericsson.se> References: <20140704131127.29231.56989.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPiC7v/l3BBpc6DC1uLV3JavH5zzZG i5kfNjE7MHtM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBl3T/oVtMRUXJyzhbWB8UBkFyMn h4SAicTDB9PZIGwxiQv31gPZXBxCAkcZJRZc3sgO4SxjlJg/dQJYFZuAkcSLjT1ACQ4OEYE0 iaddsiAms4CyxKm7MiAVwgKxEk1/L7CD2CICcRKrXnxmgbCtJK7O28EIYrMIqEi0/u9mArF5 BXwl2q+9ZIRY1cIosfBNA9gqTqDE1iUrmUFsRqDjvp9aA9bALCAucevJfCaIowUkluw5zwxh i0q8fPyPFcJWlNjXP50doj5f4k1/EzPEMkGJkzOfsExgFJ2FZNQsJGWzkJTNAntNU2L9Ln2I EkWJKd0P2SFsDYnWOXPZkcUXMLKvYuQoLU4ty003MtjECIytYxJsujsY97y0PMQowMGoxMO7 IH9XsBBrYllxZe4hRmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHoVy3zx P+dZVT6lKAQYmqkMy2J+7wpfVRticORH/LUMsSV639+v2TpnUlJ+3O5Q6X8TXd5xzTzUOP+v /8XzHjxJy/fk3pj3oflRilUJg8OOKv0NloHXKzX6HH8eK79SN2Fj5cJomYUbDOZeMXEoa1xk v3Xdz0vLvuXcfPhYev/cSxVz95Xy71diKc5INNRiLipOBAA4x2FXjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_IQYmRjYeyQXpJrXyhOaXWPHw5I Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:29:30 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUHJhc2FkLA0KdGhpcyBpcyB2ZXJ5IGludGVyZXN0aW5nIHByb3Bvc2FsIGFuZCBJIHRoaW5r IHRoYXQgdGhlIE1QTFMgV0cgd2lsbCBiZSBpbnRlcmVzdGVkIGluIHRoZSBkaXNjdXNzaW9uLiBD b3VwbGUgY29tbWVudHMgYW5kIHF1ZXN0aW9uczoNCuKAoiAgICAgICBJIGJlbGlldmUgdGhhdCBt b25pdG9yaW5nIG9mIEVDTVAgc2VnbWVudHMgb24gbGluayBsYXllciBpcyBtb3JlIGVmZmljaWVu dCBjb21wYXJpbmcgdG8gZTJlIG1vbml0b3JpbmcuIFRoZSBkb2N1bWVudCBzdWdnZXN0cyBvdGhl cndpc2UuIENvdWxkIHlvdSBnaXZlIHNjZW5hcmlvcyBvciB1c2UgY2FzZXMgdGhhdCBzdXBwb3J0 IHVzZWZ1bG5lc3Mgb2YgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGVl cnMsIGdpdmVuIHRoYXQgeW91IG5lZWQgdG8gY29udHJvbCBtYXBwaW5nIG9mIEJGRCBzZXNzaW9u cyB0byBhIHBhcnRpY3VsYXIgcGF0aDsNCuKAoiAgICAgICBhbm90aGVyIHVzZSBjYXNlIHRvIHN1 cHBvcnQgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGVlcnMgaXMgT0FN IHJlZHVuZGFuY3kuIFdoYXQgeW91IHNlZSBhcyB0aGUgbWFpbiBiZW5lZml0IHRoZXJlPyBIb3cg dG8gbWFuYWdlIGRldGVjdGlvbiB0aW1lcyBhbW9uZyBtdWx0aXBsZSBCRkQgc2Vzc2lvbnM/DQri gKIgICAgICAgaGF2ZSB5b3UgbG9va2VkIGF0IFNlY3Rpb24gMi4yLjE8aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLW1wbHMtdHAtb2FtLWNvbmYtMDY+ IG9mIHRoZSBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbXBscy10cC1vYW0tY29uZiBhbmQgU2Vj dGlvbiAzLjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1yc3Zw LXRlLW1wbHMtdHAtb2FtLWV4dC0xMj4gb2YgdGhlIGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1t cGxzLXRwLW9hbS1leHQNCg0KICAgUmVnYXJkcywNCiAgICAgICAgR3JlZw0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkN ClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA4OjMzIEFNDQpUbzogcnRnLWJmZEBpZXRmLm9y Zw0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmdvdmlu ZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwLnR4dA0KDQpIZWxsbyBhbGwsDQogIFdl IGhhdmUgcG9zdGVkIGEgbmV3IGRyYWZ0IG91dGxpbmluZyBhIHByb3Bvc2FsIHRvIGV4dGVuZCB0 aGUgQkZEIERpc2NyaW1pbmF0b3IgVExWIG9mIHRoZSBNUExTIHBpbmcgdG8gYm9vdHN0cmFwIG11 bHRpcGxlIEJGRCBzZXNzaW9ucyBmb3IgYSA8TVBMUyBGRUMsIExTUD4gdHVwbGUuIFBsZWFzZSBs ZXQgdXMga25vdyB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFib3V0IHRo aXMgZHJhZnQuDQpUaGFua3MNClByYXNhZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogRnJpZGF5LCBK dWx5IDA0LCAyMDE0IDY6NDEgUE0NClRvOiBOb2JvIEFraXlhIChub2JvKTsgVmVuZ2FkYSBQcmFz YWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgTm9ibyBBa2l5YSAobm9ibyk7IFZlbmdhZGEgUHJhc2Fk IEdvdmluZGFuICh2ZW5nZ292aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQt ZGlzYy10bHYtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdh ZGEgUHJhc2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogICAgICAgICAgIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRs dg0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgTGFiZWwgU3dpdGNoZWQgUGF0 aCAoTFNQKSBQaW5nIEV4dGVuZGVkIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24g KEJGRCkgRGlzY3JpbWluYXRvciBUTFYNCkRvY3VtZW50IGRhdGU6ICAyMDE0LTA3LTA0DQpHcm91 cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgOA0KVVJM OiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZn b3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12Z292aW5kYW4tbXBscy1l eHRlbmRlZC1iZmQtZGlzYy10bHYvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5kZWQgQmlkaXJl Y3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KICAgKEJGRCkgZGlzY3JpbWluYXRvciBUTFYg Zm9yIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykNCiAgIExhYmVsIFN3 aXRjaGVkIFBhdGggKExTUCkgUGluZyBtZWNoYW5pc20sIHRvIGFsbG93IGJvb3RzdHJhcHBpbmcg b2YNCiAgIG11bHRpcGxlIEJGRCBzZXNzaW9ucyBmb3IgYSBnaXZlbiBGRUMuDQoNCg0KDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGkgUHJhc2FkLDwvZGl2Pg0KPGRpdj50aGlzIGlz IHZlcnkgaW50ZXJlc3RpbmcgcHJvcG9zYWwgYW5kIEkgdGhpbmsgdGhhdCB0aGUgTVBMUyBXRyB3 aWxsIGJlIGludGVyZXN0ZWQgaW4gdGhlIGRpc2N1c3Npb24uIENvdXBsZSBjb21tZW50cyBhbmQg cXVlc3Rpb25zOjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nLWxlZnQ6MzZwdDsi Pg0KPGxpPkkgYmVsaWV2ZSB0aGF0IG1vbml0b3Jpbmcgb2YgRUNNUCBzZWdtZW50cyBvbiBsaW5r IGxheWVyIGlzIG1vcmUgZWZmaWNpZW50IGNvbXBhcmluZyB0byBlMmUgbW9uaXRvcmluZy4gVGhl IGRvY3VtZW50IHN1Z2dlc3RzIG90aGVyd2lzZS4gQ291bGQgeW91IGdpdmUgc2NlbmFyaW9zIG9y IHVzZSBjYXNlcyB0aGF0IHN1cHBvcnQgdXNlZnVsbmVzcyBvZiBtdWx0aXBsZSBCRkQgc2Vzc2lv bnMgYmV0d2VlbiB0aGUgc2FtZSBwZWVycywgZ2l2ZW4NCnRoYXQgeW91IG5lZWQgdG8gY29udHJv bCBtYXBwaW5nIG9mIEJGRCBzZXNzaW9ucyB0byBhIHBhcnRpY3VsYXIgcGF0aDs8L2xpPjxsaT5h bm90aGVyIHVzZSBjYXNlIHRvIHN1cHBvcnQgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4g dGhlIHNhbWUgcGVlcnMgaXMgT0FNIHJlZHVuZGFuY3kuIFdoYXQgeW91IHNlZSBhcyB0aGUgbWFp biBiZW5lZml0IHRoZXJlPyBIb3cgdG8gbWFuYWdlIGRldGVjdGlvbiB0aW1lcyBhbW9uZyBtdWx0 aXBsZSBCRkQgc2Vzc2lvbnM/PC9saT48bGk+aGF2ZSB5b3UgbG9va2VkIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1tcGxzLXRw LW9hbS1jb25mLTA2Ij48Zm9udCBjb2xvcj0iYmx1ZSI+PHU+U2VjdGlvbiAyLjIuMTwvdT48L2Zv bnQ+PC9hPiBvZiB0aGUgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLW1wbHMtdHAtb2FtLWNvbmYg YW5kIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAt cnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTIiPjxmb250IGNvbG9yPSJibHVlIj48dT5TZWN0aW9u DQozLjM8L3U+PC9mb250PjwvYT4gb2YgdGhlIGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxz LXRwLW9hbS1leHQ8L2xpPjwvdWw+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0icGFk ZGluZy1sZWZ0OjE4cHQ7Ij5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0 OjE4cHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQoNCkZyb206IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg VmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKTxicj4NCg0KU2VudDogRnJpZGF5LCBK dWx5IDA0LCAyMDE0IDg6MzMgQU08YnI+DQoNClRvOiBydGctYmZkQGlldGYub3JnPGJyPg0KDQpT dWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4t bXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYtMDAudHh0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5IZWxsbyBhbGwsPC9kaXY+DQo8ZGl2PiZuYnNwOyBXZSBoYXZlIHBvc3RlZCBhIG5l dyBkcmFmdCBvdXRsaW5pbmcgYSBwcm9wb3NhbCB0byBleHRlbmQgdGhlIEJGRCBEaXNjcmltaW5h dG9yIFRMViBvZiB0aGUgTVBMUyBwaW5nIHRvIGJvb3RzdHJhcCBtdWx0aXBsZSBCRkQgc2Vzc2lv bnMgZm9yIGEgJmx0O01QTFMgRkVDLCBMU1AmZ3Q7IHR1cGxlLiBQbGVhc2UgbGV0IHVzIGtub3cg eW91ciBxdWVzdGlvbnMsIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0Ljwv ZGl2Pg0KPGRpdj5UaGFua3M8L2Rpdj4NCjxkaXY+UHJhc2FkPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj5Gcm9tOiA8 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5t YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0gPC9kaXY+DQo8ZGl2PlNlbnQ6IEZy aWRheSwgSnVseSAwNCwgMjAxNCA2OjQxIFBNPC9kaXY+DQo8ZGl2PlRvOiBOb2JvIEFraXlhIChu b2JvKTsgVmVuZ2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgTm9ibyBBa2l5YSAobm9i byk7IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk8L2Rpdj4NCjxkaXY+U3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12Z292aW5kYW4tbXBscy1leHRl bmRlZC1iZmQtZGlzYy10bHYtMDAudHh0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZnb3ZpbmRhbi1t cGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi0wMC50eHQ8L2Rpdj4NCjxkaXY+aGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5O YW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHY8L2Rpdj4N CjxkaXY+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAwPC9k aXY+DQo8ZGl2PlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIFBpbmcgRXh0ZW5kZWQgQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXNjcmltaW5hdG9yIFRMVjwv ZGl2Pg0KPGRpdj5Eb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE0LTA3LTA0PC9kaXY+DQo8ZGl2Pkdy b3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248L2Rpdj4NCjxkaXY+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDg8L2Rpdj4NCjxkaXY+VVJM OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYtMDAudHh0Ij5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRl ZC1iZmQtZGlzYy10bHYtMDAudHh0PC9hPjwvZGl2Pg0KPGRpdj5TdGF0dXM6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1k aXNjLXRsdi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZnb3ZpbmRh bi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdi88L2E+PC9kaXY+DQo8ZGl2Pkh0bWxpemVkOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYt MDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVu ZGVkLWJmZC1kaXNjLXRsdi0wMDwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5BYnN0cmFjdDo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbmRlZCBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0 ZWN0aW9uPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyAoQkZEKSBkaXNjcmltaW5hdG9yIFRMViBm b3IgdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChNUExTKTwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBQaW5nIG1lY2hhbmlzbSwgdG8g YWxsb3cgYm9vdHN0cmFwcGluZyBvZjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgbXVsdGlwbGUg QkZEIHNlc3Npb25zIGZvciBhIGdpdmVuIEZFQy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgSUVURiBTZWNyZXRhcmlhdDwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF1121B7E7AC7eusaamb103erics_-- From nobody Mon Jul 7 16:01:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572DC1B28A5 for ; Mon, 7 Jul 2014 16:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fsaezKt4hjW for ; Mon, 7 Jul 2014 16:01:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D031B28C8 for ; Mon, 7 Jul 2014 16:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6239; q=dns/txt; s=iport; t=1404774078; x=1405983678; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jXmN1vfkZbsqTP0Dkr19YpFfdOmwTSnHufmBuWI991Q=; b=h0SER094D7ShRBF48fFj1BQrENTqNJxyOkNvAG+NRdlCLk/HbmM5z9Kg h95i3sOoOCX58LE/sZviipnXnoR0fRE3ZF3Dem+jqJIBV401ZUlvDjkqZ co+WCbKuTb2lXAY92e/fwZ9XtlH3kqPOBecDtoKCRa62S3U0zzIze2QHO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMwlu1OtJA2I/2dsb2JhbABZgmokgSzGQAGBGRZ1hAMBAQEDAQ4ZPhQMBAIBCBEEAQELHQcyFAkIAgQBDQUIiCYDCQgByVYXjHqBRhEBHzEHBoMngRYBBIoXjEWYJoNDgXc5 X-IronPort-AV: E=Sophos;i="5.01,621,1400025600"; d="scan'208";a="58965319" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 07 Jul 2014 23:01:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s67N1HaN024542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 23:01:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 18:01:17 -0500 From: "Nobo Akiya (nobo)" To: "Jeffrey (Zhaohui) Zhang" , Ross Callon , "Aissaoui, Mustapha (Mustapha)" , "jeremy.whittaker@verizon.com" , Harish Sitaraman , Kapil Arora Thread-Topic: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 Thread-Index: AQHPlUa95Ejp2shyyECvEuCXXDZC9JuL84fAgAj8WACAAFMKQA== Date: Mon, 7 Jul 2014 23:01:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/w3hIa33CpkabupiCDEWhyUvlPb8 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode-simple-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:01:20 -0000 Hi Jeffrey, Please see in-line. > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Monday, July 07, 2014 9:00 AM > To: Nobo Akiya (nobo); Ross Callon; Aissaoui, Mustapha (Mustapha); > jeremy.whittaker@verizon.com; Harish Sitaraman; Kapil Arora > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-akiya-mpls-lsp-ping- > reply-mode-simple@tools.ietf.org > Subject: RE: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply- > mode-simple-02 >=20 > Nobo, >=20 > Sorry for the late response. Holidays. No problem, and thanks for getting back! >=20 > I am not sure if it is necessary to have the flexibility of (2), but it i= s always > good to have the flexibility if it does not introduce much complexity. If= we > allow multiple mode 5, then (2) is achieved. >=20 > I'll leave this up to you. I believe (1) strikes the right balance between flexibility vs. complexity.= I will add some text describing this usage. Thanks! -Nobo =20 >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Tuesday, July 01, 2014 8:58 PM > > To: Jeffrey (Zhaohui) Zhang; Ross Callon; Aissaoui, Mustapha > > (Mustapha); jeremy.whittaker@verizon.com; Harish Sitaraman; Kapil > > Arora > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-akiya-mpls-lsp- > > ping-reply-mode-simple@tools.ietf.org > > Subject: RE: [mpls] MPLS-RT review of draft-akiya-mpls-lsp-ping-reply- > > mode-simple-02 > > > > Hi Jeffrey, > > > > Thank you for reviewing this document. > > > > > I do have one suggestion - could we allow multiple return paths to > > > be specified via multiple "Replay Mode 5" in the new "Reply Mode > > > Order > > TLV" > > > and multiple Reply Path TLVs (currently it is not allowed). > > > > Interesting, I do find what you suggested to be useful. I went back to > > RFC7110 and read up on the Reply Path TLV definition. The TLV can > > contain zero, one or more FECs. > > > > Reply Path: It is used to describe the return path that an echo > > reply will be send along. It is variable in length and can > > contain zero, one or more Target FEC sub-TLVs [RFC4379]. > > > > So it appears that "Reply Mode 5" can be one of the entries in the > > "Reply Mode Order TLV", and "Reply Path TLV" can contain multiple FECs. > > > > (1) What is possible as is: > > Pref#1: Reply Mode 4 Reply via application level control channel > > Pref#2a: Reply Mode 5 Reply via Specified Path -> First FEC listed > > Pref#2b: Reply Mode 5 Reply via Specified Path -> Second FEC liste= d > > Pref#3: Reply Mode 2 Reply via an IPv4/IPv6 UDP packet > > > > (2) What is not possible as is: > > Pref#1: Reply Mode 4 Reply via application level control channel > > Pref#2: Reply Mode 5 Reply via Specified Path -> First FEC listed > > Pref#3: Reply Mode 2 Reply via an IPv4/IPv6 UDP packet > > Pref#4: Reply Mode 5 Reply via Specified Path -> Second FEC listed > > > > Granularity of really mixing up Reply Modes and return FECs like (2) > > cannot be accomplished, but I'm not sure if we need such granularity > > and I believe (1) is reasonable. If you are ok with this, then I think > > it's worth adding texts to describe this usages. Do let us know you > > preference. > > > > Thanks! > > > > -Nobo > > > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeffrey > > (Zhaohui) > > > Zhang > > > Sent: Tuesday, July 01, 2014 12:08 PM > > > To: Ross Callon; Aissaoui, Mustapha (Mustapha); > > > jeremy.whittaker@verizon.com; Harish Sitaraman; Kapil Arora > > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-akiya-mpls-lsp- > > ping- > > > reply-mode-simple@tools.ietf.org > > > Subject: Re: [mpls] MPLS-RT review of > > > draft-akiya-mpls-lsp-ping-reply- > > > mode-simple-02 > > > > > > I have reviewed the draft and believe it is ready for WG adoption > > > consideration. > > > > > > I do have one suggestion - could we allow multiple return paths to > > > be specified via multiple "Replay Mode 5" in the new "Reply Mode > > > Order > > TLV" > > > and multiple Reply Path TLVs (currently it is not allowed). > > > > > > Thanks. > > > Jeffrey > > > _____________________________________________ > > > From: Ross Callon > > > Sent: Tuesday, June 17, 2014 4:52 PM > > > To: Jeffrey (Zhaohui) Zhang; Aissaoui, Mustapha (Mustapha); > > > jeremy.whittaker@verizon.com > > > Cc: draft-akiya-mpls-lsp-ping-reply-mode-simple@tools.ietf.org; > > > mpls- chairs@tools.ietf.org; Martin Vigoureux > > > Subject: MPLS-RT review of draft-akiya-mpls-lsp-ping-reply-mode- > > simple- > > > 02 > > > > > > > > > Jeff, Mustapha, Jeremy; > > > > > > You have been selected as MPLS Review team reviewers for > > > draft-akiya- mpls-lsp-ping-reply-mode-simple-02. > > > > > > Note to authors: You have been CC'd on this email so that you can > > > know > > that > > > this review is going on. However, please do not review your own > > document. > > > Also please don't update the draft while the reviews are in progress > > (we > > > would like the reviewers to all review the same version). > > > > > > Reviews should comment on whether the document is coherent, is it > > useful > > > (ie, is it likely to be actually useful in operational networks), > > > and > > is the > > > document technically sound?=A0 Also, is the text and grammar > > understandable > > > (it doesn't need to be perfect at this point, but should be > > > reasonably > > clear). > > > We are interested in knowing whether the document is ready to be > > > considered for WG adoption (ie, it doesn't have to be perfect at > > > this > > point, > > > but should be a good start). > > > > > > Reviews should be sent to the document authors, WG co-chairs and WG > > > secretary, and CC'd to the MPLS WG email list. If necessary, > > > Comments > > may > > > be sent privately to only the WG chairs. > > > > > > Are you able to review this draft by July 2, 2014? > > > > > > Thanks, Ross > > > (as MPLS WG chair) > > > From nobody Mon Jul 7 16:52:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481A61B2993 for ; Mon, 7 Jul 2014 16:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRHCw9RoAaEB for ; Mon, 7 Jul 2014 16:52:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2842F1B298C for ; Mon, 7 Jul 2014 16:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3841; q=dns/txt; s=iport; t=1404777173; x=1405986773; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xzrIB//VmgzmjRxL6e/Dr4kk7l9E1GHa4Sg4L+iyhs8=; b=Uq8g0G7hMA23ZckF76R1n3vpFOP5cSPsfpkxNTk1D7XNvuB+3f80KQ8s IJbC454lFOuXUOWsRhINUw7DpXSBUE0LeoGVTuW5mYMKEY5FX3WR4P3rP a3zTNAGw9tobzF9lPkFo4IPBLGIMPYGTBCwcmTryWlu4iKOHJEmCfZqmN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMkxu1OtJA2H/2dsb2JhbABPCoJqJIEfDcZBAYEWFnWEAwEBAQMBdwIQAgEIIiQyJQIEDg2IMggByVoXjkYrMQcCgyuBFgEEiheka4NDgjA X-IronPort-AV: E=Sophos;i="5.01,621,1400025600"; d="scan'208";a="58977148" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 07 Jul 2014 23:52:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s67NqqFJ013290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jul 2014 23:52:52 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 18:52:51 -0500 From: "Nobo Akiya (nobo)" To: "Nagendra Kumar Nainar (naikumar)" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgAAGuSCAAWXvgIAMTauggBet8gCAAHYg8A== Date: Mon, 7 Jul 2014 23:52:51 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MiAknugLc6QUw9UoOmqR6xwVT4U Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:52:55 -0000 Hi Nagendra, Thanks for further comments! Please see in-line. > >> From section 3, It appears that responder MUST set the LAG Info TLV. > >>Is it the case even if the downstream is not LAG?. Or did you meant > >>that if the responder have LAG based donwstream interface, then it > >>MUST include the TLV?. > > > >First bullet in the last portion of the Section 3 was exactly to > >explain why this is a MUST, but clearly additional text will be > >helpful. How about we update the bullet: > > > >[old] > > o Identify whether responder LSR understands this mechanism. > > > >[new] > > o Mandating the responder to always add the LAG Interface Info TLV > > in the MPLS echo reply allows the initiating LSR to identify > > whether responder LSR understands this mechanism. >=20 > I am trying to understand the behavior when a responder wants > back to echo received with LAG Interface Info TLV. In figure 1, assume th= ere > is one more node connected to E (say F) and A wants to trace the path fro= m > A to F (via A-B-LAG-C-E-F). When C receives thhe echo with LAG interface > Info TLV, since it doenst have any upstream/downstream LAG interface, wi= ll > it still include the TLV in reply?. If so, is it like it unset both U/D b= it?. Good question. I think you meant E and not C, since C has LAG as upstream? Assuming you were asking what will E send, then: Even if E does not have any upstream/downstream LAG, E will still include L= AG Intf Info TLV in the MPLS echo reply, if it understands this TLV. This i= s how A learns whether or not E is capable of following the procedures desc= ribed in this document. Otherwise lack of LAG upstream/downstream informati= on becomes ambiguous to A: there is no upstream/downstream LAG on E vs. E d= idn't understand the LAG procedures (i.e. ignored the option TLV and procee= ded) but may have upstream/downstream LAG. So, LAG Intf Info TLV in MPLS echo reply is to let the initiator know: - Responder understands this mechanism. - U bit to indicate that responder is capable of providing Detailed Interfa= ce and Label Stack TLV. - D bit to indicate that responder is capable of providing DDMAP with LAG i= nfo. I wanted to break up the (U)pstream and (D)ownstream capabilities, since on= some products, doing one could be more difficult than the other one. > >> Section 7 specifies as below, > >> "The Interface Index Sub-TLV describes the index assigned by the > >> upstream LSR to the interface." > >> > >> Can you also point some reference to what type of index is it?. Is it > >> something assigned and advertised by LAG protocol like LACP or PAGP?. > > > >It's a locally allocated persistent index for local interfaces. It may > >or may not be advertised, and that's not really important for this conte= xt. > >We are just interested in getting a unique value (local to that node) > >that identifies a specific interface. I could add more texts, but the > >description on this sub-TLV was mostly ported from RFC4379. I think > >it's ok as is. >=20 > Ok. So the responder will include the locally assigned index > value (of the egress interface) to this Sub-TLV and reply back. So should= we > modify the below statement?, >=20 > "The Interface Index Sub-TLV describes the index assigned by the > upstream LSR to the interface.=B2 >=20 > I think it is not the upstream LSR to the interface right?. Hmm... yes, that text was copied from RFC4379, but it's a bit confusing. Le= t me change that: [old] The Interface Index Sub-TLV describes the index assigned by the upstream LSR to the interface. [new] The Interface Index Sub-TLV describes the index assigned by this LSR to the interface. Would that work? Thanks! -Nobo From nobody Mon Jul 7 18:06:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6991B29A8 for ; Mon, 7 Jul 2014 18:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejb_uktzX1OM for ; Mon, 7 Jul 2014 18:06:40 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E7B1A0075 for ; Mon, 7 Jul 2014 18:06:39 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bj1so6422084pad.9 for ; Mon, 07 Jul 2014 18:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5gKPbccKGKYzSoz0g9gyYZYmLBS6OUb7aDyI4vRgdzY=; b=aAI6cdxvkz2drgQuU8cUv88nEzO0MF5MUWVUJw+3CfH4O+Z/dOFU/p4RSveQOQulxC N6C9mmnzVCQWNEEx44Il+GvsWf9cS19qBRD2IOXXpoVUQWqWFJrXhRshMP5QtwG+wW5A 7mC+e2jntsvs1AVXDesgCFMvJ+9y+Bx0l8nrlyxEvrB1+YkMcbiBxOcI7kN4bDluFNOX Nd+Rjr1+Wix6kt+qhG+wo3ZPn6glONYuIxnfSWFzON45t0qR7bfdDewFV3G5Nqhszi+r 0qDWrqObkg9VkUZSQolnUJ0SRWgVbDiGevdHm8SAtc5eVWyh4nH67oBi9G9Nd+iKv1Bl ZR2g== X-Received: by 10.66.163.38 with SMTP id yf6mr32542567pab.46.1404781599520; Mon, 07 Jul 2014 18:06:39 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id i10sm196839357pat.36.2014.07.07.18.06.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 18:06:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 7 Jul 2014 18:06:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10150BDE-17FD-43D0-9DE4-6E0CAAF3BD5E@gmail.com> References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BuQxn7sR9Y1r0dFU8qksdpSe6YA Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 01:06:41 -0000 Hi Nobo and authors, Slow in catching up on this ID. I have some basic questions about the draft. Want to get them clarified = before doing a detailed review. 1. I thought the ECMP is about the LSP's and not about L3 interfaces or = L2 interfaces. i.e. at MPLS LSP level where LSP's are established = irrespective of L3 or L2 interfaces. But section 1.2. talks about L3 and = L2 and implies that RFC4379 does only L3 interfaces ECMP, could you = kindly clarify? Atleast as I read RFC4379 section 4.1 doesn't = distinguish as defined in this draft. 2. Could you clarify the following? In the case of LAG interface, for a = given FEC, will there be different label stack for each sub-interface = type? If not, i.e. same label stack but differ sub i.f, which multipath = type one could use to determine hash computation? 3. If in Q #2 Label stack there exists different label stack for each = lag member, is there a downside to using separate DDMAP for each LAG = member? i.e. w/o any enhancement? 4. Also, how is DDMAP interface info validated? I believe the LAG member = link # is local. What all fields being validated for LAG interface? Responses will clarify for me to review better. :D -sam On Jun 13, 2014, at 2:14 PM, Nobo Akiya (nobo) wrote: > Dear MPLS WG, >=20 > On MPLS data plane, one aspect which OAM is blind to traffic black = holing is when LSPs are traversing over LAG interfaces. We would like to = propose an extension to RFC4379 to provide the tool an ability to = discover and traverse LAG members. >=20 > It will be very helpful if you could review this document, provide = comments and help us standardize this extension. >=20 > Thanks! >=20 > -Nobo, on behalf of authors >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, June 13, 2014 5:04 PM >> To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow); = George >> Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno = Decraene; >> Nobo Akiya (nobo); John Drake; Stephane Litkowski >> Subject: New Version Notification for draft-akiya-mpls-lsp-ping-lag- >> multipath-00.txt >>=20 >>=20 >> A new version of I-D, draft-akiya-mpls-lsp-ping-lag-multipath-00.txt >> has been successfully submitted by Nobo Akiya and posted to the IETF >> repository. >>=20 >> Name: draft-akiya-mpls-lsp-ping-lag-multipath >> Revision: 00 >> Title: Label Switched Path (LSP) Ping/Trace Multipath = Support for >> Link Aggregation Group (LAG) Interfaces >> Document date: 2014-06-13 >> Group: Individual Submission >> Pages: 18 >> URL: = http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping- >> lag-multipath-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag- >> multipath/ >> Htmlized: = http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag- >> multipath-00 >>=20 >>=20 >> Abstract: >> This document defines an extension to the Multiprotocol Label >> Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to >> describe Multipath Information for Link Aggregation (LAG) member >> links separately, thus allowing MPLS LSP Ping and Traceroute to >> discover and exercise specific paths of layer 2 Equal-Cost = Multipath >> (ECMP) over LAG interfaces. >>=20 >> This document updates RFC4379 and RFC6424. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jul 7 18:41:56 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3F21B2910 for ; Mon, 7 Jul 2014 18:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyfMoWGVmzWu for ; Mon, 7 Jul 2014 18:41:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0241B28AE for ; Mon, 7 Jul 2014 18:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7233; q=dns/txt; s=iport; t=1404783712; x=1405993312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eq5Ui8fraGaD8WHKFr4/66YNZEo/Icyr2+OFDdTCQkQ=; b=Ozcam7o/qNfg25IPDulcCLLT0s3tg35kqhjHXnxINgrSCJeqkEwvO1wh kLo4ryadMbXkl7bt1dkWz1PLXNFVGNsVYLom4K6jpxEO02hwOEZFCIeRB N+KlGb6qgku1U9xNigYYDBH2c6sHXJk7WF5esvv8cULmkAUFbi6FIqvdg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAL1Lu1OtJA2B/2dsb2JhbABZgmokUlq+ZodEAYEXFnWEAwEBAQMBAQEBNysJCQIMBAIBCBEEAQEBChQJByEGCxQJCAIEDgUIAYglAwkIAQzDFA2FfReMeoF3MQcGgyeBFgWYdoNIjDCGFIIBgUKBcCQc X-IronPort-AV: E=Sophos;i="5.01,622,1400025600"; d="scan'208";a="338436178" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jul 2014 01:41:51 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s681foLF009157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 01:41:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 20:41:50 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgCZOLID//65qEA== Date: Tue, 8 Jul 2014 01:41:49 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> <10150BDE-17FD-43D0-9DE4-6E0CAAF3BD5E@gmail.com> In-Reply-To: <10150BDE-17FD-43D0-9DE4-6E0CAAF3BD5E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/kkWXi5La7i5Hr6Ge3L6TP21xmcc Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 01:41:54 -0000 Hi Sam, Always appreciate your comments/questions :) Please see in-line. > -----Original Message----- > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] > Sent: Monday, July 07, 2014 9:07 PM > To: Nobo Akiya (nobo) > Cc: mpls@ietf.org > Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-pin= g- > lag-multipath-00.txt >=20 > Hi Nobo and authors, >=20 > Slow in catching up on this ID. >=20 > I have some basic questions about the draft. Want to get them clarified > before doing a detailed review. >=20 > 1. I thought the ECMP is about the LSP's and not about L3 interfaces or L= 2 > interfaces. i.e. at MPLS LSP level where LSP's are established irrespecti= ve of > L3 or L2 interfaces. But section 1.2. talks about L3 and L2 and implies t= hat > RFC4379 does only L3 interfaces ECMP, could you kindly clarify? Atleast a= s I > read RFC4379 section 4.1 doesn't distinguish as defined in this draft. RFC4379/RFC6424 do not explicitly spell this out, but it's the DDMAP (as we= ll as DSMP) fields that imply L3. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | DS Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And the Address Type can be: Type # Address Type K Octets ------ ------------ -------- 1 IPv4 Numbered 16 2 IPv4 Unnumbered 16 3 IPv6 Numbered 40 4 IPv6 Unnumbered 28 Type 5 (Non IP) was also added by RFC6426 for TP. If an LSR was to describe each LAG member in a DDMAP using procedures descr= ibed in RFC4379/RFC6424, then all fields expect for Multipath Info will be = exactly the same. This is sort of "weird" in the first place, but what is w= orse is that this leads to the difficulty of the second portion of the draf= t-akiya-mpls-lsp-ping-lag-multipath, which is to validate the different tra= versal for each LAG member. >=20 > 2. Could you clarify the following? In the case of LAG interface, for a g= iven > FEC, will there be different label stack for each sub-interface type? If = not, > i.e. same label stack but differ sub i.f, which multipath type one could = use > to determine hash computation? I think I understand your question ... but if my answers are not what you w= ere asking, do elaborate. For a given FEC, the incoming & outgoing labels w= ill be the same for all LAG members when traversing over a LAG to reach the= downstream. Of course SR could assign an Adj-SID for a LAG member, and exp= licitly steer the packets over the specific LAG member, but it would no lon= ger be considered to travel over the LAG at that point. Similar if RSVP was= to pin-down a specific LAG member. So the LAG is treated as one logical in= terface by the label binding procedures, thus same labels for every LAG mem= ber. As far as how an incoming packet is load balanced to each LAG member, that = could be, in the context of LSP trace, either destination IP addresses (mul= tipath type {2, 4, 8}) or Entropy Labels (multipath type {9}) or both (mult= ipath type {10}). >=20 > 3. If in Q #2 Label stack there exists different label stack for each lag > member, is there a downside to using separate DDMAP for each LAG > member? i.e. w/o any enhancement? Same label, see above. >=20 > 4. Also, how is DDMAP interface info validated? I believe the LAG member > link # is local. What all fields being validated for LAG interface? When MPLS echo request traverses over all LAG members (i.e. different inter= face index) to the nexthop, then the packets should have terminated on diff= erent incoming LAG members at the downstream (different interface index). For supported/unsupported scenarios, please view: http://tools.ietf.org/htm= l/draft-akiya-mpls-lsp-ping-lag-multipath-00#appendix-A >=20 > Responses will clarify for me to review better. :D Looking forward to seeing more comments from you, hopefully not as harsh as= the Reply Mode extension draft :) Thanks! -Nobo >=20 > -sam >=20 >=20 > On Jun 13, 2014, at 2:14 PM, Nobo Akiya (nobo) wrote: >=20 > > Dear MPLS WG, > > > > On MPLS data plane, one aspect which OAM is blind to traffic black holi= ng > is when LSPs are traversing over LAG interfaces. We would like to propose > an extension to RFC4379 to provide the tool an ability to discover and > traverse LAG members. > > > > It will be very helpful if you could review this document, provide > comments and help us standardize this extension. > > > > Thanks! > > > > -Nobo, on behalf of authors > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, June 13, 2014 5:04 PM > >> To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow); > >> George Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno > >> Decraene; Nobo Akiya (nobo); John Drake; Stephane Litkowski > >> Subject: New Version Notification for draft-akiya-mpls-lsp-ping-lag- > >> multipath-00.txt > >> > >> > >> A new version of I-D, draft-akiya-mpls-lsp-ping-lag-multipath-00.txt > >> has been successfully submitted by Nobo Akiya and posted to the IETF > >> repository. > >> > >> Name: draft-akiya-mpls-lsp-ping-lag-multipath > >> Revision: 00 > >> Title: Label Switched Path (LSP) Ping/Trace Multipath > Support for > >> Link Aggregation Group (LAG) Interfaces > >> Document date: 2014-06-13 > >> Group: Individual Submission > >> Pages: 18 > >> URL: http://www.ietf.org/internet-drafts/draft-akiya-mpls-l= sp- > ping- > >> lag-multipath-00.txt > >> Status: https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-= ping- > lag- > >> multipath/ > >> Htmlized: http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-l= ag- > >> multipath-00 > >> > >> > >> Abstract: > >> This document defines an extension to the Multiprotocol Label > >> Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to > >> describe Multipath Information for Link Aggregation (LAG) member > >> links separately, thus allowing MPLS LSP Ping and Traceroute to > >> discover and exercise specific paths of layer 2 Equal-Cost Multipath > >> (ECMP) over LAG interfaces. > >> > >> This document updates RFC4379 and RFC6424. > >> > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jul 7 19:26:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09D1B29E9 for ; Mon, 7 Jul 2014 19:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUR6kF8bR_Il for ; Mon, 7 Jul 2014 19:26:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C0F1B29F0 for ; Mon, 7 Jul 2014 19:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7870; q=dns/txt; s=iport; t=1404786361; x=1405995961; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ppEL1XcbfmlOIsfrwX26Ma9tmQ+IVg+tuemgP3/Q6GA=; b=D5/hYZArKeDD3JcA2yVtjxK0cBteGrI9e0appzzVB/9tnDjt/UWb7zyj pxE/toMN7xWbdrH8RL/WlYBq/MgXbxAPe7cF+h916A5a7OAropDUbzh90 K3o8yPj8zSa4T9Bl2AzgwwRlVRsKfFS1Kpog9oxKFypPLLMuHlkCO8Ot9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAxWu1OtJA2M/2dsb2JhbABPCoMOgR8Ngm/DPAEZfhZ1hAQBAQQ0QwIQAgEIHCgCAjAlAgQOBYhCk0OcHwaZNBeBJo0gKTMHAgKCbYFSAQSadpQMg0OCMA X-IronPort-AV: E=Sophos;i="5.01,623,1400025600"; d="scan'208";a="338159101" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jul 2014 02:26:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s682Pxrw009874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Jul 2014 02:25:59 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.65]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 21:25:59 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Nobo Akiya (nobo)" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgAAGuSCAAWXvgIAMTauggBet8gCAAHYg8IAAQuAA Date: Tue, 8 Jul 2014 02:25:58 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.146.59] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MQD5XataFXOaL0sw7cHMLdrMWDY Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:26:02 -0000 SGkgTm9ibywNCg0KR29vZCBxdWVzdGlvbi4gSSB0aGluayB5b3UgbWVhbnQgRSBhbmQgbm90IEMs IHNpbmNlIEMgaGFzIExBRyBhcyB1cHN0cmVhbT8NCg0KQXNzdW1pbmcgeW91IHdlcmUgYXNraW5n IHdoYXQgd2lsbCBFIHNlbmQsIHRoZW46DQoNCkV2ZW4gaWYgRSBkb2VzIG5vdCBoYXZlIGFueSB1 cHN0cmVhbS9kb3duc3RyZWFtIExBRywgRSB3aWxsIHN0aWxsIGluY2x1ZGUNCkxBRyBJbnRmIElu Zm8gVExWIGluIHRoZSBNUExTIGVjaG8gcmVwbHksIGlmIGl0IHVuZGVyc3RhbmRzIHRoaXMgVExW LiBUaGlzDQppcyBob3cgQSBsZWFybnMgd2hldGhlciBvciBub3QgRSBpcyBjYXBhYmxlIG9mIGZv bGxvd2luZyB0aGUgcHJvY2VkdXJlcw0KZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuIE90aGVy d2lzZSBsYWNrIG9mIExBRyB1cHN0cmVhbS9kb3duc3RyZWFtDQppbmZvcm1hdGlvbiBiZWNvbWVz IGFtYmlndW91cyB0byBBOiB0aGVyZSBpcyBubyB1cHN0cmVhbS9kb3duc3RyZWFtIExBRyBvbg0K RSB2cy4gRSBkaWRuJ3QgdW5kZXJzdGFuZCB0aGUgTEFHIHByb2NlZHVyZXMgKGkuZS4gaWdub3Jl ZCB0aGUgb3B0aW9uIFRMVg0KYW5kIHByb2NlZWRlZCkgYnV0IG1heSBoYXZlIHVwc3RyZWFtL2Rv d25zdHJlYW0gTEFHLg0KDQpTbywgTEFHIEludGYgSW5mbyBUTFYgaW4gTVBMUyBlY2hvIHJlcGx5 IGlzIHRvIGxldCB0aGUgaW5pdGlhdG9yIGtub3c6DQotIFJlc3BvbmRlciB1bmRlcnN0YW5kcyB0 aGlzIG1lY2hhbmlzbS4NCi0gVSBiaXQgdG8gaW5kaWNhdGUgdGhhdCByZXNwb25kZXIgaXMgY2Fw YWJsZSBvZiBwcm92aWRpbmcgRGV0YWlsZWQNCkludGVyZmFjZSBhbmQgTGFiZWwgU3RhY2sgVExW Lg0KLSBEIGJpdCB0byBpbmRpY2F0ZSB0aGF0IHJlc3BvbmRlciBpcyBjYXBhYmxlIG9mIHByb3Zp ZGluZyBERE1BUCB3aXRoIExBRw0KaW5mby4NCg0KSSB3YW50ZWQgdG8gYnJlYWsgdXAgdGhlIChV KXBzdHJlYW0gYW5kIChEKW93bnN0cmVhbSBjYXBhYmlsaXRpZXMsIHNpbmNlDQpvbiBzb21lIHBy b2R1Y3RzLCBkb2luZyBvbmUgY291bGQgYmUgbW9yZSBkaWZmaWN1bHQgdGhhbiB0aGUgb3RoZXIg b25lLg0KDQo8TmFnZW5kcmE+IFllcywgaXQgaXMgRSA6KS4gVGhhdCBtYWtlcyBzZW5zZS4gU28g SSB0aGluayBFIHdpbGwgc2V0IFUgYW5kDQpEIHRvIHplcm8gdG8gaW5kaWNhdGUgdGhlcmUgaXMg bm8gTEFHIGRldGFpbHMgYnV0IEkgdW5kZXJzdGFuZCB0aGlzDQpmZWF0dXJlIDopLiBNYXkgYmUg dGhpcyBjYW4gYmUgY2xhcmlmaWVkIGluIHRoZSBkcmFmdD8uDQoNCg0KSG1tLi4uIHllcywgdGhh dCB0ZXh0IHdhcyBjb3BpZWQgZnJvbSBSRkM0Mzc5LCBidXQgaXQncyBhIGJpdCBjb25mdXNpbmcu DQpMZXQgbWUgY2hhbmdlIHRoYXQ6DQoNCltvbGRdDQogICBUaGUgSW50ZXJmYWNlIEluZGV4IFN1 Yi1UTFYgZGVzY3JpYmVzIHRoZSBpbmRleCBhc3NpZ25lZCBieSB0aGUNCiAgIHVwc3RyZWFtIExT UiB0byB0aGUgaW50ZXJmYWNlLg0KDQpbbmV3XQ0KICAgVGhlIEludGVyZmFjZSBJbmRleCBTdWIt VExWIGRlc2NyaWJlcyB0aGUgaW5kZXggYXNzaWduZWQgYnkgdGhpcw0KICAgTFNSIHRvIHRoZSBp bnRlcmZhY2UuDQoNCldvdWxkIHRoYXQgd29yaz8NCg0KPE5hZ2VuZHJhPiBPciChsFRoZSBJbnRl cmZhY2UgSW5kZXggU3ViLVRMViBkZXNjcmliZXMgdGhlIGluZGV4IGFzc2lnbmVkIGJ5DQpsb2Nh bCBMU1IgdG8gdGhlIGVncmVzcyBpbnRlcmZhY2WhsT8uDQoNCg0KVGhhbmtzLA0KTmFnZW5kcmEN Cg0KT24gNy83LzE0LCA3OjUyIFBNLCAiTm9ibyBBa2l5YSAobm9ibykiIDxub2JvQGNpc2NvLmNv bT4gd3JvdGU6DQoNCj5IaSBOYWdlbmRyYSwNCj4NCj5UaGFua3MgZm9yIGZ1cnRoZXIgY29tbWVu dHMhDQo+UGxlYXNlIHNlZSBpbi1saW5lLg0KPg0KPj4gPj4gRnJvbSBzZWN0aW9uIDMsIEl0IGFw cGVhcnMgdGhhdCByZXNwb25kZXIgTVVTVCBzZXQgdGhlIExBRyBJbmZvIFRMVi4NCj4+ID4+SXMg aXQgdGhlICBjYXNlIGV2ZW4gaWYgdGhlIGRvd25zdHJlYW0gaXMgbm90IExBRz8uIE9yIGRpZCB5 b3UgbWVhbnQNCj4+ID4+dGhhdCBpZiB0aGUgIHJlc3BvbmRlciBoYXZlIExBRyBiYXNlZCBkb253 c3RyZWFtIGludGVyZmFjZSwgdGhlbiBpdA0KPj4gPj5NVVNUIGluY2x1ZGUgdGhlICBUTFY/Lg0K Pj4gPg0KPj4gPkZpcnN0IGJ1bGxldCBpbiB0aGUgbGFzdCBwb3J0aW9uIG9mIHRoZSBTZWN0aW9u IDMgd2FzIGV4YWN0bHkgdG8NCj4+ID5leHBsYWluIHdoeSB0aGlzIGlzIGEgTVVTVCwgYnV0IGNs ZWFybHkgYWRkaXRpb25hbCB0ZXh0IHdpbGwgYmUNCj4+ID5oZWxwZnVsLiBIb3cgYWJvdXQgd2Ug dXBkYXRlIHRoZSBidWxsZXQ6DQo+PiA+DQo+PiA+W29sZF0NCj4+ID4gICBvICBJZGVudGlmeSB3 aGV0aGVyIHJlc3BvbmRlciBMU1IgdW5kZXJzdGFuZHMgdGhpcyBtZWNoYW5pc20uDQo+PiA+DQo+ PiA+W25ld10NCj4+ID4gICBvICBNYW5kYXRpbmcgdGhlIHJlc3BvbmRlciB0byBhbHdheXMgYWRk IHRoZSBMQUcgSW50ZXJmYWNlIEluZm8gVExWDQo+PiA+ICAgICAgaW4gdGhlIE1QTFMgZWNobyBy ZXBseSBhbGxvd3MgdGhlIGluaXRpYXRpbmcgTFNSIHRvIGlkZW50aWZ5DQo+PiA+ICAgICAgd2hl dGhlciByZXNwb25kZXIgTFNSIHVuZGVyc3RhbmRzIHRoaXMgbWVjaGFuaXNtLg0KPj4gDQo+PiA8 TmFnZW5kcmE+IEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGJlaGF2aW9yIHdoZW4gYSBy ZXNwb25kZXIgd2FudHMNCj4+IGJhY2sgdG8gZWNobyByZWNlaXZlZCB3aXRoIExBRyBJbnRlcmZh Y2UgSW5mbyBUTFYuIEluIGZpZ3VyZSAxLCBhc3N1bWUNCj4+dGhlcmUNCj4+IGlzIG9uZSBtb3Jl IG5vZGUgY29ubmVjdGVkIHRvIEUgKHNheSBGKSBhbmQgQSB3YW50cyB0byB0cmFjZSB0aGUgcGF0 aA0KPj5mcm9tDQo+PiBBIHRvIEYgKHZpYSBBLUItTEFHLUMtRS1GKS4gV2hlbiBDIHJlY2VpdmVz IHRoaGUgZWNobyB3aXRoIExBRyBpbnRlcmZhY2UNCj4+IEluZm8gIFRMViwgc2luY2UgaXQgZG9l bnN0IGhhdmUgYW55IHVwc3RyZWFtL2Rvd25zdHJlYW0gTEFHIGludGVyZmFjZSwNCj4+d2lsbA0K Pj4gaXQgc3RpbGwgaW5jbHVkZSB0aGUgVExWIGluIHJlcGx5Py4gSWYgc28sIGlzIGl0IGxpa2Ug aXQgdW5zZXQgYm90aCBVL0QNCj4+Yml0Py4NCj4NCj5Hb29kIHF1ZXN0aW9uLiBJIHRoaW5rIHlv dSBtZWFudCBFIGFuZCBub3QgQywgc2luY2UgQyBoYXMgTEFHIGFzIHVwc3RyZWFtPw0KPg0KPkFz c3VtaW5nIHlvdSB3ZXJlIGFza2luZyB3aGF0IHdpbGwgRSBzZW5kLCB0aGVuOg0KPg0KPkV2ZW4g aWYgRSBkb2VzIG5vdCBoYXZlIGFueSB1cHN0cmVhbS9kb3duc3RyZWFtIExBRywgRSB3aWxsIHN0 aWxsIGluY2x1ZGUNCj5MQUcgSW50ZiBJbmZvIFRMViBpbiB0aGUgTVBMUyBlY2hvIHJlcGx5LCBp ZiBpdCB1bmRlcnN0YW5kcyB0aGlzIFRMVi4NCj5UaGlzIGlzIGhvdyBBIGxlYXJucyB3aGV0aGVy IG9yIG5vdCBFIGlzIGNhcGFibGUgb2YgZm9sbG93aW5nIHRoZQ0KPnByb2NlZHVyZXMgZGVzY3Jp YmVkIGluIHRoaXMgZG9jdW1lbnQuIE90aGVyd2lzZSBsYWNrIG9mIExBRw0KPnVwc3RyZWFtL2Rv d25zdHJlYW0gaW5mb3JtYXRpb24gYmVjb21lcyBhbWJpZ3VvdXMgdG8gQTogdGhlcmUgaXMgbm8N Cj51cHN0cmVhbS9kb3duc3RyZWFtIExBRyBvbiBFIHZzLiBFIGRpZG4ndCB1bmRlcnN0YW5kIHRo ZSBMQUcgcHJvY2VkdXJlcw0KPihpLmUuIGlnbm9yZWQgdGhlIG9wdGlvbiBUTFYgYW5kIHByb2Nl ZWRlZCkgYnV0IG1heSBoYXZlDQo+dXBzdHJlYW0vZG93bnN0cmVhbSBMQUcuDQo+DQo+U28sIExB RyBJbnRmIEluZm8gVExWIGluIE1QTFMgZWNobyByZXBseSBpcyB0byBsZXQgdGhlIGluaXRpYXRv ciBrbm93Og0KPi0gUmVzcG9uZGVyIHVuZGVyc3RhbmRzIHRoaXMgbWVjaGFuaXNtLg0KPi0gVSBi aXQgdG8gaW5kaWNhdGUgdGhhdCByZXNwb25kZXIgaXMgY2FwYWJsZSBvZiBwcm92aWRpbmcgRGV0 YWlsZWQNCj5JbnRlcmZhY2UgYW5kIExhYmVsIFN0YWNrIFRMVi4NCj4tIEQgYml0IHRvIGluZGlj YXRlIHRoYXQgcmVzcG9uZGVyIGlzIGNhcGFibGUgb2YgcHJvdmlkaW5nIERETUFQIHdpdGggTEFH DQo+aW5mby4NCj4NCj5JIHdhbnRlZCB0byBicmVhayB1cCB0aGUgKFUpcHN0cmVhbSBhbmQgKEQp b3duc3RyZWFtIGNhcGFiaWxpdGllcywgc2luY2UNCj5vbiBzb21lIHByb2R1Y3RzLCBkb2luZyBv bmUgY291bGQgYmUgbW9yZSBkaWZmaWN1bHQgdGhhbiB0aGUgb3RoZXIgb25lLg0KPg0KPj4gPj4g U2VjdGlvbiA3IHNwZWNpZmllcyBhcyBiZWxvdywNCj4+ID4+ICJUaGUgSW50ZXJmYWNlIEluZGV4 IFN1Yi1UTFYgZGVzY3JpYmVzIHRoZSBpbmRleCBhc3NpZ25lZCBieSB0aGUNCj4+ID4+ICAgIHVw c3RyZWFtIExTUiB0byB0aGUgaW50ZXJmYWNlLiINCj4+ID4+DQo+PiA+PiBDYW4geW91IGFsc28g cG9pbnQgc29tZSByZWZlcmVuY2UgdG8gd2hhdCB0eXBlIG9mIGluZGV4IGlzIGl0Py4gSXMgaXQN Cj4+ID4+IHNvbWV0aGluZyBhc3NpZ25lZCBhbmQgYWR2ZXJ0aXNlZCBieSBMQUcgcHJvdG9jb2wg bGlrZSBMQUNQIG9yIFBBR1A/Lg0KPj4gPg0KPj4gPkl0J3MgYSBsb2NhbGx5IGFsbG9jYXRlZCBw ZXJzaXN0ZW50IGluZGV4IGZvciBsb2NhbCBpbnRlcmZhY2VzLiBJdCBtYXkNCj4+ID5vciBtYXkg bm90IGJlIGFkdmVydGlzZWQsIGFuZCB0aGF0J3Mgbm90IHJlYWxseSBpbXBvcnRhbnQgZm9yIHRo aXMNCj4+Y29udGV4dC4NCj4+ID5XZSBhcmUganVzdCBpbnRlcmVzdGVkIGluIGdldHRpbmcgYSB1 bmlxdWUgdmFsdWUgKGxvY2FsIHRvIHRoYXQgbm9kZSkNCj4+ID50aGF0IGlkZW50aWZpZXMgYSBz cGVjaWZpYyBpbnRlcmZhY2UuIEkgY291bGQgYWRkIG1vcmUgdGV4dHMsIGJ1dCB0aGUNCj4+ID5k ZXNjcmlwdGlvbiBvbiB0aGlzIHN1Yi1UTFYgd2FzIG1vc3RseSBwb3J0ZWQgZnJvbSBSRkM0Mzc5 LiBJIHRoaW5rDQo+PiA+aXQncyBvayBhcyBpcy4NCj4+IA0KPj4gPE5hZ2VuZHJhPiBPay4gU28g dGhlIHJlc3BvbmRlciB3aWxsIGluY2x1ZGUgdGhlIGxvY2FsbHkgYXNzaWduZWQgaW5kZXgNCj4+ IHZhbHVlIChvZiB0aGUgZWdyZXNzIGludGVyZmFjZSkgdG8gdGhpcyBTdWItVExWIGFuZCByZXBs eSBiYWNrLiBTbw0KPj5zaG91bGQgd2UNCj4+IG1vZGlmeSB0aGUgYmVsb3cgc3RhdGVtZW50PywN Cj4+IA0KPj4gIlRoZSBJbnRlcmZhY2UgSW5kZXggU3ViLVRMViBkZXNjcmliZXMgdGhlIGluZGV4 IGFzc2lnbmVkIGJ5IHRoZQ0KPj4gICAgdXBzdHJlYW0gTFNSIHRvIHRoZSBpbnRlcmZhY2UuqfcN Cj4+IA0KPj4gSSB0aGluayBpdCBpcyBub3QgdGhlIHVwc3RyZWFtIExTUiB0byB0aGUgaW50ZXJm YWNlIHJpZ2h0Py4NCj4NCj5IbW0uLi4geWVzLCB0aGF0IHRleHQgd2FzIGNvcGllZCBmcm9tIFJG QzQzNzksIGJ1dCBpdCdzIGEgYml0IGNvbmZ1c2luZy4NCj5MZXQgbWUgY2hhbmdlIHRoYXQ6DQo+ DQo+W29sZF0NCj4gICBUaGUgSW50ZXJmYWNlIEluZGV4IFN1Yi1UTFYgZGVzY3JpYmVzIHRoZSBp bmRleCBhc3NpZ25lZCBieSB0aGUNCj4gICB1cHN0cmVhbSBMU1IgdG8gdGhlIGludGVyZmFjZS4N Cj4NCj5bbmV3XQ0KPiAgIFRoZSBJbnRlcmZhY2UgSW5kZXggU3ViLVRMViBkZXNjcmliZXMgdGhl IGluZGV4IGFzc2lnbmVkIGJ5IHRoaXMNCj4gICBMU1IgdG8gdGhlIGludGVyZmFjZS4NCj4NCj5X b3VsZCB0aGF0IHdvcms/DQo+DQo+VGhhbmtzIQ0KPg0KPi1Ob2JvDQo+DQo+DQoNCg== From nobody Mon Jul 7 19:32:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCAC1B2A07 for ; Mon, 7 Jul 2014 19:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KObyPyN031Ou for ; Mon, 7 Jul 2014 19:32:03 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F80D1B2A05 for ; Mon, 7 Jul 2014 19:32:03 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so6484883pab.3 for ; Mon, 07 Jul 2014 19:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3yZFRSQ+Vcji4VGqlcxxUPBiPd4OoWPKn3BWRsj/KuY=; b=X8U/5l9ZWKS+lzW1Oa5+0kAJfQE6z/M3sL07TXyR3GdVYWcmoiKbz7rKnZF3sGsbCd CIdKKJ5r42KV4hNZJehrVYoe83wa9Qh1Z9ZCB+p9p2wDdGihvAKXIgR5hx13ZTj8FmPU hav/G5TcyFOa25JOn3k83XNOXqeHx6r+5tPsRxbB/Wvonf/NBQlcO9OJWs+NvmDKrQIs QEVtzZ4bBC5BsHuLEKYsonHcfuDXLadHPxKU0lH5sWVe67/+LpQUB2a/LSGOdxFnQ9T2 29d9ojrm9tBLVS8Gf96/6goXjAuvmmL3YcIQ8+nCh6b+hFOMkyx5nnEA971iMQPwD/XJ 7TWA== X-Received: by 10.67.4.163 with SMTP id cf3mr31872975pad.92.1404786722949; Mon, 07 Jul 2014 19:32:02 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id v9sm22183506pdp.88.2014.07.07.19.32.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 19:32:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 7 Jul 2014 19:32:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> <10150BDE-17FD-43D0-9DE4-6E0CAAF3BD5E@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/krb7Xwl3ysfR6SAQFd8p_Zx58fY Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:32:06 -0000 Thanks, Nobo, for quick response. Inline for my comments. On Jul 7, 2014, at 6:41 PM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 > Always appreciate your comments/questions :) >=20 > Please see in-line. >=20 >> -----Original Message----- >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Monday, July 07, 2014 9:07 PM >> To: Nobo Akiya (nobo) >> Cc: mpls@ietf.org >> Subject: Re: [mpls] New Version Notification for = draft-akiya-mpls-lsp-ping- >> lag-multipath-00.txt >>=20 >> Hi Nobo and authors, >>=20 >> Slow in catching up on this ID. >>=20 >> I have some basic questions about the draft. Want to get them = clarified >> before doing a detailed review. >>=20 >> 1. I thought the ECMP is about the LSP's and not about L3 interfaces = or L2 >> interfaces. i.e. at MPLS LSP level where LSP's are established = irrespective of >> L3 or L2 interfaces. But section 1.2. talks about L3 and L2 and = implies that >> RFC4379 does only L3 interfaces ECMP, could you kindly clarify? = Atleast as I >> read RFC4379 section 4.1 doesn't distinguish as defined in this = draft. >=20 > RFC4379/RFC6424 do not explicitly spell this out, but it's the DDMAP = (as well as DSMP) fields that imply L3. >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MTU | Address Type | DS Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Downstream IP Address (4 or 16 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Downstream Interface Address (4 or 16 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > And the Address Type can be: >=20 > Type # Address Type K Octets > ------ ------------ -------- > 1 IPv4 Numbered 16 > 2 IPv4 Unnumbered 16 > 3 IPv6 Numbered 40 > 4 IPv6 Unnumbered 28 >=20 > Type 5 (Non IP) was also added by RFC6426 for TP. May be the wording in your draft should change, because neither RFC = explicitly say that. It could be just that LAG interface type was not = explicitly identified.=20 >=20 > If an LSR was to describe each LAG member in a DDMAP using procedures = described in RFC4379/RFC6424, then all fields expect for Multipath Info = will be exactly the same. This is sort of "weird" in the first place, = but what is worse is that this leads to the difficulty of the second = portion of the draft-akiya-mpls-lsp-ping-lag-multipath, which is to = validate the different traversal for each LAG member. ok >=20 >>=20 >> 2. Could you clarify the following? In the case of LAG interface, for = a given >> FEC, will there be different label stack for each sub-interface type? = If not, >> i.e. same label stack but differ sub i.f, which multipath type one = could use >> to determine hash computation? >=20 > I think I understand your question ... but if my answers are not what = you were asking, do elaborate. For a given FEC, the incoming & outgoing = labels will be the same for all LAG members when traversing over a LAG = to reach the downstream. Of course SR could assign an Adj-SID for a LAG = member, and explicitly steer the packets over the specific LAG member, = but it would no longer be considered to travel over the LAG at that = point. Similar if RSVP was to pin-down a specific LAG member. So the LAG = is treated as one logical interface by the label binding procedures, = thus same labels for every LAG member. Few questions, Because you mentioned it is L2 interfaces only, I was wondering whether = L3 header is taken into consideration or not!=20 Secondly, assuming if member is not pinned to a specific LSP, is the = validation for FEC? If so, how is that being done? when do you consider = LSP ping/trace failure? As it is sub member failure, the interface is = still running and packets are still fwd'd.=20 >=20 > As far as how an incoming packet is load balanced to each LAG member, = that could be, in the context of LSP trace, either destination IP = addresses (multipath type {2, 4, 8}) or Entropy Labels (multipath type = {9}) or both (multipath type {10}). You tripped me with L2 only interfaces/sub if. Hence the question, = whether L3 header is taken into consideration. >=20 >>=20 >> 3. If in Q #2 Label stack there exists different label stack for each = lag >> member, is there a downside to using separate DDMAP for each LAG >> member? i.e. w/o any enhancement? >=20 > Same label, see above. >=20 >>=20 >> 4. Also, how is DDMAP interface info validated? I believe the LAG = member >> link # is local. What all fields being validated for LAG interface? >=20 > When MPLS echo request traverses over all LAG members (i.e. different = interface index) to the nexthop, then the packets should have terminated = on different incoming LAG members at the downstream (different interface = index). >=20 > For supported/unsupported scenarios, please view: = http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-00#appe= ndix-A I think appendix sections are very imp to consider and should be in main = sections. =46rom high level, this addition will help discover various LAG members = associated with the data path of an LSP. But I think it is difficult to = validate against a given FEC. Because the DDMAP info of LAG member sent = cannot be validated. If it is indeed could be validated, should be = documented in the ID.=20 >=20 >>=20 >> Responses will clarify for me to review better. :D >=20 > Looking forward to seeing more comments from you, hopefully not as = harsh as the Reply Mode extension draft :) It is just a beginning and hope you won't conclude with reply mode 1. :D -sam >=20 > Thanks! >=20 > -Nobo >=20 >>=20 >> -sam >>=20 >>=20 >> On Jun 13, 2014, at 2:14 PM, Nobo Akiya (nobo) = wrote: >>=20 >>> Dear MPLS WG, >>>=20 >>> On MPLS data plane, one aspect which OAM is blind to traffic black = holing >> is when LSPs are traversing over LAG interfaces. We would like to = propose >> an extension to RFC4379 to provide the tool an ability to discover = and >> traverse LAG members. >>>=20 >>> It will be very helpful if you could review this document, provide >> comments and help us standardize this extension. >>>=20 >>> Thanks! >>>=20 >>> -Nobo, on behalf of authors >>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Friday, June 13, 2014 5:04 PM >>>> To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow); >>>> George Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno >>>> Decraene; Nobo Akiya (nobo); John Drake; Stephane Litkowski >>>> Subject: New Version Notification for = draft-akiya-mpls-lsp-ping-lag- >>>> multipath-00.txt >>>>=20 >>>>=20 >>>> A new version of I-D, = draft-akiya-mpls-lsp-ping-lag-multipath-00.txt >>>> has been successfully submitted by Nobo Akiya and posted to the = IETF >>>> repository. >>>>=20 >>>> Name: draft-akiya-mpls-lsp-ping-lag-multipath >>>> Revision: 00 >>>> Title: Label Switched Path (LSP) Ping/Trace Multipath >> Support for >>>> Link Aggregation Group (LAG) Interfaces >>>> Document date: 2014-06-13 >>>> Group: Individual Submission >>>> Pages: 18 >>>> URL: = http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp- >> ping- >>>> lag-multipath-00.txt >>>> Status: = https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping- >> lag- >>>> multipath/ >>>> Htmlized: = http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag- >>>> multipath-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> This document defines an extension to the Multiprotocol Label >>>> Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to >>>> describe Multipath Information for Link Aggregation (LAG) member >>>> links separately, thus allowing MPLS LSP Ping and Traceroute to >>>> discover and exercise specific paths of layer 2 Equal-Cost = Multipath >>>> (ECMP) over LAG interfaces. >>>>=20 >>>> This document updates RFC4379 and RFC6424. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >> tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 From nobody Mon Jul 7 21:47:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BEA1B2A25 for ; Mon, 7 Jul 2014 21:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvKHu4WfVmz4 for ; Mon, 7 Jul 2014 21:46:29 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880341A0ADC for ; Mon, 7 Jul 2014 21:46:29 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id s684kSwY028894 for ; Tue, 8 Jul 2014 13:46:28 +0900 (JST) Received: from mailsv.nec.co.jp (imss61.nec.co.jp [10.7.69.156]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id s684kRE14013 for ; Tue, 8 Jul 2014 13:46:27 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id s684kRCZ025816 for ; Tue, 8 Jul 2014 13:46:27 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.146] [10.38.151.146]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-382439; Tue, 8 Jul 2014 13:45:31 +0900 Received: from BPXM18GP.gisp.nec.co.jp ([169.254.2.157]) by BPXC18GP.gisp.nec.co.jp ([10.38.151.146]) with mapi id 14.02.0328.011; Tue, 8 Jul 2014 13:45:31 +0900 From: Zhenlong Cui To: "mpls@ietf.org" Thread-Topic: MPLS-TP multi-failure protection Thread-Index: Ac+aZtbSwSLShHxfT7qgOwu7VnDdKQ== Date: Tue, 8 Jul 2014 04:45:31 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.38.126.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/d6H6e_KOK4tY-p0Ht-KQ8qTBigQ Subject: [mpls] MPLS-TP multi-failure protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 04:47:06 -0000 RGVhciBBbGwsDQoNCldlJ3ZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt Y3VpLW1wbHMtdHAtbWZwLXVzZS1jYXNlLWFuZC1yZXF1aXJlbWVudHMtMDIgYXMgc2hvd24gaW4g dGhlIGZvbGxvd2luZyBlLW1haWwuDQoNCiAtSGlzdG9yeQ0KICBPbGRlciB2ZXJzaW9uKC0wMSkg aW5jbHVkZXMgbToxLCBidXQgbm90IG06bi4NCg0KIC1QdXJwb3NlIG9mIHRoZSBuZXcgdmVyc2lv bi4NCiAgRXh0ZW5kIHRoZSBzY29wZSB0byBjb3ZlciBtOm4sIGJlY2F1c2UgaXQgbWVldHMgdGhl IGN1c3RvbWVyIG5lZWRzIHdlbGwuDQoNCg0KQW55IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIHdv dWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIA0KDQoNClRoYW5rIHlvdSwNCnpoZW5sb25nDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwg SnVseSAwNSwgMjAxNCAzOjQ5IEFNDQpUbzogTWFzYWhpcm8gRGFpa29rdTsgUm9sZiBXaW50ZXI7 IFNhbSBBbGRyaW47IEhpbWFuc2h1IEMuIFNoYWg7IEN1aSBaaGVubG9uZyjltJQg54+N6b6NKTsg Um9sZiBXaW50ZXI7IE1hc2FoaXJvIERhaWtva3U7IEhpbWFuc2h1IFNoYWg7IFNhbSBBbGRyaW47 IEN1aSBaaGVubG9uZyjltJQg54+N6b6NKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1jdWktbXBscy10cC1tZnAtdXNlLWNhc2UtYW5kLXJlcXVpcmVtZW50cy0w Mi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY3VpLW1wbHMtdHAtbWZwLXVz ZS1jYXNlLWFuZC1yZXF1aXJlbWVudHMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFpoZW5sb25nIEN1aSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6CQlkcmFmdC1jdWktbXBscy10cC1tZnAtdXNlLWNhc2UtYW5kLXJlcXVpcmVtZW50 cw0KUmV2aXNpb246CTAyDQpUaXRsZToJCVVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIGZvciBN UExTLVRQIG11bHRpLWZhaWx1cmUgcHJvdGVjdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wNy0w NA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNw0KVVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWN1aS1tcGxzLXRw LW1mcC11c2UtY2FzZS1hbmQtcmVxdWlyZW1lbnRzLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1tcGxzLXRwLW1mcC11c2Ut Y2FzZS1hbmQtcmVxdWlyZW1lbnRzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWN1aS1tcGxzLXRwLW1mcC11c2UtY2FzZS1hbmQtcmVxdWlyZW1lbnRz LTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtY3VpLW1wbHMtdHAtbWZwLXVzZS1jYXNlLWFuZC1yZXF1aXJlbWVudHMtMDINCg0KQWJzdHJh Y3Q6DQogICBUaGUgYmFzaWMgc3Vydml2YWJpbGl0eSB0ZWNobmlxdWUgaGFzIGJlZW4gZGVmaW5l ZCBpbiBNdWx0aXByb3RvY29sDQogICBMYWJlbCBTd2l0Y2hpbmcgVHJhbnNwb3J0IFByb2ZpbGUg KE1QTFMtVFApIG5ldHdvcmsgW1JGQzYzNzhdLiAgVGhhdA0KICAgcHJvdG9jb2wgaG93ZXZlciBp cyBsaW1pdGVkIHRvIDErMSBhbmQgMToxIHByb3RlY3Rpb24sIG5vdCBkZXNpZ25lZA0KICAgdG8g aGFuZGxlIG11bHRpLWZhaWx1cmUgcHJvdGVjdGlvbi4NCg0KICAgVGhpcyBkb2N1bWVudCBpbnRy b2R1Y2VzIHNvbWUgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgZm9yIG11bHRpLQ0KICAgZmFp bHVyZSBwcm90ZWN0aW9uIGZ1bmN0aW9uYWxpdHkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From nobody Tue Jul 8 03:56:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54D11B2A29 for ; Tue, 8 Jul 2014 03:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLv0kdc3IgfT for ; Tue, 8 Jul 2014 03:56:31 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id A57A11B2800 for ; Tue, 8 Jul 2014 03:56:31 -0700 (PDT) Received: (qmail 30992 invoked by uid 0); 8 Jul 2014 10:56:26 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 8 Jul 2014 10:56:26 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id PmwK1o00N2SSUrH01mwN9f; Tue, 08 Jul 2014 04:56:25 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=zqHLjNqbk_wA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=7xPyp7LSBkGDkgT6ofoA:9 a=3rl6ZFYCiICjTTEz:21 a=DJTLcd-5B76n8cFT:21 a=QEXdDO2ut3YA:10 a=33rK67OTR_gA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QRBioTGF407aBSfevLLg+Qv45Zy/+6tNFYt6HIMCJiU=; b=d7DyaLADFY2OPWMjLtvRkjXnVtKfiycMAE3/MwM/UtN9qQYV1jwFcd5+o6zZe1xH4ay+5L+L3h1lRh6pmYnM/EkZAxbrgYSALhEJiz1MkGLZmKAY4Vc4uhXyO//UfnTq; Received: from box313.bluehost.com ([69.89.31.113]:51191 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X4T4O-0001eO-2y; Tue, 08 Jul 2014 04:56:20 -0600 Message-ID: <53BBCE48.7060008@labn.net> Date: Tue, 08 Jul 2014 06:56:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yaacov Weingarten , Jeong Ryoo References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sEBaCNWs5s_j8RqqBgZF7ZqkJaA Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 10:56:35 -0000 Yaacov, Sounds reasonable, but I'll need to see the new wording to be sure. Thanks, Lou On 7/5/2014 3:49 PM, Yaacov Weingarten wrote: > > Lou, hi > I would like to address two of your comments, in your follow-up > message, since I am the source of the change in terminology. > > Regarding the two occurences of "assigned" in place of "utilized" - > when I read the proposed changes,as discussed amongst the authors, I > felt that in those two instances the use of "utilized" could lead to > some ambiguity. > > If we state that "resources SHOULD be utilized on a first come first > served basis" this could be interpreted (IMO) as referring to the > packet level, rather than utilized by a specific path, such that > packets from different paths could be interspersed along the shared > segments. Therefore,I suggested that or this context it would be > better to use a word that meant that the first-come first served basis > was at the level of assigning (or allocating) the resources rather > than utilizing them. > > Hope this clarifies this point. I am certain that I speak for the > other authors in saying that I am open to other suggestions. > > BR, > yaacov > > On Jul 4, 2014 3:53 AM, "Jeong Ryoo" > wrote: > > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are > proposing our resolutions to your comments. Please, let us know if > the proposal is appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, > we concluded that the distinction between protection and > restoration should be aligned with the exiting documents > normatively referenced by this document. Accordingly, the > following 16 modifications will be done in revision: > > > > (1) Section 1, the third paragraph > > OLD: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 linear protection requires > > that resources are committed for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are committed, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > NEW: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 protection requires > > that resources are allocated for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are allocated, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > > > (2) The whole text in Section 3.1 will be replaced with: > > [RFC6372], based upon the definitions in [RFC4427], differentiates > between "protection" and "restoration" dependent upon the dynamism > of the resource allocation. The same distinction is used in > [RFC3945], [RFC4426], and [RFC4428]. This document also uses the > same distinction between protection and restoration as stated in > [RFC6372]. > > > > (3) In page 6, > > OLD: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine to which parties the protection > > resources are committed. > > NEW: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine which parties utilize the > protection > > resources. > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > > OLD: > > resources may be planned but would not be committed until … > > NEW: > > resources may be planned but would not be utilized until … > > > > (5) In the second paragraph in page 7, > > OLD: > > "Hard Preemption" requires the programming of selectors at the > ingress of each shared segment to specify which backup path has > the highest priority when committing protection resources, the > others being preempted. > > NEW > > "Hard Preemption" requires the programming of selectors at the > ingress of each shared segment to specify the priorities of backup > paths, so that traffic of lower priority paths can be preempted. > > > > (6) The first paragraph of Section 4.1: > > OLD: > > … and commit the associated resources. The commitment of resources > > is dependent upon … > > NEW: > > … and coordinate the utilization of the associated shared resources. > > The resource utilization coordination is dependent upon … > > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The > different working paths in > > the SMP network are involved in the resource utilization > coordination. > > . > > > > (8) Section 5.1, > > OLD: > > … and commit the associated resources. > > NEW > > … and coordinate the utilization of the associated shared resources. > > > > (9) In Section 5.1, > > OLD: > > In the case of multiple working paths failing, the commitment of the > > shared resources SHALL be coordinated between the different working > > paths in the SMP network. > > NEW: > > In the case of multiple working paths failing, the shared resource > utilization > > coordination SHALL be between the different working > > paths in the SMP network. > > > > (10) Section 5.1.1. > > OLD: > > … because they already have been committed to the protection of, > for example, a higher priority working path. > > NEW: > > … because they already have been utilized for the protection of, > for example, a higher priority working path. > > > > (11) Section 5.2, the second bullet item: > > OLD: > > Resources of the shared segments SHALL be committed to the > > protection path … > > NEW: > > Resources of the shared segments SHALL be utilized by the > > protection path … > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > > (14) Section 5.2. the seventh bullet item > > OLD: > > Once resources of shared segments have been successfully committed > > to a protection path, … > > NEW: > > Once resources of shared segments have been successfully utilized > > by a protection path, … > > > > (15) Section 5.3, the first paragraph, > > OLD: > > … request the commitment of protection resources. If the necessary > > shared resources are unavailable to be committed to the protection > > path, the endpoints … > > > > NEW: > > … request the coordination of the shared resource utilization. If > the necessary > > shared resources are unavailable, the endpoints … > > > > (16) Section 5.3, the second paragraph, > > OLD: > > Similarly, if preemption is supported and the resources currently > > committed for a particular working path are … > > NEW: > > Similarly, if preemption is supported and the resources currently > > utilized by a particular working path are … > > > > > > - Section 2, 1st paragraph, last sentence. This sentence really > defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > “This document is intended to clarify the instructions to protocol > designers producing solutions that satisfy the requirements set > out in this document.” > > > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in > the PSC linear protection switching, such as RFC 6378 (PSC) and > RFC 7271 (PSC in APS mode), fate-sharing is not required as > unidirectional switching is allowed. This document does not impose > any restriction on co-routing, either. > > > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and > hard preemptions in the context of extra traffic, which is not > exactly the case for SMP. > > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use > SHALL NOT. > > > > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal > priority requests, i.e., when the requests occur simultaneously,, > tie-breaking rules SHALL be defined in scope of an SMP domain. > > > > > > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > “As described in [RFC6372], the event of preemption may be > detected by OAM and reported as a fault or a degradation of > traffic delivery.” > > > - Section 5.7. There may be coordination required on > soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from “SMP in > hard-preemption mode SHOULD …” to “SMP SHOULD …” and move the > changed paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used > in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > “The MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.” > > > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really > introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for > SMP. Some text of Section 2 is repeated in Section 1 as you > suggested earlier. > > > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as > closely as possible to provide fast protection. > > > > > - Section 5.2. I suggest numbering the currently bulletted > requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the > fourth bullet belongs to the requirements of hard-preemption. > > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > > > - Section 5.2: requirement 6 seems to be a subset of 7, so it > should be > dropped. > > [Authors] Yes, it will be deleted. > > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control > plane supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that “When the condition that > triggered the protection switching is cleared, …” > > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes > of operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add “as described in [RFC6372]” to the ends of > two paragraphs for WTR timer and hold-off timer. > > > > ***** End of Comment resolution ***** > > > > > > > ------------------------------------------------------------------------ > *보낸 사람 : *"Lou Berger" > > *보낸 날짜 : *2014-06-22 01:00:48 ( +09:00 ) > *받는 사람 : *rtg-ads@tools.ietf.org > > > *참조 : *rtg-dir@ietf.org > >, > draft-ietf-mpls-smp-requirements.all@tools.ietf.org > > >, > mpls@ietf.org > > *제목 : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt > > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information > about the > Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing > ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them > through > discussion or by updating the draft. > > Document: draft-ietf-mpls-smp-requirements-06.txt > Reviewer: Lou Berger > Review Date: June 21 2014 > IETF LC End Date: 2014-06-23 > Intended Status: Informational > > Summary: > I have some minor concerns about this document that I think > should (must, actually) be resolved before publication. > > Comments: > > I think the document is well written and, other than a couple of > terminology related issues, easily understood. The document does > have a number of terminology and technical issues which should be > readily resolved prior to publication. > > Major Issues: > > Major issues are the type of concerns that will result in the > document being blocked until they are resolved. The Routing ADs will > become involved. Please include all of the major issues you have > found. Give as much context information as possible (e.g., section > numbers, paragraph counts). If you find no major issues, please > write: "No major issues found." > > - No major issues found. In particular, I expect all issues can be > resolved without AD intervention. Some of the minor issues, if not > resolved will be escalated to the AD/major issue category. > > Minor Issues: > > Minor issues are concerns about clarity or technical accuracy that > should be discussed and resolved before publication, but which would > normally be resolved between the authors and the reviewers. Please > include all of the minor issues you have found. Give as much context > information as possible (e.g., section numbers, paragraph counts). > If you find no minor issues, please write: "No minor issues found." > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > - Section 2, 1st paragraph, last sentence. This sentence really > defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > - Section 5.7. There may be coordination required on > soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > Nits: > > - Abstract: I don't recall the term "executive action" being used > in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > - Sections 3 (and to a lesser degree section 2) are really > introductory > text. I'm unsure as to why they aren't part of section 1. > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > - Section 3.2 again uses the "executive action" term. > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > - Section 5.2. I suggest numbering the currently bulletted > requirements > list. > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > - Section 5.2: requirement 6 seems to be a subset of 7, so it > should be > dropped. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > - Section 5.3. s/MAY/will > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > - section 5.6. RFC 6372 should be referenced > > > _______________________________________________ > 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 nobody Tue Jul 8 18:23:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B891A01C3; Tue, 8 Jul 2014 18:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNJIFr1xQvE1; Tue, 8 Jul 2014 18:23:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D6E1A011B; Tue, 8 Jul 2014 18:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6860; q=dns/txt; s=iport; t=1404869033; x=1406078633; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0RwxNhp2JxsGaFwtOQBCHYSgb/qOinP3jMeW6OLFoYU=; b=WrQibg62f/QelHq8sF2KMq4ONH48h99uh2n3T9nElT7HzjlUMpFrDsLo 69Y+aywgwFE9C+6+kVjm0kNqcDNloOstmEM9afrHCMmjVKos3ezSXI5rV sO433ImncT1DZcJ718Eu8JAVLZ2OtH+PxtYZkt8wWVEGqmmFjI7UGRjMv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAICZvFOtJV2b/2dsb2JhbABagmokUlqCb7xAh0EBGX0WdYQDAQEBAwEjEUMCDAQCAQYCEQQBAQMCBh0DAgICMBQBCAgCBAENBQgBiDEIAQySJZwnhU+UDheBLI1lBisHBAKCcTaBFgWcPpJEggGBQoIw X-IronPort-AV: E=Sophos;i="5.01,629,1400025600"; d="scan'208";a="338657813" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2014 01:23:43 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s691NhPF005166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 01:23:43 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 20:23:43 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" Thread-Topic: New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt Thread-Index: AQHPl4mF1OunTubKs0CpX824dSlWBZuQXyiAgAUao4CAAXaOAA== Date: Wed, 9 Jul 2014 01:23:42 +0000 Message-ID: References: <20140704131127.29231.56989.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D34623EBA@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7E7AC7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7E7AC7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/poRM-WYipbujWh-7_1ywhkphlXk Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-vgovindan-mpls-extended-bfd-disc-tlv-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 01:23:55 -0000 SGkgR3JlZywgUHJhc2FkLCBldCBhbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg R3JlZ29yeSBNaXJza3kNCj4gU2VudDogTW9uZGF5LCBKdWx5IDA3LCAyMDE0IDU6MjkgUE0NCj4g VG86IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk7IHJ0Zy1iZmRAaWV0Zi5vcmcN Cj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLQ0KPiBleHRlbmRlZC1iZmQtZGlz Yy10bHYtMDAudHh0DQo+IA0KPiBIaSBQcmFzYWQsDQo+IHRoaXMgaXMgdmVyeSBpbnRlcmVzdGlu ZyBwcm9wb3NhbCBhbmQgSSB0aGluayB0aGF0IHRoZSBNUExTIFdHIHdpbGwgYmUNCj4gaW50ZXJl c3RlZCBpbiB0aGUgZGlzY3Vzc2lvbi4gQ291cGxlIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6DQo+ IOKAoiBJIGJlbGlldmUgdGhhdCBtb25pdG9yaW5nIG9mIEVDTVAgc2VnbWVudHMgb24gbGluayBs YXllciBpcyBtb3JlIGVmZmljaWVudA0KPiBjb21wYXJpbmcgdG8gZTJlIG1vbml0b3JpbmcuIFRo ZSBkb2N1bWVudCBzdWdnZXN0cyBvdGhlcndpc2UuIENvdWxkIHlvdQ0KPiBnaXZlIHNjZW5hcmlv cyBvciB1c2UgY2FzZXMgdGhhdCBzdXBwb3J0IHVzZWZ1bG5lc3Mgb2YgbXVsdGlwbGUgQkZEIHNl c3Npb25zDQo+IGJldHdlZW4gdGhlIHNhbWUgcGVlcnMsIGdpdmVuIHRoYXQgeW91IG5lZWQgdG8g Y29udHJvbCBtYXBwaW5nIG9mIEJGRA0KPiBzZXNzaW9ucyB0byBhIHBhcnRpY3VsYXIgcGF0aDsN Cg0KQSBiaXQgb2YgYSBiYWNrZ3JvdW5kIG9uIHRoaXMgZG9jdW1lbnQuDQoNCkVWUE4gaXMgdmVy eSBrZWVuIG9uIHdhbnRpbmcgdG8gdXNlIEJGRCBwZXIgRUwgKG9yIHN1YnNldCBvZiB0aGUgRUxz KSB0byBtZWV0IHRoZWlyIHJlcXVpcmVtZW50cy4gVGhlc2UgYXJlIGRlc2NyaWJlZCBpbjoNCg0K ZHJhZnQtc2FsYW0tbDJ2cG4tZXZwbi1vYW0tcmVxLWZybXdrDQpkcmFmdC12Z292aW5kYW4tbDJ2 cG4tZXZwbi1iZmQNCg0KV2l0aCB0aGF0IHNhaWQsIEkgZnVsbHkgYWdyZWUgdGhhdCB0aGVyZSBp cyBnb2luZyB0byBiZSBhIGh1Z2UgaW1wYWN0IHRvIEJGRCBzY2FsZSBpZiB3ZSBhcmUgdG8gcHJv Y2VlZCBkb3duIHRoaXMgcGF0aCwgYW5kIHRoaXMgc2hvdWxkIGJlIGNvbnNpZGVyZWQvZGlzY3Vz c2VkIGluIGEgZ3JvdXAgdGhhdCBpbmNsdWRlcyBCRkQgZm9sa3MuDQoNCk5vdGUgdGhhdCB0aGUg Zm9ybWF0IG9mIHRoZSBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYg aXMga2VwdCBnZW5lcmljIHNvIHRoYXQgbXVsdGlwbGUgc2Vzc2lvbnMgYXJlIGFic3RyYWN0ZWQg YnkgIkluc3RhbmNlIElkZW50aWZpZXIiIHJhdGhlciB0aGFuIGJvb3N0cmFwcGVkIEJGRCBzZXNz aW9ucyBiZWluZyBzdHJpY3RseSB0aWVkIHRvIHNvbWV0aGluZyBlbHNlIChsaWtlIEVMIHZhbHVl KS4gU28gdGhlIGRyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdiB3YXMg Y3JlYXRlZCBhcyByZXN1bHQgb2YgRVZQTiByZXF1aXJlbWVudCBidXQgZHJhZnQtdmdvdmluZGFu LW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2IGl0c2VsZiBpcyBhIGdlbmVyaWMgZG9jdW1lbnQu DQoNCj4g4oCiIGFub3RoZXIgdXNlIGNhc2UgdG8gc3VwcG9ydCBtdWx0aXBsZSBCRkQNCj4gc2Vz c2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwZWVycyBpcyBPQU0gcmVkdW5kYW5jeS4gV2hhdCB5b3Ug c2VlIGFzIHRoZQ0KPiBtYWluIGJlbmVmaXQgdGhlcmU/IEhvdyB0byBtYW5hZ2UgZGV0ZWN0aW9u IHRpbWVzIGFtb25nIG11bHRpcGxlIEJGRA0KPiBzZXNzaW9ucz8NCg0KSG93IG1hbnkgc2Vzc2lv bnMgYSBub2RlIGJvb3RzdHJhcHMgZm9yIGEgc2FtZSBGRUMvcGF0aCB0byB0aGUgcmVtb3RlIG5v ZGUsIHdoeSBhbmQgaG93IHRob3NlIHNlc3Npb25zIGFyZSByZWxhdGVkIGlzIGEgbG9jYWwgbWF0 dGVyLiBQZXJoYXBzIHRoYXQgc2hvdWxkIGJlIHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCj4g 4oCiIGhhdmUgeW91IGxvb2tlZCBhdCBTZWN0aW9uIDIuMi4xIG9mIHRoZSBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbXBscy10cC0NCj4gb2FtLWNvbmYgYW5kIFNlY3Rpb24gMy4zIG9mIHRoZSBk cmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0DQoNClRoYW5rcyBmb3IgdGhl IHBvaW50ZXIuIFllcyB3ZSBjYW4gY2VydGFpbmx5IGV4dGVuZCB0aG9zZSBUTFZzIGluc3RlYWQg aWYgdGhhdCBpcyB0aGUgY29uc2Vuc3VzLg0KDQpUaGUgb3RoZXIgYXNwZWN0IG9mIGRyYWZ0LXZn b3ZpbmRhbi1tcGxzLWV4dGVuZGVkLWJmZC1kaXNjLXRsdiB0aGF0IHdpbGwgYmUgYmVuZWZpY2lh bCB0byBnZXQtZmVlZGJhY2svZGlzY3VzcyBpcyBBcHBlbmRpeCBBIGluIHRoZSBkb2N1bWVudCwg d2hldGhlciBvciBub3Qgd2UgYXJlIGhhcHB5IHdpdGggaW1wbGljaXQgYXNzdW1wdGlvbiBvZiBi b290c3RyYXBwZWQgQkZEIHNlc3Npb24gYmVpbmcgZGVsZXRlZCBbc29tZXRpbWUgYWZ0ZXJdIHRo b3NlIHNlc3Npb25zIGdvIGRvd24uDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KPiANCj4gUmVnYXJk cywNCj4gwqDCoMKgwqDCoMKgwqAgR3JlZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFZlbmdhZGENCj4gUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkNCj4gU2VudDog RnJpZGF5LCBKdWx5IDA0LCAyMDE0IDg6MzMgQU0NCj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4g U3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdmdvdmluZGFu LW1wbHMtZXh0ZW5kZWQtDQo+IGJmZC1kaXNjLXRsdi0wMC50eHQNCj4gDQo+IEhlbGxvIGFsbCwN Cj4gwqAgV2UgaGF2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQgb3V0bGluaW5nIGEgcHJvcG9zYWwgdG8g ZXh0ZW5kIHRoZSBCRkQNCj4gRGlzY3JpbWluYXRvciBUTFYgb2YgdGhlIE1QTFMgcGluZyB0byBi b290c3RyYXAgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGZvciBhDQo+IDxNUExTIEZFQywgTFNQPiB0 dXBsZS4gUGxlYXNlIGxldCB1cyBrbm93IHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cywNCj4gc3Vn Z2VzdGlvbnMgYWJvdXQgdGhpcyBkcmFmdC4NCj4gVGhhbmtzDQo+IFByYXNhZA0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBGcmlkYXksIEp1bHkg MDQsIDIwMTQgNjo0MSBQTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibyk7IFZlbmdhZGEgUHJhc2Fk IEdvdmluZGFuICh2ZW5nZ292aSk7IE5vYm8gQWtpeWENCj4gKG5vYm8pOyBWZW5nYWRhIFByYXNh ZCBHb3ZpbmRhbiAodmVuZ2dvdmkpDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLQ0KPiBkaXNjLXRsdi0wMC50 eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmdvdmluZGFuLW1wbHMt ZXh0ZW5kZWQtYmZkLWRpc2MtdGx2LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgdG8NCj4gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6wqDCoMKgwqDCoMKgwqDCoMKgwqAgZHJhZnQtdmdv dmluZGFuLW1wbHMtZXh0ZW5kZWQtYmZkLWRpc2MtdGx2DQo+IFJldmlzaW9uOsKgwqDCoMKgwqDC oCAwMA0KPiBUaXRsZTrCoMKgwqDCoMKgwqDCoMKgwqAgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQ KSBQaW5nIEV4dGVuZGVkIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPiBEZXRlY3Rpb24gKEJG RCkgRGlzY3JpbWluYXRvciBUTFYgRG9jdW1lbnQgZGF0ZTrCoCAyMDE0LTA3LTA0DQo+IEdyb3Vw OsKgwqDCoMKgwqDCoMKgwqDCoCBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6wqDCoMKg wqDCoMKgwqDCoMKgIDgNCj4gVVJMOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdmdvdmluZGFuLW1wbHMtDQo+IGV4dGVuZGVk LWJmZC1kaXNjLXRsdi0wMC50eHQNCj4gU3RhdHVzOsKgwqDCoMKgwqDCoMKgwqAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdmdvdmluZGFuLW1wbHMtDQo+IGV4dGVuZGVk LWJmZC1kaXNjLXRsdi8NCj4gSHRtbGl6ZWQ6wqDCoMKgwqDCoMKgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXZnb3ZpbmRhbi1tcGxzLWV4dGVuZGVkLQ0KPiBiZmQtZGlzYy10bHYt MDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gwqDCoCBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4g ZXh0ZW5kZWQgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KPiDCoMKgIChCRkQp IGRpc2NyaW1pbmF0b3IgVExWIGZvciB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg KE1QTFMpDQo+IMKgwqAgTGFiZWwgU3dpdGNoZWQgUGF0aCAoTFNQKSBQaW5nIG1lY2hhbmlzbSwg dG8gYWxsb3cgYm9vdHN0cmFwcGluZyBvZg0KPiDCoMKgIG11bHRpcGxlIEJGRCBzZXNzaW9ucyBm b3IgYSBnaXZlbiBGRUMuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IA0K From nobody Wed Jul 9 03:41:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EEC1A03EA for ; Wed, 9 Jul 2014 03:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq71ndJ16MJG for ; Wed, 9 Jul 2014 03:41:02 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117161A03E9 for ; Wed, 9 Jul 2014 03:41:01 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id w8so5924744qac.11 for ; Wed, 09 Jul 2014 03:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0289eQZ/FBDy5VPfjhkRvTzxLLVYmKvRdxIJUpawe44=; b=s38cMeUFxLmHEYDijwNb5A21CN+VYXqZLROeUrvzcyQzKHFC7lRHWPSkdLyRb08cSA kvT4bh5PaZn8GQSRTqXZ9uaHxddR9fV1s2IjEljQJqI9FkIkPv8/+rHsJ3tZoZZsjNoP ViixBmkN7ZhZvj1GPndV22L6/uH44w7m5yOWzWdzXtWIMWcpLH3J1Gi0qN3Bt3/3KntH uRczYktWbLwWMx/ZSfVj4M1Zmw6P1/3IZoYka75w53LFYP/gM9s1FU4gRdIpO0hrJLc8 2HPK1BkVyzgQwfKT8t7TYuQBQi8ybqn2K93XnT0sMxbBc2nThMpNys3bbOO7RxPOJxYt wcyw== MIME-Version: 1.0 X-Received: by 10.140.30.73 with SMTP id c67mr64439211qgc.16.1404902461280; Wed, 09 Jul 2014 03:41:01 -0700 (PDT) Received: by 10.224.93.10 with HTTP; Wed, 9 Jul 2014 03:41:01 -0700 (PDT) Date: Wed, 9 Jul 2014 18:41:01 +0800 Message-ID: From: weiqiang cheng To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113a35a42617f904fdc05823 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/B8oB2RV8A8WZEPNLuyT8QFYhKQ0 Cc: "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" Subject: [mpls] =?utf-8?q?=5BMPLS=5D_Any_comments_on_the_draft_of_MPLS-TP_?= =?utf-8?q?Shared-Ring_protection_=28MSRP=29_mechanism_for_ring_topology?= =?utf-8?b?4oCdID8=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 10:41:03 -0000 --001a113a35a42617f904fdc05823 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi There, We uploaded the new version draft =E2=80=9CMPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology=E2=80=9D https://datatracker.ietf.org/doc/draft-cheng-mpls-tp-shared-ring-protection= / We authors would like to see comments on this draft. Please help to review it and It would be highly appreciated to send your comments on the mailing list. Thanks, Weiqiang Cheng --001a113a35a42617f904fdc05823 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi There,
We uploaded the new version draft =E2=80=9CMPLS-TP Shared-Ring protection (MSRP) mechanism for ring topolo=
gy=E2=80=9D
https://datatracker.ietf.org/doc/dr=
aft-cheng-mpls-tp-shared-ring-protection/
We authors would like to see comments on this draft. Please help=
 to review it and It would be highly appreciated to send your comments on t=
he mailing list.
=C2=A0
Than=
ks,
Weiqiang Cheng
--001a113a35a42617f904fdc05823-- From nobody Wed Jul 9 04:08:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9821A03F2 for ; Wed, 9 Jul 2014 04:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.55 X-Spam-Level: * X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6aWe-9NDmlu for ; Wed, 9 Jul 2014 04:07:54 -0700 (PDT) Received: from BLU004-OMC4S21.hotmail.com (blu004-omc4s21.hotmail.com [65.55.111.160]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB591A03F1 for ; Wed, 9 Jul 2014 04:07:53 -0700 (PDT) Received: from BLU168-W15 ([65.55.111.136]) by BLU004-OMC4S21.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Wed, 9 Jul 2014 04:07:53 -0700 X-TMN: [P6gS2EjPHKDVeb0USgmbECHx8NEaX6yT] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_00624080-bee7-48fc-b086-c90df0cdde6a_" From: =?gb2312?B?1Pi+/rKo?= To: "mpls@ietf.org" , "chengwq@gmail.com" Date: Wed, 9 Jul 2014 19:07:52 +0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2014 11:07:53.0175 (UTC) FILETIME=[077EBE70:01CF9B66] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/7UMJ7Duhkwd3Z36NstuFtOQIxzg Cc: "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" Subject: Re: [mpls] =?gb2312?b?W01QTFNdIEFueSBjb21tZW50cyBvbiB0aGUgZHJhZnQg?= =?gb2312?b?b2YgTVBMUy1UUCBTaGFyZWQtUmluZyBwcm90ZWN0aW9uIChNU1JQKSBtZWNo?= =?gb2312?b?YW5pc20gZm9yIHJpbmcgdG9wb2xvZ3mhsSA/?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 11:07:55 -0000 --_00624080-bee7-48fc-b086-c90df0cdde6a_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksV2VpcWlhbmcgQ2hlbmcNCiAgICAgIGkgaGF2ZSBzb21lIHF1ZXN0aW9uIGFib3V0IHRoZSAi ZHJhZnQtY2hlbmctbXBscy10cC1zaGFyZWQtcmluZy1wcm90ZWN0aW9uLTAyIi4NCiAgMS4gIHRo ZSBkaWZmZXJlbnQgYmV0d2VlbiAibm9ybWFsIHdyYXBwaW5nIiBhbmQgIlAyUCBzaG91dCB3cmFw cGluZyIuDQogIDIuICBjYW4gaSB1c2UgdGhlIFJJTkcgQVBTIHByb3RvY29sIGRlZmluZWQgaW4g Ry44MTMyIHRvIGltcGxlbWVudCB0aGUgc2NoZW1lIG9mIHRoaXMgZG9jdW1lbnQuDQogIDMuICBm b3IgdGhlICdkdWFsLW5vZGUgaW50ZXJjb25uZWN0ZWQgcmluZ3MnLCB0aGVyZSBtdXN0IGJlIHRo ZSBzYW1lIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiBub2RlIEMgYW5kIG5vZGUgRCBp biBmaWd1cmUgMTE/DQoNCkJlc3QgUmVnYXJkcyEgDQpCb0JvDQoNCg0KRGF0ZTogV2VkLCA5IEp1 bCAyMDE0IDE4OjQxOjAxICswODAwDQpGcm9tOiBjaGVuZ3dxQGdtYWlsLmNvbQ0KVG86IG1wbHNA aWV0Zi5vcmcNCkNDOiBkcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb25A dG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBbTVBMU10gQW55IGNvbW1lbnRzIG9uIHRo ZSBkcmFmdCBvZiBNUExTLVRQIFNoYXJlZC1SaW5nIHByb3RlY3Rpb24gKE1TUlApIG1lY2hhbmlz bSBmb3IgcmluZyB0b3BvbG9neaGxID8NCg0KSGkgVGhlcmUsV2UgdXBsb2FkZWQgdGhlIG5ldyB2 ZXJzaW9uIGRyYWZ0IKGwTVBMUy1UUCBTaGFyZWQtUmluZyBwcm90ZWN0aW9uIChNU1JQKSBtZWNo YW5pc20gZm9yIHJpbmcgdG9wb2xvZ3mhsQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb24vV2UgYXV0aG9ycyB3 b3VsZCBsaWtlIHRvIHNlZSBjb21tZW50cyBvbiB0aGlzIGRyYWZ0LiBQbGVhc2UgaGVscCB0byBy ZXZpZXcgaXQgYW5kIEl0IHdvdWxkIGJlIGhpZ2hseSBhcHByZWNpYXRlZCB0byBzZW5kIHlvdXIg Y29tbWVudHMgb24gdGhlIG1haWxpbmcgbGlzdC4KIFRoYW5rcyxXZWlxaWFuZyBDaGVuZwoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm1wbHMgbWFpbGlu ZyBsaXN0Cm1wbHNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzIAkJIAkgICAJCSAg --_00624080-bee7-48fc-b086-c90df0cdde6a_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5Os6iyO3RxbraDQp9DQotLT48L3N0eWxlPjwvaGVhZD4NCjxib2R5IGNsYXNzPSdo bW1lc3NhZ2UnPjxkaXYgZGlyPSdsdHInPmhpLFdlaXFpYW5nIENoZW5nPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpIGhhdmUgc29tZSBxdWVzdGlvbiBhYm91dCB0aGUgImRyYWZ0 LWNoZW5nLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbi0wMiIuPGJyPiZuYnNwOyAxLiZu YnNwOyB0aGUgZGlmZmVyZW50IGJldHdlZW4gIm5vcm1hbCB3cmFwcGluZyIgYW5kICJQMlAgc2hv dXQgd3JhcHBpbmciLjxicj4mbmJzcDsgMi4mbmJzcDsgY2FuIGkgdXNlIHRoZSBSSU5HIEFQUyBw cm90b2NvbCBkZWZpbmVkIGluIEcuODEzMiB0byBpbXBsZW1lbnQgdGhlIHNjaGVtZSBvZiB0aGlz IGRvY3VtZW50Ljxicj4mbmJzcDsgMy4mbmJzcDsgZm9yIHRoZSAnZHVhbC1ub2RlIGludGVyY29u bmVjdGVkIHJpbmdzJywgdGhlcmUgbXVzdCBiZSB0aGUgc2FtZSBmb3J3YXJkaW5nIGluZm9ybWF0 aW9uIGJldHdlZW4gbm9kZSBDIGFuZCBub2RlIEQgaW4gZmlndXJlIDExPzxicj48YnI+QmVzdCBS ZWdhcmRzISA8YnI+Qm9Cbzxicj48YnI+PGJyPjxkaXY+PGhyIGlkPSJzdG9wU3BlbGxpbmciPkRh dGU6IFdlZCwgOSBKdWwgMjAxNCAxODo0MTowMSArMDgwMDxicj5Gcm9tOiBjaGVuZ3dxQGdtYWls LmNvbTxicj5UbzogbXBsc0BpZXRmLm9yZzxicj5DQzogZHJhZnQtY2hlbmctbXBscy10cC1zaGFy ZWQtcmluZy1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnPGJyPlN1YmplY3Q6IFttcGxzXSBbTVBM U10gQW55IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBvZiBNUExTLVRQIFNoYXJlZC1SaW5nIHByb3Rl Y3Rpb24gKE1TUlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neaGxID88YnI+PGJyPjxkaXYg ZGlyPSJsdHIiPjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIFRoZXJlLDwvc3Bhbj48L3ByZT48 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSB1cGxvYWRlZCB0aGUgbmV3IHZlcnNpb24gZHJhZnQg PC9zcGFuPqGwPHNwYW4gbGFuZz0iRU4tVVMiPk1QTFMtVFAgU2hhcmVkLVJpbmcgcHJvdGVjdGlv biAoTVNSUCkgbWVjaGFuaXNtIGZvciByaW5nIHRvcG9sb2d5PC9zcGFuPqGxPC9wcmU+CjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWNoZW5nLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbi8iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1tcGxz LXRwLXNoYXJlZC1yaW5nLXByb3RlY3Rpb24vPC9hPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5XZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gc2VlIGNvbW1lbnRzIG9uIHRoaXMg ZHJhZnQuIFBsZWFzZSBoZWxwIHRvIHJldmlldyBpdCBhbmQgSXQgd291bGQgYmUgaGlnaGx5IGFw cHJlY2lhdGVkIHRvIHNlbmQgeW91ciBjb21tZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0Ljwvc3Bh bj48L3ByZT4KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcHJlPjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+V2VpcWlhbmcgQ2hlbmc8L3NwYW4+PC9wcmU+PC9kaXY+Cjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwptcGxzIG1haWxpbmcgbGlzdAptcGxz QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvZGl2 PiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_00624080-bee7-48fc-b086-c90df0cdde6a_-- From nobody Wed Jul 9 04:10:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CFD1A03F6 for ; Wed, 9 Jul 2014 04:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5whzERFyS_36 for ; Wed, 9 Jul 2014 04:10:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFC61A03F1 for ; Wed, 9 Jul 2014 04:10:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU12193; Wed, 09 Jul 2014 11:10:51 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 12:10:27 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 19:10:24 +0800 From: "Dongjie (Jimmy)" To: weiqiang cheng , "mpls@ietf.org" Thread-Topic: =?utf-8?B?W21wbHNdIFtNUExTXSBBbnkgY29tbWVudHMgb24gdGhlIGRyYWZ0IG9mIE1Q?= =?utf-8?B?TFMtVFAgU2hhcmVkLVJpbmcgcHJvdGVjdGlvbiAoTVNSUCkgbWVjaGFuaXNt?= =?utf-8?B?IGZvciByaW5nIHRvcG9sb2d54oCdID8=?= Thread-Index: AQHPm2LAyQYWN4Lt20KSjepCmlFg25uXk54g Date: Wed, 9 Jul 2014 11:10:23 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927336BE7CD@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.76] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927336BE7CDnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Gf43HaHAi2ysPEUgUdMMWG_uYxQ Cc: "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" Subject: Re: [mpls] =?utf-8?q?=5BMPLS=5D_Any_comments_on_the_draft_of_MPLS-TP_?= =?utf-8?q?Shared-Ring_protection_=28MSRP=29_mechanism_for_ring_topology?= =?utf-8?b?4oCdID8=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 11:10:55 -0000 --_000_76CD132C3ADEF848BD84D028D243C927336BE7CDnkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzLA0KDQpJIGhhdmUgb25lIHF1aWNrIGNvbW1lbnQgb24gdGhpcyBkcmFmdDoN Cg0KU2luY2Ugd2UgaGF2ZSBMaW5lYXIgUHJvdGVjdGlvbiAoUFNDKSBhbmQgdGhlIHdvcmsgYmVp bmcgZG9uZSBvbiBTaGFyZWQgTWVzaCBQcm90ZWN0aW9uLCBkbyB3ZSBuZWVkIGRlZGljYXRlZCBw cm90ZWN0aW9uIHNvbHV0aW9uIGZvciByaW5nIHRvcG9sb2d5Pw0KDQpCZXN0IHJlZ2FyZHMsDQpK aWUNCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIHdlaXFpYW5nIGNoZW5nDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDksIDIwMTQgNjo0MSBQ TQ0KVG86IG1wbHNAaWV0Zi5vcmcNCkNjOiBkcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJlZC1yaW5n LXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBbTVBMU10gQW55IGNv bW1lbnRzIG9uIHRoZSBkcmFmdCBvZiBNUExTLVRQIFNoYXJlZC1SaW5nIHByb3RlY3Rpb24gKE1T UlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neeKAnSA/DQoNCg0KSGkgVGhlcmUsDQoNCldl IHVwbG9hZGVkIHRoZSBuZXcgdmVyc2lvbiBkcmFmdCDigJxNUExTLVRQIFNoYXJlZC1SaW5nIHBy b3RlY3Rpb24gKE1TUlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neeKAnQ0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJlZC1yaW5n LXByb3RlY3Rpb24vDQoNCldlIGF1dGhvcnMgd291bGQgbGlrZSB0byBzZWUgY29tbWVudHMgb24g dGhpcyBkcmFmdC4gUGxlYXNlIGhlbHAgdG8gcmV2aWV3IGl0IGFuZCBJdCB3b3VsZCBiZSBoaWdo bHkgYXBwcmVjaWF0ZWQgdG8gc2VuZCB5b3VyIGNvbW1lbnRzIG9uIHRoZSBtYWlsaW5nIGxpc3Qu DQoNCg0KDQpUaGFua3MsDQoNCldlaXFpYW5nIENoZW5nDQo= --_000_76CD132C3ADEF848BD84D028D243C927336BE7CDnkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYXV0aG9ycywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIGhhdmUgb25lIHF1aWNrIGNvbW1lbnQgb24gdGhpcyBkcmFmdDoNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSB3ZSBoYXZlIExpbmVhciBQcm90 ZWN0aW9uIChQU0MpIGFuZCB0aGUgd29yayBiZWluZyBkb25lIG9uIFNoYXJlZCBNZXNoIFByb3Rl Y3Rpb24sIGRvIHdlIG5lZWQgZGVkaWNhdGVkIHByb3RlY3Rpb24gc29sdXRpb24gZm9yIHJpbmcg dG9wb2xvZ3k/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkppZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj53ZWlxaWFuZyBjaGVuZzxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIEp1bHkgMDksIDIwMTQgNjo0MSBQTTxicj4NCjxiPlRvOjwvYj4gbXBsc0BpZXRmLm9y Zzxicj4NCjxiPkNjOjwvYj4gZHJhZnQtY2hlbmctbXBscy10cC1zaGFyZWQtcmluZy1wcm90ZWN0 aW9uQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttcGxzXSBbTVBMU10gQW55 IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBvZiBNUExTLVRQIFNoYXJlZC1SaW5nIHByb3RlY3Rpb24g KE1TUlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neeKAnSA/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+SGkgVGhlcmUsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5XZSB1cGxvYWRlZCB0aGUgbmV3IHZlcnNpb24gZHJhZnQg4oCcTVBMUy1UUCBT aGFyZWQtUmluZyBwcm90ZWN0aW9uIChNU1JQKSBtZWNoYW5pc20gZm9yIHJpbmcgdG9wb2xvZ3ni gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW5nLW1wbHMtdHAt c2hhcmVkLXJpbmctcHJvdGVjdGlvbi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWNoZW5nLW1wbHMtdHAtc2hhcmVkLXJpbmctcHJvdGVjdGlvbi88L2E+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBhdXRob3JzIHdvdWxk IGxpa2UgdG8gc2VlIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQuIFBsZWFzZSBoZWxwIHRvIHJldmll dyBpdCBhbmQgSXQgd291bGQgYmUgaGlnaGx5IGFwcHJlY2lhdGVkIHRvIHNlbmQgeW91ciBjb21t ZW50cyBvbiB0aGUgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5XZWlxaWFuZyBDaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_76CD132C3ADEF848BD84D028D243C927336BE7CDnkgeml512mbxchi_-- From nobody Wed Jul 9 05:04:22 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD161A04A2 for ; Wed, 9 Jul 2014 05:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pqkw8GpSzXg for ; Wed, 9 Jul 2014 05:04:15 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA0D1A04A1 for ; Wed, 9 Jul 2014 05:04:14 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id cm18so6204795qab.28 for ; Wed, 09 Jul 2014 05:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z/5dJdBFfsnjiZSW1xeQyNj4ZywmuNJkC8u0/7WlYJo=; b=oEs1GWoXgLhpx4mz059r+yY4TbYTC7tYxSEO7akZt1b6UryiFIAw2xuS4M871Px7BE 6bnYBI7hICTHTa8vxY97AUSN0+NBi2BLis5xajVUU46aGJDk785cersc/uIYkzEfFCAn d/qCNCIRPbbYEXJ8l17EGzr/8pjBUQ8BWlvZrRqJiQJS8LAB6gRgVk6OjJPj97ZeMI8B QjHqXkHKq3uvoaUBBYNo0WpRABzP6V9UpEfksnbhSZIRJC43gipKu9rhT2FEjDtETiI2 QbYrOcu0EgdqlINnX+fJ9sayH8aiYZ2ZCnaFojyN5uW/p0Xi0jaerjS1dVBdsgCyBIgW OG2g== MIME-Version: 1.0 X-Received: by 10.140.108.99 with SMTP id i90mr66596330qgf.56.1404907454073; Wed, 09 Jul 2014 05:04:14 -0700 (PDT) Received: by 10.224.93.10 with HTTP; Wed, 9 Jul 2014 05:04:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jul 2014 20:04:13 +0800 Message-ID: From: weiqiang cheng To: =?UTF-8?B?5pu+5bO75rOi?= Content-Type: multipart/alternative; boundary=001a11390c9cbe117e04fdc18138 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4ZK6HD4h3hQT3tsCTnIrCglYeYA Cc: "mpls@ietf.org" , "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" Subject: Re: [mpls] =?utf-8?q?=5BMPLS=5D_Any_comments_on_the_draft_of_MPLS-TP_?= =?utf-8?q?Shared-Ring_protection_=28MSRP=29_mechanism_for_ring_topology?= =?utf-8?b?4oCdID8=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:04:20 -0000 --001a11390c9cbe117e04fdc18138 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI Bobo, Thanks a lot for your questions. please see my answer in line: 1. the different between "normal wrapping" and "P2P shout wrapping". [WQ]: In Normal wrapping, protection switching executes at both nodes neighbored failure respectively,so the traffic will be wrapped twice. For Short wrapping protection, switching only executes at up-stream node which neighbored to failure,the destination node will extract the flow from the protection ring directly.This scheme can optimize latency and bandwidth. 2. can i use the RING APS protocol defined in G.8132 to implement the scheme of this document. [WQ]: As I know G.8132 is a draft in ITU-T and ITU-T seams no release plan for it now. The principle is similar. But this draft's ring construction is totally different from G.8132. 3. for the 'dual-node interconnected rings', there must be the same forwarding information between node C and node D in figure 11? [WQ]: Yes, Node C and Node D should sync the forwarding information of LSPs that traverse the interconnected rings, so that both interconnection nodes can terminate the source ring runnel and forward it to the correct destination ring tunnel in interconnected ring. B.R. Weiqiang Cheng 2014-07-09 19:07 GMT+08:00 =E6=9B=BE=E5=B3=BB=E6=B3=A2 : > hi,Weiqiang Cheng > i have some question about the > "draft-cheng-mpls-tp-shared-ring-protection-02". > 1. the different between "normal wrapping" and "P2P shout wrapping". > 2. can i use the RING APS protocol defined in G.8132 to implement the > scheme of this document. > 3. for the 'dual-node interconnected rings', there must be the same > forwarding information between node C and node D in figure 11? > > Best Regards! > BoBo > > > ------------------------------ > Date: Wed, 9 Jul 2014 18:41:01 +0800 > From: chengwq@gmail.com > To: mpls@ietf.org > CC: draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org > Subject: [mpls] [MPLS] Any comments on the draft of MPLS-TP Shared-Ring > protection (MSRP) mechanism for ring topology=E2=80=9D ? > > > Hi There, > > We uploaded the new version draft =E2=80=9CMPLS-TP Shared-Ring protection= (MSRP) mechanism for ring topology=E2=80=9D > > https://datatracker.ietf.org/doc/draft-cheng-mpls-tp-shared-ring-protecti= on/ > > We authors would like to see comments on this draft. Please help to revie= w it and It would be highly appreciated to send your comments on the mailin= g list. > > > > Thanks, > > Weiqiang Cheng > > > _______________________________________________ mpls mailing list > mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls > --001a11390c9cbe117e04fdc18138 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI Bobo,

Thanks a lot for your question= s. please see my answer in line:

1. =C2=A0the different between "normal wrapping&qu= ot; and "P2P shout wrapping".

[WQ]: In Normal wrapping, protection switching executes= at both nodes neighbored failure respectively,so the =C2=A0traffic will be= wrapped twice. For Short wrapping protection, switching only executes at u= p-stream node which neighbored to failure,the destination node will extract= the flow from the protection ring directly.This scheme can optimize latenc= y and bandwidth.
=
2. =C2=A0can i use the RING APS protocol defined in= G.8132 to implement the scheme of this document.
=
[WQ]: As I know G.8132 is a draft in ITU-T and ITU-= T seams no release plan for it now. The principle is similar. But this draf= t's ring construction is totally different from G.8132.
=
3. =C2=A0for the 'dual-node interconnected ring= s', there must be the same forwarding information between node C and no= de D in figure 11?
=
[WQ]: Yes, Node C and Node D should sync the forwar= ding information of LSPs that traverse the interconnected rings, so that bo= th interconnection nodes can terminate the=C2=A0source ring runnel and for= ward it to the correct destination ring tunnel in interconnected ring.

B.R.
Weiqiang Cheng


2014-07= -09 19:07 GMT+08:00 =E6=9B=BE=E5=B3=BB=E6=B3=A2 <zjbdamo@hotmail.com= >:
hi,Weiqiang Cheng
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i= have some question about the "draft-cheng-mpls-tp-shared-ring-protect= ion-02".
=C2=A0 1.=C2=A0 the different between "normal wrappin= g" and "P2P shout wrapping".
=C2=A0 2.=C2=A0 can i use the RING APS protocol defined in G.8132 to implem= ent the scheme of this document.
=C2=A0 3.=C2=A0 for the 'dual-node = interconnected rings', there must be the same forwarding information be= tween node C and node D in figure 11?

Best Regards!
BoBo



Date: Wed, 9 Jul 2014 18:41:= 01 +0800
From: ch= engwq@gmail.com
To: mpls@ietf.org
CC: draft-cheng-mpls-tp-shared-ring-protection@tools.ie= tf.org
Subject: [mpls] [MPLS] Any comments on the draft of MPLS-TP S= hared-Ring protection (MSRP) mechanism for ring topology=E2=80=9D ?


Hi The=
re,
We uploaded the new version draft=
 =E2=80=9CMPLS-TP Shared-Ring protection (MSRP)=
 mechanism for ring topology=E2=80=9D
https://datatrack=
er.ietf.org/doc/draft-cheng-mpls-tp-shared-ring-protection/
We authors would like to see comments on this dra=
ft. Please help to review it and It would be highly appreciated to send you=
r comments on the mailing list.
=C2=A0
Than=
ks,
Weiqiang Cheng

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

--001a11390c9cbe117e04fdc18138-- From nobody Wed Jul 9 05:29:59 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBA21A04C5 for ; Wed, 9 Jul 2014 05:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQFRr7vpBLNl for ; Wed, 9 Jul 2014 05:29:55 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3B01A04A2 for ; Wed, 9 Jul 2014 05:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1105; q=dns/txt; s=iport; t=1404909010; x=1406118610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a5JPnBxQ5rx86xkMZoWrlM1NtesW2pqGPVBF8/Q2Kxc=; b=kfR7UssPw1Sqe/N4vCaKnNFfVu7KwmdwpROhUcxaWUzIFFsY3VZ3lqNW e/s6ab65RY3yruxT7DiILqNKra5Kn43nGQrScB3+9BW7rXevTG5IgQSkd CkL+rGCeLJ9xXaPMQqluaSG5KqDSMrTx173pR/6F94GSjxvXeyaGzWFBg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAB41vVOtJA2N/2dsb2JhbABZgw6BLMU7gSEBgREWdYQDAQEBBDoxAwsMAgICAQgRBAEBCxQFBAcbFxQJCAIEAQ0FCIg6yGMXBI5cEAIBHjEHBoMngRYBBK8CggGBQoIw X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="59417294" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 09 Jul 2014 12:30:09 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s69CTsRY025826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 12:29:54 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 07:29:54 -0500 From: "Siva Sivabalan (msiva)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel Thread-Topic: Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document Thread-Index: AQHPmeuq415gEYUmrESh7HlYbkakNZuXrwIw Date: Wed, 9 Jul 2014 12:29:53 +0000 Message-ID: References: <53BAA7BA.2060903@pi.nu> In-Reply-To: <53BAA7BA.2060903@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0DdJsQSzyi0bDQ4Vfy4dIxMVqu0 Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:29:57 -0000 Support as an author. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, July 07, 2014 9:59 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; Adrian Farrel Cc: draft-bryant-mpls-oam-udp-return@tools.ietf.org Subject: Poll to see if we have support to make draft-bryant-mpls-oam-udp-r= eturn an mpls working group document Working Group, The authors of draft-bryant-mpls-oam-udp-return has informed us that the dr= aft is ready to be polled to see if we have consensus to make it a working = group document. This mail starts a two week adoption poll. We have not yet done the IPR poll, it will be done in parallel to the adopt= ion poll. There are no IPR disclosed against this draft. Please send your comments to the mpls working group mailing list (mpls@ietf.org) This adoption poll ends Juli 21, 2014! /Loa for the mpls wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 9 05:45:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1819E1A0535 for ; Wed, 9 Jul 2014 05:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6varvvJhn9e3 for ; Wed, 9 Jul 2014 05:45:47 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6610A1A0502 for ; Wed, 9 Jul 2014 05:45:47 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s69CjAHD031216; Wed, 9 Jul 2014 08:45:41 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 1n0sp9s3nv-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 09 Jul 2014 08:45:41 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 9 Jul 2014 08:45:40 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 9 Jul 2014 08:45:39 -0400 From: "Shah, Himanshu" To: "Siva Sivabalan (msiva)" , Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Adrian Farrel Date: Wed, 9 Jul 2014 08:45:39 -0400 Thread-Topic: Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document Thread-Index: AQHPmeuq415gEYUmrESh7HlYbkakNZuXrwIwgAAEMdA= Message-ID: <40746B2300A8FC4AB04EE722A593182B75000F8F@ONWVEXCHMB04.ciena.com> References: <53BAA7BA.2060903@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-09_03:2014-07-09,2014-07-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407090164 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/tc16rFrpbxUaCDAoDb0Oha8p9cw Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Subject: Re: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:45:49 -0000 Support to adopt this as a working group draft. /himanshu -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Siva Sivabalan (msiv= a) Sent: Wednesday, July 09, 2014 8:30 AM To: Loa Andersson; mpls@ietf.org; mpls-chairs@tools.ietf.org; Adrian Farrel Cc: draft-bryant-mpls-oam-udp-return@tools.ietf.org Subject: Re: [mpls] Poll to see if we have support to make draft-bryant-mpl= s-oam-udp-return an mpls working group document Support as an author. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, July 07, 2014 9:59 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; Adrian Farrel Cc: draft-bryant-mpls-oam-udp-return@tools.ietf.org Subject: Poll to see if we have support to make draft-bryant-mpls-oam-udp-r= eturn an mpls working group document Working Group, The authors of draft-bryant-mpls-oam-udp-return has informed us that the dr= aft is ready to be polled to see if we have consensus to make it a working = group document. This mail starts a two week adoption poll. We have not yet done the IPR poll, it will be done in parallel to the adopt= ion poll. There are no IPR disclosed against this draft. Please send your comments to the mpls working group mailing list (mpls@ietf.org) This adoption poll ends Juli 21, 2014! /Loa for the mpls wg co-chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 9 05:53:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3F1A05D1 for ; Wed, 9 Jul 2014 05:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH4mBYf4ySdF for ; Wed, 9 Jul 2014 05:53:19 -0700 (PDT) Received: from catr.cn (catrma.catr.cn [219.239.97.64]) by ietfa.amsl.com (Postfix) with ESMTP id 721D41A0538 for ; Wed, 9 Jul 2014 05:53:15 -0700 (PDT) Received: from user-THINK (unknown [64.208.49.5]) by app1 (Coremail) with SMTP id FhADCgBnbyfpOr1TSI4AAA--.1850S2; Wed, 09 Jul 2014 20:51:56 +0800 (CST) Date: Wed, 9 Jul 2014 14:51:58 +0200 From: "lifang@catr.cn" To: "weiqiang cheng" , "mpls@ietf.org" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[cn] Mime-Version: 1.0 Message-ID: <2014070914515461242528@catr.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart513046328684_=----" X-CM-TRANSID: FhADCgBnbyfpOr1TSI4AAA--.1850S2 X-Coremail-Antispam: 1UD129KBjvdXoWrtF15tF1kuF4UKw1xKw4kWFg_yoWfWFXEkw sIgr1093y3tw4xt3y3CryfWw4fGa15KF12yr1rJ3ZIgF1aywsrZ3s2y393XanxK3ZrGFnr AFsxJ3s8AFy3ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb_AYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1lnx0E6VACY4xI67k04243AVACY4xI67k04243AVAKzVAK j4xI6x02cVCv0xWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVWUJVW8Jw Aqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG 0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6xIIjxv20xvE14v26r106r15Mc Ij6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l FcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIecxEwVCI4VW5JwCF04 k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1r MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4 1lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l IxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0x vEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuY vjxUO2NtUUUUU X-CM-SenderInfo: polit0nj6ft3fuof0/ Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yQH3qHyBagGoCzih5n8BWUPSmPk Cc: "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" Subject: Re: [mpls] =?utf-8?q?=5BMPLS=5D_Any_comments_on_the_draft_of_MPLS-TP_?= =?utf-8?q?Shared-Ring_protection_=28MSRP=29_mechanism_for_ring_top?= =?utf-8?b?b2xvZ3nigJ0gPw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:53:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart513046328684_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgV2VpIHFpYW5nLA0KIA0KSSBoYXZlIGEgY29tbWVudCBvbiB0aGUgIlJQUyByZXF1ZXN0IGNv ZGUiIGluIDMuMS4yICBSUFMgUERVIHN0cnVjdHVyZS4gQ291bGQgTVNSUCBiZSBleHRlbmRlZCB0 byBzdXBwb3J0ICJTaWduYWwgRGVncmFkZSAoU0QpIiBhcyBhIHRyaWdnZXIgY29uZGl0aW9uPyAN CiANCjIwMTQtMDctMDkNCg0KDQpCZXN0IFJlZ2FyZHMNCkxJIEZhbmcNCg0K5Y+R5Lu25Lq677ya IHdlaXFpYW5nIGNoZW5nDQrlj5HpgIHml7bpl7TvvJogMjAxNC0wNy0wOSAxMjo0MQ0K5pS25Lu2 5Lq677yaIG1wbHNAaWV0Zi5vcmcNCuaKhOmAge+8miBkcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJl ZC1yaW5nLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmcNCuS4u+mimO+8miBbbXBsc11bTVBMU10g QW55IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBvZiBNUExTLVRQIFNoYXJlZC1SaW5nIHByb3RlY3Rp b24gKE1TUlApIG1lY2hhbmlzbSBmb3IgcmluZyB0b3BvbG9neeKAnSA/DQogDQpIaSBUaGVyZSxX ZSB1cGxvYWRlZCB0aGUgbmV3IHZlcnNpb24gZHJhZnQg4oCcTVBMUy1UUCBTaGFyZWQtUmluZyBw cm90ZWN0aW9uIChNU1JQKSBtZWNoYW5pc20gZm9yIHJpbmcgdG9wb2xvZ3nigJ1odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1tcGxzLXRwLXNoYXJlZC1yaW5nLXBy b3RlY3Rpb24vV2UgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHNlZSBjb21tZW50cyBvbiB0aGlzIGRy YWZ0LiBQbGVhc2UgaGVscCB0byByZXZpZXcgaXQgYW5kIEl0IHdvdWxkIGJlIGhpZ2hseSBhcHBy ZWNpYXRlZCB0byBzZW5kIHlvdXIgY29tbWVudHMgb24gdGhlIG1haWxpbmcgbGlzdC4gVGhhbmtz LFdlaXFpYW5nIENoZW5nDQo= ------=_001_NextPart513046328684_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
=0A
=0A=0A=0A=0A

Hi Wei qiang,

=0A

 

=0A

I have a comment= =0Aon the "RPS request code"=0Ain 3.1.2  RPS PDU= structure. Could MSRP be extended to support=0A"Signal Degrade (SD)" as a= trigger condition? 

=0A

Dear Authors,

as the scope of the document includes MPLS data plan= e I’ve included MPLS WG in the discussion. Hope you don’t mind.=

Please find my notes to the draft below:<= /p>

·         Section 2 states  “S-BFD packets = are transmitted with IP header, UDP header and BFD control header”. D= oes that mean that ACH encapsulation is outside the scope of this document = as in that case S-BFD packets would not have IP and UDP headers. If that is the case, then clarification of the scope seems ap= propriate.

·         Section 2 introduces “explicitly label= switched” scenario. What is it?

·         Section 2.1, bullet describing selection of = Destination IP address. The RFC 5884 allows use of the whole range rather t= han one address:

“The destination IP= address MUST be randomly chosen from the 127/8 range for IPv4 and  fr= om the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following exception.= ”

The document, as worded, = restricts use of Destination IP address to exercise particular path among a= vailable multi-paths, as suggested in the RFC 5884.

I’d suggest to use = explanation from Section 7 of the RFC 5884.

·         Note that if IP/UDP encapsulation used for S= -BFD there could not be “new associated channel type for S-BFD”= as 0x0021 and 0x0057 must be used for IPv4 and IPv6 accordingly. Or was th= e Ed.Note for PW-ACH encapsulation? But Section 3 discusses only IP routing of S-BFD pong.

 

Thank you for your kind = consideration.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B7E8F2Deusaamb103erics_-- From nobody Wed Jul 9 16:41:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD91B2848 for ; Wed, 9 Jul 2014 16:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ucCiI5-JEN2 for ; Wed, 9 Jul 2014 16:41:18 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775611B283E for ; Wed, 9 Jul 2014 16:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2913; q=dns/txt; s=iport; t=1404949284; x=1406158884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CvQlMma5dBPVAsaUUUrU0BZXaV7Zb14KlD+sLHLbsMQ=; b=ERhgVFBbY+5vRrodt8hPla4++ZbkHgueDymct93dwkhhWPLuKDlGiHov OXMSWJuG0MdKSjCmg+UAwtH7/UAqYmuoW3v11Sa5m79c7Uzb12AXg5oPT 8Fg67X/VOi5v/EXio8VddxnEVRtMpoqJzlc+MVIJ7JQygjg/hLHtzmllr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFALHRvVOtJA2K/2dsb2JhbABPCoJqJIEfDcZlAYEHFnWEAwEBAQMBOj0CDAQCAQgRBAEBCxQQMh0IAgQOBQiIMggByEgXjmYrBisHAgSDJ4EWAQSvAoNDgjA X-IronPort-AV: E=Sophos;i="5.01,634,1400025600"; d="scan'208";a="59555683" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 09 Jul 2014 23:41:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s69NfHtk001599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Jul 2014 23:41:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 18:41:17 -0500 From: "Nobo Akiya (nobo)" To: "Nagendra Kumar Nainar (naikumar)" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgAAGuSCAAWXvgIAMTauggBet8gCAAHYg8IAAQuAAgALj8yA= Date: Wed, 9 Jul 2014 23:41:15 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gPknf0kg14xChhIqeDt8Eq83rXw Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 23:41:20 -0000 Hi Nagendra, > -----Original Message----- > From: Nagendra Kumar Nainar (naikumar) > Sent: Monday, July 07, 2014 10:26 PM > To: Nobo Akiya (nobo) > Cc: mpls@ietf.org > Subject: Re: New Version Notification for draft-akiya-mpls-lsp-ping-lag- > multipath-00.txt >=20 > Hi Nobo, >=20 > Good question. I think you meant E and not C, since C has LAG as upstream= ? >=20 > Assuming you were asking what will E send, then: >=20 > Even if E does not have any upstream/downstream LAG, E will still include > LAG Intf Info TLV in the MPLS echo reply, if it understands this TLV. Thi= s is > how A learns whether or not E is capable of following the procedures > described in this document. Otherwise lack of LAG upstream/downstream > information becomes ambiguous to A: there is no upstream/downstream > LAG on E vs. E didn't understand the LAG procedures (i.e. ignored the opt= ion > TLV and proceeded) but may have upstream/downstream LAG. >=20 > So, LAG Intf Info TLV in MPLS echo reply is to let the initiator know: > - Responder understands this mechanism. > - U bit to indicate that responder is capable of providing Detailed Inter= face > and Label Stack TLV. > - D bit to indicate that responder is capable of providing DDMAP with LAG > info. >=20 > I wanted to break up the (U)pstream and (D)ownstream capabilities, since > on some products, doing one could be more difficult than the other one. >=20 > Yes, it is E :). That makes sense. So I think E will set U and= D to > zero to indicate there is no LAG details but I understand this feature :)= . May > be this can be clarified in the draft?. Sure, how about changes in Section 3. [old] These procedures allow initiating LSR to: o Identify whether responder LSR understands this mechanism. o Identify whether each DDMAP describes a LAG interface or a non-LAG interface. [new] These procedures allow initiating LSR to: o Mandating the responder LSR to always add the LAG Interface Info TLV in the MPLS echo reply allows the initiating LSR to identify whether responder LSR understands this mechanism o The value of the LAG Description Indicator flag in DS Flags will allo= w the initiating LSR to identify whether each DDMAP describes a LAG interface or a non-LAG interface Will that work? >=20 >=20 > Hmm... yes, that text was copied from RFC4379, but it's a bit confusing. > Let me change that: >=20 > [old] > The Interface Index Sub-TLV describes the index assigned by the > upstream LSR to the interface. >=20 > [new] > The Interface Index Sub-TLV describes the index assigned by this > LSR to the interface. >=20 > Would that work? >=20 > Or "The Interface Index Sub-TLV describes the index assigned > by local LSR to the egress interface"?. Accepted. Thank! -Nobo From nobody Wed Jul 9 17:34:41 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6931A00A8 for ; Wed, 9 Jul 2014 17:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW_PxxmV3c7F for ; Wed, 9 Jul 2014 17:34:36 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21C71A0086 for ; Wed, 9 Jul 2014 17:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5057; q=dns/txt; s=iport; t=1404952512; x=1406162112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UG1yq4IMwP4kJCU1EpauwTuqppkyHZp2/9dVdmAL9Yw=; b=Igw40Gn8UC8l+UBPW4JkwXJODhQUyQXt0iBfuoPWTdFc5OAc7vBOYxuo WLtd4wnJOm43I1PR7x79mtLo097278Y2Mk5geyD+2Jk474VPzIQOaLyyB iky/UwsaSAKTZGa7sC+osyvFLPYjZ8MpIOk7vso4rQn3GLHqHt0nHNhX6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAAvfvVOtJA2I/2dsb2JhbABZgmokUlq/JIdBAYEHFnWEAwEBAQMBDiwrAgsFAgULAgEIIhQQMiUCBA4NE4gfCAEMyB4XjxExB4MtgRYFnD6SRIIBgUKBcCQc X-IronPort-AV: E=Sophos;i="5.01,635,1400025600"; d="scan'208";a="59609240" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 10 Jul 2014 00:35:11 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6A0YZIB022148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 00:34:35 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 19:34:35 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgCZOLID//65qEIAAaXQAgAKhV1A= Date: Thu, 10 Jul 2014 00:34:34 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> <10150BDE-17FD-43D0-9DE4-6E0CAAF3BD5E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Lyot-I9t4oxYQJES_VyvbsNhbI8 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 00:34:39 -0000 Hi Sam, > Thanks, Nobo, for quick response. Sorry for the delay in my second response :D > >> 2. Could you clarify the following? In the case of LAG interface, for > >> a given FEC, will there be different label stack for each > >> sub-interface type? If not, i.e. same label stack but differ sub i.f, > >> which multipath type one could use to determine hash computation? > > > > I think I understand your question ... but if my answers are not what y= ou > were asking, do elaborate. For a given FEC, the incoming & outgoing label= s > will be the same for all LAG members when traversing over a LAG to reach > the downstream. Of course SR could assign an Adj-SID for a LAG member, > and explicitly steer the packets over the specific LAG member, but it wou= ld > no longer be considered to travel over the LAG at that point. Similar if = RSVP > was to pin-down a specific LAG member. So the LAG is treated as one logic= al > interface by the label binding procedures, thus same labels for every LAG > member. > Few questions, >=20 > Because you mentioned it is L2 interfaces only, I was wondering whether L= 3 > header is taken into consideration or not! I see, actual data carried on the LSP may be "whatever", but for the purpos= e of LSP Traceroute multipath discovery, we can assume that multipath is go= ing to be performed with destination IP or Flow/Entropy Label. > Secondly, assuming if member is not pinned to a specific LSP, is the > validation for FEC? If so, how is that being done? when do you consider L= SP > ping/trace failure? As it is sub member failure, the interface is still r= unning > and packets are still fwd'd. If a LAG member is pinned to a specific LSP, then this document does not im= pose any changes. Thanks for pointing this out though, I think it's worth s= pelling that out in the document. What do you think about following text at= the end of Section 2 (Overview). Note that the mechanism described in this document does not impose any changes to scenarios where an LSP is pinned down to a particular LAG member (i.e. the LAG is not treated as one logical interface by the LSP). > >> 4. Also, how is DDMAP interface info validated? I believe the LAG > >> member link # is local. What all fields being validated for LAG interf= ace? > > > > When MPLS echo request traverses over all LAG members (i.e. different > interface index) to the nexthop, then the packets should have terminated > on different incoming LAG members at the downstream (different interface > index). > > > > For supported/unsupported scenarios, please view: > > http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag-multipath-00# > > appendix-A > I think appendix sections are very imp to consider and should be in main > sections. I agree that Appendix is useful. At the same time, I'd like the main to foc= us on the problem and the solution (otherwise the document could become eve= n more difficult to read). How about I add explicit xref to Appendix from t= he Overview. ... o In Section 7, the Interface Index Sub-TLV; o In Section 8, the Detailed Interface and Label Stack TLV; o In Appendix A, issues with LAG having L2 Switch. <---- this entry! > From high level, this addition will help discover various LAG members > associated with the data path of an LSP. But I think it is difficult to v= alidate > against a given FEC. Because the DDMAP info of LAG member sent cannot be > validated. If it is indeed could be validated, should be documented in th= e ID. Good point. I think Section 4 (Mechanism to Validate L2 ECMP Traversal) can= use more texts to describe the what can be validated. How about we make so= me changes in the Section 4 (Mechanism to Validate L2 ECMP Traversal). [old] Described procedures allow initiating LSR to know: o The expected load balance information of every LAG member link, at LSR with TTL=3Dn. o The actual incoming interface at LSR with TTL=3Dn+1, including the interface index of LAG member link if incoming interface is a LAG interface. [new] Described procedures allow initiating LSR to know: o The expected load balance information of every LAG member link, at LSR with TTL=3Dn. o With specific entropy, the expected interface index of the outgoing LAG member link at TTL=3Dn. o With specific entropy, the interface index of the incoming LAG member link at TTL=3Dn+1. Expectation is that there's a relationship between the interface index of the outgoing LAG member link at TTL=3Dn and the interface index of the incoming LAG member link at TTL=3Dn+1 for all discovered entropies. In other words, set of entropies that load balances to outgoing LAG member link X at TTL=3Dn should all reach the nexthop on same incoming LAG member link Y at TTL=3Dn+1. Well, you are already providing good set of comments, much appreciate it! Thanks! -Nobo From nobody Wed Jul 9 21:58:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42F31A049F for ; Wed, 9 Jul 2014 21:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jbfQQkAqnjX for ; Wed, 9 Jul 2014 21:57:53 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C82E1A00F0 for ; Wed, 9 Jul 2014 21:57:53 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so6756618qgd.19 for ; Wed, 09 Jul 2014 21:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k3qfny0Mj+bHRDxd+ZaDoptNWLoab7Q06YEQVQOpRk4=; b=WvDb+XEqzZc4u8MbSbM0MHqvWXSBYqaU5o71ZkObsvykyEDmp3wfUkSs4GSPoBuuwB AJj8Rwg9z1mYV/DM3CjEt/ywmBgY/bhe94M+hEtsYxjXen/DxCRlsWjW6bbwkjygUzzH pkTIdqAHn1X1q6muyP/9aqN0HVdTa/TIFlDb+gORuMrHEDRDqvOkNjpk+XLzYmVoYhL/ TCZdjDvpwg+Iwmot5dVTBCkxtJR34yLbXw/WXwuLQPzGhU40Ub+jp1isPQW7h8/6GVeL KEstesAXPvBPc4ZZ8hvU891r05gu5CIfedukFqA21QpEaQSET3+d4m/QAof8JkRmSEwD xHvA== MIME-Version: 1.0 X-Received: by 10.140.88.103 with SMTP id s94mr31618473qgd.73.1404968272206; Wed, 09 Jul 2014 21:57:52 -0700 (PDT) Received: by 10.224.93.10 with HTTP; Wed, 9 Jul 2014 21:57:52 -0700 (PDT) In-Reply-To: <76CD132C3ADEF848BD84D028D243C927336BE7CD@nkgeml512-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C927336BE7CD@nkgeml512-mbx.china.huawei.com> Date: Thu, 10 Jul 2014 12:57:52 +0800 Message-ID: From: weiqiang cheng To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=001a11c11e1cc9205804fdcfaae4 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1avOvqQHRbNBHijLQgI1m_Qk09A Cc: "mpls@ietf.org" , "draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org" Subject: Re: [mpls] =?utf-8?q?=5BMPLS=5D_Any_comments_on_the_draft_of_MPLS-TP_?= =?utf-8?q?Shared-Ring_protection_=28MSRP=29_mechanism_for_ring_topology?= =?utf-8?b?4oCdID8=?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 04:57:55 -0000 --001a11c11e1cc9205804fdcfaae4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jie, Thanks for your comments. MPLS-TP based networks are usually constructed with multiple-ring topology.In some failure scenarios, linear protection such as PSC cannot cover the multi-failure issue.In addition,for many application scenarios such as mobile backhaul,a large number of services should be terminated in one core node.Because the linear protection should be executed end to end,the core node will take heavy load to handle OAM messages and Protection switching. SMP is a very good solution to share the resources and improve the network reliability. My understanding is that shared ring protection is a special case of SMP for ring specifically. It is more easy to implement and able to reduce the complexity of protection configuration and operation in ring topology. B.R. Weiqiang Cheng 2014-07-09 19:10 GMT+08:00 Dongjie (Jimmy) : > Dear authors, > > > > I have one quick comment on this draft: > > > > Since we have Linear Protection (PSC) and the work being done on Shared > Mesh Protection, do we need dedicated protection solution for ring topolo= gy? > > > > Best regards, > > Jie > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *weiqiang cheng > *Sent:* Wednesday, July 09, 2014 6:41 PM > *To:* mpls@ietf.org > *Cc:* draft-cheng-mpls-tp-shared-ring-protection@tools.ietf.org > *Subject:* [mpls] [MPLS] Any comments on the draft of MPLS-TP Shared-Ring > protection (MSRP) mechanism for ring topology=E2=80=9D ? > > > > Hi There, > > We uploaded the new version draft =E2=80=9CMPLS-TP Shared-Ring protection= (MSRP) mechanism for ring topology=E2=80=9D > > https://datatracker.ietf.org/doc/draft-cheng-mpls-tp-shared-ring-protecti= on/ > > We authors would like to see comments on this draft. Please help to revie= w it and It would be highly appreciated to send your comments on the mailin= g list. > > > > Thanks, > > Weiqiang Cheng > > --001a11c11e1cc9205804fdcfaae4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jie,
Th= anks for your comments.

MPLS-T= P based networks are usually constructed with multiple-ring topology.In som= e failure scenarios, linear protection such as PSC cannot cover the multi-f= ailure issue.In addition,for many application scenarios such as mobile back= haul,a large number of services should be terminated in one core node.Becau= se the linear protection should be executed end to end,the core node will t= ake heavy load to handle OAM messages and Protection switching. =C2=A0

SMP is a very good sol= ution to share the resources and improve the network reliability. My unders= tanding is that shared ring protection is a special case of SMP for ring sp= ecifically. It is more easy to implement and able to reduce
the complexity o= f protection configuration and operation in ring topology. =C2=A0=C2=A0

B.R.
Weiqia= ng Cheng


2014-07-09 19:10 GMT+08:00 Dongjie (Jimmy) <jie.dong@huawei.com>:

Dear autho= rs,

=C2= =A0

I have one= quick comment on this draft:

=C2= =A0

Since we h= ave Linear Protection (PSC) and the work being done on Shared Mesh Protecti= on, do we need dedicated protection solution for ring topology?

=C2= =A0

Best regar= ds,

Jie=

=C2= =A0

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of weiqiang cheng
Sent: Wednesday, July 09, 2014 6:41 PM
To: mpls@ietf.org=
Cc: draft-cheng-mpls-tp-shared-ring-protection@t= ools.ietf.org
Subject: [mpls] [MPLS] Any comments on the draft of MPLS-TP Shared-R= ing protection (MSRP) mechanism for ring topology=E2=80=9D ?<= /span>

=C2=A0

Hi There,
We uploaded the new version draft =E2=80=9CMPLS-T=
P Shared-Ring protection (MSRP) mechanism for ring topology=E2=80=9D=
https://datatrack=
er.ietf.org/doc/draft-cheng-mpls-tp-shared-ring-protection/
We authors would like to see comments on this dra=
ft. Please help to review it and It would be highly appreciated to send you=
r comments on the mailing list.
=C2=A0
Thanks,
Weiqiang Cheng

--001a11c11e1cc9205804fdcfaae4-- From nobody Wed Jul 9 22:47:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EFC1B2797 for ; Wed, 9 Jul 2014 22:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWjxLrRrYsfe for ; Wed, 9 Jul 2014 22:47:12 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCE31B2795 for ; Wed, 9 Jul 2014 22:47:12 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id fp1so10254495pdb.11 for ; Wed, 09 Jul 2014 22:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UX0uI6Ey1nTd1jzV7IiTW+V0xL1vCsT0S4DWE3CKfjc=; b=hW69aOjrTLF45YpI4F+5PWiRe2tTKCBO7j9A9GBRbw5lXtWuxtFgB3RtGIoJ/UEILu ig+qiKP+EyMLzf1JfCgqUPV+JAjEMzziDdlUVO4gGkardo5cn1MpepThpPkbzXgfm0ka 7+3wQiC8HyQxPfAL/DxzDUHuYUvsLpXXjxbciu+WVQzsGsfsHyc+Akhn1GDJxaqahoVX xh7R/qh5pw4yHoB4N5wuU0AwLgCjfcfrIrvi0LD490ia3OkYmEya/Z+L8Du262642LyT MosrrD2RVnzZw+BL7JwzAWHqC8fKJOo2/CJF8G/rVLTykMiYAuibqfEaybA8Pd8AMiUT q3GA== X-Received: by 10.66.136.131 with SMTP id qa3mr44623135pab.77.1404971232113; Wed, 09 Jul 2014 22:47:12 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id op6sm30912773pdb.71.2014.07.09.22.47.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 22:47:11 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Wed, 9 Jul 2014 22:47:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> <10150BDE-17FD-43D0-9DE4-6E0CAAF3BD5E@gmail.com> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cy5b6dt6m8hqseDSKI2dka-44JY Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 05:47:13 -0000 Hi Nobo, Thanks for the responses. Snipped out things so as not to bloat the discussion.=20 I could review draft when you add those changes. For now, have some points which I feel are more imp :D Hope you don=92t = mind. >=20 >> =46rom high level, this addition will help discover various LAG = members >> associated with the data path of an LSP. But I think it is difficult = to validate >> against a given FEC. Because the DDMAP info of LAG member sent cannot = be >> validated. If it is indeed could be validated, should be documented = in the ID. >=20 > Good point. I think Section 4 (Mechanism to Validate L2 ECMP = Traversal) can use more texts to describe the what can be validated. How = about we make some changes in the Section 4 (Mechanism to Validate L2 = ECMP Traversal). >=20 > [old] > Described procedures allow initiating LSR to know: >=20 > o The expected load balance information of every LAG member link, = at > LSR with TTL=3Dn. >=20 > o The actual incoming interface at LSR with TTL=3Dn+1, including = the > interface index of LAG member link if incoming interface is a LAG > interface. >=20 > [new] > Described procedures allow initiating LSR to know: >=20 > o The expected load balance information of every LAG member link, = at > LSR with TTL=3Dn. >=20 > o With specific entropy, the expected interface index of the > outgoing LAG member link at TTL=3Dn. >=20 > o With specific entropy, the interface index of the incoming LAG > member link at TTL=3Dn+1. >=20 > Expectation is that there's a relationship between the interface > index of the outgoing LAG member link at TTL=3Dn and the interface > index of the incoming LAG member link at TTL=3Dn+1 for all = discovered > entropies. In other words, set of entropies that load balances to > outgoing LAG member link X at TTL=3Dn should all reach the nexthop = on > same incoming LAG member link Y at TTL=3Dn+1. I think this is very important, for the reasons below. 1. How does one know same LAG bundle originates at TTL=3Dn terminates at = TTL=3Dn+1. I am talking from discovery/treetrace/someother side? Both = TTL=3Dn and TTL=3Dn+1 could tell it is LAG but doesn=92t mean that is = 1:1 correspondence per link/link member. IOW, how does sec #3 be performed for the scenario described in last = paragraph in sec #4? Better yet, how does one know not to perform if = any? 2. Let us take this scenario, I receive DDMAP at TTL=3Dn with various = LAG interface+members and their multipath info. I send TTL=3Dn+1 with a = chosen LAG interface and multi path info. At TTL=3Dn+1, what am I going = to validate? For the FEC validation and interface validation, I need to = check for specific information, in this case the LAG member. My = understanding is, unlike load balanced interfaces, if LAG member is not = pinned to specific LSP, the even if one member link fails, it load = balances over other member link, because MPLS will only see it as single = interface from LIB point of view, no? 3. If the LAG member info be only used to indicate that there is LAG but = NOT for validation, then text should be added to describe that. = Especially on how FEC interface and label validation is done.=20 4. As you said, if a LAG member is pinned to a specific LSP, then we = will be using a separate DSMAP/DDMAP anyway. If so, could explain the = benefit of LAG with multi path info really used for? In other words, how = much beneficial compared to BFD over LAG? 5. When do you consider a LAG member has failed and how do you indicate = or inform the requestor? Will save more questions for later :D -sam > Well, you are already providing good set of comments, much appreciate = it! >=20 > Thanks! >=20 > -Nobo >=20 From nobody Wed Jul 9 23:55:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3899B1A035C; Wed, 9 Jul 2014 23:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meox6gttRAD5; Wed, 9 Jul 2014 23:55:11 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4EA1A0359; Wed, 9 Jul 2014 23:55:10 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jul 2014 15:55:07 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 10 Jul 2014 15:55:04 +0900 From: =?utf-8?B?66WY7KCV64+Z?= To: Lou Berger , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+gAHv9wCAB+MbNg== Date: Thu, 10 Jul 2014 06:55:03 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> In-Reply-To: <53B8190E.6080505@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.4.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/TgPRltfAQHDWvqn1hSSUTF2tEZI Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] =?utf-8?b?7ZqM7IugOiBbUlRHLURJUl0gIFJ0Z0RpciByZXZpZXc6IGRy?= =?utf-8?q?aft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 06:55:14 -0000 DQpUaGFuayB5b3UsIExvdQ0KDQpQbGVhc2UsIHNlZSB0aGUgbGluZXMgc3RhcnRpbmcgd2l0aCBb SlJdIGZvciBteSByZXNwb25zZXMgdG8geW91ciBjb21tZW50cy4gDQoNCkkgcmVtb3ZlZCB0aGUg cGFydHMgdGhhdCB3ZSBoYXZlIGFscmVhZHkgYWdyZWVkIG9uLiBJIGFsc28gZXJhc2VkIHlvdXIg Y29tbWVudHMgdGhhdCBhcmUgbWlub3IgZWRpdG9yaWFsIGFuZCB3aWxsIGJlIHJlZmxlY3RlZCBp biB0aGUgbmV4dCB2ZXJzaW9uIGFzIHlvdSBzdWdnZXN0ZWQuIFRoZSB0d28g4oCcYXNzaWduZWTi gJ0gcmVsYXRlZCBjb21tZW50cyBhcmUgbm90IGNvdmVyZWQgaGVyZSBhcyB0aGV5IGFyZSBiZWlu ZyBkaXNjdXNzZWQgd2l0aCBZYWFjb3YuIA0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcN Cg0KKioqKioqIA0KICANCig0KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQpPTEQ6DQp0 aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBjb21taXR0ZWQs DQpORVcNCnRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGRl ZGljYXRlZCwNCiAgDQpEZWRpY2F0ZWQgaXMgYWxzbyBhbiBhbWJpZ3VvdXMgdGVybSwgaG93IGFi b3V0Og0KT0xEDQogICB0aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBm dWxseSBjb21taXR0ZWQsIHRoZQ0KICAgcHJvdGVjdGlvbiBwYXRoIGluIHRoZSBjYXNlIG9mIFNN UCBjb25zaXN0cyBvZiBzZWdtZW50cyB0aGF0IGFyZQ0KICAgZGVkaWNhdGVkIHRvIHRoZSBwcm90 ZWN0aW9uIG9mIHRoZSByZWxhdGVkIHdvcmtpbmcgcGF0aCBhbmQgYWxzbw0KTkVXDQogICB0aGUg cmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBhbGxvY2F0ZWQsIHRo ZQ0KICAgcHJvdGVjdGlvbiBwYXRoIGluIHRoZSBjYXNlIG9mIFNNUCBjb25zaXN0cyBvZiBzZWdt ZW50cyB0aGF0IGFyZQ0KICAgYWxsb2NhdGVkIHRvIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSByZWxh dGVkIHdvcmtpbmcgcGF0aCBhbmQgYWxzbw0KDQpbSlJdIFRoaXMgcGFyYWdyYXBoIGRlc2NyaWJl cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGxpbmVhciBwcm90ZWN0aW9uIGFuZCBzaGFyZWQgbWVz aCBwcm90ZWN0aW9uIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHByb3RlY3Rpb24gcmVzb3VyY2Ug c2hhcmluZy4gSW4gbGluZWFyIHByb3RlY3Rpb24gc3dpdGNoaW5nLCB0aGUgcmVzb3VyY2VzIGFy ZSBub3Qgc2hhcmVkIGJ1dCBkZWRpY2F0ZWQgdG8gdGhlIHByb3RlY3Rpb24gcGF0aC4gU01QIGhh cyBzaGFyZWQgcmVzb3VyY2VzIGluIHNvbWUgc2VnbWVudHMuIEkgdGhpbmsgdGhlIHdvcmQsIOKA nGRlZGljYXRlZOKAnSBpcyBnZW5lcmFsIGVub3VnaCB0byBiZSB1c2VkIHdpdGhvdXQgYW55IGZ1 cnRoZXIgZGVmaW5pdGlvbi4gUkZDIDYzNzIgYWxzbyB1c2VzIOKAnGRlZGljYXRlZOKAnCwgYW5k IHRoaXMgZG9jdW1lbnQgZm9sbG93cyB0aGUgc2FtZSB1c2UgYXMgaW4gUkZDIDYzNzINCg0KKDcp IFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4xOg0KT0xEOg0KV2hlbiB0aGUgcmVz ZXJ2ZWQgcmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIGNvbW1pdHRlZCB0byBh DQpwYXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50 IHJlc291cmNlcw0KYXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24gcGF0aC4g VGhpcyB0aGVuIGltcGxpZXMgdGhhdA0KaWYgYW5vdGhlciB3b3JraW5nIHBhdGggb2YgdGhlIFNN UCBkb21haW4gdHJpZ2dlcnMgYSBwcm90ZWN0aW9uDQpzd2l0Y2gsIHRoZSBjb21taXRtZW50IG9m IHRoZSByZXNvdXJjZXMgbWF5IGZhaWwuIEluIG9yZGVyIHRvDQpvcHRpbWl6ZSB0aGUgb3BlcmF0 aW9uIG9mIHRoZSBjb21taXRtZW50IGFuZCBwcmVwYXJpbmcgZm9yIGNhc2VzIG9mDQptdWx0aXBs ZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRoZSBjb21taXRtZW50IG9mIHRoZSBzaGFyZWQNCnJl c291cmNlcyBhcmUgYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcg cGF0aHMgaW4NCnRoZSBTTVAgbmV0d29yay4NCk5FVzoNCldoZW4gdGhlIHJlc2VydmVkIHJlc291 cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSB1dGlsaXplZCBieSBhDQpwYXJ0aWN1bGFy IHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50IHJlc291cmNlcw0K YXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24gcGF0aC4gVGhpcyB0aGVuIGlt cGxpZXMgdGhhdA0KaWYgYW5vdGhlciB3b3JraW5nIHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJp Z2dlcnMgYSBwcm90ZWN0aW9uDQpzd2l0Y2gsIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29y ZGluYXRpb24gbWF5IGZhaWwuIFRoZSBkaWZmZXJlbnQgd29ya2luZyBwYXRocyBpbg0KdGhlIFNN UCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRp bmF0aW9uLiAgDQoNCg0KVGhpcyBpcyBmaW5lLCBidXQgSSB3b25kZXIgd2h5IHlvdSBhcmUgdXNp bmcgInJlc291cmNlIHV0aWxpemF0aW9uIiB2cyAicHJvdGVjdGlvbiBzd2l0Y2giPyAodGhpcyBp cyBhY3R1YWxseSBhIGJpdCBvZiBhIGdlbmVyYWwgY29tbWVudCAtLSBJIHRoZSBsYXR0ZXIgaXMg YW4gZXhpc3RpbmcgYXBwbGljYWJsZSB0ZXJtIHRoYXQgd291bGQgaGVscCByZWFkZXJzIGhvdyB0 aGlzIGRvY3VtZW50IGZpdHMgaW4gdG8gdGhlIHRlY2hub2xvZ3kgc3BhY2UuKQ0KDQpbSlJdIEFz IGRlc2NyaWJlZCBpbiBhbiBlYXJsaWVyIHBhcnQgb2YgdGhpcyBzZWN0aW9uLCBTTVAgcHJvdGVj dGlvbiBjb25zaXN0cyBvZiB0d28gb3BlcmF0aW9uczogdHJhZmZpYyBzd2l0Y2hvdmVyIGFuZCBy ZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24uIFRoZSBzZW50ZW5jZXMgYXJlIGFib3V0 IHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24sIGFuZCDigJxyZXNvdXJjZSB1 dGlsaXphdGlvbuKAnSBzZWVtcyB0byBiZSBtb3JlIGFjY3VyYXRlLiANCg0KDQotIEdlbmVyYWwg Y29tbWVudDogZmF0ZS1zaGFyaW5nIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCnBy b3RlY3Rpb246IEhvdyBpcyBjby1yb3V0aW5nIHByZXNlcnZlZCBmb3IgdGhlIHJldmVyc2UgcGF0 aCBpbiBTTVA/DQpJJ2QgYXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggY29vcmRpbmF0aW9u IHByb3RvY29sIHdvdWxkIGJlDQpyZXF1aXJlZCB0byB0cmlnZ2VyIGEgc3dpdGNob3ZlciBvZiB0 aGUgcmV2ZXJzZSBMU1AgaW4gdGhlIGNvLXJvdXRlZA0K