From nobody Wed Apr 1 14:10:43 2015 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 D9CCA1ABD37 for ; Wed, 1 Apr 2015 14:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S9f2Jy_wzIyL for ; Wed, 1 Apr 2015 14:10:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ADD1AC3CF for ; Wed, 1 Apr 2015 14:10:39 -0700 (PDT) Received: from BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 1 Apr 2015 21:10:22 +0000 Received: from BLUPR05MB564.namprd05.prod.outlook.com ([10.141.202.150]) by BLUPR05MB564.namprd05.prod.outlook.com ([10.141.202.150]) with mapi id 15.01.0118.022; Wed, 1 Apr 2015 21:10:22 +0000 From: Minjie Dai To: Nobo Akiya Thread-Topic: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse Thread-Index: AdBpwIwyiAChjxNzTYuMDuXIXWj/wgBdEjSAAFQwSwA= Date: Wed, 1 Apr 2015 21:10:21 +0000 Message-ID: References: <006001d069c0$d9eadeb0$8dc09c10$@gmail.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.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB562; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(52604005)(479174004)(51704005)(24454002)(41574002)(19580405001)(46102003)(62966003)(87936001)(19580395003)(66066001)(77096005)(99286002)(76176999)(54356999)(40100003)(102836002)(15975445007)(92566002)(561944003)(50986999)(122556002)(86362001)(110136001)(2900100001)(77156002)(36756003)(2656002)(230783001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB564.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB562; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB562; x-forefront-prvs: 053315510E Content-Type: text/plain; charset="euc-kr" Content-ID: <24FF5FC142F9304CA36DB05F7FA0483C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2015 21:10:21.8552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB562 Archived-At: Cc: 'mpls' Subject: Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse 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, 01 Apr 2015 21:10:42 -0000 UmVzZW5kaW5nIGR1ZSB0byBvcmlnaW5hbCBtYWlsIGdvdCBib3VuY2VkIGFuZCBub3QgYXBwZWFy aW5nIGluIHRoZSBtYWlsDQphcmNoaXZlIGFmdGVyIGEgY291cGxlIG9mIGRheXMNCg0KT24gMy8z MC8xNSwgOTo1OSBQTSwgIk1pbmppZSBEYWkiIDxtZGFpQGp1bmlwZXIubmV0PiB3cm90ZToNCg0K PkhpIE5vYm8sDQo+DQo+VGhhbmtzIGZvciB0YWtpbmcgdGltZSByZXZpZXdpbmcgdGhlIGRyYWZ0 Lg0KPg0KPjEuIFJlZ2FyZGluZyB0aGUgY2FzZSBvZiBjb21wbGV0ZSBwYXRoIG92ZXJsYXAsIHdl IGRvIHRoaW5rIHdpdGggdGhlDQo+Y29ycmVjdGx5IGltcGxlbWVudGVkIHNvZnR3YXJlLCB0aGUg TFNScyBjYW4gYXZvaWQgb3BlcmF0aW9ucyBzdWNoIGFzIExGSUINCj51cGRhdGUgYW5kIGRhdGEg cGF0aCB2ZXJpZmljYXRpb24uIFNvZnR3YXJlIGltcGxlbWVudGVkIHRoZSBuZXcgYWxnb3JpdGht DQo+Y2FuIGJyaW5nIGluIGJ1Z3MsIGJ1dCB0aGlzIGlzIG5vIGRpZmZlcmVudCBmcm9tIGFueSBv dGhlciB0eXBlIG9mDQo+c29mdHdhcmUgY2hhbmdlLiBKdXN0IGFzIGluIGV4aXN0aW5nIE1CQiBp bnN0YW5jZSBzd2l0Y2gsIHRoZXJlIGFyZSBtb3JlDQo+Y2hhbmNlcyB0byBjcmVhdGUgbW9yZSBm YWlsdXJlcyBkdWUgdG8gbW9yZSB1cGRhdGVzIGluIHRoZSBzeXN0ZW0gY29tcGFyZQ0KPnRvIHRo ZSBwcm9wb3NhbCB3aGljaCBhdm9pZCBtYWpvcml0eSBvZiB0aGUgdXBkYXRlIGFuZCBjaGFuZ2Vz LiBJbg0KPmFkZGl0aW9uLCB0aGlzIGRvZXNuqfZ0IHByZXZlbnQgY29udGludWVkIG1vbml0b3Jp bmcgb2YgdGhlIExTUCBoZWFsdGggYXMNCj5iZWZvcmUsIHdlIGFyZSBqdXN0IHN0YXRpbmcsIGlm IGltcGxlbWVudGVkIGNvcnJlY3RseSBldmVyeXRoaW5nIHdvdWxkIGJlDQo+a2VwdCB0aGUgc2Ft ZSBiZXR3ZWVuIGluc3RhbmNlcyBhbmQgdGhlcmUgaXMgbm8gbmVlZCBmb3Igc2V0dGluZyB1cCBh IG5ldw0KPnNlc3Npb24gdG8gZG8gdmVyaWZpY2F0aW9uIGZvciB0aGUgbmV3IGluc3RhbmNlLiBJ IHdlbnQgb3ZlciB0aGUgUkZDNTg4NA0KPmFuZCBJIGFtIG5vdCBlbnRpcmVseSBzdXJlIEJGRCBt YW5kYXRlIGEgbmV3IEJGRCBzZXNzaW9uIHRvIGJlIHNldHVwIGZvcg0KPnRoZSBuZXcgaW5zdGFu Y2UuIE5ldyBpbnN0YW5jZSBvZiB0aGUgTFNQIGlzIHBhcnQgb2YgdGhlIHNhbWUgc2Vzc2lvbiwN Cj5qdXN0IGEgZGlmZmVyZW50IGluY2FybmF0aW9uLCBlbmQgcG9pbnQgZXRjIGFyZSBzdGlsbCB0 aGUgc2FtZS4gSSBkb26p9nQNCj5zZWUgd2h5IEJGRCBzZXNzaW9uIGNhbqn2dCBiZSBpbmhlcml0 ZWQgZm9yIHRoZSBjb21wbGV0ZSBvdmVybGFwIGNhc2UuIEJ1dA0KPkkgd2lsbCBjaGVjayB3aXRo IG90aGVyIEJGRCBleHBlcnRzIHRvIG1ha2Ugc3VyZSBJIGFtIG5vdCBtYWtpbmcgaW5jb3JyZWN0 DQo+YXNzdW1wdGlvbi4gSXQgY291bGQgYmUganVzdCBhbiBjb21tb24gcHJhY3RpY2UgdGhhdCBC RkQgaXMgdGllZCB0bw0KPnNwZWNpZmljIGluc3RhbmNlIG9mIExTUCwgd2hpY2ggY2FuIGJlIGNo YW5nZWQgd2l0aG91dCBicmVha2luZyBCRkQNCj5zdGFuZGFyZCBhcyBwYXJ0IG9mIHRoaXMgcHJv cG9zZWQgb3B0aW1pemF0aW9uLg0KPg0KPjIuIEZvciB0aGUgcGFydGlhbCBvdmVybGFwIGNhc2Us IHlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LiBJIHdpbGwNCj5yZXdvcmQgdG8gbWFrZSBj bGVhciB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Igc2VwYXJhdGUgZGF0YSBwbGFuZQ0KPnZlcmlm aWNhdGlvbiBmb3IgdGhlIG5ldyBpbnN0YW5jZSwgdXNpbmcgdGhlIHNhbWUgbWV0aG9kLCBidXQg bm90IHJldXNpbmcNCj50aGUgc2FtZSBzZXNzaW9uLg0KPg0KPg0KPlJlZ2FyZHMsDQo+DQo+TWlu amllDQo+DQo+T24gMy8yOC8xNSwgNjozNiBQTSwgIk5vYm8gQWtpeWEiIDxub2JvLmFraXlhLmRl dkBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPj5IaSBBdXRob3JzLA0KPj4NCj4+SSBoYXZlIGNvdXBs ZSBvZiBjb21tZW50cyBmcm9tIE9BTSBwZXJzcGVjdGl2ZS4NCj4+KHVzaW5nIGVtYWlsIGluc3Rl YWQgb2YgbWljIHNpbmNlIHdlIHdlcmUgdmVyeSBzaG9ydCBvbiB0aW1lKQ0KPj4NCj4+U2VjdGlv biAyDQo+Pg0KPj4gICBUaGUNCj4+ICAgYmVzdCBjYXNlIHNjZW5hcmlvIGlzIGNvbXBsZXRlIG92 ZXJsYXAgb2YgdGhlIHR3byBwYXRocyBlbmQgdG8gZW5kOw0KPj4gICBpbiB3aGljaCBjYXNlIHRo ZXJlIGlzIG5vIG5lZWQgZm9yIGFueSBsYWJlbCBjaGFuZ2VzIGFuZCBMRklCDQo+PiAgIHVwZGF0 ZXMsIGJvdGggaW4gdGhlIHRyYW5zaXQgYXMgd2VsbCBhcyBpbiB0aGUgaW5ncmVzcyByb3V0ZXJz LiAgSW4NCj4+ICAgdGhpcyBzY2VuYXJpbyB0aGVyZSBpcyBhbHNvIG5vIG5lZWQgdG8gcGVyZm9y bSBkYXRhIHBsYW5lDQo+PiAgIHZlcmlmaWNhdGlvbiBmb3IgdGhlIG5ldyB0dW5uZWwgaW5zdGFu Y2UuDQo+Pg0KPj5CZWluZyBhIHBhcmFub2lkIE9BTSBwZXJzb24sIHRoZSBzdGF0ZW1lbnQgIm5v IG5lZWQgdG8gcGVyZm9ybSBkYXRhIHBsYW5lDQo+PnZlcmlmaWNhdGlvbiIgbWFrZXMgbWUgYSBi aXQgbmVydm91cy4gVGhlcmUncyBhIGJpZyBkaWZmZXJlbmNlIGJldHdlZW4NCj4+InRoZXJlIHNo b3VsZCBiZSBubyBkYXRhIHBsYW5lIGltcGFjdCIgdG8gInRoZXJlIGlzIG5vIGRhdGEgcGxhbmUN Cj4+aW1wYWN0IiwNCj4+cGFydGljdWxhcmx5IGJlY2F1c2UgY29kZSBjaGFuZ2VzIHJlcXVpcmVk IGFyZSB0byBub3QgY2hhbmdlIGV4aXN0aW5nDQo+PmRhdGENCj4+cGxhbmUgdmlhIGxhYmVsIHNo YXJpbmcgYnkgbXVsdGlwbGUgTFNQcy4gVGhhdCBpbXBsaWVzIHRoYXQgYW55DQo+PmJ1Z3MvdGlt aW5nLWlzc3Vlcy9ldGMgaW4gdGhhdCBzcGVjaWZpYyBjb2RlIHNwYWNlIGNhbiBjYXVzZSBleGlz dGluZw0KPj5kYXRhDQo+PnBsYW5lIHRvIGFjdHVhbGx5IHB1cmdlZCBbYWNjaWRlbnRseV0uIEkg d291bGQgZmVlbCBtb3JlIGNvbWZvcnRhYmxlIGlmDQo+PnRoZQ0KPj5kb2N1bWVudCBkaWQgbm90 IGltcGx5IHRoYXQgZXZlcnl0aGluZyBhYm91dCB0aGUgbmV3IExTUCBpcyBwZXJmZWN0bHkNCj4+ aGFwcHkNCj4+dy9vIGFueSBPQU0gdG8gdmVyaWZ5IGl0Lg0KPj4NCj4+ICAgRm9yIHRoZSBjYXNl IHdoZXJlIHRoZSB0d28NCj4+ICAgcGF0aHMgb3ZlcmxhcHMgb25seSBmcm9tIGEgY2VydGFpbiB0 cmFuc2l0IHJvdXRlciAocmF0aGVyIHRoYW4gZnJvbQ0KPj4gICB0aGUgaW5ncmVzcyksIGxhYmVs IHJldXNlIHN0YXJ0cyBhdCB0aGF0IHJvdXRlciBhbmQgY29udGludWVzIGFsbCB0aGUNCj4+ICAg d2F5IHRvIHRoZSBlZ3Jlc3Mgcm91dGVyLiAgSW4gdGhpcyBjYXNlIHRoZSBleGlzdGluZyBkYXRh IHBsYW5lDQo+PiAgIHZlcmlmaWNhdGlvbiBtZXRob2QgY2FuIHN0aWxsIGJlIHVzZWQgdG8gdmVy aWZ5IG5ldyB0dW5uZWwgaW5zdGFuY2UNCj4+ICAgYXMgYmVmb3JlLg0KPj4NCj4+SSdtIGZhaXJs eSBzdXJlIHRoYXQgeW91IGRpZCBub3QgaW1wbHkgImV4aXN0aW5nIGRhdGEgcGxhbmUgdmVyaWZp Y2F0aW9uDQo+Pl9pbnN0YW5jZV8gY2FuIHN0aWxsIGJlIHVzZWQgLi4uIi4gQnV0IHRvIGRvdWJs eSBtYWtlIHN1cmUgLi4uIGlmIHdlIHRha2UNCj4+QkZEIFtSRkM1ODg0XSBhcyBhbiBleGlzdGlu ZyBkYXRhIHBsYW5lIHZlcmlmaWNhdGlvbiBtZXRob2QsIHlvdSBjYW5ub3QNCj4+cmV1c2UgYW4g ZXhpc3RpbmcgQkZEIGluc3RhbmNlIChpLmUuLCBCRkQgc2Vzc2lvbiBmb3IgdGhlIG9sZCBMU1Ag Y2Fubm90DQo+PmJlDQo+PnVzZWQgZm9yIHRoZSBuZXcgTFNQKSwgc2luY2UgdGhlIEJGRCBzZXNz aW9uIG9uIHRoZSBlZ3Jlc3MgaXMgdGllZCB0byB0aGUNCj4+RkVDIGZvciB0aGUgb2xkIExTUC4g SWYgeW91IGF0dGVtcHQgdG8gZG8gdGhpcyB3L28gYW55IGZ1cnRoZXIgQkZEDQo+PnByb2NlZHVy ZXMsIHRoZSBCRkQgc2Vzc2lvbiBhdCB0aGUgZWdyZXNzIGZvciB0aGUgb2xkIExTUCB3aWxsIGJl IHJlbW92ZWQNCj4+d2hlbiB0aGUgb2xkIExTUCBpcyByZW1vdmVkIGZyb20gdGhlIGVncmVzcy4N Cj4+DQo+PlRoYW5rcyENCj4+DQo+Pi1Ob2JvDQo+Pg0KPj4NCj4+DQo+Pg0KPj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5tcGxzIG1haWxpbmcgbGlz dA0KPj5tcGxzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KPg0KDQo= From nobody Wed Apr 1 22:18:53 2015 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 722CA1B2A97 for ; Wed, 1 Apr 2015 22:18:52 -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 DJE5RyYzFOkB for ; Wed, 1 Apr 2015 22:18:50 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F361A1BE0 for ; Wed, 1 Apr 2015 22:18:49 -0700 (PDT) Received: by pactp5 with SMTP id tp5so73384659pac.1 for ; Wed, 01 Apr 2015 22:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Me5p+Y8wZ1AE/t/ESBnNOY7Da0Wl0pOMq0MG0jxsu+g=; b=HGTvQnMsZugrcLEa9byF0HhdWChD5w7I0ChGUcrFc90F1QAyZL9/rpdnXaVdz+pJ6I tmFgWYGw5CFcyikcryKSdQBKdJ0fgv0XKLGhJDyE3yKwfNSUzWHLLICkRnt0o1Mcg21L pyv6CM7mftfZjRmtghWWdWg3hwFhCSI+b0t0/PqianXHZuBE2bVXw8YtEElAN2iYrBUo Vi62n1iLBeYcdfc6/KnShgqJr+zligkeRwIwsZlzSkjxCKAYbAGgUHfvG8Mo9PRM54JG 1sY7DJJSwWVgkSSruv9Wt9WcFT+f+7eqIQLBoai9yYfxrresP6d5oeSxXJHwBn3R9nVf UWcQ== X-Received: by 10.66.227.169 with SMTP id sb9mr85253150pac.11.1427951929658; Wed, 01 Apr 2015 22:18:49 -0700 (PDT) Received: from NoboAkiyaPC ([209.49.1.194]) by mx.google.com with ESMTPSA id og11sm2186932pdb.91.2015.04.01.22.18.47 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Apr 2015 22:18:48 -0700 (PDT) From: "Nobo Akiya" To: "'Minjie Dai'" References: <006001d069c0$d9eadeb0$8dc09c10$@gmail.com> In-Reply-To: Date: Wed, 1 Apr 2015 22:18:46 -0700 Message-ID: <000c01d06d04$7f9c9790$7ed5c6b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ/uESsAe8QwkPH/+hptB22ujvDxwFUJ2AIAtWfeqibuUhXAA== Content-Language: en-ca Archived-At: Cc: 'mpls' Subject: Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse 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, 02 Apr 2015 05:18:52 -0000 Hi Minjie, Thanks for your response. Please see in-line with [NOBO]. > -----Original Message----- > From: Minjie Dai [mailto:mdai@juniper.net] > Sent: April-01-15 2:10 PM > To: Nobo Akiya > Cc: 'mpls' > Subject: Re: [mpls] Mail regarding = draft-dai-mpls-rsvp-te-mbb-label-reuse >=20 > Resending due to original mail got bounced and not appearing in the = mail > archive after a couple of days >=20 > On 3/30/15, 9:59 PM, "Minjie Dai" wrote: >=20 > >Hi Nobo, > > > >Thanks for taking time reviewing the draft. > > > >1. Regarding the case of complete path overlap, we do think with the > >correctly implemented software, the LSRs can avoid operations such as > >LFIB update and data path verification. Software implemented the new > >algorithm can bring in bugs, but this is no different from any other > >type of software change. Just as in existing MBB instance switch, = there > >are more chances to create more failures due to more updates in the > >system compare to the proposal which avoid majority of the update and > >changes. In addition, this doesn=B9t prevent continued monitoring of = the > >LSP health as before, we are just stating, if implemented correctly > >everything would be kept the same between instances and there is no > >need for setting up a new session to do verification for the new > >instance. [NOBO] This is probably something we won't be able to fully converge on. Optimistic person would likely say, yup no need to prove the new LSP = health with this mechanism. Paranoid person would likely say what I say :) >> I went over the RFC5884 and I am not entirely sure BFD > >mandate a new BFD session to be setup for the new instance. New > >instance of the LSP is part of the same session, just a different > >incarnation, end point etc are still the same. I don=B9t see why BFD > >session can=B9t be inherited for the complete overlap case. But I = will > >check with other BFD experts to make sure I am not making incorrect > >assumption. It could be just an common practice that BFD is tied to > >specific instance of LSP, which can be changed without breaking BFD standard > as part of this proposed optimization. [NOBO] The BFD session is tied to the FEC, and the FEC includes the = LSP-ID. >From what I understand, the old/new LSPs will have different LSP-ID? If = so, then that's the gotcha. > > > >2. For the partial overlap case, your understanding is correct. I = will > >reword to make clear that there is a need for separate data plane > >verification for the new instance, using the same method, but not > >reusing the same session. [NOBO] Thanks for considering my comments! -Nobo > > > > > >Regards, > > > >Minjie > > > >On 3/28/15, 6:36 PM, "Nobo Akiya" wrote: > > > >>Hi Authors, > >> > >>I have couple of comments from OAM perspective. > >>(using email instead of mic since we were very short on time) > >> > >>Section 2 > >> > >> The > >> best case scenario is complete overlap of the two paths end to = end; > >> in which case there is no need for any label changes and LFIB > >> updates, both in the transit as well as in the ingress routers. = In > >> this scenario there is also no need to perform data plane > >> verification for the new tunnel instance. > >> > >>Being a paranoid OAM person, the statement "no need to perform data > >>plane verification" makes me a bit nervous. There's a big difference > >>between "there should be no data plane impact" to "there is no data > >>plane impact", particularly because code changes required are to not > >>change existing data plane via label sharing by multiple LSPs. That > >>implies that any bugs/timing-issues/etc in that specific code space > >>can cause existing data plane to actually purged [accidently]. I = would > >>feel more comfortable if the document did not imply that everything > >>about the new LSP is perfectly happy w/o any OAM to verify it. > >> > >> For the case where the two > >> paths overlaps only from a certain transit router (rather than = from > >> the ingress), label reuse starts at that router and continues all = the > >> way to the egress router. In this case the existing data plane > >> verification method can still be used to verify new tunnel = instance > >> as before. > >> > >>I'm fairly sure that you did not imply "existing data plane > >>verification _instance_ can still be used ...". But to doubly make > >>sure ... if we take BFD [RFC5884] as an existing data plane > >>verification method, you cannot reuse an existing BFD instance = (i.e., > >>BFD session for the old LSP cannot be used for the new LSP), since = the > >>BFD session on the egress is tied to the FEC for the old LSP. If you > >>attempt to do this w/o any further BFD procedures, the BFD session = at > >>the egress for the old LSP will be removed when the old LSP is = removed > >>from the egress. > >> > >>Thanks! > >> > >>-Nobo > >> > >> > >> > >> > >>_______________________________________________ > >>mpls mailing list > >>mpls@ietf.org > >>https://www.ietf.org/mailman/listinfo/mpls > > From nobody Thu Apr 2 10:31:43 2015 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 75E031AD09B for ; Thu, 2 Apr 2015 10:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtjANHHMl0-k for ; Thu, 2 Apr 2015 10:31:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A13B1AD05C for ; Thu, 2 Apr 2015 10:31:39 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1432.namprd05.prod.outlook.com (25.160.107.154) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 17:31:38 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0125.002; Thu, 2 Apr 2015 17:31:38 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: [Bier] draft-wijnands-mpls-bier-encapsulation-02: Call for adoption Thread-Index: AQHQbI0ye6gTLvFz6UWokH0niunb/Z0585Og Date: Thu, 2 Apr 2015 17:31:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1432; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(69234005)(164054003)(2501003)(76576001)(18717965001)(74316001)(16236675004)(92566002)(62966003)(99286002)(450100001)(77156002)(230783001)(66066001)(19617315012)(87936001)(2656002)(19300405004)(15975445007)(2900100001)(110136001)(33656002)(102836002)(46102003)(86362001)(19625215002)(19580405001)(107886001)(54356999)(2351001)(50986999)(106116001)(122556002)(229853001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1432; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY1PR0501MB1432; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1432; x-forefront-prvs: 0534947130 Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB143048B33F7C91A3B1CE05BDA5F20BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 17:31:38.3140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1432 Archived-At: Subject: [mpls] FYI: [Bier] draft-wijnands-mpls-bier-encapsulation-02: Call for adoption 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, 02 Apr 2015 17:31:41 -0000 --_000_BY1PR0501MB143048B33F7C91A3B1CE05BDA5F20BY1PR0501MB1430_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJIChmb3IgeW91ciBpbmZvcm1hdGlvbik6IFRoZXJlIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24g Y3VycmVudGx5IGFjdGl2ZSBvbiB0aGUgQklFUiBlbWFpbCBsaXN0IGZvciBkcmFmdC13aWpuYW5k cy1tcGxzLWJpZXItZW5jYXBzdWxhdGlvbi0wMi4gSWYgeW91IGFyZSBpbnRlcmVzdGVkLCB0aGVu IHBsZWFzZSByZWFkIHRoZSBkb2N1bWVudCwgam9pbnQgdGhlIEJJRVIgV0cgbGlzdCwgYW5kIGNv bW1lbnQgb24gdGhhdCBsaXN0LiBUaGUgYWJzdHJhY3QgZm9yIHRoaXMgZG9jdW1lbnQgaXMgYmVs b3cuDQoNClRoYW5rcywgUm9zcw0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpBYnN0cmFjdA0KDQogICBC aXQgSW5kZXggRXhwbGljaXQgUmVwbGljYXRpb24gKEJJRVIpIGlzIGFuIGFyY2hpdGVjdHVyZSB0 aGF0DQogICBwcm92aWRlcyBvcHRpbWFsIG11bHRpY2FzdCBmb3J3YXJkaW5nIHRocm91Z2ggYSAi bXVsdGljYXN0IGRvbWFpbiIsDQogICB3aXRob3V0IHJlcXVpcmluZyBpbnRlcm1lZGlhdGUgcm91 dGVycyB0byBtYWludGFpbiBhbnkgcGVyLWZsb3cgc3RhdGUNCiAgIG9yIHRvIGVuZ2FnZSBpbiBh biBleHBsaWNpdCB0cmVlLWJ1aWxkaW5nIHByb3RvY29sLiAgV2hlbiBhIG11bHRpY2FzdA0KICAg ZGF0YSBwYWNrZXQgZW50ZXJzIHRoZSBkb21haW4sIHRoZSBpbmdyZXNzIHJvdXRlciBkZXRlcm1p bmVzIHRoZSBzZXQNCiAgIG9mIGVncmVzcyByb3V0ZXJzIHRvIHdoaWNoIHRoZSBwYWNrZXQgbmVl ZHMgdG8gYmUgc2VudC4gIFRoZSBpbmdyZXNzDQogICByb3V0ZXIgdGhlbiBlbmNhcHN1bGF0ZXMg dGhlIHBhY2tldCBpbiBhIEJJRVIgaGVhZGVyLiAgVGhlIEJJRVINCiAgIGhlYWRlciBjb250YWlu cyBhIGJpdHN0cmluZyBpbiB3aGljaCBlYWNoIGJpdCByZXByZXNlbnRzIGV4YWN0bHkgb25lDQog ICBlZ3Jlc3Mgcm91dGVyIGluIHRoZSBkb21haW47IHRvIGZvcndhcmQgdGhlIHBhY2tldCB0byBh IGdpdmVuIHNldCBvZg0KICAgZWdyZXNzIHJvdXRlcnMsIHRoZSBiaXRzIGNvcnJlc3BvbmRpbmcg dG8gdGhvc2Ugcm91dGVycyBhcmUgc2V0IGluDQogICB0aGUgQklFUiBoZWFkZXIuICBUaGUgZGV0 YWlscyBvZiB0aGUgZW5jYXBzdWxhdGlvbiBkZXBlbmQgb24gdGhlIHR5cGUNCiAgIG9mIG5ldHdv cmsgdXNlZCB0byByZWFsaXplIHRoZSBtdWx0aWNhc3QgZG9tYWluLiAgVGhpcyBkb2N1bWVudA0K ICAgc3BlY2lmaWVzIHRoZSBCSUVSIGVuY2Fwc3VsYXRpb24gdG8gYmUgdXNlZCBpbiBhbiBNUExT IG5ldHdvcmsuDQoNCkZyb206IEJJRVIgW21haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnIFNoZXBoZXJkDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDAxLCAyMDE1 IDExOjA0IEFNDQpUbzogYmllckBpZXRmLm9yZw0KU3ViamVjdDogW0JpZXJdIGRyYWZ0LXdpam5h bmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyOiBDYWxsIGZvciBhZG9wdGlvbg0KDQpUaGlz IGlzIHRoZSBvZmZpY2lhbCBXRyBDYWxsIEZvciBBZG9wdGlvbiBmb3IgdGhlIGZvbGxvd2luZyBJ RDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2lqbmFuZHMtbXBs cy1iaWVyLWVuY2Fwc3VsYXRpb24vDQoNCkF0IHRoZSBCSUVSIFdHIG1lZXRpbmcsIElFVEYgOTIg aW4gRGFsbGFzLCB0aGUgcm9vbSBpbmRpY2F0ZWQgc3VwcG9ydCBmb3IgYWRvcHRpb24uIFBsZWFz ZSByZXNwb25kIHRvIHRoZSBsaXN0IHdpdGggeW91ciB5ZXMvbm8gdm90ZSB0byBjb25maXJtLg0K DQpUaGFua3MsDQpHcmVnIChjaGFpcnMpDQo= --_000_BY1PR0501MB143048B33F7C91A3B1CE05BDA5F20BY1PR0501MB1430_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GWUkgKGZvciB5b3VyIGluZm9ybWF0aW9uKTogVGhlcmUg aXMgYSBjYWxsIGZvciBhZG9wdGlvbiBjdXJyZW50bHkgYWN0aXZlIG9uIHRoZSBCSUVSIGVtYWls IGxpc3QgZm9yIGRyYWZ0LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBJZiB5 b3UgYXJlIGludGVyZXN0ZWQsDQogdGhlbiBwbGVhc2UgcmVhZCB0aGUgZG9jdW1lbnQsIGpvaW50 IHRoZSBCSUVSIFdHIGxpc3QsIGFuZCBjb21tZW50IG9uIHRoYXQgbGlzdC4gVGhlIGFic3RyYWN0 IGZvciB0aGlzIGRvY3VtZW50IGlzIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCBSb3NzDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWJz dHJhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBCaXQgSW5kZXggRXhwbGljaXQgUmVwbGljYXRp b24gKEJJRVIpIGlzIGFuIGFyY2hpdGVjdHVyZSB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyBwcm92aWRlcyBvcHRpbWFsIG11bHRpY2FzdCBmb3J3YXJkaW5n IHRocm91Z2ggYSAmcXVvdDttdWx0aWNhc3QgZG9tYWluJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgd2l0aG91dCByZXF1aXJpbmcgaW50ZXJtZWRpYXRl IHJvdXRlcnMgdG8gbWFpbnRhaW4gYW55IHBlci1mbG93IHN0YXRlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvciB0byBlbmdhZ2UgaW4gYW4gZXhwbGljaXQgdHJl ZS1idWlsZGluZyBwcm90b2NvbC4mbmJzcDsgV2hlbiBhIG11bHRpY2FzdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZGF0YSBwYWNrZXQgZW50ZXJzIHRoZSBkb21h aW4sIHRoZSBpbmdyZXNzIHJvdXRlciBkZXRlcm1pbmVzIHRoZSBzZXQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG9mIGVncmVzcyByb3V0ZXJzIHRvIHdoaWNoIHRo ZSBwYWNrZXQgbmVlZHMgdG8gYmUgc2VudC4mbmJzcDsgVGhlIGluZ3Jlc3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHJvdXRlciB0aGVuIGVuY2Fwc3VsYXRlcyB0 aGUgcGFja2V0IGluIGEgQklFUiBoZWFkZXIuJm5ic3A7IFRoZSBCSUVSPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBoZWFkZXIgY29udGFpbnMgYSBiaXRzdHJpbmcg aW4gd2hpY2ggZWFjaCBiaXQgcmVwcmVzZW50cyBleGFjdGx5IG9uZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZWdyZXNzIHJvdXRlciBpbiB0aGUgZG9tYWluOyB0 byBmb3J3YXJkIHRoZSBwYWNrZXQgdG8gYSBnaXZlbiBzZXQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGVncmVzcyByb3V0ZXJzLCB0aGUgYml0cyBjb3JyZXNw b25kaW5nIHRvIHRob3NlIHJvdXRlcnMgYXJlIHNldCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhlIEJJRVIgaGVhZGVyLiZuYnNwOyBUaGUgZGV0YWlscyBv ZiB0aGUgZW5jYXBzdWxhdGlvbiBkZXBlbmQgb24gdGhlIHR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG9mIG5ldHdvcmsgdXNlZCB0byByZWFsaXplIHRoZSBt dWx0aWNhc3QgZG9tYWluLiZuYnNwOyBUaGlzIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBzcGVjaWZpZXMgdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiB0 byBiZSB1c2VkIGluIGFuIE1QTFMgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJJRVIgW21haWx0bzpi aWVyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWcgU2hlcGhlcmQ8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAwMSwgMjAxNSAxMTowNCBBTTxicj4N CjxiPlRvOjwvYj4gYmllckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbQmllcl0gZHJh ZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVuY2Fwc3VsYXRpb24tMDI6IENhbGwgZm9yIGFkb3B0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+VGhpcyBpcyB0aGUgb2ZmaWNpYWwgV0cgQ2FsbCBGb3IgQWRv cHRpb24gZm9yIHRoZSBmb2xsb3dpbmcgSUQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVuY2Fwc3VsYXRp b24vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aWpuYW5kcy1tcGxz LWJpZXItZW5jYXBzdWxhdGlvbi88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BdCB0aGUgQklFUiBXRyBt ZWV0aW5nLCBJRVRGIDkyIGluIERhbGxhcywgdGhlIHJvb20gaW5kaWNhdGVkIHN1cHBvcnQgZm9y IGFkb3B0aW9uLiBQbGVhc2UgcmVzcG9uZCB0byB0aGUgbGlzdCB3aXRoIHlvdXIgeWVzL25vIHZv dGUgdG8gY29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+R3JlZyAoY2hhaXJzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY1PR0501MB143048B33F7C91A3B1CE05BDA5F20BY1PR0501MB1430_-- From nobody Thu Apr 2 11:08:21 2015 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 1AF491A0086 for ; Thu, 2 Apr 2015 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5ydMMyP_Gdu for ; Thu, 2 Apr 2015 11:08:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FBD1A0030 for ; Thu, 2 Apr 2015 11:08:14 -0700 (PDT) Received: from BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) by BLUPR05MB232.namprd05.prod.outlook.com (10.255.191.18) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 18:08:14 +0000 Received: from BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 2 Apr 2015 18:08:13 +0000 Received: from BLUPR05MB564.namprd05.prod.outlook.com ([10.141.202.150]) by BLUPR05MB564.namprd05.prod.outlook.com ([10.141.202.150]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 18:08:13 +0000 From: Minjie Dai To: Nobo Akiya Thread-Topic: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse Thread-Index: AdBpwIwyiAChjxNzTYuMDuXIXWj/wgBdEjSAAFQwSwAAH7oHAAAMM+EA Date: Thu, 2 Apr 2015 18:08:12 +0000 Message-ID: References: <006001d069c0$d9eadeb0$8dc09c10$@gmail.com> <000c01d06d04$7f9c9790$7ed5c6b0$@gmail.com> In-Reply-To: <000c01d06d04$7f9c9790$7ed5c6b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB563; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB232; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(52604005)(37854004)(377454003)(41574002)(24454002)(479174004)(13464003)(46102003)(66066001)(561944003)(83506001)(76176999)(122556002)(86362001)(19580395003)(87936001)(19580405001)(50986999)(102836002)(77096005)(2900100001)(2656002)(54356999)(62966003)(2950100001)(77156002)(230783001)(92566002)(36756003)(93886004)(110136001)(15975445007)(99286002)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB564.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB563; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB563; x-forefront-prvs: 0534947130 Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 18:08:13.0054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB563 X-OriginatorOrg: juniper.net Archived-At: Cc: 'mpls' Subject: Re: [mpls] Mail regarding draft-dai-mpls-rsvp-te-mbb-label-reuse 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, 02 Apr 2015 18:08:18 -0000 VGhhbmtzIE5vYm8sDQoNCkkgdG9vayBhIHNlY29uZCBsb29rIG9mIHRoZSBCRkQgZHJhZnQgYW5k IGFsc28gTFNQIHBpbmcgZHJhZnQgNDM3OSwgZm9yDQpSU1ZQIExTUCwgTFNQIElEIGlzIHBhcnQg b2YgdGhlIEZFQywgc28geW91IGFyZSBjb3JyZWN0IHRvIHBvaW50IG91dCB0aGF0DQphIG5ldyBC RkQgc2Vzc2lvbiBuZWVkIHRvIGJlIGVzdGFibGlzaGVkIGZvciBuZXcgaW5zdGFuY2UgLGVpdGhl ciBiZWZvcmUNCm9yIGFmdGVyIExTUCBpbnN0YW5jZSBzd2l0Y2guDQoNClJlZ2FyZHMsDQoNCk1p bmppZQ0KDQpPbiA0LzEvMTUsIDEwOjE4IFBNLCAiTm9ibyBBa2l5YSIgPG5vYm8uYWtpeWEuZGV2 QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5IaSBNaW5qaWUsDQo+DQo+VGhhbmtzIGZvciB5b3VyIHJl c3BvbnNlLg0KPg0KPlBsZWFzZSBzZWUgaW4tbGluZSB3aXRoIFtOT0JPXS4NCj4NCj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBNaW5qaWUgRGFpIFttYWlsdG86bWRhaUBq dW5pcGVyLm5ldF0NCj4+IFNlbnQ6IEFwcmlsLTAxLTE1IDI6MTAgUE0NCj4+IFRvOiBOb2JvIEFr aXlhDQo+PiBDYzogJ21wbHMnDQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIE1haWwgcmVnYXJkaW5n DQo+PmRyYWZ0LWRhaS1tcGxzLXJzdnAtdGUtbWJiLWxhYmVsLXJldXNlDQo+PiANCj4+IFJlc2Vu ZGluZyBkdWUgdG8gb3JpZ2luYWwgbWFpbCBnb3QgYm91bmNlZCBhbmQgbm90IGFwcGVhcmluZyBp biB0aGUgbWFpbA0KPj4gYXJjaGl2ZSBhZnRlciBhIGNvdXBsZSBvZiBkYXlzDQo+PiANCj4+IE9u IDMvMzAvMTUsIDk6NTkgUE0sICJNaW5qaWUgRGFpIiA8bWRhaUBqdW5pcGVyLm5ldD4gd3JvdGU6 DQo+PiANCj4+ID5IaSBOb2JvLA0KPj4gPg0KPj4gPlRoYW5rcyBmb3IgdGFraW5nIHRpbWUgcmV2 aWV3aW5nIHRoZSBkcmFmdC4NCj4+ID4NCj4+ID4xLiBSZWdhcmRpbmcgdGhlIGNhc2Ugb2YgY29t cGxldGUgcGF0aCBvdmVybGFwLCB3ZSBkbyB0aGluayB3aXRoIHRoZQ0KPj4gPmNvcnJlY3RseSBp bXBsZW1lbnRlZCBzb2Z0d2FyZSwgdGhlIExTUnMgY2FuIGF2b2lkIG9wZXJhdGlvbnMgc3VjaCBh cw0KPj4gPkxGSUIgdXBkYXRlIGFuZCBkYXRhIHBhdGggdmVyaWZpY2F0aW9uLiBTb2Z0d2FyZSBp bXBsZW1lbnRlZCB0aGUgbmV3DQo+PiA+YWxnb3JpdGhtIGNhbiBicmluZyBpbiBidWdzLCBidXQg dGhpcyBpcyBubyBkaWZmZXJlbnQgZnJvbSBhbnkgb3RoZXINCj4+ID50eXBlIG9mIHNvZnR3YXJl IGNoYW5nZS4gSnVzdCBhcyBpbiBleGlzdGluZyBNQkIgaW5zdGFuY2Ugc3dpdGNoLCB0aGVyZQ0K Pj4gPmFyZSBtb3JlIGNoYW5jZXMgdG8gY3JlYXRlIG1vcmUgZmFpbHVyZXMgZHVlIHRvIG1vcmUg dXBkYXRlcyBpbiB0aGUNCj4+ID5zeXN0ZW0gY29tcGFyZSB0byB0aGUgcHJvcG9zYWwgd2hpY2gg YXZvaWQgbWFqb3JpdHkgb2YgdGhlIHVwZGF0ZSBhbmQNCj4+ID5jaGFuZ2VzLiBJbiBhZGRpdGlv biwgdGhpcyBkb2Vzbqn2dCBwcmV2ZW50IGNvbnRpbnVlZCBtb25pdG9yaW5nIG9mIHRoZQ0KPj4g PkxTUCBoZWFsdGggYXMgYmVmb3JlLCB3ZSBhcmUganVzdCBzdGF0aW5nLCBpZiBpbXBsZW1lbnRl ZCBjb3JyZWN0bHkNCj4+ID5ldmVyeXRoaW5nIHdvdWxkIGJlIGtlcHQgdGhlIHNhbWUgYmV0d2Vl biBpbnN0YW5jZXMgYW5kIHRoZXJlIGlzIG5vDQo+PiA+bmVlZCBmb3Igc2V0dGluZyB1cCBhIG5l dyBzZXNzaW9uIHRvIGRvIHZlcmlmaWNhdGlvbiBmb3IgdGhlIG5ldw0KPj4gPmluc3RhbmNlLg0K Pg0KPltOT0JPXSBUaGlzIGlzIHByb2JhYmx5IHNvbWV0aGluZyB3ZSB3b24ndCBiZSBhYmxlIHRv IGZ1bGx5IGNvbnZlcmdlIG9uLg0KPk9wdGltaXN0aWMgcGVyc29uIHdvdWxkIGxpa2VseSBzYXks IHl1cCBubyBuZWVkIHRvIHByb3ZlIHRoZSBuZXcgTFNQDQo+aGVhbHRoDQo+d2l0aCB0aGlzIG1l Y2hhbmlzbS4gUGFyYW5vaWQgcGVyc29uIHdvdWxkIGxpa2VseSBzYXkgd2hhdCBJIHNheSA6KQ0K Pg0KPj4+IEkgd2VudCBvdmVyIHRoZSBSRkM1ODg0IGFuZCBJIGFtIG5vdCBlbnRpcmVseSBzdXJl IEJGRA0KPj4gPm1hbmRhdGUgYSBuZXcgQkZEIHNlc3Npb24gdG8gYmUgc2V0dXAgZm9yIHRoZSBu ZXcgaW5zdGFuY2UuIE5ldw0KPj4gPmluc3RhbmNlIG9mIHRoZSBMU1AgaXMgcGFydCBvZiB0aGUg c2FtZSBzZXNzaW9uLCBqdXN0IGEgZGlmZmVyZW50DQo+PiA+aW5jYXJuYXRpb24sIGVuZCBwb2lu dCBldGMgYXJlIHN0aWxsIHRoZSBzYW1lLiBJIGRvbqn2dCBzZWUgd2h5IEJGRA0KPj4gPnNlc3Np b24gY2FuqfZ0IGJlIGluaGVyaXRlZCBmb3IgdGhlIGNvbXBsZXRlIG92ZXJsYXAgY2FzZS4gQnV0 IEkgd2lsbA0KPj4gPmNoZWNrIHdpdGggb3RoZXIgQkZEIGV4cGVydHMgdG8gbWFrZSBzdXJlIEkg YW0gbm90IG1ha2luZyBpbmNvcnJlY3QNCj4+ID5hc3N1bXB0aW9uLiBJdCBjb3VsZCBiZSBqdXN0 IGFuIGNvbW1vbiBwcmFjdGljZSB0aGF0IEJGRCBpcyB0aWVkIHRvDQo+PiA+c3BlY2lmaWMgaW5z dGFuY2Ugb2YgTFNQLCB3aGljaCBjYW4gYmUgY2hhbmdlZCB3aXRob3V0IGJyZWFraW5nIEJGRA0K PnN0YW5kYXJkDQo+PiBhcyBwYXJ0IG9mIHRoaXMgcHJvcG9zZWQgb3B0aW1pemF0aW9uLg0KPg0K PltOT0JPXSBUaGUgQkZEIHNlc3Npb24gaXMgdGllZCB0byB0aGUgRkVDLCBhbmQgdGhlIEZFQyBp bmNsdWRlcyB0aGUNCj5MU1AtSUQuDQo+RnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgdGhlIG9sZC9u ZXcgTFNQcyB3aWxsIGhhdmUgZGlmZmVyZW50IExTUC1JRD8gSWYNCj5zbywNCj50aGVuIHRoYXQn cyB0aGUgZ290Y2hhLg0KPg0KPj4gPg0KPj4gPjIuIEZvciB0aGUgcGFydGlhbCBvdmVybGFwIGNh c2UsIHlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LiBJIHdpbGwNCj4+ID5yZXdvcmQgdG8g bWFrZSBjbGVhciB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Igc2VwYXJhdGUgZGF0YSBwbGFuZQ0K Pj4gPnZlcmlmaWNhdGlvbiBmb3IgdGhlIG5ldyBpbnN0YW5jZSwgdXNpbmcgdGhlIHNhbWUgbWV0 aG9kLCBidXQgbm90DQo+PiA+cmV1c2luZyB0aGUgc2FtZSBzZXNzaW9uLg0KPg0KPltOT0JPXSBU aGFua3MgZm9yIGNvbnNpZGVyaW5nIG15IGNvbW1lbnRzIQ0KPg0KPi1Ob2JvDQo+DQo+PiA+DQo+ PiA+DQo+PiA+UmVnYXJkcywNCj4+ID4NCj4+ID5NaW5qaWUNCj4+ID4NCj4+ID5PbiAzLzI4LzE1 LCA2OjM2IFBNLCAiTm9ibyBBa2l5YSIgPG5vYm8uYWtpeWEuZGV2QGdtYWlsLmNvbT4gd3JvdGU6 DQo+PiA+DQo+PiA+PkhpIEF1dGhvcnMsDQo+PiA+Pg0KPj4gPj5JIGhhdmUgY291cGxlIG9mIGNv bW1lbnRzIGZyb20gT0FNIHBlcnNwZWN0aXZlLg0KPj4gPj4odXNpbmcgZW1haWwgaW5zdGVhZCBv ZiBtaWMgc2luY2Ugd2Ugd2VyZSB2ZXJ5IHNob3J0IG9uIHRpbWUpDQo+PiA+Pg0KPj4gPj5TZWN0 aW9uIDINCj4+ID4+DQo+PiA+PiAgIFRoZQ0KPj4gPj4gICBiZXN0IGNhc2Ugc2NlbmFyaW8gaXMg Y29tcGxldGUgb3ZlcmxhcCBvZiB0aGUgdHdvIHBhdGhzIGVuZCB0byBlbmQ7DQo+PiA+PiAgIGlu IHdoaWNoIGNhc2UgdGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55IGxhYmVsIGNoYW5nZXMgYW5kIExG SUINCj4+ID4+ICAgdXBkYXRlcywgYm90aCBpbiB0aGUgdHJhbnNpdCBhcyB3ZWxsIGFzIGluIHRo ZSBpbmdyZXNzIHJvdXRlcnMuICBJbg0KPj4gPj4gICB0aGlzIHNjZW5hcmlvIHRoZXJlIGlzIGFs c28gbm8gbmVlZCB0byBwZXJmb3JtIGRhdGEgcGxhbmUNCj4+ID4+ICAgdmVyaWZpY2F0aW9uIGZv ciB0aGUgbmV3IHR1bm5lbCBpbnN0YW5jZS4NCj4+ID4+DQo+PiA+PkJlaW5nIGEgcGFyYW5vaWQg T0FNIHBlcnNvbiwgdGhlIHN0YXRlbWVudCAibm8gbmVlZCB0byBwZXJmb3JtIGRhdGENCj4+ID4+ cGxhbmUgdmVyaWZpY2F0aW9uIiBtYWtlcyBtZSBhIGJpdCBuZXJ2b3VzLiBUaGVyZSdzIGEgYmln IGRpZmZlcmVuY2UNCj4+ID4+YmV0d2VlbiAidGhlcmUgc2hvdWxkIGJlIG5vIGRhdGEgcGxhbmUg aW1wYWN0IiB0byAidGhlcmUgaXMgbm8gZGF0YQ0KPj4gPj5wbGFuZSBpbXBhY3QiLCBwYXJ0aWN1 bGFybHkgYmVjYXVzZSBjb2RlIGNoYW5nZXMgcmVxdWlyZWQgYXJlIHRvIG5vdA0KPj4gPj5jaGFu Z2UgZXhpc3RpbmcgZGF0YSBwbGFuZSB2aWEgbGFiZWwgc2hhcmluZyBieSBtdWx0aXBsZSBMU1Bz LiBUaGF0DQo+PiA+PmltcGxpZXMgdGhhdCBhbnkgYnVncy90aW1pbmctaXNzdWVzL2V0YyBpbiB0 aGF0IHNwZWNpZmljIGNvZGUgc3BhY2UNCj4+ID4+Y2FuIGNhdXNlIGV4aXN0aW5nIGRhdGEgcGxh bmUgdG8gYWN0dWFsbHkgcHVyZ2VkIFthY2NpZGVudGx5XS4gSSB3b3VsZA0KPj4gPj5mZWVsIG1v cmUgY29tZm9ydGFibGUgaWYgdGhlIGRvY3VtZW50IGRpZCBub3QgaW1wbHkgdGhhdCBldmVyeXRo aW5nDQo+PiA+PmFib3V0IHRoZSBuZXcgTFNQIGlzIHBlcmZlY3RseSBoYXBweSB3L28gYW55IE9B TSB0byB2ZXJpZnkgaXQuDQo+PiA+Pg0KPj4gPj4gICBGb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIHR3 bw0KPj4gPj4gICBwYXRocyBvdmVybGFwcyBvbmx5IGZyb20gYSBjZXJ0YWluIHRyYW5zaXQgcm91 dGVyIChyYXRoZXIgdGhhbiBmcm9tDQo+PiA+PiAgIHRoZSBpbmdyZXNzKSwgbGFiZWwgcmV1c2Ug c3RhcnRzIGF0IHRoYXQgcm91dGVyIGFuZCBjb250aW51ZXMgYWxsDQo+PnRoZQ0KPj4gPj4gICB3 YXkgdG8gdGhlIGVncmVzcyByb3V0ZXIuICBJbiB0aGlzIGNhc2UgdGhlIGV4aXN0aW5nIGRhdGEg cGxhbmUNCj4+ID4+ICAgdmVyaWZpY2F0aW9uIG1ldGhvZCBjYW4gc3RpbGwgYmUgdXNlZCB0byB2 ZXJpZnkgbmV3IHR1bm5lbCBpbnN0YW5jZQ0KPj4gPj4gICBhcyBiZWZvcmUuDQo+PiA+Pg0KPj4g Pj5JJ20gZmFpcmx5IHN1cmUgdGhhdCB5b3UgZGlkIG5vdCBpbXBseSAiZXhpc3RpbmcgZGF0YSBw bGFuZQ0KPj4gPj52ZXJpZmljYXRpb24gX2luc3RhbmNlXyBjYW4gc3RpbGwgYmUgdXNlZCAuLi4i LiBCdXQgdG8gZG91Ymx5IG1ha2UNCj4+ID4+c3VyZSAuLi4gaWYgd2UgdGFrZSBCRkQgW1JGQzU4 ODRdIGFzIGFuIGV4aXN0aW5nIGRhdGEgcGxhbmUNCj4+ID4+dmVyaWZpY2F0aW9uIG1ldGhvZCwg eW91IGNhbm5vdCByZXVzZSBhbiBleGlzdGluZyBCRkQgaW5zdGFuY2UgKGkuZS4sDQo+PiA+PkJG RCBzZXNzaW9uIGZvciB0aGUgb2xkIExTUCBjYW5ub3QgYmUgdXNlZCBmb3IgdGhlIG5ldyBMU1Ap LCBzaW5jZSB0aGUNCj4+ID4+QkZEIHNlc3Npb24gb24gdGhlIGVncmVzcyBpcyB0aWVkIHRvIHRo ZSBGRUMgZm9yIHRoZSBvbGQgTFNQLiBJZiB5b3UNCj4+ID4+YXR0ZW1wdCB0byBkbyB0aGlzIHcv byBhbnkgZnVydGhlciBCRkQgcHJvY2VkdXJlcywgdGhlIEJGRCBzZXNzaW9uIGF0DQo+PiA+PnRo ZSBlZ3Jlc3MgZm9yIHRoZSBvbGQgTFNQIHdpbGwgYmUgcmVtb3ZlZCB3aGVuIHRoZSBvbGQgTFNQ IGlzIHJlbW92ZWQNCj4+ID4+ZnJvbSB0aGUgZWdyZXNzLg0KPj4gPj4NCj4+ID4+VGhhbmtzIQ0K Pj4gPj4NCj4+ID4+LU5vYm8NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Pm1wbHMgbWFp bGluZyBsaXN0DQo+PiA+Pm1wbHNAaWV0Zi5vcmcNCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiA+DQo+DQo+DQoNCg== From nobody Thu Apr 2 22:52:43 2015 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 695F41A90C5 for ; Thu, 2 Apr 2015 22:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ciMa9yERXOLv for ; Thu, 2 Apr 2015 22:52:40 -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 2EAE21A90C8 for ; Thu, 2 Apr 2015 22:52:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUL27738; Fri, 03 Apr 2015 05:52:37 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Apr 2015 06:52:36 +0100 Received: from SZXEMA507-MBS.china.huawei.com ([169.254.6.245]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 3 Apr 2015 13:52:31 +0800 From: "Hejia (Jia)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Thread-Index: AQHQawKLkKmCufCfd0u8+IIc6tkkYp013ykAgATOCBA= Date: Fri, 3 Apr 2015 05:52:30 +0000 Message-ID: <735916399E11684EAF4EB4FB376B719551B538AC@szxema507-mbs.china.huawei.com> References: <551A772A.2040004@pi.nu> In-Reply-To: <551A772A.2040004@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls-chairs@tools.ietf.org" , "elisa.bellagamba@ericsson.com" , "dward@cisco.com" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 03 Apr 2015 05:52:42 -0000 Yes, support. One tiny comment, the reference to [RSVP-TE-CONF] could be replaced by RFC = 7487 now. =20 B.R. Jia -----Original Message----- Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Date: Mon, 30 Mar 2015 15:59:46 +0000 From: Ross Callon To: mpls@ietf.org CC: Loa Andersson , dward@cisco.com , mpls-chairs@tools.ietf.org ,= elisa.bellagamba@ericsson.com Reminder, the WGLC for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09 ends la= ter this week. So far there are no responses. If you care about this document, then please read it and reply to the WGLC. Thanks, Ross *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross Callon *Sent:* Tuesday, March 10, 2015 4:46 PM *To:* mpls@ietf.org *Cc:* mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org *Subject:* [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls= -tp-oam-conf Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-m= pls-tp-oam-conf-09. Because this WGLC will span the IETF in Dallas, it will be extended to just= over three weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org ). There are no IPR disclosures against this document. All the authors have st= ated that they are not aware of any IPR that relates to this draft (two of the responses w= ere private to the WG chairs). This working group last call ends Thursday April 2, 2015. Ross for the MPLS WG chairs From nobody Fri Apr 3 15:09:34 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E63051A1B17; Fri, 3 Apr 2015 15:09:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1751A1AC2 for ; Fri, 3 Apr 2015 15:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 UJjDZpARMHKw for ; Fri, 3 Apr 2015 15:09:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC741A1AF0 for ; Fri, 3 Apr 2015 15:09:11 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:47725 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ye9m2-0000DQ-MH for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Fri, 03 Apr 2015 15:09:11 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t33M95Ex002412 for ; Fri, 3 Apr 2015 22:09:05 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 1E9E7C2081E; Fri, 3 Apr 2015 22:09:05 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> References: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #815506 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 03 Apr 2015 22:09:05 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150403220911.BBC741A1AF0@ietfa.amsl.com> Resent-Date: Fri, 3 Apr 2015 15:09:11 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org Subject: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 22:09:33 -0000 Dear Authors, We have two questions about the assignments requested by this document: 1) Which range should be used for the TLV registrations? 0-16383 Standards Action (This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized.) 16384-31743 Specification Required (Experimental RFC needed) 32768-49161 Standards Action (This range is for optional TLVs that can be silently dropped if not recognized.) 49162-64511 Specification Required (Experimental RFC needed) 2) Can you confirm that we should make the Message Types assignment from the Standards Action range (0-191) , rather than the Specification Required range (192-255)? Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters thanks, Amanda Baber IANA Request Specialist ICANN From nobody Fri Apr 3 16:05:31 2015 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 2D7F71A8743; Fri, 3 Apr 2015 16:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 DpXQlhQIFsZT; Fri, 3 Apr 2015 16:05:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8611A873C; Fri, 3 Apr 2015 16:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150403230528.30746.97488.idtracker@ietfa.amsl.com> Date: Fri, 03 Apr 2015 16:05:28 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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, 03 Apr 2015 23:05:29 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ From nobody Sat Apr 4 10:26:13 2015 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 B674C1A0041 for ; Sat, 4 Apr 2015 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Y1R73g2_Qfiz for ; Sat, 4 Apr 2015 10:26:10 -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 5D8851A0023 for ; Sat, 4 Apr 2015 10:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4340; q=dns/txt; s=iport; t=1428168371; x=1429377971; h=from:to:cc:subject:date:message-id:mime-version; bh=WdpvlvIrQpOM1EYEKH708bvAxIOWoyqdbfXuGquiIIM=; b=hD9c5bHjIglsj/b9h2Q+vJHqiFoc5cAtAktkcHPW0WF2pFy5U5lEkQXD wtF0rhdvferSLphlZfJ/QvblEFfiqZ4cuB9gttcNu0s8/qQKHHjYdDEGT 0byj3MAt5s1Ys9pcrsz9MR7A8yUV8T7IJULgmkjeU9O2veX7gkaM7Z5Lf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AWBQDHHSBV/4oNJK1cgkVDgS4Fy22BHUwBAQEBAQF+hB4BAgQdEEELEgEIBAoDAwECKDkUCQoEAQ0FiC/MHQEBAQEBAQEBAQEBAQEBAQEBAQEBGIsphGgRhDQFkGuKAoEdgzWMOoNIIoIzgTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,523,1422921600"; d="scan'208,217";a="406069777" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 04 Apr 2015 17:26:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t34HQ9ZY014492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Apr 2015 17:26:09 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.109]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sat, 4 Apr 2015 12:26:09 -0500 From: "Faisal Iqbal (faiqbal)" To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 Thread-Index: AQHQbvxu+p3HjS95y0iXmgq5BivpTg== Date: Sat, 4 Apr 2015 17:26:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.100] Content-Type: multipart/alternative; boundary="_000_D145966FCE3Cfaiqbalciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 04 Apr 2015 17:26:11 -0000 --_000_D145966FCE3Cfaiqbalciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve followed this draft and related discussions and I believe it is read= y for publication. Regards, Faisal Iqbal From: Ross Callon > Date: Friday, March 20, 2015 at 10:03 AM To: "mpls@ietf.org" > Cc: Loa Andersson >, "'= mpls-chairs@tools. org'" > Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-= mode-simple-01 Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-r= eply-mode-simple-01. Because this WGLC will span the IETF in Dallas, it will be extended to thre= e weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have st= ated that they are not aware of any IPR that relates to this draft. This working group last call ends Friday April 10, 2015. Ross for the MPLS WG chairs --_000_D145966FCE3Cfaiqbalciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <66E1E89ACB30854398344EE48F991905@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I=92ve followed this draft and related discussions and I believe it is= ready for publication.

Regards,
Faisal Iqbal

From: Ross Callon <rcallon@juniper.net>
Date: Friday, March 20, 2015 at 10:= 03 AM
To: "mpls@ietf.org" <mpls@i= etf.org>
Cc: Loa Andersson <loa@mail01.huawei.com>, "'mpls-chai= rs@tools. org'" <mpls= -chairs@tools.ietf.org>
Subject: [mpls] working group last = call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Working Group,
 
This is to initiate a working group last call on draft-ietf-mpls-lsp-p= ing-reply-mode-simple-01.
Because this WGLC will span the IETF in Dallas, it will be extended to= three weeks.
 
Please send your comments to the mpls wg mailing list (mpls@ietf.org).
 
There are no IPR disclosures against this document. All the authors ha= ve stated that they
are not aware of any IPR that relates to this draft.
 
This working group last call ends Friday  April 10, 2015.  <= /div>
 
Ross
for the MPLS WG chairs
 
 
--_000_D145966FCE3Cfaiqbalciscocom_-- From nobody Sun Apr 5 17:10:35 2015 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 B670A1ACE7C for ; Sun, 5 Apr 2015 17:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDYI0qnEYh7a for ; Sun, 5 Apr 2015 17:10:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CDB1ACE75 for ; Sun, 5 Apr 2015 17:10:31 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1429.namprd05.prod.outlook.com (25.160.107.151) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 6 Apr 2015 00:10:30 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0125.002; Mon, 6 Apr 2015 00:10:29 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Thread-Index: AQHQb/4XUj4KO1FX70O31W+6j8Sx3A== Date: Mon, 6 Apr 2015 00:10:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1429; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(377454003)(46102003)(74316001)(66066001)(19580395003)(19580405001)(19609705001)(102836002)(2501003)(18717965001)(40100003)(122556002)(15975445007)(86362001)(99286002)(76576001)(77156002)(62966003)(19300405004)(50986999)(2656002)(19625215002)(76176999)(230783001)(2900100001)(2950100001)(87936001)(16236675004)(106116001)(54356999)(92566002)(110136001)(2351001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1429; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY1PR0501MB1429; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1429; x-forefront-prvs: 0538A71254 Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB14307B7B5965125211314F1FA5FE0BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2015 00:10:29.7367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1429 Archived-At: Cc: Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 06 Apr 2015 00:10:33 -0000 --_000_BY1PR0501MB14307B7B5965125211314F1FA5FE0BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This working group last call has now ended. There was one public response (to the MPLS working group) in support. I als= o got private responses of support from two of the authors. Otherwise there= were no responses (neither in favor nor opposed). This is not sufficient t= o constitute "rough consensus". As such the working group last call has fai= led. My inclination is to wait for the July IETF (in Prague), and give the autho= rs an opportunity to present and solicit additional support. Depending upon= the response there, we may then repeat the WGLC. Thanks, Ross (as WG co-chair) From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, March 10, 2015 4:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@t= ools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-t= p-oam-conf Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-m= pls-tp-oam-conf-09. Because this WGLC will span the IETF in Dallas, it will be extended to just= over three weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have st= ated that they are not aware of any IPR that relates to this draft (two of the responses w= ere private to the WG chairs). This working group last call ends Thursday April 2, 2015. Ross for the MPLS WG chairs --_000_BY1PR0501MB14307B7B5965125211314F1FA5FE0BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This working group last c= all has now ended.

 <= /p>

There was one public resp= onse (to the MPLS working group) in support. I also got private responses o= f support from two of the authors. Otherwise there were no responses (neither in favor nor opposed). This is not sufficient to con= stitute “rough consensus”. As such the working group last call = has failed.

 <= /p>

My inclination is to wait= for the July IETF (in Prague), and give the authors an opportunity to pres= ent and solicit additional support. Depending upon the response there, we may then repeat the WGLC.

 <= /p>

Thanks, Ross

(as WG co-chair)

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Tuesday, March 10, 2015 4:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam= -conf@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -mpls-tp-oam-conf

 

Working Group,

 

This is to initiate a working group las= t call on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09.

Because this WGLC will span the IETF in= Dallas, it will be extended to just over three weeks.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have stated that they

are not aware of any IPR that relates t= o this draft (two of the responses were private to

the WG chairs).

 

This working group last call ends Thurs= day  April 2, 2015. 

 

Ross

for the MPLS WG chairs

 

 

--_000_BY1PR0501MB14307B7B5965125211314F1FA5FE0BY1PR0501MB1430_-- From nobody Sun Apr 5 18:10:35 2015 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 B7D1B1ACECD for ; Sun, 5 Apr 2015 18:10:33 -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 uYn9k7jkWviI for ; Sun, 5 Apr 2015 18:10:31 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751A91ACEC4 for ; Sun, 5 Apr 2015 18:10:31 -0700 (PDT) Received: by pddn5 with SMTP id n5so28561886pdd.2 for ; Sun, 05 Apr 2015 18:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=C6lC/+3h8QK7sXfvkNSIVSX4NwCY2C5yjzetn+QbGxw=; b=ME2Ov4BBAz1kRvRq1ZKWJlEf4OOLRerQ12OIcBEyJ7c9pWKUxKgIrdGinnpDT94ldc IG7BiQxiNZ81703so+8aSdfEETldAWs2gqs0ySAqSPZJKC+KAAFsLC0YKLT3xhnXVLez 6TtDICnmoDk65EmtmjdNqtDxBdwa9Ob7i7SIXtMB1mcEjwnxohHLAeuNpSNQhAgOdBjz RjKhUM0GpgkmRWkLbLzwBbslIc/poVgkeoy/RLoOJKVtWNuovDz/bH4iK/Yo2QcXUklf 832r83aIzfmfsC9cOKTTt7kRQvQRvgA5dyrjvKYjUOuN+oZLEsWx12nIU7z19/pdF05r AAbg== X-Received: by 10.68.231.66 with SMTP id te2mr23395823pbc.118.1428282631180; Sun, 05 Apr 2015 18:10:31 -0700 (PDT) Received: from NoboAkiyaPC (108-245-44-219.lightspeed.sntcca.sbcglobal.net. [108.245.44.219]) by mx.google.com with ESMTPSA id ts4sm2667482pbc.41.2015.04.05.18.10.29 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Apr 2015 18:10:30 -0700 (PDT) From: "Nobo Akiya" To: "'Ross Callon'" , References: In-Reply-To: Date: Sun, 5 Apr 2015 18:10:26 -0700 Message-ID: <005801d07006$789a7ed0$69cf7c70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugHj/uh8nOZ5mVA= Content-Language: en-ca Archived-At: Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 06 Apr 2015 01:10:33 -0000 Hi Ross, My apologies for being late. I skipped over all the PM details, but read rest of the document. This document defines an important functionality for TP OAM, and I do support = its progress. I did spot few things which should be addressed in the document = (especially #1 and #4). 1. Section 2.2 - BFD Configuration sub-TLV, which MUST be included if either the CC, the CV or both OAM Function flags being set in the OAM Function Flags Sub-TLV [RFC7260]. I'm guessing that above is a copy & paste error/leftover. MPLS OAM = Function TLV is defined in the section 2.2 of the draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf document, and the TLV has MPLS = OAM TLV Flags defined. We would want to refer to the MPLS OAM TLV Flags in = the MPLS OAM Function TLV instead of OAM Function flags in the OAM Function Flags Sub-TLV defined in RFC7260. And if above is true (and the text is corrected), then the reference to RFC7260 can also be removed (as it is not mentioned anywhere else in = this document). 2. Section 2.2 This sub-TLV MUST carry a "BFD Local Discriminator sub-TLV" and a "Timer Negotiation Parameters sub-TLV" if the N flag is cleared. The "Source MEP-ID sub-TLV" MUST also be included. If the I flag is set, the "BFD Authentication sub-TLV" MAY be included. I think above should be removed, as it is a subset (and a bit confusion subset) of what is better described at the end of Section 2.2.1 anyways. 3. Section 2.2.1 In this case an updated Negotiation Timer Parameters sub-TLV, containing values supported by the egress node, is returned to the ingress. Above is probably a good place to reference RFC7419 to prevent = problematic interop of multiple devices. 4. Section 2.2.4 There needs to be some synchronicity between AuthType/AuthKeyID to = specified in "this" MPLS echo request message and AuthType/AuthKeyID being used by = BFD control packets. For example: - If BFD control packets using "new" auth is received by the egress LSR before MPLS echo request with new "auth" is received, all BFD control packets using "new" auth will be dropped. - To take that a step further, if BFD control packets using "new" auth = is received by the egress LSR before "this" MPLS echo request is received = by the egress LSR and corresponding BFD session is updated to point to the "new" auth , all BFD control packets using "new" auth will be dropped. - If BFD control packets using "new" auth is only sent X time after = sending the MPLS echo request with new "auth", then it is not guaranteed that = the egress LSR will still be accepting BFD control packets with "old" auth = for X amount of time. - And of course there's the error case of the egress LSR not being able = to support the specified the "new" auth specified in received MPLS echo request, but the ingress LSR starts using the "new" auth before it = receives back NOSUP from the egress LSR via MPLS echo reply. I suspect if sufficient details are not defined, we would likely run = into some inter-op issues with this aspect. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: April-05-15 5:10 PM > To: mpls@ietf.org > Cc: Ross Callon; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf@tools.ietf.org > Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf >=20 > This working group last call has now ended. >=20 > There was one public response (to the MPLS working group) in support. = I also > got private responses of support from two of the authors. Otherwise = there were > no responses (neither in favor nor opposed). This is not sufficient to constitute > =93rough consensus=94. As such the working group last call has failed. >=20 > My inclination is to wait for the July IETF (in Prague), and give the authors an > opportunity to present and solicit additional support. Depending upon = the > response there, we may then repeat the WGLC. >=20 > Thanks, Ross > (as WG co-chair) >=20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Tuesday, March 10, 2015 4:46 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf@tools.ietf.org > Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf >=20 > Working Group, >=20 > This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf-09. > Because this WGLC will span the IETF in Dallas, it will be extended to just over > three weeks. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There are no IPR disclosures against this document. All the authors = have stated > that they > are not aware of any IPR that relates to this draft (two of the = responses were > private to > the WG chairs). >=20 > This working group last call ends Thursday=A0 April 2, 2015. >=20 > Ross > for the MPLS WG chairs >=20 >=20 From nobody Mon Apr 6 11:29:02 2015 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 3DD471A909C; Mon, 6 Apr 2015 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBbEzaVXiGF7; Mon, 6 Apr 2015 11:25:54 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682401A908F; Mon, 6 Apr 2015 11:25:54 -0700 (PDT) Received: by iggg4 with SMTP id g4so8377879igg.0; Mon, 06 Apr 2015 11:25:53 -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=P7IfUONHD84I5oiDrktuOlOCL8on5vYdOFDb74WYrlw=; b=w+tC20hF1YOYDWWb7Lu2XPdRly3VDtzAg9Vox9jKW9G5rRR2L3zexyFOZ+xMd/Qpj4 rwhTZBSy0axw5tkpIveAf3YJ2nZLvoCnG9Lx+12Jgf0wEIaC31Rn4l4f8N5rWSDqglGc 9ifI2f0enQFfVb2TqfjyuUGD4ec3zHFTPhT+dM+M6T30o3B6tWIYPJOzCYGFJQK+6ker r6mcITU2Ifp1TedelohaJlCuvcQgWLfH+o8xgS9xlZUhkA06jpcTX3aFWc02CcAFOpNf YEv/RSENFiSykY/uHDjY1zVrVCjMbZS1kMfjODD4fYcnjFMWwEvC0ud4CFMP3FEGuAc6 tUmw== MIME-Version: 1.0 X-Received: by 10.50.79.233 with SMTP id m9mr21859528igx.45.1428344753812; Mon, 06 Apr 2015 11:25:53 -0700 (PDT) Received: by 10.107.52.21 with HTTP; Mon, 6 Apr 2015 11:25:53 -0700 (PDT) In-Reply-To: <550AABAC.9020008@cisco.com> References: <55033E87.3030305@juniper.net> <5503403E.4050304@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CB77@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CBB2@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1827D3C5@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CCE9@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CEFD@NKGEML512-MBS.china.huawei.com> <550A2B98.4010409@gmail.com> <95467337-1826-4C9E-888A-ABABE872CD56@cisco.com> <550AABAC.9020008@cisco.com> Date: Mon, 6 Apr 2015 11:25:53 -0700 Message-ID: From: Tony Przygienda To: Stewart Bryant Content-Type: multipart/alternative; boundary=089e0139fffcab1e100513126d2f Archived-At: X-Mailman-Approved-At: Mon, 06 Apr 2015 11:29:01 -0700 Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" , Antoni Przygienda , "IJsbrand Wijnands \(iwijnand\)" , "Jeffrey \(Zhaohui\) Zhang" Subject: Re: [mpls] [Bier] Encapsulation first nibble 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, 06 Apr 2015 18:25:56 -0000 --089e0139fffcab1e100513126d2f Content-Type: text/plain; charset=UTF-8 As individual contributor: So, hold and below, I refreshed my memory on all the PWE3 architecture and control words and PW and got enlilghtened about the 'heuristical' DPIs and generally me thinks that we cannot use the 4 bits as 'version number' starting at 0 but have to align the 4 bits with the PW CW which already took the 0000 and 0001 while the 4 and 6 are black magic to be avoided. With that I think now Eric makes most sense (while the 0x15 is intriguing as well). So, will BIER be IPv7 ? or IPv8 to leave IPv7 some breathing space ;-) On Thu, Mar 19, 2015 at 3:57 AM, Stewart Bryant wrote: > Re-my last email. > > Aren't learning spell correctors annoying! VCXO was supposed to be > VCCV. Clearly my iPad feels itself to be more closely affiliated to my > radio interests than my PW interests :( > > - Stewart > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --089e0139fffcab1e100513126d2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As individual= contributor:=C2=A0

<= /div>
So, hold and below, I refr= eshed my memory on all the PWE3 architecture and control words and PW and g= ot enlilghtened about the 'heuristical' DPIs and generally me think= s that we cannot use the 4 bits as 'version number' starting at 0 b= ut have to align the 4 bits with the PW CW which already took the 0000 and = 0001 =C2=A0while the 4 and 6 are black magic to be avoided.=C2=A0

With that I think now Eric makes most sense (while the = =C2=A00x15 is intriguing as well). So, will BIER be IPv7 ? =C2=A0or IPv8 to= leave IPv7 =C2=A0some breathing space ;-)=C2=A0

On Thu, Mar 19, 2015 at 3:57 AM,= Stewart Bryant <stbryant@cisco.com> wrote:
Re-my last email.

Aren't learning spell correctors annoying!=C2=A0 VCXO was supposed to b= e
VCCV.=C2=A0 Clearly my iPad feels itself to be more closely affiliated to m= y
radio interests than my PW interests :(

- Stewart



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

--089e0139fffcab1e100513126d2f-- From nobody Mon Apr 6 13:15:42 2015 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 5EB2D1A9128 for ; Mon, 6 Apr 2015 13:15:41 -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 6j8S5XP7BH1g for ; Mon, 6 Apr 2015 13:15:39 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F5C1A9127 for ; Mon, 6 Apr 2015 13:15:35 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so54907533pdb.0 for ; Mon, 06 Apr 2015 13:15:34 -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=uaY2HwB08APHE3moazEG2kzog7Ga1YyryxontlEn0L8=; b=C/CaOMRajTd52g+FIfPBuM3J4CiCWNSzWSVcw61/0erMX/9YRq3CgZpTXDS2OwQwf7 3xC2LRXS59bj3Kjn1VE89Y1ZyOzc3X3UKUsYcA0Bt+kPTEtaysylDPQ0P461ID0K3BIy c9OC8siCVifOclsbEfdwhiQ1iodqnphxgD4dCv7Ksj42yhrbOoZRQWq5rUWPl9MGAq3d 0aK+PuAjwGxb5tfdiKzq1MWTLUHofC/f066ncvNIS32IDKG5qm2nRfIoby+aFFiPZjFV NK63MuxtN+HGFPt4+5GBX0eHfWpsj/heSMINkghmRRefqLAJRPncs9XuZMxUhAGBCoak N9+g== X-Received: by 10.70.90.233 with SMTP id bz9mr30128651pdb.47.1428351334864; Mon, 06 Apr 2015 13:15:34 -0700 (PDT) Received: from [100.110.33.242] ([104.135.1.242]) by mx.google.com with ESMTPSA id fz15sm5592768pdb.54.2015.04.06.13.15.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 13:15:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AE71BAF4-D9A7-45CC-AE8A-61818BF3CE44 Mime-Version: 1.0 (1.0) From: Sam Aldrin X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Mon, 6 Apr 2015 13:15:32 -0700 Content-Transfer-Encoding: 7bit Message-Id: <703BA676-95DA-4573-948E-41EB395CA83F@gmail.com> References: To: Ross Callon Archived-At: Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 06 Apr 2015 20:15:41 -0000 --Apple-Mail-AE71BAF4-D9A7-45CC-AE8A-61818BF3CE44 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Useful draft from operator perspective. Thank the authors for considering my= comments. Support its last call. Sam Sent from my iPhone > On Mar 20, 2015, at 7:03 AM, Ross Callon wrote: >=20 > Working Group, > =20 > This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-= reply-mode-simple-01. > Because this WGLC will span the IETF in Dallas, it will be extended to thr= ee weeks. > =20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > =20 > There are no IPR disclosures against this document. All the authors have s= tated that they > are not aware of any IPR that relates to this draft. > =20 > This working group last call ends Friday April 10, 2015.=20 > =20 > Ross > for the MPLS WG chairs > =20 > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-AE71BAF4-D9A7-45CC-AE8A-61818BF3CE44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Useful draft from operator perspective. Thank the authors for considering my comments. Support its last call.

Sam

Sent from my iPhone

On Mar 20, 2015, at 7:03 AM, Ross Callon <rcallon@juniper.net> wrote:

Working Group,
 
This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01.
Because this WGLC will span the IETF in Dallas, it will be extended to three weeks.
 
Please send your comments to the mpls wg mailing list (mpls@ietf.org).
 
There are no IPR disclosures against this document. All the authors have stated that they
are not aware of any IPR that relates to this draft.
 
This working group last call ends Friday  April 10, 2015. 
 
Ross
for the MPLS WG chairs
 
 
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--Apple-Mail-AE71BAF4-D9A7-45CC-AE8A-61818BF3CE44-- From nobody Mon Apr 6 13:46:31 2015 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 A4BF51A92B4; Mon, 6 Apr 2015 13:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 lLvhjsKZg8ik; Mon, 6 Apr 2015 13:46:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5430B1A9237; Mon, 6 Apr 2015 13:46:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8575C180475; Mon, 6 Apr 2015 13:45:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150406204538.8575C180475@rfc-editor.org> Date: Mon, 6 Apr 2015 13:45:38 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7510 on Encapsulating MPLS in UDP 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, 06 Apr 2015 20:46:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7510 Title: Encapsulating MPLS in UDP Author: X. Xu, N. Sheth, L. Yong, R. Callon, D. Black Status: Standards Track Stream: IETF Date: April 2015 Mailbox: xuxiaohu@huawei.com, nsheth@juniper.net, lucy.yong@huawei.com, rcallon@juniper.net, david.black@emc.com Pages: 19 Characters: 43208 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-in-udp-11.txt URL: https://www.rfc-editor.org/info/rfc7510 This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Apr 7 09:17:47 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8E7F01B379A; Tue, 7 Apr 2015 09:17:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713351B3768 for ; Tue, 7 Apr 2015 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AqwZ0wivt3ei for ; Tue, 7 Apr 2015 09:17:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7B71A897D for ; Tue, 7 Apr 2015 09:17:44 -0700 (PDT) Received: from alln-iport-2.cisco.com ([173.37.142.89]:27034) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfWC7-0002nr-FY for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Tue, 07 Apr 2015 09:17:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1012; q=dns/txt; s=iport; t=1428423465; x=1429633065; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DWVyhyXvob9Vg3wwGHYH85PO9K2kzncacQ+qcy3cDaI=; b=E2WPES8MZIkILl9pQGxYYw2Uvmc6IcCDLYm6zDomxl/yqxj5QF2UWagW ilqFOFc2yg5kd/ahG43R8JcypEku9PwR2aCgsbVddM/gg/UfSWOeYB1TB 7vn3lyMDbx6gQYdy8W/T51AfHiNXqRACDR2WEzkvVTxPe7Cwq7Jopiasx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BxBQAjAiRV/5RdJa1cgwhSXAXFRoV9AoEuTAEBAQEBAX6EHwEBBDo/EAIBCDYFCzIlAgQOBQmIIQ3MXQEBAQEBAQEBAQEBAQEBAQEBAQEBGIsrgT2DPweELQWQdIoHgR2DN4cKiH0ighAjgTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,538,1422921600"; d="scan'208";a="139038977" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 07 Apr 2015 16:17:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t37GHasO024391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 16:17:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 11:17:35 -0500 From: "George Swallow (swallow)" To: "drafts-approval@iana.org" Thread-Topic: [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) Thread-Index: AQHQblrexkyhSfFeI0Om81lN8J54uZ1B0MCA Date: Tue, 7 Apr 2015 16:17:34 +0000 Message-ID: References: <20150325222459.19546.84118.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.3.9.131030 x-originating-ip: [10.98.56.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 173.37.142.89 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: swallow@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150407161744.CD7B71A897D@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 09:17:44 -0700 (PDT) Resent-From: swallow@cisco.com Archived-At: Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 07 Apr 2015 16:17:46 -0000 Amanda - Please assign all four from the 0-16383 range. Thanks, George On 4/3/15 6:09 PM, "Amanda Baber via RT" wrote: >Dear Authors, > >We have two questions about the assignments requested by this document: > >1) Which range should be used for the TLV registrations? > >0-16383 Standards Action (This range is for mandatory TLVs or for >optional TLVs that require an error message if not recognized.) >16384-31743 Specification Required (Experimental RFC needed) >32768-49161 Standards Action (This range is for optional TLVs that can be >silently dropped if not recognized.) >49162-64511 Specification Required (Experimental RFC needed) > >2) Can you confirm that we should make the Message Types assignment from >the Standards Action range (0-191) , rather than the Specification >Required range (192-255)? > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > >thanks, > >Amanda Baber >IANA Request Specialist >ICANN > From nobody Tue Apr 7 12:05:31 2015 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 67E021B3ADD; Tue, 7 Apr 2015 12:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 JQNYb0dsOSeU; Tue, 7 Apr 2015 12:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4394A1B3AE2; Tue, 7 Apr 2015 12:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407190525.13619.35489.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 12:05:25 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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: Tue, 07 Apr 2015 19:05:30 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ From nobody Tue Apr 7 13:57:44 2015 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 276211B3C8C for ; Tue, 7 Apr 2015 13:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xfpGlVthGOOd for ; Tue, 7 Apr 2015 13:57:41 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AB31B3C84 for ; Tue, 7 Apr 2015 13:57:34 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t37KvWsF030891; Tue, 7 Apr 2015 21:57:32 +0100 Received: from 950129200 (089144209172.atnat0018.highway.a1.net [89.144.209.172]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t37KvUL1030877 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 21:57:31 +0100 From: "Adrian Farrel" To: "'Ross Callon'" , References: In-Reply-To: Date: Tue, 7 Apr 2015 21:57:34 +0100 Message-ID: <031c01d07175$79858450$6c908cf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031D_01D0717D.DB4C5D50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQPgMp+F85EfvPJp+pmFDDXz24DS/pkihRvw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21456.002 X-TM-AS-Result: No--21.070-10.0-31-10 X-imss-scan-details: No--21.070-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBeDtEKgt5AZnBRIrj8R47FQWEGv3gaUmeFiljlHjWyuR/X WBLkU7fuHbdHNxnhaCyBTvfwfVvQq49Tk4aumaegYD9XTRdaMO32acON9Q+rnjDJ9a3KikGoG9v VgL2UulsxJ6rawp6j1hnXKu8rGlRW9bPHgjnnomDDr0AjBcmfRjQAp53S718Hu6qThyrnanMGLH HeUCuj1wdX3Mah8hY2DOtleVVYquO3ih824MgIleLdprnA5EQROhJ9m53n4aBrMbakJN8OebEI+ kQaRrlmm1RTgzt+urUeStwhoe2wg3z5lEEBuvacCFaAixm5eU9A8JZETQujwtqCxkzSpW/XjBqN xmHpZGRYAxAMf3MvtKZta/jjPB3yiJx4642cvJb9KXlxhBAZb4N12XKYbuJLVxt8iPZNr2yALjq nIlNKdNXjKfop/WvT3wqC9Qsu3hf9+rKlRf1WaEtzk37SzX4NlPV6Vaqi4bDxxaAXDrCns4j7J3 jzONjdJa6rGJR4RfowuiDzT/FFiVHi+vC6FxL8BU4uU+5y12q2InV6AaP6lZUhT38IzfaR7KBBZ 2QBUyxPifNxprH2cuulrrvUsCg/hxaO3bw3PjDjrayXo0o3MIfsPVs/8Vw6EfKzCAntKpAGk2pT PAu+9//55Kkc+9/6c91xMYNqHkWBkjWfpo1TNt/wYmMFcJSIkBfdTMRAXUalF7MF/8ayEnii5kS OR4tGVCir/P/HlBCexSLBWoM4BFISCbZIzCBZIj0zFI5DoJJeCrB32KOS0H6cp973lFkJS/4a/2 DJkv/yzEFaT3dkzG5zP/FSQ4TNo27w8ee4WC+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMz84ZtJ974wh40drr0026U8m0SRjhNglonsbm191U2Sd+3BndfXUhXQ== Archived-At: Cc: mpls-chairs@tools.ietf.org, 'Loa Andersson' Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:57:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_031D_01D0717D.DB4C5D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have read the most recent revision of this document and have no objection to the WG requesting its publication. I have some comments that I think should be addressed before publication. Thanks, Adrian I don't believe this document updates 4379. It certainly does not explain how it updates 4379, and since 7110 did not update 4379, it seems unlikely that this document does. However, if the authors feel that it is intended to update 4379 (i.e., an implementation of 4379 will not be complete without also including the function of this document, for example, there is a problem in 4379 that this document fixes) then the document needs to explain what the update is and how 4379 implementations are affected. I *can* believe that this document updates 7110, but it needs to explain it and (presumably) observe that 7110 is not complete without this document. (Actually, section 3.1 has most of this text, but the Introduction should make the clear linkage to the "update".) --- Section 3.2 gives clear instructions and guidance on forming the Reply Mode Order TLV but not on what to do if a received TLV deviates from the MUST and MUST NOT instructions. Options might include ignoring errors, ignoring the TLV, ignoring the message. But presumably not sending an error response (because how would you know how to send it?) --- The last guidance in 3.2 is: 8. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply Mode Order TLV. "SHOULD NOT" means "you can do it if you have good reason." Please can you explain the good reason and how the receiver should interpret a "Do not reply" mode coming, say, third in a list of five modes. --- The security considerations are hard to believe! At the very least, 7110 makes some security observations that surely apply here. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: 20 March 2015 14:04 To: mpls@ietf.org Cc: Loa Andersson; mpls-chairs@tools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01. Because this WGLC will span the IETF in Dallas, it will be extended to three weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated that they are not aware of any IPR that relates to this draft. This working group last call ends Friday April 10, 2015. Ross for the MPLS WG chairs ------=_NextPart_000_031D_01D0717D.DB4C5D50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have read the most recent = revision of this document and have no objection to the WG requesting its = publication.

 

I have some comments that I = think should be addressed before publication.

 

Thanks,

Adrian

 

I don't believe this document = updates 4379. It certainly does not

explain how it updates 4379, = and since 7110 did not update 4379, it

seems unlikely that this = document does. However, if the authors feel that

it is intended to update 4379 = (i.e., an implementation of 4379 will not

be complete without also = including the function of this document, for

example, there is a problem in = 4379 that this document fixes) then the

document needs to explain what = the update is and how 4379 implementations

are = affected.

 

I *can* believe that this = document updates 7110, but it needs to explain

it and (presumably) observe = that 7110 is not complete without this

document. (Actually, section = 3.1 has most of this text, but the

Introduction should make the = clear linkage to the "update".)

 

---

 

Section 3.2 gives clear = instructions and guidance on forming the Reply

Mode Order TLV but not on what = to do if a received TLV deviates from the

MUST and MUST NOT = instructions. Options might include ignoring = errors,

ignoring the TLV, ignoring the = message. But presumably not sending an

error response (because how = would you know how to send it?)

 

---

       &nbs= p;            = ;            =             &= nbsp;        =

The last guidance in 3.2 = is:

 

   8.  Reply Mode value 1 (Do not = reply) SHOULD NOT be used in the Reply

       = Mode Order TLV.

 

"SHOULD NOT" means = "you can do it if you have good reason." Please = can

you explain the good reason = and how the receiver should interpret a

"Do not reply" mode = coming, say, third in a list of five modes.

 

---

 

The security considerations = are hard to believe!

At the very least, 7110 makes = some security observations that surely

apply = here.

 

From: mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of Ross = Callon
Sent: 20 March 2015 14:04
To: = mpls@ietf.org
Cc: Loa Andersson; = mpls-chairs@tools.ietf.org
Subject: [mpls] working group last = call for = draft-ietf-mpls-lsp-ping-reply-mode-simple-01

=

 

Working = Group,

 

This is to initiate a working group last = call on = draft-ietf-mpls-lsp-ping-reply-mode-simple-01.

Because this WGLC will span the IETF in = Dallas, it will be extended to three weeks. =

 

Please send your comments to the mpls wg = mailing list (mpls@ietf.org).

 

There are no IPR disclosures against this = document. All the authors have stated that they =

are not aware of any IPR that relates to = this draft.

 

This working group last call ends = Friday  April 10, 2015. 

 

Ross

for the MPLS WG = chairs

 

 

------=_NextPart_000_031D_01D0717D.DB4C5D50-- From nobody Tue Apr 7 13:57:56 2015 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 D34701B3C9C for ; Tue, 7 Apr 2015 13:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 V81leHoWH8EG for ; Tue, 7 Apr 2015 13:57:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C201A9107 for ; Tue, 7 Apr 2015 13:57:35 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t37KvX7d030903; Tue, 7 Apr 2015 21:57:33 +0100 Received: from 950129200 (089144209172.atnat0018.highway.a1.net [89.144.209.172]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t37KvUL2030877 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 21:57:32 +0100 From: "Adrian Farrel" To: "'Ross Callon'" , References: In-Reply-To: Date: Tue, 7 Apr 2015 21:57:34 +0100 Message-ID: <032b01d07175$7a6535f0$6f2fa1d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032C_01D0717D.DC2C0EF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugHj/uh8nOleDpA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21456.002 X-TM-AS-Result: No--16.397-10.0-31-10 X-imss-scan-details: No--16.397-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBT7QvMcPWmSOGonqgs5zxBh8Ytn75ClDO638ZUY6gSd3md +25VkQszM6AYDRVyusurrlYLeXheSBmN40CNJF1HVoDlQpf4TdUpWss5kPUFdMPeHaeZngFBH9d YEuRTt+6T9AFIos/69i8qyDve6XUAjAJ35L3MgLZNCH0Dib0S0SwJzaIVMjGtB1j59po+6EQVjA eaOyL90setslknmQ/gjVjvwC8i3K9ANJabxsmbMkcVayrW/N3UGbJMFqqIm9xF+YXPIqAdvi1lx AVVUrr2Xxl++CV5LZdjXzx1pPoeS7jj3IxuLhij4t2mucDkRBELy8o3bV9yTfDtk4ziLyBO0UFH zpW9t1kdn874qANH/v2005/gaC3xiVm/X1CarJC8coKUcaOOvdZKsq3DGpalzO86RLKahv/KmLA /VYsJLwrjHjSPKL+XSaVfaxxV94/trubt8TkL4cG0UNgaZpYqtF9GMNu1bqLkOOZ1bT6psa7BVP FMOQQusrZgdv+SJ0/88SAvS2rKrnRue7aQeqLEsyw+ZJnFumQTskidPjB12hON+Q7elv5YPSawi BLK6fcf9nvUckM1oVpzKEH0vVqvEnerDpp3+WMAGGKG8CG8Akh41hM/w6ZM+TdKNkxxkWRSUGH6 RuK0zz8NRz8HpCmSZEZKdSp4I705BGX7329oyQwfhKwa9GwDWq9ln3+CkiFnnK6mXN72mznuQWM 5MjklgExzV+J9XRhiXQjTxUn166dwsJe6fN2LQesjq8XPMbuQF91MxEBdRrXvDHySC+eUlSBIvH 74wfJrar1QOTCmjzl5+IQAcYVk8lEDYmoBkrOeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMiSr5ISSsIxwf+oJMy8WR2OsGa3FDOhjdXRVoKyP+YKV+3BndfXUhXQ== Archived-At: Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:57:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032C_01D0717D.DC2C0EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ross, Apologies for a late review from me, as well (my excuses is that as AD I didn't participate in WG last calls, and since Dallas I've been sick). I have no objection to this document and it addresses a specific requirement to provide a mechanism to enable MPLS OAM features that is independent from the control plane, but that nevertheless does not require the MCN either. I wonder whether the various bit flag arrays (such as Figure 1/Table 1, Figure 2, Figure 7) should be managed by IANA? In any case, it would be helpful to use some more consistent language to say that unassigned bits MUST be transmitted as zero and ignored on receipt - currently this is deduced from the figures through a variety of language. My final thought is to ask why this document doesn't share data structures with draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. Of course, it doesn't need to, but it is probably turning on and off exactly the same OAM function, so it might save some text to use the same structures. Cheers, Adrian From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: 06 April 2015 01:10 To: mpls@ietf.org Cc: Ross Callon; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf This working group last call has now ended. There was one public response (to the MPLS working group) in support. I also got private responses of support from two of the authors. Otherwise there were no responses (neither in favor nor opposed). This is not sufficient to constitute "rough consensus". As such the working group last call has failed. My inclination is to wait for the July IETF (in Prague), and give the authors an opportunity to present and solicit additional support. Depending upon the response there, we may then repeat the WGLC. Thanks, Ross (as WG co-chair) From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, March 10, 2015 4:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09. Because this WGLC will span the IETF in Dallas, it will be extended to just over three weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have stated that they are not aware of any IPR that relates to this draft (two of the responses were private to the WG chairs). This working group last call ends Thursday April 2, 2015. Ross for the MPLS WG chairs ------=_NextPart_000_032C_01D0717D.DC2C0EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ross,

 

Apologies for a late review = from me, as well (my excuses is that as AD

I didn't participate in WG = last calls, and since Dallas I've been sick).

 

I have no objection to this = document and it addresses a specific

requirement to provide a = mechanism to enable MPLS OAM features that is

independent from the control = plane, but that nevertheless does not

require the MCN = either.

 

I wonder whether the various = bit flag arrays (such as Figure 1/Table 1,

Figure 2, Figure 7) should be = managed by IANA? In any case, it would be

helpful to use some more = consistent language to say that unassigned bits

MUST be transmitted as zero = and ignored on receipt - currently this is

deduced from the figures = through a variety of language.

 

My final thought is to ask why = this document doesn't share data

structures with = draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. Of course, = it

doesn't need to, but it is = probably turning on and off exactly the same

OAM function, so it might save = some text to use the same structures.

 

Cheers,

Adrian

 

From: mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of Ross = Callon
Sent: 06 April 2015 01:10
To: = mpls@ietf.org
Cc: Ross Callon; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: Re: [mpls] working group last call for = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

 

This working group last call has now ended. =

 

There was one public response (to the MPLS = working group) in support. I also got private responses of support from = two of the authors. Otherwise there were no responses (neither in favor = nor opposed). This is not sufficient to constitute “rough = consensus”. As such the working group last call has = failed.

 

My inclination is to wait for the July IETF = (in Prague), and give the authors an opportunity to present and solicit = additional support. Depending upon the response there, we may then = repeat the WGLC.

 

Thanks, Ross

(as WG co-chair)

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of = Ross Callon
Sent: Tuesday, March 10, 2015 4:46 = PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: [mpls] working group last call for = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

 

Working Group,

 

This is to initiate a working group last call on = draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09. =

Because this WGLC will span the IETF in Dallas, it will be = extended to just over three weeks.

 

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

 

There are no IPR disclosures against this document. All the = authors have stated that they

are not aware of any IPR that relates to this draft (two of = the responses were private to

the WG chairs).

 

This working group last call ends Thursday  April 2, = 2015. 

 

Ross

for the MPLS WG chairs

 

 

------=_NextPart_000_032C_01D0717D.DC2C0EF0-- From nobody Tue Apr 7 20:01:25 2015 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 ADDCF1B2C15; Tue, 7 Apr 2015 20:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 j7LhjUvxnwpH; Tue, 7 Apr 2015 20:01:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DB11B2C14; Tue, 7 Apr 2015 20:01:20 -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 BRD56760; Wed, 08 Apr 2015 03:01:18 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Apr 2015 04:01:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 8 Apr 2015 11:01:09 +0800 From: Xuxiaohu To: Xuxiaohu , "'Erik Nordmark'" , "nvo3@ietf.org" Thread-Topic: Re: [nvo3] Encapsulation considerations Thread-Index: AdBxodagEeaWbZwEQCSsmj8ZrqiVwQAAXeVA Date: Wed, 8 Apr 2015 03:01:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323576@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [nvo3] Encapsulation considerations 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, 08 Apr 2015 03:01:22 -0000 T2YgY291cnNlLCBpZiBpdCdzIGFsbG93ZWQgdG8gbWFrZSBhIG1pbm9yIGNoYW5nZSB0byB0aGUg TVBMUyBhcmNoaXRlY3R1cmUgKGkuZS4sIGFkZGluZyBhIHByb3RvY29sIGZpZWxkIGltbWVkaWF0 ZWx5IGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIHRvIGluZGljYXRlIHRoZSBN UExTIHBheWxvYWQgdHlwZSApLCB0aGUgZmlyc3QgbmliYmxlIGlzc3VlIGltcG9zZWQgb24gdGhv c2UgbmV3IGVuY2Fwc3VsYXRpb25zIHdoaWNoIG1heSBiZSB0cmFuc3BvcnRlZCBvdmVyIE1QTFMg d291bGQgZGlzYXBwZWFyIGZvcmV2ZXIuIEZ1cnRoZXJtb3JlLCB0aGUgbmVjZXNzaXR5IG9mIGFs bG9jYXRpbmcgbG9jYWwgbGFiZWxzIGp1c3QgZm9yIHRoZSBwdXJwb3NlIG9mIGluZGljYXRpbmcg dGhvc2UgbmV3IGVuY2Fwc3VsYXRpb25zIChpbWFnaW5lIGhvdyB0byB0cmFuc3BvcnQgTlNIIG92 ZXIgTVBMUykgd291bGQgZGlzYXBwZWFyIGZvcmV2ZXIgYXMgd2VsbC4NCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFv aHUNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAxNSAxMDoxNSBBTQ0KPiBUbzogJ0Vy aWsgTm9yZG1hcmsnOyBudm8zQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbnZvM10gRW5jYXBz dWxhdGlvbiBjb25zaWRlcmF0aW9ucw0KPiANCj4gSGkgRXJpaywNCj4gDQo+IEFzIGl0IGhhcyBz YWlkIGluIHRoZSBkcmFmdCA6ICIuLi4gV2UgbGF0ZXIgZXhwYW5kZWQgdGhlIHNjb3BlIHNvbWV3 aGF0IHRvDQo+IGNvbnNpZGVyIGhvdyB0aGUgZW5jYXBzdWxhdGlvbnMgd291bGQgcGxheSB3aXRo IE1QTFMgInRyYW5zcG9ydCIsIHdoaWNoIGlzDQo+IGltcG9ydGFudCBiZWNhdXNlIFNGQyBhbmQg QklFUiBzZWVtIHRvIHRhcmdldCBiZWluZyBkZXBlbmRlbnQgb2YgdGhlDQo+IHVuZGVybHlpbmcg InRyYW5zcG9ydCIuLi4iLCBpdCB3b3VsZCBiZSBuZWNlc3NhcnkgdG8gY29uc2lkZXIgdGhlIGZp cnN0IG5pYmJsZQ0KPiBpc3N1ZSBmb3IgdGhvc2UgZW5jYXBzdWxhdGlvbnMgd2hpY2ggbWF5IGJl IHRyYW5zcG9ydGVkIG92ZXIgTVBMUy4gTW9yZQ0KPiBzcGVjaWZpY2FsbHksIGZvciB0aG9zZSBl bmNhcHN1bGF0aW9ucyB3aGljaCBtYXkgYmUgZGlyZWN0bHkgZW5jYXBzdWxhdGVkIGZ1cnRoZXIN Cj4gd2l0aCBhbiBNUExTIGhlYWRlciwgdGhleSBtdXN0IG5vdCBzdGFydCB3aXRoIHRoZSB2YWx1 ZSA0IChJUHY0KSBvciB0aGUgdmFsdWUgNg0KPiAoSVB2NikgaW4gdGhlIGZpcnN0IG5pYmJsZS4g T3RoZXJ3aXNlLCB0aGV5IHdvdWxkIGJlIG1pc3Rha2VubHkgaW50ZXJwcmV0ZWQgYXMgSVANCj4g cGF5bG9hZHMgYnkgdHJhbnNpdCBMU1JzIGFuZCB0aGVyZWZvcmUgYmUgc3ViamVjdGVkIHRvIEVD TVAgYW5kIHBvdGVudGlhbA0KPiBwYWNrZXQgbWlzb3JkZXJpbmcuDQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IEVyaWsgTm9yZG1hcmsgW21haWx0bzpub3JkbWFya0Bzb25pYy5uZXRdDQo+ID4gU2VudDog MjAxNcTqM9TCMjbI1SA1OjAxDQo+ID4gVG86IG52bzNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBb bnZvM10gRW5jYXBzdWxhdGlvbiBjb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4NCj4gPiBJIHByZXNl bnRlZCBwYXJ0IG9mIHRoaXMgYXQgdGhlIG1vc3QgcmVjZW50IE5WTzMgaW50ZXJpbSBtZWV0aW5n LlRoZQ0KPiA+IGZ1bGwNCj4gMTINCj4gPiBhcmVhcyBvZiBjb25zaWRlcmF0aW9ucyB3aGVyZSBw cmVzZW50ZWQgYXQgUlRHV0cgZWFybGllciB0aGlzIHdlZWsuDQo+ID4gICBUaGUgZHJhZnQgaXMN Cj4gPiAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ydGctZHQtZW5j YXAvDQo+ID4gICBhbmQgdGhlIHNsaWRlcyBhcmUgYXQNCj4gPiAgICBodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItcnRnd2ctOC5wZGYNCj4gPg0KPiA+ IFRoZXJlIGlzIHByb2JhYmx5IGFkZGl0aW9uYWwgdGhpbmdzIGluIHRoZXJlIHRvIGNvbnNpZGVy IGZvciBOVk8zLCBhbmQNCj4gYWR2aWNlDQo+ID4gdGhhdCBjYW4gYmUgcmV1c2VkIHRvIG1ha2Ug aXQgZWFzaWVyIHRvIG1vdmUgTlZPMyBmb3J3YXJkLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiAg ICAgRXJpaw0KPiA+DQo+ID4NCj4gPg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From nobody Wed Apr 8 05:32:20 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 06CE11B30CC; Wed, 8 Apr 2015 05:32:19 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9801B30CA for ; Wed, 8 Apr 2015 05:32:18 -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 CyifmM-6zaPr for ; Wed, 8 Apr 2015 05:32:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C701B30CB for ; Wed, 8 Apr 2015 05:32:16 -0700 (PDT) Received: from pipi.pi.nu ([83.168.239.141]:41228) by zinfandel.tools.ietf.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yfp9T-0001FU-51 for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Wed, 08 Apr 2015 05:32:16 -0700 Received: from [172.20.10.2] (2.64.18.113.mobile.tre.se [2.64.18.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E5D681801294; Wed, 8 Apr 2015 14:32:10 +0200 (CEST) Message-ID: <55251FCA.90506@pi.nu> Date: Wed, 08 Apr 2015 14:32:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "George Swallow (swallow)" , "drafts-approval@iana.org" References: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 83.168.239.141 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: loa@pi.nu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150408123216.E6C701B30CB@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 05:32:16 -0700 (PDT) Resent-From: loa@pi.nu Archived-At: Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 08 Apr 2015 12:32:19 -0000 George, That is fine for the TLVs, what about the message types? /Loa On 2015-04-07 18:17, George Swallow (swallow) wrote: > Amanda - > > Please assign all four from the 0-16383 range. > > Thanks, > > George > > On 4/3/15 6:09 PM, "Amanda Baber via RT" wrote: > >> Dear Authors, >> >> We have two questions about the assignments requested by this document: >> >> 1) Which range should be used for the TLV registrations? >> >> 0-16383 Standards Action (This range is for mandatory TLVs or for >> optional TLVs that require an error message if not recognized.) >> 16384-31743 Specification Required (Experimental RFC needed) >> 32768-49161 Standards Action (This range is for optional TLVs that can be >> silently dropped if not recognized.) >> 49162-64511 Specification Required (Experimental RFC needed) >> >> 2) Can you confirm that we should make the Message Types assignment from >> the Standards Action range (0-191) , rather than the Specification >> Required range (192-255)? >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> thanks, >> >> Amanda Baber >> IANA Request Specialist >> ICANN >> > > _______________________________________________ > 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 Wed Apr 8 07:31:24 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 85B451B313D; Wed, 8 Apr 2015 07:31:22 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663F71B313B for ; Wed, 8 Apr 2015 07:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hqw--PDuW0yq for ; Wed, 8 Apr 2015 07:31:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0461B3133 for ; Wed, 8 Apr 2015 07:31:20 -0700 (PDT) Received: from alln-iport-3.cisco.com ([173.37.142.90]:17167) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yfr0h-0006rc-6S for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Wed, 08 Apr 2015 07:31:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1740; q=dns/txt; s=iport; t=1428503479; x=1429713079; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N0FaHlkzUEvB3ITXoH3mgMwllSG7QlssheV7YiJoUBo=; b=PSPMUlcJ1f6MaChNauv2zO0lqhyLcWo/FKWhZCnQtu1k/3cF2vuJuT/G swN0qkz0DSXNm2GZYWgf9lRKdO82AwNuyXwIg/aw9g/0Hp1ksLRt5MG+u NXnrdpAaanEpYfL/uYfMb1/jWuCDl5zy6OpYdkHmrO4AVqKaAAlSZiHpr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBAABOyVV/51dJa1cgwhSXAXDZwmBSAqFfQKBKDgUAQEBAQEBAX2EIAEBBAEBATcxAwsOAgIBCBgeBQsbDAslAgQBDQUJiCENzB4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIsngT2CXBEBUQeELQWQdIoHgR2DN4cKiH0ighAjgTxvgQs5fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,544,1422921600"; d="scan'208";a="139320052" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 08 Apr 2015 14:31:12 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t38EVCSc028287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 14:31:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 8 Apr 2015 09:31:12 -0500 From: "George Swallow (swallow)" To: Loa Andersson , "drafts-approval@iana.org" Thread-Topic: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) Thread-Index: AQHQblrexkyhSfFeI0Om81lN8J54uZ1B0MCAgAGWbAD//94tAA== Date: Wed, 8 Apr 2015 14:31:12 +0000 Message-ID: References: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> <55251FCA.90506@pi.nu> In-Reply-To: <55251FCA.90506@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C7D51CB5CA3424EB9BD8062BD67049C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 173.37.142.90 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: swallow@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150408143120.CA0461B3133@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 07:31:20 -0700 (PDT) Resent-From: swallow@cisco.com Archived-At: Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 08 Apr 2015 14:31:22 -0000 The message type should be assigned from "standards action". George On 4/8/15 8:32 AM, "Loa Andersson" wrote: >George, > >That is fine for the TLVs, what about the message types? > >/Loa > >On 2015-04-07 18:17, George Swallow (swallow) wrote: >> Amanda - >> >> Please assign all four from the 0-16383 range. >> >> Thanks, >> >> George >> >> On 4/3/15 6:09 PM, "Amanda Baber via RT" >>wrote: >> >>> Dear Authors, >>> >>> We have two questions about the assignments requested by this document: >>> >>> 1) Which range should be used for the TLV registrations? >>> >>> 0-16383 Standards Action (This range is for mandatory TLVs or for >>> optional TLVs that require an error message if not recognized.) >>> 16384-31743 Specification Required (Experimental RFC needed) >>> 32768-49161 Standards Action (This range is for optional TLVs that can >>>be >>> silently dropped if not recognized.) >>> 49162-64511 Specification Required (Experimental RFC needed) >>> >>> 2) Can you confirm that we should make the Message Types assignment >>>from >>> the Standards Action range (0-191) , rather than the Specification >>> Required range (192-255)? >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> thanks, >>> >>> Amanda Baber >>> IANA Request Specialist >>> ICANN >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > >--=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 Apr 8 09:03:04 2015 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 2F8671B3339 for ; Wed, 8 Apr 2015 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 t40YKqIzByN9 for ; Wed, 8 Apr 2015 09:02:55 -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 ECA6C1B330C for ; Wed, 8 Apr 2015 09:00:48 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-9e-5524fa2d3f4a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 71.58.12456.D2AF4255; Wed, 8 Apr 2015 11:51:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Wed, 8 Apr 2015 12:00:45 -0400 From: Gregory Mirsky To: Nobo Akiya , 'Ross Callon' , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Thread-Index: AQHQb/4e6lxvQUESVUS7PAp42TBBtZ0/b/8AgAPZikA= Date: Wed, 8 Apr 2015 16:00:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9435F8@eusaamb103.ericsson.se> References: <005801d07006$789a7ed0$69cf7c70$@gmail.com> In-Reply-To: <005801d07006$789a7ed0$69cf7c70$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPt67uL5VQg+O3zS0mnHrAZPH90hIW i1tLV7JaPDn3jsXi74orLA6sHjtn3WX3WLLkJ5PH9aar7B5fLn9mC2CJ4rJJSc3JLEst0rdL 4MpY8GwjS8E/3Yr/3TeYGxivqHQxcnJICJhIvHu3gA3CFpO4cG89kM3FISRwlFHi1qlWVghn GaPE1f0TmUCq2ASMJF5s7GEHsUUECiVm9U5jAiliFtjBKHH78GxWkISwQLTE1ukXmLsYOYCK YiTmtRhC1FtJzJ+zjRHEZhFQkXjU/4wNpIRXwFdi8g05iF1PgcasugV2EaeAhUTrpz/MIDYj 0HXfT60Bu4FZQFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0kMWnpOVaIej2JG1OnsEHY2hLL Fr4Gq+cVEJQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBEbWMQk23R2M e15aHmIU4GBU4uFNCFYJFWJNLCuuzD3EKM3BoiTOu+jBwRAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjBOT5x3/pxdwWCuvzs/gwfTVLNwWbke0TnhtmLG1UCjfdpP/n/8SVzZf4bES0rH6 tbo2Us/E53L1notfSube4ZkdwL4t8JDCVyP55BC7yLPdXn7Ve9n4zogyHX2u0mf2z0Tz3bZg F2nz7CvH6lOX/H1Qzex8/uXk8Llq1mwMti4Jir6VRQaFSizFGYmGWsxFxYkAqemLAo0CAAA= Archived-At: Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 08 Apr 2015 16:02:57 -0000 Hi Nobo, greatly appreciate your review and thoughtful comments. I'll send another n= ote to propose resolutions by next week (digging out of two-weeks of e-mail= ). Kind regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya Sent: Sunday, April 05, 2015 6:10 PM To: 'Ross Callon'; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@t= ools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mp= ls-tp-oam-conf Hi Ross, My apologies for being late. I skipped over all the PM details, but read rest of the document. This docu= ment defines an important functionality for TP OAM, and I do support its pr= ogress. I did spot few things which should be addressed in the document (especially #1 and #4). 1. Section 2.2 - BFD Configuration sub-TLV, which MUST be included if either the CC, the CV or both OAM Function flags being set in the OAM Function Flags Sub-TLV [RFC7260]. I'm guessing that above is a copy & paste error/leftover. MPLS OAM Function= TLV is defined in the section 2.2 of the draft-ietf-mpls-lsp-ping-mpls-tp-= oam-conf document, and the TLV has MPLS OAM TLV Flags defined. We would wan= t to refer to the MPLS OAM TLV Flags in the MPLS OAM Function TLV instead o= f OAM Function flags in the OAM Function Flags Sub-TLV defined in RFC7260. And if above is true (and the text is corrected), then the reference to RFC7260 can also be removed (as it is not mentioned anywhere else in this d= ocument). 2. Section 2.2 This sub-TLV MUST carry a "BFD Local Discriminator sub-TLV" and a "Timer Negotiation Parameters sub-TLV" if the N flag is cleared. The "Source MEP-ID sub-TLV" MUST also be included. If the I flag is set, the "BFD Authentication sub-TLV" MAY be included. I think above should be removed, as it is a subset (and a bit confusion subset) of what is better described at the end of Section 2.2.1 anyways. 3. Section 2.2.1 In this case an updated Negotiation Timer Parameters sub-TLV, containing values supported by the egress node, is returned to the ingress. Above is probably a good place to reference RFC7419 to prevent problematic = interop of multiple devices. 4. Section 2.2.4 There needs to be some synchronicity between AuthType/AuthKeyID to specifie= d in "this" MPLS echo request message and AuthType/AuthKeyID being used by = BFD control packets. For example: - If BFD control packets using "new" auth is received by the egress LSR bef= ore MPLS echo request with new "auth" is received, all BFD control packets = using "new" auth will be dropped. - To take that a step further, if BFD control packets using "new" auth is r= eceived by the egress LSR before "this" MPLS echo request is received by th= e egress LSR and corresponding BFD session is updated to point to the "new"= auth , all BFD control packets using "new" auth will be dropped. - If BFD control packets using "new" auth is only sent X time after sending= the MPLS echo request with new "auth", then it is not guaranteed that the = egress LSR will still be accepting BFD control packets with "old" auth for = X amount of time. - And of course there's the error case of the egress LSR not being able to = support the specified the "new" auth specified in received MPLS echo reques= t, but the ingress LSR starts using the "new" auth before it receives back = NOSUP from the egress LSR via MPLS echo reply. I suspect if sufficient details are not defined, we would likely run into s= ome inter-op issues with this aspect. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: April-05-15 5:10 PM > To: mpls@ietf.org > Cc: Ross Callon; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf@tools.ietf.org > Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf >=20 > This working group last call has now ended. >=20 > There was one public response (to the MPLS working group) in support.=20 > I also > got private responses of support from two of the authors. Otherwise=20 > there were > no responses (neither in favor nor opposed). This is not sufficient to constitute > "rough consensus". As such the working group last call has failed. >=20 > My inclination is to wait for the July IETF (in Prague), and give the authors an > opportunity to present and solicit additional support. Depending upon=20 > the response there, we may then repeat the WGLC. >=20 > Thanks, Ross > (as WG co-chair) >=20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Tuesday, March 10, 2015 4:46 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf@tools.ietf.org > Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf >=20 > Working Group, >=20 > This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf-09. > Because this WGLC will span the IETF in Dallas, it will be extended to just over > three weeks. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There are no IPR disclosures against this document. All the authors=20 > have stated > that they > are not aware of any IPR that relates to this draft (two of the=20 > responses were > private to > the WG chairs). >=20 > This working group last call ends Thursday=A0 April 2, 2015. >=20 > Ross > for the MPLS WG chairs >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Apr 8 09:09:14 2015 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 E41481B3354 for ; Wed, 8 Apr 2015 09:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8ttkIGhF2OE8 for ; Wed, 8 Apr 2015 09:09:09 -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 D6CF81B3342 for ; Wed, 8 Apr 2015 09:09:08 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-4c-5524eff90489 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FF.6A.17241.9FFE4255; Wed, 8 Apr 2015 11:08:10 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 8 Apr 2015 12:09:02 -0400 From: Gregory Mirsky To: "adrian@olddog.co.uk" , 'Ross Callon' , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Thread-Index: AQHQb/4e6lxvQUESVUS7PAp42TBBtZ1CTgIAgAD8mmA= Date: Wed, 8 Apr 2015 16:09:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B94362A@eusaamb103.ericsson.se> References: <032b01d07175$7a6535f0$6f2fa1d0$@olddog.co.uk> In-Reply-To: <032b01d07175$7a6535f0$6f2fa1d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B94362Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPiO6v9yqhBt/+slr86LnBbDHh1AMm i++XlrBY3Fq6ktXi74orLA6sHkuW/GTyuN50ld1jxeaVjB5fLn9mC2CJ4rJJSc3JLEst0rdL 4Mro2PiJpaB7E2PF7E/bWRsYL89n7GLk5JAQMJFof3GeHcIWk7hwbz1bFyMXh5DAUUaJ1Zen M0I4yxglLvdvZgGpYhMwknixsQesQ0SgXOLF5nXMIEXMAjsYJW4fns0KkhAWiJbYOv0CUIID qChGYl6LIUS9lcSsH21sIDaLgIrE9LbjYDavgK/E22mL2CGWvQCas/Qk2HmcAtYS147NALMZ gc77fmoNE4jNLCAucevJfCaIswUkluw5zwxhi0q8fPyPFcJWkpi09BwryA3MAvkSO7YmQuwS lDg58wnLBEbRWUgmzUKomoWkCqJER2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqW m25kuIkRGIvHJNgcdzAu+GR5iFGAg1GJhzchWCVUiDWxrLgy9xCjNAeLkjhv2ZWDIUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYA07U107unVy7XUqAU2HV1NSnvvMztvf0iVztufS552Xd lzV//36yrHseenTujA0G9a+fHJVdfCJ28f2He/uYvGSfC9q6fLNmsru0Ttbr34wckWtLOZ6t nKCYddNzd3h78CaBn886PrI/X7kwdS/3Zo+IT3N/XzutPif2S9bSVdqRE8wXczxyeq/EUpyR aKjFXFScCABMaviepgIAAA== Archived-At: Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 08 Apr 2015 16:09:13 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B94362Aeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, hope everything is well and getting better. Many thanks for taking time to review this document and share your comments= . I'll need more time to think how to address them and will send another ma= il perhaps in a week. In the meantime, I've a question. You've suggested: "... unassigned bits MUST be transmitted as zero and ignored on receipt ...= " in another discussion, it was pointed to me that "transmitted as zero and i= gnored on receipt" for reserved fields or bits/flags is falling out of favo= r as accepted form of expression. Would appreciate suggestions on how to im= prove it. Regards, Greg From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, April 07, 2015 1:58 PM To: 'Ross Callon'; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@t= ools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mp= ls-tp-oam-conf Hi Ross, Apologies for a late review from me, as well (my excuses is that as AD I didn't participate in WG last calls, and since Dallas I've been sick). I have no objection to this document and it addresses a specific requirement to provide a mechanism to enable MPLS OAM features that is independent from the control plane, but that nevertheless does not require the MCN either. I wonder whether the various bit flag arrays (such as Figure 1/Table 1, Figure 2, Figure 7) should be managed by IANA? In any case, it would be helpful to use some more consistent language to say that unassigned bits MUST be transmitted as zero and ignored on receipt - currently this is deduced from the figures through a variety of language. My final thought is to ask why this document doesn't share data structures with draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. Of course, it doesn't need to, but it is probably turning on and off exactly the same OAM function, so it might save some text to use the same structures. Cheers, Adrian From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: 06 April 2015 01:10 To: mpls@ietf.org Cc: Ross Callon; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mp= ls-tp-oam-conf This working group last call has now ended. There was one public response (to the MPLS working group) in support. I als= o got private responses of support from two of the authors. Otherwise there= were no responses (neither in favor nor opposed). This is not sufficient t= o constitute "rough consensus". As such the working group last call has fai= led. My inclination is to wait for the July IETF (in Prague), and give the autho= rs an opportunity to present and solicit additional support. Depending upon= the response there, we may then repeat the WGLC. Thanks, Ross (as WG co-chair) From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, March 10, 2015 4:46 PM To: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ie= tf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-t= p-oam-conf Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-m= pls-tp-oam-conf-09. Because this WGLC will span the IETF in Dallas, it will be extended to just= over three weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have st= ated that they are not aware of any IPR that relates to this draft (two of the responses w= ere private to the WG chairs). This working group last call ends Thursday April 2, 2015. Ross for the MPLS WG chairs --_000_7347100B5761DC41A166AC17F22DF1121B94362Aeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian,

hope everything is well a= nd getting better.

Many thanks for taking ti= me to review this document and share your comments. I’ll need more ti= me to think how to address them and will send another mail perhaps in a week. In the meantime, I’ve a question. You’ve suggested:=

in another discussion, it= was pointed to me that “transmitted as zero and ignored on receipt&#= 8221; for reserved fields or bits/flags is falling out of favor as accepted form of expression. Would appreciate suggestions on how to improve it.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, April 07, 2015 1:58 PM
To: 'Ross Callon'; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam= -conf@tools.ietf.org
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-= ping-mpls-tp-oam-conf

 

Hi Ross,

 = ;

Apologies = for a late review from me, as well (my excuses is that as AD

I didn't p= articipate in WG last calls, and since Dallas I've been sick).

 = ;

I have no = objection to this document and it addresses a specific

requiremen= t to provide a mechanism to enable MPLS OAM features that is

independen= t from the control plane, but that nevertheless does not<= /p>

require th= e MCN either.

 = ;

I wonder w= hether the various bit flag arrays (such as Figure 1/Table 1,

Figure 2, = Figure 7) should be managed by IANA? In any case, it would be

helpful to= use some more consistent language to say that unassigned bits

MUST be tr= ansmitted as zero and ignored on receipt - currently this is

deduced fr= om the figures through a variety of language.

 = ;

My final t= hought is to ask why this document doesn't share data

structures= with draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. Of course, it

doesn't ne= ed to, but it is probably turning on and off exactly the same

OAM functi= on, so it might save some text to use the same structures.

 = ;

Cheers,

Adrian

 = ;

From: mpls [mailto:mpls-bounces@ietf= .org] On Behalf Of Ross Callon
Sent: 06 April 2015 01:10
To: mpls@ietf.org
Cc: Ross Callon; mpls-= chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-= ping-mpls-tp-oam-conf

 

This working group last c= all has now ended.

 <= /p>

There was one public resp= onse (to the MPLS working group) in support. I also got private responses o= f support from two of the authors. Otherwise there were no responses (neither in favor nor opposed). This is not sufficient to con= stitute “rough consensus”. As such the working group last call = has failed.

 <= /p>

My inclination is to wait= for the July IETF (in Prague), and give the authors an opportunity to pres= ent and solicit additional support. Depending upon the response there, we may then repeat the WGLC.

 <= /p>

Thanks, Ross

(as WG co-chair)

 <= /p>

From: mpls [mailto:mpls-bounces@ietf= .org] On Behalf Of Ross Callon
Sent: Tuesday, March 10, 2015 4:46 PM
To: mpls@ietf.org
Cc: mpls-chairs@tools.= ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -mpls-tp-oam-conf

 

Working Group,

 

This is to initiate a working group las= t call on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-09.

Because this WGLC will span the IETF in= Dallas, it will be extended to just over three weeks.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have stated that they

are not aware of any IPR that relates t= o this draft (two of the responses were private to

the WG chairs).

 

This working group last call ends Thurs= day  April 2, 2015. 

 

Ross

for the MPLS WG chairs

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B94362Aeusaamb103erics_-- From nobody Wed Apr 8 11:56:57 2015 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 964D11B350A for ; Wed, 8 Apr 2015 11:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 gMv3pjzd9_GD for ; Wed, 8 Apr 2015 11:56:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6129D1B3506 for ; Wed, 8 Apr 2015 11:56:52 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t38Iumq6016568; Wed, 8 Apr 2015 19:56:48 +0100 Received: from 950129200 (089144230255.atnat0039.highway.a1.net [89.144.230.255]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t38Iuk2C016549 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 19:56:47 +0100 From: "Adrian Farrel" To: "'Gregory Mirsky'" , "'Ross Callon'" , References: <032b01d07175$7a6535f0$6f2fa1d0$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF1121B94362A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94362A@eusaamb103.ericsson.se> Date: Wed, 8 Apr 2015 19:56:50 +0100 Message-ID: <046401d0722d$c6e67070$54b35150$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugHj/uh8Ad/4fEgBVqFPUZzRHsEw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21458.002 X-TM-AS-Result: No--10.363-10.0-31-10 X-imss-scan-details: No--10.363-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTotqx4vLVZ3FvHkpkyUphL9oprEeoZHCQJh2lxkfcGsFBr7 FyaVZKQrm0VAp0zzAIVjbqBQKsxALxerDOEQhKOMnbUZkYTzXIYkKs3LoBtQlRxUkJPe1WBqUpN 5b4Xd/F24PhLcqHA2WoR6ktsj4/uoxGtpMtFxybKNZ7kc4Uq+4+iY+s2L3xQEZ5yuplze9puuz4 mtMHP79GlLQc62MC4SugilbkAuMWXvkJu04PYxt/OHbIp2eXtYpwnFZnn+VHw3Z3efQH+wj53bq Ww72JHkD8fxgfysaI6Rk6XtYogiarQ/aqQZTRfKC24oEZ6SpSkj80Za3RRg8Ix/1d2MX54y1ZrG b+KZKdNf7vpwhSLPpuZzPO+SIFIBrW7Lspl6Tvo= Archived-At: Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:56:55 -0000 Hi Greg, [snip] > You've suggested: > ". unassigned bits MUST be transmitted as zero and ignored on receipt ." > in another discussion, it was pointed to me that "transmitted as zero and > ignored on receipt" for reserved fields or bits/flags is falling out of favor as > accepted form of expression. Would appreciate suggestions on how to > improve it. I guess I'm old so stuff I like falls out of favor all the time, but it doesn't change my opinion :-) Firstly, there is a difference between truly reserved fields, and fields that are currently unassigned but which you expect to possibly assign one day. In the former case, no-one really cares how the fields are set and, of course (?) no-one will look at such fields. In the latter case you need to be forward compatible. That means that an implementation that can process some new meaning of the previously unused field must receive a value form a legacy implementation that it will not misinterpret. The easiest way to handle this is to require legacy implementations to transmit zero - then the new meaning of the field can include "zero means not supported". Similarly, a legacy implementation that receives a non-setting (from a new implementation) needs to not barf. The easiest way is to simply ignore the fields that are believed to be unused. None of this means that a legacy implementation should police the setting of zero in an unused field it received. Indeed, although it could police the sender's adherence to "MUST be zero" is should not do so because it is not supposed to look at the field at all. Maybe you need to be asking the person who suggested that the concept is falling out of favor. They might have a suggestion. A From Spence.Jackson@pmcs.com Wed Apr 8 13:47:22 2015 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 ECEFB1B364B for ; Wed, 8 Apr 2015 13:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 SiNLdOcPdmQi for ; Wed, 8 Apr 2015 13:47:19 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B131B3648 for ; Wed, 8 Apr 2015 13:47:19 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id D78FC1070CA4 for ; Wed, 8 Apr 2015 13:47:18 -0700 (PDT) Received: from smtp.pmcs.com (bby1cas02.pmc-sierra.internal [216.241.227.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bby1mta03.pmc-sierra.bc.ca (Postfix) with ESMTP id BFAE11070812 for ; Wed, 8 Apr 2015 13:47:18 -0700 (PDT) Received: from BBYEXM01.pmc-sierra.internal ([169.254.1.130]) by bby1cas02.pmc-sierra.internal ([2002:d8f1:e38f::d8f1:e38f]) with mapi id 14.03.0123.003; Wed, 8 Apr 2015 13:47:18 -0700 From: Spencer Jackson To: "mpls@ietf.org" Thread-Topic: Need clarification for the draft-cheng-mpls-tp-shared-ring-protection Thread-Index: AdByOr5M4g/UqSorSgCC4PobCqkVJQ== Date: Wed, 8 Apr 2015 20:47:17 +0000 Message-ID: <5E6B9C6C95BED441A489C1836E08EF93A658D7A9@BBYEXM01.pmc-sierra.internal> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.241.227.4] Content-Type: multipart/alternative; boundary="_000_5E6B9C6C95BED441A489C1836E08EF93A658D7A9BBYEXM01pmcsier_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pmcs.com; h=from:to:subject:date:message-id:content-type:mime-version; s=default; bh=Kmp4ULL1629sSgG1gTfTneWA/aVCIAl4UejTIENWMYk=; b=FRPJyVultDzIM+2NqmoDZqwwUjOe0zNTHbv/qUDHzKY3Klm440HDT2ZBmB/Ou1KvABjakwYK1l6WH657qdu6JrFJCiY2RIBtjZ5sTEY9hIw/cJa6YPG53rKHx9QmvdOVi/Zn6YqsnTqiAVQy61FzZ1/vN4s/0cF21rDoNdcI4pI= Archived-At: Subject: [mpls] Need clarification for the draft-cheng-mpls-tp-shared-ring-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: Wed, 08 Apr 2015 20:50:16 -0000 --_000_5E6B9C6C95BED441A489C1836E08EF93A658D7A9BBYEXM01pmcsier_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors of draft-cheng-mpls-tp-shared-ring-protection_04, We plan to implement the protocol and would like to get some clarification = for the following questions. 1. Section 4.3.1.1, in the given example the link failure is bi-direc= tional. Please clarify if both bi-directional and uni-directional link fai= lures are covered in this draft. 2. Figure 8. Please clarify the meaning of I and S under each node. 3. Section 4.4.4, 4th paragraph, "..... Nodes F and E will detect the= failure ...." should be "..... Nodes F and D will detect the failure ...."= , right? 4. Section 5.1.3.2. Short and long path needs to be clearly defined. 5. Throughout the document, only operation of the clockwise working a= nd anti-clockwise protection rings is described. The anti-clockwise working= and clockwise protection rings are defined, but their operation is not des= cribed. What is the purpose of these additional rings? Is this intended to = support steering (i.e. a node should select the clockwise working or anti-c= lockwise working ring, depending on the distance to the exit node)? Thanks, Spence -- Spence Jackson Austin Software Center Engineering Manager PMC-Sierra Wireless Infrastructure and Networking Division 6850 Austin Center Blvd., Suite 215, Austin, TX 78731 512-345-3808 x113 (Tel) 512-345-3828 (Fax) 512-589-9681 (Mobile) http://pmcs.com/products/mobile/network_processors/ This message is sent in confidence for the addressee only. It may contain l= egally privileged information. The contents are not to be disclosed to anyo= ne other than the addressee. Unauthorized recipients are requested to prese= rve this confidentiality, advise the sender immediately of any error in tra= nsmission and delete the email from their systems. --_000_5E6B9C6C95BED441A489C1836E08EF93A658D7A9BBYEXM01pmcsier_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors of draft-cheng-mpls-tp-shared-ring-prot= ection_04,

 

We plan to implement the protocol and would like to = get some clarification for the following questions.

 

1.     &= nbsp; Section 4.3.1.1, in the given example the link fail= ure is bi-directional.  Please clarify if both bi-directional and uni-= directional link failures are covered in this draft.

2.     &= nbsp; Figure 8.  Please clarify the meaning of I and= S under each node.

3.     &= nbsp; Section 4.4.4, 4th paragraph, “= 230;.. Nodes F and E will detect the failure ….” should be= “….. Nodes F and D will detect the failure ….”, ri= ght?

4.     &= nbsp; Section 5.1.3.2. Short and long path needs to be cl= early defined.

5.     &= nbsp; Throughout the document, only operation of the cloc= kwise working and anti-clockwise protection rings is described. The anti-cl= ockwise working and clockwise protection rings are defined, but their opera= tion is not described. What is the purpose of these additional rings? Is this intended to support steering (i= .e. a node should select the clockwise working or anti-clockwise working ri= ng, depending on the distance to the exit node)?

 

Thanks,

Spence

 

--

 

Spence Jackson

Austin Software Center Engineering Manager

PMC-Sierra

Wireless Infrastructure and Networking Division

6850 Austin Center Blvd., Suite 215, Austin, TX 7= 8731

512-345-3808 x113 (Tel)

512-345-3828 (Fax)

512-589-9681 (Mobile)

 

http://pmcs.com/products/mobile/network_processors/

 

This message is sent= in confidence for the addressee only. It may contain legally privileged in= formation. The contents are not to be disclosed to anyone other than the ad= dressee. Unauthorized recipients are requested to preserve this confidentiality, advise the sender immediately = of any error in transmission and delete the email from their systems.<= /o:p>

 

--_000_5E6B9C6C95BED441A489C1836E08EF93A658D7A9BBYEXM01pmcsier_-- From nobody Wed Apr 8 15:43:34 2015 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 1943B1A90C5 for ; Wed, 8 Apr 2015 15:43:33 -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 vL-qOHCU0dNL for ; Wed, 8 Apr 2015 15:43:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193CE1A90C0 for ; Wed, 8 Apr 2015 15:43:31 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so103045169wgb.1 for ; Wed, 08 Apr 2015 15:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=KDfPeMqZDvgvCuTkrOEhU0G3eWBj6t5+nYlqrYOZou8=; b=ae8E95992m5/vZDPt1GPa5ZpZwdKCxS1YvTMnFX30YysrSp6srSDR8p4VwOFgT1vWC 2ma979P2AO5rogau0r1mqH3+sDpgdkTqx76XchlZXyOfGfZ0TxYN4oFmpgJN25W4cB89 KZoIrQ7Z2vRv25u2QwLXaFX10gIMvztXF8A6fUv70hEoS//vSUzL+0WTCG1Hs2gbbTIb UBjh3fO9QAD42Rqc9R8z58IX5d7Dq5AmhoI7EM34X0RysvJ0zGaqvDcwEojsZ3VxnlXx V62UhqvpCdpZhwaBlmhEDlohavtEgn5zDDJpHrdHMvO1ULWGr9qMekTyIXK9ePWhBMxv oayg== X-Received: by 10.194.192.65 with SMTP id he1mr55180546wjc.118.1428533009866; Wed, 08 Apr 2015 15:43:29 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id ei8sm17559753wib.10.2015.04.08.15.43.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 15:43:29 -0700 (PDT) Message-ID: <5525AF0F.7000807@gmail.com> Date: Thu, 09 Apr 2015 00:43:27 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Spencer Jackson , "mpls@ietf.org" References: <5E6B9C6C95BED441A489C1836E08EF93A658D7A9@BBYEXM01.pmc-sierra.internal> In-Reply-To: <5E6B9C6C95BED441A489C1836E08EF93A658D7A9@BBYEXM01.pmc-sierra.internal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] Need clarification for the draft-cheng-mpls-tp-shared-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:43:33 -0000 Dear Spence, You wrote: > We plan to implement the protocol and would like to get some > clarification for the following questions. Very good. Please let me try to answer: > 1.Section 4.3.1.1, in the given example the link failure is > bi-directional. Please clarify if both bi-directional and > uni-directional link failures are covered in this draft. Indeed, both bidirectional (e.g cable cut) and uni-directional (e.g. single fiber cut) are covered. If it is not obvious we will add text. > 2.Figure 8. Please clarify the meaning of I and S under each node. The I and S are in fact indicating the status of the link between two adjacent nodes. The "I" indicates "intact" the "S" indicates "severed". In this example the link between nodes C and D is broken. > 3.Section 4.4.4, 4^th paragraph, “….. Nodes F and E will detect the > failure ….” should be “….. Nodes F and D will detect the failure ….”, > right? Good catch! will be corrected. > 4.Section 5.1.3.2. Short and long path needs to be clearly defined. OK, we will add text. > 5.Throughout the document, only operation of the clockwise working > and anti-clockwise protection rings is described. The anti-clockwise > working and clockwise protection rings are defined, but their > operation is not described. What is the purpose of these additional > rings? Is this intended to support steering (i.e. a node should > select the clockwise working or anti-clockwise working ring, > depending on the distance to the exit node)? Maybe we should add text to explain that the description is for CW working and ACW protection, but applicable in the same way to ACW working and CW protection. In general the working path prefers to take the shortest path (to reduce the propagation delay), for example in Figure 3 the shortest working path from A to C is clockwise, and the shortest path from A to E is anti-clockwise. Also in transport networks the traffic is in general bi-directional, and co-routed. This means that in the forward direction traffic may flow clockwise, and in the reverse direction will consequently flow anti-clockwise. > Thanks, You're welcome. Best regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Wed Apr 8 16:29:31 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 892EC1ACD2F; Wed, 8 Apr 2015 16:29:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4AA1ACC86 for ; Wed, 8 Apr 2015 16:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 NVFjX6rU_wAH for ; Wed, 8 Apr 2015 16:29:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279871ACC92 for ; Wed, 8 Apr 2015 16:29:26 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:42333 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfzPR-0001t5-5U for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Wed, 08 Apr 2015 16:29:25 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t38NTIBO005942 for ; Wed, 8 Apr 2015 23:29:19 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id EE5C9C20812; Wed, 8 Apr 2015 23:29:18 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> References: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #815506 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 08 Apr 2015 23:29:18 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150408232926.279871ACC92@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 16:29:26 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org Subject: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:29:29 -0000 Dear Authors: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We've completed the IANA Actions for the following RFC-to-be: draft-ietf-mpls-proxy-lsp-ping-05 NOTE: The following have been converted to lower case: "could" in TBA-9; "marked" in the notes attached to the registration procedures for the Downstream Mapping and Next Hop registries. QUESTION: The existing sub-TLV registries list notes for each registration range. The new sub-TLV registry for Proxy Echo Parameters doesn't, because I couldn't find a source for those notes in RFC 4379. Should those notes ("This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized," etc.) be included in this registry's registration procedures? If so, are these included or implied in RFC 4379? If there isn't a source for them in RFC 4379, they'll have to be spelled out in this document's IANA Considerations section. ACTION 1: IANA has registered the following Message Types: 3 MPLS Proxy Ping Request [RFC-ietf-mpls-proxy-lsp-ping-05] 4 MPLS Proxy Ping Reply [RFC-ietf-mpls-proxy-lsp-ping-05] Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters ACTION 2: IANA has registered the following TLVs: 23 Proxy Echo Parameters [RFC-ietf-mpls-proxy-lsp-ping-05] [http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-23] 24 Reply-to Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs 25 Upstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs 26 Downstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters ACTION 3: IANA has registered the following Return Codes: 16 Proxy Ping not authorized. [RFC-ietf-mpls-proxy-lsp-ping-05] 17 Proxy Ping parameters need to be modified. [RFC-ietf-mpls-proxy-lsp-ping-05] 18 MPLS Echo Request could not be sent. [RFC-ietf-mpls-proxy-lsp-ping-05] 19 Replying router has FEC mapping for topmost FEC. [RFC-ietf-mpls-proxy-lsp-ping-05] Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters ACTION 4: IANA has created the following registry: Sub-TLVs for TLV Type 23 Reference [RFC4379][RFC-ietf-mpls-proxy-lsp-ping-05] Range Registration Procedures 0-16383 Standards Action 16384-31743 Specification Required 32768-49161 Standards Action 49162-64511 Specification Required Sub-Type Sub-TLV Name Reference Comment 0 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] 1 Next Hop [RFC-ietf-mpls-proxy-lsp-ping-05] 2-64511 Unassigned 64512-65535 Reserved for Vendor or Private Use [RFC4379] Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters ACTION 5: IANA has made this document an additional reference for the Downstream Mapping Address Type Registry, added the note "Each time a code point is assigned from this registry, unless the same registration is made in both registries, the corresponding Next Hop Address Type Registry must be marked "Reserved" to the top of the registry, and added the following registrations: 6 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] 7 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters ACTION 6: IANA has created the following registry: Next Hop Address Type Registry Registration Procedure(s): Standards Action Reference: [RFC-ietf-mpls-proxy-lsp-ping-05] Note: Each time a code point is assigned from this registry, unless the same registration is made in both registries, the corresponding Downstream Address Mapping Registry must be marked "Reserved." Type Type of Next Hop Address Length IF Length Reference 0 Unassigned 1 IPv4 Numbered 4 4 [RFC4379] 2 IPv4 Unnumbered 4 4 [RFC4379] 3 IPv6 Numbered 16 16 [RFC4379] 4 IPv6 Unnumbered 16 4 [RFC4379] 5 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] 6 IPv4 Protocol Adj 4 0 [RFC-ietf-mpls-proxy-lsp-ping-05] 7 IPv6 Protocol Adj 16 0 [RFC-ietf-mpls-proxy-lsp-ping-05] 8-255 Unassigned Please see http://www.iana.org/assignments/mpls-lsp-ping-parameters The updated list of Protocol Registries is available here: http://www.iana.org/protocols Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) We'll update the reference when the RFC Editor notifies us that they've assigned a number. Thanks, Amanda Baber IANA Request Specialist ICANN From nobody Wed Apr 8 17:06:17 2015 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 364E61A002F; Wed, 8 Apr 2015 17:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 7j66U8iPQe4U; Wed, 8 Apr 2015 17:06:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27F1A0032; Wed, 8 Apr 2015 17:06:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409000615.20730.94443.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 17:06:15 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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, 09 Apr 2015 00:06:16 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ From nobody Wed Apr 8 19:20:37 2015 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 81EA81B2A28; Wed, 8 Apr 2015 19:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1qYiwCyXgeYn; Wed, 8 Apr 2015 19:20:30 -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 19E9C1B2A27; Wed, 8 Apr 2015 19:20:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUQ26433; Thu, 09 Apr 2015 02:20:27 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 03:20:26 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 10:20:21 +0800 From: Xuxiaohu To: Erik Nordmark , "nvo3@ietf.org" Thread-Topic: [nvo3] Encapsulation considerations Thread-Index: AQHQcljZ0fVc246YHEKvkFIl2pYVuJ1D7uKA Date: Thu, 9 Apr 2015 02:20:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> In-Reply-To: <5525C22C.1030303@acm.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [mpls] [nvo3] Encapsulation considerations 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, 09 Apr 2015 02:20:31 -0000 SGkgRXJpaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmlrIE5v cmRtYXJrIFttYWlsdG86bm9yZG1hcmtAYWNtLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEFwcmls IDA5LCAyMDE1IDg6MDUgQU0NCj4gVG86IFh1eGlhb2h1OyBudm8zQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbnZvM10gRW5jYXBzdWxhdGlvbiBjb25zaWRlcmF0aW9ucw0KPiANCj4gT24gNC83 LzE1IDc6MTUgUE0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+IEhpIEVyaWssDQo+ID4NCj4gPiBBcyBp dCBoYXMgc2FpZCBpbiB0aGUgZHJhZnQgOiAiLi4uIFdlIGxhdGVyIGV4cGFuZGVkIHRoZSBzY29w ZSBzb21ld2hhdCB0bw0KPiBjb25zaWRlciBob3cgdGhlIGVuY2Fwc3VsYXRpb25zIHdvdWxkIHBs YXkgd2l0aCBNUExTICJ0cmFuc3BvcnQiLCB3aGljaCBpcw0KPiBpbXBvcnRhbnQgYmVjYXVzZSBT RkMgYW5kIEJJRVIgc2VlbSB0byB0YXJnZXQgYmVpbmcgZGVwZW5kZW50IG9mIHRoZQ0KPiB1bmRl cmx5aW5nICJ0cmFuc3BvcnQiLi4uIiwgaXQgd291bGQgYmUgbmVjZXNzYXJ5IHRvIGNvbnNpZGVy IHRoZSBmaXJzdCBuaWJibGUNCj4gaXNzdWUgZm9yIHRob3NlIGVuY2Fwc3VsYXRpb25zIHdoaWNo IG1heSBiZSB0cmFuc3BvcnRlZCBvdmVyIE1QTFMuIE1vcmUNCj4gc3BlY2lmaWNhbGx5LCBmb3Ig dGhvc2UgZW5jYXBzdWxhdGlvbnMgd2hpY2ggbWF5IGJlIGRpcmVjdGx5IGVuY2Fwc3VsYXRlZCBm dXJ0aGVyDQo+IHdpdGggYW4gTVBMUyBoZWFkZXIsIHRoZXkgbXVzdCBub3Qgc3RhcnQgd2l0aCB0 aGUgdmFsdWUgNCAoSVB2NCkgb3IgdGhlIHZhbHVlIDYNCj4gKElQdjYpIGluIHRoZSBmaXJzdCBu aWJibGUuIE90aGVyd2lzZSwgdGhleSB3b3VsZCBiZSBtaXN0YWtlbmx5IGludGVycHJldGVkIGFz IElQDQo+IHBheWxvYWRzIGJ5IHRyYW5zaXQgTFNScyBhbmQgdGhlcmVmb3JlIGJlIHN1YmplY3Rl ZCB0byBFQ01QIGFuZCBwb3RlbnRpYWwNCj4gcGFja2V0IG1pc29yZGVyaW5nLg0KPiANCj4gWGlh b2h1LA0KPiBHb29kIHBvaW50Lg0KPiANCj4gQnV0IEkgY291bGRuJ3QgdGVsbCBmcm9tIHRoZSBl bWFpbHMgb24gdGhlIEJJRVIgbGlzdCB3aGV0aGVyIHRoZSBjb25zdHJhaW50cyBvbiB0aGUNCj4g Zmlyc3QgbmliYmxlIHZhbHVlIGlzIGEgc3RyaWN0IHJlcXVpcmVtZW50IGluIGFsbCBjYXNlcywg b3Igd2hldGhlciBpdCBpcyBjb25kaXRpb25hbA0KPiBvbiBzb21ldGhpbmcgKGFuZCBpZiBzbywg d2hhdCBpcyB0aGUgY29uZGl0aW9uKS4NCg0KVGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhv dWdodCBvZiBpbmNsdWRlOiAxKSB0aGUgZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFj a2V0IG1pc29yZGVyaW5nOyAyKSB0aGUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQg b3ZlciBhbiBNUExTIFBTTjsgMykgTFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRo ZSBjb250ZW50cyBvZiB0aGUgTVBMUyBwYXlsb2FkIHRvIHNlbGVjdCB0aGUgRUNNUCBwYXRoLg0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQoNCj4gT25jZSBJIGtub3cgdGhhdCBhbnN3ZXIgd2Ug Y2FuIGRlZmluaXRlbHkgYWRkIHNvbWUgdGV4dCBwb2ludGluZyBvdXQgdGhlIGlzc3VlLg0KPiAN Cj4gVGhhbmtzLA0KPiAgICAgRXJpaw0KPiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBY aWFvaHUNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBF cmlrIE5vcmRtYXJrIFttYWlsdG86bm9yZG1hcmtAc29uaWMubmV0XQ0KPiA+PiBTZW50OiAyMDE1 xOoz1MIyNsjVIDU6MDENCj4gPj4gVG86IG52bzNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW252 bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnMNCj4gPj4NCj4gPj4NCj4gPj4gSSBwcmVz ZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2VudCBOVk8zIGludGVyaW0gbWVldGlu Zy5UaGUNCj4gPj4gZnVsbA0KPiA+IDEyDQo+ID4+IGFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdo ZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVyIHRoaXMgd2Vlay4NCj4gPj4gICAgVGhlIGRy YWZ0IGlzDQo+ID4+ICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1y dGctZHQtZW5jYXAvDQo+ID4+ICAgIGFuZCB0aGUgc2xpZGVzIGFyZSBhdA0KPiA+PiAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgu cGRmDQo+ID4+DQo+ID4+IFRoZXJlIGlzIHByb2JhYmx5IGFkZGl0aW9uYWwgdGhpbmdzIGluIHRo ZXJlIHRvIGNvbnNpZGVyIGZvciBOVk8zLA0KPiA+PiBhbmQNCj4gPiBhZHZpY2UNCj4gPj4gdGhh dCBjYW4gYmUgcmV1c2VkIHRvIG1ha2UgaXQgZWFzaWVyIHRvIG1vdmUgTlZPMyBmb3J3YXJkLg0K PiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiAgICAgIEVyaWsNCj4gPj4NCj4gPj4NCj4gPj4NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gPiBudm8zQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo+ID4NCg0K From nobody Thu Apr 9 00:55:20 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 683781A891C; Thu, 9 Apr 2015 00:55:18 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DD41A8771 for ; Thu, 9 Apr 2015 00:55:18 -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 q5oPmLy-7Bi1 for ; Thu, 9 Apr 2015 00:55:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038301A8A9A for ; Thu, 9 Apr 2015 00:55:15 -0700 (PDT) Received: from pipi.pi.nu ([83.168.239.141]:40572) by zinfandel.tools.ietf.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yg7Iv-0004k1-BR for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Thu, 09 Apr 2015 00:55:14 -0700 Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CF073180145E; Thu, 9 Apr 2015 09:55:09 +0200 (CEST) Message-ID: <5526305D.4040700@pi.nu> Date: Thu, 09 Apr 2015 09:55:09 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: drafts-approval@iana.org References: <20150325222459.19546.84118.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 83.168.239.141 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: loa@pi.nu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150409075515.038301A8A9A@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 00:55:15 -0700 (PDT) Resent-From: loa@pi.nu Archived-At: Archived-At: Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 09 Apr 2015 07:55:18 -0000 Authors, This looks right to me, but you at least one of the authors need sign-off. As for the question I think that the same notes as for the other registers would be OK, i.e.: 0-16383 Standards Action This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized. 16384-31743 Specification Required Experimental RFC needed 32768-49161 Standards Action This range is for optional TLVs that can be silently dropped if not recognized. 49162-64511 Specification Required Experimental RFC needed /Loa On 2015-04-09 01:29, Amanda Baber via RT wrote: > Dear Authors: > > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > > We've completed the IANA Actions for the following RFC-to-be: > > draft-ietf-mpls-proxy-lsp-ping-05 > > NOTE: The following have been converted to lower case: "could" in TBA-9; "marked" in the notes attached to the registration procedures for the Downstream Mapping and Next Hop registries. > > QUESTION: The existing sub-TLV registries list notes for each registration range. The new sub-TLV registry for Proxy Echo Parameters doesn't, because I couldn't find a source for those notes in RFC 4379. > > Should those notes ("This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized," etc.) be included in this registry's registration procedures? If so, are these included or implied in RFC 4379? If there isn't a source for them in RFC 4379, they'll have to be spelled out in this document's IANA Considerations section. > > ACTION 1: > > IANA has registered the following Message Types: > > 3 MPLS Proxy Ping Request [RFC-ietf-mpls-proxy-lsp-ping-05] > 4 MPLS Proxy Ping Reply [RFC-ietf-mpls-proxy-lsp-ping-05] > > Please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > > ACTION 2: > > IANA has registered the following TLVs: > > 23 Proxy Echo Parameters [RFC-ietf-mpls-proxy-lsp-ping-05] [http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-23] > 24 Reply-to Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs > 25 Upstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs > 26 Downstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs > > Please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > > ACTION 3: > > IANA has registered the following Return Codes: > > 16 Proxy Ping not authorized. [RFC-ietf-mpls-proxy-lsp-ping-05] > 17 Proxy Ping parameters need to be modified. [RFC-ietf-mpls-proxy-lsp-ping-05] > 18 MPLS Echo Request could not be sent. [RFC-ietf-mpls-proxy-lsp-ping-05] > 19 Replying router has FEC mapping for topmost FEC. [RFC-ietf-mpls-proxy-lsp-ping-05] > > Please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > > ACTION 4: > > IANA has created the following registry: > > Sub-TLVs for TLV Type 23 > Reference > [RFC4379][RFC-ietf-mpls-proxy-lsp-ping-05] > > Range Registration Procedures > 0-16383 Standards Action > 16384-31743 Specification Required > 32768-49161 Standards Action > 49162-64511 Specification Required > > Sub-Type Sub-TLV Name Reference Comment > 0 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > 1 Next Hop [RFC-ietf-mpls-proxy-lsp-ping-05] > 2-64511 Unassigned > 64512-65535 Reserved for Vendor or Private Use [RFC4379] > > Please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > > ACTION 5: > > IANA has made this document an additional reference for the Downstream Mapping Address Type Registry, added the note "Each time a code point is assigned from this registry, unless the same registration is made in both registries, the corresponding Next Hop Address Type Registry must be marked "Reserved" to the top of the registry, and added the following registrations: > > 6 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > 7 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > > Please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > > ACTION 6: > > IANA has created the following registry: > > Next Hop Address Type Registry > Registration Procedure(s): Standards Action > Reference: [RFC-ietf-mpls-proxy-lsp-ping-05] > Note: Each time a code point is assigned from this registry, unless the > same registration is made in both registries, the corresponding > Downstream Address Mapping Registry must be marked "Reserved." > > Type Type of Next Hop Address Length IF Length Reference > 0 Unassigned > 1 IPv4 Numbered 4 4 [RFC4379] > 2 IPv4 Unnumbered 4 4 [RFC4379] > 3 IPv6 Numbered 16 16 [RFC4379] > 4 IPv6 Unnumbered 16 4 [RFC4379] > 5 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > 6 IPv4 Protocol Adj 4 0 [RFC-ietf-mpls-proxy-lsp-ping-05] > 7 IPv6 Protocol Adj 16 0 [RFC-ietf-mpls-proxy-lsp-ping-05] > 8-255 Unassigned > > Please see > http://www.iana.org/assignments/mpls-lsp-ping-parameters > > > The updated list of Protocol Registries is available here: > > http://www.iana.org/protocols > > Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) > > We'll update the reference when the RFC Editor notifies us that they've assigned a number. > > Thanks, > > Amanda Baber > IANA Request Specialist > ICANN > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 9 06:30:33 2015 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 2A9971B2D50 for ; Thu, 9 Apr 2015 06:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 voubxINO7V0l for ; Thu, 9 Apr 2015 06:30:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 085361B2D3F for ; Thu, 9 Apr 2015 06:30:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D630A180092; Thu, 9 Apr 2015 06:29:48 -0700 (PDT) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150409132948.D630A180092@rfc-editor.org> Date: Thu, 9 Apr 2015 06:29:48 -0700 (PDT) Archived-At: Cc: mpls@ietf.org, rshearma@brocade.com, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC3031 (4331) 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, 09 Apr 2015 13:30:32 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=4331 -------------------------------------- Type: Technical Reported by: Robert Shearman Section: 3.22 Original Text ------------- When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. Corrected Text -------------- When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid and it has a usable L3 next hop. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. Notes ----- There is ambiguity as to the cause of the "ILM [not mapping] the packet's incoming label into an NHLFE". It could be read in a number of ways, of which only one can be correct: 1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no binding has been installed because the label hasn't been advertised. Clearly, 3.18 covers this case already, and is inconsistent with the section title of "Lack of Outgoing Label" so this interpretation is unlikely to have been intended. 2. The label is valid and is expected to be used for forwarding, but an NHLFE entry is missing or not usable because the interface the next hop is reachable over has gone down, or for some other reason isn't usable. This interpretation is ruled out by the statement that "it is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding", which wouldn't be possible if the interface was down. 3. A resource allocation error occurred meaning that the ILM binding was allocated, but the NHLFE entry couldn't be allocated. There is no mention of resource issues in this or related sections so again this interpretation seems unlikely. 4. The label is valid and is expected to be used for forwarding, but the LSR has received no label binding from the LSP's next hop even though it has a usable L3 next hop (i.e. it lacks an outgoing label). It cannot map to an NHLFE entry because the actions in section 3.10 don't include popping and forwarding as unlabeled. This is therefore the interpretation that best fits. To clarify that interpretation 4 is the one intended, the phrase "and it has a usable L3 next hop" is inserted into the text, using the definition of L3 next hop from section 3.17. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Apr 9 07:19:12 2015 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 74C111A6EE7; Thu, 9 Apr 2015 07:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MSvkAviWRWIE; Thu, 9 Apr 2015 07:19:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B51501A1F00; Thu, 9 Apr 2015 07:19:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7AC67180204; Thu, 9 Apr 2015 07:18:32 -0700 (PDT) To: rshearma@brocade.com, erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150409141832.7AC67180204@rfc-editor.org> Date: Thu, 9 Apr 2015 07:18:32 -0700 (PDT) Archived-At: Cc: mpls@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Errata Rejected] RFC3031 (4331) 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, 09 Apr 2015 14:19:11 -0000 The following errata report has been rejected for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=4331 -------------------------------------- Status: Rejected Type: Technical Reported by: Robert Shearman Date Reported: 2015-04-09 Rejected by: Alia Atlas (IESG) Section: 3.22 Original Text ------------- When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. Corrected Text -------------- When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid and it has a usable L3 next hop. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. Notes ----- Although the reporter is concerned about ambiguity in terms of why the ILM doesn't map a valid label into an NHLFE, the reason that might happen is really irrelevant. The original statement clearly specifies that it could be an error or transient condition. The correct action of discarding a packet where the label doesn't map into a n NHLFE applies regardless of whether or not there is a usable L3 next hop. This proposed errata would thus add incorrect ambiguity for no purpose. ================================================ There is ambiguity as to the cause of the "ILM [not mapping] the packet's incoming label into an NHLFE". It could be read in a number of ways, of which only one can be correct: 1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no binding has been installed because the label hasn't been advertised. Clearly, 3.18 covers this case already, and is inconsistent with the section title of "Lack of Outgoing Label" so this interpretation is unlikely to have been intended. 2. The label is valid and is expected to be used for forwarding, but an NHLFE entry is missing or not usable because the interface the next hop is reachable over has gone down, or for some other reason isn't usable. This interpretation is ruled out by the statement that "it is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding", which wouldn't be possible if the interface was down. 3. A resource allocation error occurred meaning that the ILM binding was allocated, but the NHLFE entry couldn't be allocated. There is no mention of resource issues in this or related sections so again this interpretation seems unlikely. 4. The label is valid and is expected to be used for forwarding, but the LSR has received no label binding from the LSP's next hop even though it has a usable L3 next hop (i.e. it lacks an outgoing label). It cannot map to an NHLFE entry because the actions in section 3.10 don't include popping and forwarding as unlabeled. This is therefore the interpretation that best fits. To clarify that interpretation 4 is the one intended, the phrase "and it has a usable L3 next hop" is inserted into the text, using the definition of L3 next hop from section 3.17. --VERIFIER NOTES-- Although the reporter is concerned about ambiguity in terms of why the ILM doesn't map a valid label into an NHLFE, the reason that might happen is really irrelevant. The original statement clearly specifies that it could be an error or transient condition. The correct action of discarding a packet where the label doesn't map into a n NHLFE applies regardless of whether or not there is a usable L3 next hop. This proposed errata would thus add incorrect ambiguity for no purpose. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Apr 9 11:01:36 2015 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 A97CC1B304F; Thu, 9 Apr 2015 11:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4boevSxiwMa; Thu, 9 Apr 2015 11:01:33 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BFF1B304C; Thu, 9 Apr 2015 11:01:33 -0700 (PDT) Received: by obbry2 with SMTP id ry2so26599060obb.1; Thu, 09 Apr 2015 11:01:32 -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=UcszIte+kdNmlchUsLjxmFom+vsM4s7FNGkJ4ZPDZMA=; b=GRJ/vE02uznPFRLi7xT0qQz8hbstVvmo68GoKUQBD+Lkil2EGj7k6XYDL1lZjs07rQ VnnBOOpgPNqU+Xo8Rs17/5rwvoABYlofLZGrJ9yx0YJ4qWFGblfw4gt40UKUqtwqrrCR MSn7WIgyDR5cyX1djd6za9p9AxML6FMizJnOHpCEzvVdpRqZf+leMYTqg2Ob1sK4C5XU jODm9d/TsufDpvadUZZUyTeTH+9y3aMckap8uAd3Rxnkn4if0Njz/Dy06rJNAKuIRqMg 1Haugi0Kf06JwIM62tT/oF0j6otrbDKFy/6UV/aX5kkcYjMQLEcEsBjgM733pxkTmizi EeVA== MIME-Version: 1.0 X-Received: by 10.60.165.68 with SMTP id yw4mr39722675oeb.76.1428602492766; Thu, 09 Apr 2015 11:01:32 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Thu, 9 Apr 2015 11:01:32 -0700 (PDT) In-Reply-To: <5526BBDB.3000805@acm.org> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> Date: Thu, 9 Apr 2015 14:01:32 -0400 Message-ID: From: Alia Atlas To: Erik Nordmark Content-Type: multipart/alternative; boundary=047d7b4508621b532f05134e700a Archived-At: Cc: BIER , "mpls@ietf.org" , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] [nvo3] Encapsulation considerations 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, 09 Apr 2015 18:01:35 -0000 --047d7b4508621b532f05134e700a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark wrote: > On 4/8/15 7:20 PM, Xuxiaohu wrote: > >> Hi Erik, >> >> But I couldn't tell from the emails on the BIER list whether the >>> constraints on the first nibble value is a strict requirement in all ca= ses, >>> or whether it is conditional on something (and if so, what is the >>> condition). >>> >> The conditions that I have thought of include: 1) the encapsulation is >> sensitive to packet misordering; 2) the encapsulation may be transported >> over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of t= he >> MPLS payload to select the ECMP path. >> > Those are conditions when the misordering would happen. But are you sayin= g > that any LSR is free to use the MPLS payload (including looking for 4 and= 6 > in the first nibble) to determine whether the packet is IPv4 and IPv6 and > use what it thinks are IPv4 and IPv6 fields for ECMP purposes? Take a quick look at RFC 4385 - which is the control word for pseudo-wires. The short form is that a number of routers at the time peeked beneath the label stack to figure out whether what was inside as IPv4 or IPv6 based solely upon the first nibble. A recommendation was made that the checksum should also be verified, but the only equipment that I'm certain of that did that isn't around anymore. Also look at Section 2.4 of RFC 7325. Alia > > Thanks, > Erik > > >> Best regards, >> Xiaohu >> >> Once I know that answer we can definitely add some text pointing out th= e >>> issue. >>> >>> Thanks, >>> Erik >>> >>> Best regards, >>>> Xiaohu >>>> >>>> -----Original Message----- >>>>> From: Erik Nordmark [mailto:nordmark@sonic.net] >>>>> Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01 >>>>> To: nvo3@ietf.org >>>>> Subject: [nvo3] Encapsulation considerations >>>>> >>>>> >>>>> I presented part of this at the most recent NVO3 interim meeting.The >>>>> full >>>>> >>>> 12 >>>> >>>>> areas of considerations where presented at RTGWG earlier this week. >>>>> The draft is >>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ >>>>> and the slides are at >>>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>>> >>>>> There is probably additional things in there to consider for NVO3, >>>>> and >>>>> >>>> advice >>>> >>>>> that can be reused to make it easier to move NVO3 forward. >>>>> >>>>> Regards, >>>>> Erik >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --047d7b4508621b532f05134e700a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <nordmark@acm.org> = wrote:
On 4/8/15 7:20 PM= , Xuxiaohu wrote:
Hi Erik,

But I couldn't tell from the emails on the BIER list whether the constr= aints on the first nibble value is a strict requirement in all cases, or wh= ether it is conditional on something (and if so, what is the condition).
The conditions that I have thought of include: 1) the encapsulation is sens= itive to packet misordering; 2) the encapsulation may be transported over a= n MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS p= ayload to select the ECMP path.
Those are conditions when the misordering would happen. But are you saying = that any LSR is free to use the MPLS payload (including looking for 4 and 6= in the first nibble) to determine whether the packet is IPv4 and IPv6 and = use what it thinks are IPv4 and IPv6 fields for ECMP purposes?
=

Take a quick look at RFC 4385 - which is the control wo= rd for pseudo-wires.
The short form is that a number of routers a= t the time peeked beneath the label stack to figure out whether what was in= side as IPv4 or IPv6 based solely upon the first nibble.=C2=A0 A recommenda= tion was made that the checksum should also be verified, but the only equip= ment that I'm certain of that did that isn't around anymore.
<= div>
Also look at Section 2.4 of RFC 7325.

Alia
=C2=A0

Thanks,
=C2=A0 =C2=A0Erik


Best regards,
Xiaohu

Once I know that answer we can definitely add some text pointing out the is= sue.

Thanks,
=C2=A0 =C2=A0 =C2=A0Erik

Best regards,
Xiaohu

-----Original Message-----
From: Erik Nordmark [mailto:nordmark@sonic.net]
Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01
To: nvo3@ietf.org Subject: [nvo3] Encapsulation considerations


I presented part of this at the most recent NVO3 interim meeting.The
full
12
areas of considerations where presented at RTGWG earlier this week.
=C2=A0 =C2=A0 The draft is
=C2=A0 =C2=A0 =C2=A0 http://datatracker.ietf.org/doc/draft-rt= g-dt-encap/
=C2=A0 =C2=A0 and the slides are at
=C2=A0 =C2=A0 =C2=A0http://www.ietf.org/proceedin= gs/92/slides/slides-92-rtgwg-8.pdf

There is probably additional things in there to consider for NVO3,
and
advice
that can be reused to make it easier to move NVO3 forward.

Regards,
=C2=A0 =C2=A0 =C2=A0 Erik



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



_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

--047d7b4508621b532f05134e700a-- From nobody Thu Apr 9 11:48:04 2015 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 6913F1A86F7; Thu, 9 Apr 2015 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 XueSsRgGfWmS; Thu, 9 Apr 2015 11:47:54 -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 6AC5F1A3B9D; Thu, 9 Apr 2015 11:47:46 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-d9-552672c071f2 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 57.01.12456.0C276255; Thu, 9 Apr 2015 14:38:24 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 14:47:43 -0400 From: David Allan I To: Tony Przygienda , Alia Atlas Thread-Topic: [Bier] [sfc] [nvo3] Encapsulation considerations Thread-Index: AQHQcvGAbLNbfLoTTU+uoBqvb9o3op1E/6Lg Date: Thu, 9 Apr 2015 18:47:42 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> 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: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyuXSPn+6BIrVQg55NphafHl5itlg6Yw+T xa2lK1kt+qfuZLJ4Ol/S4smDrewWux9sZLHYen4VowOHx+Ur3h47Z91l92g58pbVY8mSn0wB LFFcNimpOZllqUX6dglcGV/XLWEqaNvNWHFp9gS2BsaebYxdjJwcEgImEl+eHGeHsMUkLtxb z9bFyMUhJHCUUeLkpxtACQ4gZxmjxDFXkBo2AQOJPf+/gPWKCHhKbH84AayeWWA/o8TPX9fZ QBLCArYSa55fYYcospM4v+EzVIORxMv7t1hAbBYBFYnNs1aB1fAK+EqcOHOdFWLxSyaJW+ue gw3iFAiUuDLhCzOIzQh03fdTa5hAbGYBcYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtqLEvv7p 7BD1+RLrVl1ihVgmKHFy5hOWCYyis5CMmoWkbBaSsllA/zMLaEqs36UPUaIoMaX7ITuErSHR OmcuO7L4Akb2VYwcpcWpZbnpRgabGIFRekyCTXcH456XlocYBTgYlXh4HyxRDRViTSwrrsw9 xCjNwaIkzrvowcEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw5ufw/ty36ceFDA8vlROeb Zqvnaj7cuGPnlWI7fU4P2RVPr6cG1a50ORpxeLZq/5L1zzxb1Q2e/XngWfHGaeFnZxaWIsmW 9Lhl+qKb3NWf9yrv/PNm/UurP4meV6dUh4RM1eXNZoludT5+MiVO/rSczUkNvbBXH1dkTTk6 2fumiaEL20ub/HglluKMREMt5qLiRABsk3w0swIAAA== Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" , "nvo3@ietf.org" , Erik Nordmark Subject: Re: [mpls] [Bier] [sfc] [nvo3] Encapsulation considerations 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, 09 Apr 2015 18:48:01 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PIGl0IGlzIHNpbXBseSBhIHJlc3RyaWN0aW9uIG9uIHRoZSBmaXJzdCBmb3VyIGJpdHMgb2Yg YW55dGhpbmcgdGhhdCBjYW4gYmUgZGlyZWN0bHkgZW5jYXBzdWxhdGVkIGluIE1QTFMNCg0KT3Ro ZXJ3aXNlLCBkZXNpZ25pbmcgKGZvciBleGFtcGxlKSBhIHZlcnNpb24gZmllbGQgZm9yIHdoaWNo IElBTkEgd2lsbCBoYXZlIHRvIHB1bmNoIGhvbGVzIGluIHRoZSBhc3NpZ25tZW50IHJhbmdlIGRv ZXMgbm90IHNlZW0gbGlrZSBhIGdvb2QgaWRlYS4gQW5kIEnigJl2ZSBub3QgYmVlbiBhYmxlIHRv IGNvbnZpbmNlIG15c2VsZiB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgaGFzIGNvbXBsZXRlbHkgZ29u ZSBhd2F5Lg0KDQpDaGVlcnMNCkRhdmUNCg0KRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbnkgUHJ6eWdpZW5kYQ0KU2VudDogVGh1cnNkYXks IEFwcmlsIDA5LCAyMDE1IDExOjE4IEFNDQpUbzogQWxpYSBBdGxhcw0KQ2M6IG1wbHNAaWV0Zi5v cmc7IEJJRVI7IHNmY0BpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZzsgRXJpayBOb3JkbWFyazsgWHV4 aWFvaHUNClN1YmplY3Q6IFJlOiBbQmllcl0gW3NmY10gW252bzNdIEVuY2Fwc3VsYXRpb24gY29u c2lkZXJhdGlvbnMNCg0KSSB3b3VsZCB2ZW50dXJlIHRvIHNheSB0aGF0DQphLiAgICAgIEJJRVIg bWlzb3JkZXJpbmcgd291bGQgYmUgYSBiYWQgdGhpbmcgZm9yIG1hbnkgYXBwbGljYXRpb25zIGJ1 dCBJIGRvIG5vdCB0aGluayB0aGF0IHRoZSBlbmNhcHN1bGF0aW9uIHBlciBzZSBtaXNvcmRlcnMg b3Igbm90IGFzIHByb3BlcnR5LCBpdOKAmXMgdGhlIHdheSB0aGUgaW50ZXJtZWRpYXRlIHJvdXRl cnMgYXJlIGFsbG93ZWQgdG8gcGxheSBzaGFubmlnYW5zIChvciBzZWVuIGRpZmZlcmVudGx5LCDi gJhoZXVyaXN0aWNhbGx54oCZIGNvbWUgdXAgd2l0aCB0aGluZ3MgZ2l2ZW4gdW5jbGVhciBzZW1h bnRpY3Mgb2YgdGhlIGVuY2FwcykgdGhhdCBjYXVzZXMgbWlzb3JkZXJpbmcuIFNvIGl0IGlzIHVw IHRvIHRoZSBlbmNhcHMgdG8gZ2l2ZSBlbm91Z2ggaW5mbyBzbyB0aGUgcm91dGVycyBpbiB0aGUg bWlkZGxlIGRvIHRoZSDigJhyaWdodCB0aGluZ+KAmS4gTW9kdWxvIGhpc3RvcmljYWwgcHJvYmxl bXMgd2l0aCBDVyBzdXBwb3J0IGFuZCBzbyBvbiDigKYNCmIuICAgICAgVGhpcyBmbGF2b3Igb2Yg ZGlzY3Vzc2lvbiBpcyByZXBlYXRpbmcsIGUuZy4gZVZQTiBSRkMgd2l0aCB0aGUgQ1cvbm8gQ1cg ZGViYXRlIHdoaWNoIEkgY291bGQgcmVzdG9yZSBvbmx5IHBhcnRpYWxseSBhbmQgb3RoZXIgZ3Jv dXBzIG5vdyDigKYNCg0KT0ssIGxlbW1lIHN0aWNrIG15IChuYcOvdmUgOy0pIGhlYWQgZmFyIG91 dDogd2h5IGRvIGVuY2FwcyBndWlkZWxpbmVzIGZvciBldmVyeXRoaW5nIHRoYXQgY2FuIGdvIG92 ZXIgUFNOIG5vdCBtYW5kYXRlIENXIGZyb20gbm93IG9uPyBFeGlzdGluZyBnZWFyIGFuZCBoaXN0 b3JpY2FsIFJGQ3Mgc3VwcG9ydGVkIHVudGlsIHRoZXkgcGV0ZXIgb3V0IGFuZCBlbnRyb3B5IGxh YmVscyBiZWluZyBhbiBvcnRob2dvbmFsIG1lY2hhbmlzbSDigKYgIE9yIGRvIHdlIHRoaW5rIHRo ZSDigJhoZXVyaXN0aWNhbCBEUEknIGlzIGEgYm90dG9tbGVzcyBib3ggb2YgYmFuZC1haWRzID8N Cg0KLS0tIHRvbnkNCg0KT24gVGh1LCBBcHIgOSwgMjAxNSBhdCAxMTowMSBBTSwgQWxpYSBBdGxh cyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4gd3JvdGU6DQpP biBUaHUsIEFwciA5LCAyMDE1IGF0IDE6NTAgUE0sIEVyaWsgTm9yZG1hcmsgPG5vcmRtYXJrQGFj bS5vcmc8bWFpbHRvOm5vcmRtYXJrQGFjbS5vcmc+PiB3cm90ZToNCk9uIDQvOC8xNSA3OjIwIFBN LCBYdXhpYW9odSB3cm90ZToNCkhpIEVyaWssDQpCdXQgSSBjb3VsZG4ndCB0ZWxsIGZyb20gdGhl IGVtYWlscyBvbiB0aGUgQklFUiBsaXN0IHdoZXRoZXIgdGhlIGNvbnN0cmFpbnRzIG9uIHRoZSBm aXJzdCBuaWJibGUgdmFsdWUgaXMgYSBzdHJpY3QgcmVxdWlyZW1lbnQgaW4gYWxsIGNhc2VzLCBv ciB3aGV0aGVyIGl0IGlzIGNvbmRpdGlvbmFsIG9uIHNvbWV0aGluZyAoYW5kIGlmIHNvLCB3aGF0 IGlzIHRoZSBjb25kaXRpb24pLg0KVGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBv ZiBpbmNsdWRlOiAxKSB0aGUgZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFja2V0IG1p c29yZGVyaW5nOyAyKSB0aGUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBh biBNUExTIFBTTjsgMykgTFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250 ZW50cyBvZiB0aGUgTVBMUyBwYXlsb2FkIHRvIHNlbGVjdCB0aGUgRUNNUCBwYXRoLg0KVGhvc2Ug YXJlIGNvbmRpdGlvbnMgd2hlbiB0aGUgbWlzb3JkZXJpbmcgd291bGQgaGFwcGVuLiBCdXQgYXJl IHlvdSBzYXlpbmcgdGhhdCBhbnkgTFNSIGlzIGZyZWUgdG8gdXNlIHRoZSBNUExTIHBheWxvYWQg KGluY2x1ZGluZyBsb29raW5nIGZvciA0IGFuZCA2IGluIHRoZSBmaXJzdCBuaWJibGUpIHRvIGRl dGVybWluZSB3aGV0aGVyIHRoZSBwYWNrZXQgaXMgSVB2NCBhbmQgSVB2NiBhbmQgdXNlIHdoYXQg aXQgdGhpbmtzIGFyZSBJUHY0IGFuZCBJUHY2IGZpZWxkcyBmb3IgRUNNUCBwdXJwb3Nlcz8NCg0K VGFrZSBhIHF1aWNrIGxvb2sgYXQgUkZDIDQzODUgLSB3aGljaCBpcyB0aGUgY29udHJvbCB3b3Jk IGZvciBwc2V1ZG8td2lyZXMuDQpUaGUgc2hvcnQgZm9ybSBpcyB0aGF0IGEgbnVtYmVyIG9mIHJv dXRlcnMgYXQgdGhlIHRpbWUgcGVla2VkIGJlbmVhdGggdGhlIGxhYmVsIHN0YWNrIHRvIGZpZ3Vy ZSBvdXQgd2hldGhlciB3aGF0IHdhcyBpbnNpZGUgYXMgSVB2NCBvciBJUHY2IGJhc2VkIHNvbGVs eSB1cG9uIHRoZSBmaXJzdCBuaWJibGUuICBBIHJlY29tbWVuZGF0aW9uIHdhcyBtYWRlIHRoYXQg dGhlIGNoZWNrc3VtIHNob3VsZCBhbHNvIGJlIHZlcmlmaWVkLCBidXQgdGhlIG9ubHkgZXF1aXBt ZW50IHRoYXQgSSdtIGNlcnRhaW4gb2YgdGhhdCBkaWQgdGhhdCBpc24ndCBhcm91bmQgYW55bW9y ZS4NCg0KQWxzbyBsb29rIGF0IFNlY3Rpb24gMi40IG9mIFJGQyA3MzI1Lg0KDQpBbGlhDQoNCg0K VGhhbmtzLA0KICAgRXJpaw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCk9uY2UgSSBrbm93IHRo YXQgYW5zd2VyIHdlIGNhbiBkZWZpbml0ZWx5IGFkZCBzb21lIHRleHQgcG9pbnRpbmcgb3V0IHRo ZSBpc3N1ZS4NCg0KVGhhbmtzLA0KICAgICBFcmlrDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86bm9y ZG1hcmtAc29uaWMubmV0PG1haWx0bzpub3JkbWFya0Bzb25pYy5uZXQ+XQ0KU2VudDogMjAxNeW5 tDPmnIgyNuaXpSA1OjAxDQpUbzogbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4N ClN1YmplY3Q6IFtudm8zXSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zDQoNCg0KSSBwcmVz ZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2VudCBOVk8zIGludGVyaW0gbWVldGlu Zy5UaGUNCmZ1bGwNCjEyDQphcmVhcyBvZiBjb25zaWRlcmF0aW9ucyB3aGVyZSBwcmVzZW50ZWQg YXQgUlRHV0cgZWFybGllciB0aGlzIHdlZWsuDQogICAgVGhlIGRyYWZ0IGlzDQogICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJ0Zy1kdC1lbmNhcC8NCiAgICBhbmQg dGhlIHNsaWRlcyBhcmUgYXQNCiAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgucGRmDQoNClRoZXJlIGlzIHByb2JhYmx5IGFkZGl0 aW9uYWwgdGhpbmdzIGluIHRoZXJlIHRvIGNvbnNpZGVyIGZvciBOVk8zLA0KYW5kDQphZHZpY2UN CnRoYXQgY2FuIGJlIHJldXNlZCB0byBtYWtlIGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2Fy ZC4NCg0KUmVnYXJkcywNCiAgICAgIEVyaWsNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmc8 bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCSUVSIG1haWxpbmcgbGlz dA0KQklFUkBpZXRmLm9yZzxtYWlsdG86QklFUkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmllcg0KDQo= --_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklNTyBpdCBpcyBzaW1wbHkgYSByZXN0cmljdGlvbiBvbiB0aGUgZmlyc3QgZm91ciBiaXRzIG9m IGFueXRoaW5nIHRoYXQgY2FuIGJlIGRpcmVjdGx5IGVuY2Fwc3VsYXRlZCBpbiBNUExTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5PdGhlcndpc2UsIGRlc2lnbmluZyAoZm9yIGV4YW1wbGUpIGEgdmVyc2lvbiBmaWVsZCBm b3Igd2hpY2ggSUFOQSB3aWxsIGhhdmUgdG8gcHVuY2ggaG9sZXMgaW4gdGhlIGFzc2lnbm1lbnQg cmFuZ2UgZG9lcyBub3Qgc2VlbSBsaWtlIGEgZ29vZCBpZGVhLiBBbmQgSeKAmXZlDQogbm90IGJl ZW4gYWJsZSB0byBjb252aW5jZSBteXNlbGYgdGhhdCB0aGlzIHJlcXVpcmVtZW50IGhhcyBjb21w bGV0ZWx5IGdvbmUgYXdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBC SUVSIFttYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5U b255IFByenlnaWVuZGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA5LCAyMDE1 IDExOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBBbGlhIEF0bGFzPGJyPg0KPGI+Q2M6PC9iPiBtcGxz QGlldGYub3JnOyBCSUVSOyBzZmNAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IEVyaWsgTm9yZG1h cms7IFh1eGlhb2h1PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQmllcl0gW3NmY10gW252bzNd IEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHdvdWxkIHZlbnR1cmUgdG8gc2F5IHRoYXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QklFUiBtaXNvcmRl cmluZyB3b3VsZCBiZSBhIGJhZCB0aGluZyBmb3IgbWFueSBhcHBsaWNhdGlvbnMgYnV0IEkgZG8g bm90IHRoaW5rIHRoYXQgdGhlIGVuY2Fwc3VsYXRpb24gcGVyIHNlIG1pc29yZGVycyBvciBub3Qg YXMgcHJvcGVydHksIGl04oCZcyB0aGUgd2F5IHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycw0KIGFy ZSBhbGxvd2VkIHRvIHBsYXkgc2hhbm5pZ2FucyAob3Igc2VlbiBkaWZmZXJlbnRseSwg4oCYaGV1 cmlzdGljYWxseeKAmSBjb21lIHVwIHdpdGggdGhpbmdzIGdpdmVuIHVuY2xlYXIgc2VtYW50aWNz IG9mIHRoZSBlbmNhcHMpIHRoYXQgY2F1c2VzIG1pc29yZGVyaW5nLiBTbyBpdCBpcyB1cCB0byB0 aGUgZW5jYXBzIHRvIGdpdmUgZW5vdWdoIGluZm8gc28gdGhlIHJvdXRlcnMgaW4gdGhlIG1pZGRs ZSBkbyB0aGUg4oCYcmlnaHQgdGhpbmfigJkuIE1vZHVsbw0KIGhpc3RvcmljYWwgcHJvYmxlbXMg d2l0aCBDVyBzdXBwb3J0IGFuZCBzbyBvbiDigKYgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5iLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGZsYXZv ciBvZiBkaXNjdXNzaW9uIGlzIHJlcGVhdGluZywgZS5nLiBlVlBOIFJGQyB3aXRoIHRoZSBDVy9u byBDVyBkZWJhdGUgd2hpY2ggSSBjb3VsZCByZXN0b3JlIG9ubHkgcGFydGlhbGx5IGFuZCBvdGhl ciBncm91cHMgbm93IOKApg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIGxlbW1lIHN0aWNrIG15IChuYcOv dmUgOy0pIGhlYWQgZmFyIG91dDogd2h5IGRvIGVuY2FwcyBndWlkZWxpbmVzIGZvciBldmVyeXRo aW5nIHRoYXQgY2FuIGdvIG92ZXINCiBQU04gbm90IG1hbmRhdGUgQ1cgZnJvbSBub3cgb24/IEV4 aXN0aW5nIGdlYXIgYW5kIGhpc3RvcmljYWwgUkZDcyBzdXBwb3J0ZWQgdW50aWwgdGhleSBwZXRl ciBvdXQgYW5kIGVudHJvcHkgbGFiZWxzIGJlaW5nIGFuIG9ydGhvZ29uYWwgbWVjaGFuaXNtIOKA piAmbmJzcDtPciBkbyB3ZSB0aGluayB0aGUg4oCYaGV1cmlzdGljYWwgRFBJJyBpcyBhIGJvdHRv bWxlc3MgYm94IG9mIGJhbmQtYWlkcyA/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS0gdG9ueSZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgQXByIDksIDIwMTUgYXQgMTE6MDEgQU0sIEFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpha2F0bGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFrYXRsYXNAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA5LCAyMDE1IGF0IDE6NTAgUE0sIEVyaWsgTm9yZG1h cmsgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JkbWFya0BhY20ub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bm9yZG1hcmtAYWNtLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gNC84LzE1IDc6MjAgUE0sIFh1eGlhb2h1IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I aSBFcmlrLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkgY291bGRu J3QgdGVsbCBmcm9tIHRoZSBlbWFpbHMgb24gdGhlIEJJRVIgbGlzdCB3aGV0aGVyIHRoZSBjb25z dHJhaW50cyBvbiB0aGUgZmlyc3QgbmliYmxlIHZhbHVlIGlzIGEgc3RyaWN0IHJlcXVpcmVtZW50 IGluIGFsbCBjYXNlcywgb3Igd2hldGhlciBpdCBpcyBjb25kaXRpb25hbCBvbiBzb21ldGhpbmcg KGFuZCBpZiBzbywgd2hhdCBpcyB0aGUgY29uZGl0aW9uKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBvZiBp bmNsdWRlOiAxKSB0aGUgZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFja2V0IG1pc29y ZGVyaW5nOyAyKSB0aGUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhbiBN UExTIFBTTjsgMykgTFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250ZW50 cyBvZiB0aGUgTVBMUyBwYXlsb2FkIHRvIHNlbGVjdA0KIHRoZSBFQ01QIHBhdGguPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9zZSBhcmUgY29uZGl0aW9ucyB3aGVuIHRo ZSBtaXNvcmRlcmluZyB3b3VsZCBoYXBwZW4uIEJ1dCBhcmUgeW91IHNheWluZyB0aGF0IGFueSBM U1IgaXMgZnJlZSB0byB1c2UgdGhlIE1QTFMgcGF5bG9hZCAoaW5jbHVkaW5nIGxvb2tpbmcgZm9y IDQgYW5kIDYgaW4gdGhlIGZpcnN0IG5pYmJsZSkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIHBh Y2tldCBpcyBJUHY0IGFuZCBJUHY2IGFuZCB1c2Ugd2hhdCBpdA0KIHRoaW5rcyBhcmUgSVB2NCBh bmQgSVB2NiBmaWVsZHMgZm9yIEVDTVAgcHVycG9zZXM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYWtlIGEgcXVpY2sgbG9vayBhdCBSRkMgNDM4NSAtIHdo aWNoIGlzIHRoZSBjb250cm9sIHdvcmQgZm9yIHBzZXVkby13aXJlcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzaG9ydCBmb3JtIGlzIHRo YXQgYSBudW1iZXIgb2Ygcm91dGVycyBhdCB0aGUgdGltZSBwZWVrZWQgYmVuZWF0aCB0aGUgbGFi ZWwgc3RhY2sgdG8gZmlndXJlIG91dCB3aGV0aGVyIHdoYXQgd2FzIGluc2lkZSBhcyBJUHY0IG9y IElQdjYgYmFzZWQgc29sZWx5IHVwb24gdGhlIGZpcnN0IG5pYmJsZS4mbmJzcDsgQSByZWNvbW1l bmRhdGlvbiB3YXMgbWFkZSB0aGF0IHRoZSBjaGVja3N1bSBzaG91bGQgYWxzbyBiZQ0KIHZlcmlm aWVkLCBidXQgdGhlIG9ubHkgZXF1aXBtZW50IHRoYXQgSSdtIGNlcnRhaW4gb2YgdGhhdCBkaWQg dGhhdCBpc24ndCBhcm91bmQgYW55bW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBsb29rIGF0IFNlY3Rpb24gMi40IG9mIFJGQyA3 MzI1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbGlhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NClRoYW5rcyw8YnI+DQombmJzcDsgJm5ic3A7RXJpazxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KWGlhb2h1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uY2UgSSBrbm93IHRoYXQg YW5zd2VyIHdlIGNhbiBkZWZpbml0ZWx5IGFkZCBzb21lIHRleHQgcG9pbnRpbmcgb3V0IHRoZSBp c3N1ZS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtFcmlrPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogRXJpayBO b3JkbWFyayBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpub3JkbWFya0Bzb25pYy5uZXQiIHRhcmdl dD0iX2JsYW5rIj5ub3JkbWFya0Bzb25pYy5uZXQ8L2E+XTxicj4NClNlbnQ6IDIwMTU8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+MzxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4yNjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwvc3Bhbj4g NTowMTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24g Y29uc2lkZXJhdGlvbnM8YnI+DQo8YnI+DQo8YnI+DQpJIHByZXNlbnRlZCBwYXJ0IG9mIHRoaXMg YXQgdGhlIG1vc3QgcmVjZW50IE5WTzMgaW50ZXJpbSBtZWV0aW5nLlRoZTxicj4NCmZ1bGw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEyPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hcmVhcyBvZiBjb25zaWRlcmF0aW9ucyB3aGVyZSBwcmVzZW50ZWQg YXQgUlRHV0cgZWFybGllciB0aGlzIHdlZWsuPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgZHJhZnQg aXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJ0Zy1kdC1lbmNhcC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnRnLWR0LWVuY2FwLzwvYT48YnI+DQom bmJzcDsgJm5ic3A7IGFuZCB0aGUgc2xpZGVzIGFyZSBhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xp ZGVzLTkyLXJ0Z3dnLTgucGRmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgucGRmPC9hPjxicj4NCjxicj4N ClRoZXJlIGlzIHByb2JhYmx5IGFkZGl0aW9uYWwgdGhpbmdzIGluIHRoZXJlIHRvIGNvbnNpZGVy IGZvciBOVk8zLDxicj4NCmFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YWR2aWNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPnRoYXQgY2FuIGJlIHJldXNlZCB0byBtYWtlIGl0IGVhc2llciB0byBt b3ZlIE5WTzMgZm9yd2FyZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IEVyaWs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpudm8zIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpudm8zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZvM0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL252bzM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+c2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpCSUVSIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIj5CSUVSQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllciIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllcjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_-- From nobody Thu Apr 9 11:58:59 2015 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 ECDD31B3020; Thu, 9 Apr 2015 10:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 AH5XSFAWdHxY; Thu, 9 Apr 2015 10:50:32 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA611B3005; Thu, 9 Apr 2015 10:50:27 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t39HoKJ0005206 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Apr 2015 10:50:20 -0700 Message-ID: <5526BBDB.3000805@acm.org> Date: Thu, 09 Apr 2015 10:50:19 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Xuxiaohu , Erik Nordmark , "nvo3@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVb/0+50Af8ZeMxdOuGDh90O3udgK4gFmlhDa5vfLYq3/CwN4RBN8w9VNu10S5+W3FNLONgEZ1dE/+SLyN4FvlPl X-Sonic-ID: C;RMWo4+De5BGN6tBwQIsAyQ== M;4mnA4+De5BGN6tBwQIsAyQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 11:58:57 -0700 Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [mpls] [nvo3] Encapsulation considerations 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, 09 Apr 2015 17:50:37 -0000 On 4/8/15 7:20 PM, Xuxiaohu wrote: > Hi Erik, > >> But I couldn't tell from the emails on the BIER list whether the >> constraints on the first nibble value is a strict requirement in all >> cases, or whether it is conditional on something (and if so, what is >> the condition). > The conditions that I have thought of include: 1) the encapsulation is sensitive to packet misordering; 2) the encapsulation may be transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS payload to select the ECMP path. Those are conditions when the misordering would happen. But are you saying that any LSR is free to use the MPLS payload (including looking for 4 and 6 in the first nibble) to determine whether the packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes? Thanks, Erik > > Best regards, > Xiaohu > >> Once I know that answer we can definitely add some text pointing out the issue. >> >> Thanks, >> Erik >> >>> Best regards, >>> Xiaohu >>> >>>> -----Original Message----- >>>> From: Erik Nordmark [mailto:nordmark@sonic.net] >>>> Sent: 2015年3月26日 5:01 >>>> To: nvo3@ietf.org >>>> Subject: [nvo3] Encapsulation considerations >>>> >>>> >>>> I presented part of this at the most recent NVO3 interim meeting.The >>>> full >>> 12 >>>> areas of considerations where presented at RTGWG earlier this week. >>>> The draft is >>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ >>>> and the slides are at >>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>> >>>> There is probably additional things in there to consider for NVO3, >>>> and >>> advice >>>> that can be reused to make it easier to move NVO3 forward. >>>> >>>> Regards, >>>> Erik >>>> >>>> >>>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> > From nobody Thu Apr 9 11:59:01 2015 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 3DFF21B3095; Thu, 9 Apr 2015 11:17:49 -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 4YHLhlfslwPw; Thu, 9 Apr 2015 11:17:46 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A0B1A898C; Thu, 9 Apr 2015 11:17:43 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so121483270ied.1; Thu, 09 Apr 2015 11:17:42 -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=ep1PYuLdHD4McTHckhL6SXQnJuOuosi1r9kMflJgwiE=; b=L18Q37asqH3AhFeg3sKzSY20q7KKjqmetk3m7PTu+e1LTUU3ueF6msVsxFjC7GJD/b +fLXsVbQPzab4oWB2crvSMb38tT9ClkcyMLPhZAS21lcTvsk0uZ4SqQuYykBfEeIGrPE kQmDwVDzFkvL/FWhHUcKxNrwmcGR2sQKAOjmtgQnyK6JHhGQpgkQEC03ErT+GBrI1Apr xKawyzWPnlDY76XSS2nNrodnILLatjc/KynlnJWMQm66wbQAGvEaJ1rVNKNzb6pSArAe NrqoLXLzB74Ly9ixpb8hUeQ0/qAueCS61AKJ6zgdPSOGIGcCIUUQPxQ8v3sAesSsOT8z TAfw== MIME-Version: 1.0 X-Received: by 10.50.93.69 with SMTP id cs5mr22608983igb.4.1428603462778; Thu, 09 Apr 2015 11:17:42 -0700 (PDT) Received: by 10.107.52.21 with HTTP; Thu, 9 Apr 2015 11:17:42 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> Date: Thu, 9 Apr 2015 11:17:42 -0700 Message-ID: From: Tony Przygienda To: Alia Atlas Content-Type: multipart/alternative; boundary=089e01537ed8ec84a605134ea9e0 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 11:58:57 -0700 Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" , "nvo3@ietf.org" , Erik Nordmark Subject: Re: [mpls] [Bier] [sfc] [nvo3] Encapsulation considerations 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, 09 Apr 2015 18:17:49 -0000 --089e01537ed8ec84a605134ea9e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would venture to say that a. BIER misordering would be a bad thing for many applications but I do not think that the encapsulation per se misorders or not as property, it=E2=80=99s the way the intermediate routers are allowed to play shannigan= s (or seen differently, =E2=80=98heuristically=E2=80=99 come up with things given= unclear semantics of the encaps) that causes misordering. So it is up to the encaps to give enough info so the routers in the middle do the =E2=80=98right thin= g=E2=80=99. Modulo historical problems with CW support and so on =E2=80=A6 b. This flavor of discussion is repeating, e.g. eVPN RFC with the CW/no CW debate which I could restore only partially and other groups now = =E2=80=A6 OK, lemme stick my (na=C3=AFve ;-) head far out: why do encaps guidelines f= or everything that can go over PSN not mandate CW from now on? Existing gear and historical RFCs supported until they peter out and entropy labels being an orthogonal mechanism =E2=80=A6 Or do we think the =E2=80=98heuristical = DPI' is a bottomless box of band-aids ? --- tony On Thu, Apr 9, 2015 at 11:01 AM, Alia Atlas wrote: > On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark wrote: > >> On 4/8/15 7:20 PM, Xuxiaohu wrote: >> >>> Hi Erik, >>> >>> But I couldn't tell from the emails on the BIER list whether the >>>> constraints on the first nibble value is a strict requirement in all c= ases, >>>> or whether it is conditional on something (and if so, what is the >>>> condition). >>>> >>> The conditions that I have thought of include: 1) the encapsulation is >>> sensitive to packet misordering; 2) the encapsulation may be transporte= d >>> over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of = the >>> MPLS payload to select the ECMP path. >>> >> Those are conditions when the misordering would happen. But are you >> saying that any LSR is free to use the MPLS payload (including looking f= or >> 4 and 6 in the first nibble) to determine whether the packet is IPv4 and >> IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes? > > > Take a quick look at RFC 4385 - which is the control word for pseudo-wire= s. > The short form is that a number of routers at the time peeked beneath the > label stack to figure out whether what was inside as IPv4 or IPv6 based > solely upon the first nibble. A recommendation was made that the checksu= m > should also be verified, but the only equipment that I'm certain of that > did that isn't around anymore. > > Also look at Section 2.4 of RFC 7325. > > Alia > > >> >> Thanks, >> Erik >> >> >>> Best regards, >>> Xiaohu >>> >>> Once I know that answer we can definitely add some text pointing out >>>> the issue. >>>> >>>> Thanks, >>>> Erik >>>> >>>> Best regards, >>>>> Xiaohu >>>>> >>>>> -----Original Message----- >>>>>> From: Erik Nordmark [mailto:nordmark@sonic.net] >>>>>> Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01 >>>>>> To: nvo3@ietf.org >>>>>> Subject: [nvo3] Encapsulation considerations >>>>>> >>>>>> >>>>>> I presented part of this at the most recent NVO3 interim meeting.The >>>>>> full >>>>>> >>>>> 12 >>>>> >>>>>> areas of considerations where presented at RTGWG earlier this week. >>>>>> The draft is >>>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ >>>>>> and the slides are at >>>>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>>>> >>>>>> There is probably additional things in there to consider for NVO3, >>>>>> and >>>>>> >>>>> advice >>>>> >>>>>> that can be reused to make it easier to move NVO3 forward. >>>>>> >>>>>> Regards, >>>>>> Erik >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> >>>>> >>> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > --089e01537ed8ec84a605134ea9e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would venture to say that=

a.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 BIER misordering would be a bad thing for many applications but I do not think t= hat the encapsulation per se misorders or not as property, it=E2=80=99s the way= the intermediate routers are allowed to play shannigans (or seen differently, =E2=80=98heuri= stically=E2=80=99 come up with things given unclear semantics of the encaps) that causes misordering. So it is up to the encaps to give enough info so the routers i= n the middle do the =E2=80=98right thing=E2=80=99. Modulo historical problems wit= h CW support and so on =E2=80=A6

b.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 This flavor of discussion is repeating, e.g. eVPN RFC with the CW/no CW debate which I cou= ld restore only partially and other groups now =E2=80=A6

=C2=A0

OK, lemme stick my (na=C3=AFve ;-) head far = out: why do encaps guidelines for everything that can go over PSN not mandate CW from now on? Existing gear a= nd historical RFCs supported until they peter out and entropy labels being an = orthogonal mechanism =E2=80=A6 =C2=A0Or do we think the =E2=80=98heuristica= l DPI' is a bottomless box of band-aids ?

=C2=A0

--- tony=C2=A0


On Thu, Apr 9, 2015 at 11:01 A= M, Alia Atlas <akatlas@gmail.com> wrote:
On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <= span dir=3D"ltr"><= nordmark@acm.org> wrote:
On 4/8/15 7:20 PM, Xuxiaohu wrote:
Hi Erik,

But I couldn't tell from the emails on the BIER list whether the constr= aints on the first nibble value is a strict requirement in all cases, or wh= ether it is conditional on something (and if so, what is the condition).
The conditions that I have thought of include: 1) the encapsulation is sens= itive to packet misordering; 2) the encapsulation may be transported over a= n MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS p= ayload to select the ECMP path.
Those are conditions when the misordering would happen. But are you saying = that any LSR is free to use the MPLS payload (including looking for 4 and 6= in the first nibble) to determine whether the packet is IPv4 and IPv6 and = use what it thinks are IPv4 and IPv6 fields for ECMP purposes?
=

Take a quick look at RFC 4385 - which is the con= trol word for pseudo-wires.
The short form is that a number of ro= uters at the time peeked beneath the label stack to figure out whether what= was inside as IPv4 or IPv6 based solely upon the first nibble.=C2=A0 A rec= ommendation was made that the checksum should also be verified, but the onl= y equipment that I'm certain of that did that isn't around anymore.=

Also look at Section 2.4 of RFC 7325.
<= br>
Alia
=C2=A0

Thanks,
=C2=A0 =C2=A0Erik


Best regards,
Xiaohu

Once I know that answer we can definitely add some text pointing out the is= sue.

Thanks,
=C2=A0 =C2=A0 =C2=A0Erik

Best regards,
Xiaohu

-----Original Message-----
From: Erik Nordmark [mailto:nordmark@sonic.net]
Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01
To: nvo3@ietf.org Subject: [nvo3] Encapsulation considerations


I presented part of this at the most recent NVO3 interim meeting.The
full
12
areas of considerations where presented at RTGWG earlier this week.
=C2=A0 =C2=A0 The draft is
=C2=A0 =C2=A0 =C2=A0 http://datatracker.ietf.org/doc/draft-rt= g-dt-encap/
=C2=A0 =C2=A0 and the slides are at
=C2=A0 =C2=A0 =C2=A0http://www.ietf.org/proceedin= gs/92/slides/slides-92-rtgwg-8.pdf

There is probably additional things in there to consider for NVO3,
and
advice
that can be reused to make it easier to move NVO3 forward.

Regards,
=C2=A0 =C2=A0 =C2=A0 Erik



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



_______________________________________________


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


--089e01537ed8ec84a605134ea9e0-- From nobody Thu Apr 9 12:05:29 2015 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 D62291A89A0; Thu, 9 Apr 2015 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 1u-0_qITMbQi; Thu, 9 Apr 2015 12:05:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 436BB1A89B5; Thu, 9 Apr 2015 12:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409190525.32752.53396.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 12:05:25 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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, 09 Apr 2015 19:05:28 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registry/ From nobody Thu Apr 9 12:32:19 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A59821B3102; Thu, 9 Apr 2015 12:32:17 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843BB1B30F5 for ; Thu, 9 Apr 2015 12:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 BubpDIb1KMX7 for ; Thu, 9 Apr 2015 12:32:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2EF1B30FB for ; Thu, 9 Apr 2015 12:32:11 -0700 (PDT) Received: from alln-iport-2.cisco.com ([173.37.142.89]:43298) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgIBO-0004pF-55 for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Thu, 09 Apr 2015 12:32:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1428607930; x=1429817530; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=The4eRGCXKmjPNtswA9SHdZVSBc/gBxbGacqOy92lIQ=; b=Hsx+HpUkgKNfGYEqN2ikXDFlP0o78m0+zjP5IWiy9XI+SKjoQkyAdcoA //tGdQ8ymZuT7t6sImOtFAbkmlG3q3SntGUNrDUT7TRj/8faYf+v5oWfH XlJ7eLBW3v9VB4MziZRlF9zoZRlXjMZdHt7QhC5rTg/Jt6NZJm845KZY3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AWBQBM0iZV/40NJK1cgwhSVwUFxEYJgVOGAQKBRzgUAQEBAQEBAX2EIAIEOj8SAQg2BT0lAgQOBQmIIQgFzlEBAQEBAQEBAQIBAQEBAQEBAQEZiyuBPYM/B4QtBY5rghaKC4EdgzeHD4F6UQaCY4NLIoIQI4E8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="139816440" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 09 Apr 2015 19:32:01 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t39JW0hH030531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 19:32:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 14:32:00 -0500 From: "George Swallow (swallow)" To: "drafts-approval@iana.org" Thread-Topic: [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) Thread-Index: AQHQclPf7TlV22YwkUeC9dZHZlXeyJ1FI8sA Date: Thu, 9 Apr 2015 19:32:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.131.118.57] Content-Type: text/plain; charset="us-ascii" Content-ID: <309839FFBF3A6643B2A42F9A3E48C1FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 173.37.142.89 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: swallow@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150409193211.AA2EF1B30FB@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 12:32:11 -0700 (PDT) Resent-From: swallow@cisco.com Archived-At: Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 09 Apr 2015 19:32:17 -0000 Amanda - These look fine to me. Thanks! George On 4/8/15 7:29 PM, "Amanda Baber via RT" wrote: >Dear Authors: > >ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > >We've completed the IANA Actions for the following RFC-to-be: > >draft-ietf-mpls-proxy-lsp-ping-05 > >NOTE: The following have been converted to lower case: "could" in TBA-9; >"marked" in the notes attached to the registration procedures for the >Downstream Mapping and Next Hop registries. > >QUESTION: The existing sub-TLV registries list notes for each >registration range. The new sub-TLV registry for Proxy Echo Parameters >doesn't, because I couldn't find a source for those notes in RFC 4379. > >Should those notes ("This range is for mandatory TLVs or for optional >TLVs that require an error message if not recognized," etc.) be included >in this registry's registration procedures? If so, are these included or >implied in RFC 4379? If there isn't a source for them in RFC 4379, >they'll have to be spelled out in this document's IANA Considerations >section.=20 > >ACTION 1: > >IANA has registered the following Message Types: > >3 MPLS Proxy Ping Request [RFC-ietf-mpls-proxy-lsp-ping-05] >4 MPLS Proxy Ping Reply [RFC-ietf-mpls-proxy-lsp-ping-05] > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > > >ACTION 2: > >IANA has registered the following TLVs: > >23 Proxy Echo=20 >Parameters [RFC-ietf-mpls-proxy-lsp-ping-05] [http://www.iana.org/assignme >nts/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-23] >24 Reply-to Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs >25 Upstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs >26 Downstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No >Sub-TLVs > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > > >ACTION 3: > >IANA has registered the following Return Codes: > >16 Proxy Ping not authorized. [RFC-ietf-mpls-proxy-lsp-ping-05] >17 Proxy Ping parameters need to be >modified. [RFC-ietf-mpls-proxy-lsp-ping-05] >18 MPLS Echo Request could not be sent. [RFC-ietf-mpls-proxy-lsp-ping-05] >19 Replying router has FEC mapping for topmost >FEC. [RFC-ietf-mpls-proxy-lsp-ping-05] > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > > >ACTION 4: > >IANA has created the following registry: > >Sub-TLVs for TLV Type 23 >Reference >[RFC4379][RFC-ietf-mpls-proxy-lsp-ping-05] > >Range Registration Procedures >0-16383 Standards Action >16384-31743 Specification Required >32768-49161 Standards Action >49162-64511 Specification Required > >Sub-Type Sub-TLV Name Reference Comment >0 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05]=09 >1 Next Hop [RFC-ietf-mpls-proxy-lsp-ping-05]=09 >2-64511 Unassigned =09 >64512-65535 Reserved for Vendor or Private Use [RFC4379] > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > > >ACTION 5: > >IANA has made this document an additional reference for the Downstream >Mapping Address Type Registry, added the note "Each time a code point is >assigned from this registry, unless the same registration is made in >both registries, the corresponding Next Hop Address Type Registry must >be marked "Reserved" to the top of the registry, and added the following >registrations: > >6 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >7 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > > >ACTION 6: > >IANA has created the following registry: > >Next Hop Address Type Registry >Registration Procedure(s): Standards Action >Reference: [RFC-ietf-mpls-proxy-lsp-ping-05] >Note: Each time a code point is assigned from this registry, unless the >same registration is made in both registries, the corresponding >Downstream Address Mapping Registry must be marked "Reserved." > >Type Type of Next Hop Address Length IF Length Reference >0 Unassigned =09 >1 IPv4 Numbered 4 4 [RFC4379] >2 IPv4 Unnumbered 4 4 [RFC4379] >3 IPv6 Numbered 16 16 [RFC4379] >4 IPv6 Unnumbered 16 4 [RFC4379] >5 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >6 IPv4 Protocol Adj 4 0 [RFC-ietf-mpls-proxy-lsp-ping-05] >7 IPv6 Protocol Adj 16 0 [RFC-ietf-mpls-proxy-lsp-ping-05] >8-255 Unassigned > >Please see >http://www.iana.org/assignments/mpls-lsp-ping-parameters > > >The updated list of Protocol Registries is available here: >=20 >http://www.iana.org/protocols > >Please let us know whether the above IANA Actions look OK. As soon as we >receive your confirmation, we'll notify the RFC Editor that this >document's IANA Actions are complete. (If this document has a team of >authors, one reply on behalf of everyone will suffice.) > >We'll update the reference when the RFC Editor notifies us that they've >assigned a number. > >Thanks, > >Amanda Baber >IANA Request Specialist >ICANN > From nobody Thu Apr 9 15:51:03 2015 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 DB3641B3541; Thu, 9 Apr 2015 15:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 I-CY_1sqUw5x; Thu, 9 Apr 2015 15:50:33 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id BDF451B3534; Thu, 9 Apr 2015 15:50:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,552,1422950400"; d="scan'208";a="61710338" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 09 Apr 2015 15:55:35 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 9 Apr 2015 15:50:33 -0700 Received: from SJEXCHMB06.corp.ad.broadcom.com ([fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 9 Apr 2015 15:50:32 -0700 From: Ian Cox To: Erik Nordmark , Xuxiaohu , "nvo3@ietf.org" Thread-Topic: [Bier] [nvo3] Encapsulation considerations Thread-Index: AQHQclja5X+vlmoZrkq2Qyp/IFKZP51EaByAgAED1ID//9vF8A== Date: Thu, 9 Apr 2015 22:50:31 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> In-Reply-To: <5526BBDB.3000805@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [mpls] [Bier] [nvo3] Encapsulation considerations 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, 09 Apr 2015 22:50:38 -0000 TVBMUyBoYXMgbm8gaW5kaWNhdGlvbiBpbiB0aGUgbGFiZWwgc3RhY2sgZm9yIGludGVybWVkaWF0 ZSBub2RlcyB3aGF0IHRoZSB1bmRlcmx5aW5nIHBheWxvYWQgaXMuICBUbyBhY2hpZXZlIGJldHRl ciBsb2FkIGJhbGFuY2luZyBvZiBNUExTIHRyYWZmaWMgbW9zdCBoYXJkd2FyZSB0b2RheSBsb29r cyB0byBzZWUgaWYgdGhlIGZpcnN0IG5pYmJsZSBpcyA0IG9yIDYgdGhlbiBwYXJzZSBpbnRvIHRo ZSBwYXlsb2FkIHVuZGVyIHRoZSBiZWxpZWYgdGhhdCBpdCBpcyBhIElQdjQgb3IgdjYgcGFja2V0 IGFuZCBwYXJzZSB0aGUgYWRkcmVzcyBmaWVsZHMgb3V0IHRvIHVzZSBpbiB0aGUgRUNNUCBoYXNo LiAgSWYgeW91ciBkZWZpbmluZyBzb21ldGhpbmcgbmV3IHBsZWFzZSBwdXQgYSAibmV4dCBwcm90 b2NvbCIgb3IgdHlwZSBmaWVsZCBpbiB0aGUgcHJlY2VkaW5nIGhlYWRlciBzbyBpdCBjbGVhciB3 aGF0IHRoZSBuZXh0IHByb3RvY29sIGlzLiAgVGhlIDQgb3IgNiBndWVzcyBmb3IgdGhlIHVuZGVy bHlpbmcgTVBMUyBwYXlsb2FkIGJlaW5nIGFuIElQIHBhY2tldCB3YXMgZmluZSB1bnRpbCBJRUVF IGFsbG9jYXRlZCBNQUMgYWRkcmVzc2VzIHN0YXJ0aW5nIHdpdGggNi4gVGhpcyBpc3N1ZSBpcyBz cGVjaWZpYyBQV0UzIHBhY2tldHMgdGhhdCBkbyBub3QgY29udGFpbiB0aGUgY29udHJvbCB3b3Jk Lg0KDQoNCklhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQklFUiBbbWFp bHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWsgTm9yZG1hcmsNClNl bnQ6IFRodXJzZGF5LCBBcHJpbCAwOSwgMjAxNSAxMDo1MCBBTQ0KVG86IFh1eGlhb2h1OyBFcmlr IE5vcmRtYXJrOyBudm8zQGlldGYub3JnDQpDYzogbXBsc0BpZXRmLm9yZzsgQklFUjsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW0JpZXJdIFtudm8zXSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVy YXRpb25zDQoNCk9uIDQvOC8xNSA3OjIwIFBNLCBYdXhpYW9odSB3cm90ZToNCj4gSGkgRXJpaywN Cj4NCj4+IEJ1dCBJIGNvdWxkbid0IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxp c3Qgd2hldGhlciB0aGUgDQo+PiBjb25zdHJhaW50cyBvbiB0aGUgZmlyc3QgbmliYmxlIHZhbHVl IGlzIGEgc3RyaWN0IHJlcXVpcmVtZW50IGluIGFsbCANCj4+IGNhc2VzLCBvciB3aGV0aGVyIGl0 IGlzIGNvbmRpdGlvbmFsIG9uIHNvbWV0aGluZyAoYW5kIGlmIHNvLCB3aGF0IGlzIA0KPj4gdGhl IGNvbmRpdGlvbikuIA0KPiBUaGUgY29uZGl0aW9ucyB0aGF0IEkgaGF2ZSB0aG91Z2h0IG9mIGlu Y2x1ZGU6IDEpIHRoZSBlbmNhcHN1bGF0aW9uIGlzIHNlbnNpdGl2ZSB0byBwYWNrZXQgbWlzb3Jk ZXJpbmc7IDIpIHRoZSBlbmNhcHN1bGF0aW9uIG1heSBiZSB0cmFuc3BvcnRlZCBvdmVyIGFuIE1Q TFMgUFNOOyAzKSBMU1JzIHdpdGhpbiB0aGF0IE1QTFMgUFNOIG1heSB1c2UgdGhlIGNvbnRlbnRz IG9mIHRoZSBNUExTIHBheWxvYWQgdG8gc2VsZWN0IHRoZSBFQ01QIHBhdGguDQpUaG9zZSBhcmUg Y29uZGl0aW9ucyB3aGVuIHRoZSBtaXNvcmRlcmluZyB3b3VsZCBoYXBwZW4uIEJ1dCBhcmUgeW91 IA0Kc2F5aW5nIHRoYXQgYW55IExTUiBpcyBmcmVlIHRvIHVzZSB0aGUgTVBMUyBwYXlsb2FkIChp bmNsdWRpbmcgbG9va2luZyANCmZvciA0IGFuZCA2IGluIHRoZSBmaXJzdCBuaWJibGUpIHRvIGRl dGVybWluZSB3aGV0aGVyIHRoZSBwYWNrZXQgaXMgSVB2NCANCmFuZCBJUHY2IGFuZCB1c2Ugd2hh dCBpdCB0aGlua3MgYXJlIElQdjQgYW5kIElQdjYgZmllbGRzIGZvciBFQ01QIHB1cnBvc2VzPw0K DQpUaGFua3MsDQogICAgRXJpaw0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+ PiBPbmNlIEkga25vdyB0aGF0IGFuc3dlciB3ZSBjYW4gZGVmaW5pdGVseSBhZGQgc29tZSB0ZXh0 IHBvaW50aW5nIG91dCB0aGUgaXNzdWUuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gICAgICBFcmlrDQo+ Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBYaWFvaHUNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86bm9yZG1hcmtA c29uaWMubmV0XQ0KPj4+PiBTZW50OiAyMDE15bm0M+aciDI25pelIDU6MDENCj4+Pj4gVG86IG52 bzNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJh dGlvbnMNCj4+Pj4NCj4+Pj4NCj4+Pj4gSSBwcmVzZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBt b3N0IHJlY2VudCBOVk8zIGludGVyaW0gbWVldGluZy5UaGUNCj4+Pj4gZnVsbA0KPj4+IDEyDQo+ Pj4+IGFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdoZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJs aWVyIHRoaXMgd2Vlay4NCj4+Pj4gICAgIFRoZSBkcmFmdCBpcw0KPj4+PiAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJ0Zy1kdC1lbmNhcC8NCj4+Pj4gICAgIGFu ZCB0aGUgc2xpZGVzIGFyZSBhdA0KPj4+PiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1ydGd3Zy04LnBkZg0KPj4+Pg0KPj4+PiBUaGVyZSBp cyBwcm9iYWJseSBhZGRpdGlvbmFsIHRoaW5ncyBpbiB0aGVyZSB0byBjb25zaWRlciBmb3IgTlZP MywNCj4+Pj4gYW5kDQo+Pj4gYWR2aWNlDQo+Pj4+IHRoYXQgY2FuIGJlIHJldXNlZCB0byBtYWtl IGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2FyZC4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+ Pj4gICAgICAgRXJpaw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+PiBu dm8zQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u dm8zDQo+Pj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCg== From nobody Thu Apr 9 18:09:40 2015 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 9679B1A1BE5; Thu, 9 Apr 2015 18:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FStXIuYAJYTk; Thu, 9 Apr 2015 18:09: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 C738B1A1BCA; Thu, 9 Apr 2015 18:09:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUR33768; Fri, 10 Apr 2015 01:09:33 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 02:09:32 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 09:09:26 +0800 From: Xuxiaohu To: RFC Errata System , "erosen@cisco.com" , "arun@force10networks.com" , "rcallon@juniper.net" , "akatlas@gmail.com" , "db3546@att.com" , "aretana@cisco.com" , "loa@pi.nu" , "swallow@cisco.com" , "rcallon@juniper.net" Thread-Topic: [mpls] [Technical Errata Reported] RFC3031 (4331) Thread-Index: AQHQcslkHnHPDdm1xEmy7aOfjPjEz51FaPvw Date: Fri, 10 Apr 2015 01:09:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083246AE@NKGEML512-MBS.china.huawei.com> References: <20150409132948.D630A180092@rfc-editor.org> In-Reply-To: <20150409132948.D630A180092@rfc-editor.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rshearma@brocade.com" , spring Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (4331) 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, 10 Apr 2015 01:09:38 -0000 Hi all, It seems that interpretation 4 would become more common in MPLS-SPRING (i.e= ., segment routing) networks where OSPF or ISIS is used as a label distribu= tion protocol and partial routers are still legacy routers (e.g. pure IP ro= uter). In this case, it seems feasible to allow the LSR to replace the top = label by an IP-based tunnel header and then forward the packet further via = conventional IP forwarding. The tunnel destination is the /32 or /128 FEC p= refix corresponding to that top label. For more details about this usage, p= lease refer to https://tools.ietf.org/html/draft-xu-spring-islands-connecti= on-over-ip-04. This usage is valuable both in the incremental deployment ca= se where partial routers have not yet be upgraded to support MPLS-SPRING an= d in some specific cases where it's unnecessary to make all routers to be M= PLS-SPRING-capable (e.g., in the dual-plane TE scenario where only the edge= routers of each plane need to be MPLS-SPRING-capable). Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of RFC Errata System > Sent: Thursday, April 09, 2015 9:30 PM > To: erosen@cisco.com; arun@force10networks.com; rcallon@juniper.net; > akatlas@gmail.com; db3546@att.com; aretana@cisco.com; loa@pi.nu; > swallow@cisco.com; rcallon@juniper.net > Cc: mpls@ietf.org; rshearma@brocade.com; rfc-editor@rfc-editor.org > Subject: [mpls] [Technical Errata Reported] RFC3031 (4331) >=20 > The following errata report has been submitted for RFC3031, "Multiprotoco= l > Label Switching Architecture". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3031&eid=3D4331 >=20 > -------------------------------------- > Type: Technical > Reported by: Robert Shearman >=20 > Section: 3.22 >=20 > Original Text > ------------- > When a labeled packet is traveling along an LSP, it may occasionally happ= en that > it reaches an LSR at which the ILM does not map the packet's incoming lab= el into > an NHLFE, even though the incoming label is itself valid. This can happe= n due > to transient conditions, or due to an error at the LSR which should be th= e > packet's next hop. >=20 > Corrected Text > -------------- > When a labeled packet is traveling along an LSP, it may occasionally happ= en that > it reaches an LSR at which the ILM does not map the packet's incoming lab= el into > an NHLFE, even though the incoming label is itself valid and it has a usa= ble L3 > next hop. This can happen due to transient conditions, or due to an erro= r at > the LSR which should be the packet's next hop. >=20 > Notes > ----- > There is ambiguity as to the cause of the "ILM [not mapping] the packet's > incoming label into an NHLFE". It could be read in a number of ways, of w= hich > only one can be correct: >=20 > 1. The label is valid in terms of syntax (e.g. not Implicit NULL), but no= binding has > been installed because the label hasn't been advertised. Clearly, 3.18 co= vers this > case already, and is inconsistent with the section title of "Lack of Outg= oing Label" > so this interpretation is unlikely to have been intended. >=20 > 2. The label is valid and is expected to be used for forwarding, but an N= HLFE > entry is missing or not usable because the interface the next hop is reac= hable > over has gone down, or for some other reason isn't usable. This interpret= ation is > ruled out by the statement that "it is tempting in such cases to strip of= f the label > stack and attempt to forward the packet further via conventional forwardi= ng", > which wouldn't be possible if the interface was down. >=20 > 3. A resource allocation error occurred meaning that the ILM binding was > allocated, but the NHLFE entry couldn't be allocated. There is no mention= of > resource issues in this or related sections so again this interpretation = seems > unlikely. >=20 > 4. The label is valid and is expected to be used for forwarding, but the = LSR has > received no label binding from the LSP's next hop even though it has a us= able L3 > next hop (i.e. it lacks an outgoing label). It cannot map to an NHLFE en= try > because the actions in section 3.10 don't include popping and forwarding = as > unlabeled. This is therefore the interpretation that best fits. >=20 > To clarify that interpretation 4 is the one intended, the phrase "and it = has a > usable L3 next hop" is inserted into the text, using the definition of L3= next hop > from section 3.17. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please use = "Reply > All" to discuss whether it should be verified or rejected. When a decisio= n is > reached, the verifying party (IESG) can log in to change the status and e= dit the > report, if necessary. >=20 > -------------------------------------- > RFC3031 (draft-ietf-mpls-arch-06) > -------------------------------------- > Title : Multiprotocol Label Switching Architecture > Publication Date : January 2001 > Author(s) : E. Rosen, A. Viswanathan, R. Callon > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 9 18:37:21 2015 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 8F6461A8A83; Thu, 9 Apr 2015 18:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aOR-A60Ak0el; Thu, 9 Apr 2015 18:37:14 -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 51C831A0007; Thu, 9 Apr 2015 18:37:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRF73625; Fri, 10 Apr 2015 01:37:11 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 02:37:10 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 09:37:06 +0800 From: Xuxiaohu To: Ian Cox , Erik Nordmark , "nvo3@ietf.org" Thread-Topic: [Bier] [nvo3] Encapsulation considerations Thread-Index: AQHQcljZ0fVc246YHEKvkFIl2pYVuJ1D7uKAgACBmYCAAFPggIAArZvw Date: Fri, 10 Apr 2015 01:37:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083246E5@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [mpls] [Bier] [nvo3] Encapsulation considerations 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, 10 Apr 2015 01:37:16 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJYW4gQ294IFttYWlsdG86aWNv eEBicm9hZGNvbS5jb21dDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTAsIDIwMTUgNjo1MSBBTQ0K PiBUbzogRXJpayBOb3JkbWFyazsgWHV4aWFvaHU7IG52bzNAaWV0Zi5vcmcNCj4gQ2M6IG1wbHNA aWV0Zi5vcmc7IEJJRVI7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0JpZXJdIFtudm8z XSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zDQo+IA0KPiBNUExTIGhhcyBubyBpbmRpY2F0 aW9uIGluIHRoZSBsYWJlbCBzdGFjayBmb3IgaW50ZXJtZWRpYXRlIG5vZGVzIHdoYXQgdGhlDQo+ IHVuZGVybHlpbmcgcGF5bG9hZCBpcy4gIFRvIGFjaGlldmUgYmV0dGVyIGxvYWQgYmFsYW5jaW5n IG9mIE1QTFMgdHJhZmZpYyBtb3N0DQo+IGhhcmR3YXJlIHRvZGF5IGxvb2tzIHRvIHNlZSBpZiB0 aGUgZmlyc3QgbmliYmxlIGlzIDQgb3IgNiB0aGVuIHBhcnNlIGludG8gdGhlDQo+IHBheWxvYWQg dW5kZXIgdGhlIGJlbGllZiB0aGF0IGl0IGlzIGEgSVB2NCBvciB2NiBwYWNrZXQgYW5kIHBhcnNl IHRoZSBhZGRyZXNzDQo+IGZpZWxkcyBvdXQgdG8gdXNlIGluIHRoZSBFQ01QIGhhc2guICBJZiB5 b3VyIGRlZmluaW5nIHNvbWV0aGluZyBuZXcgcGxlYXNlIHB1dCBhDQo+ICJuZXh0IHByb3RvY29s IiBvciB0eXBlIGZpZWxkIGluIHRoZSBwcmVjZWRpbmcgaGVhZGVyIHNvIGl0IGNsZWFyIHdoYXQg dGhlIG5leHQNCg0KSXMgaXQgdG9vIGxhdGUgdG8gZml4IHRoYXQgZmxhdyBvZiB0aGUgTVBMUyBh cmNoaXRlY3R1cmUgKGUuZy4sIHRoZSBsYWNrIG9mIGFuIGV4cGxpY2l0IHByb3RvY29sIGlkIGZp ZWxkKT8gT3IgdGhhdCBmbGF3IGlzIGJlbGlldmVkIGFzIGFuIGluY29tcGxldGUgYmVhdXR5IGFu ZCB0aGVyZWZvcmUgc2hvdWxkIGJlIHByZXNlcnZlZCBmb3JldmVyPyANCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gcHJvdG9jb2wgaXMuICBUaGUgNCBvciA2IGd1ZXNzIGZvciB0aGUgdW5k ZXJseWluZyBNUExTIHBheWxvYWQgYmVpbmcgYW4gSVANCj4gcGFja2V0IHdhcyBmaW5lIHVudGls IElFRUUgYWxsb2NhdGVkIE1BQyBhZGRyZXNzZXMgc3RhcnRpbmcgd2l0aCA2LiBUaGlzIGlzc3Vl IGlzDQo+IHNwZWNpZmljIFBXRTMgcGFja2V0cyB0aGF0IGRvIG5vdCBjb250YWluIHRoZSBjb250 cm9sIHdvcmQuDQoNCj4gDQo+IElhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVyaWsgTm9yZG1hcmsNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA5LCAyMDE1IDEwOjUwIEFN DQo+IFRvOiBYdXhpYW9odTsgRXJpayBOb3JkbWFyazsgbnZvM0BpZXRmLm9yZw0KPiBDYzogbXBs c0BpZXRmLm9yZzsgQklFUjsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQmllcl0gW252 bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnMNCj4gDQo+IE9uIDQvOC8xNSA3OjIwIFBN LCBYdXhpYW9odSB3cm90ZToNCj4gPiBIaSBFcmlrLA0KPiA+DQo+ID4+IEJ1dCBJIGNvdWxkbid0 IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxpc3Qgd2hldGhlciB0aGUNCj4gPj4g Y29uc3RyYWludHMgb24gdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZSBpcyBhIHN0cmljdCByZXF1aXJl bWVudCBpbiBhbGwNCj4gPj4gY2FzZXMsIG9yIHdoZXRoZXIgaXQgaXMgY29uZGl0aW9uYWwgb24g c29tZXRoaW5nIChhbmQgaWYgc28sIHdoYXQgaXMNCj4gPj4gdGhlIGNvbmRpdGlvbikuDQo+ID4g VGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBvZiBpbmNsdWRlOiAxKSB0aGUgZW5j YXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUNCj4gdG8gcGFja2V0IG1pc29yZGVyaW5nOyAyKSB0aGUg ZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhbiBNUExTDQo+IFBTTjsgMykg TFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250ZW50cyBvZiB0aGUgTVBM UyBwYXlsb2FkIHRvDQo+IHNlbGVjdCB0aGUgRUNNUCBwYXRoLg0KPiBUaG9zZSBhcmUgY29uZGl0 aW9ucyB3aGVuIHRoZSBtaXNvcmRlcmluZyB3b3VsZCBoYXBwZW4uIEJ1dCBhcmUgeW91IHNheWlu Zw0KPiB0aGF0IGFueSBMU1IgaXMgZnJlZSB0byB1c2UgdGhlIE1QTFMgcGF5bG9hZCAoaW5jbHVk aW5nIGxvb2tpbmcgZm9yIDQgYW5kIDYgaW4gdGhlDQo+IGZpcnN0IG5pYmJsZSkgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgdGhlIHBhY2tldCBpcyBJUHY0IGFuZCBJUHY2IGFuZCB1c2Ugd2hhdCBpdA0K PiB0aGlua3MgYXJlIElQdjQgYW5kIElQdjYgZmllbGRzIGZvciBFQ01QIHB1cnBvc2VzPw0KPiAN Cj4gVGhhbmtzLA0KPiAgICAgRXJpaw0KPiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBY aWFvaHUNCj4gPg0KPiA+PiBPbmNlIEkga25vdyB0aGF0IGFuc3dlciB3ZSBjYW4gZGVmaW5pdGVs eSBhZGQgc29tZSB0ZXh0IHBvaW50aW5nIG91dCB0aGUNCj4gaXNzdWUuDQo+ID4+DQo+ID4+IFRo YW5rcywNCj4gPj4gICAgICBFcmlrDQo+ID4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBY aWFvaHUNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBG cm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86bm9yZG1hcmtAc29uaWMubmV0XQ0KPiA+Pj4+IFNl bnQ6IDIwMTXlubQz5pyIMjbml6UgNTowMQ0KPiA+Pj4+IFRvOiBudm8zQGlldGYub3JnDQo+ID4+ Pj4gU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnMNCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4gSSBwcmVzZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2Vu dCBOVk8zIGludGVyaW0NCj4gPj4+PiBtZWV0aW5nLlRoZSBmdWxsDQo+ID4+PiAxMg0KPiA+Pj4+ IGFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdoZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVy IHRoaXMgd2Vlay4NCj4gPj4+PiAgICAgVGhlIGRyYWZ0IGlzDQo+ID4+Pj4gICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ydGctZHQtZW5jYXAvDQo+ID4+Pj4gICAg IGFuZCB0aGUgc2xpZGVzIGFyZSBhdA0KPiA+Pj4+DQo+ID4+Pj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgucGRmDQo+ID4+Pj4NCj4g Pj4+PiBUaGVyZSBpcyBwcm9iYWJseSBhZGRpdGlvbmFsIHRoaW5ncyBpbiB0aGVyZSB0byBjb25z aWRlciBmb3IgTlZPMywNCj4gPj4+PiBhbmQNCj4gPj4+IGFkdmljZQ0KPiA+Pj4+IHRoYXQgY2Fu IGJlIHJldXNlZCB0byBtYWtlIGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2FyZC4NCj4gPj4+ Pg0KPiA+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4gICAgICAgRXJpaw0KPiA+Pj4+DQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4+PiBudm8zQGlldGYub3JnDQo+ID4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4gPj4+DQo+ID4NCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJJ RVIgbWFpbGluZyBsaXN0DQo+IEJJRVJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyDQo= From nobody Thu Apr 9 19:18:42 2015 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 646651A9089; Thu, 9 Apr 2015 19:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lEyB1sFz1viM; Thu, 9 Apr 2015 19:18:38 -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 BB4781A908E; Thu, 9 Apr 2015 19:18:37 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-d4-5526dc674635 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CC.A7.12456.76CD6255; Thu, 9 Apr 2015 22:09:11 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 22:18:35 -0400 From: Uma Chunduri To: Xuxiaohu , RFC Errata System , "erosen@cisco.com" , "arun@force10networks.com" , "rcallon@juniper.net" , "akatlas@gmail.com" , "db3546@att.com" , "aretana@cisco.com" , "loa@pi.nu" , "swallow@cisco.com" , "rcallon@juniper.net" Thread-Topic: [mpls] [Technical Errata Reported] RFC3031 (4331) Thread-Index: AQHQcslhlYrKqN3vJk+vcGvqA513i51Fs3OA///ODLA= Date: Fri, 10 Apr 2015 02:18:34 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F624A5A@eusaamb105.ericsson.se> References: <20150409132948.D630A180092@rfc-editor.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083246AE@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083246AE@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyuXRPuG76HbVQgycLdC0+PbzEbPH351ZG i10dX5gsLnd1s1usuzuJxeLf3DnMFreWrmS1+LviCotF0/6vbBbXrwDFrq5pYre4PaWJ0WLr +VWMDrweL/vnMHr0HLvM5jHl90ZWj1kvX7J57Jx1l92j5chbVo8lS34yeVxvusruMWt6G5tH Q9sx1gCuKC6blNSczLLUIn27BK6Mns2dbAVfTSomXf/K2sDYrd3FyMkhIWAisbxpAxuELSZx 4d56IJuLQ0jgKKPE9ZkPWCGcZYwSX+cvZQapYhPQk/g49Sc7SEJE4AyzROuGZpYuRg4OZoEy ic4bLiA1wgJ2Epe/dzGC2CIC9hILNoHYHEC2lcSPF9YgYRYBVYnrN6azgNi8Ar4Suw58ZIfY 1cwocaJ9JdhFnAJhEpf794AVMQJd9/3UGiYQm1lAXOLWk/lMEFcLSCzZc54ZwhaVePn4HyuE rSQxaek5Voh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLk KC1OLctNNzLYxAiM8mMSbLo7GPe8tDzEKMDBqMTD+2CJaqgQa2JZcWXuIUZpDhYlcd5FDw6G CAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMPi/vxPntk8v7Y/EpD/xLo/8EHj4xl9NnRcaB my27Ol94H82ZcqRhfVZjSI90dYqSLH83T3i4UA7X+5MbfxVxTvy//t2KmJ2fzTQ0cw+tCXhy p+TNLe/Uc+tK9ldJCJ7ckCPYfNIgN3q1XtL8r1s0++4aRKWLumr/XWWyUyH8xxGvlLkSzTJK LMUZiYZazEXFiQBC4tMl0wIAAA== Archived-At: Cc: "mpls@ietf.org" , "rshearma@brocade.com" , spring Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (4331) 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, 10 Apr 2015 02:18:40 -0000 Xioahu et all, The transient case talked in 3.22 can be more frequent for MPLS-SPRING, if= the NH node is still re-converging while traffic hits travelling along the= installed ingress LSP. I heard this (@IETF-92) from the early test scenar= ios with SPRING. Any possible solution here other than dropping the packet? The case you pointed below in non-transient case which is possible as allud= ed with both incremental deployments or new IP based deployments (MBH) wit= h few MPLS-SPRING nodes.=20 Thanks! -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Thursday, April 09, 2015 6:09 PM To: RFC Errata System; erosen@cisco.com; arun@force10networks.com; rcallon@= juniper.net; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; loa@pi.n= u; swallow@cisco.com; rcallon@juniper.net Cc: mpls@ietf.org; rshearma@brocade.com; spring Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (4331) Hi all, It seems that interpretation 4 would become more common in MPLS-SPRING (i.e= ., segment routing) networks where OSPF or ISIS is used as a label distribu= tion protocol and partial routers are still legacy routers (e.g. pure IP ro= uter). In this case, it seems feasible to allow the LSR to replace the top = label by an IP-based tunnel header and then forward the packet further via = conventional IP forwarding. The tunnel destination is the /32 or /128 FEC p= refix corresponding to that top label. For more details about this usage, p= lease refer to https://tools.ietf.org/html/draft-xu-spring-islands-connecti= on-over-ip-04. This usage is valuable both in the incremental deployment ca= se where partial routers have not yet be upgraded to support MPLS-SPRING an= d in some specific cases where it's unnecessary to make all routers to be M= PLS-SPRING-capable (e.g., in the dual-plane TE scenario where only the edge= routers of each plane need to be MPLS-SPRING-capable). Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of RFC Errata=20 > System > Sent: Thursday, April 09, 2015 9:30 PM > To: erosen@cisco.com; arun@force10networks.com; rcallon@juniper.net;=20 > akatlas@gmail.com; db3546@att.com; aretana@cisco.com; loa@pi.nu;=20 > swallow@cisco.com; rcallon@juniper.net > Cc: mpls@ietf.org; rshearma@brocade.com; rfc-editor@rfc-editor.org > Subject: [mpls] [Technical Errata Reported] RFC3031 (4331) >=20 > The following errata report has been submitted for RFC3031,=20 > "Multiprotocol Label Switching Architecture". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3031&eid=3D4331 >=20 > -------------------------------------- > Type: Technical > Reported by: Robert Shearman >=20 > Section: 3.22 >=20 > Original Text > ------------- > When a labeled packet is traveling along an LSP, it may occasionally=20 > happen that it reaches an LSR at which the ILM does not map the=20 > packet's incoming label into an NHLFE, even though the incoming label=20 > is itself valid. This can happen due to transient conditions, or due=20 > to an error at the LSR which should be the packet's next hop. >=20 > Corrected Text > -------------- > When a labeled packet is traveling along an LSP, it may occasionally=20 > happen that it reaches an LSR at which the ILM does not map the=20 > packet's incoming label into an NHLFE, even though the incoming label=20 > is itself valid and it has a usable L3 next hop. This can happen due=20 > to transient conditions, or due to an error at the LSR which should be th= e packet's next hop. >=20 > Notes > ----- > There is ambiguity as to the cause of the "ILM [not mapping] the=20 > packet's incoming label into an NHLFE". It could be read in a number=20 > of ways, of which only one can be correct: >=20 > 1. The label is valid in terms of syntax (e.g. not Implicit NULL), but=20 > no binding has been installed because the label hasn't been=20 > advertised. Clearly, 3.18 covers this case already, and is inconsistent w= ith the section title of "Lack of Outgoing Label" > so this interpretation is unlikely to have been intended. >=20 > 2. The label is valid and is expected to be used for forwarding, but=20 > an NHLFE entry is missing or not usable because the interface the next=20 > hop is reachable over has gone down, or for some other reason isn't=20 > usable. This interpretation is ruled out by the statement that "it is=20 > tempting in such cases to strip off the label stack and attempt to=20 > forward the packet further via conventional forwarding", which wouldn't b= e possible if the interface was down. >=20 > 3. A resource allocation error occurred meaning that the ILM binding=20 > was allocated, but the NHLFE entry couldn't be allocated. There is no=20 > mention of resource issues in this or related sections so again this=20 > interpretation seems unlikely. >=20 > 4. The label is valid and is expected to be used for forwarding, but=20 > the LSR has received no label binding from the LSP's next hop even=20 > though it has a usable L3 next hop (i.e. it lacks an outgoing label).=20 > It cannot map to an NHLFE entry because the actions in section 3.10=20 > don't include popping and forwarding as unlabeled. This is therefore the = interpretation that best fits. >=20 > To clarify that interpretation 4 is the one intended, the phrase "and=20 > it has a usable L3 next hop" is inserted into the text, using the=20 > definition of L3 next hop from section 3.17. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC3031 (draft-ietf-mpls-arch-06) > -------------------------------------- > Title : Multiprotocol Label Switching Architecture > Publication Date : January 2001 > Author(s) : E. Rosen, A. Viswanathan, R. Callon > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > 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 Thu Apr 9 20:34:38 2015 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 8333E1AC3EC; Thu, 9 Apr 2015 20:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cxl2UdCFB4pd; Thu, 9 Apr 2015 20:34:33 -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 7F3221AC3E9; Thu, 9 Apr 2015 20:34:32 -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 BRF80664; Fri, 10 Apr 2015 03:34:30 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 04:34:29 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 11:34:26 +0800 From: Xuxiaohu To: Tony Przygienda , Alia Atlas Thread-Topic: [Bier] [sfc] [nvo3] Encapsulation considerations Thread-Index: AQHQcljZ0fVc246YHEKvkFIl2pYVuJ1D7uKAgACBmYCAAAMiAIAABIUAgAETRwA= Date: Fri, 10 Apr 2015 03:34:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Erik Nordmark , "nvo3@ietf.org" , BIER , "sfc@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] [Bier] [sfc] [nvo3] Encapsulation considerations 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, 10 Apr 2015 03:34:36 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KRnJvbTogVG9ueSBQcnp5Z2llbmRhIFttYWlsdG86dG9ueXNpZXRmQGdtYWls LmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTAsIDIwMTUgMjoxOCBBTQ0KVG86IEFsaWEgQXRs YXMNCkNjOiBFcmlrIE5vcmRtYXJrOyBCSUVSOyBtcGxzQGlldGYub3JnOyBYdXhpYW9odTsgbnZv M0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0JpZXJdIFtzZmNdIFtudm8z XSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zDQoNCkkgd291bGQgdmVudHVyZSB0byBzYXkg dGhhdA0KYS4gICAgICBCSUVSIG1pc29yZGVyaW5nIHdvdWxkIGJlIGEgYmFkIHRoaW5nIGZvciBt YW55IGFwcGxpY2F0aW9ucyBidXQgSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgZW5jYXBzdWxhdGlv biBwZXIgc2UgbWlzb3JkZXJzIG9yIG5vdCBhcyBwcm9wZXJ0eSwgaXTigJlzIHRoZSB3YXkgdGhl IGludGVybWVkaWF0ZSByb3V0ZXJzIGFyZSBhbGxvd2VkIHRvIHBsYXkgc2hhbm5pZ2FucyAob3Ig c2VlbiBkaWZmZXJlbnRseSwg4oCYaGV1cmlzdGljYWxseeKAmSBjb21lIHVwIHdpdGggdGhpbmdz IGdpdmVuIHVuY2xlYXIgc2VtYW50aWNzIG9mIHRoZSBlbmNhcHMpIHRoYXQgY2F1c2VzIG1pc29y ZGVyaW5nLiBTbyBpdCBpcyB1cCB0byB0aGUgZW5jYXBzIHRvIGdpdmUgZW5vdWdoIGluZm8gc28g dGhlIHJvdXRlcnMgaW4gdGhlIG1pZGRsZSBkbyB0aGUg4oCYcmlnaHQgdGhpbmfigJkuIE1vZHVs byBoaXN0b3JpY2FsIHByb2JsZW1zIHdpdGggQ1cgc3VwcG9ydCBhbmQgc28gb24g4oCmDQpiLiAg ICAgIFRoaXMgZmxhdm9yIG9mIGRpc2N1c3Npb24gaXMgcmVwZWF0aW5nLCBlLmcuIGVWUE4gUkZD IHdpdGggdGhlIENXL25vIENXIGRlYmF0ZSB3aGljaCBJIGNvdWxkIHJlc3RvcmUgb25seSBwYXJ0 aWFsbHkgYW5kIG90aGVyIGdyb3VwcyBub3cg4oCmDQoNCk9LLCBsZW1tZSBzdGljayBteSAobmHD r3ZlIDstKSBoZWFkIGZhciBvdXQ6IHdoeSBkbyBlbmNhcHMgZ3VpZGVsaW5lcyBmb3IgZXZlcnl0 aGluZyB0aGF0IGNhbiBnbyBvdmVyIFBTTiBub3QgbWFuZGF0ZSBDVyBmcm9tIG5vdyBvbj8gRXhp c3RpbmcgZ2VhciBhbmQgaGlzdG9yaWNhbCBSRkNzIHN1cHBvcnRlZCB1bnRpbCB0aGV5IHBldGVy IG91dCBhbmQgZW50cm9weSBsYWJlbHMgYmVpbmcgYW4gb3J0aG9nb25hbCBtZWNoYW5pc20g4oCm ICBPciBkbyB3ZSB0aGluayB0aGUg4oCYaGV1cmlzdGljYWwgRFBJJyBpcyBhIGJvdHRvbWxlc3Mg Ym94IG9mIGJhbmQtYWlkcyA/DQpbWGlhb2h1XSBXb3VsZG7igJl0IGl0IGJlIGJldHRlciB0byBp bnNlcnQgYSBwcm90b2NvbCBpZCBmaWVsZCB0aGFuIHRvIGluc2VydCBhIENXPyBUaGUgbGF0dGVy IGNvdWxkIG9ubHkgdGVsbCB5b3UgdGhlIE1QTFMgcGF5bG9hZCBpcyBub3QgSVAgcGF5bG9hZCB3 aGlsZSB0aGUgZm9ybWVyIGNvdWxkIHRlbGwgeW91IHdoYXQgdGhlIE1QTFMgcGF5bG9hZCBpcy4g QXMgRXJpYyBtZW50aW9uZWQgcHJldmlvdXNseSBpbiB0aGUgQklFUiBtYWlsaW5nLWxpc3QsIGl0 4oCZcyB1c2VmdWwgZm9yIGludGVybWVkaWF0ZSByb3V0ZXJzIHRvIGtub3cgd2hldGhlciB0aGUg TVBMUyBwYXlsb2FkIGlzIGEgQklFUiBwYWNrZXQuIEluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0ICho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndWljaGFyZC1zZmMtbXBscy1tZXRhZGF0 YS0wMCkgYWxzbyBtZW50aW9uZWQgdGhlIG5lZWQgb2YgZGV0ZXJtaW5pbmcgdGhlIE1QTFMgcGF5 bG9hZCAoaS5lLiwganVzdCBrbm93aW5nIHRoZSBwYXlsb2FkIGlzIG5vdCBhbiBJUCBwYXlsb2Fk IGlzIG5vdCBlbm91Z2gpLiBIb3dldmVyLCB0aGUgYXBwcm9hY2ggYXMgZGVmaW5lZCBpbiB0aGlz IGRyYWZ0IGlzIG9ubHkgYXBwbGljYWJsZSBvZiBpbmRpY2F0aW5nIHRoZSBwcmVzZW5jZSBvZiBt ZXRhZGF0YSB3aXRoaW4gYW4gTVBMUyBwYWNrZXQuIFdvdWxkbuKAmXQgaXQgYmUgYmV0dGVyIHRv IGdvIGEgc3RlcCBmdXJ0aGVyIChpLmUuLCBpbnNlcnRpbmcgYSBwcm90b2NvbCBpZCBmaWVsZCBi ZXR3ZWVuIHRoZSBsYWJlbCBzdGFjayBhbmQgdGhlIE1QTFMgcGF5bG9hZCk/IEluIHRoaXMgd2F5 LCBpdOKAmXMgYXBwbGljYWJsZSBvZiBpbmRpY2F0aW5nIHdoYXRldmVyIE1QTFMgcGF5bG9hZHMg YW5kIHRoZXJlZm9yZSBpdCB3b3VsZCBub3QgbmVlZCB0aG9zZSBNUExTIHBheWxvYWRzIHRoZW1z ZWx2ZXMgdG8gaW5kaWNhdGUgdGhlIHBheWxvYWQgdHlwZXMgKGkuZS4sIGJ5IHVzaW5nIHRoZSBm aXJzdCBuaWJibGUgYXMgYSBwb29yLW1hbuKAmXMgcHJvdG9jb2wgaWQgZmllbGQpLg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQotLS0gdG9ueQ0KDQpPbiBUaHUsIEFwciA5LCAyMDE1IGF0IDExOjAx IEFNLCBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5j b20+PiB3cm90ZToNCk9uIFRodSwgQXByIDksIDIwMTUgYXQgMTo1MCBQTSwgRXJpayBOb3JkbWFy ayA8bm9yZG1hcmtAYWNtLm9yZzxtYWlsdG86bm9yZG1hcmtAYWNtLm9yZz4+IHdyb3RlOg0KT24g NC84LzE1IDc6MjAgUE0sIFh1eGlhb2h1IHdyb3RlOg0KSGkgRXJpaywNCkJ1dCBJIGNvdWxkbid0 IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxpc3Qgd2hldGhlciB0aGUgY29uc3Ry YWludHMgb24gdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZSBpcyBhIHN0cmljdCByZXF1aXJlbWVudCBp biBhbGwgY2FzZXMsIG9yIHdoZXRoZXIgaXQgaXMgY29uZGl0aW9uYWwgb24gc29tZXRoaW5nIChh bmQgaWYgc28sIHdoYXQgaXMgdGhlIGNvbmRpdGlvbikuDQpUaGUgY29uZGl0aW9ucyB0aGF0IEkg aGF2ZSB0aG91Z2h0IG9mIGluY2x1ZGU6IDEpIHRoZSBlbmNhcHN1bGF0aW9uIGlzIHNlbnNpdGl2 ZSB0byBwYWNrZXQgbWlzb3JkZXJpbmc7IDIpIHRoZSBlbmNhcHN1bGF0aW9uIG1heSBiZSB0cmFu c3BvcnRlZCBvdmVyIGFuIE1QTFMgUFNOOyAzKSBMU1JzIHdpdGhpbiB0aGF0IE1QTFMgUFNOIG1h eSB1c2UgdGhlIGNvbnRlbnRzIG9mIHRoZSBNUExTIHBheWxvYWQgdG8gc2VsZWN0IHRoZSBFQ01Q IHBhdGguDQpUaG9zZSBhcmUgY29uZGl0aW9ucyB3aGVuIHRoZSBtaXNvcmRlcmluZyB3b3VsZCBo YXBwZW4uIEJ1dCBhcmUgeW91IHNheWluZyB0aGF0IGFueSBMU1IgaXMgZnJlZSB0byB1c2UgdGhl IE1QTFMgcGF5bG9hZCAoaW5jbHVkaW5nIGxvb2tpbmcgZm9yIDQgYW5kIDYgaW4gdGhlIGZpcnN0 IG5pYmJsZSkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIHBhY2tldCBpcyBJUHY0IGFuZCBJUHY2 IGFuZCB1c2Ugd2hhdCBpdCB0aGlua3MgYXJlIElQdjQgYW5kIElQdjYgZmllbGRzIGZvciBFQ01Q IHB1cnBvc2VzPw0KDQpUYWtlIGEgcXVpY2sgbG9vayBhdCBSRkMgNDM4NSAtIHdoaWNoIGlzIHRo ZSBjb250cm9sIHdvcmQgZm9yIHBzZXVkby13aXJlcy4NClRoZSBzaG9ydCBmb3JtIGlzIHRoYXQg YSBudW1iZXIgb2Ygcm91dGVycyBhdCB0aGUgdGltZSBwZWVrZWQgYmVuZWF0aCB0aGUgbGFiZWwg c3RhY2sgdG8gZmlndXJlIG91dCB3aGV0aGVyIHdoYXQgd2FzIGluc2lkZSBhcyBJUHY0IG9yIElQ djYgYmFzZWQgc29sZWx5IHVwb24gdGhlIGZpcnN0IG5pYmJsZS4gIEEgcmVjb21tZW5kYXRpb24g d2FzIG1hZGUgdGhhdCB0aGUgY2hlY2tzdW0gc2hvdWxkIGFsc28gYmUgdmVyaWZpZWQsIGJ1dCB0 aGUgb25seSBlcXVpcG1lbnQgdGhhdCBJJ20gY2VydGFpbiBvZiB0aGF0IGRpZCB0aGF0IGlzbid0 IGFyb3VuZCBhbnltb3JlLg0KDQpBbHNvIGxvb2sgYXQgU2VjdGlvbiAyLjQgb2YgUkZDIDczMjUu DQoNCkFsaWENCg0KDQpUaGFua3MsDQogICBFcmlrDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K T25jZSBJIGtub3cgdGhhdCBhbnN3ZXIgd2UgY2FuIGRlZmluaXRlbHkgYWRkIHNvbWUgdGV4dCBw b2ludGluZyBvdXQgdGhlIGlzc3VlLg0KDQpUaGFua3MsDQogICAgIEVyaWsNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVyaWsgTm9yZG1h cmsgW21haWx0bzpub3JkbWFya0Bzb25pYy5uZXQ8bWFpbHRvOm5vcmRtYXJrQHNvbmljLm5ldD5d DQpTZW50OiAyMDE15bm0M+aciDI25pelIDU6MDENClRvOiBudm8zQGlldGYub3JnPG1haWx0bzpu dm8zQGlldGYub3JnPg0KU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlv bnMNCg0KDQpJIHByZXNlbnRlZCBwYXJ0IG9mIHRoaXMgYXQgdGhlIG1vc3QgcmVjZW50IE5WTzMg aW50ZXJpbSBtZWV0aW5nLlRoZQ0KZnVsbA0KMTINCmFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdo ZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVyIHRoaXMgd2Vlay4NCiAgICBUaGUgZHJhZnQg aXMNCiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnRnLWR0LWVu Y2FwLw0KICAgIGFuZCB0aGUgc2xpZGVzIGFyZSBhdA0KICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItcnRnd2ctOC5wZGYNCg0KVGhlcmUgaXMg cHJvYmFibHkgYWRkaXRpb25hbCB0aGluZ3MgaW4gdGhlcmUgdG8gY29uc2lkZXIgZm9yIE5WTzMs DQphbmQNCmFkdmljZQ0KdGhhdCBjYW4gYmUgcmV1c2VkIHRvIG1ha2UgaXQgZWFzaWVyIHRvIG1v dmUgTlZPMyBmb3J3YXJkLg0KDQpSZWdhcmRzLA0KICAgICAgRXJpaw0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0K bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnZvMw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJ RVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgVG9ueSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gVG9ueSBQcnp5Z2llbmRhIFttYWlsdG86dG9ueXNpZXRmQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEwLCAyMDE1IDI6MTggQU08YnI+ DQo8Yj5Ubzo8L2I+IEFsaWEgQXRsYXM8YnI+DQo8Yj5DYzo8L2I+IEVyaWsgTm9yZG1hcms7IEJJ RVI7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1OyBudm8zQGlldGYub3JnOyBzZmNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtCaWVyXSBbc2ZjXSBbbnZvM10gRW5jYXBzdWxhdGlv biBjb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIHZlbnR1cmUg dG8gc2F5IHRoYXQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJJRVIgbWlzb3JkZXJpbmcg d291bGQgYmUgYSBiYWQgdGhpbmcgZm9yIG1hbnkgYXBwbGljYXRpb25zIGJ1dCBJIGRvIG5vdCB0 aGluayB0aGF0IHRoZSBlbmNhcHN1bGF0aW9uIHBlciBzZSBtaXNvcmRlcnMgb3Igbm90IGFzIHBy b3BlcnR5LCBpdOKAmXMgdGhlIHdheSB0aGUgaW50ZXJtZWRpYXRlDQogcm91dGVycyBhcmUgYWxs b3dlZCB0byBwbGF5IHNoYW5uaWdhbnMgKG9yIHNlZW4gZGlmZmVyZW50bHksIOKAmGhldXJpc3Rp Y2FsbHnigJkgY29tZSB1cCB3aXRoIHRoaW5ncyBnaXZlbiB1bmNsZWFyIHNlbWFudGljcyBvZiB0 aGUgZW5jYXBzKSB0aGF0IGNhdXNlcyBtaXNvcmRlcmluZy4gU28gaXQgaXMgdXAgdG8gdGhlIGVu Y2FwcyB0byBnaXZlIGVub3VnaCBpbmZvIHNvIHRoZSByb3V0ZXJzIGluIHRoZSBtaWRkbGUgZG8g dGhlIOKAmHJpZ2h0IHRoaW5n4oCZLg0KIE1vZHVsbyBoaXN0b3JpY2FsIHByb2JsZW1zIHdpdGgg Q1cgc3VwcG9ydCBhbmQgc28gb24g4oCmIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjU0LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMg Zmxhdm9yIG9mIGRpc2N1c3Npb24gaXMgcmVwZWF0aW5nLCBlLmcuIGVWUE4gUkZDIHdpdGggdGhl IENXL25vIENXIGRlYmF0ZSB3aGljaCBJIGNvdWxkIHJlc3RvcmUgb25seSBwYXJ0aWFsbHkgYW5k IG90aGVyIGdyb3VwcyBub3cg4oCmDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PSywgbGVtbWUgc3RpY2sgbXkgKG5hw692ZSA7LSkgaGVhZCBmYXIgb3V0OiB3aHkgZG8gZW5j YXBzIGd1aWRlbGluZXMgZm9yIGV2ZXJ5dGhpbmcNCiB0aGF0IGNhbiBnbyBvdmVyIFBTTiBub3Qg bWFuZGF0ZSBDVyBmcm9tIG5vdyBvbj8gRXhpc3RpbmcgZ2VhciBhbmQgaGlzdG9yaWNhbCBSRkNz IHN1cHBvcnRlZCB1bnRpbCB0aGV5IHBldGVyIG91dCBhbmQgZW50cm9weSBsYWJlbHMgYmVpbmcg YW4gb3J0aG9nb25hbCBtZWNoYW5pc20g4oCmICZuYnNwO09yIGRvIHdlIHRoaW5rIHRoZSDigJho ZXVyaXN0aWNhbCBEUEknIGlzIGEgYm90dG9tbGVzcyBib3ggb2YgYmFuZC1haWRzID8NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltYaWFvaHVdIFdvdWxkbuKAmXQgaXQgYmUgYmV0dGVyIHRvIGluc2VydCBhIHBy b3RvY29sIGlkIGZpZWxkIHRoYW4gdG8gaW5zZXJ0IGEgQ1c/IFRoZQ0KIGxhdHRlciBjb3VsZCBv bmx5IHRlbGwgeW91IHRoZSBNUExTIHBheWxvYWQgaXMgbm90IElQIHBheWxvYWQgd2hpbGUgdGhl IGZvcm1lciBjb3VsZCB0ZWxsIHlvdSB3aGF0IHRoZSBNUExTIHBheWxvYWQgaXMuIEFzIEVyaWMg bWVudGlvbmVkIHByZXZpb3VzbHkgaW4gdGhlIEJJRVIgbWFpbGluZy1saXN0LCBpdOKAmXMgdXNl ZnVsIGZvciBpbnRlcm1lZGlhdGUgcm91dGVycyB0byBrbm93IHdoZXRoZXIgdGhlIE1QTFMgcGF5 bG9hZCBpcyBhIEJJRVIgcGFja2V0Lg0KIEluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0ICg8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndWljaGFyZC1zZmMtbXBscy1tZXRh ZGF0YS0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3VpY2hhcmQtc2ZjLW1w bHMtbWV0YWRhdGEtMDA8L2E+KSBhbHNvIG1lbnRpb25lZCB0aGUgbmVlZCBvZiBkZXRlcm1pbmlu ZyB0aGUgTVBMUyBwYXlsb2FkIChpLmUuLCBqdXN0IGtub3dpbmcgdGhlIHBheWxvYWQgaXMNCiBu b3QgYW4gSVAgcGF5bG9hZCBpcyBub3QgZW5vdWdoKS4gSG93ZXZlciwgdGhlIGFwcHJvYWNoIGFz IGRlZmluZWQgaW4gdGhpcyBkcmFmdCBpcyBvbmx5IGFwcGxpY2FibGUgb2YgaW5kaWNhdGluZyB0 aGUgcHJlc2VuY2Ugb2YgbWV0YWRhdGEgd2l0aGluIGFuIE1QTFMgcGFja2V0LiBXb3VsZG7igJl0 IGl0IGJlIGJldHRlciB0byBnbyBhIHN0ZXAgZnVydGhlciAoaS5lLiwgaW5zZXJ0aW5nIGEgcHJv dG9jb2wgaWQgZmllbGQgYmV0d2VlbiB0aGUgbGFiZWwNCiBzdGFjayBhbmQgdGhlIE1QTFMgcGF5 bG9hZCk/IEluIHRoaXMgd2F5LCBpdOKAmXMgYXBwbGljYWJsZSBvZiBpbmRpY2F0aW5nIHdoYXRl dmVyIE1QTFMgcGF5bG9hZHMgYW5kIHRoZXJlZm9yZSBpdCB3b3VsZCBub3QgbmVlZCB0aG9zZSBN UExTIHBheWxvYWRzIHRoZW1zZWx2ZXMgdG8gaW5kaWNhdGUgdGhlIHBheWxvYWQgdHlwZXMgKGku ZS4sIGJ5IHVzaW5nIHRoZSBmaXJzdCBuaWJibGUgYXMgYSBwb29yLW1hbuKAmXMgcHJvdG9jb2wg aWQgZmllbGQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C ZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS0g dG9ueSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBBcHIgOSwgMjAxNSBhdCAxMTowMSBBTSwgQWxp YSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+T24gVGh1LCBBcHIgOSwgMjAxNSBhdCAxOjUwIFBNLCBFcmlrIE5vcmRtYXJrICZs dDs8YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRt YXJrQGFjbS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gNC84LzE1IDc6MjAgUE0sIFh1eGlh b2h1IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEVyaWssPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkJ1dCBJIGNvdWxkbid0IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxpc3Qg d2hldGhlciB0aGUgY29uc3RyYWludHMgb24gdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZSBpcyBhIHN0 cmljdCByZXF1aXJlbWVudCBpbiBhbGwgY2FzZXMsIG9yIHdoZXRoZXIgaXQgaXMgY29uZGl0aW9u YWwgb24gc29tZXRoaW5nIChhbmQgaWYgc28sIHdoYXQgaXMgdGhlIGNvbmRpdGlvbikuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBvZiBpbmNsdWRlOiAxKSB0aGUg ZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFja2V0IG1pc29yZGVyaW5nOyAyKSB0aGUg ZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhbiBNUExTIFBTTjsgMykgTFNS cyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250ZW50cyBvZiB0aGUNCiBNUExT IHBheWxvYWQgdG8gc2VsZWN0IHRoZSBFQ01QIHBhdGguPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRob3NlIGFyZSBjb25kaXRp b25zIHdoZW4gdGhlIG1pc29yZGVyaW5nIHdvdWxkIGhhcHBlbi4gQnV0IGFyZSB5b3Ugc2F5aW5n IHRoYXQgYW55IExTUiBpcyBmcmVlIHRvIHVzZSB0aGUgTVBMUyBwYXlsb2FkIChpbmNsdWRpbmcg bG9va2luZyBmb3IgNCBhbmQgNiBpbiB0aGUgZmlyc3QgbmliYmxlKSB0byBkZXRlcm1pbmUgd2hl dGhlciB0aGUgcGFja2V0IGlzIElQdjQgYW5kIElQdjYNCiBhbmQgdXNlIHdoYXQgaXQgdGhpbmtz IGFyZSBJUHY0IGFuZCBJUHY2IGZpZWxkcyBmb3IgRUNNUCBwdXJwb3Nlcz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UYWtlIGEgcXVpY2sgbG9vayBhdCBSRkMgNDM4 NSAtIHdoaWNoIGlzIHRoZSBjb250cm9sIHdvcmQgZm9yIHBzZXVkby13aXJlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIHNob3J0IGZvcm0gaXMgdGhhdCBhIG51bWJlciBvZiByb3V0ZXJzIGF0 IHRoZSB0aW1lIHBlZWtlZCBiZW5lYXRoIHRoZSBsYWJlbCBzdGFjayB0byBmaWd1cmUgb3V0IHdo ZXRoZXIgd2hhdCB3YXMgaW5zaWRlIGFzIElQdjQgb3IgSVB2NiBiYXNlZCBzb2xlbHkgdXBvbiB0 aGUgZmlyc3QgbmliYmxlLiZuYnNwOyBBIHJlY29tbWVuZGF0aW9uIHdhcyBtYWRlIHRoYXQgdGhl IGNoZWNrc3VtDQogc2hvdWxkIGFsc28gYmUgdmVyaWZpZWQsIGJ1dCB0aGUgb25seSBlcXVpcG1l bnQgdGhhdCBJJ20gY2VydGFpbiBvZiB0aGF0IGRpZCB0aGF0IGlzbid0IGFyb3VuZCBhbnltb3Jl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxzbyBs b29rIGF0IFNlY3Rpb24gMi40IG9mIFJGQyA3MzI1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJz cDtFcmlrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KQmVzdCByZWdh cmRzLDxicj4NClhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uY2Ug SSBrbm93IHRoYXQgYW5zd2VyIHdlIGNhbiBkZWZpbml0ZWx5IGFkZCBzb21lIHRleHQgcG9pbnRp bmcgb3V0IHRoZSBpc3N1ZS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDtFcmlrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCByZWdhcmRz LDxicj4NClhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IEVyaWsgTm9yZG1hcmsgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAc29uaWMubmV0 IiB0YXJnZXQ9Il9ibGFuayI+bm9yZG1hcmtAc29uaWMubmV0PC9hPl08YnI+DQpTZW50OiAyMDE1 PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4zPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4yNjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDU6MDE8YnI+DQpUbzogPGEgaHJlZj0i bWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFtudm8zXSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zPGJyPg0KPGJy Pg0KPGJyPg0KSSBwcmVzZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2VudCBOVk8z IGludGVyaW0gbWVldGluZy5UaGU8YnI+DQpmdWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFyZWFzIG9mIGNv bnNpZGVyYXRpb25zIHdoZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVyIHRoaXMgd2Vlay48 YnI+DQombmJzcDsgJm5ic3A7IFRoZSBkcmFmdCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnRnLWR0LWVu Y2FwLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ydGctZHQtZW5jYXAvPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgYW5kIHRoZSBzbGlkZXMg YXJlIGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItcnRnd2ctOC5wZGYiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMt OTItcnRnd2ctOC5wZGY8L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgcHJvYmFibHkgYWRkaXRpb25h bCB0aGluZ3MgaW4gdGhlcmUgdG8gY29uc2lkZXIgZm9yIE5WTzMsPGJyPg0KYW5kPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFk dmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYXQgY2FuIGJlIHJldXNl ZCB0byBtYWtlIGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2FyZC48YnI+DQo8YnI+DQpSZWdh cmRzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEVyaWs8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm52bzMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZv MyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5zZmMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpCSUVSIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIj5CSUVSQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmll ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YmllcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_-- From nobody Thu Apr 9 23:37:44 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8B9871ACEF8; Thu, 9 Apr 2015 23:37:43 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0931ACEF4 for ; Thu, 9 Apr 2015 23:37:43 -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 37-4qNys8MHY for ; Thu, 9 Apr 2015 23:37:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCF81ACEED for ; Thu, 9 Apr 2015 23:37:40 -0700 (PDT) Received: from pipi.pi.nu ([83.168.239.141]:49924) by zinfandel.tools.ietf.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgSZP-0007LG-3H for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Thu, 09 Apr 2015 23:37:40 -0700 Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 00C781801587; Fri, 10 Apr 2015 08:37:31 +0200 (CEST) Message-ID: <55276FAB.90404@pi.nu> Date: Fri, 10 Apr 2015 08:37:31 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "George Swallow (swallow)" , "drafts-approval@iana.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 83.168.239.141 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: loa@pi.nu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150410063740.DCCF81ACEED@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 23:37:40 -0700 (PDT) Resent-From: loa@pi.nu Archived-At: Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 10 Apr 2015 06:37:43 -0000 George, In my Shepherd response to the IANA mail, I responded to "QUESTION" (below) I said it is correct to add the notes to the sub-TLV registry for Proxy Echo Parameters as we have for the existing sub-TLV registries. Do you agree? /Loa On 2015-04-09 21:32, George Swallow (swallow) wrote: > Amanda - > > These look fine to me. > > Thanks! > > George > > On 4/8/15 7:29 PM, "Amanda Baber via RT" wrote: > >> Dear Authors: >> >> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED >> >> We've completed the IANA Actions for the following RFC-to-be: >> >> draft-ietf-mpls-proxy-lsp-ping-05 >> >> NOTE: The following have been converted to lower case: "could" in TBA-9; >> "marked" in the notes attached to the registration procedures for the >> Downstream Mapping and Next Hop registries. >> >> QUESTION: The existing sub-TLV registries list notes for each >> registration range. The new sub-TLV registry for Proxy Echo Parameters >> doesn't, because I couldn't find a source for those notes in RFC 4379. >> >> Should those notes ("This range is for mandatory TLVs or for optional >> TLVs that require an error message if not recognized," etc.) be included >> in this registry's registration procedures? If so, are these included or >> implied in RFC 4379? If there isn't a source for them in RFC 4379, >> they'll have to be spelled out in this document's IANA Considerations >> section. >> >> ACTION 1: >> >> IANA has registered the following Message Types: >> >> 3 MPLS Proxy Ping Request [RFC-ietf-mpls-proxy-lsp-ping-05] >> 4 MPLS Proxy Ping Reply [RFC-ietf-mpls-proxy-lsp-ping-05] >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> >> ACTION 2: >> >> IANA has registered the following TLVs: >> >> 23 Proxy Echo >> Parameters [RFC-ietf-mpls-proxy-lsp-ping-05] [http://www.iana.org/assignme >> nts/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-23] >> 24 Reply-to Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs >> 25 Upstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs >> 26 Downstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No >> Sub-TLVs >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> >> ACTION 3: >> >> IANA has registered the following Return Codes: >> >> 16 Proxy Ping not authorized. [RFC-ietf-mpls-proxy-lsp-ping-05] >> 17 Proxy Ping parameters need to be >> modified. [RFC-ietf-mpls-proxy-lsp-ping-05] >> 18 MPLS Echo Request could not be sent. [RFC-ietf-mpls-proxy-lsp-ping-05] >> 19 Replying router has FEC mapping for topmost >> FEC. [RFC-ietf-mpls-proxy-lsp-ping-05] >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> >> ACTION 4: >> >> IANA has created the following registry: >> >> Sub-TLVs for TLV Type 23 >> Reference >> [RFC4379][RFC-ietf-mpls-proxy-lsp-ping-05] >> >> Range Registration Procedures >> 0-16383 Standards Action >> 16384-31743 Specification Required >> 32768-49161 Standards Action >> 49162-64511 Specification Required >> >> Sub-Type Sub-TLV Name Reference Comment >> 0 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >> 1 Next Hop [RFC-ietf-mpls-proxy-lsp-ping-05] >> 2-64511 Unassigned >> 64512-65535 Reserved for Vendor or Private Use [RFC4379] >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> >> ACTION 5: >> >> IANA has made this document an additional reference for the Downstream >> Mapping Address Type Registry, added the note "Each time a code point is >> assigned from this registry, unless the same registration is made in >> both registries, the corresponding Next Hop Address Type Registry must >> be marked "Reserved" to the top of the registry, and added the following >> registrations: >> >> 6 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >> 7 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> >> ACTION 6: >> >> IANA has created the following registry: >> >> Next Hop Address Type Registry >> Registration Procedure(s): Standards Action >> Reference: [RFC-ietf-mpls-proxy-lsp-ping-05] >> Note: Each time a code point is assigned from this registry, unless the >> same registration is made in both registries, the corresponding >> Downstream Address Mapping Registry must be marked "Reserved." >> >> Type Type of Next Hop Address Length IF Length Reference >> 0 Unassigned >> 1 IPv4 Numbered 4 4 [RFC4379] >> 2 IPv4 Unnumbered 4 4 [RFC4379] >> 3 IPv6 Numbered 16 16 [RFC4379] >> 4 IPv6 Unnumbered 16 4 [RFC4379] >> 5 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >> 6 IPv4 Protocol Adj 4 0 [RFC-ietf-mpls-proxy-lsp-ping-05] >> 7 IPv6 Protocol Adj 16 0 [RFC-ietf-mpls-proxy-lsp-ping-05] >> 8-255 Unassigned >> >> Please see >> http://www.iana.org/assignments/mpls-lsp-ping-parameters >> >> >> The updated list of Protocol Registries is available here: >> >> http://www.iana.org/protocols >> >> Please let us know whether the above IANA Actions look OK. As soon as we >> receive your confirmation, we'll notify the RFC Editor that this >> document's IANA Actions are complete. (If this document has a team of >> authors, one reply on behalf of everyone will suffice.) >> >> We'll update the reference when the RFC Editor notifies us that they've >> assigned a number. >> >> Thanks, >> >> Amanda Baber >> IANA Request Specialist >> ICANN >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Apr 10 03:58:11 2015 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 962F71B2C22 for ; Fri, 10 Apr 2015 03:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_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 3WM7uYBIllDI for ; Fri, 10 Apr 2015 03:58:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0637.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::637]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640441B2C25 for ; Fri, 10 Apr 2015 03:58:07 -0700 (PDT) Received: from AMSPR05MB0658.eurprd05.prod.outlook.com (10.242.74.22) by AMSPR05MB0660.eurprd05.prod.outlook.com (10.242.74.24) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 10:56:18 +0000 Received: from AMSPR05MB0658.eurprd05.prod.outlook.com ([10.242.74.22]) by AMSPR05MB0658.eurprd05.prod.outlook.com ([10.242.74.22]) with mapi id 15.01.0130.020; Fri, 10 Apr 2015 10:56:17 +0000 From: David Mozes To: "mpls@ietf.org" Thread-Topic: MPLS meeting in Dallas Thread-Index: AdBzfIhYxLULg4/ISMO2AZHu60qLEg== Date: Fri, 10 Apr 2015 10:56:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.57.242.47] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR05MB0660; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(54356999)(77156002)(33656002)(92566002)(86362001)(50986999)(16236675004)(66066001)(19580395003)(122556002)(87936001)(62966003)(558084003)(40100003)(2656002)(15975445007)(102836002)(110136001)(77096005)(107886001)(2501003)(74316001)(76576001)(450100001)(19300405004)(2351001)(46102003)(19625215002)(229853001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR05MB0660; H:AMSPR05MB0658.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMSPR05MB0660; BCL:0; PCL:0; RULEID:; SRVR:AMSPR05MB0660; x-forefront-prvs: 054231DC40 Content-Type: multipart/alternative; boundary="_000_AMSPR05MB06585FB7F7D559669DACAC33B6FA0AMSPR05MB0658eurp_" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2015 10:56:17.8221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR05MB0660 Archived-At: Subject: [mpls] MPLS meeting in Dallas 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, 10 Apr 2015 10:58:09 -0000 --_000_AMSPR05MB06585FB7F7D559669DACAC33B6FA0AMSPR05MB0658eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi * , During the meeting on Friday there was a presentation of signaling of com= panion label for OAM together with the data plan label , Can someone point me to the relevant daft or presentation ? Thx David --_000_AMSPR05MB06585FB7F7D559669DACAC33B6FA0AMSPR05MB0658eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi * ,

During the  meeting on Friday  there was a= presentation of signaling of companion label for OAM  together with t= he data plan label ,

Can someone point me to the relevant daft or present= ation ?

 

Thx

David

--_000_AMSPR05MB06585FB7F7D559669DACAC33B6FA0AMSPR05MB0658eurp_-- From nobody Fri Apr 10 10:24:37 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 47F671A883F; Fri, 10 Apr 2015 10:24:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2334F1A8838 for ; Fri, 10 Apr 2015 10:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Ntk5mFkMdY14 for ; Fri, 10 Apr 2015 10:24:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4741A8831 for ; Fri, 10 Apr 2015 10:24:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com ([173.37.86.80]:18755) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgcfQ-0003gI-M9 for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Fri, 10 Apr 2015 10:24:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6064; q=dns/txt; s=iport; t=1428686673; x=1429896273; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zcUAx5q3+Yed3JpiRkKKvXC+JtY3+upy/we2+7qmEOQ=; b=A6xC1sMIuPdi8NhKnCYvZSbk46bakqPfB9F36yJ0PKIP4AY+PGF4xEWr am8vJB2F8dvUfovFE4PiOfwNXTP6h9e5uqaSqlX6/AuMC0GfdhyswWq7f hXfEE6KLqBuLPKs1awQLBU57GgTZQPojjjyPFSXQ3rG7q/2UyE/ugHbWd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQAMByhV/4cNJK1cgwxSVwUFxjSGAQKBQEwBAQEBAQF+hCABAQQ6MQ4OAgIBCBgeBQsbFyUCBAENBQmIIQgFzyYBAQEBAQEBAQEBAQEBAQEBAQEBARgEiyeBPYJcEAIBUAeELQWRA4oNgR2DN4cRgXpRBoJjg0wiggMNDxSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,557,1422921600"; d="scan'208";a="407744869" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 10 Apr 2015 17:24:16 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3AHOFUH001859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Apr 2015 17:24:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 10 Apr 2015 12:24:15 -0500 From: "George Swallow (swallow)" To: Loa Andersson , "drafts-approval@iana.org" Thread-Topic: [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) Thread-Index: AQHQclPf7TlV22YwkUeC9dZHZlXeyJ1FI8sAgAD9AoCAAHGfgA== Date: Fri, 10 Apr 2015 17:24:14 +0000 Message-ID: References: <55276FAB.90404@pi.nu> In-Reply-To: <55276FAB.90404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <4CDB5DA2E29D684EA50F805A13807F32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 173.37.86.80 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: swallow@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150410172433.BE4741A8831@ietfa.amsl.com> Resent-Date: Fri, 10 Apr 2015 10:24:33 -0700 (PDT) Resent-From: swallow@cisco.com Archived-At: Archived-At: Cc: "draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.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, 10 Apr 2015 17:24:36 -0000 Yes. On 4/10/15 2:37 AM, "Loa Andersson" wrote: >George, > >In my Shepherd response to the IANA mail, I responded to "QUESTION" >(below) I said it is correct to add the notes to the sub-TLV registry >for Proxy Echo Parameters as we have for the existing sub-TLV >registries. > >Do you agree? > >/Loa > >On 2015-04-09 21:32, George Swallow (swallow) wrote: >> Amanda - >> >> These look fine to me. >> >> Thanks! >> >> George >> >> On 4/8/15 7:29 PM, "Amanda Baber via RT" >>wrote: >> >>> Dear Authors: >>> >>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED >>> >>> We've completed the IANA Actions for the following RFC-to-be: >>> >>> draft-ietf-mpls-proxy-lsp-ping-05 >>> >>> NOTE: The following have been converted to lower case: "could" in >>>TBA-9; >>> "marked" in the notes attached to the registration procedures for the >>> Downstream Mapping and Next Hop registries. >>> >>> QUESTION: The existing sub-TLV registries list notes for each >>> registration range. The new sub-TLV registry for Proxy Echo Parameters >>> doesn't, because I couldn't find a source for those notes in RFC 4379. >>> >>> Should those notes ("This range is for mandatory TLVs or for optional >>> TLVs that require an error message if not recognized," etc.) be >>>included >>> in this registry's registration procedures? If so, are these included >>>or >>> implied in RFC 4379? If there isn't a source for them in RFC 4379, >>> they'll have to be spelled out in this document's IANA Considerations >>> section. >>> >>> ACTION 1: >>> >>> IANA has registered the following Message Types: >>> >>> 3 MPLS Proxy Ping Request [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 4 MPLS Proxy Ping Reply [RFC-ietf-mpls-proxy-lsp-ping-05] >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> >>> ACTION 2: >>> >>> IANA has registered the following TLVs: >>> >>> 23 Proxy Echo >>>=20 >>>Parameters [RFC-ietf-mpls-proxy-lsp-ping-05] [http://www.iana.org/assign >>>me >>> nts/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-23] >>> 24 Reply-to Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs >>> 25 Upstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No >>>Sub-TLVs >>> 26 Downstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No >>> Sub-TLVs >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> >>> ACTION 3: >>> >>> IANA has registered the following Return Codes: >>> >>> 16 Proxy Ping not authorized. [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 17 Proxy Ping parameters need to be >>> modified. [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 18 MPLS Echo Request could not be >>>sent. [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 19 Replying router has FEC mapping for topmost >>> FEC. [RFC-ietf-mpls-proxy-lsp-ping-05] >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> >>> ACTION 4: >>> >>> IANA has created the following registry: >>> >>> Sub-TLVs for TLV Type 23 >>> Reference >>> [RFC4379][RFC-ietf-mpls-proxy-lsp-ping-05] >>> >>> Range Registration Procedures >>> 0-16383 Standards Action >>> 16384-31743 Specification Required >>> 32768-49161 Standards Action >>> 49162-64511 Specification Required >>> >>> Sub-Type Sub-TLV Name Reference Comment >>> 0 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05]=09 >>> 1 Next Hop [RFC-ietf-mpls-proxy-lsp-ping-05]=09 >>> 2-64511 Unassigned =09 >>> 64512-65535 Reserved for Vendor or Private Use [RFC4379] >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> >>> ACTION 5: >>> >>> IANA has made this document an additional reference for the Downstream >>> Mapping Address Type Registry, added the note "Each time a code point >>>is >>> assigned from this registry, unless the same registration is made in >>> both registries, the corresponding Next Hop Address Type Registry must >>> be marked "Reserved" to the top of the registry, and added the >>>following >>> registrations: >>> >>> 6 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 7 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> >>> ACTION 6: >>> >>> IANA has created the following registry: >>> >>> Next Hop Address Type Registry >>> Registration Procedure(s): Standards Action >>> Reference: [RFC-ietf-mpls-proxy-lsp-ping-05] >>> Note: Each time a code point is assigned from this registry, unless the >>> same registration is made in both registries, the corresponding >>> Downstream Address Mapping Registry must be marked "Reserved." >>> >>> Type Type of Next Hop Address Length IF Length Reference >>> 0 Unassigned =09 >>> 1 IPv4 Numbered 4 4 [RFC4379] >>> 2 IPv4 Unnumbered 4 4 [RFC4379] >>> 3 IPv6 Numbered 16 16 [RFC4379] >>> 4 IPv6 Unnumbered 16 4 [RFC4379] >>> 5 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 6 IPv4 Protocol Adj 4 0 [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 7 IPv6 Protocol Adj 16 0 [RFC-ietf-mpls-proxy-lsp-ping-05] >>> 8-255 Unassigned >>> >>> Please see >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters >>> >>> >>> The updated list of Protocol Registries is available here: >>> >>> http://www.iana.org/protocols >>> >>> Please let us know whether the above IANA Actions look OK. As soon as >>>we >>> receive your confirmation, we'll notify the RFC Editor that this >>> document's IANA Actions are complete. (If this document has a team of >>> authors, one reply on behalf of everyone will suffice.) >>> >>> We'll update the reference when the RFC Editor notifies us that they've >>> assigned a number. >>> >>> Thanks, >>> >>> Amanda Baber >>> IANA Request Specialist >>> ICANN >>> >> > >--=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 Fri Apr 10 11:06:13 2015 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 539D81B29E6; Fri, 10 Apr 2015 11:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 r3E-URA25Mwd; Fri, 10 Apr 2015 11:06:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3951B29DD; Fri, 10 Apr 2015 11:06:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410180610.17861.3355.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 11:06:10 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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, 10 Apr 2015 18:06:11 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ From nobody Fri Apr 10 11:35:28 2015 Return-Path: X-Original-To: expand-draft-ietf-mpls-proxy-lsp-ping.all@virtual.ietf.org Delivered-To: mpls@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3CE4B1B2D31; Fri, 10 Apr 2015 11:35:26 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mpls-proxy-lsp-ping.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B381B2D30 for ; Fri, 10 Apr 2015 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] 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 zjsajH7HSq9X for ; Fri, 10 Apr 2015 11:35:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E121B2CDB for ; Fri, 10 Apr 2015 11:35:23 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:44328 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ygdlz-0002IM-5u for draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org; Fri, 10 Apr 2015 11:35:23 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3AIZHu8030966 for ; Fri, 10 Apr 2015 18:35:17 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 768D6C204D2; Fri, 10 Apr 2015 18:35:17 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: References: <55276FAB.90404@pi.nu> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #815506 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 10 Apr 2015 18:35:17 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-mpls-proxy-lsp-ping.all@ietf.org Resent-Message-Id: <20150410183523.F3E121B2CDB@ietfa.amsl.com> Resent-Date: Fri, 10 Apr 2015 11:35:23 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: Cc: draft-ietf-mpls-proxy-lsp-ping.all@tools.ietf.org Subject: [mpls] [IANA #815506] Protocol Action: 'Proxy MPLS Echo Request' to Proposed Standard (draft-ietf-mpls-proxy-lsp-ping-05.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval@iana.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 18:35:26 -0000 Hi, This is complete, and I think I see where these notes came from in RFC 4379: Section 3. Packet Format "Types less than 32768 (i.e., with the high-order bit equal to 0) are mandatory TLVs that MUST either be supported by an implementation or result in the return code of 2 ("One or more of the TLVs was not understood") being sent in the echo response. "Types greater than or equal to 32768 (i.e., with the high-order bit equal to 1) are optional TLVs that SHOULD be ignored if the implementation does not understand or support them." I'm assuming that the first paragraph equates to "This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized." Section 7. IANA Considerations "Values from "Specification Required" ranges MUST be registered with IANA. The request MUST be made via an Experimental RFC that describes the format and procedures for using the code point; the actual assignment is made during the IANA actions for the RFC." I'll tell the RFC Editor the actions are complete. Thanks! Amanda On Fri Apr 10 17:24:47 2015, swallow@cisco.com wrote: > Yes. > > On 4/10/15 2:37 AM, "Loa Andersson" wrote: > > >George, > > > >In my Shepherd response to the IANA mail, I responded to "QUESTION" > >(below) I said it is correct to add the notes to the sub-TLV registry > >for Proxy Echo Parameters as we have for the existing sub-TLV > >registries. > > > >Do you agree? > > > >/Loa > > > >On 2015-04-09 21:32, George Swallow (swallow) wrote: > >> Amanda - > >> > >> These look fine to me. > >> > >> Thanks! > >> > >> George > >> > >> On 4/8/15 7:29 PM, "Amanda Baber via RT" > >>wrote: > >> > >>> Dear Authors: > >>> > >>> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > >>> > >>> We've completed the IANA Actions for the following RFC-to-be: > >>> > >>> draft-ietf-mpls-proxy-lsp-ping-05 > >>> > >>> NOTE: The following have been converted to lower case: "could" in > >>>TBA-9; > >>> "marked" in the notes attached to the registration procedures for the > >>> Downstream Mapping and Next Hop registries. > >>> > >>> QUESTION: The existing sub-TLV registries list notes for each > >>> registration range. The new sub-TLV registry for Proxy Echo Parameters > >>> doesn't, because I couldn't find a source for those notes in RFC 4379. > >>> > >>> Should those notes ("This range is for mandatory TLVs or for optional > >>> TLVs that require an error message if not recognized," etc.) be > >>>included > >>> in this registry's registration procedures? If so, are these included > >>>or > >>> implied in RFC 4379? If there isn't a source for them in RFC 4379, > >>> they'll have to be spelled out in this document's IANA Considerations > >>> section. > >>> > >>> ACTION 1: > >>> > >>> IANA has registered the following Message Types: > >>> > >>> 3 MPLS Proxy Ping Request [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 4 MPLS Proxy Ping Reply [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> > >>> Please see > >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters > >>> > >>> > >>> ACTION 2: > >>> > >>> IANA has registered the following TLVs: > >>> > >>> 23 Proxy Echo > >>> > >>>Parameters [RFC-ietf-mpls-proxy-lsp-ping-05] [http://www.iana.org/assign > >>>me > >>> nts/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-23] > >>> 24 Reply-to Address [RFC-ietf-mpls-proxy-lsp-ping-05] No Sub-TLVs > >>> 25 Upstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No > >>>Sub-TLVs > >>> 26 Downstream Neighbor Address [RFC-ietf-mpls-proxy-lsp-ping-05] No > >>> Sub-TLVs > >>> > >>> Please see > >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters > >>> > >>> > >>> ACTION 3: > >>> > >>> IANA has registered the following Return Codes: > >>> > >>> 16 Proxy Ping not authorized. [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 17 Proxy Ping parameters need to be > >>> modified. [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 18 MPLS Echo Request could not be > >>>sent. [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 19 Replying router has FEC mapping for topmost > >>> FEC. [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> > >>> Please see > >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters > >>> > >>> > >>> ACTION 4: > >>> > >>> IANA has created the following registry: > >>> > >>> Sub-TLVs for TLV Type 23 > >>> Reference > >>> [RFC4379][RFC-ietf-mpls-proxy-lsp-ping-05] > >>> > >>> Range Registration Procedures > >>> 0-16383 Standards Action > >>> 16384-31743 Specification Required > >>> 32768-49161 Standards Action > >>> 49162-64511 Specification Required > >>> > >>> Sub-Type Sub-TLV Name Reference Comment > >>> 0 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 1 Next Hop [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 2-64511 Unassigned > >>> 64512-65535 Reserved for Vendor or Private Use [RFC4379] > >>> > >>> Please see > >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters > >>> > >>> > >>> ACTION 5: > >>> > >>> IANA has made this document an additional reference for the Downstream > >>> Mapping Address Type Registry, added the note "Each time a code point > >>>is > >>> assigned from this registry, unless the same registration is made in > >>> both registries, the corresponding Next Hop Address Type Registry must > >>> be marked "Reserved" to the top of the registry, and added the > >>>following > >>> registrations: > >>> > >>> 6 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 7 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> > >>> Please see > >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters > >>> > >>> > >>> ACTION 6: > >>> > >>> IANA has created the following registry: > >>> > >>> Next Hop Address Type Registry > >>> Registration Procedure(s): Standards Action > >>> Reference: [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> Note: Each time a code point is assigned from this registry, unless the > >>> same registration is made in both registries, the corresponding > >>> Downstream Address Mapping Registry must be marked "Reserved." > >>> > >>> Type Type of Next Hop Address Length IF Length Reference > >>> 0 Unassigned > >>> 1 IPv4 Numbered 4 4 [RFC4379] > >>> 2 IPv4 Unnumbered 4 4 [RFC4379] > >>> 3 IPv6 Numbered 16 16 [RFC4379] > >>> 4 IPv6 Unnumbered 16 4 [RFC4379] > >>> 5 Reserved [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 6 IPv4 Protocol Adj 4 0 [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 7 IPv6 Protocol Adj 16 0 [RFC-ietf-mpls-proxy-lsp-ping-05] > >>> 8-255 Unassigned > >>> > >>> Please see > >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters > >>> > >>> > >>> The updated list of Protocol Registries is available here: > >>> > >>> http://www.iana.org/protocols > >>> > >>> Please let us know whether the above IANA Actions look OK. As soon as > >>>we > >>> receive your confirmation, we'll notify the RFC Editor that this > >>> document's IANA Actions are complete. (If this document has a team of > >>> authors, one reply on behalf of everyone will suffice.) > >>> > >>> We'll update the reference when the RFC Editor notifies us that they've > >>> assigned a number. > >>> > >>> Thanks, > >>> > >>> Amanda Baber > >>> IANA Request Specialist > >>> ICANN > >>> > >> > > > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > From nobody Fri Apr 10 12:05:25 2015 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 68D7C1A898C; Fri, 10 Apr 2015 12:05:24 -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 os2s12Ek8KCO; Fri, 10 Apr 2015 12:05:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4D1A87BB; Fri, 10 Apr 2015 12:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410190523.18379.35264.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 12:05:23 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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, 10 Apr 2015 19:05:24 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ From nobody Fri Apr 10 12:05:34 2015 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 A0B551B2DA3; Fri, 10 Apr 2015 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 5We8p1G-J5_W; Fri, 10 Apr 2015 12:05:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 598401B2D84; Fri, 10 Apr 2015 12:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410190525.18379.65754.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 12:05:25 -0700 From: IETF Secretariat Archived-At: Subject: [mpls] ID Tracker State Update Notice: 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, 10 Apr 2015 19:05:32 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mpls-proxy-lsp-ping/ From nobody Sat Apr 11 12:00:41 2015 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 BDAED1B2C59; Sat, 11 Apr 2015 12:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 9YhJknOWn8Ph; Sat, 11 Apr 2015 12:00:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98D61B2C6B; Sat, 11 Apr 2015 12:00:32 -0700 (PDT) Received: from mb-aye.local (160.sub-70-211-1.myvzw.com [70.211.1.160]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3BIwWSG000395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Apr 2015 18:58:33 GMT (envelope-from joelja@bogus.com) To: Ian Cox , Erik Nordmark , Xuxiaohu , "nvo3@ietf.org" references: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> From: joel jaeggli message-id: <55296ED2.9030204@bogus.com> Date: Sat, 11 Apr 2015 11:58:26 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN" Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [mpls] [nvo3] [Bier] Encapsulation considerations 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, 11 Apr 2015 19:00:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/9/15 3:50 PM, Ian Cox wrote: > MPLS has no indication in the label stack for intermediate nodes what > the underlying payload is. To achieve better load balancing of MPLS > traffic most hardware today looks to see if the first nibble is 4 or > 6 then parse into the payload under the belief that it is a IPv4 or > v6 packet and parse the address fields out to use in the ECMP hash. Some of them also use the TOS or DSCP bits as part of the hashkey with the additional ensuing entertainment value that provides. > If your defining something new please put a "next protocol" or type > field in the preceding header so it clear what the next protocol is. > The 4 or 6 guess for the underlying MPLS payload being an IP packet > was fine until IEEE allocated MAC addresses starting with 6. This > issue is specific PWE3 packets that do not contain the control word. >=20 >=20 > Ian >=20 > -----Original Message----- From: BIER [mailto:bier-bounces@ietf.org] > On Behalf Of Erik Nordmark Sent: Thursday, April 09, 2015 10:50 AM=20 > To: Xuxiaohu; Erik Nordmark; nvo3@ietf.org Cc: mpls@ietf.org; BIER; > sfc@ietf.org Subject: Re: [Bier] [nvo3] Encapsulation considerations >=20 > On 4/8/15 7:20 PM, Xuxiaohu wrote: >> Hi Erik, >>=20 >>> But I couldn't tell from the emails on the BIER list whether the >>> constraints on the first nibble value is a strict requirement in >>> all cases, or whether it is conditional on something (and if so, >>> what is the condition). >> The conditions that I have thought of include: 1) the encapsulation >> is sensitive to packet misordering; 2) the encapsulation may be >> transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use >> the contents of the MPLS payload to select the ECMP path. > Those are conditions when the misordering would happen. But are you=20 > saying that any LSR is free to use the MPLS payload (including > looking for 4 and 6 in the first nibble) to determine whether the > packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6 > fields for ECMP purposes? >=20 > Thanks, Erik >=20 >>=20 >> Best regards, Xiaohu >>=20 >>> Once I know that answer we can definitely add some text pointing >>> out the issue. >>>=20 >>> Thanks, Erik >>>=20 >>>> Best regards, Xiaohu >>>>=20 >>>>> -----Original Message----- From: Erik Nordmark >>>>> [mailto:nordmark@sonic.net] Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5= 5:01 To: >>>>> nvo3@ietf.org Subject: [nvo3] Encapsulation considerations >>>>>=20 >>>>>=20 >>>>> I presented part of this at the most recent NVO3 interim >>>>> meeting.The full >>>> 12 >>>>> areas of considerations where presented at RTGWG earlier this >>>>> week. The draft is=20 >>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ and the >>>>> slides are at=20 >>>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>>> >>>>> >>>>>=20 There is probably additional things in there to consider for NVO3, >>>>> and >>>> advice >>>>> that can be reused to make it easier to move NVO3 forward. >>>>>=20 >>>>> Regards, Erik >>>>>=20 >>>>>=20 >>>>>=20 >>>> _______________________________________________ nvo3 mailing >>>> list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 >>>>=20 >>=20 >=20 > _______________________________________________ BIER mailing list=20 > BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier=20 > _______________________________________________ nvo3 mailing list=20 > nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 >=20 --UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUpbtMACgkQ8AA1q7Z/VrINqACeMRbp54zcWVo6pBHXm8GukO42 mIAAn1cqvs0a5eQLK26KUZIIBeIJyg2s =7sEa -----END PGP SIGNATURE----- --UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN-- From nobody Sat Apr 11 23:04:02 2015 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 BF7D71B34DB; Sat, 11 Apr 2015 23:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Bg9XuZOWSdRu; Sat, 11 Apr 2015 23:03:56 -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 0AB731B34D8; Sat, 11 Apr 2015 23:03:55 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-7b-5529b4114d58 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.FD.12456.214B9255; Sun, 12 Apr 2015 01:53:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Sun, 12 Apr 2015 02:03:46 -0400 From: Gregory Mirsky To: "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+Cg== Date: Sun, 12 Apr 2015 06:03:46 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> 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: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPoK7QFs1Qg6M7xSwuPnzKbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVsev+EfaCLXMZ K37OXM3SwPirg7GLkZNDQsBE4tmthWwQtpjEhXvrgWwuDiGBo4wS7dvfsUA4yxklfgOtAqli EzCSeLGxhx3EFhE4zSjxpVEJxGYW8JK49HwaM4gtLGAr0d/9hgmixknizLIrULaexJO578G2 sQioSmz7+JQFxOYV8JV4/PQeWJwR6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwph K0l8/D2fHaI+X2Lh+dtsEDMFJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY +8yBx0zI4gsY2VcxcpQWp5blphsZbGIERtIxCTbdHYx7XloeYhTgYFTi4X3grhEqxJpYVlyZ e4hRmoNFSZx30YODIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYhX0OJQgcSRWNLD3yTClF Idn9TnS22wvXBfnt/1f2fN5qLVvA/dm59ujJBeIV7wMuXjkVbrJy+36rzw9keCeYVlm98L8W P63tV5n+/bIbu88uVg9tttFnmPJ9v43V2h7pw8kz9klFB35qaBK/drRJVPf2v8l7sxztcooS 84quzv4gaGEcyletxFKckWioxVxUnAgAAAoC14UCAAA= Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-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: Sun, 12 Apr 2015 06:03:59 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·         Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

·         Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

·         Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_-- From nobody Sun Apr 12 11:04:30 2015 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 ED1BB1A1B60; Sun, 12 Apr 2015 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 r_K4h-p9ygPo; Sun, 12 Apr 2015 11:04:19 -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 127251A1B5E; Sun, 12 Apr 2015 11:04:17 -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 BRH69625; Sun, 12 Apr 2015 18:04:15 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Apr 2015 19:04:14 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Sun, 12 Apr 2015 11:03:39 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQ Date: Sun, 12 Apr 2015 18:03:38 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.94] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-teas-rsvp-ingress-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: Sun, 12 Apr 2015 18:04:26 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@iet= f.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. Can you give more details about the cases in which false positives may be p= roduced? Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-cha= irs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·        Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·        Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

·        Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

Can you give more deta= ils about the cases in which false positives may be produced?

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_-- From nobody Sun Apr 12 11:35:10 2015 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 BE7D41A873B for ; Sun, 12 Apr 2015 11:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 aF_ruM9Q0FaL for ; Sun, 12 Apr 2015 11:35:06 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B411A873C for ; Sun, 12 Apr 2015 11:35:06 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so82175620pdb.1 for ; Sun, 12 Apr 2015 11:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=H9ztCLSe70Sax/8i5RC7bHHiY5oijJnows+SZD1RDZ8=; b=QDGwlxEFOAWLfQaOFVrJfzkMIkP2ZFkGAbezwYSAxSZhiOR3KMaMwxwquJgmYyO/qs liBQ4NU9UofMyQpLOPRmZ9OBE5S6GWL2Qwj7CckddsLWahAaeKMvn37Mxue6lUjPHF2s L01VqK0umk50kifiW5AeRnXV33qGzmmGSdm9vjF29XdpnLYLwb78OX3DBo3V9dklMN7N mFN1D2nodabMNnRQRUftt+5SqBsl8PmJValuJK62n4ZnYMlmiU3CiKOqPg21VEuvC23t lZj6be4r1I46a5xs6FVqgY2T78gN1IBkvlZs8tvYaMWH9M96lIe+K5qjz+UcLi3jfFTt 16Ag== X-Received: by 10.68.241.9 with SMTP id we9mr19650996pbc.59.1428863706003; Sun, 12 Apr 2015 11:35:06 -0700 (PDT) Received: from NoboAkiyaPC (ip-64-134-223-233.public.wayport.net. [64.134.223.233]) by mx.google.com with ESMTPSA id bs4sm4948431pbc.3.2015.04.12.11.34.49 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 12 Apr 2015 11:35:05 -0700 (PDT) From: "Nobo Akiya" To: , "'Ross Callon'" , References: <031c01d07175$79858450$6c908cf0$@olddog.co.uk> In-Reply-To: <031c01d07175$79858450$6c908cf0$@olddog.co.uk> Date: Sun, 12 Apr 2015 11:34:27 -0700 Message-ID: <00ed01d0754f$5e7d98e0$1b78caa0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01D07514.B22354C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQPgMp+F85EfvPJp+pmFDDXz24DS/gILku6kmRnZdTA= Content-Language: en-ca Archived-At: Cc: mpls-chairs@tools.ietf.org, 'Loa Andersson' Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 12 Apr 2015 18:35:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EE_01D07514.B22354C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Adrian, Many thanks for your comments. Please see in-line with [NOBO]. From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: April-07-15 1:58 PM To: 'Ross Callon'; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; 'Loa Andersson' Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 Hi, I have read the most recent revision of this document and have no objection to the WG requesting its publication. I have some comments that I think should be addressed before publication. Thanks, Adrian I don't believe this document updates 4379. It certainly does not explain how it updates 4379, and since 7110 did not update 4379, it seems unlikely that this document does. However, if the authors feel that it is intended to update 4379 (i.e., an implementation of 4379 will not be complete without also including the function of this document, for example, there is a problem in 4379 that this document fixes) then the document needs to explain what the update is and how 4379 implementations are affected. I *can* believe that this document updates 7110, but it needs to explain it and (presumably) observe that 7110 is not complete without this document. (Actually, section 3.1 has most of this text, but the Introduction should make the clear linkage to the "update".) [NOBO] Let me discuss this one with authors and get back to you. --- Section 3.2 gives clear instructions and guidance on forming the Reply Mode Order TLV but not on what to do if a received TLV deviates from the MUST and MUST NOT instructions. Options might include ignoring errors, ignoring the TLV, ignoring the message. But presumably not sending an error response (because how would you know how to send it?) [NOBO] That's a good point. What the document really state is that The Reply Mode value 5 (Reply via Specified Path) MAY be repeated but all other Reply Mode values MUST NOT be repeated. Will update the document to make it clear. --- The last guidance in 3.2 is: 8. Reply Mode value 1 (Do not reply) SHOULD NOT be used in the Reply Mode Order TLV. "SHOULD NOT" means "you can do it if you have good reason." Please can you explain the good reason and how the receiver should interpret a "Do not reply" mode coming, say, third in a list of five modes. [NOBO] Another good point. Here, we should replace the "SHOULD NOT" to "MUST NOT" as exhausting all specified reply mode options implicitly means that the responder does not have any path to reply and no message will be send anyways. --- The security considerations are hard to believe! At the very least, 7110 makes some security observations that surely apply here. [NOBO] At the least, we will reference RFC7110 in the Security Consideration section. Additionally, we'll see if there are any additional vulnerabilities exposed by the changes and add those (if any). Thanks! -Nobo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: 20 March 2015 14:04 To: mpls@ietf.org Cc: Loa Andersson; mpls-chairs@tools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01. Because this WGLC will span the IETF in Dallas, it will be extended to three weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org ). There are no IPR disclosures against this document. All the authors have stated that they are not aware of any IPR that relates to this draft. This working group last call ends Friday April 10, 2015. Ross for the MPLS WG chairs ------=_NextPart_000_00EE_01D07514.B22354C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Adrian,

 

Many thanks = for your comments.

 

Please see = in-line with [NOBO].

 

From:<= /b> mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian = Farrel
Sent: April-07-15 1:58 PM
To: 'Ross Callon'; = mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org; 'Loa = Andersson'
Subject: Re: [mpls] working group last call for = draft-ietf-mpls-lsp-ping-reply-mode-simple-01

=

 

Hi,

 

I have read the most recent revision of this document and have no = objection to the WG requesting its publication.

 

I have some comments that I think should be addressed before = publication.

 

Thanks,

Adrian

 

I don't believe this document updates 4379. It certainly does = not

explain how it updates 4379, and since 7110 did not update 4379, = it

seems unlikely that this document does. However, if the authors feel = that

it is intended to update 4379 (i.e., an implementation of 4379 will = not

be complete without also including the function of this document, for =

example, there is a problem in 4379 that this document fixes) then = the

document needs to explain what the update is and how 4379 = implementations

are affected.

 

I *can* believe that this document updates 7110, but it needs to = explain

it and (presumably) observe that 7110 is not complete without = this

document. (Actually, section 3.1 has most of this text, but = the

Introduction should make the clear linkage to the = "update".)

 

[NOBO] Let = me discuss this one with authors and get back to you.

 

---

 

Section 3.2 gives clear instructions and guidance on forming the = Reply

Mode Order TLV but not on what to do if a received TLV deviates from = the

MUST and MUST NOT instructions. Options might include ignoring = errors,

ignoring the TLV, ignoring the message. But presumably not sending = an

error response (because how would you know how to send = it?)

 

[NOBO] = That’s a good point. What the document really state is that The = Reply Mode value 5 (Reply via Specified Path) MAY be repeated but all = other Reply Mode values MUST NOT be repeated. Will update the document = to make it clear.

 

---

            =             &= nbsp; =             &= nbsp;           &n= bsp;  

The last guidance in 3.2 is:

 

   8.  Reply Mode value 1 (Do not reply) SHOULD NOT be = used in the Reply

       Mode Order = TLV.

 

"SHOULD NOT" means "you can do it if you have good = reason." Please can

you explain the good reason and how the receiver should interpret a =

"Do not reply" mode coming, say, third in a list of five = modes.

 

[NOBO] = Another good point. Here, we should replace the “SHOULD NOT” = to “MUST NOT” as exhausting all specified reply mode options = implicitly means that the responder does not have any path to reply and = no message will be send anyways.

 

---

 

The security considerations are hard to = believe!

At the very least, 7110 makes some security observations that = surely

apply here.

 

[NOBO] At = the least, we will reference RFC7110 in the Security Consideration = section. Additionally, we’ll see if there are any additional = vulnerabilities exposed by the changes and add those (if = any).

 

Thanks!<= /o:p>

 

-Nobo

 

From: mpls [mailto:mpls-bounces@ietf.org] = On Behalf Of Ross Callon
Sent: 20 March 2015 = 14:04
To: mpls@ietf.org
Cc: Loa = Andersson; mpls-chairs@tools.ietf.org=
Subject: [mpls] working group last call for = draft-ietf-mpls-lsp-ping-reply-mode-simple-01

=

 

Working = Group,

 

This is to = initiate a working group last call on = draft-ietf-mpls-lsp-ping-reply-mode-simple-01.

Because this = WGLC will span the IETF in Dallas, it will be extended to three weeks. =

 

Please send = your comments to the mpls wg mailing list (mpls@ietf.org).

 

There are no = IPR disclosures against this document. All the authors have stated that = they

are not = aware of any IPR that relates to this = draft.

 

This working = group last call ends Friday  April 10, 2015.  =

 

Ross

for the MPLS = WG chairs

 

 

------=_NextPart_000_00EE_01D07514.B22354C0-- From nobody Mon Apr 13 09:03:42 2015 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 773D31ACE31 for ; Mon, 13 Apr 2015 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9-pRy4j_PUD for ; Mon, 13 Apr 2015 09:03:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239BE1ACE1B for ; Mon, 13 Apr 2015 09:03:29 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1205.namprd05.prod.outlook.com (25.160.104.145) with Microsoft SMTP Server (TLS) id 15.1.130.23; Mon, 13 Apr 2015 16:03:27 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 13 Apr 2015 16:03:27 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0136.014; Mon, 13 Apr 2015 16:03:27 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 Thread-Index: AQHQYxaymmEqkSnB6UOwcgu2gEley51LPmXA Date: Mon, 13 Apr 2015 16:03:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.13] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1205; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(60444003)(377454003)(164054003)(2501003)(46102003)(87936001)(19609705001)(19580405001)(2351001)(40100003)(19580395003)(229853001)(122556002)(2656002)(19300405004)(16236675004)(230783001)(86362001)(74316001)(92566002)(106116001)(18717965001)(19625215002)(15975445007)(102836002)(66066001)(54356999)(50986999)(76176999)(62966003)(77156002)(76576001)(110136001)(99286002)(2950100001)(33656002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY1PR0501MB1430; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 0545EFAC9A Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB143031F1768A8854BA4CB30EA5E70BY1PR0501MB1430_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 16:03:26.7178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 X-OriginatorOrg: juniper.net Archived-At: Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 13 Apr 2015 16:03:36 -0000 --_000_BY1PR0501MB143031F1768A8854BA4CB30EA5E70BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This working group last call has ended, with sufficient support and no oppo= sition. There have however been a number of comments received. Thanks to ev= eryone who took the time to review the draft and comment. Authors, please update the draft in response to the comments. After this is= done, I will submit the document for publication. Thanks, Ross From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon Sent: Friday, March 20, 2015 10:04 AM To: mpls@ietf.org Cc: Loa Andersson; mpls-chairs@tools.ietf.org Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-reply-= mode-simple-01 Working Group, This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-r= eply-mode-simple-01. Because this WGLC will span the IETF in Dallas, it will be extended to thre= e weeks. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors have st= ated that they are not aware of any IPR that relates to this draft. This working group last call ends Friday April 10, 2015. Ross for the MPLS WG chairs --_000_BY1PR0501MB143031F1768A8854BA4CB30EA5E70BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This working group last c= all has ended, with sufficient support and no opposition. There have howeve= r been a number of comments received. Thanks to everyone who took the time to review the draft and comment.

 <= /p>

Authors, please update th= e draft in response to the comments. After this is done, I will submit the = document for publication.

 <= /p>

Thanks, Ross

 <= /p>

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Friday, March 20, 2015 10:04 AM
To: mpls@ietf.org
Cc: Loa Andersson; mpls-chairs@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -reply-mode-simple-01

 

Working Group,

 

This is to initiate a working group las= t call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01.<= /p>

Because this WGLC will span the IETF in= Dallas, it will be extended to three weeks.

 

Please send your comments to the mpls w= g mailing list (mpls@ietf.org).

 

There are no IPR disclosures against th= is document. All the authors have stated that they

are not aware of any IPR that relates t= o this draft.

 

This working group last call ends Frida= y  April 10, 2015. 

 

Ross

for the MPLS WG chairs

 

 

--_000_BY1PR0501MB143031F1768A8854BA4CB30EA5E70BY1PR0501MB1430_-- From nobody Mon Apr 13 11:58:39 2015 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 31ABE1B2FDD; Mon, 13 Apr 2015 11:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mmZbqyi_vR7v; Mon, 13 Apr 2015 11:58:35 -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 965A61B2A2D; Mon, 13 Apr 2015 11:58:35 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-5d-552baee739f4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 40.FB.17241.7EEAB255; Mon, 13 Apr 2015 13:56:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 13 Apr 2015 14:58:28 -0400 From: Gregory Mirsky To: "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6A== Date: Mon, 13 Apr 2015 18:58:28 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn+7zddqhBluatS2mvv3JbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVMWFNL3PBdM+K 8xPOsjQwbrfvYuTgkBAwkZhxuqiLkRPIFJO4cG89WxcjF4eQwFFGiYWXeplBEkICyxklNp4N A7HZBIwkXmzsYQexRQROMkr83Q5mMwt4SVx6Pg2sXljARmLe5S5GkPkiAo4SKxfnQJTrSax5 DtHKIqAq8flLHwtICa+Ar8ST7fogYUagE76fWsMEMVFc4taT+UwQpwlILNlznhnCFpV4+fgf K4StJDFp6TlWiPp8ie/rp7CA2LwCghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDcxAqPnmASb4w7GBZ8sDzEKcDAq8fAmVGmFCrEm lhVX5h5ilOZgURLnLbtyMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4+GANV6lIdocZzVW qm8+3rrleElRfmzOPKbFO9yfJlj2qXVvYZZTupPJ929XiUWXvoXCcxZbz51pb2bGXDnO4rFG Xe36qh1Cvh8c02yE70hYt3Us0U5fYv4rw5UtwuNY3Ycbv23/ydxfdvqkS9a/r+XyD24rHpu3 58izKRumFDjlXQ25XM56XomlOCPRUIu5qDgRAKBq0SN/AgAA Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-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: Mon, 13 Apr 2015 18:58:38 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slowe= r to detect failure and perform switchover then an arbitrary local protecti= on method. I believe that that is not the case and, as been demonstrated by= deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec= switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. o The last in Section 1.1 suggests that node R3 may detect failure of the= node L1 through monitoring BFD session between two nodes. Firstly, if this= is multi-hop BFD session over IP network, then there's no guarantee that i= ts path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed= that RFC 5884 may be used, I have to remind, that RFC 5884 operates betwee= n LSP end points and R1 is not end point. Thus, Sub-Path Maintenance Entity= (SPME) co-routed with the segment R1-L3 MUST be established. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any l= isted LSR in the EGRESS_BACKUP object it SHOULD select it locally and recor= d it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i= .e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that = is required when selecting backup egress. That is serious security concern = and must be properly addressed in Security Considerations section of the dr= aft. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Editors,

please kindly consider my comments to the current ve= rsion of this work:

·         Introduction

o   The third paragraph mentions that an end-to-= end protection may be slower to detect failure and perform switchover then = an arbitrary local protection method. I believe that that is not the case a= nd, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover = and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.

o   The last in Section 1.1 suggests that node R= 3 may detect failure of the node L1 through monitoring BFD session between = two nodes. Firstly, if this is multi-hop BFD session over IP network, then = there’s no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that R= FC 5884 may be used, I have to remind, that RFC 5884 operates between LSP e= nd points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)= co-routed with the segment R1-L3 MUST be established.

·         Section 5.2

o   The third paragraph assumes that if a PLR ca= nnot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD = select it locally and record it in the EGRESS_BACKUP object. I believe that= that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is requ= ired when selecting backup egress. That is serious security concern and mus= t be properly addressed in Security Considerations section of the draft.

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_-- From nobody Mon Apr 13 20:19:38 2015 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 DE37C1B3291; Mon, 13 Apr 2015 20:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 L8qd5lRbyHBD; Mon, 13 Apr 2015 20:19:33 -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 B057F1B3293; Mon, 13 Apr 2015 20:19:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU73010; Tue, 14 Apr 2015 03:19:30 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 04:19:29 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 13 Apr 2015 20:19:26 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6ABbWMEw Date: Tue, 14 Apr 2015 03:19:26 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37F079@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.193] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Comments to draft-ietf-teas-rsvp-egress-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, 14 Apr 2015 03:19:36 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Monday, April 13, 2015 2:58 PM To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chairs@ietf= .org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slowe= r to detect failure and perform switchover then an arbitrary local protecti= on method. I believe that that is not the case and, as been demonstrated by= deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec= switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. [Huaimo] It seems that the statement in the paragraph is true. For a globa= l protection (or an end-to-end protection), it may take more time since the= time includes the propagation time and processing time. The propagation ti= me may depend on the size of the network. In general, the bigger the networ= k, the longer the propagation delay. The processing time may comprise the r= elated processing time on every node along the path from the egress node to= a node interesting the failure and doing switchover. o The last in Section 1.1 suggests that node R3 may detect failure of the= node L1 through monitoring BFD session between two nodes. Firstly, if this= is multi-hop BFD session over IP network, then there's no guarantee that i= ts path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed= that RFC 5884 may be used, I have to remind, that RFC 5884 operates betwee= n LSP end points and R1 is not end point. Thus, Sub-Path Maintenance Entity= (SPME) co-routed with the segment R1-L3 MUST be established. [Huaimo] It seems that R3 is the upstream node of L1 and there is no multi-= hop BFD session between R3 and L1. This current version of the document focuses on extending the protection of= RFC 4090 from a transit node to an egress node. It seems that it is better= to have another document for others if needed. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any l= isted LSR in the EGRESS_BACKUP object it SHOULD select it locally and recor= d it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i= .e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that = is required when selecting backup egress. That is serious security concern = and must be properly addressed in Security Considerations section of the dr= aft. [Huaimo] This paragraph says that the upstream node of the primary egress k= nows/determines that there is not any backup egress given for the primary = egress. In this case, the upstream node selects a backup egress according t= o a local policy. The upstream node may not need to be aware of any service= s or CEs. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, April 13, 2015 2:58 PM
To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chai= rs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection

 

Dear Editors,

please kindly consider my comments to the current ve= rsion of this work:

·        Introduction

o   The third paragraph mentions that an end-to-= end protection may be slower to detect failure and perform switchover then = an arbitrary local protection method. I believe that that is not the case a= nd, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover = and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.

[Huaimo] It seems that= the statement in the paragraph is true.  For a global protection (or = an end-to-end protection), it may take more time since the time includes th= e propagation time and processing time. The propagation time may depend on the size of the network. In general, the bi= gger the network, the longer the propagation delay. The processing time may= comprise the related processing time on every node along the path from the= egress node to a node interesting the failure and doing switchover.

o   The last in Section 1.1 suggests that node R= 3 may detect failure of the node L1 through monitoring BFD session between = two nodes. Firstly, if this is multi-hop BFD session over IP network, then = there’s no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that R= FC 5884 may be used, I have to remind, that RFC 5884 operates between LSP e= nd points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)= co-routed with the segment R1-L3 MUST be established.

[Huaimo] It seems that= R3 is the upstream node of L1 and there is no multi-hop BFD session betwee= n R3 and L1.

This current version o= f the document focuses on extending the protection of RFC 4090 from a trans= it node to an egress node. It seems that it is better to have another docum= ent for others if needed.

·        Section 5.2

o   The third paragraph assumes that if a PLR ca= nnot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD = select it locally and record it in the EGRESS_BACKUP object. I believe that= that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is requ= ired when selecting backup egress. That is serious security concern and mus= t be properly addressed in Security Considerations section of the draft.

[Huaimo] This paragrap= h says that the upstream node of the primary egress knows/determines that &= nbsp;there is not any backup egress given for the primary egress. In this c= ase, the upstream node selects a backup egress according to a local policy. The upstream node may not need to be aware of= any services or CEs.    

 

Regards,

    &= nbsp;           Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_-- From nobody Wed Apr 15 15:22:49 2015 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 5331E1A1B34 for ; Wed, 15 Apr 2015 15:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 cQiBK-7s4mfH for ; Wed, 15 Apr 2015 15:22:44 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D14D1A1B29 for ; Wed, 15 Apr 2015 15:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16080; q=dns/txt; s=iport; t=1429136565; x=1430346165; h=from:to:subject:date:message-id:mime-version; bh=VNxb9J5L/7iwLc+n22vydsS1Z5jO0/7GhCdVrqUlucA=; b=iQr47juAzsfk34jahmeCtijc6+XFXwRuDHuwZKFQeu8NF5VBK+8H/CMt RWwsn6FhSEjQBgtqAV6+6SU7UEqA+DCRFonp64oQxKqdvKYJ+6rybUEZz eA1ngWswapOTRlv4Am9cLdeEftcxBDxSd9cyqgZyPw75nlXDp064Y+duC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C/BABd5C5V/5xdJa1cgkVHUl0ExXEJgU+HRDgUAQEBAQEBAX2EJ4ELAYEAJwSIPQ2gaqVolFsFkRaDe4YdgR06gn6JFocOIoIDHIFQgjN/AQEB X-IronPort-AV: E=Sophos;i="5.11,583,1422921600"; d="scan'208,217";a="141623198" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 15 Apr 2015 22:22:44 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3FMMhLW003994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Apr 2015 22:22:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.36]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 17:22:43 -0500 From: "Tarek Saad (tsaad)" To: "mpls@ietf.org" Thread-Topic: Preliminary minutes from MPLS IETF92 Thread-Index: AQHQd8qwtuQIp1v1hUWP3uGvL5CPSQ== Date: Wed, 15 Apr 2015 22:22:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [161.44.213.146] Content-Type: multipart/alternative; boundary="_000_D1545CF7CB51tsaadciscocom_" MIME-Version: 1.0 Archived-At: Subject: [mpls] Preliminary minutes from MPLS IETF92 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, 15 Apr 2015 22:22:48 -0000 --_000_D1545CF7CB51tsaadciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, Below are the preliminary minutes taken during IETF92 MPLS sessions. Please= let me know if you have comments or would like to update/change them. MPLS Meeting notes for 24 and 27 March, IETF92 Materials are available at the following links: Agenda draft-fang-mpls-hsdn-for-hsdc draft-ietf-mpls-spring-entropy-label draft-kompella-mpls-rsvp-ecmp draft-zheng-mpls-lsp-ping-yang-cfg-old draft-chandra-mpls-enhanced-frr-bypass draft-cheng-mpls-tp-shared-ring-protection draft-dai-mpls-rsvp-te-mbb-label-reuse draft-ietf-mpls-lsp-ping-relay-reply draft-kompella-mpls-larp draft-kompella-mpls-rmr draft-mirsky-mpls-bfd-directed draft-mirsky-mpls-residence-time draft-openconfig-mpls-consolidated-model draft-saad-teas-yang-te-rsvp draft-tiruveedhula-mpls-mldp-mib draft-mtaillon-rsvpte-summary-frr-00 IETF92_MPLS_WG_Status Agenda: Administrative (agenda bashing, WG status) http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label http://tools.ietf.org/html/draft-tiruveedhula-mpls-mldp-mib http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply http://tools.ietf.org/html/draft-kompella-mpls-rsvp-ecmp http://tools.ietf.org/html/draft-kompella-mpls-larp http://tools.ietf.org/html/draft-kompella-mpls-rmr http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-ring-protection http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed http://tools.ietf.org/html/draft-mirsky-mpls-residence-time Wednesday's minutes: Sriganesh=92s presentation on Spring Entropy Labels: - No comments or questions. Kishore=92s presentation on P2MP and MP2MP LSP MIB: - No comments or questions(?) George Swallow=92s presentation on LSP Ping relay reply: - No comments or questions. Kireeti=92s presentation on Multi-path Label Switched Paths Signaled Using = RSVP-TE: - Kireeti asked for WG adoption and early IANA code point allocations. - Himanshu Shah (Ciena) asked if you can do asymmetric bandwidth distributi= on. - Kireeti said that you can do weighted distribution. There is neither an e= qual-cost nor an equal-distribution requirement. - George had a rapid fire conversation with Kireeti that I did not capture = any of. - Eric Osborne asked a question (I didn=92t get what the question was). - Lou Berger asked for the format of the association object to be written d= own. - Loa asked for improvements in the content of the IANA Considerations befo= re making a request for early allocations. Kireeti=92s presentation on Labeled ARP: - Kireeti asked for comments on the list, and adoption by the WG. - Himanshu asked why this is required. - Kireeti said that it is useful as a proxy ARP mechanism. Kireeti=92s presentation on resilient MPLS Rings: - Greg Mirsky asked a question about timers =96 what would be the defaults = and ranges? - Greg was asked to wait until Kireeti had gotten further into his presenta= tion. - The question did not get answered, but =96 because of time constraints = =96 needs to be taken to the list. - George asked if you can break up the bundles talked about in the draft. - Kireeti said that you can. - Greg Mirsky asked questions on ring interconnectivity, which Kireeti answ= ered. - The answer was that nodes advertise ring ID on particular links so this i= s a link property. This should be clarified in the next version. - George asked a question about (?) that Kireeti said would be answered on = the next slide. - Greg asked a question about manual switch-over =96 is it in the draft? - Kireeti said that specific support details (Lock/Unlock controls, etc.) a= re not in the current draft and will be in future work. - Ross Callon asked for a clarification of the meaning of maximally connect= ed rings. - Stewart Bryant asked how you can distinguish clockwise and =93anti-clockw= ise=94 directions on the ring. Kireeti said that it is explained in the dr= aft. - Eric Osborne observed that there is some history of ring work in MPLS. - (?) from Huawei asked a couple of questions. - Kireeti answered one question by saying that irregular rings require the = same sort of configuration information. - Kireeti explained the motivation for using RSVP-TE. - Kireeti punted on the MRT question, due to time limits. - Li Weng (Comcast) asked how you would protect a ring under specific failu= re scenarios. - This discussion would need to be continued on the list. - Stewart asked how this proposal would work if one or more parts of a ring= failed to come up. - Further discussion will need to be taken to the list. Liang Geng=92s (China Mobile) presentation on MSRP: - Weiqiang asked for feedback from the WG and to determine if the draft mig= ht be ready for adoption. - Kireeti and George asked questions about where on a ring the decision is = made for traffic exiting the ring. - Shahram Davari answered. - Eric Osborne said that this draft needs some discussion as to why the exi= sting RFC(s) are inadequate. - Loa asked if this observation applies to both this draft and Kireeti=92s = draft. - Eric said that =96 in his opinion =96 Kireeti=92s draft already provides = enough info to distinguish its applicability. Greg Mirsky=92s presentation on Directed BFD Return Path status: - No comments or questions. Greg Mirsky=92s presentation on Residence Time Measurement: - Shahram Davari asked why the format in the draft was used. It seems to b= e more than is needed. - Greg said that we chose to use the same format as was used in IEEE 1588. - Shahram asked if the draft allows for further extensions, giving an examp= le. - Greg said that additional sub-TLVs could be defined. Friday's minutes: Tarek's presentation on MPLS RSVP and TE related Yang actvites - No comments or questions. Kamran's presentation on MPLS LDP related YANG model - No comments or questions. Greg's presentatio on draft-zheng-mpls-lsp-ping-yang-cfg - No comments or questions. Ina's OC-MPLS YANG model draft-openconfig-mpls-consolidated-model Luang's presentation on draft-fang-mpls-hsdn-for-hsdc - TBD Stewart's presentation on draft-bryant-mpls-flow-ident - TBD Stewart's presentation on idraft-bryant-mpls-sfl-control - TBD Ron's presentation on draft-bonica-mpls-self-ping - TBD Tarek's presetnation on draft-mtaillon-mpls-summary-frr-rsvpte - Lou aksed why not use RSVP message bundles - Tarek answered, still with message bundles, for 10000's of states, likely= you'll need to send 1000's of messages and the receiver will have to parse= and process all messages Chandra's presentation on draft-chandra-mpls-enhanced-frr-bypass - No comments or questions. Minjie's presentaiton on draft-dai-mpls-rsvp-te-mbb-label-reuse-00 - No comments or questions. Regards, Tarek --_000_D1545CF7CB51tsaadciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

Below are the preliminary minutes taken during IETF= 92 MPLS sessions. Please let me know if you have comments or would like to = update/change them.

MPLS Meeting notes for 24 and 27 March, IETF92
Materials are available at the following links:
Agenda
draft-fang-mpls-hsdn-for-hsdc
draft-ietf-mpls-spring-entropy-label
draft-kompella-mpls-rsvp-ecmp
draft-zheng-mpls-lsp-ping-yang-cfg-old
draft-chandra-mpls-enhanced-frr-bypass
draft-cheng-mpls-tp-shared-ring-protection
draft-dai-mpls-rsvp-te-mbb-label-reuse
draft-ietf-mpls-lsp-ping-relay-reply
draft-kompella-mpls-larp
draft-kompella-mpls-rmr
draft-mirsky-mpls-bfd-directed
draft-mirsky-mpls-residence-time
draft-openconfig-mpls-consolidated-model
draft-saad-teas-yang-te-rsvp
draft-tiruveedhula-mpls-mldp-mib
draft-mtaillon-rsvpte-summary-frr-00
IETF92_MPLS_WG_Status

Agenda:

Administrative (agenda bashing, WG status)
http://tools.ietf.org/html/draft-kini-mpls-spring-entropy-label
http://tools.ietf.org/html/draft-tiruveedhula-mpls-mldp-mib
http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply
http://tools.ietf.org/html/draft-kompella-mpls-rsvp-ecmp
http://tools.ietf.org/html/draft-kompella-mpls-larp
http://tools.ietf.org/html/draft-kompella-mpls-rmr
http://tools.ietf.org/html/draft-cheng-mpls-tp-shared-ring-protection<= /div>
http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed
http://tools.ietf.org/html/draft-mirsky-mpls-residence-time

Wednesday's minutes:
Sriganesh=92s presentation on Spring Entropy Labels:
- No comments or questions.

Kishore=92s presentation on P2MP and MP2MP LSP MIB:
- No comments or questions(?)

George Swallow=92s presentation on LSP Ping relay reply:
- No comments or questions.

Kireeti=92s presentation on Multi-path Label Switched Paths Signaled U= sing RSVP-TE:
- Kireeti asked for WG adoption and early IANA code point allocations.=
- Himanshu Shah (Ciena) asked if you can do asymmetric bandwidth distr= ibution.
- Kireeti said that you can do weighted distribution. There is neither= an equal-cost nor an equal-distribution requirement.
- George had a rapid fire conversation with Kireeti that I did not cap= ture any of.
- Eric Osborne asked a question (I didn=92t get what the question was)= .
- Lou Berger asked for the format of the association object to be writ= ten down.
- Loa asked for improvements in the content of the IANA Considerations= before making a request for early allocations.

Kireeti=92s presentation on Labeled ARP:
- Kireeti asked for comments on the list, and adoption by the WG.
- Himanshu asked why this is required.
- Kireeti said that it is useful as a proxy ARP mechanism.

Kireeti=92s presentation on resilient MPLS Rings:
- Greg Mirsky asked a question about timers =96 what would be the defa= ults and ranges?
- Greg was asked to wait until Kireeti had gotten further into his pre= sentation.
- The question did not get answered, but =96 because of time constrain= ts =96 needs to be taken to the list.
- George asked if you can break up the bundles talked about in the dra= ft.
- Kireeti said that you can.
- Greg Mirsky asked questions on ring interconnectivity, which Kireeti= answered.
- The answer was that nodes advertise ring ID on particular links so t= his is a link property.  This should be clarified in the next version.=
- George asked a question about (?) that Kireeti said would be answere= d on the next slide.
- Greg asked a question about manual switch-over =96 is it in the draf= t?
- Kireeti said that specific support details (Lock/Unlock controls, et= c.) are not in the current draft and will be in future work.
- Ross Callon asked for a clarification of the meaning of maximally co= nnected rings.
- Stewart Bryant asked how you can distinguish clockwise and =93anti-c= lockwise=94 directions on the ring.  Kireeti said that it is explained= in the draft.
- Eric Osborne observed that there is some history of ring work in MPL= S.
- (?) from Huawei asked a couple of questions.
- Kireeti answered one question by saying that irregular rings require= the same sort of configuration information.
- Kireeti explained the motivation for using RSVP-TE.
- Kireeti punted on the MRT question, due to time limits.
- Li Weng (Comcast) asked how you would protect a ring under specific = failure scenarios.
- This discussion would need to be continued on the list.
- Stewart asked how this proposal would work if one or more parts of a= ring failed to come up.
- Further discussion will need to be taken to the list.

Liang Geng=92s (China Mobile) presentation on MSRP:
- Weiqiang asked for feedback from the WG and to determine if the draf= t might be ready for adoption.
- Kireeti and George asked questions about where on a ring the decisio= n is made for traffic exiting the ring.
- Shahram Davari answered.
- Eric Osborne said that this draft needs some discussion as to why th= e existing RFC(s) are inadequate.
- Loa asked if this observation applies to both this draft and Kireeti= =92s draft.
- Eric said that =96 in his opinion =96 Kireeti=92s draft already prov= ides enough info to distinguish its applicability.

Greg Mirsky=92s presentation on Directed BFD Return Path status:
- No comments or questions.

Greg Mirsky=92s presentation on Residence Time Measurement:
- Shahram Davari asked why the format in the draft was used.  It = seems to be more than is needed.
- Greg said that we chose to use the same format as was used in IEEE 1= 588.
- Shahram asked if the draft allows for further extensions, giving an = example.
- Greg said that additional sub-TLVs could be defined.


Friday's minutes:
Tarek's presentation on MPLS RSVP and TE related Yang actvites
- No comments or questions.

Kamran's presentation on MPLS LDP related YANG model
- No comments or questions.

Greg's presentatio on draft-zheng-mpls-lsp-ping-yang-cfg
- No comments or questions.

Ina's OC-MPLS YANG model draft-openconfig-mpls-consolidated-model

Luang's presentation on draft-fang-mpls-hsdn-for-hsdc
- TBD

Stewart's presentation on draft-bryant-mpls-flow-ident
- TBD

Stewart's presentation on idraft-bryant-mpls-sfl-control
- TBD

Ron's presentation on draft-bonica-mpls-self-ping
- TBD

Tarek's presetnation on draft-mtaillon-mpls-summary-frr-rsvpte
- Lou aksed why not use RSVP message bundles
- Tarek answered, still with message bundles, for 10000's of states, l= ikely you'll need to send 1000's of messages and the receiver will have to = parse and process all messages

Chandra's presentation on draft-chandra-mpls-enhanced-frr-bypass
- No comments or questions.

Minjie's presentaiton on draft-dai-mpls-rsvp-te-mbb-label-reuse-00
- No comments or questions.

Regards,
Tarek

--_000_D1545CF7CB51tsaadciscocom_-- From nobody Wed Apr 15 22:40:08 2015 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 B45541A8911; Wed, 15 Apr 2015 22:40:05 -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 F6X0DnypKtQS; Wed, 15 Apr 2015 22:40:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C9F1A6F3F; Wed, 15 Apr 2015 22:40:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416054004.8700.71799.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 22:40:04 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-reply-mode-simple-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, 16 Apr 2015 05:40:05 -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) Ping/Traceroute Reply Mode Simplification Authors : Nobo Akiya George Swallow Carlos Pignataro Loa Andersson Mach(Guoyi) Chen Filename : draft-ietf-mpls-lsp-ping-reply-mode-simple-02.txt Pages : 13 Date : 2015-04-15 Abstract: The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the "Reply via Specified Path (5)" Reply Mode value to easily indicate the reverse LSP. This document also adds an optional TLV which can carry ordered list of Reply Mode values. This document updates RFC7110. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode-simple/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-reply-mode-simple-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 Wed Apr 15 22:40:10 2015 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 D781C1A6F3F; Wed, 15 Apr 2015 22:40:06 -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 FizuxwFOM4wd; Wed, 15 Apr 2015 22:40:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6121A8863; Wed, 15 Apr 2015 22:40:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416054004.8700.56243.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 22:40:04 -0700 Archived-At: Subject: [mpls] New Version Notification - draft-ietf-mpls-lsp-ping-reply-mode-simple-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, 16 Apr 2015 05:40:07 -0000 A new version (-02) has been submitted for draft-ietf-mpls-lsp-ping-reply-mode-simple: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-reply-mode-simple-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-reply-mode-simple/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-reply-mode-simple-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. IETF Secretariat. From nobody Thu Apr 16 10:06:32 2015 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 23F8F1B2D04 for ; Thu, 16 Apr 2015 10:06:31 -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 3O0q6wtgL_Y0 for ; Thu, 16 Apr 2015 10:06:29 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00F51B2D53 for ; Thu, 16 Apr 2015 10:06:28 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so63809051lbc.1 for ; Thu, 16 Apr 2015 10:06:27 -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=h3Ge5f0lVmXDdMHMxj5xtSSjwL/VHhdyS2QEba028yY=; b=XAinjXB5c4M2pgBSowbjPiAD0FbMkUZ5ULBZuM+eK4jY5rpMmOM69ptExkaDrHrHNi X5bvzprJGxnX9+h8sDFftLsa8MkEOD0NQgzPs/lwUxEto9dfDrH15+4qfauyk/6WNqX/ zbs6aL0nJBh3Gf7rR6ySpceYCu6N9lSee4GuvMDrN2WF/DYbPZLrMmya/2qgGoFrVwlo aBpv7dZVD6Wbg9oBUllNFGFZESlWEHUdOTLWltsrRYAveO9Ip2XZO49SAxZWyTJULO26 5MfYz7HlA9ebMJ712K0Jd0Qbj+uAK03HVwaKw1HjXu7dAKarBQ5las51nibS/dtVThfG RahA== MIME-Version: 1.0 X-Received: by 10.152.22.104 with SMTP id c8mr29065667laf.87.1429203987182; Thu, 16 Apr 2015 10:06:27 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Thu, 16 Apr 2015 10:06:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2015 10:06:27 -0700 Message-ID: From: Nobo Akiya To: Ross Callon Content-Type: multipart/alternative; boundary=089e0158ab90f7b8650513da7bc9 Archived-At: Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 16 Apr 2015 17:06:31 -0000 --089e0158ab90f7b8650513da7bc9 Content-Type: text/plain; charset=UTF-8 Hi Ross, Thank you for Shepherding this document. We (authors) have posted the revision (-02) addressing all comments received during the LC of this document (thanks to those who provided comments!). Thanks! -Nobo, on behalf of authors On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon wrote: > This working group last call has ended, with sufficient support and no > opposition. There have however been a number of comments received. Thanks > to everyone who took the time to review the draft and comment. > > > > Authors, please update the draft in response to the comments. After this > is done, I will submit the document for publication. > > > > Thanks, Ross > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross Callon > *Sent:* Friday, March 20, 2015 10:04 AM > *To:* mpls@ietf.org > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org > *Subject:* [mpls] working group last call for > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Working Group, > > > > This is to initiate a working group last call on > draft-ietf-mpls-lsp-ping-reply-mode-simple-01. > > Because this WGLC will span the IETF in Dallas, it will be extended to > three weeks. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > There are no IPR disclosures against this document. All the authors have > stated that they > > are not aware of any IPR that relates to this draft. > > > > This working group last call ends Friday April 10, 2015. > > > > Ross > > for the MPLS WG chairs > > > > > --089e0158ab90f7b8650513da7bc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ross,

Thank you for Shepherding this= document.

We (authors) have posted the revision (= -02) addressing all comments received during the LC of this document (thank= s to those who provided comments!).

Thanks!
<= div>
-Nobo, on behalf of authors

On Mon, Apr 13, 2015 at 9:03 AM, R= oss Callon <rcallon@juniper.net> wrote:

This working group last c= all has ended, with sufficient support and no opposition. There have howeve= r been a number of comments received. Thanks to everyone who took the time to review the draft and comment.

=C2=A0

Authors, please update th= e draft in response to the comments. After this is done, I will submit the = document for publication.

=C2=A0

Thanks, Ross

=C2=A0

From: mpls [ma= ilto:mpls-bounce= s@ietf.org] On Behalf Of Ross Callon
Sent: Friday, March 20, 2015 10:04 AM
To: mpls@ietf.org=
Cc: Loa Andersson; mpls-chairs@tools.ietf.org
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping= -reply-mode-simple-01

=C2=A0

Working Group,

=C2=A0

This is to initiate a working group las= t call on draft-ietf-mpls-lsp-ping-reply-mode-simple-01.

Because this WGLC will span the IETF in= Dallas, it will be extended to three weeks.

=C2=A0

Please send your comments to the mpls w= g mailing list (mpls@iet= f.org).

=C2=A0

There are no IPR disclosures against th= is document. All the authors have stated that they

are not aware of any IPR that relates t= o this draft.

=C2=A0

This working group last call ends Frida= y=C2=A0 April 10, 2015.=C2=A0

=C2=A0

Ross

for the MPLS WG chairs

=C2=A0

=C2=A0


--089e0158ab90f7b8650513da7bc9-- From nobody Thu Apr 16 10:50:10 2015 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 225F81B33C5 for ; Thu, 16 Apr 2015 10:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 aYhX0L1TKdo2 for ; Thu, 16 Apr 2015 10:50:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECC81B3425 for ; Thu, 16 Apr 2015 10:49:39 -0700 (PDT) Received: from pc6 (81.151.162.168) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 16 Apr 2015 17:31:54 +0000 Message-ID: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> From: t.petch To: Nobo Akiya , Ross Callon References: Date: Thu, 16 Apr 2015 18:30:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB4PR02CA0049.eurprd02.prod.outlook.com (10.242.174.177) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(41574002)(51704005)(164054003)(377454003)(24454002)(13464003)(77096005)(14496001)(15975445007)(33646002)(5820100001)(61296003)(62236002)(44716002)(122386002)(84392001)(42186005)(47776003)(66066001)(19580395003)(19580405001)(76176999)(81686999)(50986999)(87976001)(81816999)(50226001)(1556002)(62966003)(77156002)(46102003)(86362001)(40100003)(50466002)(92566002)(230783001)(23676002)(4001410100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMSPR07MB051; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB051; X-Forefront-PRVS: 0548586081 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2015 17:31:54.1690 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 16 Apr 2015 17:50:09 -0000 Nobo I was struck by Adrian's comment which, if I understand correctly, was what to do if a MUST or SHOULD is violated and as I see it, I am unclear if this was addressed. Thus 3.2 2) what should a recipient do when the echo reply does contain a Reply Mode Order TLV ? Or in 6), 'SHOULD contain at least two Reply Mode values' - when may that SHOULD be violated and if it is, does that render the TLV not valid as described in 4? Tom Petch ----- Original Message ----- From: "Nobo Akiya" To: "Ross Callon" Cc: ; ; Sent: Thursday, April 16, 2015 6:06 PM Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > Hi Ross, > > Thank you for Shepherding this document. > > We (authors) have posted the revision (-02) addressing all comments > received during the LC of this document (thanks to those who provided > comments!). > > Thanks! > > -Nobo, on behalf of authors > > On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon wrote: > > > This working group last call has ended, with sufficient support and no > > opposition. There have however been a number of comments received. Thanks > > to everyone who took the time to review the draft and comment. > > > > > > > > Authors, please update the draft in response to the comments. After this > > is done, I will submit the document for publication. > > > > > > > > Thanks, Ross > > > > > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross Callon > > *Sent:* Friday, March 20, 2015 10:04 AM > > *To:* mpls@ietf.org > > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org > > *Subject:* [mpls] working group last call for > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > > Working Group, > > > > > > > > This is to initiate a working group last call on > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01. > > > > Because this WGLC will span the IETF in Dallas, it will be extended to > > three weeks. > > > > > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > > > > > There are no IPR disclosures against this document. All the authors have > > stated that they > > > > are not aware of any IPR that relates to this draft. > > > > > > > > This working group last call ends Friday April 10, 2015. > > > > > > > > Ross > > > > for the MPLS WG chairs > > > > > > > > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Thu Apr 16 11:10:13 2015 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 6682C1B2EF4 for ; Thu, 16 Apr 2015 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ijcJeweOimBL for ; Thu, 16 Apr 2015 11:10:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132FE1B2EBD for ; Thu, 16 Apr 2015 11:10:09 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3GIA6f4022004; Thu, 16 Apr 2015 19:10:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3GIA3Mt021992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2015 19:10:05 +0100 From: "Adrian Farrel" To: "'t.petch'" , "'Nobo Akiya'" , "'Ross Callon'" References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> In-Reply-To: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> Date: Thu, 16 Apr 2015 19:10:06 +0100 Message-ID: <039601d07870$93441fd0$b9cc5f70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQPgMp+F85EfvPJp+pmFDDXz24DS/gHDk72sAiR8PsAB8lbRg5kBqJLA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21482.002 X-TM-AS-Result: No--0.992-10.0-31-10 X-imss-scan-details: No--0.992-10.0-31-10 X-TMASE-MatchedRID: 5+1rHnqhWUTMy6K24fisq/HkpkyUphL9McUnpY8JAof87i5L+UKVgkHq 72dazUUafeul6Dnab9DW5noeYys7ZYT3OBUyTele7spMO3HwKCA6QNs2WCY79Xz6vt8n2NeAo8W MkQWv6iV95l0nVeyiuBQF+BLVItD4C24oEZ6SpSmcfuxsiY4QFCnuhr/brEYTBY+HEQjrM82BVg nppaA9/djcuw7oJW82R9geeVePX1aHx/3593XRE+S+ZTuCPZ+tPifujgI13dqh071fQj6NysC+k sT6a9fy Archived-At: Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:10:12 -0000 Tom captures my point. > I was struck by Adrian's comment which, if I understand correctly, was > what to do if a MUST or SHOULD is violated and as I see it, I am unclear > if this was addressed. > > Thus 3.2 2) what should a recipient do when the echo reply does contain > a Reply Mode Order TLV ? > > Or in 6), 'SHOULD contain at least two Reply Mode values' - when may > that SHOULD be violated and if it is, does that render the TLV not valid > as described in 4? From nobody Thu Apr 16 13:26:08 2015 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 53D7D1A894E for ; Thu, 16 Apr 2015 13:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 1-FZvfi7Et3C for ; Thu, 16 Apr 2015 13:26:00 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38371B367C for ; Thu, 16 Apr 2015 13:25:55 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 2F2B48E043D for ; Thu, 16 Apr 2015 13:25:55 -0700 (PDT) Received: from smtp.pmcs.com (bby1cas03.pmc-sierra.internal [216.241.227.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bby1mta02.pmc-sierra.bc.ca (Postfix) with ESMTP id 5E18C8E033C for ; Thu, 16 Apr 2015 13:25:54 -0700 (PDT) Received: from BBYEXM01.pmc-sierra.internal ([169.254.1.160]) by bby1cas03.pmc-sierra.internal ([fe80::6555:ee5c:e637:a304%16]) with mapi id 14.03.0123.003; Thu, 16 Apr 2015 13:25:54 -0700 From: Spencer Jackson To: "mpls@ietf.org" Thread-Topic: Need more clarification for the draft-cheng-mpls-tp-shared-ring-protection Thread-Index: AdB4g0iHvI36CTnsQjiBpDo6zDKZjg== Date: Thu, 16 Apr 2015 20:25:53 +0000 Message-ID: <5E6B9C6C95BED441A489C1836E08EF93A659FEA2@BBYEXM01.pmc-sierra.internal> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.241.227.4] Content-Type: multipart/alternative; boundary="_000_5E6B9C6C95BED441A489C1836E08EF93A659FEA2BBYEXM01pmcsier_" MIME-Version: 1.0 X-internal: True Archived-At: Subject: [mpls] Need more clarification for the draft-cheng-mpls-tp-shared-ring-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: Thu, 16 Apr 2015 20:26:01 -0000 --_000_5E6B9C6C95BED441A489C1836E08EF93A659FEA2BBYEXM01pmcsier_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors of draft-cheng-mpls-tp-shared-ring-protection_04, Section 5.1 states that RPS requests are required to be sent in both direct= ions. Does this mean on the paired working/protection paths (RcW/RaP or RaW= /RcP), or on the clockwise and anti-clockwise protection paths (RcP/RaP)? I presume the former, although this is different from linear APS in which o= nly the protection path carries the coordination protocol. Thanks, Spence -- Spence Jackson Austin Software Center Engineering Manager PMC-Sierra Wireless Infrastructure and Networking Division 6850 Austin Center Blvd., Suite 215, Austin, TX 78731 512-345-3808 x113 (Tel) 512-345-3828 (Fax) 512-589-9681 (Mobile) http://pmcs.com/products/mobile/network_processors/ This message is sent in confidence for the addressee only. It may contain l= egally privileged information. The contents are not to be disclosed to anyo= ne other than the addressee. Unauthorized recipients are requested to prese= rve this confidentiality, advise the sender immediately of any error in tra= nsmission and delete the email from their systems. --_000_5E6B9C6C95BED441A489C1836E08EF93A659FEA2BBYEXM01pmcsier_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors of draft-cheng-mpls-tp-shared-ring-prot= ection_04,

 

Section 5.1 states that RPS requests are required to= be sent in both directions. Does this mean on the paired working/protectio= n paths (RcW/RaP or RaW/RcP), or on the clockwise and anti-clockwise protec= tion paths (RcP/RaP)?

 

I presume the former, although this is different fro= m linear APS in which only the protection path carries the coordination pro= tocol.

 

Thanks,

Spence

 

--

 

Spence Jackson

Austin Software Center Engineering Manager

PMC-Sierra

Wireless Infrastructure and Networking Division

6850 Austin Center Blvd., Suite 215, Austin, TX 7= 8731

512-345-3808 x113 (Tel)

512-345-3828 (Fax)

512-589-9681 (Mobile)

 

http://pmcs.com/products/mobile/network_processors/

 

This message is sent= in confidence for the addressee only. It may contain legally privileged in= formation. The contents are not to be disclosed to anyone other than the ad= dressee. Unauthorized recipients are requested to preserve this confidentiality, advise the sender immediately = of any error in transmission and delete the email from their systems.<= /o:p>

 

--_000_5E6B9C6C95BED441A489C1836E08EF93A659FEA2BBYEXM01pmcsier_-- From nobody Thu Apr 16 14:17:05 2015 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 6DF8A1A8A8A for ; Thu, 16 Apr 2015 14:17:03 -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 OXpohoVfnZ1l for ; Thu, 16 Apr 2015 14:17:02 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71711A8A81 for ; Thu, 16 Apr 2015 14:17:01 -0700 (PDT) Received: by widjs5 with SMTP id js5so20578734wid.1 for ; Thu, 16 Apr 2015 14:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=CEds6GHNesy1tbPzE5HTtq/6bPZmCzG7wi2vFNA4gEY=; b=r+O5Zv4qlxOo6dCqIOqALLqbE4fBUc+5+7gb3SK4uMOM18Og03ffPpvVGFu8Jmvowh 3Y65+nX+WsUtnQCJn+/BB4t6wPHDTkEkVBSvkgp1cbYjnmfMiHS2cTVUwUqfkPDc3IVk dOLkHqVzU88TWLNcA/65mMHBJLH2jlkH3GCLRHFBShq/BCyMn6k0M7ishw+vrfUhYs9w uGdAzJ4UMzrhpwgNzauzLhx1ejh/i3qVJC1xc/oKftwPy5nWvIG/EY7tPG9pHPSg/keg 7J9aiFVgX1lCxngHUtXlYhpofr10PZZ2HtN++sUmgvA5Cd4evd4wROGos10EIoz8bnkC oruA== X-Received: by 10.180.106.131 with SMTP id gu3mr242054wib.16.1429219020484; Thu, 16 Apr 2015 14:17:00 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id go4sm27604908wib.1.2015.04.16.14.16.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 14:16:59 -0700 (PDT) Message-ID: <553026CA.80508@gmail.com> Date: Thu, 16 Apr 2015 23:16:58 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Spencer Jackson , "mpls@ietf.org" References: <5E6B9C6C95BED441A489C1836E08EF93A659FEA2@BBYEXM01.pmc-sierra.internal> In-Reply-To: <5E6B9C6C95BED441A489C1836E08EF93A659FEA2@BBYEXM01.pmc-sierra.internal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] Need more clarification for the draft-cheng-mpls-tp-shared-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:17:03 -0000 Hello Spence, You wrote: > Dear authors of draft-cheng-mpls-tp-shared-ring-protection_04, > > Section 5.1 states that RPS requests are required to be sent in both > directions. Does this mean on the paired working/protection paths > (RcW/RaP or RaW/RcP), or on the clockwise and anti-clockwise protection > paths (RcP/RaP)? It is the latter. The reason is that in case the working path fails the protection protocol continues to work and will be able to coordinate the protection switch. This is the same reason why in linear protection the PSC is sent on the protection paths. Best regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Thu Apr 16 16:58:11 2015 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 F0D641A033B; Thu, 16 Apr 2015 16:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dKOP9Gn9E8Hz; Thu, 16 Apr 2015 16:58:04 -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 A599C1A028A; Thu, 16 Apr 2015 16:58:03 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-04-552ff59759ef Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.95.12456.795FF255; Thu, 16 Apr 2015 19:47:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 19:57:58 -0400 From: Gregory Mirsky To: Huaimo Chen , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AQHQdUsbhXhJtQ5lC02wWl3AD+NymZ1QUc6g Date: Thu, 16 Apr 2015 23:57:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.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_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXSPn+6Mr/qhBlOPM1lcfPiU2WLr0yuM FreWrmS1+PxnG6NF09xdTBatP3awOLB5tBx5y+qxZMlPJo8vlz+zBTBHcdmkpOZklqUW6dsl cGVMObyfreDyG8aKGx8WMzYwLj7D2MXIySEhYCJx9cFxJghbTOLCvfVsILaQwFFGifvTNboY uYDs5YwSXe8+s4Mk2ASMJF5s7GEHSYgIfGaU+LL6CStIglnAS+LS82nMILawgLtE180DYLaI gIfEimtzgKZyANlGEm83uIKEWQRUJV7uewZWwivgK3Fv/zw2iGUzGSV2rPwMdgWnQJjE7D3z wK5jBLru+6k1TBC7xCVuPZkPdbWAxJI955khbFGJl4//sULYihL7+qezQ9TnSzye3gW1TFDi 5MwnLBMYRWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66 kcEmRmA0HpNg093BuOel5SFGAQ5GJR7eBeL6oUKsiWXFlbmHGKU5WJTEeRc9OBgiJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgTGaZffp/YX/tk/e+2CxgsqKmKinqqyRxlOPHfH6UN54SeVa xuE5B87JFCkK/Q/8bPz9Xkb6t3b1eTpFV+oVLI0erj03W3TDt5JTs5fee/0gbkd2jZ2x7vvU ksfF0oGXDV+v/bI6tLV5fSLDA3XbdQ0iXEILapjun35+la2ofPJm/dspy/LVbzgrsRRnJBpq MRcVJwIAJY6OpKcCAAA= Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-teas-rsvp-ingress-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: Thu, 16 Apr 2015 23:58:10 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, thank you for kind consideration of my comments. Please find more in-lined = and tagged GIM>> notes. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Sunday, April 12, 2015 11:04 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org;= teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. GIM>> I think it is strange to cite requirement on scale of seconds if not = tens of seconds in discussion of method of local protection that supposed t= o perform protection switchover in sub-second if not sub-50msec time. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. GIM>> As noted above, these seem as requirements of different scale. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. GIM>> Routing convergence may take seconds. Is that acceptable as failure d= etection time for local protection? Protection switchover expected to be fa= st, perhaps on sub-50 msec scale. From TDM world we carry 10 msec failure d= etection, and BFD implementations can support that. but here, it appears, y= ou describe failure detection mechanism with detection time on scale of sec= onds if not tens of seconds. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. GIM>> In that case, the text is not needed either. Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. GIM>> If this is historical part, then it may be moved to Appendix or taken= from the document altogether. Can you give more details about the cases in which false positives may be p= roduced? GIM>> If current proposal is limited to Source-detect case only then possi= bility of false positive/negative depends on Source to Ingress connection a= nd OAM mechanism used. But that is deployment issue and is outside of scope= of this document Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,<= /span>

thank you for kind con= sideration of my comments. Please find more in-lined and tagged GIM>>= notes.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ie= tf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf= .org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·         Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·         Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

GIM>> I think it= is strange to cite requirement on scale of seconds if not tens of seconds = in discussion of method of local protection that supposed to perform protec= tion switchover in sub-second if not sub-50msec time.

 

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

GIM>> As noted a= bove, these seem as requirements of different scale.

 

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

GIM>> Routing co= nvergence may take seconds. Is that acceptable as failure detection time fo= r local protection? Protection switchover expected to be fast, perhaps on s= ub-50 msec scale. From TDM world we carry 10 msec failure detection, and BFD implementations can support that. but h= ere, it appears, you describe failure detection mechanism with detection ti= me on scale of seconds if not tens of seconds.

 

·         Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

GIM>> In that ca= se, the text is not needed either.

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

GIM>> If this is= historical part, then it may be moved to Appendix or taken from the docume= nt altogether.

 

Can you give more deta= ils about the cases in which false positives may be produced?

GIM>> If current= proposal is limited to Source-detect case only  then possibility of f= alse positive/negative depends on Source to Ingress connection and OAM mech= anism used. But that is deployment issue and is outside of scope of this document

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_-- From nobody Thu Apr 16 18:38:08 2015 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 4887E1A8A48 for ; Thu, 16 Apr 2015 18:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fnKMI4Z5JJaH for ; Thu, 16 Apr 2015 18:38:04 -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 8FA0D1A8A43 for ; Thu, 16 Apr 2015 18:38:04 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-62-55300d0a0c97 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 20.B7.12456.A0D00355; Thu, 16 Apr 2015 21:27:07 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 21:38:02 -0400 From: Gregory Mirsky To: Nobo Akiya , 'Ross Callon' , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf Thread-Index: AQHQb/4e6lxvQUESVUS7PAp42TBBtZ0/b/8AgBD8mdA= Date: Fri, 17 Apr 2015 01:38:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B94CDFF@eusaamb103.ericsson.se> References: <005801d07006$789a7ed0$69cf7c70$@gmail.com> In-Reply-To: <005801d07006$789a7ed0$69cf7c70$@gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiC43r0GowdaznBYTTj1gsvh+aQmL xa2lK1ktnpx7x2Lxd8UVFgdWj52z7rJ7LFnyk8njetNVdo8vlz+zBbBEcdmkpOZklqUW6dsl cGXsOvietaDRvGLblhXMDYwrtLsYOTgkBEwkDm+o6mLkBDLFJC7cW8/WxcjFISRwlFHi3MGl jBDOckaJF2dusYJUsQkYSbzY2MMOYosIFErM6p3GBFLELLCDUeL24dlgRcIC0RJbp19gBtkg IhAjMa/FEKLeSuLlsz1MIDaLgKrEjHn3wEp4BXwlNuxThtj1FGjMqltsIDWcAhYSrZ/+MIPY jEDXfT+1BqyXWUBc4taT+UwQVwtILNlznhnCFpV4+fgfK4StKLGvfzo7RL2exI2pU9ggbG2J ZQtfg9XzCghKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQLj6pgEm+4O xj0vLQ8xCnAwKvHwLhDXDxViTSwrrsw9xCjNwaIkzrvowcEQIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYy6ERN2azmsO1Bm/KqovjnR7KtjRnfxrsSa6HXXb5zezl+o9nBCn+OUzjKvC1O3 rOpfciT85U5+8ddpp7W+bPr54+fSdVWXnm+r/XttR6XK2f1WOac+LGDO4Z7jtv3DBKOvAk8n 8U+ev3rT7w33zLLeh+b6LuK3nRy/SYzjSfrVIzkLuQVuFlZFKrEUZyQaajEXFScCAAdecraM AgAA Archived-At: Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 17 Apr 2015 01:38:07 -0000 Hi Nobo, finally got to address your comments (greatly appreciate your help). Please find in-line and tagged GIM>>. Kind regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya Sent: Sunday, April 05, 2015 6:10 PM To: 'Ross Callon'; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@t= ools.ietf.org Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mp= ls-tp-oam-conf Hi Ross, My apologies for being late. I skipped over all the PM details, but read rest of the document. This docu= ment defines an important functionality for TP OAM, and I do support its pr= ogress. I did spot few things which should be addressed in the document (especially #1 and #4). 1. Section 2.2 - BFD Configuration sub-TLV, which MUST be included if either the CC, the CV or both OAM Function flags being set in the OAM Function Flags Sub-TLV [RFC7260]. I'm guessing that above is a copy & paste error/leftover. MPLS OAM Function= TLV is defined in the section 2.2 of the draft-ietf-mpls-lsp-ping-mpls-tp-= oam-conf document, and the TLV has MPLS OAM TLV Flags defined. We would wan= t to refer to the MPLS OAM TLV Flags in the MPLS OAM Function TLV instead o= f OAM Function flags in the OAM Function Flags Sub-TLV defined in RFC7260. And if above is true (and the text is corrected), then the reference to RFC7260 can also be removed (as it is not mentioned anywhere else in this d= ocument). GIM>> Indeed, cut-paste. New text will be: - BFD Configuration sub-TLV, which MUST be included if either the CC, the CV or both MPLS OAM Function flags being set in the MPLS OAM Functions TLV . And the Table 1 caption will be not to MPLS OAM TLV Flags but to MPLS OAM = Functions Flags. 2. Section 2.2 This sub-TLV MUST carry a "BFD Local Discriminator sub-TLV" and a "Timer Negotiation Parameters sub-TLV" if the N flag is cleared. The "Source MEP-ID sub-TLV" MUST also be included. If the I flag is set, the "BFD Authentication sub-TLV" MAY be included. I think above should be removed, as it is a subset (and a bit confusion subset) of what is better described at the end of Section 2.2.1 anyways. GIM>> Agree to remove. 3. Section 2.2.1 In this case an updated Negotiation Timer Parameters sub-TLV, containing values supported by the egress node, is returned to the ingress. Above is probably a good place to reference RFC7419 to prevent problematic = interop of multiple devices. GIM>> Agreed. Updated with the reference: - the N flag is cleared and the S flag is set, and the Negotiation Timer Parameters sub-TLV received by the egress contains unsupported values. In this case an updated Negotiation Timer Parameters sub-TLV, containing values supported by the egress node [RFC7419], is returned to the ingress. 4. Section 2.2.4 There needs to be some synchronicity between AuthType/AuthKeyID to specifie= d in "this" MPLS echo request message and AuthType/AuthKeyID being used by = BFD control packets. For example: - If BFD control packets using "new" auth is received by the egress LSR bef= ore MPLS echo request with new "auth" is received, all BFD control packets = using "new" auth will be dropped. - To take that a step further, if BFD control packets using "new" auth is r= eceived by the egress LSR before "this" MPLS echo request is received by th= e egress LSR and corresponding BFD session is updated to point to the "new"= auth , all BFD control packets using "new" auth will be dropped. - If BFD control packets using "new" auth is only sent X time after sending= the MPLS echo request with new "auth", then it is not guaranteed that the = egress LSR will still be accepting BFD control packets with "old" auth for = X amount of time. - And of course there's the error case of the egress LSR not being able to = support the specified the "new" auth specified in received MPLS echo reques= t, but the ingress LSR starts using the "new" auth before it receives back = NOSUP from the egress LSR via MPLS echo reply. I suspect if sufficient details are not defined, we would likely run into s= ome inter-op issues with this aspect. GIM>> I agree, more details should be provided. How about a new paragraph a= dded to the section: If BFD Authentication sub-TLV used for a BFD session in Up state then the Sender of the MPLS LSP Echo Request SHOULD ensure that old and new modes of authentication, i.e. combination of Auth.Type and Auth. Key ID, used to send and receive BFD control packets until the Sender can confirm that its peer had switched to the new authentication. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: April-05-15 5:10 PM > To: mpls@ietf.org > Cc: Ross Callon; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf@tools.ietf.org > Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf >=20 > This working group last call has now ended. >=20 > There was one public response (to the MPLS working group) in support.=20 > I also > got private responses of support from two of the authors. Otherwise=20 > there were > no responses (neither in favor nor opposed). This is not sufficient to constitute > "rough consensus". As such the working group last call has failed. >=20 > My inclination is to wait for the July IETF (in Prague), and give the authors an > opportunity to present and solicit additional support. Depending upon=20 > the response there, we may then repeat the WGLC. >=20 > Thanks, Ross > (as WG co-chair) >=20 > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon > Sent: Tuesday, March 10, 2015 4:46 PM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf@tools.ietf.org > Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam- > conf >=20 > Working Group, >=20 > This is to initiate a working group last call on draft-ietf-mpls-lsp-ping-mpls-tp- > oam-conf-09. > Because this WGLC will span the IETF in Dallas, it will be extended to just over > three weeks. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There are no IPR disclosures against this document. All the authors=20 > have stated > that they > are not aware of any IPR that relates to this draft (two of the=20 > responses were > private to > the WG chairs). >=20 > This working group last call ends Thursday=A0 April 2, 2015. >=20 > Ross > for the MPLS WG chairs >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 17 05:10:35 2015 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 CBCD61B2B85 for ; Fri, 17 Apr 2015 05:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 oCnUqayw8NHA for ; Fri, 17 Apr 2015 05:10:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A331B2B71 for ; Fri, 17 Apr 2015 05:10:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 66CAEBEEE for ; Fri, 17 Apr 2015 13:10:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4McRlhwOHK7 for ; Fri, 17 Apr 2015 13:10:29 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14C39BEED for ; Fri, 17 Apr 2015 13:10:29 +0100 (IST) Message-ID: <5530F834.40002@cs.tcd.ie> Date: Fri, 17 Apr 2015 13:10:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] would the WG like to adopt draft-farrelll-mpls-opportunistic-encrypt? 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, 17 Apr 2015 12:10:35 -0000 Hiya, Adrian and I wrote up [1]. How'd the WG feel about adopting that? If you did, I'd be willing to continue editing if you wanted. So consider this as a request that the WG take on this work. In case it helps, the current abstract is: " This document describes a way to apply opportunistic security between adjacent nodes on an MPLS Label Switched Path (LSP) or between end points of an LSP. It explains how keys may be agreed to enable encryption, and how key identifiers are exchanged in encrypted MPLS packets. Finally, this document describes the applicability of this approach to opportunistic security in MPLS networks with an indication of the level of improved security as well as the continued vulnerabilities. This document does not describe security for MPLS control plane protocols. " Cheers, S. [1] https://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt From nobody Fri Apr 17 13:39:55 2015 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 7DD3A1A88D5; Fri, 17 Apr 2015 13:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LLRku1LVSj0q; Fri, 17 Apr 2015 13:39:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id E14F21A9070; Fri, 17 Apr 2015 13:39:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5A84F180209; Fri, 17 Apr 2015 13:38:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150417203854.5A84F180209@rfc-editor.org> Date: Fri, 17 Apr 2015 13:38:54 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7506 on IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) 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, 17 Apr 2015 20:39:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7506 Title: IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) Author: K. Raza, N. Akiya, C. Pignataro Status: Standards Track Stream: IETF Date: April 2015 Mailbox: skraza@cisco.com, nobo.akiya.dev@gmail.com, cpignata@cisco.com Pages: 6 Characters: 11322 Updates: RFC 4379 I-D Tag: draft-ietf-mpls-oam-ipv6-rao-03.txt URL: https://www.rfc-editor.org/info/rfc7506 RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379. The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From houssam.kl@gmail.com Sat Apr 18 07:50:24 2015 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 17EED1A877B for ; Sat, 18 Apr 2015 07:50:24 -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, FSL_MY_NAME_IS=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 UzXUStVTV78y for ; Sat, 18 Apr 2015 07:50:22 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE4B1A8778 for ; Sat, 18 Apr 2015 07:50:22 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so90226649obb.3 for ; Sat, 18 Apr 2015 07:50:21 -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 :content-type:content-transfer-encoding; bh=vggXm1GCVW20piXYjAm7yDG1qXQbuV4d6BBdpN6xlcY=; b=b8XWfqzGbdrRpbycvkds31alXjzPBX4Gv059JH+j9Cj7xWtLo0/GpsCFb72H/Boc1o o0V7TFKYGSerMee09SwK+iuTRY7UgR24Jg9PV61DOMAbFNtQIBXT3dfUfXMTX2kkwkq8 4kdX27+spXEpUGXrkzX4BqywB/6A1X2KW0gPvlvGR97x/UGYXwYiyQg+1mRZ5ik5JDl7 bU2jIP3S7QgqGeZDEJi4w7X6yGB02LCrh1XwiPoVwKm+JhcGsKShUd17M1+3qK0npYCb APMmnkdfc0AOeg4gDS8K07oTm6sJf/gREqnQtM5MbD9dTeIK/Z4QI/kdtRc39du6ulix oXdw== MIME-Version: 1.0 X-Received: by 10.182.227.132 with SMTP id sa4mr7418064obc.40.1429368621871; Sat, 18 Apr 2015 07:50:21 -0700 (PDT) Received: by 10.202.199.204 with HTTP; Sat, 18 Apr 2015 07:50:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Apr 2015 16:50:21 +0200 Message-ID: From: Houssam Eddine Kassah Laouar To: mpls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [mpls] MPLS-Support and 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: Sat, 18 Apr 2015 14:51:20 -0000 On 4/18/15, Houssam Eddine Kassah Laouar wrote: > Dear MPLS Team, > > i find your mail on ietf.org website, so i want to discuss with you > and i hope i can find my way with. > > my name is Houssam Master 2 student in computer science from Algeria > and i work on my thesis of Master on IP/MPLS Networks. > > my Master thesis topic is about: ""Strategy of security for IP / MPLS > networks in terms of fault tolerance approach"" > > so any document in this field send it to me and good luck for your's > project too > > > Thank you in advance > > -- > > > *|*Thank You*|*=D8=B4=D9=83=D8=B1=D8=A7 =D8=AC=D8=B2=D9=8A=D9=84=D8=A7 = =D9=84=D9=83=D9=85*|* > *|*With our warmest wishes *|* =D9=85=D8=B9 =D8=A3=D8=B7=D9=8A=D8=A8 =D8= =A7=D9=84=D8=AA=D9=85=D9=86=D9=8A=D8=A7=D8=AA *|* > > *|*PEOPLE CARE ABOUT HOW TO GET MONEY BUT...*|* > > *|*ME I CARE ABOUT HOW CAN I GIVE THEM HONEY *| * > > |hOussam Eddine KASSAH LAOUAR|=D8=AD=D8=B3=D8=A7=D9=85 =D8=A7=D9=84=D8=AF= =D9=8A=D9=86 =D9=83=D8=A7=D8=B3=D8=AD =D9=84=D8=B9=D9=88=D8=B1| > > *|CEO&CO-Founder | Constantine Cisco User Group > |* > *|IT-Responsible| EuroArab Project | AEGEE-Europe / European Students' > Forum |* > *|Master Degree | Computer Science Option ICT | Constantine University | > Algeria |* > *|Mobile : +213 557 552 012 | Mail : houssam.kassah@aegee.org > |* > *|Social Media : @hOussamKASSAH | Skyp= e > : dr.housekl | My Facebook | M= y > Linkedin | * > --=20 *|*Thank You*|*=D8=B4=D9=83=D8=B1=D8=A7 =D8=AC=D8=B2=D9=8A=D9=84=D8=A7 =D9= =84=D9=83=D9=85*|* *|*With our warmest wishes *|* =D9=85=D8=B9 =D8=A3=D8=B7=D9=8A=D8=A8 =D8=A7= =D9=84=D8=AA=D9=85=D9=86=D9=8A=D8=A7=D8=AA *|* *|*PEOPLE CARE ABOUT HOW TO GET MONEY BUT...*|* *|*ME I CARE ABOUT HOW CAN I GIVE THEM HONEY *| * |hOussam Eddine KASSAH LAOUAR|=D8=AD=D8=B3=D8=A7=D9=85 =D8=A7=D9=84=D8=AF= =D9=8A=D9=86 =D9=83=D8=A7=D8=B3=D8=AD =D9=84=D8=B9=D9=88=D8=B1| *|CEO&CO-Founder | Constantine Cisco User Group |* *|IT-Responsible| EuroArab Project | AEGEE-Europe / European Students' Forum |* *|Master Degree | Computer Science Option ICT | Constantine University | Algeria |* *|Mobile : +213 557 552 012 | Mail : houssam.kassah@aegee.org |* *|Social Media : @hOussamKASSAH | Skype : dr.housekl | My Facebook | My Linkedin | * From nobody Sat Apr 18 10:23:58 2015 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 861611A8EA9 for ; Sat, 18 Apr 2015 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_15=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 FEKGT9Zz-zdp for ; Sat, 18 Apr 2015 10:23:53 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFFF1A901C for ; Sat, 18 Apr 2015 10:23:30 -0700 (PDT) Received: by laat2 with SMTP id t2so100595320laa.1 for ; Sat, 18 Apr 2015 10:23:29 -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=q9RsEMmdulDWdtL/CVFMPPF4LG4+QxGzwwexMGCOYaY=; b=ny25xCXDGVWB/ShS5pivHENvv7oIEoMjpRhesAcZPGR2E6xorKp7Dn+juYUVW85u/o JWI9c8cNhonsR22haV6E8VbKqWxrli3gffk0qcWXBp4c+i/AJ/8FY4Gb17sM/abw5JXb ZGjLrDFc6y8KHf1o4IV0nCBuqiwaHiF5WA2k25Y1gPKxp0T1JY668tCSUbLpBl7TofV3 gs5RJI3/zXZkk/MJ8+OpFZp5SN7PUWqzDYyi76oclzFrh2Hn2L+bdeswutLFvB62egsn P949gC3VAfakTpayVRjMZAsZtL17iz08G2umQ763myD4h1mpGWsybO6N/+xzMKZU4/4z tOpA== MIME-Version: 1.0 X-Received: by 10.112.156.97 with SMTP id wd1mr1886463lbb.30.1429377808873; Sat, 18 Apr 2015 10:23:28 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Sat, 18 Apr 2015 10:23:28 -0700 (PDT) In-Reply-To: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> Date: Sat, 18 Apr 2015 10:23:28 -0700 Message-ID: From: Nobo Akiya To: "t.petch" Content-Type: multipart/alternative; boundary=089e0112cc808c3eb6051402f409 Archived-At: Cc: Ross Callon , mpls , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 18 Apr 2015 17:23:55 -0000 --089e0112cc808c3eb6051402f409 Content-Type: text/plain; charset=UTF-8 Hi Tom, Although we have added this text after the list/bullet items in section 3.2: If a responder LSR receives a Reply Mode Order TLV which does not comply to the rules described above, then the responder LSR MUST ignore the Reply Mode Order TLV. You are right, it doesn't cover the case where a receiver (the initiator LSR) receives an MPLS echo reply with a Reply Mode Order TLV. Perhaps above text should be changed to: If an LSR receives a Reply Mode Order TLV which does not comply to the rules described above, then the LSR MUST ignore the Reply Mode Order TLV. Will that address your first comment? Regarding your second comment (3.2-6), is that really too ambiguous? To me, that text translates to following implementations: - When sending a Reply Mode Order TLV, 2 or more Reply Mode values shall be present. - When receiving a Reply Mode Order TLV, accept 1 or more Reply Mode values. If you think the text really should be updated, then we can change (3.2-6): [OLD] 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, and SHOULD contain at least two Reply Mode values. [NEW] 6. Reply Mode Order TLV MUST contain at least one Reply Mode value. Thoughts? Thanks! -Nobo On Thu, Apr 16, 2015 at 10:30 AM, t.petch wrote: > Nobo > > I was struck by Adrian's comment which, if I understand correctly, was > what to do if a MUST or SHOULD is violated and as I see it, I am unclear > if this was addressed. > > Thus 3.2 2) what should a recipient do when the echo reply does contain > a Reply Mode Order TLV ? > > Or in 6), 'SHOULD contain at least two Reply Mode values' - when may > that SHOULD be violated and if it is, does that render the TLV not valid > as described in 4? > > > Tom Petch > > ----- Original Message ----- > From: "Nobo Akiya" > To: "Ross Callon" > Cc: ; ; > > Sent: Thursday, April 16, 2015 6:06 PM > Subject: Re: [mpls] end of WGLC, RE: working group last call for > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Hi Ross, > > > > Thank you for Shepherding this document. > > > > We (authors) have posted the revision (-02) addressing all comments > > received during the LC of this document (thanks to those who provided > > comments!). > > > > Thanks! > > > > -Nobo, on behalf of authors > > > > On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon > wrote: > > > > > This working group last call has ended, with sufficient support and > no > > > opposition. There have however been a number of comments received. > Thanks > > > to everyone who took the time to review the draft and comment. > > > > > > > > > > > > Authors, please update the draft in response to the comments. After > this > > > is done, I will submit the document for publication. > > > > > > > > > > > > Thanks, Ross > > > > > > > > > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross > Callon > > > *Sent:* Friday, March 20, 2015 10:04 AM > > > *To:* mpls@ietf.org > > > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org > > > *Subject:* [mpls] working group last call for > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > > > > > > Working Group, > > > > > > > > > > > > This is to initiate a working group last call on > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01. > > > > > > Because this WGLC will span the IETF in Dallas, it will be extended > to > > > three weeks. > > > > > > > > > > > > Please send your comments to the mpls wg mailing list > (mpls@ietf.org). > > > > > > > > > > > > There are no IPR disclosures against this document. All the authors > have > > > stated that they > > > > > > are not aware of any IPR that relates to this draft. > > > > > > > > > > > > This working group last call ends Friday April 10, 2015. > > > > > > > > > > > > Ross > > > > > > for the MPLS WG chairs > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > --089e0112cc808c3eb6051402f409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

Although we have added this tex= t after the list/bullet items in section 3.2:

If a responder LSR receives a Reply Mode Order TLV which does= not comply to the rules described above, then the responder LSR MUST ignore the Reply Mode Order TLV.

You are right, it doesn't co=
ver the case where a receiver (the initiator LSR) receives an MPLS echo rep=
ly with a Reply Mode Order TLV. Perhaps above text should be changed to:

   If an LSR receives a Reply Mode Order TLV which does not
   comply to the rules described above, then the LSR MUST
   ignore the Reply Mode Order TLV.

Will that address your first comment?

Regarding your second comment=
 (3.2-6), is that really too ambiguous? To me, that text translates to foll=
owing implementations:
- When sending a Reply Mode Order TLV, 2 or more Reply Mode val=
ues shall be present.
- When receiving a Reply Mode Order TLV, accept 1 or more Reply =
Mode values.

If y=
ou think the text really should be updated, then we can change (3.2-6):

[OLD]
   6.  Rep=
ly Mode Order TLV MUST contain at least one Reply Mode value,
       and SHOULD contain at least two Reply Mode values.

[NEW]
=

   6.  Reply Mode Order TLV MUST contain at least one Reply =
Mode value.

Thoughts?

Th=
anks!

<=
/pre>
-Nobo
=

On Th= u, Apr 16, 2015 at 10:30 AM, t.petch <ietfc@btconnect.com>= wrote:
Nobo

I was struck by Adrian's comment which, if I understand correctly, was<= br> what to do if a MUST or SHOULD is violated and as I see it, I am unclear if this was addressed.

Thus 3.2 2) what should a recipient do when the echo reply does contain
a Reply Mode Order TLV ?

Or in 6), 'SHOULD contain at least two Reply Mode values' - when ma= y
that SHOULD be violated and if it is, does that render the TLV not valid as described in 4?


Tom Petch

----- Original Message -----
From: "Nobo Akiya" <nobo.akiya.dev@gmail.com>
To: "Ross Callon" <rcal= lon@juniper.net>
Cc: <mpls@ietf.org>; <mpls-chairs@tools.ietf.org>;<= br> <draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org>
Sent: Thursday, April 16, 2015 6:06 PM
Subject: Re: [mpls] end of WGLC, RE: working group last call for
draft-ietf-mpls-lsp-ping-reply-mode-simple-01


> Hi Ross,
>
> Thank you for Shepherding this document.
>
> We (authors) have posted the revision (-02) addressing all comments > received during the LC of this document (thanks to those who provided<= br> > comments!).
>
> Thanks!
>
> -Nobo, on behalf of authors
>
> On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon <rcallon@juniper.net>
wrote:
>
> >=C2=A0 This working group last call has ended, with sufficient sup= port and
no
> > opposition. There have however been a number of comments received= .
Thanks
> > to everyone who took the time to review the draft and comment. > >
> >
> >
> > Authors, please update the draft in response to the comments. Aft= er
this
> > is done, I will submit the document for publication.
> >
> >
> >
> > Thanks, Ross
> >
> >
> >
> > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross
Callon
> > *Sent:* Friday, March 20, 2015 10:04 AM
> > *To:* mpls@ietf.org
> > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org
> > *Subject:* [mpls] working group last call for
> > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > >
> >
> >
> > Working Group,
> >
> >
> >
> > This is to initiate a working group last call on
> > draft-ietf-mpls-lsp-ping-reply-mode-simple-01.
> >
> > Because this WGLC will span the IETF in Dallas, it will be extend= ed
to
> > three weeks.
> >
> >
> >
> > Please send your comments to the mpls wg mailing list
(mpls@ietf.org).
> >
> >
> >
> > There are no IPR disclosures against this document. All the autho= rs
have
> > stated that they
> >
> > are not aware of any IPR that relates to this draft.
> >
> >
> >
> > This working group last call ends Friday=C2=A0 April 10, 2015. > >
> >
> >
> > Ross
> >
> > for the MPLS WG chairs
> >
> >
> >
> >
> >
>


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


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


--089e0112cc808c3eb6051402f409-- From nobody Sat Apr 18 10:46:05 2015 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 367181A870F for ; Sat, 18 Apr 2015 10:46:02 -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 fFHCKO503YJB for ; Sat, 18 Apr 2015 10:46:00 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B581A8702 for ; Sat, 18 Apr 2015 10:45:59 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so104032729lbb.0 for ; Sat, 18 Apr 2015 10:45:58 -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=/UQRD8GGu73HSTe/HxO/jAIIWst/xlkbi4MQYBNAEc8=; b=BMUyos7HdxkE1D5nDp36A5QvKXD56fBPwcbsbMeZxU3m3tUCy8+pXsg0g5CmYbRSF9 BAsAZaeVxgNB6mJKkK4jGepzsu9gb79i78mdVDJdkvdfKxv8AeGhE5BpIN83G8pPUixg NglQ9nmkqrFlZJ8CKzDmUDq40xEU4ZflrcscVYWOdszwvWpND253jyBV91Y0+uGzSPzt PW9JUFXz0gBjM0ROFNTuXUMNM6chfj/SDUcyPoA7CF5yEYzC5uDaAtMc6LVNtVrLMjeX TNJqH7QLHB3XbzCv92p7dXS+5btWABjXPBoAo6t4BzE7Zy+Fzkmobbc2cT6iRobDpWiU 73zA== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr9056677laj.48.1429379158218; Sat, 18 Apr 2015 10:45:58 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Sat, 18 Apr 2015 10:45:58 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94CDFF@eusaamb103.ericsson.se> References: <005801d07006$789a7ed0$69cf7c70$@gmail.com> <7347100B5761DC41A166AC17F22DF1121B94CDFF@eusaamb103.ericsson.se> Date: Sat, 18 Apr 2015 10:45:58 -0700 Message-ID: From: Nobo Akiya To: Gregory Mirsky Content-Type: multipart/alternative; boundary=089e0160adf8f99db80514034483 Archived-At: Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf 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, 18 Apr 2015 17:46:02 -0000 --089e0160adf8f99db80514034483 Content-Type: text/plain; charset=UTF-8 Hi Greg, Snipping out ones concluded (thanks for addressing them!). > 4. Section 2.2.4 > > There needs to be some synchronicity between AuthType/AuthKeyID to > specified in "this" MPLS echo request message and AuthType/AuthKeyID being > used by BFD control packets. For example: > > - If BFD control packets using "new" auth is received by the egress LSR > before MPLS echo request with new "auth" is received, all BFD control > packets using "new" auth will be dropped. > - To take that a step further, if BFD control packets using "new" auth is > received by the egress LSR before "this" MPLS echo request is received by > the egress LSR and corresponding BFD session is updated to point to the > "new" auth , all BFD control packets using "new" auth will be dropped. > - If BFD control packets using "new" auth is only sent X time after > sending the MPLS echo request with new "auth", then it is not guaranteed > that the egress LSR will still be accepting BFD control packets with "old" > auth for X amount of time. > - And of course there's the error case of the egress LSR not being able to > support the specified the "new" auth specified in received MPLS echo > request, but the ingress LSR starts using the "new" auth before it receives > back NOSUP from the egress LSR via MPLS echo reply. > > I suspect if sufficient details are not defined, we would likely run into > some inter-op issues with this aspect. > > GIM>> I agree, more details should be provided. How about a new paragraph > added to the section: > If BFD Authentication sub-TLV used for a BFD session in Up state then > the Sender of the MPLS LSP Echo Request SHOULD ensure that old and > new modes of authentication, i.e. combination of Auth.Type and Auth. > Key ID, used to send and receive BFD control packets until the > Sender can confirm that its peer had switched to the new > authentication. > > IMO, I think there are couple of critical aspects which have to be described. 1. Sender: a. Sender of BFD authentication change via MPLS echo request must not start using the new authentication type/key until it receives back the acknowledgement via MPLS echo reply. b. BFD authentication must change to the new authentication type/key within a reasonable time after receiving back acknowledgement via MPLS echo reply. 2. Receiver: a. Receiver of BFD authentication change in MPLS echo request must setup the BFD receive path to accept both old & new authentication type/key for the session before sending back the acknowledgement via MPLS echo reply. b. Old authentication type/key can get unassociated from the session once the BFD session starts receiving the new authentication type/key. Still there is one gotcha, which is that MPLS echo reply is unreliable (i.e., typically an IP routed UDP packet). So there is a chance that MPLS echo reply can get lost in transit. In addition, we need the receiver to setup the SW/HW path (in step 2a above). That means the receiver may not be able to send MPLS echo reply immediate (i.e., ping times out). To protect from these, we probably want the sender to resent the BFD authentication change in MPLS echo request if corresponding MPLS echo reply is not received back. Note, don't take above texts as is ... sort of wrote this email in a hurry. Thanks! -Nobo --089e0160adf8f99db80514034483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Greg,

Snipping out ones conclu= ded (thanks for addressing them!).


4. Section 2.2.4

There needs to be some synchronicity between AuthType/AuthKeyID to specifie= d in "this" MPLS echo request message and AuthType/AuthKeyID bein= g used by BFD control packets. For example:

- If BFD control packets using "new" auth is received by the egre= ss LSR before MPLS echo request with new "auth" is received, all = BFD control packets using "new" auth will be dropped.
- To take that a step further, if BFD control packets using "new"= auth is received by the egress LSR before "this" MPLS echo reque= st is received by the egress LSR and corresponding BFD session is updated t= o point to the "new" auth , all BFD control packets using "n= ew" auth will be dropped.
- If BFD control packets using "new" auth is only sent X time aft= er sending the MPLS echo request with new "auth", then it is not = guaranteed that the egress LSR will still be accepting BFD control packets = with "old" auth for X amount of time.
- And of course there's the error case of the egress LSR not being able= to support the specified the "new" auth specified in received MP= LS echo request, but the ingress LSR starts using the "new" auth = before it receives back NOSUP from the egress LSR via MPLS echo reply.

I suspect if sufficient details are not defined, we would likely run into s= ome inter-op issues with this aspect.

GIM>> I agree, more details should be provided. How about a ne= w paragraph added to the section:
=C2=A0 =C2=A0If BFD Authentication sub-TLV used for a BFD session in Up sta= te then
=C2=A0 =C2=A0the Sender of the MPLS LSP Echo Request SHOULD ensure that old= and
=C2=A0 =C2=A0new modes of authentication, i.e. combination of Auth.Type and= Auth.
=C2=A0 =C2=A0Key ID, used to send and receive BFD control packets until the=
=C2=A0 =C2=A0Sender can confirm that its peer had switched to the new
=C2=A0 =C2=A0authentication.

<= br>
IMO, I think there are couple of critical aspects which have = to be described.

1. Sender:
=C2=A0 a. Se= nder of BFD authentication change via MPLS echo request must not start usin= g the new authentication type/key until it receives back the acknowledgemen= t via MPLS echo reply.
=C2=A0 b. BFD authentication must change t= o the new authentication type/key within a reasonable time after receiving = back acknowledgement via MPLS echo reply.

2. Recei= ver:
=C2=A0 a. Receiver of BFD authentication change in MPLS echo= request must setup the BFD receive path to accept both old & new authe= ntication type/key for the session before sending back the acknowledgement = via MPLS echo reply.
=C2=A0 b. Old authentication type/key can ge= t unassociated from the session once the BFD session starts receiving the n= ew authentication type/key.

Still there is one got= cha, which is that MPLS echo reply is unreliable (i.e., typically an IP rou= ted UDP packet). So there is a chance that MPLS echo reply can get lost in = transit. In addition, we need the receiver to setup the SW/HW path (in step= 2a above). That means the receiver may not be able to send MPLS echo reply= immediate (i.e., ping times out). To protect from these, we probably want = the sender to resent the BFD authentication change in MPLS echo request if = corresponding MPLS echo reply is not received back.

Note, don't take above texts as is ... sort of wrote this email in a = hurry.

Thanks!

-Nobo


--089e0160adf8f99db80514034483-- From nobody Sun Apr 19 02:09:19 2015 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 B474C1B2ACF for ; Sun, 19 Apr 2015 02:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 wSWPAM3zb58b for ; Sun, 19 Apr 2015 02:09:15 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1713D1A1B29 for ; Sun, 19 Apr 2015 02:09:14 -0700 (PDT) Received: from pc6 (81.151.162.168) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.130.23; Sun, 19 Apr 2015 09:08:53 +0000 Message-ID: <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> From: t.petch To: Nobo Akiya References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> Date: Sun, 19 Apr 2015 10:07:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: AMSPR02CA0023.eurprd02.prod.outlook.com (10.242.225.151) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(41574002)(51704005)(377454003)(164054003)(24454002)(51444003)(50466002)(42186005)(15975445007)(110136001)(93886004)(19580395003)(84392001)(19580405001)(86362001)(23676002)(122386002)(5820100001)(62966003)(77156002)(40100003)(62236002)(61296003)(66066001)(44716002)(81686999)(50226001)(50986999)(77096005)(76176999)(92566002)(230783001)(46102003)(14496001)(33646002)(81816999)(1456003)(47776003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 05514B7026 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2015 09:08:53.8204 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: Ross Callon , mpls , mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 19 Apr 2015 09:09:17 -0000 Inline, and including Adrian in the reply since really I am piggybacking on his comment. Tom Petch ---- Original Message ----- From: "Nobo Akiya" To: "t.petch" Cc: "Ross Callon" ; "mpls" ; ; Sent: Saturday, April 18, 2015 6:23 PM > Hi Tom, > > Although we have added this text after the list/bullet items in section 3.2: > > If a responder LSR receives a Reply Mode Order TLV which does not > comply to the rules described above, then the responder LSR MUST > ignore the Reply Mode Order TLV. > > You are right, it doesn't cover the case where a receiver (the > initiator LSR) receives an MPLS echo reply with a Reply Mode Order > TLV. Perhaps above text should be changed to: > > If an LSR receives a Reply Mode Order TLV which does not > comply to the rules described above, then the LSR MUST > ignore the Reply Mode Order TLV. > > Will that address your first comment? Yes but ... I think that it is a change of meaning. Is is enough just to ignore the TLV or should the whole PDU be discarded? I find it difficult to know but don't feel strongly about that choice so will go with what you suggest. > > Regarding your second comment (3.2-6), is that really too ambiguous? > To me, that text translates to following implementations: > > - When sending a Reply Mode Order TLV, 2 or more Reply Mode values > shall be present. > > - When receiving a Reply Mode Order TLV, accept 1 or more Reply Mode values. Again, that is a change of meaning to me. SHALL, if not shall, is the same as MUST while 'SHOULD', in our jargon, says there are reasons (not) to do it and RFC commonly spell out such reasons for doing so. So the NEW text below is a change IMHO. But again, I have no strong feelings about it. Tom Petch > If you think the text really should be updated, then we can change (3.2-6): > > [OLD] > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, > and SHOULD contain at least two Reply Mode values. > > [NEW] > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode value. > > > Thoughts? > > > Thanks! > > > -Nobo > > > On Thu, Apr 16, 2015 at 10:30 AM, t.petch wrote: > > > Nobo > > > > I was struck by Adrian's comment which, if I understand correctly, was > > what to do if a MUST or SHOULD is violated and as I see it, I am unclear > > if this was addressed. > > > > Thus 3.2 2) what should a recipient do when the echo reply does contain > > a Reply Mode Order TLV ? > > > > Or in 6), 'SHOULD contain at least two Reply Mode values' - when may > > that SHOULD be violated and if it is, does that render the TLV not valid > > as described in 4? > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Nobo Akiya" > > To: "Ross Callon" > > Cc: ; ; > > > > Sent: Thursday, April 16, 2015 6:06 PM > > Subject: Re: [mpls] end of WGLC, RE: working group last call for > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > Hi Ross, > > > > > > Thank you for Shepherding this document. > > > > > > We (authors) have posted the revision (-02) addressing all comments > > > received during the LC of this document (thanks to those who provided > > > comments!). > > > > > > Thanks! > > > > > > -Nobo, on behalf of authors > > > > > > On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon > > wrote: > > > > > > > This working group last call has ended, with sufficient support and > > no > > > > opposition. There have however been a number of comments received. > > Thanks > > > > to everyone who took the time to review the draft and comment. > > > > > > > > > > > > > > > > Authors, please update the draft in response to the comments. After > > this > > > > is done, I will submit the document for publication. > > > > > > > > > > > > > > > > Thanks, Ross > > > > > > > > > > > > > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross > > Callon > > > > *Sent:* Friday, March 20, 2015 10:04 AM > > > > *To:* mpls@ietf.org > > > > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org > > > > *Subject:* [mpls] working group last call for > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > > > > > > > > > > Working Group, > > > > > > > > > > > > > > > > This is to initiate a working group last call on > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01. > > > > > > > > Because this WGLC will span the IETF in Dallas, it will be extended > > to > > > > three weeks. > > > > > > > > > > > > > > > > Please send your comments to the mpls wg mailing list > > (mpls@ietf.org). > > > > > > > > > > > > > > > > There are no IPR disclosures against this document. All the authors > > have > > > > stated that they > > > > > > > > are not aware of any IPR that relates to this draft. > > > > > > > > > > > > > > > > This working group last call ends Friday April 10, 2015. > > > > > > > > > > > > > > > > Ross > > > > > > > > for the MPLS WG chairs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- -- > > -------- > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > From nobody Sun Apr 19 15:07:29 2015 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 465291A8986 for ; Sun, 19 Apr 2015 15:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_15=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 RJ0pgziEnyYI for ; Sun, 19 Apr 2015 15:07:24 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013C51A898C for ; Sun, 19 Apr 2015 15:07:24 -0700 (PDT) Received: by lagv1 with SMTP id v1so114120948lag.3 for ; Sun, 19 Apr 2015 15:07:22 -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=ae4ydzH6W6vpEnHCoXO05OFKASlyC2zqnNCycOSN3k4=; b=eqOiV1xNNd9zFpOfHol5VMF5VSXmbEqJ0z3ouxPeqeE2wgabB3Ns/O9nQbCJnl4mVV udBEe/XPc3JXt2gJLP3bmUOzfY1bLz5eM/ysZAdFuCpwDuCSYcRjvC7ePskk8GRCq/+T tUgGdoRZVd4kcgcVjucJ57JwtAwjdn2hGryh+Sym9+F6eWYZqm90zs7mtIhx9toRve8F JipOmvdYG02q/CrtcXv97Ge1Bpxai4KNXO4RCHimvkhWjx01spmFd2trleU25xDS7U1O tIqyMUZmwqYKHbYDM3bvzHDtXr/85WZRQ6lCbG3y9xJvRgNnjvaY5Fvf++JMAOcQXu7T H2WQ== MIME-Version: 1.0 X-Received: by 10.152.87.70 with SMTP id v6mr4035738laz.30.1429481242403; Sun, 19 Apr 2015 15:07:22 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Sun, 19 Apr 2015 15:07:22 -0700 (PDT) In-Reply-To: <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> Date: Sun, 19 Apr 2015 15:07:22 -0700 Message-ID: From: Nobo Akiya To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c363ccaaa93205141b0905 Archived-At: Cc: Ross Callon , mpls , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 19 Apr 2015 22:07:27 -0000 --001a11c363ccaaa93205141b0905 Content-Type: text/plain; charset=UTF-8 Hi Tom, Please see in-line with [NOBO]. On Sun, Apr 19, 2015 at 2:07 AM, t.petch wrote: > Inline, and including Adrian in the reply since really I am piggybacking > on his comment. > > Tom Petch > > > ---- Original Message ----- > From: "Nobo Akiya" > To: "t.petch" > Cc: "Ross Callon" ; "mpls" ; > ; > > Sent: Saturday, April 18, 2015 6:23 PM > > > Hi Tom, > > > > Although we have added this text after the list/bullet items in > section 3.2: > > > > If a responder LSR receives a Reply Mode Order TLV which does not > > comply to the rules described above, then the responder LSR MUST > > ignore the Reply Mode Order TLV. > > > > You are right, it doesn't cover the case where a receiver (the > > initiator LSR) receives an MPLS echo reply with a Reply Mode Order > > TLV. Perhaps above text should be changed to: > > > > If an LSR receives a Reply Mode Order TLV which does not > > comply to the rules described above, then the LSR MUST > > ignore the Reply Mode Order TLV. > > > > Will that address your first comment? > > > > Yes but ... I think that it is a change of meaning. Is is enough just > to ignore the TLV or should the whole PDU be discarded? I find it > difficult to know but don't feel strongly about that choice so will go > with what you suggest. > > > [NOBO] I see where you are coming from. We explicitly made the Reply Mode Order TLV an optional TLV (i.e., requests code point from 32768-49161). There are still many ways one can behave when a received optional TLV was "bad", but let's not get into that with this thread. Instead, let me just state that dropping just this optional TLV when the TLV is bad is not a wrong behavior. We will respin the document to update the text to cover the "initiator" side as well. Thanks for catching this! > > > Regarding your second comment (3.2-6), is that really too ambiguous? > > To me, that text translates to following implementations: > > > > - When sending a Reply Mode Order TLV, 2 or more Reply Mode values > > shall be present. > > > > - When receiving a Reply Mode Order TLV, accept 1 or more Reply Mode > values. > > > > Again, that is a change of meaning to me. SHALL, if not shall, is the > same as MUST while 'SHOULD', in our jargon, says there are reasons > (not) to do it and RFC commonly spell out such reasons for doing so. So > the NEW text below is a change IMHO. But again, I have no strong > feelings about it. > > Tom Petch > > > [NOBO] Ok, probably best to just say "MUST have at least one Reply Mode value" (and remove the SHOULD portion of this bullet/item) to avoid any confusion. We will update this document with this change. Thanks! -Nobo > > If you think the text really should be updated, then we can change > (3.2-6): > > > > [OLD] > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode > value, > > and SHOULD contain at least two Reply Mode values. > > > > [NEW] > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode > value. > > > > > > Thoughts? > > > > > > Thanks! > > > > > > -Nobo > > > > > > On Thu, Apr 16, 2015 at 10:30 AM, t.petch wrote: > > > > > Nobo > > > > > > I was struck by Adrian's comment which, if I understand correctly, > was > > > what to do if a MUST or SHOULD is violated and as I see it, I am > unclear > > > if this was addressed. > > > > > > Thus 3.2 2) what should a recipient do when the echo reply does > contain > > > a Reply Mode Order TLV ? > > > > > > Or in 6), 'SHOULD contain at least two Reply Mode values' - when may > > > that SHOULD be violated and if it is, does that render the TLV not > valid > > > as described in 4? > > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Nobo Akiya" > > > To: "Ross Callon" > > > Cc: ; ; > > > > > > Sent: Thursday, April 16, 2015 6:06 PM > > > Subject: Re: [mpls] end of WGLC, RE: working group last call for > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > > > > Hi Ross, > > > > > > > > Thank you for Shepherding this document. > > > > > > > > We (authors) have posted the revision (-02) addressing all > comments > > > > received during the LC of this document (thanks to those who > provided > > > > comments!). > > > > > > > > Thanks! > > > > > > > > -Nobo, on behalf of authors > > > > > > > > On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon > > > wrote: > > > > > > > > > This working group last call has ended, with sufficient support > and > > > no > > > > > opposition. There have however been a number of comments > received. > > > Thanks > > > > > to everyone who took the time to review the draft and comment. > > > > > > > > > > > > > > > > > > > > Authors, please update the draft in response to the comments. > After > > > this > > > > > is done, I will submit the document for publication. > > > > > > > > > > > > > > > > > > > > Thanks, Ross > > > > > > > > > > > > > > > > > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross > > > Callon > > > > > *Sent:* Friday, March 20, 2015 10:04 AM > > > > > *To:* mpls@ietf.org > > > > > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org > > > > > *Subject:* [mpls] working group last call for > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > > > > > > > > > > > > > > > Working Group, > > > > > > > > > > > > > > > > > > > > This is to initiate a working group last call on > > > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01. > > > > > > > > > > Because this WGLC will span the IETF in Dallas, it will be > extended > > > to > > > > > three weeks. > > > > > > > > > > > > > > > > > > > > Please send your comments to the mpls wg mailing list > > > (mpls@ietf.org). > > > > > > > > > > > > > > > > > > > > There are no IPR disclosures against this document. All the > authors > > > have > > > > > stated that they > > > > > > > > > > are not aware of any IPR that relates to this draft. > > > > > > > > > > > > > > > > > > > > This working group last call ends Friday April 10, 2015. > > > > > > > > > > > > > > > > > > > > Ross > > > > > > > > > > for the MPLS WG chairs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > -- > > > -------- > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > --001a11c363ccaaa93205141b0905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

Please see in-line with [NOBO].

On Sun, Apr 19, 2015 at 2:07 AM, t.petch <= span dir=3D"ltr"><ietfc@btconnect.com> wrote:
Inline, an= d including Adrian in the reply since really I am piggybacking
on his comment.

Tom Petch


---- Original Message -----
From: "Nobo Akiya" <nobo.akiya.dev@gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Ross Callon" <rcal= lon@juniper.net>; "mpls" <mpls@ietf.org>;
<mpls-chairs@tools.ietf.or= g>;
<draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org>
Sent: Saturday, April 18, 2015 6:23 PM

> Hi Tom,
>
> Although we have added this text after the list/bullet items in
section 3.2:
>
>=C2=A0 =C2=A0 If a responder LSR receives a Reply Mode Order TLV which = does not
>=C2=A0 =C2=A0 comply to the rules described above, then the responder L= SR MUST
>=C2=A0 =C2=A0 ignore the Reply Mode Order TLV.
>
> You are right, it doesn't cover the case where a receiver (the
> initiator LSR) receives an MPLS echo reply with a Reply Mode Order
> TLV. Perhaps above text should be changed to:
>
>=C2=A0 =C2=A0 If an LSR receives a Reply Mode Order TLV which does not<= br> >=C2=A0 =C2=A0 comply to the rules described above, then the LSR MUST >=C2=A0 =C2=A0 ignore the Reply Mode Order TLV.
>
> Will that address your first comment?

<tp>

Yes but ... I think that it is a change of meaning.=C2=A0 Is is enough just=
to ignore the TLV or should the whole PDU be discarded?=C2=A0 I find it
difficult to know but don't feel strongly about that choice so will go<= br> with what you suggest.

</tp>

[NOBO] I see where you are = coming from. We explicitly made the Reply Mode Order TLV an optional TLV (i= .e., requests code point from=C2=A032768-49161). There are = still many ways one can behave when a received optional TLV was "bad&q= uot;, but let's not get into that with this thread. Instead, let me jus= t state that dropping just this optional TLV when the TLV is bad is not a w= rong behavior. We will respin the document to update the text to cov= er the "initiator" side as well. Thanks for catching this!
<= div>
>
> Regarding your second comment (3.2-6), is that really too ambiguous? > To me, that text translates to following implementations:
>
> - When sending a Reply Mode Order TLV, 2 or more Reply Mode values
> shall be present.
>
> - When receiving a Reply Mode Order TLV, accept 1 or more Reply Mode values.

<tp>

Again, that is a change of meaning to me.=C2=A0 SHALL, if not shall, is the=
same as MUST while=C2=A0 'SHOULD', in our jargon, says there are re= asons
(not) to do it and RFC commonly spell out such reasons for doing so.=C2=A0 = So
the NEW text below is a change IMHO.=C2=A0 But again, I have no strong
feelings about it.

Tom Petch
</tp>


[NOBO] Ok, probably best to just say "MUST have = at least one Reply Mode value" (and remove the SHOULD portion of this = bullet/item) to avoid any confusion. We will update this document with this= change.

Thanks!

-Nobo
=C2=A0
> If you think the text really should be updated, then we can change
(3.2-6):
>
> [OLD]
>
>=C2=A0 =C2=A0 6.=C2=A0 Reply Mode Order TLV MUST contain at least one R= eply Mode
value,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and SHOULD contain at least two Reply Mode = values.
>
> [NEW]
>
>=C2=A0 =C2=A0 6.=C2=A0 Reply Mode Order TLV MUST contain at least one R= eply Mode
value.
>
>
> Thoughts?
>
>
> Thanks!
>
>
> -Nobo
>
>
> On Thu, Apr 16, 2015 at 10:30 AM, t.petch <ietfc@btconnect.com> wrote:
>
> > Nobo
> >
> > I was struck by Adrian's comment which, if I understand corre= ctly,
was
> > what to do if a MUST or SHOULD is violated and as I see it, I am<= br> unclear
> > if this was addressed.
> >
> > Thus 3.2 2) what should a recipient do when the echo reply does contain
> > a Reply Mode Order TLV ?
> >
> > Or in 6), 'SHOULD contain at least two Reply Mode values'= - when may
> > that SHOULD be violated and if it is, does that render the TLV no= t
valid
> > as described in 4?
> >
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Nobo Akiya" <nobo.akiya.dev@gmail.com>
> > To: "Ross Callon" <rcallon@juniper.net>
> > Cc: <mpls@ietf.org>; &= lt;mpls-chairs@tools.ietf.org= >;
> > <draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org>
> > Sent: Thursday, April 16, 2015 6:06 PM
> > Subject: Re: [mpls] end of WGLC, RE: working group last call for<= br> > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01
> >
> >
> > > Hi Ross,
> > >
> > > Thank you for Shepherding this document.
> > >
> > > We (authors) have posted the revision (-02) addressing all comments
> > > received during the LC of this document (thanks to those who=
provided
> > > comments!).
> > >
> > > Thanks!
> > >
> > > -Nobo, on behalf of authors
> > >
> > > On Mon, Apr 13, 2015 at 9:03 AM, Ross Callon <rcallon@juniper.net>
> > wrote:
> > >
> > > >=C2=A0 This working group last call has ended, with suff= icient support
and
> > no
> > > > opposition. There have however been a number of comment= s
received.
> > Thanks
> > > > to everyone who took the time to review the draft and c= omment.
> > > >
> > > >
> > > >
> > > > Authors, please update the draft in response to the com= ments.
After
> > this
> > > > is done, I will submit the document for publication. > > > >
> > > >
> > > >
> > > > Thanks, Ross
> > > >
> > > >
> > > >
> > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross
> > Callon
> > > > *Sent:* Friday, March 20, 2015 10:04 AM
> > > > *To:* mpls@ietf.org
> > > > *Cc:* Loa Andersson; mpls-chairs@tools.ietf.org
> > > > *Subject:* [mpls] working group last call for
> > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01
> > > >
> > > >
> > > >
> > > > Working Group,
> > > >
> > > >
> > > >
> > > > This is to initiate a working group last call on
> > > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01.
> > > >
> > > > Because this WGLC will span the IETF in Dallas, it will= be
extended
> > to
> > > > three weeks.
> > > >
> > > >
> > > >
> > > > Please send your comments to the mpls wg mailing list > > (mpls@ietf.org).
> > > >
> > > >
> > > >
> > > > There are no IPR disclosures against this document. All= the
authors
> > have
> > > > stated that they
> > > >
> > > > are not aware of any IPR that relates to this draft. > > > >
> > > >
> > > >
> > > > This working group last call ends Friday=C2=A0 April 10= , 2015.
> > > >
> > > >
> > > >
> > > > Ross
> > > >
> > > > for the MPLS WG chairs
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>
> ----------------------------------------------------------------------=
--
> > --------
> >
> >
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> >
> >
>


--001a11c363ccaaa93205141b0905-- From nobody Mon Apr 20 13:19:38 2015 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 C49261B305B for ; Mon, 20 Apr 2015 13:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 oCuWWtxc5Lkn for ; Mon, 20 Apr 2015 13:19:34 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BEC1B3054 for ; Mon, 20 Apr 2015 13:19:33 -0700 (PDT) Received: by wiun10 with SMTP id n10so105503310wiu.1 for ; Mon, 20 Apr 2015 13:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vqVC2aHjDfynQ1Hly4RC0k5ipx1SM54cZBZVojIvT7I=; b=pz1IdFbtuY9uUCnAsZu35Xry9Ds+/GaeWduZGl4aYKIV39msq0E35YkpFk8fb9Wsio RZ3SCKSgttVR1bzNI3nXE8frjg/QZ+L7KKV8YPV57PblJd9KXwKyYHo1Jz/0OfHNgjF+ wqK4Ozobvq3CggIm/tX1j12GWSJYtCC72S49kvqjo/Il6OLhQJ1Glmcl/ND8RlQB/1dH UZVsvdT2nOzRB2GMZ9RkmX9jbMQlzNHcCtngDmISDSFtREgROfcsvYbWxGf9w7GzLvvo EHzzykr78rj69F8an4mDLCHXmQUwviK/F4WSsGJhtf0tCCPiNOdT9vwxdsiQVOBmlCns lBpA== X-Received: by 10.194.177.132 with SMTP id cq4mr32841772wjc.99.1429561171739; Mon, 20 Apr 2015 13:19:31 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id es5sm28706981wjc.30.2015.04.20.13.19.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 13:19:30 -0700 (PDT) Message-ID: <55355F51.1010306@gmail.com> Date: Mon, 20 Apr 2015 22:19:29 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [mpls] MSRP discussion X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 20:19:35 -0000 All, In: > Below are the *_preliminary_* minutes taken during IETF92 MPLS sessions. I noticed the following discussion: > Liang Geng’s (China Mobile) presentation on MSRP: > - Eric Osborne said that this draft needs some discussion as to why the > existing RFC(s) are inadequate. > - Loa asked if this observation applies to both this draft and Kireeti’s > draft. > - Eric said that – in his opinion – Kireeti’s draft already provides > enough info to distinguish its applicability. Section 2.3 of draft-cheng-mpls-tp-shared-ring-protection describes the Configuration Complexity. I will try to provide some more details: Suppose a ring with N nodes. --------------------------- Applying RFC6974 means that from every ring-node a linear protection configuration has to be provisioned with every other node in the ring, i.e. with (N-1) other nodes. This means that in every node there will be (N-1) instances of the PSC protocol. In order to detect faults and to transport the PSC OAM each instance shall have a MEP on the working path and a MEP on the protection path. (A MEP == co-located so_MEP and sk_MEP). This means that every ring-node should have the capability to support (N-1) * 2 MEPs. Applying draft-cheng-mpls-tp-shared-ring-protection means that in every ring-node there will be a single instance of the MSRP protocol. In order to detect faults and to transport the MSRP OAM each instance (e.g. in node N) shall have a MEP on the working path and a MEP on the protection path to node (N-1) and also to node (N+1). This means that every ring-node should have the capability to support 2 * 2 MEPs. Suppose a ring with N nodes, and one node has to be added: --------------------------------------------------------- Applying RFC6974 means that every existing ring-node has to be updated: a new PSC protocol instance created, and 2 MEPs instantiated. In the new node N PSC instances have to be created and N * 2 MEPs instanciated. Applying draft-cheng-mpls-tp-shared-ring-protection means that in every existing ring-node the ring-map has to be extended. In the new node a single MSRP instance has to be created and 4 MEPs instantiated. Note that the 4 MEPs have to be instantiated anyway to be able to monitor the links with the adjacent ring-nodes, so in fact only the MSRP OAM has to be enabled. Regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From nobody Tue Apr 21 08:27:49 2015 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 43C0A1ACE5E; Tue, 21 Apr 2015 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eGje1vuHflgg; Tue, 21 Apr 2015 08:27: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 9A1351ACE4D; Tue, 21 Apr 2015 08:27:29 -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 BRQ88849; Tue, 21 Apr 2015 15:27:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 16:27:26 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 08:27:23 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQAOobtwAA2TtZ4A== Date: Tue, 21 Apr 2015 15:27:22 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E3804B5@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.156] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-teas-rsvp-ingress-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, 21 Apr 2015 15:27:44 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. My answers/explanations are inline below with [Huaimo 2]. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, April 16, 2015 7:58 PM To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; te= as-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Huaimo, thank you for kind consideration of my comments. Please find more in-lined = and tagged GIM>> notes. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Sunday, April 12, 2015 11:04 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org<= mailto:draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>; teas-chairs= @ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. GIM>> I think it is strange to cite requirement on scale of seconds if not = tens of seconds in discussion of method of local protection that supposed t= o perform protection switchover in sub-second if not sub-50msec time. [Huaimo 2] The requirement is for the control plane. More specifically, it = is for the PATH message (not to be cleaned up) for the LSP at the next hop = of the primary ingress of the LSP when the primary ingress fails. After the= primary ingress fails, the next hop will not receive any PATH message from= the primary ingress. In order to prevent the PATH message from clean up at= the next hop, the backup ingress seems required to detect the failure of t= he primary ingress and send/refresh the PATH message to the next hop before= the PATH message is cleaned up. Thus it seems reasonable for the requireme= nt to have the time for detecting the failure of the primary ingress in sec= onds or even tens of seconds instead of sub-seconds or within 50 ms. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. GIM>> As noted above, these seem as requirements of different scale. [Huaimo 2] See the explanation above. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. GIM>> Routing convergence may take seconds. Is that acceptable as failure d= etection time for local protection? Protection switchover expected to be fa= st, perhaps on sub-50 msec scale. From TDM world we carry 10 msec failure d= etection, and BFD implementations can support that. but here, it appears, y= ou describe failure detection mechanism with detection time on scale of sec= onds if not tens of seconds. [Huaimo 2] The routing convergence is for the control plane. Refer to the e= xplanation above. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. GIM>> In that case, the text is not needed either. [Huaimo 2] Can you give more details regarding to "the text is not needed e= ither"? Which part of the text (do you think) is not needed in section 5.1? Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. GIM>> If this is historical part, then it may be moved to Appendix or taken= from the document altogether. [Huaimo 2] A couple of detection modes were removed from the document. One = more will be smoothed out. Thus there will be only one mode in the document= . Can you give more details about the cases in which false positives may be p= roduced? GIM>> If current proposal is limited to Source-detect case only then possi= bility of false positive/negative depends on Source to Ingress connection a= nd OAM mechanism used. But that is deployment issue and is outside of scope= of this document Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below with [Huaimo 2].<= /span>

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, April 16, 2015 7:58 PM
To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.= org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Huaimo,<= /span>

thank you for kind con= sideration of my comments. Please find more in-lined and tagged GIM>>= notes.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf= .org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·        Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·        Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

GIM>> I think it= is strange to cite requirement on scale of seconds if not tens of seconds = in discussion of method of local protection that supposed to perform protec= tion switchover in sub-second if not sub-50msec time.

[Huaimo 2] The require= ment is for the control plane. More specifically, it is for the PATH messag= e (not to be cleaned up) for the LSP at the next hop of the primary ingress= of the LSP when the primary ingress fails. After the primary ingress fails, the next hop will not receive any = PATH message from the primary ingress. In order to prevent the PATH message= from clean up at the next hop, the backup ingress seems required to detect= the failure of the primary ingress and send/refresh the PATH message to the next hop before the PATH message = is cleaned up. Thus it seems reasonable for the requirement to have the tim= e for detecting the failure of the primary ingress in seconds or even tens = of seconds instead of sub-seconds or within 50 ms.

 

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

GIM>> As noted a= bove, these seem as requirements of different scale.

[Huaimo 2] See the exp= lanation above.

 

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

GIM>> Routing co= nvergence may take seconds. Is that acceptable as failure detection time fo= r local protection? Protection switchover expected to be fast, perhaps on s= ub-50 msec scale. From TDM world we carry 10 msec failure detection, and BFD implementations can support that. but h= ere, it appears, you describe failure detection mechanism with detection ti= me on scale of seconds if not tens of seconds.

[Huaimo 2] The routing= convergence is for the control plane. Refer to the explanation above.=

 

·        Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

GIM>> In that ca= se, the text is not needed either.

[Huaimo 2] Can you giv= e more details regarding to “the text is not needed either”? Wh= ich part of the text (do you think) is not needed in section 5.1?

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

GIM>> If this is= historical part, then it may be moved to Appendix or taken from the docume= nt altogether.

[Huaimo 2] A couple of= detection modes were removed from the document. One more will be smoothed = out. Thus there will be only one mode in the document.

 

Can you give more deta= ils about the cases in which false positives may be produced?

GIM>> If current= proposal is limited to Source-detect case only  then possibility of f= alse positive/negative depends on Source to Ingress connection and OAM mech= anism used. But that is deployment issue and is outside of scope of this document

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_-- From nobody Tue Apr 21 17:19:52 2015 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 E1DEE1B2F3C for ; Tue, 21 Apr 2015 17:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SXk253wnIEJJ for ; Tue, 21 Apr 2015 17:19:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC8E1B2F32 for ; Tue, 21 Apr 2015 17:19:48 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1431.namprd05.prod.outlook.com (25.160.107.153) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 22 Apr 2015 00:19:29 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0136.026; Wed, 22 Apr 2015 00:19:29 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: [Rtg-yang-coord] Fwd: YANG Editing Session at IETF 93 Thread-Index: AQHQfEyAyruUKe+oOUW8VVtEoLDh8p1X1ndggABUB9A= Date: Wed, 22 Apr 2015 00:19:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.13] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1431; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(2473001)(69234005)(377454003)(66066001)(2656002)(77156002)(122556002)(76576001)(50986999)(54356999)(74316001)(46102003)(15975445007)(102836002)(16236675004)(19580395003)(33656002)(92566002)(19625215002)(2900100001)(18717965001)(62966003)(230783001)(19300405004)(2351001)(99286002)(110136001)(450100001)(40100003)(106116001)(86362001)(107886001)(19617315012)(19580405001)(2501003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1431; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY1PR0501MB1431; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1431; x-forefront-prvs: 0554B1F54F Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1430FF216388534093101B15A5EE0BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2015 00:19:29.1349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1431 Archived-At: Subject: [mpls] FW: [Rtg-yang-coord] Fwd: YANG Editing Session at IETF 93 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, 22 Apr 2015 00:19:51 -0000 --_000_BY1PR0501MB1430FF216388534093101B15A5EE0BY1PR0501MB1430_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLiBUaGVyZSB3aWxsIGJlIGEg4oCcWUFORyBBZHZpY2UgYW5kIEVkaXRpbmcgU2Vzc2lvbuKA nSBvbiBTdW5kYXkgYWZ0ZXJub29uIGF0IHRoZSB1cGNvbWluZyBJRVRGIGluIFByYWd1ZS4gVGhl IHBvaW50ZXIgYmVsb3cgZ2l2ZXMgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbi4NCg0KUm9zcw0KDQpG cm9tOiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCZW5vaXQgQ2xhaXNlDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwg MjAxNSAxMjowMiBQTQ0KVG86IFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFu Zy1jb29yZEBpZXRmLm9yZz4NClN1YmplY3Q6IFtSdGcteWFuZy1jb29yZF0gRndkOiBZQU5HIEVk aXRpbmcgU2Vzc2lvbiBhdCBJRVRGIDkzDQoNCkZZSS4NCg0KUmVnYXJkcywgQmVub2l0DQoNCg0K LS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCllBTkcgRWRp dGluZyBTZXNzaW9uIGF0IElFVEYgOTMNCg0KRGF0ZToNCg0KVHVlLCAyMSBBcHIgMjAxNSAxODow MToyMCArMDIwMA0KDQpGcm9tOg0KDQpCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT48 bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPg0KDQpUbzoNCg0KTkVUTU9EIFdvcmtpbmcgR3JvdXAg PG5ldG1vZEBpZXRmLm9yZz48bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KDQoNCkZZSS4NCg0K aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkzL3R1dG9yaWFscy95YW5nLXNlc3Npb24uaHRt bA0KDQoNCg0KUmVnYXJkcywgQmVub2l0DQoNCg0K --_000_BY1PR0501MB1430FF216388534093101B15A5EE0BY1PR0501MB1430_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RllJLiBUaGVyZSB3aWxsIGJlIGEg4oCcWUFORyBBZHZpY2UgYW5kIEVkaXRpbmcgU2Vz c2lvbuKAnSBvbiBTdW5kYXkgYWZ0ZXJub29uIGF0IHRoZSB1cGNvbWluZyBJRVRGIGluIFByYWd1 ZS4gVGhlIHBvaW50ZXIgYmVsb3cgZ2l2ZXMgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbi4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb3NzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gUnRnLXlhbmctY29vcmQgWzxhIGhyZWY9Im1haWx0bzpy dGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRnLXlhbmctY29vcmQtYm91 bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlbm9pdCBDbGFpc2U8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXByaWwgMjEsIDIwMTUgMTI6MDIgUE08YnI+DQo8Yj5U bzo8L2I+IDxhIGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyI+UnRnLXlhbmct Y29vcmRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtSdGcteWFuZy1jb29yZF0g RndkOiBZQU5HIEVkaXRpbmcgU2Vzc2lvbiBhdCBJRVRGIDkzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RllJLjxicj4NCjxicj4NClJlZ2FyZHMsIEJlbm9p dDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Ci0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIg c3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDxvOnA+PC9v OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPllBTkcgRWRpdGluZyBTZXNzaW9uIGF0IElFVEYgOTM8bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6IDxvOnA+PC9v OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlR1ZSwgMjEgQXByIDIwMTUgMTg6MDE6MjAgJiM0MzswMjAw PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpw PjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW5vaXQgQ2xhaXNlIDxhIGhyZWY9Im1haWx0bzpi Y2xhaXNlQGNpc2NvLmNvbSI+Jmx0O2JjbGFpc2VAY2lzY28uY29tJmd0OzwvYT48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlRvOiA8bzpwPjwvbzpwPjwvYj48 L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ORVRNT0QgV29ya2luZyBHcm91cCA8YSBocmVmPSJtYWlsdG86bmV0bW9k QGlldGYub3JnIj4mbHQ7bmV0bW9kQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5GWUku PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0 aW5nLzkzL3R1dG9yaWFscy95YW5nLXNlc3Npb24uaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9t ZWV0aW5nLzkzL3R1dG9yaWFscy95YW5nLXNlc3Npb24uaHRtbDwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLCBCZW5vaXQ8bzpw PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY1PR0501MB1430FF216388534093101B15A5EE0BY1PR0501MB1430_-- From nobody Wed Apr 22 06:15:26 2015 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 386BE1A017E for ; Wed, 22 Apr 2015 06:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ApFQdE-Z8ySd for ; Wed, 22 Apr 2015 06:15: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 492FE1A020B for ; Wed, 22 Apr 2015 06:15:20 -0700 (PDT) Received: from [10.33.12.45] (c-400770d5.45-1-64736c10.cust.bredbandsbolaget.se [213.112.7.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id ABC53180145E; Wed, 22 Apr 2015 15:15:17 +0200 (CEST) Message-ID: <55379EE5.8000801@pi.nu> Date: Wed, 22 Apr 2015 15:15:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nobo Akiya , "t.petch" References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ross Callon , mpls , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 22 Apr 2015 13:15:25 -0000 Tom, On 2015-04-20 00:07, Nobo Akiya wrote: > > > Yes but ... I think that it is a change of meaning. Is is enough just > to ignore the TLV or should the whole PDU be discarded? I find it > difficult to know but don't feel strongly about that choice so will go > with what you suggest. > > > > So I don't misunderstand what you are saying. It seems to me like the comments made by Adrian and you actually requires a "change of meaning", that is kind of essence of a "cooment", right? As for what to do with if the TLV is not recognized, it is intentionally requested from a space where it can be silently dropped (i.e. "ignored"). The new TLV Type value should be assigned from the range (32768-49161) specified in [RFC4379] section 3 that allows the TLV type to be silently dropped if not recognized. Type Meaning Reference ---- ------- --------- TBD1 Reply Mode Order TLV this document What is it that I miss? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 23 02:41:04 2015 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 2FA7F1A906A for ; Thu, 23 Apr 2015 02:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 RkcLoyI8xvDG for ; Thu, 23 Apr 2015 02:41:00 -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 882FE1A906D for ; Thu, 23 Apr 2015 02:40:35 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CFBDF1801127; Thu, 23 Apr 2015 11:40:33 +0200 (CEST) Message-ID: <5538BE10.60706@pi.nu> Date: Thu, 23 Apr 2015 11:40:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5530F834.40002@cs.tcd.ie> In-Reply-To: <5530F834.40002@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] would the WG like to adopt draft-farrelll-mpls-opportunistic-encrypt? 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, 23 Apr 2015 09:41:03 -0000 Working Group, I've read the draft (a while ago) and I think this document is within the wg charter and should be progressed by the mpls wg. (chair hat on> If I hear nothing to the contrary I will start the process with mpls-rt review, IPR poll and wg adoption poll first week of May. There has been some comments, but I think those are address. Please read and comment on the draft. /Loa On 2015-04-17 14:10, Stephen Farrell wrote: > > Hiya, > > Adrian and I wrote up [1]. How'd the WG feel about adopting > that? If you did, I'd be willing to continue editing if you > wanted. So consider this as a request that the WG take on > this work. > > In case it helps, the current abstract is: > > " > This document describes a way to apply opportunistic security > between adjacent nodes on an MPLS Label Switched Path (LSP) or > between end points of an LSP. It explains how keys may be agreed > to enable encryption, and how key identifiers are exchanged in > encrypted MPLS packets. Finally, this document describes the > applicability of this approach to opportunistic security in MPLS > networks with an indication of the level of improved security as > well as the continued vulnerabilities. > > This document does not describe security for MPLS control plane > protocols. > " > > Cheers, > S. > > [1] https://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt > > _______________________________________________ > 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 Thu Apr 23 02:48:54 2015 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 AA3231A905C for ; Thu, 23 Apr 2015 02:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 z3Qlc5Is80vr for ; Thu, 23 Apr 2015 02:48:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE801A9082 for ; Thu, 23 Apr 2015 02:48:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 923FCBE32; Thu, 23 Apr 2015 10:48:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK9sQSDd9yVg; Thu, 23 Apr 2015 10:48:36 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D7D54BECC; Thu, 23 Apr 2015 10:48:35 +0100 (IST) Message-ID: <5538BFF3.8030701@cs.tcd.ie> Date: Thu, 23 Apr 2015 10:48:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Loa Andersson , "mpls@ietf.org" References: <5530F834.40002@cs.tcd.ie> <5538BE10.60706@pi.nu> In-Reply-To: <5538BE10.60706@pi.nu> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] would the WG like to adopt draft-farrelll-mpls-opportunistic-encrypt? 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, 23 Apr 2015 09:48:52 -0000 Hiya, On 23/04/15 10:40, Loa Andersson wrote: > Working Group, > > > > I've read the draft (a while ago) and I think this document is within > the wg charter and should be progressed by the mpls wg. > > (chair hat on> > > If I hear nothing to the contrary I will start the process with > mpls-rt review, IPR poll and wg adoption poll first week of May. Thanks Loa. I'm not entirely familiar with the mpls-rt review but one issue on which I think some detailed requirements-level guidance would be useful for me is on whether this ought stick with "classic" integer DH or move to a more modern DH approach based on curve 25519. If you have reviewers who are familiar with the issues there and with MPLS performance and implementation requirements that'd be good. If not, I'm happy to try explain the pros and cons from the security and crypto POV, either to the reviewers or the list. And that can be done post-adoption on the list if that's better too, but it'd be a good thing to bottom out early-ish in the WG process. > There has been some comments, but I think those are address. Please > read and comment on the draft. Yes, I think we've addressed the substantive comments we've so far seen. Cheers, S. > > /Loa > > > > On 2015-04-17 14:10, Stephen Farrell wrote: >> >> Hiya, >> >> Adrian and I wrote up [1]. How'd the WG feel about adopting >> that? If you did, I'd be willing to continue editing if you >> wanted. So consider this as a request that the WG take on >> this work. >> >> In case it helps, the current abstract is: >> >> " >> This document describes a way to apply opportunistic security >> between adjacent nodes on an MPLS Label Switched Path (LSP) or >> between end points of an LSP. It explains how keys may be agreed >> to enable encryption, and how key identifiers are exchanged in >> encrypted MPLS packets. Finally, this document describes the >> applicability of this approach to opportunistic security in MPLS >> networks with an indication of the level of improved security as >> well as the continued vulnerabilities. >> >> This document does not describe security for MPLS control plane >> protocols. >> " >> >> Cheers, >> S. >> >> [1] https://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > From nobody Thu Apr 23 04:16:49 2015 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 221701B2D70 for ; Thu, 23 Apr 2015 04:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 hqCUHAIlQymQ for ; Thu, 23 Apr 2015 04:16:45 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF241B2D5A for ; Thu, 23 Apr 2015 04:16:41 -0700 (PDT) Authentication-Results: pi.nu; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.148.16; Thu, 23 Apr 2015 11:04:25 +0000 Message-ID: <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> From: t.petch To: Loa Andersson , Nobo Akiya References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> Date: Thu, 23 Apr 2015 12:02:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: AM3PR03CA015.eurprd03.prod.outlook.com (10.141.191.143) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(252514010)(377424004)(24454002)(51444003)(13464003)(377454003)(51704005)(86362001)(93886004)(92566002)(77096005)(61296003)(62966003)(77156002)(46102003)(47776003)(66066001)(42186005)(1456003)(33646002)(50466002)(23676002)(50226001)(19580405001)(19580395003)(230783001)(44716002)(62236002)(40100003)(87976001)(50986999)(81816999)(81686999)(76176999)(84392001)(5001770100001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 0555EC8317 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2015 11:04:25.2767 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: Ross Callon , mpls , mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 23 Apr 2015 11:16:48 -0000 ---- Original Message ----- From: "Loa Andersson" Sent: Wednesday, April 22, 2015 2:15 PM > Tom, > > On 2015-04-20 00:07, Nobo Akiya wrote: > > > > > > Yes but ... I think that it is a change of meaning. Is is enough just > > to ignore the TLV or should the whole PDU be discarded? I find it > > difficult to know but don't feel strongly about that choice so will go > > with what you suggest. > > > > > > So I don't misunderstand what you are saying. It seems to me like the > comments made by Adrian and you actually requires a "change of meaning", > that is kind of essence of a "cooment", right? > > As for what to do with if the TLV is not recognized, it is > intentionally requested from a space where it can be silently dropped > (i.e. "ignored"). > > The new TLV Type value should be assigned from the range > (32768-49161) specified in [RFC4379] section 3 that allows the TLV > type to be silently dropped if not recognized. > > Type Meaning Reference > ---- ------- --------- > TBD1 Reply Mode Order TLV this document > > What is it that I miss? Nothing serious. My initial thought was to echo Adrian, that, at least in this context, there should be an indication what to do if a MUST or SHOULD was violated without just then having a clear sense of what it should be instead. The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) more. Adding what to do if that did not happen I was seeing as clarification. I then read Nobo as proposing going a bit further saying requires (MUST) one or more. Which might lead to boxes taking a simplistic approach and always putting in the new TLV with a single entry and ignoring the traditional TLV. Not a problem just a change from what others might think that they have consented to. On the question of what to do when the rules are violated, again I did not initially think of what the action should be. On reflection, I am still unsure. I understand that the Reply Mode Order TLV is optional and so can be ignored when not understood; that's fine. But if it is understood and can be seen to be defective, should the box with that knowledge discard just that TLV and accept the remainder of the message? Or should it argue that if this TLV is defective, then likely the rest is as well and should be ignored? I am unsure. If there is scope for a breach of security, or taking a hit in performance, then ignore is the right policy. If the requirement is to get as much data as possible from a failing network, then use it is the right policy. As long as the I-D is clear, I am not too fussed which way it goes. I am content with the changes that Nobo has proposed. Tom Petch > /Loa > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 23 05:59:24 2015 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 68E061ACD13 for ; Thu, 23 Apr 2015 05:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] 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 pV1uemM32Fi0 for ; Thu, 23 Apr 2015 05:59:21 -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 2E7C61A92F4 for ; Thu, 23 Apr 2015 05:59:07 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A437C1801127; Thu, 23 Apr 2015 14:59:05 +0200 (CEST) Message-ID: <5538EC97.8050204@pi.nu> Date: Thu, 23 Apr 2015 14:59:03 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "t.petch" , Nobo Akiya References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> In-Reply-To: <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ross Callon , mpls , mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 23 Apr 2015 12:59:23 -0000 Tom, The question you and Adrian asks is what to do if the Reply Mode Order TLV is missing. There is something fishy here, I'd like George to look at this. The LSP Ping design says that TLVs from this range may be silentsly dropped, my take is that we don't need to specify anything more than that. Now, we say that it MUST be present, and after thinking around a bit I wonder if the TLV should be assigned from the mandatory range instead? Or if the MUST be present means that the message will be malformed if it is not there, and the message should be discarded. OK - now I'm confused. /Loa On 2015-04-23 13:02, t.petch wrote: > ---- Original Message ----- > From: "Loa Andersson" > Sent: Wednesday, April 22, 2015 2:15 PM > >> Tom, >> >> On 2015-04-20 00:07, Nobo Akiya wrote: >>> >>> >>> Yes but ... I think that it is a change of meaning. Is is > enough just >>> to ignore the TLV or should the whole PDU be discarded? I find > it >>> difficult to know but don't feel strongly about that choice so > will go >>> with what you suggest. >>> >>> >> >> So I don't misunderstand what you are saying. It seems to me like the >> comments made by Adrian and you actually requires a "change of > meaning", >> that is kind of essence of a "comment", right? >> >> As for what to do with if the TLV is not recognized, it is >> intentionally requested from a space where it can be silently dropped >> (i.e. "ignored"). >> >> The new TLV Type value should be assigned from the range >> (32768-49161) specified in [RFC4379] section 3 that allows the TLV >> type to be silently dropped if not recognized. >> >> Type Meaning Reference >> ---- ------- --------- >> TBD1 Reply Mode Order TLV this document >> >> What is it that I miss? > > Nothing serious. My initial thought was to echo Adrian, that, at least > in this context, there should be an indication what to do if a MUST or > SHOULD was violated without just then having a clear sense of what it > should be instead. > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > more. Adding what to do if that did not happen I was seeing as > clarification. I then read Nobo as proposing going a bit further saying > requires (MUST) one or more. Which might lead to boxes taking a > simplistic approach and always putting in the new TLV with a single > entry and ignoring the traditional TLV. Not a problem just a change > from what others might think that they have consented to. > > On the question of what to do when the rules are violated, again I did > not initially think of what the action should be. On reflection, I am > still unsure. I understand that the Reply Mode Order TLV is optional > and so can be ignored when not understood; that's fine. But if it is > understood and can be seen to be defective, should the box with that > knowledge discard just that TLV and accept the remainder of the message? > Or should it argue that if this TLV is defective, then likely the rest > is as well and should be ignored? I am unsure. > > If there is scope for a breach of security, or taking a hit in > performance, then ignore is the right policy. If the requirement is to > get as much data as possible from a failing network, then use it is the > right policy. As long as the I-D is clear, I am not too fussed which > way it goes. I am content with the changes that Nobo has proposed. > > Tom Petch > >> /Loa >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 23 06:16:10 2015 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 6BF451AC445 for ; Thu, 23 Apr 2015 06:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 FlII7YAo8vvI for ; Thu, 23 Apr 2015 06:16:07 -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 8F6201B2EA3 for ; Thu, 23 Apr 2015 06:15:57 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 41A321801127; Thu, 23 Apr 2015 15:15:56 +0200 (CEST) Message-ID: <5538F08A.6010208@pi.nu> Date: Thu, 23 Apr 2015 15:15:54 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , "mpls@ietf.org" References: <5530F834.40002@cs.tcd.ie> <5538BE10.60706@pi.nu> <5538BFF3.8030701@cs.tcd.ie> In-Reply-To: <5538BFF3.8030701@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] would the WG like to adopt draft-farrelll-mpls-opportunistic-encrypt? 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, 23 Apr 2015 13:16:09 -0000 Stephen, On 2015-04-23 11:48, Stephen Farrell wrote: > > Hiya, > > On 23/04/15 10:40, Loa Andersson wrote: >> Working Group, >> >> >> >> I've read the draft (a while ago) and I think this document is within >> the wg charter and should be progressed by the mpls wg. >> >> (chair hat on> >> >> If I hear nothing to the contrary I will start the process with >> mpls-rt review, IPR poll and wg adoption poll first week of May. > > Thanks Loa. I'm not entirely familiar with the mpls-rt review but > one issue on which I think some detailed requirements-level guidance > would be useful for me is on whether this ought stick with "classic" > integer DH or move to a more modern DH approach based on curve 25519. > If you have reviewers who are familiar with the issues there and > with MPLS performance and implementation requirements that'd be good. > If not, I'm happy to try explain the pros and cons from the security > and crypto POV, either to the reviewers or the list. And that can be > done post-adoption on the list if that's better too, but it'd be a > good thing to bottom out early-ish in the WG process. The MPLS-RT review is there to give advice to the working group chairs whether the document is ready to be adopted as a wg doc (if ot addresses as real problem, if it is likely to be deployed in real networks, etc.) Once I start the MPLS-RT review I'll look to see if I can find a reviewer that can look at the DH issues also. /Loa > >> There has been some comments, but I think those are address. Please >> read and comment on the draft. > > Yes, I think we've addressed the substantive comments we've so > far seen. > > Cheers, > S. > >> >> /Loa >> >> >> >> On 2015-04-17 14:10, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> Adrian and I wrote up [1]. How'd the WG feel about adopting >>> that? If you did, I'd be willing to continue editing if you >>> wanted. So consider this as a request that the WG take on >>> this work. >>> >>> In case it helps, the current abstract is: >>> >>> " >>> This document describes a way to apply opportunistic security >>> between adjacent nodes on an MPLS Label Switched Path (LSP) or >>> between end points of an LSP. It explains how keys may be agreed >>> to enable encryption, and how key identifiers are exchanged in >>> encrypted MPLS packets. Finally, this document describes the >>> applicability of this approach to opportunistic security in MPLS >>> networks with an indication of the level of improved security as >>> well as the continued vulnerabilities. >>> >>> This document does not describe security for MPLS control plane >>> protocols. >>> " >>> >>> Cheers, >>> S. >>> >>> [1] https://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt >>> >>> _______________________________________________ >>> 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 Thu Apr 23 16:39:14 2015 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 070A11AD210 for ; Thu, 23 Apr 2015 16:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 qNqTTIfWCTVO for ; Thu, 23 Apr 2015 16:39:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178911AD255 for ; Thu, 23 Apr 2015 16:39:01 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3NNcq1w032565; Fri, 24 Apr 2015 00:38:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3NNcpKe032559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 00:38:52 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , "'t.petch'" , "'Nobo Akiya'" References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> In-Reply-To: <5538EC97.8050204@pi.nu> Date: Fri, 24 Apr 2015 00:38:51 +0100 Message-ID: <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQPgMp+F85EfvPJp+pmFDDXz24DS/gHDk72sAiR8PsAB8lbRgwI+M4C/AbBgzsoBy3FM4wIy3pA3Avr9XeoBa+ZcUpiqZe6A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21500.003 X-TM-AS-Result: No--41.627-10.0-31-10 X-imss-scan-details: No--41.627-10.0-31-10 X-TMASE-MatchedRID: ZFzIhWOuIzunykMun0J1wki1HC4Ql3bfDdwltGeV/6fadW4iYSMjUeO7 Q9MS0NLnIG8Wr4JNhg+YZfjORODtZc5/oVSv8cmRF6z9HGHKwNucbZkcWKk2Gz6IXkgHUCXLEwa 0+RTIVt2WjpcuRD/SFTSQYSrCJ7rbXDTmt8xVOV+wHK2BMXhNNLtW9LeKKGvbzaa9uKDkuMYJZG cq/WSdVtVMzXM9MuwmUs5bQdtg/bD5V22kT3/19gPZZctd3P4BIaLR+2xKRDLKP6Yywb5aNvRPd GKxu2/j4h0viJqnuw5EUB/N/amzHi9FtW7XfHueaUe/i9AephNu/Xr6CKXiN0FN16jLRH0PjtUg dn+AaGyqCRTto1npm4cY/nPSj3kwgFWhWut0cL2rVklnbP5JtiTa6AWhmfi1h8BhJvgqWBnueTc fwiDWZ/WUn3Uo2N77ZuQeg8xzhmDyvcecKfVZZtcjCbPZgQnFlnrMq7Sriu34JyR+b5tvoMOpfM ZV+vayRnUgijdt6WSjT363D9PEXmFqPXSLpNdAQr2qXCJMSV91k+gP1XamtJsoi2XrUn/JyeMtM D9QOgCk8oKXKhRLPI2j49Ftap9EkGUtrowrXLg= Archived-At: Cc: 'Ross Callon' , 'mpls' , mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 23:39:12 -0000 Thanks Loa, You captured it. The edge cases need to be nailed down. Personally I have no particular preference for where it is nailed, but I don't want it flapping in the breeze. A > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 23 April 2015 13:59 > To: t.petch; Nobo Akiya > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-reply- > mode-simple@tools.ietf.org > Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: working group > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > Tom, > > The question you and Adrian asks is what to do if the Reply Mode > Order TLV is missing. > > There is something fishy here, I'd like George to look at this. > > The LSP Ping design says that TLVs from this range may be silentsly > dropped, my take is that we don't need to specify anything more > than that. > > Now, we say that it MUST be present, and after thinking around a bit > I wonder if the TLV should be assigned from the mandatory range instead? > > Or if the MUST be present means that the message will be malformed if > it is not there, and the message should be discarded. > > OK - now I'm confused. > > /Loa > > On 2015-04-23 13:02, t.petch wrote: > > ---- Original Message ----- > > From: "Loa Andersson" > > Sent: Wednesday, April 22, 2015 2:15 PM > > > >> Tom, > >> > >> On 2015-04-20 00:07, Nobo Akiya wrote: > >>> > >>> > >>> Yes but ... I think that it is a change of meaning. Is is > > enough just > >>> to ignore the TLV or should the whole PDU be discarded? I find > > it > >>> difficult to know but don't feel strongly about that choice so > > will go > >>> with what you suggest. > >>> > >>> > >> > >> So I don't misunderstand what you are saying. It seems to me like the > >> comments made by Adrian and you actually requires a "change of > > meaning", > >> that is kind of essence of a "comment", right? > >> > >> As for what to do with if the TLV is not recognized, it is > >> intentionally requested from a space where it can be silently dropped > >> (i.e. "ignored"). > >> > >> The new TLV Type value should be assigned from the range > >> (32768-49161) specified in [RFC4379] section 3 that allows the TLV > >> type to be silently dropped if not recognized. > >> > >> Type Meaning Reference > >> ---- ------- --------- > >> TBD1 Reply Mode Order TLV this document > >> > >> What is it that I miss? > > > > Nothing serious. My initial thought was to echo Adrian, that, at least > > in this context, there should be an indication what to do if a MUST or > > SHOULD was violated without just then having a clear sense of what it > > should be instead. > > > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > > more. Adding what to do if that did not happen I was seeing as > > clarification. I then read Nobo as proposing going a bit further saying > > requires (MUST) one or more. Which might lead to boxes taking a > > simplistic approach and always putting in the new TLV with a single > > entry and ignoring the traditional TLV. Not a problem just a change > > from what others might think that they have consented to. > > > > On the question of what to do when the rules are violated, again I did > > not initially think of what the action should be. On reflection, I am > > still unsure. I understand that the Reply Mode Order TLV is optional > > and so can be ignored when not understood; that's fine. But if it is > > understood and can be seen to be defective, should the box with that > > knowledge discard just that TLV and accept the remainder of the message? > > Or should it argue that if this TLV is defective, then likely the rest > > is as well and should be ignored? I am unsure. > > > > If there is scope for a breach of security, or taking a hit in > > performance, then ignore is the right policy. If the requirement is to > > get as much data as possible from a failing network, then use it is the > > right policy. As long as the I-D is clear, I am not too fussed which > > way it goes. I am content with the changes that Nobo has proposed. > > > > Tom Petch > > > >> /Loa > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > -- > > > 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 Fri Apr 24 21:50:00 2015 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 2687F1A000B for ; Fri, 24 Apr 2015 21:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_15=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 y01q_7rCH0Kh for ; Fri, 24 Apr 2015 21:49:55 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06BA1A004A for ; Fri, 24 Apr 2015 21:49:54 -0700 (PDT) Received: by labbd9 with SMTP id bd9so48084837lab.2 for ; Fri, 24 Apr 2015 21:49:53 -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=gCvucJmtc3gcTrkdC5koHbA80atSWCpoK6XbirO0A2k=; b=Tc1Y4s84SLY03TgJxepUwwYjuMOatYhAgB67pKhfqK5OKbRFljtIG/wDBmw/8YpP6N Qf2ui2Nycbec74l/NxFG9jvCjkWEqQ2vdpZ5mTG6CAn77KKAHuZiorIgWLCmsOHJ4SUV buqFaCJKhHMzywUUoo3aQJeaEXYZTUfoNtHGylAWm8Bbf04atT3hexMWRoN0Esjyuqpv j2aRwvr1aNRfocKGykAz/HNORa24u6NsB8fVnF6j756J+7SIbH8DKvHZACqr+Ro6ylLZ 4yzG/iJUOP5OeNZTBCq7DX5CI3k1U0pweuTKzzuOkoTGLLhOwpAZggZqqTDI2nzdlNxx fSxQ== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr1421168laj.48.1429937393331; Fri, 24 Apr 2015 21:49:53 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Fri, 24 Apr 2015 21:49:53 -0700 (PDT) In-Reply-To: <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> Date: Fri, 24 Apr 2015 21:49:53 -0700 Message-ID: From: Nobo Akiya To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=089e0160adf86173b20514853eed Archived-At: Cc: mpls , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 25 Apr 2015 04:49:58 -0000 --089e0160adf86173b20514853eed Content-Type: text/plain; charset=UTF-8 Hi Adrian, Tom, Loa, This extension is currently structured such that it allows for backwards compatibility (i.e., transit LSR not supporting this mechanism will not return "malformed request" ... because the TLV is optional). The result is that this mechanism becomes a best effort mechanism, and we will not get the full benefit until all LSRs along the LSP (and other LSRs which could falsely receive the echo request) implements this extension. One way to allow the initiator LSR to determine whether or not the responder LSR understood this TLV, and still keeping the backwards compatibility, is that we keep the Reply Mode Order TLV as an optional TLV, but require (i.e., MUST) the responder LSR understanding this TLV to include the Reply Mode Order TLV in the echo reply, potentially with result of parsing/handling that TLV. However, that's probably not the path we want to go, as all (or most) optional TLVs will have to do something similar (i.e., include the same TLV in the echo reply). This will quickly result in echo reply packet bloat ... we should prevent that as echo reply usually tends to include more information (ILS, DSMAP/DDMAP per nexthop, multipath Sub-TLVs per nexthop, etc). To me, the right way to solve this is to create a capability TLV that mandates the reponder LSR to return which features it supports in bitmaps or something very compact. But this can be done in a separate effort/draft. In short, my preference for this document is to go as is (after incorporating comments from Tom). Thanks! -Nobo On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel wrote: > Thanks Loa, > > You captured it. The edge cases need to be nailed down. > > Personally I have no particular preference for where it is nailed, but I > don't > want it flapping in the breeze. > > A > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: 23 April 2015 13:59 > > To: t.petch; Nobo Akiya > > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org; > draft-ietf-mpls-lsp-ping-reply- > > mode-simple@tools.ietf.org > > Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: working > group > > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Tom, > > > > The question you and Adrian asks is what to do if the Reply Mode > > Order TLV is missing. > > > > There is something fishy here, I'd like George to look at this. > > > > The LSP Ping design says that TLVs from this range may be silentsly > > dropped, my take is that we don't need to specify anything more > > than that. > > > > Now, we say that it MUST be present, and after thinking around a bit > > I wonder if the TLV should be assigned from the mandatory range instead? > > > > Or if the MUST be present means that the message will be malformed if > > it is not there, and the message should be discarded. > > > > OK - now I'm confused. > > > > /Loa > > > > On 2015-04-23 13:02, t.petch wrote: > > > ---- Original Message ----- > > > From: "Loa Andersson" > > > Sent: Wednesday, April 22, 2015 2:15 PM > > > > > >> Tom, > > >> > > >> On 2015-04-20 00:07, Nobo Akiya wrote: > > >>> > > >>> > > >>> Yes but ... I think that it is a change of meaning. Is is > > > enough just > > >>> to ignore the TLV or should the whole PDU be discarded? I find > > > it > > >>> difficult to know but don't feel strongly about that choice so > > > will go > > >>> with what you suggest. > > >>> > > >>> > > >> > > >> So I don't misunderstand what you are saying. It seems to me like the > > >> comments made by Adrian and you actually requires a "change of > > > meaning", > > >> that is kind of essence of a "comment", right? > > >> > > >> As for what to do with if the TLV is not recognized, it is > > >> intentionally requested from a space where it can be silently dropped > > >> (i.e. "ignored"). > > >> > > >> The new TLV Type value should be assigned from the range > > >> (32768-49161) specified in [RFC4379] section 3 that allows the > TLV > > >> type to be silently dropped if not recognized. > > >> > > >> Type Meaning Reference > > >> ---- ------- --------- > > >> TBD1 Reply Mode Order TLV this document > > >> > > >> What is it that I miss? > > > > > > Nothing serious. My initial thought was to echo Adrian, that, at least > > > in this context, there should be an indication what to do if a MUST or > > > SHOULD was violated without just then having a clear sense of what it > > > should be instead. > > > > > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > > > more. Adding what to do if that did not happen I was seeing as > > > clarification. I then read Nobo as proposing going a bit further > saying > > > requires (MUST) one or more. Which might lead to boxes taking a > > > simplistic approach and always putting in the new TLV with a single > > > entry and ignoring the traditional TLV. Not a problem just a change > > > from what others might think that they have consented to. > > > > > > On the question of what to do when the rules are violated, again I did > > > not initially think of what the action should be. On reflection, I am > > > still unsure. I understand that the Reply Mode Order TLV is optional > > > and so can be ignored when not understood; that's fine. But if it is > > > understood and can be seen to be defective, should the box with that > > > knowledge discard just that TLV and accept the remainder of the > message? > > > Or should it argue that if this TLV is defective, then likely the rest > > > is as well and should be ignored? I am unsure. > > > > > > If there is scope for a breach of security, or taking a hit in > > > performance, then ignore is the right policy. If the requirement is to > > > get as much data as possible from a failing network, then use it is the > > > right policy. As long as the I-D is clear, I am not too fussed which > > > way it goes. I am content with the changes that Nobo has proposed. > > > > > > Tom Petch > > > > > >> /Loa > > >> > > >> -- > > >> > > >> > > >> Loa Andersson email: loa@mail01.huawei.com > > >> Senior MPLS Expert loa@pi.nu > > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > -- > > > > > > 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 > > --089e0160adf86173b20514853eed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian, Tom, Loa,

This ex= tension is currently structured such that=C2=A0it allows for backwards comp= atibility (i.e., transit LSR not supporting this mechanism will not return = "malformed request" ... because the TLV is optional).
<= br>
The result is that this mechanism becomes a best effort mecha= nism, and we will not get the full benefit until all LSRs along the LSP (an= d other LSRs which could falsely receive the echo request) implements this = extension.

One way to allow the initiator LSR to d= etermine whether or not the responder LSR understood this TLV, and still ke= eping the backwards compatibility,=C2=A0is that we keep the Reply Mode Orde= r TLV as an optional TLV, but require (i.e., MUST) the responder LSR unders= tanding this TLV to include the Reply Mode Order TLV in the echo reply, pot= entially with result of parsing/handling that TLV.

However, that's probably not the path we want to go, as all (or most) = optional TLVs will have to do something similar (i.e., include the same TLV= in the echo reply). This will quickly result in echo reply packet bloat ..= . we should prevent that as echo reply usually tends to include more inform= ation (ILS, DSMAP/DDMAP per nexthop, multipath Sub-TLVs per nexthop, etc).<= /div>

To me, the right way to solve this is to create a = capability TLV that mandates the reponder LSR to return which features it s= upports in bitmaps or something very compact. But this can be done in a sep= arate effort/draft.

In short, my preference for th= is document is to go as is (after incorporating comments from Tom).

Thanks!

-Nobo

On Thu, Apr 23, 2015= at 4:38 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Thanks Loa,

You captured it. The edge cases need to be nailed down.

Personally I have no particular preference for where it is nailed, but I do= n't
want it flapping in the breeze.

A

> -----Original Message-----
> From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Loa Andersson
> Sent: 23 April 2015 13:59
> To: t.petch; Nobo Akiya
> Cc: Ross Callon; mpls; m= pls-chairs@tools.ietf.org;
draft-ietf-mpls-lsp-ping-reply-
> mode-simple@tools.ietf.o= rg
> Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: work= ing
group
> last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01
>
> Tom,
>
> The question you and Adrian asks is what to do if the Reply Mode
> Order TLV is missing.
>
> There is something fishy here, I'd like George to look at this. >
> The LSP Ping design says that TLVs from this range may be silentsly > dropped, my take is that we don't need to specify anything more > than that.
>
> Now, we say that it MUST be present, and after thinking around a bit > I wonder if the TLV should be assigned from the mandatory range instea= d?
>
> Or if the MUST be present means that the message will be malformed if<= br> > it is not there, and the message should be discarded.
>
> OK - now I'm confused.
>
> /Loa
>
> On 2015-04-23 13:02, t.petch wrote:
> > ---- Original Message -----
> > From: "Loa Andersson" <= loa@pi.nu>
> > Sent: Wednesday, April 22, 2015 2:15 PM
> >
> >> Tom,
> >>
> >> On 2015-04-20 00:07, Nobo Akiya wrote:
> >>>=C2=A0 =C2=A0 =C2=A0 <tp>
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 Yes but ... I think that it is a chan= ge of meaning.=C2=A0 Is is
> > enough just
> >>>=C2=A0 =C2=A0 =C2=A0 to ignore the TLV or should the whole= PDU be discarded?=C2=A0 I find
> > it
> >>>=C2=A0 =C2=A0 =C2=A0 difficult to know but don't feel = strongly about that choice so
> > will go
> >>>=C2=A0 =C2=A0 =C2=A0 with what you suggest.
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 </tp>
> >>
> >> So I don't misunderstand what you are saying. It seems to= me like the
> >> comments made by Adrian and you actually requires a "cha= nge of
> > meaning",
> >> that is kind of essence of a "comment", right?
> >>
> >> As for what to do with if the TLV is not recognized, it is > >> intentionally requested from a space where it can be silently= dropped
> >> (i.e. "ignored").
> >>
> >>=C2=A0 =C2=A0 =C2=A0 The new TLV Type value should be assigned= from the range
> >>=C2=A0 =C2=A0 =C2=A0 (32768-49161) specified in [RFC4379] sect= ion 3 that allows the TLV
> >>=C2=A0 =C2=A0 =C2=A0 type to be silently dropped if not recogn= ized.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Type=C2=A0 =C2=A0Meaning=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 Reference
> >>=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 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ---------
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 TBD1=C2=A0 =C2=A0Reply Mode Order = TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this document
> >>
> >> What is it that I miss?
> >
> > Nothing serious.=C2=A0 My initial thought was to echo Adrian, tha= t, at least
> > in this context, there should be an indication what to do if a MU= ST or
> > SHOULD was violated without just then having a clear sense of wha= t it
> > should be instead.
> >
> > The I-D did require (MUST) one entry in the TLV and wanted (SHOUL= D)
> > more.=C2=A0 Adding what to do if that did not happen I was seeing= as
> > clarification.=C2=A0 I then read Nobo as proposing going a bit fu= rther saying
> > requires (MUST) one or more.=C2=A0 Which might lead to boxes taki= ng a
> > simplistic approach and always putting in the new TLV with a sing= le
> > entry and ignoring the traditional TLV.=C2=A0 Not a problem just = a change
> > from what others might think that they have consented to.
> >
> > On the question of what to do when the rules are violated, again = I did
> > not initially think of what the action should be.=C2=A0 On reflec= tion, I am
> > still unsure.=C2=A0 I understand that the Reply Mode Order TLV=C2= =A0 is optional
> > and so can be ignored when not understood; that's fine.=C2=A0= But if it is
> > understood and can be seen to be defective, should the box with t= hat
> > knowledge discard just that TLV and accept the remainder of the m= essage?
> > Or should it argue that if this TLV is defective, then likely the= rest
> > is as well and should be ignored?=C2=A0 I am unsure.
> >
> > If there is scope for a breach of security, or taking a hit in > > performance, then ignore is the right policy. If the requirement = is to
> > get as much data as possible from a failing network, then use it = is the
> > right policy.=C2=A0 As long as the I-D is clear, I am not too fus= sed which
> > way it goes.=C2=A0 I am content with the changes that Nobo has pr= oposed.
> >
> > Tom Petch
> >
> >> /Loa
> >>
> >> --
> >>
> >>
> >> 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=A0 email: 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=A0 loa@pi.nu
> >> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 = 21 64
> >
>
> --
>
>
> 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=A0 email: 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=A0 loa@pi.= nu
> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


--089e0160adf86173b20514853eed-- From nobody Sat Apr 25 03:27:29 2015 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 1F8BC1A70E1 for ; Sat, 25 Apr 2015 03:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 aLnJ7kDJw35B for ; Sat, 25 Apr 2015 03:27:25 -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 A036A1A7021 for ; Sat, 25 Apr 2015 03:27:25 -0700 (PDT) Received: from [10.33.12.39] (c-400770d5.45-1-64736c10.cust.bredbandsbolaget.se [213.112.7.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 7E858180145E for ; Sat, 25 Apr 2015 12:27:23 +0200 (CEST) Message-ID: <553B6C0A.4080706@pi.nu> Date: Sat, 25 Apr 2015 12:27:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <55394DD0.1050109@labn.net> In-Reply-To: <55394DD0.1050109@labn.net> X-Forwarded-Message-Id: <55394DD0.1050109@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Fwd: [Teas] New Wiki: Some informal guidance for standards track protocol specifications 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, 25 Apr 2015 10:27:28 -0000 Working Group, This appears to be a very useful wiki, if you are in the process of writing a draft please look at it. /Loa mpls wg co-chair -------- Forwarded Message -------- Subject: [Teas] New Wiki: Some informal guidance for standards track protocol specifications Date: Thu, 23 Apr 2015 15:53:52 -0400 From: Lou Berger To: TEAS WG All, I thought it might be useful to document some topics that repeatedly get discussed during document reviews. I started an "informal" wiki on the topic. It is located at http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines . Please take a look at, comment/modify as you see fit. As chair, I ask that all WG authors review this guidance in anticipation of comment topics you're likely to see before/during WG LC. Thanks, Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Sat Apr 25 09:17:57 2015 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 A8B341A89BB for ; Sat, 25 Apr 2015 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 mJV5Y2xAAQrT for ; Sat, 25 Apr 2015 09:17:51 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28EE1A8998 for ; Sat, 25 Apr 2015 09:17:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3PGHk2F032567; Sat, 25 Apr 2015 17:17:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3PGHirF032544 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 25 Apr 2015 17:17:45 +0100 From: "Adrian Farrel" To: "'Nobo Akiya'" References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> In-Reply-To: Date: Sat, 25 Apr 2015 17:17:43 +0100 Message-ID: <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01D07F7B.BE96C040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQPgMp+F85EfvPJp+pmFDDXz24DS/gHDk72sAiR8PsAB8lbRgwI+M4C/AbBgzsoBy3FM4wIy3pA3Avr9XeoBa+ZcUgJAy7jfAwGha6OYgvUKsA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21504.001 X-TM-AS-Result: No--50.067-10.0-31-10 X-imss-scan-details: No--50.067-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFrWoi+XHWon+PT+KclxuHvfC/ExpXrHizyrzPs85fwUk9Ev k7xjlIKiHRMPIwK2jF8uFh/dlvL8Y0hz7X71rimzyKTEsCRIdyXRahuPwaQ1WrrfxlRjqBJ3YXC agLTSWEgESz5E/KsaGTOhQ0C0WOxy/csI8LvNTh5CnGIuUMP0VSPclXBzQ1O2RancUUfiVbjKYq rHyR0jK32VMDa97gjg4CfdMQz5dC9fk8ZX+zIo8cNrWpY804TGviRliDV2nywZ4vA+WJA5l0aQE MtcnqMIH9NHCwoYsb0YugfIlA6Ib38b147nSU7Wk3ewifG2MNNB+8LAeeOOMN14Aqe8EzF8aWb+ H6zFWThuuBQngKeoeKoSMdHwVfcFkBulMq39Dyj2Ii0VSfdeQ7tq3FNsoMQgC13My87/LbQy5PB tqoQlk0C4ZMe/DiRRUhabRrhnHIygddUZJmqh3obBPrt55wnwvQOhxZnSGuFX14Hy+eYp79Fc6x qZVtGPTs49mYvM8bQQbi0n2beMrA7AfikPXgOwSLUcLhCXdt9R3sGN+j7mNHaIualmA7qVU8pDi DQQ0FPwOGawsB401abF+zkwZnVPDD8u5q9hbJhWgOVCl/hN1bSIuYdn4LPsw62uSG5kL1ZB+3z+ jGoJX7XalXqfrxweB9VrRw1/5wRYWIOyy+I0L7iMC5wdwKqdknjBMY7iKBLSauv9hRXQJJ2uxZk juzqv5iOY/O9iNZEqU8hdO034F9l+dy3lQHNxQ1OcCEvT+bfTBg/CbgV2T2sxtqQk3w55MqCUTV mFLuARwZrwJu2pACSE5ZCidiJk7nVkzMb2RnKeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKrF5UpO UNpcCumhPWBpBAYkGUtrowrXLg= Archived-At: Cc: 'mpls' , draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org, 'Ross Callon' , mpls-chairs@tools.ietf.org Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 16:17:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0089_01D07F7B.BE96C040 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nobo, =20 Let's come back to my original review comments. =20 > Section 3.2 gives clear instructions and guidance on forming the Reply > Mode Order TLV but not on what to do if a received TLV deviates from = the > MUST and MUST NOT instructions. Options might include ignoring errors, > ignoring the TLV, ignoring the message. But presumably not sending an > error response (because how would you know how to send it?) =20 You responded: =20 | [NOBO] That=E2=80=99s a good point. What the document really state is = that The | Reply Mode value 5 (Reply via Specified Path) MAY be repeated but all=20 | other Reply Mode values MUST NOT be repeated. Will update the | document to make it clear. =20 That's a fine thing to say, but doesn't answer my question about how an = implementation is supposed to behave when a received Reply Mode Order = TLV is "malformed". =20 You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. Section 3.2 = swapped the order of points 4 and 5, and enhanced the text to read... =20 4. If a responder LSR understands the Reply Mode Order TLV but the TLV is not valid (due to conditions described in the items 6, 8 and 9 immediately below), then the responder LSR MUST only use the value described in the Reply Mode field of received MPLS echo request. =20 That seems to cover most bases. Good. It might also be helpful to say "...the responder LSR MUST silently = ignore the whole Reply Mode Order TLV and MUST only use the value from = the Reply Mode field of the received MPLS echo request." Saying this helps clarify the behavior. =20 The only things I don't find covered are: =20 a. how to handle a violation of the seventh point =20 7. A Reply Mode value, except for Reply Mode value 5 (Reply via Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV. =20 I think you can address this by adding "7" to the list of conditions = in point 4. =20 b. how to handle a violation of the second point =20 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. =20 I think this will need additional text. =20 I note that after the numbered bullets you also now have the following = text... =20 If a responder LSR receives a Reply Mode Order TLV which does not comply to the rules described above, then the responder LSR MUST ignore the Reply Mode Order TLV. =20 This is better than point 4 and covers everything. You might consider whether "ignore" means "silently ignore" or whether = you want to give advice about logging. It seems probable that (because = of the nature of ping) if you do suggest logging, you also want to = describe some form of thresholding or damping. =20 =20 To address Loa's concern... The TLV is from the optional range. It can be ignored if it is not = understood, and does not require to be included. Loa asserted that the document says that the TLV MUST be included, but I = don't find this in -02. Therefore, I think this is all fine. =20 Adrian =20 From: Nobo Akiya [mailto:nobo.akiya.dev@gmail.com]=20 Sent: 25 April 2015 05:50 To: adrian@olddog.co.uk Cc: Loa Andersson; t.petch; Ross Callon; mpls; = mpls-chairs@tools.ietf.org; = draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: = working group last call for = draft-ietf-mpls-lsp-ping-reply-mode-simple-01 =20 Hi Adrian, Tom, Loa, =20 This extension is currently structured such that it allows for backwards = compatibility (i.e., transit LSR not supporting this mechanism will not = return "malformed request" ... because the TLV is optional). =20 The result is that this mechanism becomes a best effort mechanism, and = we will not get the full benefit until all LSRs along the LSP (and other = LSRs which could falsely receive the echo request) implements this = extension. =20 One way to allow the initiator LSR to determine whether or not the = responder LSR understood this TLV, and still keeping the backwards = compatibility, is that we keep the Reply Mode Order TLV as an optional = TLV, but require (i.e., MUST) the responder LSR understanding this TLV = to include the Reply Mode Order TLV in the echo reply, potentially with = result of parsing/handling that TLV. =20 However, that's probably not the path we want to go, as all (or most) = optional TLVs will have to do something similar (i.e., include the same = TLV in the echo reply). This will quickly result in echo reply packet = bloat ... we should prevent that as echo reply usually tends to include = more information (ILS, DSMAP/DDMAP per nexthop, multipath Sub-TLVs per = nexthop, etc). =20 To me, the right way to solve this is to create a capability TLV that = mandates the reponder LSR to return which features it supports in = bitmaps or something very compact. But this can be done in a separate = effort/draft. =20 In short, my preference for this document is to go as is (after = incorporating comments from Tom). =20 Thanks! =20 -Nobo =20 On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel = wrote: Thanks Loa, You captured it. The edge cases need to be nailed down. Personally I have no particular preference for where it is nailed, but I = don't want it flapping in the breeze. A > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 23 April 2015 13:59 > To: t.petch; Nobo Akiya > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp-ping-reply- > mode-simple@tools.ietf.org > Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: = working group > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > Tom, > > The question you and Adrian asks is what to do if the Reply Mode > Order TLV is missing. > > There is something fishy here, I'd like George to look at this. > > The LSP Ping design says that TLVs from this range may be silentsly > dropped, my take is that we don't need to specify anything more > than that. > > Now, we say that it MUST be present, and after thinking around a bit > I wonder if the TLV should be assigned from the mandatory range = instead? > > Or if the MUST be present means that the message will be malformed if > it is not there, and the message should be discarded. > > OK - now I'm confused. > > /Loa > > On 2015-04-23 13:02, t.petch wrote: > > ---- Original Message ----- > > From: "Loa Andersson" > > Sent: Wednesday, April 22, 2015 2:15 PM > > > >> Tom, > >> > >> On 2015-04-20 00:07, Nobo Akiya wrote: > >>> > >>> > >>> Yes but ... I think that it is a change of meaning. Is is > > enough just > >>> to ignore the TLV or should the whole PDU be discarded? I = find > > it > >>> difficult to know but don't feel strongly about that choice = so > > will go > >>> with what you suggest. > >>> > >>> > >> > >> So I don't misunderstand what you are saying. It seems to me like = the > >> comments made by Adrian and you actually requires a "change of > > meaning", > >> that is kind of essence of a "comment", right? > >> > >> As for what to do with if the TLV is not recognized, it is > >> intentionally requested from a space where it can be silently = dropped > >> (i.e. "ignored"). > >> > >> The new TLV Type value should be assigned from the range > >> (32768-49161) specified in [RFC4379] section 3 that allows the = TLV > >> type to be silently dropped if not recognized. > >> > >> Type Meaning Reference > >> ---- ------- --------- > >> TBD1 Reply Mode Order TLV this document > >> > >> What is it that I miss? > > > > Nothing serious. My initial thought was to echo Adrian, that, at = least > > in this context, there should be an indication what to do if a MUST = or > > SHOULD was violated without just then having a clear sense of what = it > > should be instead. > > > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > > more. Adding what to do if that did not happen I was seeing as > > clarification. I then read Nobo as proposing going a bit further = saying > > requires (MUST) one or more. Which might lead to boxes taking a > > simplistic approach and always putting in the new TLV with a single > > entry and ignoring the traditional TLV. Not a problem just a change > > from what others might think that they have consented to. > > > > On the question of what to do when the rules are violated, again I = did > > not initially think of what the action should be. On reflection, I = am > > still unsure. I understand that the Reply Mode Order TLV is = optional > > and so can be ignored when not understood; that's fine. But if it = is > > understood and can be seen to be defective, should the box with that > > knowledge discard just that TLV and accept the remainder of the = message? > > Or should it argue that if this TLV is defective, then likely the = rest > > is as well and should be ignored? I am unsure. > > > > If there is scope for a breach of security, or taking a hit in > > performance, then ignore is the right policy. If the requirement is = to > > get as much data as possible from a failing network, then use it is = the > > right policy. As long as the I-D is clear, I am not too fussed = which > > way it goes. I am content with the changes that Nobo has proposed. > > > > Tom Petch > > > >> /Loa > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 = =20 > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 = =20 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls =20 ------=_NextPart_000_0089_01D07F7B.BE96C040 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Nobo,

 

Let's come back to my original = review comments.

 

> Section 3.2 gives clear = instructions and guidance on forming the Reply

> Mode Order TLV but not on = what to do if a received TLV deviates from the

> MUST and MUST NOT = instructions. Options might include ignoring = errors,

> ignoring the TLV, = ignoring the message. But presumably not sending = an

> error response (because = how would you know how to send it?)

 

You = responded:

 

| [NOBO] That=E2=80=99s a good = point. What the document really state is that = The

| Reply Mode value 5 (Reply = via Specified Path) MAY be repeated but all

| other Reply Mode values MUST = NOT be repeated. Will update the

| document to make it = clear.

 

That's a fine thing to say, = but doesn't answer my question about how an implementation is supposed = to behave when a received Reply Mode Order TLV is = "malformed".

 

You posted = draft-ietf-mpls-lsp-ping-reply-mode-simple-02. Section 3.2 swapped the = order of points 4 and 5, and enhanced the text to = read...

 

=C2=A0=C2=A0 4.=C2=A0 If a responder LSR understands = the Reply Mode Order TLV but the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = TLV is not valid (due to conditions described in the items 6, = 8

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = and 9 immediately below), then the responder LSR MUST only = use

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = the value described in the Reply Mode field of received MPLS = echo

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = request.

 

That seems to cover most = bases. Good.

It might also be helpful to = say "...the responder LSR MUST silently ignore the whole Reply Mode = Order TLV and MUST only use the value from the Reply Mode field of the = received MPLS echo request."

Saying this helps clarify the = behavior.

 

The only things I don't find = covered are:

 

a. how to handle a violation = of the seventh point

 

=C2=A0=C2=A0 7.=C2=A0 A Reply Mode value, except for = Reply Mode value 5 (Reply via

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Specified Path), MUST NOT be repeated (i.e., MUST NOT = appear

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = multiple times) in the Reply Mode Order = TLV.

 

=C2=A0=C2=A0 I think you can address = this by adding "7" to the list of conditions in point = 4.

 

b. how to handle a violation = of the second point

 

=C2=A0=C2=A0 2. The Reply Mode Order = TLV MUST NOT be included in MPLS echo reply.

 

=C2=A0=C2=A0 I think this will need = additional text.

 

I note that after the numbered = bullets you also now have the following text...

 

=C2=A0=C2=A0 If a responder LSR = receives a Reply Mode Order TLV which does not

=C2=A0=C2=A0 comply to the rules = described above, then the responder LSR MUST

=C2=A0=C2=A0 ignore the Reply Mode = Order TLV.

 

This is better than point 4 = and covers everything.

You might consider whether = "ignore" means "silently ignore" or whether you want = to give advice about logging. It seems probable that (because of the = nature of ping) if you do suggest logging, you also want to describe = some form of thresholding or damping.

 

 

To address Loa's = concern...

The TLV is from the optional = range. It can be ignored if it is not understood, and does not require = to be included.

Loa asserted that the document = says that the TLV MUST be included, but I don't find this in = -02.

Therefore, I think this is all = fine.

 

Adrian

 

From: Nobo Akiya = [mailto:nobo.akiya.dev@gmail.com]
Sent: 25 April 2015 = 05:50
To: adrian@olddog.co.uk
Cc: Loa Andersson; = t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org
Subject:<= /b> Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working = group last call for = draft-ietf-mpls-lsp-ping-reply-mode-simple-01

=

 

Hi Adrian, Tom, Loa,

 

This extension is currently structured such = that it allows for backwards compatibility (i.e., transit LSR not = supporting this mechanism will not return "malformed request" = ... because the TLV is optional).

 

The result is that this mechanism becomes a best = effort mechanism, and we will not get the full benefit until all LSRs = along the LSP (and other LSRs which could falsely receive the echo = request) implements this extension.

 

One way to allow the initiator LSR to determine = whether or not the responder LSR understood this TLV, and still keeping = the backwards compatibility, is that we keep the Reply Mode Order = TLV as an optional TLV, but require (i.e., MUST) the responder LSR = understanding this TLV to include the Reply Mode Order TLV in the echo = reply, potentially with result of parsing/handling that = TLV.

 

However, that's probably not the path we want to go, = as all (or most) optional TLVs will have to do something similar (i.e., = include the same TLV in the echo reply). This will quickly result in = echo reply packet bloat ... we should prevent that as echo reply usually = tends to include more information (ILS, DSMAP/DDMAP per nexthop, = multipath Sub-TLVs per nexthop, etc).

 

To me, the right way to solve this is to create a = capability TLV that mandates the reponder LSR to return which features = it supports in bitmaps or something very compact. But this can be done = in a separate effort/draft.

 

In short, my preference for this document is to go as = is (after incorporating comments from Tom).

 

Thanks!

 

-Nobo

 

On Thu, = Apr 23, 2015 at 4:38 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Thanks Loa,

You = captured it. The edge cases need to be nailed down.

Personally I = have no particular preference for where it is nailed, but I = don't
want it flapping in the breeze.

A

> = -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On = Behalf Of Loa Andersson
> Sent: 23 April 2015 13:59
> To: = t.petch; Nobo Akiya
> Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org= ;
draft-ietf-mpls-lsp-ping-reply-
> mode-simple@tools.ietf.org=
> Subject: [mpls] George can yu look at this - Re: end of WGLC, = RE: working
group
> last call for = draft-ietf-mpls-lsp-ping-reply-mode-simple-01
>
> = Tom,
>
> The question you and Adrian asks is what to do if = the Reply Mode
> Order TLV is missing.
>
> There is = something fishy here, I'd like George to look at this.
>
> = The LSP Ping design says that TLVs from this range may be = silentsly
> dropped, my take is that we don't need to specify = anything more
> than that.
>
> Now, we say that it = MUST be present, and after thinking around a bit
> I wonder if the = TLV should be assigned from the mandatory range instead?
>
> = Or if the MUST be present means that the message will be malformed = if
> it is not there, and the message should be = discarded.
>
> OK - now I'm confused.
>
> = /Loa
>
> On 2015-04-23 13:02, t.petch wrote:
> > = ---- Original Message -----
> > From: "Loa Andersson" = <loa@pi.nu>
> > Sent: = Wednesday, April 22, 2015 2:15 PM
> >
> >> = Tom,
> >>
> >> On 2015-04-20 00:07, Nobo Akiya = wrote:
> >>>      <tp>
> = >>>
> >>>      Yes but ... I = think that it is a change of meaning.  Is is
> > enough = just
> >>>      to ignore the TLV or = should the whole PDU be discarded?  I find
> > it
> = >>>      difficult to know but don't feel = strongly about that choice so
> > will go
> = >>>      with what you suggest.
> = >>>
> >>>      = </tp>
> >>
> >> So I don't misunderstand = what you are saying. It seems to me like the
> >> comments = made by Adrian and you actually requires a "change of
> > = meaning",
> >> that is kind of essence of a = "comment", right?
> >>
> >> As for = what to do with if the TLV is not recognized, it is
> >> = intentionally requested from a space where it can be silently = dropped
> >> (i.e. "ignored").
> = >>
> >>      The new TLV Type value = should be assigned from the range
> >>      = (32768-49161) specified in [RFC4379] section 3 that allows the = TLV
> >>      type to be silently dropped if = not recognized.
> >>
> >>      =   Type   Meaning            =                 = Reference
> >>        ----  =  -------                =             ---------
> = >>        TBD1   Reply Mode Order = TLV               this = document
> >>
> >> What is it that I = miss?
> >
> > Nothing serious.  My initial = thought was to echo Adrian, that, at least
> > in this context, = there should be an indication what to do if a MUST or
> > = SHOULD was violated without just then having a clear sense of what = it
> > should be instead.
> >
> > The I-D did = require (MUST) one entry in the TLV and wanted (SHOULD)
> > = more.  Adding what to do if that did not happen I was seeing = as
> > clarification.  I then read Nobo as proposing going = a bit further saying
> > requires (MUST) one or more.  = Which might lead to boxes taking a
> > simplistic approach and = always putting in the new TLV with a single
> > entry and = ignoring the traditional TLV.  Not a problem just a change
> = > from what others might think that they have consented to.
> = >
> > On the question of what to do when the rules are = violated, again I did
> > not initially think of what the = action should be.  On reflection, I am
> > still = unsure.  I understand that the Reply Mode Order TLV  is = optional
> > and so can be ignored when not understood; that's = fine.  But if it is
> > understood and can be seen to be = defective, should the box with that
> > knowledge discard just = that TLV and accept the remainder of the message?
> > Or should = it argue that if this TLV is defective, then likely the rest
> = > is as well and should be ignored?  I am unsure.
> = >
> > If there is scope for a breach of security, or taking = a hit in
> > performance, then ignore is the right policy. If = the requirement is to
> > get as much data as possible from a = failing network, then use it is the
> > right policy.  As = long as the I-D is clear, I am not too fussed which
> > way it = goes.  I am content with the changes that Nobo has = proposed.
> >
> > Tom Petch
> >
> = >> /Loa
> >>
> >> --
> = >>
> >>
> >> Loa Andersson    =                     = email: loa@mail01.huawei.com
> = >> Senior MPLS Expert            =               loa@pi.nu
> >> Huawei = Technologies (consultant)     phone: +46 739 81 21 64
> = >
>
> --
>
>
> 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

 

------=_NextPart_000_0089_01D07F7B.BE96C040-- From nobody Sat Apr 25 16:34:00 2015 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 346CB1B327E; Sat, 25 Apr 2015 16:33:57 -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 olZcovcrI2xM; Sat, 25 Apr 2015 16:33:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 030751B29A5; Sat, 25 Apr 2015 16:33:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150425233356.17482.55947.idtracker@ietfa.amsl.com> Date: Sat, 25 Apr 2015 16:33:56 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kumarkini-mpls-spring-lsp-ping-03.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: Sat, 25 Apr 2015 23:33:57 -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) Ping/Trace for Segment Routing Networks Using MPLS Dataplane Authors : Nagendra Kumar George Swallow Carlos Pignataro Nobo Akiya Sriganesh Kini Hannes Gredler Mach(Guoyi) Chen Filename : draft-kumarkini-mpls-spring-lsp-ping-03.txt Pages : 15 Date : 2015-04-25 Abstract: Segment Routing architecture leverages the source routing and tunneling paradigms and can be directly applied to MPLS data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with Segment Routing header. The segment assignment and forwarding semantic nature of Segment Routing raises additional consideration for connectivity verification and fault isolation in LSP with Segment Routing architecture. This document illustrates the problem and describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kumarkini-mpls-spring-lsp-ping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kumarkini-mpls-spring-lsp-ping-03 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 Sun Apr 26 18:36:30 2015 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 AF5FE1B2D1C for ; Sun, 26 Apr 2015 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 ZDysKVpQW13a for ; Sun, 26 Apr 2015 18:36:24 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811D21B2D1A for ; Sun, 26 Apr 2015 18:36:23 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so71261470lbb.3 for ; Sun, 26 Apr 2015 18:36:22 -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=7UFqCCC6EwV+8nl2RFPMZ+4CwhRLggbptre8Q6Co1mI=; b=X5Eq/rNaNdqt+RMLqb8H2EU/bfPLFcjGX/WGy3+HcCeCJIg9rLDS3B9EHuuxuvO56D yb5NEonLnYhghiT7CCNT9YptU5dclB/QrXbEFVYTGOP8XE7ak55c44W0GuAzBwCcLNSl KY3OlfrVQpiWM1VgtJ/xP9hhAX7ZL+eO8er7bZERdCfCKGiTfO9HhmLFRFhEFt+2RMpn Q4iBJuEq/ibcbR9v0pXSXR6yTc0JNuwBGcm4gfLO89oD5F9JeU20/vHLSXgpg+XaxLm1 WbQVylARjrZ9EZIfGfVB3TDYfd+oA9+T7a0CpCMFKr6XmFIgp3E8dALEo0htvZ9ZLhZM iDtA== MIME-Version: 1.0 X-Received: by 10.152.45.34 with SMTP id j2mr7702911lam.99.1430098581963; Sun, 26 Apr 2015 18:36:21 -0700 (PDT) Received: by 10.112.154.168 with HTTP; Sun, 26 Apr 2015 18:36:21 -0700 (PDT) In-Reply-To: <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> Date: Sun, 26 Apr 2015 18:36:21 -0700 Message-ID: From: Nobo Akiya To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a11c2796cf8c8ee0514aac525 Archived-At: Cc: mpls , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 27 Apr 2015 01:36:28 -0000 --001a11c2796cf8c8ee0514aac525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, Many thanks for very helpful comments. I have carefully read your comments and made modifications to section 3.2 in my private copy. [OLD] 1. The Reply Mode Order TLV MAY be included in MPLS echo request. 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. 3. The Reply Mode field of an MPLS echo request MUST be set to a valid value even when supplying the Reply Mode Order TLV. The initiator LSR SHOULD set the Reply Mode field of MPLS echo request to a value that corresponds to a return path which most likely to be available, in case the responder LSR does not understand the Reply Mode Order TLV. 4. If a responder LSR understands the Reply Mode Order TLV but the TLV is not valid (due to conditions described in the items 6, 8 and 9 immediately below), then the responder LSR MUST only use the value described in the Reply Mode field of received MPLS echo request. 5. If a responder LSR understands the Reply Mode Order TLV and the TLV is valid, then the responder LSR MUST consider the Reply Mode values described in the TLV and MUST NOT use the value described in the Reply Mode field of received MPLS echo request. In other words, a valid Reply Mode Order TLV overrides the value specified in the Reply Mode field of received MPLS echo request. 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, and SHOULD contain at least two Reply Mode values. 7. A Reply Mode value, except for Reply Mode value 5 (Reply via Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV. 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included more than once in the Reply Mode Order TLV. However, in such case a Reply Path TLV MUST be included for all instances of the Reply Mode value 5 included in the Reply Mode Order TLV. In other words, 3 instances of the Reply Mode value 5 in the Reply Mode Order TLV will require 3 instances of the Reply Path TLVs. 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the Reply Mode Order TLV. If a responder LSR receives a Reply Mode Order TLV which does not comply to the rules described above, then the responder LSR MUST ignore the Reply Mode Order TLV. [NEW] 1. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. If the initiator LSR receives an MPLS echo reply with the Reply Mode Order TLV, the initiator LSR MUST ignore the whole Reply Mode Order TLV and MUST only use the value from the Reply Mode field of the received MPLS echo reply. It may be beneficial for implementations to provide counters and/or loggings, with appropriate log dampening, to record this error case. 2. The Reply Mode Order TLV MAY be included in MPLS echo request. 3. The Reply Mode field of an MPLS echo request MUST be set to a valid value even when supplying the Reply Mode Order TLV. The initiator LSR SHOULD set the Reply Mode field of MPLS echo request to a value that corresponds to a return path which most likely to be available, in case the responder LSR does not understand the Reply Mode Order TLV. 4. If a responder LSR understands the Reply Mode Order TLV but the TLV is not valid (due to conditions described in the items 6, 7, 8 and 9 immediately below), then the responder LSR MUST ignore the whole Reply Mode Order TLV and MUST only use the value from the Reply Mode field of the received MPLS echo request. It may be beneficial for implementations to provide counters and/or loggings, with appropriate log dampening, to record this error case. 5. If a responder LSR understands the Reply Mode Order TLV and the TLV is valid, then the responder LSR MUST consider the Reply Mode values described in the TLV and MUST NOT use the value described in the Reply Mode field of received MPLS echo request. In other words, a valid Reply Mode Order TLV overrides the value specified in the Reply Mode field of received MPLS echo request. 6. Reply Mode Order TLV MUST contain at least one Reply Mode value. 7. A Reply Mode value, except for Reply Mode value 5 (Reply via Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV. 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included more than once in the Reply Mode Order TLV. However, in such case a Reply Path TLV MUST be included for all instances of the Reply Mode value 5 included in the Reply Mode Order TLV. In other words, 3 instances of the Reply Mode value 5 in the Reply Mode Order TLV will require 3 instances of the Reply Path TLVs. 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the Reply Mode Order TLV. Thanks! -Nobo On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel wrote: > Hi Nobo, > > > > Let's come back to my original review comments. > > > > > Section 3.2 gives clear instructions and guidance on forming the Reply > > > Mode Order TLV but not on what to do if a received TLV deviates from th= e > > > MUST and MUST NOT instructions. Options might include ignoring errors, > > > ignoring the TLV, ignoring the message. But presumably not sending an > > > error response (because how would you know how to send it?) > > > > You responded: > > > > | [NOBO] That=E2=80=99s a good point. What the document really state is t= hat The > > | Reply Mode value 5 (Reply via Specified Path) MAY be repeated but all > > | other Reply Mode values MUST NOT be repeated. Will update the > > | document to make it clear. > > > > That's a fine thing to say, but doesn't answer my question about how an > implementation is supposed to behave when a received Reply Mode Order TLV > is "malformed". > > > > You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. Section 3.2 > swapped the order of points 4 and 5, and enhanced the text to read... > > > > 4. If a responder LSR understands the Reply Mode Order TLV but the > > TLV is not valid (due to conditions described in the items 6, 8 > > and 9 immediately below), then the responder LSR MUST only use > > the value described in the Reply Mode field of received MPLS echo > > request. > > > > That seems to cover most bases. Good. > > It might also be helpful to say "...the responder LSR MUST silently ignor= e > the whole Reply Mode Order TLV and MUST only use the value from the Reply > Mode field of the received MPLS echo request." > > Saying this helps clarify the behavior. > > > > The only things I don't find covered are: > > > > a. how to handle a violation of the seventh point > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > multiple times) in the Reply Mode Order TLV. > > > > I think you can address this by adding "7" to the list of conditions > in point 4. > > > > b. how to handle a violation of the second point > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. > > > > I think this will need additional text. > > > > I note that after the numbered bullets you also now have the following > text... > > > > If a responder LSR receives a Reply Mode Order TLV which does not > > comply to the rules described above, then the responder LSR MUST > > ignore the Reply Mode Order TLV. > > > > This is better than point 4 and covers everything. > > You might consider whether "ignore" means "silently ignore" or whether yo= u > want to give advice about logging. It seems probable that (because of the > nature of ping) if you do suggest logging, you also want to describe some > form of thresholding or damping. > > > > > > To address Loa's concern... > > The TLV is from the optional range. It can be ignored if it is not > understood, and does not require to be included. > > Loa asserted that the document says that the TLV MUST be included, but I > don't find this in -02. > > Therefore, I think this is all fine. > > > > Adrian > > > > *From:* Nobo Akiya [mailto:nobo.akiya.dev@gmail.com] > *Sent:* 25 April 2015 05:50 > *To:* adrian@olddog.co.uk > *Cc:* Loa Andersson; t.petch; Ross Callon; mpls; > mpls-chairs@tools.ietf.org; > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > *Subject:* Re: [mpls] George can yu look at this - Re: end of WGLC, RE: > working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Hi Adrian, Tom, Loa, > > > > This extension is currently structured such that it allows for backwards > compatibility (i.e., transit LSR not supporting this mechanism will not > return "malformed request" ... because the TLV is optional). > > > > The result is that this mechanism becomes a best effort mechanism, and we > will not get the full benefit until all LSRs along the LSP (and other LSR= s > which could falsely receive the echo request) implements this extension. > > > > One way to allow the initiator LSR to determine whether or not the > responder LSR understood this TLV, and still keeping the backwards > compatibility, is that we keep the Reply Mode Order TLV as an optional TL= V, > but require (i.e., MUST) the responder LSR understanding this TLV to > include the Reply Mode Order TLV in the echo reply, potentially with resu= lt > of parsing/handling that TLV. > > > > However, that's probably not the path we want to go, as all (or most) > optional TLVs will have to do something similar (i.e., include the same T= LV > in the echo reply). This will quickly result in echo reply packet bloat .= .. > we should prevent that as echo reply usually tends to include more > information (ILS, DSMAP/DDMAP per nexthop, multipath Sub-TLVs per nexthop= , > etc). > > > > To me, the right way to solve this is to create a capability TLV that > mandates the reponder LSR to return which features it supports in bitmaps > or something very compact. But this can be done in a separate effort/draf= t. > > > > In short, my preference for this document is to go as is (after > incorporating comments from Tom). > > > > Thanks! > > > > -Nobo > > > > On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel > wrote: > > Thanks Loa, > > You captured it. The edge cases need to be nailed down. > > Personally I have no particular preference for where it is nailed, but I > don't > want it flapping in the breeze. > > A > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: 23 April 2015 13:59 > > To: t.petch; Nobo Akiya > > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org; > draft-ietf-mpls-lsp-ping-reply- > > mode-simple@tools.ietf.org > > Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: worki= ng > group > > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Tom, > > > > The question you and Adrian asks is what to do if the Reply Mode > > Order TLV is missing. > > > > There is something fishy here, I'd like George to look at this. > > > > The LSP Ping design says that TLVs from this range may be silentsly > > dropped, my take is that we don't need to specify anything more > > than that. > > > > Now, we say that it MUST be present, and after thinking around a bit > > I wonder if the TLV should be assigned from the mandatory range instead= ? > > > > Or if the MUST be present means that the message will be malformed if > > it is not there, and the message should be discarded. > > > > OK - now I'm confused. > > > > /Loa > > > > On 2015-04-23 13:02, t.petch wrote: > > > ---- Original Message ----- > > > From: "Loa Andersson" > > > Sent: Wednesday, April 22, 2015 2:15 PM > > > > > >> Tom, > > >> > > >> On 2015-04-20 00:07, Nobo Akiya wrote: > > >>> > > >>> > > >>> Yes but ... I think that it is a change of meaning. Is is > > > enough just > > >>> to ignore the TLV or should the whole PDU be discarded? I fin= d > > > it > > >>> difficult to know but don't feel strongly about that choice so > > > will go > > >>> with what you suggest. > > >>> > > >>> > > >> > > >> So I don't misunderstand what you are saying. It seems to me like th= e > > >> comments made by Adrian and you actually requires a "change of > > > meaning", > > >> that is kind of essence of a "comment", right? > > >> > > >> As for what to do with if the TLV is not recognized, it is > > >> intentionally requested from a space where it can be silently droppe= d > > >> (i.e. "ignored"). > > >> > > >> The new TLV Type value should be assigned from the range > > >> (32768-49161) specified in [RFC4379] section 3 that allows the > TLV > > >> type to be silently dropped if not recognized. > > >> > > >> Type Meaning Reference > > >> ---- ------- --------- > > >> TBD1 Reply Mode Order TLV this document > > >> > > >> What is it that I miss? > > > > > > Nothing serious. My initial thought was to echo Adrian, that, at lea= st > > > in this context, there should be an indication what to do if a MUST o= r > > > SHOULD was violated without just then having a clear sense of what it > > > should be instead. > > > > > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > > > more. Adding what to do if that did not happen I was seeing as > > > clarification. I then read Nobo as proposing going a bit further > saying > > > requires (MUST) one or more. Which might lead to boxes taking a > > > simplistic approach and always putting in the new TLV with a single > > > entry and ignoring the traditional TLV. Not a problem just a change > > > from what others might think that they have consented to. > > > > > > On the question of what to do when the rules are violated, again I di= d > > > not initially think of what the action should be. On reflection, I a= m > > > still unsure. I understand that the Reply Mode Order TLV is optiona= l > > > and so can be ignored when not understood; that's fine. But if it is > > > understood and can be seen to be defective, should the box with that > > > knowledge discard just that TLV and accept the remainder of the > message? > > > Or should it argue that if this TLV is defective, then likely the res= t > > > is as well and should be ignored? I am unsure. > > > > > > If there is scope for a breach of security, or taking a hit in > > > performance, then ignore is the right policy. If the requirement is t= o > > > get as much data as possible from a failing network, then use it is t= he > > > right policy. As long as the I-D is clear, I am not too fussed which > > > way it goes. I am content with the changes that Nobo has proposed. > > > > > > Tom Petch > > > > > >> /Loa > > >> > > >> -- > > >> > > >> > > >> Loa Andersson email: loa@mail01.huawei.com > > >> Senior MPLS Expert loa@pi.nu > > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > -- > > > > > > 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 > > > --001a11c2796cf8c8ee0514aac525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

Many thanks for very helpful= comments. I have carefully read your comments and made modifications to se= ction 3.2 in my private copy.

[OLD]
1.= The Reply Mode Order TLV MAY be included in MPLS echo request. 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. 3. The Reply Mode field of an MPLS echo request MUST be set to a valid value even when supplying the Reply Mode Order TLV. The initiator LSR SHOULD set the Reply Mode field of MPLS echo request to a value that corresponds to a return path which most likely to be available, in case the responder LSR does not understand the Reply Mode Order TLV. 4. If a responder LSR understands the Reply Mode Order TLV but the TLV is not valid (due to conditions described in the items 6, 8 and 9 immediately below), then the responder LSR MUST only use the value described in the Reply Mode field of received MPLS echo request. 5. If a responder LSR understands the Reply Mode Order TLV and the TLV is valid, then the responder LSR MUST consider the Reply Mode values described in the TLV and MUST NOT use the value described in the Reply Mode field of received MPLS echo request. In other words, a valid Reply Mode Order TLV overrides the value specified in the Reply Mode field of received MPLS echo request. 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, and SHOULD contain at least two Reply Mode values. 7. A Reply Mode value, except for Reply Mode value 5 (Reply via Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV. 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included more than once in the Reply Mode Order TLV. However, in such case a Reply Path TLV MUST be included for all instances of the Reply Mode value 5 included in the Reply Mode Order TLV. In other words, 3 instances of the Reply Mode value 5 in the Reply Mode Order TLV will require 3 instances of the Reply Path TLVs. 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the Reply Mode Order TLV. If a responder LSR receives a Reply Mode Order TLV which does not comply to the rules described above, then the responder LSR MUST ignore the Reply Mode Order TLV.

[NEW]

   1.  The =
Reply Mode Order TLV MUST NOT be included in MPLS echo reply.
       If the initiator LSR receives an MPLS echo reply with the Reply
       Mode Order TLV, the initiator LSR MUST ignore the whole Reply
       Mode Order TLV and MUST only use the value from the Reply Mode
       field of the received MPLS echo reply.  It may be beneficial for
       implementations to provide counters and/or loggings, with
       appropriate log dampening, to record this error case.

   2.  The Reply Mode Order TLV MAY be included in MPLS echo request.

   3.  The Reply Mode field of an MPLS echo request MUST be set to a
       valid value even when supplying the Reply Mode Order TLV.  The
       initiator LSR SHOULD set the Reply Mode field of MPLS echo
       request to a value that corresponds to a return path which most
       likely to be available, in case the responder LSR does not
       understand the Reply Mode Order TLV.

   4.  If a responder LSR understands the Reply Mode Order TLV but the
       TLV is not valid (due to conditions described in the items 6, 7,
       8 and 9 immediately below), then the responder LSR MUST ignore
       the whole Reply Mode Order TLV and MUST only use the value from
       the Reply Mode field of the received MPLS echo request.  It may
       be beneficial for implementations to provide counters and/or
       loggings, with appropriate log dampening, to record this error
       case.

   5.  If a responder LSR understands the Reply Mode Order TLV and the
       TLV is valid, then the responder LSR MUST consider the Reply Mode
       values described in the TLV and MUST NOT use the value described
       in the Reply Mode field of received MPLS echo request.  In other
       words, a valid Reply Mode Order TLV overrides the value specified
       in the Reply Mode field of received MPLS echo request.

   6.  Reply Mode Order TLV MUST contain at least one Reply Mode value.

   7.  A Reply Mode value, except for Reply Mode value 5 (Reply via
       Specified Path), MUST NOT be repeated (i.e., MUST NOT appear
       multiple times) in the Reply Mode Order TLV.

   8.  The Reply Mode value 5 (Reply via Specified Path) MAY be included
       more than once in the Reply Mode Order TLV.  However, in such
       case a Reply Path TLV MUST be included for all instances of the
       Reply Mode value 5 included in the Reply Mode Order TLV.  In
       other words, 3 instances of the Reply Mode value 5 in the Reply
       Mode Order TLV will require 3 instances of the Reply Path TLVs.

   9.  The Reply Mode value 1 (Do not reply) MUST NOT be used in the
       Reply Mode Order TLV.

Thanks!

-Nobo


On Sat, Apr 25, 2015 at 9:17 AM, Adrian Fa= rrel <adrian@olddog.co.uk> wrote:

Hi Nobo,

=

=C2=A0

Let's come back= to my original review comments.

=C2=A0

> Section 3.2 gives clear instruct= ions and guidance on forming the Reply

> Mode Order TLV but not on what t= o do if a received TLV deviates from the

> MUST and MUST NOT instructio= ns. Options might include ignoring errors,

> ignoring the TLV, ignoring t= he message. But presumably not sending an

> error response (because how = would you know how to send it?)

=C2=A0

You responded:

=C2=A0

| [NOBO] That=E2= =80=99s a good point. What the document really state is that The<= /u>

| Reply Mod= e value 5 (Reply via Specified Path) MAY be repeated but all =

| other Reply = Mode values MUST NOT be repeated. Will update the

<= p class=3D"MsoNormal">| document to make it clea= r.

That's a fine thing to say, but doesn't answer my question = about how an implementation is supposed to behave when a received Reply Mod= e Order TLV is "malformed".

=C2=A0

You posted draft-ietf-mpls-lsp-p= ing-reply-mode-simple-02. Section 3.2 swapped the order of points 4 and 5, = and enhanced the text to read...

=C2=A0

=C2=A0=C2=A0 4.=C2= =A0 If a responder LSR understands the Reply Mode Order TLV but the<= u>

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLV is not valid (due to c= onditions described in the items 6, 8

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 and 9 immediately below), then the responder LSR MUST only us= e

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the value described in t= he Reply Mode field of received MPLS echo

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 request.

=C2=A0

That seems to cover most bases. Good.=

It migh= t also be helpful to say "...the responder LSR MUST silently ignore th= e whole Reply Mode Order TLV and MUST only use the value from the Reply Mod= e field of the received MPLS echo request."

Saying this helps clarify t= he behavior.

=C2=A0

The only things I don't find covered are:

=C2= =A0

a. h= ow to handle a violation of the seventh point

=C2=A0

=C2=A0=C2=A0 7.=C2=A0 A Reply Mode value, except for Reply Mode value 5 (= Reply via

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Specified Path),= MUST NOT be repeated (i.e., MUST NOT appear

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 multiple times) in the Reply Mode Order TLV.<= /u>

=C2= =A0

=C2=A0=C2=A0 I think you can address this by adding "7" = to the list of conditions in point 4.

=C2=A0

b. how to handle a violation of = the second point

=C2=A0

=C2=A0=C2=A0 2. The Reply Mode Order TLV= MUST NOT be included in MPLS echo reply.

=C2=A0

=C2=A0=C2=A0 I= think this will need additional text.

=C2=A0

I note that after the numbered = bullets you also now have the following text...

=C2=A0<= /p>

=C2=A0=C2=A0 If a responder LSR receives a Reply Mode Order TLV which does not

= =C2=A0=C2=A0 comply to the rules described above, then the responder= LSR MUST

=C2=A0=C2=A0 ignore the Reply Mode Order TLV.<= u>

= =C2=A0

T= his is better than point 4 and covers everything.

<= p class=3D"MsoNormal">You might consider whether= "ignore" means "silently ignore" or whether you want t= o give advice about logging. It seems probable that (because of the nature = of ping) if you do suggest logging, you also want to describe some form of = thresholding or damping.

=C2=A0

=C2=A0

To address Loa's concern...<= u>

The TLV = is from the optional range. It can be ignored if it is not understood, and = does not require to be included.

Loa asserted that the document says that th= e TLV MUST be included, but I don't find this in -02.

Therefore, I think= this is all fine.

=C2=A0

Adrian

=C2=A0

From: Nobo Akiya [mailto:nobo.akiya.dev@gmail.com]
Sen= t: 25 April 2015 05:50
To: adrian@olddog.co.uk
Cc: Loa Andersson;= t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org; draft= -ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org
Subject:= Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group= last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01<= /span>

= =C2=A0

Hi Adrian, Tom, Loa,

=C2=A0

This extension is currently structured such t= hat=C2=A0it allows for backwards compatibility (i.e., transit LSR not suppo= rting this mechanism will not return "malformed request" ... beca= use the TLV is optional).

=C2=A0

The result is t= hat this mechanism becomes a best effort mechanism, and we will not get the= full benefit until all LSRs along the LSP (and other LSRs which could fals= ely receive the echo request) implements this extension.

<= /div>

=C2=A0

One way to allow the initiator LSR to determine whether or = not the responder LSR understood this TLV, and still keeping the backwards = compatibility,=C2=A0is that we keep the Reply Mode Order TLV as an optional= TLV, but require (i.e., MUST) the responder LSR understanding this TLV to = include the Reply Mode Order TLV in the echo reply, potentially with result= of parsing/handling that TLV.

=C2=A0

However, t= hat's probably not the path we want to go, as all (or most) optional TL= Vs will have to do something similar (i.e., include the same TLV in the ech= o reply). This will quickly result in echo reply packet bloat ... we should= prevent that as echo reply usually tends to include more information (ILS,= DSMAP/DDMAP per nexthop, multipath Sub-TLVs per nexthop, etc).

=C2=A0

=

To me, the right way to solve this is to create a ca= pability TLV that mandates the reponder LSR to return which features it sup= ports in bitmaps or something very compact. But this can be done in a separ= ate effort/draft.

=C2=A0

In short, my preference= for this document is to go as is (after incorporating comments from Tom).<= u>

=C2=A0

=

Thanks!

=C2=A0

-Nobo

=C2= =A0

On Thu, Apr 23, 2015 at 4:38 PM, = Adrian Farrel <= adrian@olddog.co.uk> wrote:

Thanks Loa,

You captured it. The edge= cases need to be nailed down.

Personally I have no particular prefe= rence for where it is nailed, but I don't
want it flapping in the br= eeze.

A

> -----Original Message-----
> From: mpls [m= ailto:mpls-bounc= es@ietf.org] On Behalf Of Loa Andersson
> Sent: 23 April 2015 13:= 59
> To: t.petch; Nobo Akiya
> Cc: Ross Callon; mpls; mpls-chairs@tools.= ietf.org;
draft-ietf-mpls-lsp-ping-reply-
> mode-simple@tools.ietf.org
> Subject: [mpls] George can yu look at this - Re: end of WGLC, RE:= working
group
> last call for draft-ietf-mpls-lsp-ping-reply-mode= -simple-01
>
> Tom,
>
> The question you and Adrian= asks is what to do if the Reply Mode
> Order TLV is missing.
>=
> There is something fishy here, I'd like George to look at this= .
>
> The LSP Ping design says that TLVs from this range may be= silentsly
> dropped, my take is that we don't need to specify an= ything more
> than that.
>
> Now, we say that it MUST be = present, and after thinking around a bit
> I wonder if the TLV should= be assigned from the mandatory range instead?
>
> Or if the MU= ST be present means that the message will be malformed if
> it is not= there, and the message should be discarded.
>
> OK - now I'= ;m confused.
>
> /Loa
>
> On 2015-04-23 13:02, t.pe= tch wrote:
> > ---- Original Message -----
> > From: &quo= t;Loa Andersson" <lo= a@pi.nu>
> > Sent: Wednesday, April 22, 2015 2:15 PM
>= ; >
> >> Tom,
> >>
> >> On 2015-04-2= 0 00:07, Nobo Akiya wrote:
> >>>=C2=A0 =C2=A0 =C2=A0 <tp&= gt;
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 Yes but .= .. I think that it is a change of meaning.=C2=A0 Is is
> > enough = just
> >>>=C2=A0 =C2=A0 =C2=A0 to ignore the TLV or should t= he whole PDU be discarded?=C2=A0 I find
> > it
> >>>= ;=C2=A0 =C2=A0 =C2=A0 difficult to know but don't feel strongly about t= hat choice so
> > will go
> >>>=C2=A0 =C2=A0 =C2=A0= with what you suggest.
> >>>
> >>>=C2=A0 =C2= =A0 =C2=A0 </tp>
> >>
> >> So I don't mis= understand what you are saying. It seems to me like the
> >> co= mments made by Adrian and you actually requires a "change of
> &= gt; meaning",
> >> that is kind of essence of a "comm= ent", right?
> >>
> >> As for what to do with = if the TLV is not recognized, it is
> >> intentionally requeste= d from a space where it can be silently dropped
> >> (i.e. &quo= t;ignored").
> >>
> >>=C2=A0 =C2=A0 =C2=A0 The= new TLV Type value should be assigned from the range
> >>=C2= =A0 =C2=A0 =C2=A0 (32768-49161) specified in [RFC4379] section 3 that allow= s the TLV
> >>=C2=A0 =C2=A0 =C2=A0 type to be silently dropped = if not recognized.
> >>
> >>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Type=C2=A0 =C2=A0Meaning=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 Reference
> &= gt;>=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 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ---------
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 TBD1=C2=A0= =C2=A0Reply Mode Order TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0this document
> >>
> >> What is it that I mi= ss?
> >
> > Nothing serious.=C2=A0 My initial thought was= to echo Adrian, that, at least
> > in this context, there should = be an indication what to do if a MUST or
> > SHOULD was violated w= ithout just then having a clear sense of what it
> > should be ins= tead.
> >
> > The I-D did require (MUST) one entry in the= TLV and wanted (SHOULD)
> > more.=C2=A0 Adding what to do if that= did not happen I was seeing as
> > clarification.=C2=A0 I then re= ad Nobo as proposing going a bit further saying
> > requires (MUST= ) one or more.=C2=A0 Which might lead to boxes taking a
> > simpli= stic approach and always putting in the new TLV with a single
> > = entry and ignoring the traditional TLV.=C2=A0 Not a problem just a change> > from what others might think that they have consented to.
&g= t; >
> > On the question of what to do when the rules are viola= ted, again I did
> > not initially think of what the action should= be.=C2=A0 On reflection, I am
> > still unsure.=C2=A0 I understan= d that the Reply Mode Order TLV=C2=A0 is optional
> > and so can b= e ignored when not understood; that's fine.=C2=A0 But if it is
> = > understood and can be seen to be defective, should the box with that> > knowledge discard just that TLV and accept the remainder of the= message?
> > Or should it argue that if this TLV is defective, th= en likely the rest
> > is as well and should be ignored?=C2=A0 I a= m unsure.
> >
> > If there is scope for a breach of secur= ity, or taking a hit in
> > performance, then ignore is the right = policy. If the requirement is to
> > get as much data as possible = from a failing network, then use it is the
> > right policy.=C2=A0= As long as the I-D is clear, I am not too fussed which
> > way it= goes.=C2=A0 I am content with the changes that Nobo has proposed.
> = >
> > Tom Petch
> >
> >> /Loa
> >= >
> >> --
> >>
> >>
> >>= 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=A0 email: loa@mail01.huawei.com
> >> Senior MPLS Expe= rt=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 loa@pi.nu<= /a>
> >> Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0ph= one: +46 739 8= 1 21 64
> >
>=
> --
>=
>
> 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=A0 email: <= a href=3D"mailto:loa@mail01.huawei.com" target=3D"_blank">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=A0 loa@pi.nu
> Huaw= ei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>
> ______________________________________________= _
> mpls mailing list
> mpls@ietf.org
>= ; = https://www.ietf.org/mailman/listinfo/mpls<= /p>

=C2=A0

<= /div>

--001a11c2796cf8c8ee0514aac525-- From nobody Mon Apr 27 13:22:10 2015 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 C586D1A01C6 for ; Mon, 27 Apr 2015 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 K1uwLaoDZaU9 for ; Mon, 27 Apr 2015 13:22:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 88D861A0141 for ; Mon, 27 Apr 2015 13:22:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 525FF180092; Mon, 27 Apr 2015 13:21:10 -0700 (PDT) To: xuxiaohu@huawei.com, nsheth@juniper.net, lucy.yong@huawei.com, rcallon@juniper.net, david.black@emc.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150427202110.525FF180092@rfc-editor.org> Date: Mon, 27 Apr 2015 13:21:10 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, mpls@ietf.org Subject: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 27 Apr 2015 20:22:08 -0000 The following errata report has been submitted for RFC7510, "Encapsulating MPLS in UDP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350 -------------------------------------- Type: Editorial Reported by: Adrian Farrel Section: 7 Original Text ------------- Absent Corrected Text -------------- 7.1 BGP Tunnel Encapsulation Attribute Tunnel Type IANA maintains a registry called "Border Gateway Protocol (BGP) Parameters" with a sub-registry called "BGP Tunnel Encapsulation Attribute Tunnel Types". IANA has previously allocated a code point called "MPLS in UDP Encapsulation" with value 13. IANA has added this document as a further reference for that code point. Notes ----- This text reflects a pre-publication agreement to include a request to IANA for the action that it describes. Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7510 (draft-ietf-mpls-in-udp-11) -------------------------------------- Title : Encapsulating MPLS in UDP Publication Date : April 2015 Author(s) : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Apr 27 15:49:25 2015 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 BA6651ACD0E for ; Mon, 27 Apr 2015 15:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 iP7Ls-Y3AMub for ; Mon, 27 Apr 2015 15:49:21 -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 0CFE81AC439 for ; Mon, 27 Apr 2015 15:49:21 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-4c-553e59405ee3 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 19.81.06409.0495E355; Mon, 27 Apr 2015 17:44:01 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Mon, 27 Apr 2015 18:49:11 -0400 From: Gregory Mirsky To: "draft-cui-mpls-tp-mfp-use-case-and-requirements@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "Tarek Saad (tsaad) (tsaad@cisco.com)" Thread-Topic: MPLS-RT: review draft-cui-mpls-tp-mfp-use-case-and-requirements Thread-Index: AdCBEkfRWmDxoH6BS+CweN6nbjZ39g== Date: Mon, 27 Apr 2015 22:49:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B962C8D@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B962C8Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPoK5jpF2oQaerxe/mT0wW3y8tYbG4 tXQlq8WnEz+ZHFg8pvzeyOqxZMlPJo8vlz+zBTBHcdmkpOZklqUW6dslcGW8bnvCUnCvuGLH 7JNMDYydqV2MnBwSAiYSvYdPskDYYhIX7q1n62Lk4hASOMoocfbxSyYIZzmjxP4ds8Cq2ASM JF5s7GEHSYgINDBJbJm+Ccjh4GAWUJY4dVcGxBQW8JCYstkEpFxEwFfizf+ZLBC2nsT/BQ/Z QGwWAVWJG4e2s4CU8wLVrPxlBBJmBLrh+6k1TCA2s4C4xK0n85kgbhOQWLLnPDOELSrx8vE/ VghbSWLS0nOsEPX5Eqva/4Ot4hUQlDg58wnLBEbhWUhGzUJSNgtJGURcR2LB7k9sELa2xLKF r5lh7DMHHjMhiy9gZF/FyFFanFqWm25kuIkRGD/HJNgcdzAu+GR5iFGAg1GJh/dBvG2oEGti WXFl7iFGaQ4WJXHesisHQ4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwqrRdY/37RtNM11lq k1VpZOq83EV73wsxnuwsq5u63HDejNqe+phf9/13+a+tNjaJ+tD68vXnzxIMxmbpTzOVn77+ KlR/et0Zmy8vfJ/dEPy9/HGrSNwUARXWqgp7NhfmvWIFqddOzApdpvM0+rfTjatzKxOmCJT3 lPDKbkkJW/2TY7VD7Vw2JZbijERDLeai4kQA39HiX4ACAAA= Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT: review draft-cui-mpls-tp-mfp-use-case-and-requirements 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, 27 Apr 2015 22:49:23 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B962C8Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, I was tasked to review the draft-cui-mpls-tp-mfp-use-case-and-requirements = according the guidance: 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? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). The document is coherent and well written. It does provide clear requiremen= ts toward M:N protection mechanism. But I have concerns: * There's no discussion, nor formal definition of what constitutes = simultaneous detection of multiple failures. Is that particular time interv= al, e.g. 10 msec, or relative to a failure detection interval? * Discussion of use cases does not demonstrate that there is suffic= ient number of scenarios where M:N protection is required. Thus I could not= conclude that standardization of a solution that would comply with formula= ted in the document requirements is needed. Please find more comments to the document below: * I found that the document that presents use cases of multi-failur= e protection and formulates requirements toward possible solution is on Sta= ndard track. I think that such document is more appropriate to be on Inform= ational track; * Abstract: o I believe that references in the Abstract are not suggested and rewordi= ng of the first paragraph encouraged. * Introduction o s/MUST SHOULD/MUST/ - req. 65 and 67 in RFC 5654 use MUST for 1:1 and 1= :n protection schemes * Document Scope o After reference to existing GMPLS-based restoration mechanisms not clea= r whether scope of the document is on protection or restoration mechanisms.= Networks that do not use distributed control plane do use centralized mana= gement system. Such management system can provide service restoration in ca= se of cascading failures as pointed in Section 4.1.2. If that is the case, = should the document be discussion service resiliency in case of multiple fa= ilures? Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B962C8Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et. al,

I was tasked to review the draft-cui-mpls-tp-mfp-use= -case-and-requirements according the guidance:

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 s= ound?  We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doe= sn't have to be perfect at this point, but should be a good start).

 

The document is coherent and well written. It does p= rovide clear requirements toward M:N protection mechanism. But I have conce= rns:

·         There’s no discussion, nor formal defi= nition of what constitutes simultaneous detection of multiple failures. Is = that particular time interval, e.g. 10 msec, or relative to a failure detec= tion interval?

·         Discussion of use cases does not demonstrate= that there is sufficient number of scenarios where M:N protection is requi= red. Thus I could not conclude that standardization of a solution that woul= d comply with formulated in the document requirements is needed.

Please find more comments to the document below:

·         I found that the document that presents use = cases of multi-failure protection and formulates requirements toward possib= le solution is on Standard track. I think that such document is more approp= riate to be on Informational track;

·         Abstract:

o   I believe that references in the Abstract ar= e not suggested and rewording of the first paragraph encouraged.=

·         Introduction

o   s/MUST SHOULD/MUST/ - req. 65 and 67 in RFC = 5654 use MUST for 1:1 and 1:n protection schemes

·         Document Scope

o   After reference to existing GMPLS-based rest= oration mechanisms not clear whether scope of the document is on protection= or restoration mechanisms. Networks that do not use distributed control pl= ane do use centralized management system. Such management system can provide service restoration in case of = cascading failures as pointed in Section 4.1.2. If that is the case, should= the document be discussion service resiliency in case of multiple failures= ?

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B962C8Deusaamb103erics_-- From nobody Tue Apr 28 01:00:53 2015 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 AA9151A1A47 for ; Tue, 28 Apr 2015 01:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 T036XnBjH15W for ; Tue, 28 Apr 2015 01:00:49 -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 391BD1A1A6A for ; Tue, 28 Apr 2015 01:00:49 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CA675180145E; Tue, 28 Apr 2015 10:00:46 +0200 (CEST) Message-ID: <553F3E2D.4060208@pi.nu> Date: Tue, 28 Apr 2015 10:00:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: RFC Errata System , xuxiaohu@huawei.com, nsheth@juniper.net, lucy.yong@huawei.com, rcallon@juniper.net, david.black@emc.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, swallow@cisco.com References: <20150427202110.525FF180092@rfc-editor.org> In-Reply-To: <20150427202110.525FF180092@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 28 Apr 2015 08:00:51 -0000 Deborah, I'm a bit uncertain on who actually have the final says about errata - I think it is the AD responsible for the wg producing the RFC, after consultation with authors and wg chairs/shepherd. Anyhow I think this errata should be approved. /Loa On 2015-04-27 22:21, RFC Errata System wrote: > The following errata report has been submitted for RFC7510, > "Encapsulating MPLS in UDP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350 > > -------------------------------------- > Type: Editorial > Reported by: Adrian Farrel > > Section: 7 > > Original Text > ------------- > Absent > > Corrected Text > -------------- > 7.1 BGP Tunnel Encapsulation Attribute Tunnel Type > > IANA maintains a registry called "Border Gateway Protocol (BGP) > Parameters" with a sub-registry called "BGP Tunnel Encapsulation > Attribute Tunnel Types". IANA has previously allocated a code point > called "MPLS in UDP Encapsulation" with value 13. IANA has added > this document as a further reference for that code point. > > > Notes > ----- > This text reflects a pre-publication agreement to include a request to IANA for the action that it describes. > > Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7510 (draft-ietf-mpls-in-udp-11) > -------------------------------------- > Title : Encapsulating MPLS in UDP > Publication Date : April 2015 > Author(s) : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 28 02:01:41 2015 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 E1DF71A1BB0; Tue, 28 Apr 2015 02:01:39 -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 7-bVA29019XZ; Tue, 28 Apr 2015 02:01:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C11791A1B25; Tue, 28 Apr 2015 02:01:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428090138.18519.8705.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 02:01:38 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-08.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: Tue, 28 Apr 2015 09:01:40 -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 : Relayed Echo Reply mechanism for LSP Ping Authors : Jian Luo Lizhong Jin Thomas Nadeau George Swallow Filename : draft-ietf-mpls-lsp-ping-relay-reply-08.txt Pages : 16 Date : 2015-04-28 Abstract: In some inter autonomous system (AS) and inter-area deployment scenarios for RFC 4379 "Label Switched Path (LSP) Ping and Traceroute", a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying Label Switching Router (LSR) to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-08 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-relay-reply-08 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 Tue Apr 28 03:54:27 2015 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 5833F1A876B for ; Tue, 28 Apr 2015 03:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9IJx2MoBOD2l for ; Tue, 28 Apr 2015 03:54:23 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504EC1A876A for ; Tue, 28 Apr 2015 03:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4216; q=dns/txt; s=iport; t=1430218463; x=1431428063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iB67uK2cTC3vuy7BVCxd+BllaIy88WxUAbUi91/cq5I=; b=GUhpwol4rHx0BLO4n3QcPWsSGlVTo1DrM+hpaMpAwmJ3nc24JDEEizh1 8y2neCFhJwD2yfyHQdVCHHxGOSnOBnCiMvjaHdfi/kMlzSC3CRiPhd9SL NJ9ggwXSXKOtMsfbwbvTb+aoaoZWPxGrHRq8iS15QVRNBQKaePkFzdy69 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBAAXZj9V/40NJK1CGoMMU1wFxhZmCYFIDIYCAoE2OBQBAQEBAQEBgQqEIAEBAQQBAQFoAwsMAgICAQgRAwECAS4bBgYLHQgCBAENBQmIDgMRDTjANg2FNAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEizSBPYEQgVURAR4zBwaEJwWGQosTiGWBVIEig0iKIoZVI4IHDQ+BUW8BEXk5gQABAQE X-IronPort-AV: E=Sophos;i="5.11,663,1422921600"; d="scan'208";a="145145362" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 28 Apr 2015 10:54:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3SAsMr0021707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 10:54:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.22]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 05:54:22 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson , RFC Errata System , "xuxiaohu@huawei.com" , "nsheth@juniper.net" , "lucy.yong@huawei.com" , "rcallon@juniper.net" , "david.black@emc.com" , "akatlas@gmail.com" , "db3546@att.com" , "Alvaro Retana (aretana)" , "George Swallow (swallow)" Thread-Topic: [mpls] [Editorial Errata Reported] RFC7510 (4350) Thread-Index: AQHQgSfbd29X5R9FSUyEbRgAx5Ve851iZF2A///tcgA= Date: Tue, 28 Apr 2015 10:55:40 +0000 Message-ID: References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> In-Reply-To: <553F3E2D.4060208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.150.52.38] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 28 Apr 2015 10:54:25 -0000 Hi, I do not think this erratum should be approved, and I do not believe it is Editorial in nature. RFC 7510 states that it =B3specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP=B2 but there is no mention to the specification of any signaling associated to setting up said encapsulation. In other words, it self-concerns itself with the encap. Further, there is no mention in RFC 7510 of =B3BGP=B2 and no reference to R= FC 5512. For a document specifying a BGP Tunnel Encapsulation Attribute Tunnel Type, I=B9d expect a reference (normative) to RFC 5512 (such as in RFC 5566). Lastly, the IANA page points to a different document: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel- types Value Name Reference 13 MPLS in UDP Encapsulation [draft-ietf-l3vpn-end-system] Net-net, this RFC is not the right place to be a pointer for this assignment. Thanks, =8B Carlos -----Original Message----- From: Loa Andersson Date: Tuesday, April 28, 2015 at 4:00 AM To: RFC Errata System , Xiaohu Xu , "nsheth@juniper.net" , "lucy.yong@huawei.com" , Ross Callon , "david.black@emc.com" , Alia Atlas , "db3546@att.com" , Alvaro Retana , "George Swallow (swallow)" Cc: "mpls@ietf.org" Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) >Deborah, > >I'm a bit uncertain on who actually have the final says about >errata - I think it is the AD responsible for the wg producing >the RFC, after consultation with authors and wg chairs/shepherd. > >Anyhow I think this errata should be approved. > >/Loa > >On 2015-04-27 22:21, RFC Errata System wrote: >> The following errata report has been submitted for RFC7510, >> "Encapsulating MPLS in UDP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D7510&eid=3D4350 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Adrian Farrel >> >> Section: 7 >> >> Original Text >> ------------- >> Absent >> >> Corrected Text >> -------------- >> 7.1 BGP Tunnel Encapsulation Attribute Tunnel Type >> >> IANA maintains a registry called "Border Gateway Protocol (BGP) >> Parameters" with a sub-registry called "BGP Tunnel Encapsulation >> Attribute Tunnel Types". IANA has previously allocated a code point >> called "MPLS in UDP Encapsulation" with value 13. IANA has added >> this document as a further reference for that code point. >> >> >> Notes >> ----- >> This text reflects a pre-publication agreement to include a request to >>IANA for the action that it describes. >> >> Note that the text supplied here shows the use of the past tense as is >>normal in an RFC that reports IANA action. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7510 (draft-ietf-mpls-in-udp-11) >> -------------------------------------- >> Title : Encapsulating MPLS in UDP >> Publication Date : April 2015 >> Author(s) : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> > >--=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 Tue Apr 28 05:35:00 2015 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 DC5491A9026 for ; Tue, 28 Apr 2015 05:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 611Fua0W5ez7 for ; Tue, 28 Apr 2015 05:34:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472DD1A901E for ; Tue, 28 Apr 2015 05:34:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3SCYdfL028578; Tue, 28 Apr 2015 13:34:39 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3SCYZd1028552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 13:34:36 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , "'Loa Andersson'" , "'RFC Errata System'" , , , , , , , , "'Alvaro Retana \(aretana\)'" , "'George Swallow \(swallow\)'" References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> In-Reply-To: Date: Tue, 28 Apr 2015 13:34:35 +0100 Message-ID: <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/3DfgbSN8tEHnocD0R2+RUTGJ3wKB0O4QAOOHTASb6HkTIA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21508.006 X-TM-AS-Result: No--10.437-10.0-31-10 X-imss-scan-details: No--10.437-10.0-31-10 X-TMASE-MatchedRID: WMT2WRIkHPNw08wUkhf6cwPZZctd3P4BmWGJLfJ2t7e4Kkg59mswFwO7 BC/l/zZYwicM8oyAgjagAw7A98/bWEn4dMSWXlsdaK+MsTwM+1n3EiKJ4hMlqDnZfxjBVQRbzcw TglIp/qMQ7TSRSUjrBzu6+TpA78AjQEDexda+ekrTzWmGCXkX+TGZtPrBBPZr1TKQ8rVEUCheK2 fhGg97mT3SbOdbz3vJbYH4cnTg5Bhuzw/aNxRy7/OS+SRxjgFwwLlnHU0okA0Ti8trxo6IvFcq2 fypMLLjW7aLIPj3cZMRA4hwIn2MDY4a2rhHAtuZgsh14ebDbIligcf+CLQr29q/PugZS7lh2UwB LM8az1QXQ2DJKSUavmnnY06BIEHdu+ZnC5pywjuSzy6xUtuuTxlgDfyCPcHEwiUPGrCwNhd5nft uVZELM14Nujg4HMd+i7VALUBjJJjEeWRP8ZW60p4CIKY/Hg3AhGBk0/7pshLEQdG7H66TyH4gKq 42LRYkPJyH5cF51irYhdpmkPcTgIkIQIyl3e6LjHHIsUVsFR5+3BndfXUhXQ== Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 12:34:59 -0000 Hi Carlos, Since I raised the issue... The text that was omitted was agreed for inclusion between the RFC = Editor, IANA, and responsible AD before the publication of the RFC, but was fumbled by = the RFC Editor. The RFC Editor requested this report to be submitted to resolve this = issue, and I checked with the ADs before I posted it. The problem it solves is that the existing registry entry points at an = I-D that caused the allocation of the code point, but that I-D is not a good = reference for explaining what "MPLS in UDP" is. This document provides a better indication. You said... > RFC 7510 states that it =B3specifies an IP-based encapsulation for = MPLS, > called MPLS-in-UDP=B2 but there is no mention to the specification of = any > signaling associated to setting up said encapsulation. In other words, = it > self-concerns itself with the encap. That is correct. And there is no attempt to define any signaling or add = any mention of signaling to this document. This is not a forward pointer, but a request to include a backward = pointer. That is, it is a request to update the entry that already exists in the = registry with a pointer to this document so that people can see what "MPLS in UDP" is = when they encounter the value in the registry. > Further, there is no mention in RFC 7510 of =B3BGP=B2 and no reference = to RFC > 5512. For a document specifying a BGP Tunnel Encapsulation Attribute > Tunnel Type, I=B9d expect a reference (normative) to RFC 5512 (such as = in > RFC 5566). This document does not specify a BGP Tunnel Encapsulation Attribute and = there is no request for it to make such a specification. References could be included, but they would be pointless because there = is nothing to hook the references to. The *only* change requested is to = attach a pointer to the existing entry in the registry. > Lastly, the IANA page points to a different document: > http://www.iana.org/assignments/bgp-parameters/bgp- > parameters.xhtml#tunnel- > types >=20 > Value Name Reference > 13 MPLS in UDP Encapsulation [draft-ietf-l3vpn-end-system] Yes. Have you read that document? This errata report does not request removal of that reference. It = requests the addition of an extra reference. How is that a problem? For those of you who have read around the subject, you may recall a = prolonged series of emails across a number of mailing lists where a number of = different new I-Ds were proposed to give a more substantive reference for the = tunnel type. This errata report solves that issue without needing further documents. You may also like to note that we are dealing with a FCFS registry where = the documents supplied as references do not always provide a good = explanation. Is it better to leave the registry with a poor reference, or to add a somewhat = better one? > Net-net, this RFC is not the right place to be a pointer for this > assignment. I respect your right to hold that opinion, but I don't think you have = given any valid reasons for holding it. Perhaps this lack is caused by = unfamiliarity with FCFS registries. Adrian From nobody Tue Apr 28 05:48:28 2015 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 845B71A902A for ; Tue, 28 Apr 2015 05:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] 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 iTsprwyKoQPa for ; Tue, 28 Apr 2015 05:48:22 -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 2F2DE1A90CE for ; Tue, 28 Apr 2015 05:48:22 -0700 (PDT) Received: from [2.69.78.124] (2.69.78.124.mobile.tre.se [2.69.78.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 40D39180145E; Tue, 28 Apr 2015 14:48:20 +0200 (CEST) Message-ID: <553F8193.8040506@pi.nu> Date: Tue, 28 Apr 2015 14:48:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nobo Akiya , adrian@olddog.co.uk References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ross Callon , mpls , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 28 Apr 2015 12:48:26 -0000 Nobo, I think this is fine. Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed. Bullet 6-9 describe the mal-formednesses. Is it "invalid" rather than "not valid"? Tom and Adrian are you OK with this? /Loa On 2015-04-27 03:36, Nobo Akiya wrote: > Hi Adrian, > > Many thanks for very helpful comments. I have carefully read your > comments and made modifications to section 3.2 in my private copy. > > [OLD] > > 1. The Reply Mode Order TLV MAY be included in MPLS echo request. > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. > > 3. The Reply Mode field of an MPLS echo request MUST be set to a > valid value even when supplying the Reply Mode Order TLV. The > initiator LSR SHOULD set the Reply Mode field of MPLS echo > request to a value that corresponds to a return path which most > likely to be available, in case the responder LSR does not > understand the Reply Mode Order TLV. > > 4. If a responder LSR understands the Reply Mode Order TLV but the > TLV is not valid (due to conditions described in the items 6, 8 > and 9 immediately below), then the responder LSR MUST only use > the value described in the Reply Mode field of received MPLS echo > request. > > 5. If a responder LSR understands the Reply Mode Order TLV and the > TLV is valid, then the responder LSR MUST consider the Reply Mode > values described in the TLV and MUST NOT use the value described > in the Reply Mode field of received MPLS echo request. In other > words, a valid Reply Mode Order TLV overrides the value specified > in the Reply Mode field of received MPLS echo request. > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, > and SHOULD contain at least two Reply Mode values. > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > multiple times) in the Reply Mode Order TLV. > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included > more than once in the Reply Mode Order TLV. However, in such > case a Reply Path TLV MUST be included for all instances of the > Reply Mode value 5 included in the Reply Mode Order TLV. In > other words, 3 instances of the Reply Mode value 5 in the Reply > Mode Order TLV will require 3 instances of the Reply Path TLVs. > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the > Reply Mode Order TLV. > > If a responder LSR receives a Reply Mode Order TLV which does not > comply to the rules described above, then the responder LSR MUST > ignore the Reply Mode Order TLV. > > > [NEW] > > 1. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. > If the initiator LSR receives an MPLS echo reply with the Reply > Mode Order TLV, the initiator LSR MUST ignore the whole Reply > Mode Order TLV and MUST only use the value from the Reply Mode > field of the received MPLS echo reply. It may be beneficial for > implementations to provide counters and/or loggings, with > appropriate log dampening, to record this error case. > > 2. The Reply Mode Order TLV MAY be included in MPLS echo request. > > 3. The Reply Mode field of an MPLS echo request MUST be set to a > valid value even when supplying the Reply Mode Order TLV. The > initiator LSR SHOULD set the Reply Mode field of MPLS echo > request to a value that corresponds to a return path which most > likely to be available, in case the responder LSR does not > understand the Reply Mode Order TLV. > > 4. If a responder LSR understands the Reply Mode Order TLV but the > TLV is not valid (due to conditions described in the items 6, 7, > 8 and 9 immediately below), then the responder LSR MUST ignore > the whole Reply Mode Order TLV and MUST only use the value from > the Reply Mode field of the received MPLS echo request. It may > be beneficial for implementations to provide counters and/or > loggings, with appropriate log dampening, to record this error > case. > > 5. If a responder LSR understands the Reply Mode Order TLV and the > TLV is valid, then the responder LSR MUST consider the Reply Mode > values described in the TLV and MUST NOT use the value described > in the Reply Mode field of received MPLS echo request. In other > words, a valid Reply Mode Order TLV overrides the value specified > in the Reply Mode field of received MPLS echo request. > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode value. > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > multiple times) in the Reply Mode Order TLV. > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included > more than once in the Reply Mode Order TLV. However, in such > case a Reply Path TLV MUST be included for all instances of the > Reply Mode value 5 included in the Reply Mode Order TLV. In > other words, 3 instances of the Reply Mode value 5 in the Reply > Mode Order TLV will require 3 instances of the Reply Path TLVs. > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the > Reply Mode Order TLV. > > > Thanks! > > -Nobo > > > On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel > wrote: > > Hi Nobo,____ > > __ __ > > Let's come back to my original review comments.____ > > __ __ > > > Section 3.2 gives clear instructions and guidance on forming the Reply____ > > > Mode Order TLV but not on what to do if a received TLV deviates from the____ > > > MUST and MUST NOT instructions. Options might include ignoring errors,____ > > > ignoring the TLV, ignoring the message. But presumably not sending an____ > > > error response (because how would you know how to send it?)____ > > __ __ > > You responded:____ > > __ __ > > | [NOBO] That’s a good point. What the document really state is that > The____ > > | Reply Mode value 5 (Reply via Specified Path) MAY be repeated but > all ____ > > | other Reply Mode values MUST NOT be repeated. Will update the____ > > | document to make it clear.____ > > __ __ > > That's a fine thing to say, but doesn't answer my question about how > an implementation is supposed to behave when a received Reply Mode > Order TLV is "malformed".____ > > __ __ > > You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. Section > 3.2 swapped the order of points 4 and 5, and enhanced the text to > read...____ > > __ __ > > 4.If a responder LSR understands the Reply Mode Order TLV but the____ > > TLV is not valid (due to conditions described in the items 6, 8____ > > and 9 immediately below), then the responder LSR MUST only use____ > > the value described in the Reply Mode field of received MPLS echo____ > > request.____ > > __ __ > > That seems to cover most bases. Good.____ > > It might also be helpful to say "...the responder LSR MUST silently > ignore the whole Reply Mode Order TLV and MUST only use the value > from the Reply Mode field of the received MPLS echo request."____ > > Saying this helps clarify the behavior.____ > > __ __ > > The only things I don't find covered are:____ > > __ __ > > a. how to handle a violation of the seventh point____ > > __ __ > > 7.A Reply Mode value, except for Reply Mode value 5 (Reply via____ > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear____ > > multiple times) in the Reply Mode Order TLV.____ > > __ __ > > I think you can address this by adding "7" to the list of conditions > in point 4.____ > > __ __ > > b. how to handle a violation of the second point____ > > __ __ > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply.____ > > __ __ > > I think this will need additional text.____ > > __ __ > > I note that after the numbered bullets you also now have the > following text...____ > > __ __ > > If a responder LSR receives a Reply Mode Order TLV which does not____ > > comply to the rules described above, then the responder LSR MUST____ > > ignore the Reply Mode Order TLV.____ > > __ __ > > This is better than point 4 and covers everything.____ > > You might consider whether "ignore" means "silently ignore" or > whether you want to give advice about logging. It seems probable > that (because of the nature of ping) if you do suggest logging, you > also want to describe some form of thresholding or damping.____ > > __ __ > > __ __ > > To address Loa's concern...____ > > The TLV is from the optional range. It can be ignored if it is not > understood, and does not require to be included.____ > > Loa asserted that the document says that the TLV MUST be included, > but I don't find this in -02.____ > > Therefore, I think this is all fine.____ > > __ __ > > Adrian____ > > __ __ > > *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com > ] > *Sent:* 25 April 2015 05:50 > *To:* adrian@olddog.co.uk > *Cc:* Loa Andersson; t.petch; Ross Callon; mpls; > mpls-chairs@tools.ietf.org ; > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > > *Subject:* Re: [mpls] George can yu look at this - Re: end of WGLC, > RE: working group last call for > draft-ietf-mpls-lsp-ping-reply-mode-simple-01____ > > __ __ > > Hi Adrian, Tom, Loa,____ > > __ __ > > This extension is currently structured such that it allows for > backwards compatibility (i.e., transit LSR not supporting this > mechanism will not return "malformed request" ... because the TLV is > optional).____ > > __ __ > > The result is that this mechanism becomes a best effort mechanism, > and we will not get the full benefit until all LSRs along the LSP > (and other LSRs which could falsely receive the echo request) > implements this extension.____ > > __ __ > > One way to allow the initiator LSR to determine whether or not the > responder LSR understood this TLV, and still keeping the backwards > compatibility, is that we keep the Reply Mode Order TLV as an > optional TLV, but require (i.e., MUST) the responder LSR > understanding this TLV to include the Reply Mode Order TLV in the > echo reply, potentially with result of parsing/handling that TLV.____ > > __ __ > > However, that's probably not the path we want to go, as all (or > most) optional TLVs will have to do something similar (i.e., include > the same TLV in the echo reply). This will quickly result in echo > reply packet bloat ... we should prevent that as echo reply usually > tends to include more information (ILS, DSMAP/DDMAP per nexthop, > multipath Sub-TLVs per nexthop, etc).____ > > __ __ > > To me, the right way to solve this is to create a capability TLV > that mandates the reponder LSR to return which features it supports > in bitmaps or something very compact. But this can be done in a > separate effort/draft.____ > > __ __ > > In short, my preference for this document is to go as is (after > incorporating comments from Tom).____ > > __ __ > > Thanks!____ > > __ __ > > -Nobo____ > > __ __ > > On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel > wrote:____ > > Thanks Loa, > > You captured it. The edge cases need to be nailed down. > > Personally I have no particular preference for where it is nailed, > but I don't > want it flapping in the breeze. > > A > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org > ] On Behalf Of Loa Andersson > > Sent: 23 April 2015 13:59 > > To: t.petch; Nobo Akiya > > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org > ; > draft-ietf-mpls-lsp-ping-reply- > > mode-simple@tools.ietf.org > > Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: > working > group > > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > Tom, > > > > The question you and Adrian asks is what to do if the Reply Mode > > Order TLV is missing. > > > > There is something fishy here, I'd like George to look at this. > > > > The LSP Ping design says that TLVs from this range may be silentsly > > dropped, my take is that we don't need to specify anything more > > than that. > > > > Now, we say that it MUST be present, and after thinking around a bit > > I wonder if the TLV should be assigned from the mandatory range > instead? > > > > Or if the MUST be present means that the message will be malformed if > > it is not there, and the message should be discarded. > > > > OK - now I'm confused. > > > > /Loa > > > > On 2015-04-23 13:02, t.petch wrote: > > > ---- Original Message ----- > > > From: "Loa Andersson" > > > > Sent: Wednesday, April 22, 2015 2:15 PM > > > > > >> Tom, > > >> > > >> On 2015-04-20 00:07, Nobo Akiya wrote: > > >>> > > >>> > > >>> Yes but ... I think that it is a change of meaning. Is is > > > enough just > > >>> to ignore the TLV or should the whole PDU be discarded? > I find > > > it > > >>> difficult to know but don't feel strongly about that > choice so > > > will go > > >>> with what you suggest. > > >>> > > >>> > > >> > > >> So I don't misunderstand what you are saying. It seems to me > like the > > >> comments made by Adrian and you actually requires a "change of > > > meaning", > > >> that is kind of essence of a "comment", right? > > >> > > >> As for what to do with if the TLV is not recognized, it is > > >> intentionally requested from a space where it can be silently > dropped > > >> (i.e. "ignored"). > > >> > > >> The new TLV Type value should be assigned from the range > > >> (32768-49161) specified in [RFC4379] section 3 that > allows the TLV > > >> type to be silently dropped if not recognized. > > >> > > >> Type Meaning Reference > > >> ---- ------- --------- > > >> TBD1 Reply Mode Order TLV this document > > >> > > >> What is it that I miss? > > > > > > Nothing serious. My initial thought was to echo Adrian, that, > at least > > > in this context, there should be an indication what to do if a > MUST or > > > SHOULD was violated without just then having a clear sense of > what it > > > should be instead. > > > > > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > > > more. Adding what to do if that did not happen I was seeing as > > > clarification. I then read Nobo as proposing going a bit > further saying > > > requires (MUST) one or more. Which might lead to boxes taking a > > > simplistic approach and always putting in the new TLV with a single > > > entry and ignoring the traditional TLV. Not a problem just a > change > > > from what others might think that they have consented to. > > > > > > On the question of what to do when the rules are violated, > again I did > > > not initially think of what the action should be. On > reflection, I am > > > still unsure. I understand that the Reply Mode Order TLV is > optional > > > and so can be ignored when not understood; that's fine. But if > it is > > > understood and can be seen to be defective, should the box with > that > > > knowledge discard just that TLV and accept the remainder of the > message? > > > Or should it argue that if this TLV is defective, then likely > the rest > > > is as well and should be ignored? I am unsure. > > > > > > If there is scope for a breach of security, or taking a hit in > > > performance, then ignore is the right policy. If the > requirement is to > > > get as much data as possible from a failing network, then use > it is the > > > right policy. As long as the I-D is clear, I am not too fussed > which > > > way it goes. I am content with the changes that Nobo has proposed. > > > > > > Tom Petch > > > > > >> /Loa > > >> > > >> -- > > >> > > >> > > >> Loa Andersson email: > loa@mail01.huawei.com > > >> Senior MPLS Expert loa@pi.nu > > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > > -- > > > > > > Loa Andersson email:loa@mail01.huawei.com > > Senior MPLS Expertloa@pi.nu > > Huawei Technologies (consultant) phone:+46 739 81 21 64 > > > > _______________________________________________ > > 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 Tue Apr 28 06:55:00 2015 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 796E81ACD7E; Tue, 28 Apr 2015 06:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 z1XMRIDZluuy; Tue, 28 Apr 2015 06:54:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0A1ACD52; Tue, 28 Apr 2015 06:54:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8F0DA180206; Tue, 28 Apr 2015 06:53:58 -0700 (PDT) To: adrian@olddog.co.uk, xuxiaohu@huawei.com, nsheth@juniper.net, lucy.yong@huawei.com, rcallon@juniper.net, david.black@emc.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150428135358.8F0DA180206@rfc-editor.org> Date: Tue, 28 Apr 2015 06:53:58 -0700 (PDT) Archived-At: Cc: mpls@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Errata Verified] RFC7510 (4350) 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, 28 Apr 2015 13:54:59 -0000 The following errata report has been verified for RFC7510, "Encapsulating MPLS in UDP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350 -------------------------------------- Status: Verified Type: Editorial Reported by: Adrian Farrel Date Reported: 2015-04-27 Verified by: Alia Atlas (IESG) Section: 7 Original Text ------------- Absent Corrected Text -------------- 7.1 BGP Tunnel Encapsulation Attribute Tunnel Type IANA maintains a registry called "Border Gateway Protocol (BGP) Parameters" with a sub-registry called "BGP Tunnel Encapsulation Attribute Tunnel Types". IANA has previously allocated a code point called "MPLS in UDP Encapsulation" with value 13. IANA has added this document as a further reference for that code point. Notes ----- This text reflects a pre-publication agreement to include a request to IANA for the action that it describes. Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action. -------------------------------------- RFC7510 (draft-ietf-mpls-in-udp-11) -------------------------------------- Title : Encapsulating MPLS in UDP Publication Date : April 2015 Author(s) : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Apr 28 06:55:12 2015 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 BD64D1ACD52; Tue, 28 Apr 2015 06:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 4t1MH4NiIvDD; Tue, 28 Apr 2015 06:54:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 13DF31ACD08; Tue, 28 Apr 2015 06:54:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 95648180207; Tue, 28 Apr 2015 06:53:58 -0700 (PDT) To: adrian@olddog.co.uk, xuxiaohu@huawei.com, nsheth@juniper.net, lucy.yong@huawei.com, rcallon@juniper.net, david.black@emc.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150428135358.95648180207@rfc-editor.org> Date: Tue, 28 Apr 2015 06:53:58 -0700 (PDT) Archived-At: Cc: mpls@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Errata Verified] RFC7510 (4350) 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, 28 Apr 2015 13:54:59 -0000 The following errata report has been verified for RFC7510, "Encapsulating MPLS in UDP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7510&eid=4350 -------------------------------------- Status: Verified Type: Editorial Reported by: Adrian Farrel Date Reported: 2015-04-27 Verified by: Alia Atlas (IESG) Section: 7 Original Text ------------- Absent Corrected Text -------------- 7.1 BGP Tunnel Encapsulation Attribute Tunnel Type IANA maintains a registry called "Border Gateway Protocol (BGP) Parameters" with a sub-registry called "BGP Tunnel Encapsulation Attribute Tunnel Types". IANA has previously allocated a code point called "MPLS in UDP Encapsulation" with value 13. IANA has added this document as a further reference for that code point. Notes ----- This text reflects a pre-publication agreement to include a request to IANA for the action that it describes. Note that the text supplied here shows the use of the past tense as is normal in an RFC that reports IANA action. -------------------------------------- RFC7510 (draft-ietf-mpls-in-udp-11) -------------------------------------- Title : Encapsulating MPLS in UDP Publication Date : April 2015 Author(s) : X. Xu, N. Sheth, L. Yong, R. Callon, D. Black Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Apr 28 06:59:27 2015 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 3F7E11ACD52 for ; Tue, 28 Apr 2015 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 8EfAMc37bly7 for ; Tue, 28 Apr 2015 06:59:22 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B73B1ACD8E for ; Tue, 28 Apr 2015 06:59:20 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3SDxHhQ000817; Tue, 28 Apr 2015 14:59:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3SDxFkw000785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 14:59:16 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , "'Nobo Akiya'" References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> <553F8193.8040506@pi.nu> In-Reply-To: <553F8193.8040506@pi.nu> Date: Tue, 28 Apr 2015 14:59:16 +0100 Message-ID: <011c01d081bb$843f9010$8cbeb030$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQPgMp+F85EfvPJp+pmFDDXz24DS/gHDk72sAiR8PsAB8lbRgwI+M4C/AbBgzsoBy3FM4wIy3pA3Avr9XeoBa+ZcUgJAy7jfAwGha6MBuq+ZXgIepnUrAYcK8UmYXImx0A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21508.006 X-TM-AS-Result: No--43.848-10.0-31-10 X-imss-scan-details: No--43.848-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtEwJ6xbTjBa5qfXIl6Cf6Vrt3aeg7g/usAiFs20Vxq/wqbJ BUbWQw1/9lkA+U5/c8qqEjHR8FX3BZAbpTKt/Q8oDPhWwJzVhb4oAys1ZnmifYqUnvVNf36DK6v HqAmHiihyC511Aa/rrre9jPJWA+Z/fZRSAB5AyaDKl4yJoI+fG6KaxHqGRwkCyvfX8jlSts9Tac dDUa7rn70eXV6kEIhuuMJ1zedLNHHltYkU0vW1g7MjW/sniEQKO1K5iM8Q6KBb8pv4L0h+ItoFL 957gqWBgTttjVVm2w0mNpzri1sedxmN40CNJF1HMIiU395I8H2nCcVmef5UfGecrqZc3vabUKmz H22CobLO6NwyPA2Em5bZ2d9EDf9gCNmyKN5cwZZPuMJi/ZAk8Y7vhl9PIBCwIbxYwbCxGTS8vgG 4C4GxKcXHJO+ADeY235UQIFIaHt8AzT8btdR142A/V00XWjDtVo4lwLFUdisZ4vA+WJA5l0m7ll tw/MltW4s10/eVbKV3pylBb1UsCupLXJKeenhQ9iItFUn3XkO7atxTbKDEIAtdzMvO/y20MuTwb aqEJZNAuGTHvw4kUVIWm0a4ZxyMoHXVGSZqod6GwT67eecJ8L0DocWZ0hrhV9eB8vnmKe/RXOsa mVbRj07OPZmLzPG0NSHubTbIDFlARZwyzva+YUhEDfw/93BuyeUl7aCTy8gdGynCN4u9Jch+hkW OQ+NP0H+hMLVCqQqKw4MXRQa21DcFasZFt/8/wCZxkTHxccmVq+okl1rYD9YIrMNiSqPJecZf3B 8j81r2zVwvvHqBF4BQPfgi6u66Sfh0xJZeWx2eAiCmPx4NwFkMvWAuahr8ooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: 'Ross Callon' , 'mpls' , mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 13:59:26 -0000 I'm OK with what Nobo said. A > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 28 April 2015 13:48 > To: Nobo Akiya; adrian@olddog.co.uk > Cc: t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org; = draft-ietf-mpls-lsp- > ping-reply-mode-simple@tools.ietf.org > Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: = working > group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 >=20 > Nobo, >=20 > I think this is fine. >=20 > Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed. >=20 > Bullet 6-9 describe the mal-formednesses. >=20 > Is it "invalid" rather than "not valid"? >=20 > Tom and Adrian are you OK with this? >=20 > /Loa >=20 > On 2015-04-27 03:36, Nobo Akiya wrote: > > Hi Adrian, > > > > Many thanks for very helpful comments. I have carefully read your > > comments and made modifications to section 3.2 in my private copy. > > > > [OLD] > > > > 1. The Reply Mode Order TLV MAY be included in MPLS echo = request. > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo = reply. > > > > 3. The Reply Mode field of an MPLS echo request MUST be set to = a > > valid value even when supplying the Reply Mode Order TLV. = The > > initiator LSR SHOULD set the Reply Mode field of MPLS echo > > request to a value that corresponds to a return path which = most > > likely to be available, in case the responder LSR does not > > understand the Reply Mode Order TLV. > > > > 4. If a responder LSR understands the Reply Mode Order TLV but = the > > TLV is not valid (due to conditions described in the items = 6, 8 > > and 9 immediately below), then the responder LSR MUST only = use > > the value described in the Reply Mode field of received MPLS = echo > > request. > > > > 5. If a responder LSR understands the Reply Mode Order TLV and = the > > TLV is valid, then the responder LSR MUST consider the Reply = Mode > > values described in the TLV and MUST NOT use the value = described > > in the Reply Mode field of received MPLS echo request. In = other > > words, a valid Reply Mode Order TLV overrides the value = specified > > in the Reply Mode field of received MPLS echo request. > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode = value, > > and SHOULD contain at least two Reply Mode values. > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > multiple times) in the Reply Mode Order TLV. > > > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be = included > > more than once in the Reply Mode Order TLV. However, in = such > > case a Reply Path TLV MUST be included for all instances of = the > > Reply Mode value 5 included in the Reply Mode Order TLV. In > > other words, 3 instances of the Reply Mode value 5 in the = Reply > > Mode Order TLV will require 3 instances of the Reply Path = TLVs. > > > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in = the > > Reply Mode Order TLV. > > > > If a responder LSR receives a Reply Mode Order TLV which does = not > > comply to the rules described above, then the responder LSR MUST > > ignore the Reply Mode Order TLV. > > > > > > [NEW] > > > > 1. The Reply Mode Order TLV MUST NOT be included in MPLS echo = reply. > > If the initiator LSR receives an MPLS echo reply with the = Reply > > Mode Order TLV, the initiator LSR MUST ignore the whole = Reply > > Mode Order TLV and MUST only use the value from the Reply = Mode > > field of the received MPLS echo reply. It may be beneficial = for > > implementations to provide counters and/or loggings, with > > appropriate log dampening, to record this error case. > > > > 2. The Reply Mode Order TLV MAY be included in MPLS echo = request. > > > > 3. The Reply Mode field of an MPLS echo request MUST be set to = a > > valid value even when supplying the Reply Mode Order TLV. = The > > initiator LSR SHOULD set the Reply Mode field of MPLS echo > > request to a value that corresponds to a return path which = most > > likely to be available, in case the responder LSR does not > > understand the Reply Mode Order TLV. > > > > 4. If a responder LSR understands the Reply Mode Order TLV but = the > > TLV is not valid (due to conditions described in the items = 6, 7, > > 8 and 9 immediately below), then the responder LSR MUST = ignore > > the whole Reply Mode Order TLV and MUST only use the value = from > > the Reply Mode field of the received MPLS echo request. It = may > > be beneficial for implementations to provide counters and/or > > loggings, with appropriate log dampening, to record this = error > > case. > > > > 5. If a responder LSR understands the Reply Mode Order TLV and = the > > TLV is valid, then the responder LSR MUST consider the Reply = Mode > > values described in the TLV and MUST NOT use the value = described > > in the Reply Mode field of received MPLS echo request. In = other > > words, a valid Reply Mode Order TLV overrides the value = specified > > in the Reply Mode field of received MPLS echo request. > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode = value. > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > multiple times) in the Reply Mode Order TLV. > > > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be = included > > more than once in the Reply Mode Order TLV. However, in = such > > case a Reply Path TLV MUST be included for all instances of = the > > Reply Mode value 5 included in the Reply Mode Order TLV. In > > other words, 3 instances of the Reply Mode value 5 in the = Reply > > Mode Order TLV will require 3 instances of the Reply Path = TLVs. > > > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in = the > > Reply Mode Order TLV. > > > > > > Thanks! > > > > -Nobo > > > > > > On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel > > wrote: > > > > Hi Nobo,____ > > > > __ __ > > > > Let's come back to my original review comments.____ > > > > __ __ > > > > > Section 3.2 gives clear instructions and guidance on forming = the Reply____ > > > > > Mode Order TLV but not on what to do if a received TLV = deviates from > the____ > > > > > MUST and MUST NOT instructions. Options might include ignoring > errors,____ > > > > > ignoring the TLV, ignoring the message. But presumably not = sending > an____ > > > > > error response (because how would you know how to send = it?)____ > > > > __ __ > > > > You responded:____ > > > > __ __ > > > > | [NOBO] That=E2=80=99s a good point. What the document really = state is that > > The____ > > > > | Reply Mode value 5 (Reply via Specified Path) MAY be repeated = but > > all ____ > > > > | other Reply Mode values MUST NOT be repeated. Will update = the____ > > > > | document to make it clear.____ > > > > __ __ > > > > That's a fine thing to say, but doesn't answer my question about = how > > an implementation is supposed to behave when a received Reply = Mode > > Order TLV is "malformed".____ > > > > __ __ > > > > You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. = Section > > 3.2 swapped the order of points 4 and 5, and enhanced the text = to > > read...____ > > > > __ __ > > > > 4.If a responder LSR understands the Reply Mode Order TLV but = the____ > > > > TLV is not valid (due to conditions described in the items 6, = 8____ > > > > and 9 immediately below), then the responder LSR MUST only = use____ > > > > the value described in the Reply Mode field of received MPLS = echo____ > > > > request.____ > > > > __ __ > > > > That seems to cover most bases. Good.____ > > > > It might also be helpful to say "...the responder LSR MUST = silently > > ignore the whole Reply Mode Order TLV and MUST only use the = value > > from the Reply Mode field of the received MPLS echo = request."____ > > > > Saying this helps clarify the behavior.____ > > > > __ __ > > > > The only things I don't find covered are:____ > > > > __ __ > > > > a. how to handle a violation of the seventh point____ > > > > __ __ > > > > 7.A Reply Mode value, except for Reply Mode value 5 (Reply = via____ > > > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear____ > > > > multiple times) in the Reply Mode Order TLV.____ > > > > __ __ > > > > I think you can address this by adding "7" to the list of = conditions > > in point 4.____ > > > > __ __ > > > > b. how to handle a violation of the second point____ > > > > __ __ > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo > reply.____ > > > > __ __ > > > > I think this will need additional text.____ > > > > __ __ > > > > I note that after the numbered bullets you also now have the > > following text...____ > > > > __ __ > > > > If a responder LSR receives a Reply Mode Order TLV which does = not____ > > > > comply to the rules described above, then the responder LSR = MUST____ > > > > ignore the Reply Mode Order TLV.____ > > > > __ __ > > > > This is better than point 4 and covers everything.____ > > > > You might consider whether "ignore" means "silently ignore" or > > whether you want to give advice about logging. It seems probable > > that (because of the nature of ping) if you do suggest logging, = you > > also want to describe some form of thresholding or damping.____ > > > > __ __ > > > > __ __ > > > > To address Loa's concern...____ > > > > The TLV is from the optional range. It can be ignored if it is = not > > understood, and does not require to be included.____ > > > > Loa asserted that the document says that the TLV MUST be = included, > > but I don't find this in -02.____ > > > > Therefore, I think this is all fine.____ > > > > __ __ > > > > Adrian____ > > > > __ __ > > > > *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com > > ] > > *Sent:* 25 April 2015 05:50 > > *To:* adrian@olddog.co.uk > > *Cc:* Loa Andersson; t.petch; Ross Callon; mpls; > > mpls-chairs@tools.ietf.org ; > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > > = > > *Subject:* Re: [mpls] George can yu look at this - Re: end of = WGLC, > > RE: working group last call for > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01____ > > > > __ __ > > > > Hi Adrian, Tom, Loa,____ > > > > __ __ > > > > This extension is currently structured such that it allows for > > backwards compatibility (i.e., transit LSR not supporting this > > mechanism will not return "malformed request" ... because the = TLV is > > optional).____ > > > > __ __ > > > > The result is that this mechanism becomes a best effort = mechanism, > > and we will not get the full benefit until all LSRs along the = LSP > > (and other LSRs which could falsely receive the echo request) > > implements this extension.____ > > > > __ __ > > > > One way to allow the initiator LSR to determine whether or not = the > > responder LSR understood this TLV, and still keeping the = backwards > > compatibility, is that we keep the Reply Mode Order TLV as an > > optional TLV, but require (i.e., MUST) the responder LSR > > understanding this TLV to include the Reply Mode Order TLV in = the > > echo reply, potentially with result of parsing/handling that = TLV.____ > > > > __ __ > > > > However, that's probably not the path we want to go, as all (or > > most) optional TLVs will have to do something similar (i.e., = include > > the same TLV in the echo reply). This will quickly result in = echo > > reply packet bloat ... we should prevent that as echo reply = usually > > tends to include more information (ILS, DSMAP/DDMAP per nexthop, > > multipath Sub-TLVs per nexthop, etc).____ > > > > __ __ > > > > To me, the right way to solve this is to create a capability TLV > > that mandates the reponder LSR to return which features it = supports > > in bitmaps or something very compact. But this can be done in a > > separate effort/draft.____ > > > > __ __ > > > > In short, my preference for this document is to go as is (after > > incorporating comments from Tom).____ > > > > __ __ > > > > Thanks!____ > > > > __ __ > > > > -Nobo____ > > > > __ __ > > > > On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel = > > wrote:____ > > > > Thanks Loa, > > > > You captured it. The edge cases need to be nailed down. > > > > Personally I have no particular preference for where it is = nailed, > > but I don't > > want it flapping in the breeze. > > > > A > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org > > ] On Behalf Of Loa Andersson > > > Sent: 23 April 2015 13:59 > > > To: t.petch; Nobo Akiya > > > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org > > ; > > draft-ietf-mpls-lsp-ping-reply- > > > mode-simple@tools.ietf.org = > > > Subject: [mpls] George can yu look at this - Re: end of WGLC, = RE: > > working > > group > > > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > Tom, > > > > > > The question you and Adrian asks is what to do if the Reply = Mode > > > Order TLV is missing. > > > > > > There is something fishy here, I'd like George to look at = this. > > > > > > The LSP Ping design says that TLVs from this range may be = silentsly > > > dropped, my take is that we don't need to specify anything = more > > > than that. > > > > > > Now, we say that it MUST be present, and after thinking = around a bit > > > I wonder if the TLV should be assigned from the mandatory = range > > instead? > > > > > > Or if the MUST be present means that the message will be = malformed if > > > it is not there, and the message should be discarded. > > > > > > OK - now I'm confused. > > > > > > /Loa > > > > > > On 2015-04-23 13:02, t.petch wrote: > > > > ---- Original Message ----- > > > > From: "Loa Andersson" > > > > > Sent: Wednesday, April 22, 2015 2:15 PM > > > > > > > >> Tom, > > > >> > > > >> On 2015-04-20 00:07, Nobo Akiya wrote: > > > >>> > > > >>> > > > >>> Yes but ... I think that it is a change of meaning. = Is is > > > > enough just > > > >>> to ignore the TLV or should the whole PDU be = discarded? > > I find > > > > it > > > >>> difficult to know but don't feel strongly about that > > choice so > > > > will go > > > >>> with what you suggest. > > > >>> > > > >>> > > > >> > > > >> So I don't misunderstand what you are saying. It seems to = me > > like the > > > >> comments made by Adrian and you actually requires a = "change of > > > > meaning", > > > >> that is kind of essence of a "comment", right? > > > >> > > > >> As for what to do with if the TLV is not recognized, it is > > > >> intentionally requested from a space where it can be = silently > > dropped > > > >> (i.e. "ignored"). > > > >> > > > >> The new TLV Type value should be assigned from the = range > > > >> (32768-49161) specified in [RFC4379] section 3 that > > allows the TLV > > > >> type to be silently dropped if not recognized. > > > >> > > > >> Type Meaning Reference > > > >> ---- ------- --------- > > > >> TBD1 Reply Mode Order TLV this = document > > > >> > > > >> What is it that I miss? > > > > > > > > Nothing serious. My initial thought was to echo Adrian, = that, > > at least > > > > in this context, there should be an indication what to do = if a > > MUST or > > > > SHOULD was violated without just then having a clear sense = of > > what it > > > > should be instead. > > > > > > > > The I-D did require (MUST) one entry in the TLV and wanted = (SHOULD) > > > > more. Adding what to do if that did not happen I was = seeing as > > > > clarification. I then read Nobo as proposing going a bit > > further saying > > > > requires (MUST) one or more. Which might lead to boxes = taking a > > > > simplistic approach and always putting in the new TLV with = a single > > > > entry and ignoring the traditional TLV. Not a problem just = a > > change > > > > from what others might think that they have consented to. > > > > > > > > On the question of what to do when the rules are violated, > > again I did > > > > not initially think of what the action should be. On > > reflection, I am > > > > still unsure. I understand that the Reply Mode Order TLV = is > > optional > > > > and so can be ignored when not understood; that's fine. = But if > > it is > > > > understood and can be seen to be defective, should the box = with > > that > > > > knowledge discard just that TLV and accept the remainder of = the > > message? > > > > Or should it argue that if this TLV is defective, then = likely > > the rest > > > > is as well and should be ignored? I am unsure. > > > > > > > > If there is scope for a breach of security, or taking a hit = in > > > > performance, then ignore is the right policy. If the > > requirement is to > > > > get as much data as possible from a failing network, then = use > > it is the > > > > right policy. As long as the I-D is clear, I am not too = fussed > > which > > > > way it goes. I am content with the changes that Nobo has = proposed. > > > > > > > > Tom Petch > > > > > > > >> /Loa > > > >> > > > >> -- > > > >> > > > >> > > > >> Loa Andersson email: > > loa@mail01.huawei.com > > > >> Senior MPLS Expert loa@pi.nu > > > >> Huawei Technologies (consultant) phone: +46 739 81 21 = 64 > > > > > > > > > > > > -- > > > > > > > > > Loa Andersson = email:loa@mail01.huawei.com > > > > Senior MPLS Expertloa@pi.nu > > > Huawei Technologies (consultant) phone:+46 739 81 21 64 > > > > > > > _______________________________________________ > > > mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls____ > > > > __ __ > > > > >=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 From nobody Tue Apr 28 09:01:54 2015 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 7C6601ACEC0 for ; Tue, 28 Apr 2015 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ioSysX3UJb03 for ; Tue, 28 Apr 2015 09:01:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E811ACF24 for ; Tue, 28 Apr 2015 09:01:17 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 2A273CCED9AAA; Tue, 28 Apr 2015 16:01:10 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t3SG1Bns007892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 12:01:11 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 12:01:11 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "mpls@ietf.org" Thread-Topic: Review of draft-hao-mpls-ip-hard-pipe-01 Thread-Index: AdCBzIr6SsqnVpHOQqOMLXhwS/KfnQ== Date: Tue, 28 Apr 2015 16:01:10 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D948330B5@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Nevil Brownlee Subject: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 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, 28 Apr 2015 16:01:52 -0000 Dear all, I was asked to review this draft which is intended to be handled in the Ind= ependent Stream. Below are my comments to the authors.=20 Members of this list can also provide comments to the authors. Please copy = the Independent Submission Editorial Board at the following address: rfc-ise@rfc-editor.org Regards, Mustapha. ---------------------------- https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 1. Overall comment: This document describes how a guaranteed bandwidth service can be deployed = in a MPLS network by partitioning the network resources into two managed la= yers, referred to as strata. The guaranteed service layer is referred to a= s "Hard Pipe" stratum. The management of the resources and the placement of the MPLS tunnels and s= ervices into the "Hard Pipe" stratum are performed with a management syste= m. Thus the transport and service labels are static but this important info= rmation has not been stated upfront in the document. Only in section 6 that= MPLS-TP was mentioned. Furthermore, the reference to T-LDP signaled labels= in Section 3 adds to the confusion.=20 I propose that the Introduction and Scope sections be explicit about the fr= amework used to achieve the "Hard Pipe" stratum, that is by means of a mana= gement system and static transport and service labels.=20 In fact, I would think the document value would be in describing more detai= ls of the framework including configuration aspects, resource and service m= anagement including resilience. These aspects have not been sufficiently ad= dressed and the focus was more on how to use MPLS labels to differentiate t= he two strata. 2. Section 1.1 - Scope: As part of the second bullet, I cannot find in the document how a router pr= otects the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" strat= um overbooks a link. Having a separate label for the guaranteed service is = not sufficient. The authors should describe if LSP pre-emption and/or QoS m= arkings are used to differentiate the treatment across the strata. 3. Section 3: If the document objective is to describe the framework used, then this sect= ion should begin by explaining the initial configuration performed by the N= MS to lay the ground for the building of the two stratums. This includes th= e partitioning of the links, the assignment of transport and service label = ranges in the routers, the overbooking strategy, etc. Then, you can discuss how a guaranteed service is configured in the network= using static transport labels and static service labels. This should cover= the placement of the working and backup paths since Section 6 mentions MPL= S-TP protection is used. Next, a description of how the transport LSP and service are monitored for = continuity and defects.=20 Finally, the behavior when resources are overbooked and what services are p= re-empted or degraded should be described. ------------------------------------ From nobody Tue Apr 28 10:43:38 2015 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 133751A8A79 for ; Tue, 28 Apr 2015 10:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 TgEoBhAGKrQD for ; Tue, 28 Apr 2015 10:43:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD521A8A57 for ; Tue, 28 Apr 2015 10:43:35 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 28 Apr 2015 17:43:16 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.01.0154.018; Tue, 28 Apr 2015 17:43:16 +0000 From: Ronald Bonica To: "mpls@ietf.org" Thread-Topic: SDN/MPLS 2015 CFP Announcement Thread-Index: AdCB2szHSz5mXbPJT/K/nsEKNENutQ== Date: Tue, 28 Apr 2015 17:43:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(40100003)(107886001)(2351001)(229853001)(46102003)(110136001)(122556002)(2900100001)(54356999)(2501003)(50986999)(92566002)(450100001)(87936001)(62966003)(86362001)(2656002)(77156002)(15975445007)(102836002)(74316001)(33656002)(99286002)(76576001)(66066001)(15188555004)(19580405001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 0560A2214D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2015 17:43:16.4164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: [mpls] SDN/MPLS 2015 CFP Announcement 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, 28 Apr 2015 17:43:37 -0000 Call for Presentation Abstract Proposals Now up at http://www.isocore.com/2= 015/cfp.htm Submissions Deadline: May 11 Isocore's 2015 International Conference, the 18th Annual event on new netwo= rking technologies will be held November 15-18, 2015, in Washington, DC. This year, the overarching themes of the conference will be on Softwarizati= on, Programmatic Control, Security and Operational Experience of the Networ= k and Services in Cloud, Data Centers and DevOps environments. The conference Program Committee is soliciting presentation proposals seeki= ng original and unpublished work to continue the tradition initiated by thi= s conference in 1998 of covering cutting-edge topics. Presentations address= ing new technologies and operational experience are solicited from network = equipment vendors, service providers, the research community, government ag= encies, and enterprise users. Please submit your abstracts to cfp2015@isocore.com Regards, Ron Bonica From nobody Tue Apr 28 10:57:27 2015 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 E0B641A87C7 for ; Tue, 28 Apr 2015 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 y_lZPUVFisqm for ; Tue, 28 Apr 2015 10:57:21 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CAF1A1AB3 for ; Tue, 28 Apr 2015 10:57:21 -0700 (PDT) Authentication-Results: olddog.co.uk; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.148.16; Tue, 28 Apr 2015 17:57:01 +0000 Message-ID: <048c01d081dc$82451ca0$4001a8c0@gateway.2wire.net> From: t.petch To: , 'Loa Andersson' , 'Nobo Akiya' References: <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> <553F8193.8040506@pi.nu> <011c01d081bb$843f9010$8cbeb030$@olddog.co.uk> Date: Tue, 28 Apr 2015 18:55:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB4PR05CA0008.eurprd05.prod.outlook.com (25.160.40.18) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(41574002)(377424004)(13464003)(51444003)(66654002)(51704005)(252514010)(230783001)(40100003)(122386002)(84392001)(87976001)(15975445007)(77096005)(23676002)(1556002)(77156002)(50466002)(62966003)(1456003)(61296003)(93886004)(47776003)(66066001)(5001770100001)(46102003)(19580405001)(62236002)(14496001)(19580395003)(50986999)(33646002)(44716002)(50226001)(92566002)(86362001)(42186005)(76176999)(81816999)(81686999)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2015 17:57:01.3822 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: 'Ross Callon' , 'mpls' , mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 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, 28 Apr 2015 17:57:26 -0000 Me too Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "'Loa Andersson'" ; "'Nobo Akiya'" Cc: "'t.petch'" ; "'Ross Callon'" ; "'mpls'" ; ; Sent: Tuesday, April 28, 2015 2:59 PM I'm OK with what Nobo said. A > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 28 April 2015 13:48 > To: Nobo Akiya; adrian@olddog.co.uk > Cc: t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp- > ping-reply-mode-simple@tools.ietf.org > Subject: Re: [mpls] George can yu look at this - Re: end of WGLC, RE: working > group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > Nobo, > > I think this is fine. > > Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed. > > Bullet 6-9 describe the mal-formednesses. > > Is it "invalid" rather than "not valid"? > > Tom and Adrian are you OK with this? > > /Loa > > On 2015-04-27 03:36, Nobo Akiya wrote: > > Hi Adrian, > > > > Many thanks for very helpful comments. I have carefully read your > > comments and made modifications to section 3.2 in my private copy. > > > > [OLD] > > > > 1. The Reply Mode Order TLV MAY be included in MPLS echo request. > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. > > > > 3. The Reply Mode field of an MPLS echo request MUST be set to a > > valid value even when supplying the Reply Mode Order TLV. The > > initiator LSR SHOULD set the Reply Mode field of MPLS echo > > request to a value that corresponds to a return path which most > > likely to be available, in case the responder LSR does not > > understand the Reply Mode Order TLV. > > > > 4. If a responder LSR understands the Reply Mode Order TLV but the > > TLV is not valid (due to conditions described in the items 6, 8 > > and 9 immediately below), then the responder LSR MUST only use > > the value described in the Reply Mode field of received MPLS echo > > request. > > > > 5. If a responder LSR understands the Reply Mode Order TLV and the > > TLV is valid, then the responder LSR MUST consider the Reply Mode > > values described in the TLV and MUST NOT use the value described > > in the Reply Mode field of received MPLS echo request. In other > > words, a valid Reply Mode Order TLV overrides the value specified > > in the Reply Mode field of received MPLS echo request. > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode value, > > and SHOULD contain at least two Reply Mode values. > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > multiple times) in the Reply Mode Order TLV. > > > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included > > more than once in the Reply Mode Order TLV. However, in such > > case a Reply Path TLV MUST be included for all instances of the > > Reply Mode value 5 included in the Reply Mode Order TLV. In > > other words, 3 instances of the Reply Mode value 5 in the Reply > > Mode Order TLV will require 3 instances of the Reply Path TLVs. > > > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the > > Reply Mode Order TLV. > > > > If a responder LSR receives a Reply Mode Order TLV which does not > > comply to the rules described above, then the responder LSR MUST > > ignore the Reply Mode Order TLV. > > > > > > [NEW] > > > > 1. The Reply Mode Order TLV MUST NOT be included in MPLS echo reply. > > If the initiator LSR receives an MPLS echo reply with the Reply > > Mode Order TLV, the initiator LSR MUST ignore the whole Reply > > Mode Order TLV and MUST only use the value from the Reply Mode > > field of the received MPLS echo reply. It may be beneficial for > > implementations to provide counters and/or loggings, with > > appropriate log dampening, to record this error case. > > > > 2. The Reply Mode Order TLV MAY be included in MPLS echo request. > > > > 3. The Reply Mode field of an MPLS echo request MUST be set to a > > valid value even when supplying the Reply Mode Order TLV. The > > initiator LSR SHOULD set the Reply Mode field of MPLS echo > > request to a value that corresponds to a return path which most > > likely to be available, in case the responder LSR does not > > understand the Reply Mode Order TLV. > > > > 4. If a responder LSR understands the Reply Mode Order TLV but the > > TLV is not valid (due to conditions described in the items 6, 7, > > 8 and 9 immediately below), then the responder LSR MUST ignore > > the whole Reply Mode Order TLV and MUST only use the value from > > the Reply Mode field of the received MPLS echo request. It may > > be beneficial for implementations to provide counters and/or > > loggings, with appropriate log dampening, to record this error > > case. > > > > 5. If a responder LSR understands the Reply Mode Order TLV and the > > TLV is valid, then the responder LSR MUST consider the Reply Mode > > values described in the TLV and MUST NOT use the value described > > in the Reply Mode field of received MPLS echo request. In other > > words, a valid Reply Mode Order TLV overrides the value specified > > in the Reply Mode field of received MPLS echo request. > > > > 6. Reply Mode Order TLV MUST contain at least one Reply Mode value. > > > > 7. A Reply Mode value, except for Reply Mode value 5 (Reply via > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear > > multiple times) in the Reply Mode Order TLV. > > > > 8. The Reply Mode value 5 (Reply via Specified Path) MAY be included > > more than once in the Reply Mode Order TLV. However, in such > > case a Reply Path TLV MUST be included for all instances of the > > Reply Mode value 5 included in the Reply Mode Order TLV. In > > other words, 3 instances of the Reply Mode value 5 in the Reply > > Mode Order TLV will require 3 instances of the Reply Path TLVs. > > > > 9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the > > Reply Mode Order TLV. > > > > > > Thanks! > > > > -Nobo > > > > > > On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel > > wrote: > > > > Hi Nobo,____ > > > > __ __ > > > > Let's come back to my original review comments.____ > > > > __ __ > > > > > Section 3.2 gives clear instructions and guidance on forming the Reply____ > > > > > Mode Order TLV but not on what to do if a received TLV deviates from > the____ > > > > > MUST and MUST NOT instructions. Options might include ignoring > errors,____ > > > > > ignoring the TLV, ignoring the message. But presumably not sending > an____ > > > > > error response (because how would you know how to send it?)____ > > > > __ __ > > > > You responded:____ > > > > __ __ > > > > | [NOBO] That’s a good point. What the document really state is that > > The____ > > > > | Reply Mode value 5 (Reply via Specified Path) MAY be repeated but > > all ____ > > > > | other Reply Mode values MUST NOT be repeated. Will update the____ > > > > | document to make it clear.____ > > > > __ __ > > > > That's a fine thing to say, but doesn't answer my question about how > > an implementation is supposed to behave when a received Reply Mode > > Order TLV is "malformed".____ > > > > __ __ > > > > You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02. Section > > 3.2 swapped the order of points 4 and 5, and enhanced the text to > > read...____ > > > > __ __ > > > > 4.If a responder LSR understands the Reply Mode Order TLV but the____ > > > > TLV is not valid (due to conditions described in the items 6, 8____ > > > > and 9 immediately below), then the responder LSR MUST only use____ > > > > the value described in the Reply Mode field of received MPLS echo____ > > > > request.____ > > > > __ __ > > > > That seems to cover most bases. Good.____ > > > > It might also be helpful to say "...the responder LSR MUST silently > > ignore the whole Reply Mode Order TLV and MUST only use the value > > from the Reply Mode field of the received MPLS echo request."____ > > > > Saying this helps clarify the behavior.____ > > > > __ __ > > > > The only things I don't find covered are:____ > > > > __ __ > > > > a. how to handle a violation of the seventh point____ > > > > __ __ > > > > 7.A Reply Mode value, except for Reply Mode value 5 (Reply via____ > > > > Specified Path), MUST NOT be repeated (i.e., MUST NOT appear____ > > > > multiple times) in the Reply Mode Order TLV.____ > > > > __ __ > > > > I think you can address this by adding "7" to the list of conditions > > in point 4.____ > > > > __ __ > > > > b. how to handle a violation of the second point____ > > > > __ __ > > > > 2. The Reply Mode Order TLV MUST NOT be included in MPLS echo > reply.____ > > > > __ __ > > > > I think this will need additional text.____ > > > > __ __ > > > > I note that after the numbered bullets you also now have the > > following text...____ > > > > __ __ > > > > If a responder LSR receives a Reply Mode Order TLV which does not____ > > > > comply to the rules described above, then the responder LSR MUST____ > > > > ignore the Reply Mode Order TLV.____ > > > > __ __ > > > > This is better than point 4 and covers everything.____ > > > > You might consider whether "ignore" means "silently ignore" or > > whether you want to give advice about logging. It seems probable > > that (because of the nature of ping) if you do suggest logging, you > > also want to describe some form of thresholding or damping.____ > > > > __ __ > > > > __ __ > > > > To address Loa's concern...____ > > > > The TLV is from the optional range. It can be ignored if it is not > > understood, and does not require to be included.____ > > > > Loa asserted that the document says that the TLV MUST be included, > > but I don't find this in -02.____ > > > > Therefore, I think this is all fine.____ > > > > __ __ > > > > Adrian____ > > > > __ __ > > > > *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com > > ] > > *Sent:* 25 April 2015 05:50 > > *To:* adrian@olddog.co.uk > > *Cc:* Loa Andersson; t.petch; Ross Callon; mpls; > > mpls-chairs@tools.ietf.org ; > > draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org > > > > *Subject:* Re: [mpls] George can yu look at this - Re: end of WGLC, > > RE: working group last call for > > draft-ietf-mpls-lsp-ping-reply-mode-simple-01____ > > > > __ __ > > > > Hi Adrian, Tom, Loa,____ > > > > __ __ > > > > This extension is currently structured such that it allows for > > backwards compatibility (i.e., transit LSR not supporting this > > mechanism will not return "malformed request" ... because the TLV is > > optional).____ > > > > __ __ > > > > The result is that this mechanism becomes a best effort mechanism, > > and we will not get the full benefit until all LSRs along the LSP > > (and other LSRs which could falsely receive the echo request) > > implements this extension.____ > > > > __ __ > > > > One way to allow the initiator LSR to determine whether or not the > > responder LSR understood this TLV, and still keeping the backwards > > compatibility, is that we keep the Reply Mode Order TLV as an > > optional TLV, but require (i.e., MUST) the responder LSR > > understanding this TLV to include the Reply Mode Order TLV in the > > echo reply, potentially with result of parsing/handling that TLV.____ > > > > __ __ > > > > However, that's probably not the path we want to go, as all (or > > most) optional TLVs will have to do something similar (i.e., include > > the same TLV in the echo reply). This will quickly result in echo > > reply packet bloat ... we should prevent that as echo reply usually > > tends to include more information (ILS, DSMAP/DDMAP per nexthop, > > multipath Sub-TLVs per nexthop, etc).____ > > > > __ __ > > > > To me, the right way to solve this is to create a capability TLV > > that mandates the reponder LSR to return which features it supports > > in bitmaps or something very compact. But this can be done in a > > separate effort/draft.____ > > > > __ __ > > > > In short, my preference for this document is to go as is (after > > incorporating comments from Tom).____ > > > > __ __ > > > > Thanks!____ > > > > __ __ > > > > -Nobo____ > > > > __ __ > > > > On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel > > wrote:____ > > > > Thanks Loa, > > > > You captured it. The edge cases need to be nailed down. > > > > Personally I have no particular preference for where it is nailed, > > but I don't > > want it flapping in the breeze. > > > > A > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org > > ] On Behalf Of Loa Andersson > > > Sent: 23 April 2015 13:59 > > > To: t.petch; Nobo Akiya > > > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org > > ; > > draft-ietf-mpls-lsp-ping-reply- > > > mode-simple@tools.ietf.org > > > Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: > > working > > group > > > last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01 > > > > > > Tom, > > > > > > The question you and Adrian asks is what to do if the Reply Mode > > > Order TLV is missing. > > > > > > There is something fishy here, I'd like George to look at this. > > > > > > The LSP Ping design says that TLVs from this range may be silentsly > > > dropped, my take is that we don't need to specify anything more > > > than that. > > > > > > Now, we say that it MUST be present, and after thinking around a bit > > > I wonder if the TLV should be assigned from the mandatory range > > instead? > > > > > > Or if the MUST be present means that the message will be malformed if > > > it is not there, and the message should be discarded. > > > > > > OK - now I'm confused. > > > > > > /Loa > > > > > > On 2015-04-23 13:02, t.petch wrote: > > > > ---- Original Message ----- > > > > From: "Loa Andersson" > > > > > Sent: Wednesday, April 22, 2015 2:15 PM > > > > > > > >> Tom, > > > >> > > > >> On 2015-04-20 00:07, Nobo Akiya wrote: > > > >>> > > > >>> > > > >>> Yes but ... I think that it is a change of meaning. Is is > > > > enough just > > > >>> to ignore the TLV or should the whole PDU be discarded? > > I find > > > > it > > > >>> difficult to know but don't feel strongly about that > > choice so > > > > will go > > > >>> with what you suggest. > > > >>> > > > >>> > > > >> > > > >> So I don't misunderstand what you are saying. It seems to me > > like the > > > >> comments made by Adrian and you actually requires a "change of > > > > meaning", > > > >> that is kind of essence of a "comment", right? > > > >> > > > >> As for what to do with if the TLV is not recognized, it is > > > >> intentionally requested from a space where it can be silently > > dropped > > > >> (i.e. "ignored"). > > > >> > > > >> The new TLV Type value should be assigned from the range > > > >> (32768-49161) specified in [RFC4379] section 3 that > > allows the TLV > > > >> type to be silently dropped if not recognized. > > > >> > > > >> Type Meaning Reference > > > >> ---- ------- --------- > > > >> TBD1 Reply Mode Order TLV this document > > > >> > > > >> What is it that I miss? > > > > > > > > Nothing serious. My initial thought was to echo Adrian, that, > > at least > > > > in this context, there should be an indication what to do if a > > MUST or > > > > SHOULD was violated without just then having a clear sense of > > what it > > > > should be instead. > > > > > > > > The I-D did require (MUST) one entry in the TLV and wanted (SHOULD) > > > > more. Adding what to do if that did not happen I was seeing as > > > > clarification. I then read Nobo as proposing going a bit > > further saying > > > > requires (MUST) one or more. Which might lead to boxes taking a > > > > simplistic approach and always putting in the new TLV with a single > > > > entry and ignoring the traditional TLV. Not a problem just a > > change > > > > from what others might think that they have consented to. > > > > > > > > On the question of what to do when the rules are violated, > > again I did > > > > not initially think of what the action should be. On > > reflection, I am > > > > still unsure. I understand that the Reply Mode Order TLV is > > optional > > > > and so can be ignored when not understood; that's fine. But if > > it is > > > > understood and can be seen to be defective, should the box with > > that > > > > knowledge discard just that TLV and accept the remainder of the > > message? > > > > Or should it argue that if this TLV is defective, then likely > > the rest > > > > is as well and should be ignored? I am unsure. > > > > > > > > If there is scope for a breach of security, or taking a hit in > > > > performance, then ignore is the right policy. If the > > requirement is to > > > > get as much data as possible from a failing network, then use > > it is the > > > > right policy. As long as the I-D is clear, I am not too fussed > > which > > > > way it goes. I am content with the changes that Nobo has proposed. > > > > > > > > Tom Petch > > > > > > > >> /Loa > > > >> > > > >> -- > > > >> > > > >> > > > >> Loa Andersson email: > > loa@mail01.huawei.com > > > >> Senior MPLS Expert loa@pi.nu > > > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > > > > > > -- > > > > > > > > > Loa Andersson email:loa@mail01.huawei.com > > > > Senior MPLS Expertloa@pi.nu > > > Huawei Technologies (consultant) phone:+46 739 81 21 64 > > > > > > > _______________________________________________ > > > 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 Tue Apr 28 11:58:30 2015 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 529091A008F for ; Tue, 28 Apr 2015 11:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 R0jOSJb1JETn for ; Tue, 28 Apr 2015 11:58:27 -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 F05BF1A007E for ; Tue, 28 Apr 2015 11:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6247; q=dns/txt; s=iport; t=1430247503; x=1431457103; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PrGozEz7jhNBYG5dHfItXFW84Y0u7X+WnR8jz+9ryGA=; b=MQHvoCz6Hgw3+9Y6N4ax5ODvLHoxUknSQMJnbtpz886LUiDEFXGZNFCH toYqOlhks8U1jp6IOUmCd3WZePXoYKpXwtYUqLPVnok8iDCMx2lFqCqHb T2hEPfWqV/32wPcvZMeqA49Vnjtf6ZU93O5c6K9fk7GuvAzd34eb6Co2h Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DSBAAC1z9V/4oNJK1cgwxTXAXGLGYJgVOGBAKBOzgUAQEBAQEBAYEKhCABAQEDAW4LBQsCAQgYLjIlAgQOBQkFiBUIDcc4AQEBAQEBAQEBAQEBAQEBAQEBGos4gT2BLoIaB4MXgRYFj0KCI4F0gTeHFIEjg0mCcIZmg1qDUCOCBw0PgVFvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,665,1422921600"; d="asc'?scan'208";a="145343803" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2015 18:58:23 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3SIwN26019069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 18:58:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.22]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 13:58:22 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: [mpls] [Editorial Errata Reported] RFC7510 (4350) Thread-Index: AQHQgSfbd29X5R9FSUyEbRgAx5Ve851iZF2A///tcgCAAF8RgIAAazmA Date: Tue, 28 Apr 2015 18:58:21 +0000 Message-ID: <6A69A0A7-6C76-4AB3-94A6-0D123DFE8459@cisco.com> References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> In-Reply-To: <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.62] Content-Type: multipart/signed; boundary="Apple-Mail=_C89CDF5F-A6F4-468F-9C06-882E946AF418"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "Black, David" , Ross Callon , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 28 Apr 2015 18:58:29 -0000 --Apple-Mail=_C89CDF5F-A6F4-468F-9C06-882E946AF418 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Adrian, Thanks for the additional context. Note that I did not object any = changes made to the registry itself (although I still think that = pointing to RFC 7510 is incorrect), only to the errata. Modifying the = data plane document to include an IANA action for BGP sounds off. In other words, I see two problems with the approach from the errata (or = really two sides of the same issue): 1. RFC 7510 specifies the data plane encapsulation, and not the BGP = signaling. As such, it does not make for a good reference for the BGP = Tunnel Encapsulation Attribute Tunnel Type 13. 2. Existing entries in the =93BGP Tunnel Encapsulation Attribute Tunnel = Types=94 registry point to the documents which specify how that = attribute is used. For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to = RFC 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The = value 4 points to RFC 5566 and not to RFC4302, RFC4303. There is another technical problem with the current approach: RFC 7510 = specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS = respectively. To which one of these two does the BGP Tunnel = Encapsulation Attribute Tunnel Type value of 13 correspond to? Do you = actually need two Types? Further, do you need to consider the LB from = RFC 5640? Please see more inline. > On Apr 28, 2015, at 8:34 AM, Adrian Farrel = wrote: >=20 > Hi Carlos, >=20 > Since I raised the issue... >=20 > The text that was omitted was agreed for inclusion between the RFC = Editor, IANA, > and responsible AD before the publication of the RFC, but was fumbled = by the RFC > Editor. >=20 > The RFC Editor requested this report to be submitted to resolve this = issue, and > I checked with the ADs before I posted it. >=20 > The problem it solves is that the existing registry entry points at an = I-D that > caused the allocation of the code point, but that I-D is not a good = reference > for explaining what "MPLS in UDP" is. This document provides a better > indication. >=20 The reference should not explain what =93MPLS in UDP=94 is. The = reference should explain what is the BGP Tunnel Encapsulation Attribute = Tunnel Type 13 for MPLS in UDP. > You said... >=20 >> RFC 7510 states that it =B3specifies an IP-based encapsulation for = MPLS, >> called MPLS-in-UDP=B2 but there is no mention to the specification of = any >> signaling associated to setting up said encapsulation. In other = words, it >> self-concerns itself with the encap. >=20 > That is correct. And there is no attempt to define any signaling or = add any > mention of signaling to this document. >=20 > This is not a forward pointer, but a request to include a backward = pointer. That > is, it is a request to update the entry that already exists in the = registry with > a pointer to this document so that people can see what "MPLS in UDP" = is when > they encounter the value in the registry. >=20 I understand. My comment is that the reference should not be to =93MPLS = in UDP=94. The same way that the Type 1 does not point to RFC 3931. >> Further, there is no mention in RFC 7510 of =B3BGP=B2 and no = reference to RFC >> 5512. For a document specifying a BGP Tunnel Encapsulation Attribute >> Tunnel Type, I=B9d expect a reference (normative) to RFC 5512 (such = as in >> RFC 5566). >=20 > This document does not specify a BGP Tunnel Encapsulation Attribute = and there is > no request for it to make such a specification. >=20 > References could be included, but they would be pointless because = there is > nothing to hook the references to. The *only* change requested is to = attach a > pointer to the existing entry in the registry. >=20 >> Lastly, the IANA page points to a different document: >> http://www.iana.org/assignments/bgp-parameters/bgp- >> parameters.xhtml#tunnel- >> types >>=20 >> Value Name Reference >> 13 MPLS in UDP Encapsulation [draft-ietf-l3vpn-end-system] >=20 > Yes. > Have you read that document? >=20 > This errata report does not request removal of that reference. It = requests the > addition of an extra reference. How is that a problem? >=20 I see not problem with the addition of a reference in an IANA registry. I do see a problem with modifying the RFC by way of an errata. > For those of you who have read around the subject, you may recall a = prolonged > series of emails across a number of mailing lists where a number of = different > new I-Ds were proposed to give a more substantive reference for the = tunnel type. > This errata report solves that issue without needing further = documents. >=20 Can the reference be added without the Erratum? That seems possible to = me. > You may also like to note that we are dealing with a FCFS registry = where the > documents supplied as references do not always provide a good = explanation. Is it > better to leave the registry with a poor reference, or to add a = somewhat better > one? >=20 >> Net-net, this RFC is not the right place to be a pointer for this >> assignment. >=20 > I respect your right to hold that opinion, but I don't think you have = given any > valid reasons for holding it. Perhaps this lack is caused by = unfamiliarity with > FCFS registries. >=20 I am happy to be educated. I re-read the FCFS definition form RFC 5226. = Why does RFC 7510 need to be modified for this? Thanks, =97 Carlos. > Adrian >=20 --Apple-Mail=_C89CDF5F-A6F4-468F-9C06-882E946AF418 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlU/2E0ACgkQtfDPGTp3USxrsgCeLpS6sy4h+Ub6FIiu5tH63Hom kLoAn2eiNdHdAN5Fq1zZ6b3ocA7WoJKR =O/i2 -----END PGP SIGNATURE----- --Apple-Mail=_C89CDF5F-A6F4-468F-9C06-882E946AF418-- From nobody Wed Apr 29 00:21:12 2015 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 813DC1AD49D for ; Wed, 29 Apr 2015 00:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 DiKpOe_x_ORn for ; Wed, 29 Apr 2015 00:21:09 -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 A2A9C1ACF59 for ; Wed, 29 Apr 2015 00:21:08 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C42571801127; Wed, 29 Apr 2015 09:21:06 +0200 (CEST) Message-ID: <55408663.1070906@pi.nu> Date: Wed, 29 Apr 2015 09:21:07 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 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, 29 Apr 2015 07:21:10 -0000 Mustapha, in line please. On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: > Dear all, > I was asked to review this draft which is intended to be handled in the Independent Stream. Below are my comments to the authors. > > Members of this list can also provide comments to the authors. Please copy the Independent Submission Editorial Board at the following address: > rfc-ise@rfc-editor.org > > Regards, > Mustapha. > ---------------------------- > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 > > 1. Overall comment: > This document describes how a guaranteed bandwidth service can be deployed in a MPLS network by partitioning the network resources into two managed layers, referred to as strata. The guaranteed service layer is referred to as "Hard Pipe" stratum. > > The management of the resources and the placement of the MPLS tunnels and services into the "Hard Pipe" stratum are performed with a management system. Thus the transport and service labels are static but this important information has not been stated upfront in the document. Do you have a a definition of "static labels" that we can refer to? /Loa Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference to T-LDP signaled labels in Section 3 adds to the confusion. > > I propose that the Introduction and Scope sections be explicit about the framework used to achieve the "Hard Pipe" stratum, that is by means of a management system and static transport and service labels. > > In fact, I would think the document value would be in describing more details of the framework including configuration aspects, resource and service management including resilience. These aspects have not been sufficiently addressed and the focus was more on how to use MPLS labels to differentiate the two strata. > > 2. Section 1.1 - Scope: > As part of the second bullet, I cannot find in the document how a router protects the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum overbooks a link. Having a separate label for the guaranteed service is not sufficient. The authors should describe if LSP pre-emption and/or QoS markings are used to differentiate the treatment across the strata. > > 3. Section 3: > If the document objective is to describe the framework used, then this section should begin by explaining the initial configuration performed by the NMS to lay the ground for the building of the two stratums. This includes the partitioning of the links, the assignment of transport and service label ranges in the routers, the overbooking strategy, etc. > > Then, you can discuss how a guaranteed service is configured in the network using static transport labels and static service labels. This should cover the placement of the working and backup paths since Section 6 mentions MPLS-TP protection is used. > > Next, a description of how the transport LSP and service are monitored for continuity and defects. > > Finally, the behavior when resources are overbooked and what services are pre-empted or degraded should be described. > ------------------------------------ > > _______________________________________________ > 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 Wed Apr 29 01:40:50 2015 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 485A51A1B05; Wed, 29 Apr 2015 01:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JoPoAXw8DHFH; Wed, 29 Apr 2015 01:40:47 -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 1BAB01A700F; Wed, 29 Apr 2015 01:40:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRY48269; Wed, 29 Apr 2015 08:40:43 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Apr 2015 09:40:43 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 29 Apr 2015 16:40:34 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" , Adrian Farrel Thread-Topic: [mpls] [Editorial Errata Reported] RFC7510 (4350) Thread-Index: AQHQgSfZ/DAmCRMKgEyTJeq3ChnB/p1hinCAgAAw3wCAABujgIAAazmAgAFpEwA= Date: Wed, 29 Apr 2015 08:40:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08329BF2@NKGEML512-MBS.china.huawei.com> References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> <6A69A0A7-6C76-4AB3-94A6-0D123DFE8459@cisco.com> In-Reply-To: <6A69A0A7-6C76-4AB3-94A6-0D123DFE8459@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "Black, David" , Ross Callon , "bess@ietf.org" , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 29 Apr 2015 08:40:49 -0000 Hi Carlos, > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, April 29, 2015 2:58 AM > To: Adrian Farrel > Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper.net; Lucy > yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro > Retana (aretana); George Swallow (swallow); mpls@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) >=20 > Hi, Adrian, >=20 > Thanks for the additional context. Note that I did not object any changes= made > to the registry itself (although I still think that pointing to RFC 7510 = is incorrect), > only to the errata. Modifying the data plane document to include an IANA = action > for BGP sounds off. >=20 > In other words, I see two problems with the approach from the errata (or = really > two sides of the same issue): >=20 > 1. RFC 7510 specifies the data plane encapsulation, and not the BGP signa= ling. As > such, it does not make for a good reference for the BGP Tunnel Encapsulat= ion > Attribute Tunnel Type 13. >=20 > 2. Existing entries in the "BGP Tunnel Encapsulation Attribute Tunnel Typ= es" > registry point to the documents which specify how that attribute is used. >=20 > For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to R= FC > 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The value= 4 > points to RFC 5566 and not to RFC4302, RFC4303. In fact, I had ever followed the above logic by specifying the BGP signalin= g for MPLS-in-UDP in a separate doc (https://tools.ietf.org/html/draft-xu-s= oftwire-encaps-udp-00) which has been moved to BESS WG (see https://tools.i= etf.org/html/draft-xu-bess-encaps-udp-00) recently. However... Best regards, Xiaohu > There is another technical problem with the current approach: RFC 7510 > specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS > respectively. To which one of these two does the BGP Tunnel Encapsulation > Attribute Tunnel Type value of 13 correspond to? Do you actually need two > Types? Further, do you need to consider the LB from RFC 5640? >=20 > Please see more inline. >=20 > > On Apr 28, 2015, at 8:34 AM, Adrian Farrel wrote: > > > > Hi Carlos, > > > > Since I raised the issue... > > > > The text that was omitted was agreed for inclusion between the RFC > > Editor, IANA, and responsible AD before the publication of the RFC, > > but was fumbled by the RFC Editor. > > > > The RFC Editor requested this report to be submitted to resolve this > > issue, and I checked with the ADs before I posted it. > > > > The problem it solves is that the existing registry entry points at an > > I-D that caused the allocation of the code point, but that I-D is not > > a good reference for explaining what "MPLS in UDP" is. This document > > provides a better indication. > > >=20 > The reference should not explain what "MPLS in UDP" is. The reference sho= uld > explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 for= MPLS > in UDP. >=20 > > You said... > > > >> RFC 7510 states that it =B3specifies an IP-based encapsulation for > >> MPLS, called MPLS-in-UDP=B2 but there is no mention to the > >> specification of any signaling associated to setting up said > >> encapsulation. In other words, it self-concerns itself with the encap. > > > > That is correct. And there is no attempt to define any signaling or > > add any mention of signaling to this document. > > > > This is not a forward pointer, but a request to include a backward > > pointer. That is, it is a request to update the entry that already > > exists in the registry with a pointer to this document so that people > > can see what "MPLS in UDP" is when they encounter the value in the regi= stry. > > >=20 > I understand. My comment is that the reference should not be to "MPLS in > UDP". The same way that the Type 1 does not point to RFC 3931. >=20 > >> Further, there is no mention in RFC 7510 of =B3BGP=B2 and no reference= to > >> RFC 5512. For a document specifying a BGP Tunnel Encapsulation > >> Attribute Tunnel Type, I=B9d expect a reference (normative) to RFC 551= 2 > >> (such as in RFC 5566). > > > > This document does not specify a BGP Tunnel Encapsulation Attribute > > and there is no request for it to make such a specification. > > > > References could be included, but they would be pointless because > > there is nothing to hook the references to. The *only* change > > requested is to attach a pointer to the existing entry in the registry. > > > >> Lastly, the IANA page points to a different document: > >> http://www.iana.org/assignments/bgp-parameters/bgp- > >> parameters.xhtml#tunnel- > >> types > >> > >> Value Name Reference > >> 13 MPLS in UDP Encapsulation [draft-ietf-l3vpn-end-system] > > > > Yes. > > Have you read that document? > > > > This errata report does not request removal of that reference. It > > requests the addition of an extra reference. How is that a problem? > > >=20 > I see not problem with the addition of a reference in an IANA registry. >=20 > I do see a problem with modifying the RFC by way of an errata. >=20 > > For those of you who have read around the subject, you may recall a > > prolonged series of emails across a number of mailing lists where a > > number of different new I-Ds were proposed to give a more substantive > reference for the tunnel type. > > This errata report solves that issue without needing further documents. > > >=20 > Can the reference be added without the Erratum? That seems possible to me= . >=20 > > You may also like to note that we are dealing with a FCFS registry > > where the documents supplied as references do not always provide a > > good explanation. Is it better to leave the registry with a poor > > reference, or to add a somewhat better one? > > > >> Net-net, this RFC is not the right place to be a pointer for this > >> assignment. > > > > I respect your right to hold that opinion, but I don't think you have > > given any valid reasons for holding it. Perhaps this lack is caused by > > unfamiliarity with FCFS registries. > > >=20 > I am happy to be educated. I re-read the FCFS definition form RFC 5226. W= hy > does RFC 7510 need to be modified for this? >=20 > Thanks, >=20 > - Carlos. >=20 > > Adrian > > From nobody Wed Apr 29 05:56:30 2015 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 0E97C1B2C9B; Wed, 29 Apr 2015 05:56:29 -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 zl9Bsq1jttnu; Wed, 29 Apr 2015 05:56:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 735031B2C82; Wed, 29 Apr 2015 05:56:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150429125627.15134.65678.idtracker@ietfa.amsl.com> Date: Wed, 29 Apr 2015 05:56:27 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc6374-udp-return-path-03.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, 29 Apr 2015 12:56:29 -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 : RFC6374 UDP Return Path Authors : Stewart Bryant Siva Sivabalan Sagar Soni Filename : draft-ietf-mpls-rfc6374-udp-return-path-03.txt Pages : 8 Date : 2015-04-29 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-ietf-mpls-rfc6374-udp-return-path/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc6374-udp-return-path-03 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc6374-udp-return-path-03 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 Apr 29 10:26:27 2015 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 7549B1ACD6A for ; Wed, 29 Apr 2015 10:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Dy0Y9-5iJYM9 for ; Wed, 29 Apr 2015 10:26:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162741ACD8E for ; Wed, 29 Apr 2015 10:26:21 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id A63E6B45E1E34; Wed, 29 Apr 2015 17:26:17 +0000 (GMT) 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 t3THQHHb002522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 13:26:17 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 13:26:17 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 Thread-Index: AdCBzIr6SsqnVpHOQqOMLXhwS/KfnQAogseAAAwv7YA= Date: Wed, 29 Apr 2015 17:26:17 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> In-Reply-To: <55408663.1070906@pi.nu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 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, 29 Apr 2015 17:26:26 -0000 Hi Loa, By static label, I meant a label which is assigned to a LSP or a PW by conf= iguration and not by a control plane protocol. I believe this is what is be= ing described in this draft but let me know if I am wrong. Regards, Mustapha. > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, April 29, 2015 3:21 AM > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Cc: Nevil Brownlee > Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >=20 > Mustapha, >=20 > in line please. >=20 > On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: > > Dear all, > > I was asked to review this draft which is intended to be handled in the > Independent Stream. Below are my comments to the authors. > > > > Members of this list can also provide comments to the authors. Please c= opy the > Independent Submission Editorial Board at the following address: > > rfc-ise@rfc-editor.org > > > > Regards, > > Mustapha. > > ---------------------------- > > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 > > > > 1. Overall comment: > > This document describes how a guaranteed bandwidth service can be deplo= yed > in a MPLS network by partitioning the network resources into two managed = layers, > referred to as strata. The guaranteed service layer is referred to as "H= ard Pipe" > stratum. > > > > The management of the resources and the placement of the MPLS tunnels a= nd > services into the "Hard Pipe" stratum are performed with a management sy= stem. > Thus the transport and service labels are static but this important infor= mation has > not been stated upfront in the document. >=20 > Do you have a a definition of "static labels" that we can refer to? >=20 > /Loa > Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference = to T- > LDP signaled labels in Section 3 adds to the confusion. > > >=20 > > I propose that the Introduction and Scope sections be explicit about th= e > framework used to achieve the "Hard Pipe" stratum, that is by means of a > management system and static transport and service labels. > > > > In fact, I would think the document value would be in describing more d= etails of > the framework including configuration aspects, resource and service manag= ement > including resilience. These aspects have not been sufficiently addressed = and the > focus was more on how to use MPLS labels to differentiate the two strata. > > > > 2. Section 1.1 - Scope: > > As part of the second bullet, I cannot find in the document how a route= r protects > the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum ov= erbooks a > link. Having a separate label for the guaranteed service is not sufficien= t. The > authors should describe if LSP pre-emption and/or QoS markings are used t= o > differentiate the treatment across the strata. > > > > 3. Section 3: > > If the document objective is to describe the framework used, then this = section > should begin by explaining the initial configuration performed by the NMS= to lay > the ground for the building of the two stratums. This includes the partit= ioning of the > links, the assignment of transport and service label ranges in the router= s, the > overbooking strategy, etc. > > > > Then, you can discuss how a guaranteed service is configured in the net= work > using static transport labels and static service labels. This should cove= r the > placement of the working and backup paths since Section 6 mentions MPLS-T= P > protection is used. > > > > Next, a description of how the transport LSP and service are monitored = for > continuity and defects. > > > > Finally, the behavior when resources are overbooked and what services a= re pre- > empted or degraded should be described. > > ------------------------------------ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=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 From nobody Wed Apr 29 12:25:10 2015 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 F41431ACE38; Wed, 29 Apr 2015 12:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 y2W-MVF_uP0p; Wed, 29 Apr 2015 12:25:04 -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 985CC1A907F; Wed, 29 Apr 2015 12:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26190; q=dns/txt; s=iport; t=1430335504; x=1431545104; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DUyhPDwU8R5yWyKAdQkLGBDUFMG8m16yXk0a20j2O5s=; b=KehUGhpB1sh7VeKYa+8JuSFsOMESH07PtNbtU5tZOYedyTTLbw4l35Kw 5r4EHaW5m90bQkLYyvsruNaBCFughVnUhebotWtPO1oAyFzjX5ERtlw4e hEOya21a8MGBxZUUeXk85cZC7DhGouSxcb34dOhCWK5LEZSAbmoCt6jHz M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHBQCoL0FV/5BdJa1cgkVHU1wFxRWCQoYEAoFFTAEBAQEBAYELhCABAQEDAW4LBQcEAgEIEQQBAQEgBwcyFAkIAgQOBQkFiBUIDcgAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4o2gQKBPYNEBAcGgxGBFgWPRoIkgXeBOFqGP4Ejg0mCcYZvg1yDUCOCBw0PgVFvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,672,1422921600"; d="asc'?scan'208,217";a="415886108" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 29 Apr 2015 19:24:43 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3TJOhr1015565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 19:24:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.22]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 14:24:42 -0500 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [mpls] [Editorial Errata Reported] RFC7510 (4350) Thread-Index: AQHQgSfbd29X5R9FSUyEbRgAx5Ve851iZF2A///tcgCAAF8RgIAAazmAgADluICAALP5AA== Date: Wed, 29 Apr 2015 19:24:42 +0000 Message-ID: <36AD6E96-92BE-4040-A7F0-F31570CE166E@cisco.com> References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> <6A69A0A7-6C76-4AB3-94A6-0D123DFE8459@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08329BF2@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08329BF2@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.213] Content-Type: multipart/signed; boundary="Apple-Mail=_CC2691C3-DC7B-42DA-A7ED-9A62C870E402"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "Black, David" , Ross Callon , "bess@ietf.org" , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 29 Apr 2015 19:25:08 -0000 --Apple-Mail=_CC2691C3-DC7B-42DA-A7ED-9A62C870E402 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB57CA97-2485-4FF7-B5A1-546707346D4E" --Apple-Mail=_FB57CA97-2485-4FF7-B5A1-546707346D4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Xiaohu, > On Apr 29, 2015, at 4:40 AM, Xuxiaohu wrote: >=20 > Hi Carlos, >=20 >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] >> Sent: Wednesday, April 29, 2015 2:58 AM >> To: Adrian Farrel >> Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper.net = ; Lucy >> yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; = Alvaro >> Retana (aretana); George Swallow (swallow); mpls@ietf.org = >> Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) >>=20 >> Hi, Adrian, >>=20 >> Thanks for the additional context. Note that I did not object any = changes made >> to the registry itself (although I still think that pointing to RFC = 7510 is incorrect), >> only to the errata. Modifying the data plane document to include an = IANA action >> for BGP sounds off. >>=20 >> In other words, I see two problems with the approach from the errata = (or really >> two sides of the same issue): >>=20 >> 1. RFC 7510 specifies the data plane encapsulation, and not the BGP = signaling. As >> such, it does not make for a good reference for the BGP Tunnel = Encapsulation >> Attribute Tunnel Type 13. >>=20 >> 2. Existing entries in the "BGP Tunnel Encapsulation Attribute Tunnel = Types" >> registry point to the documents which specify how that attribute is = used. >>=20 >> For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not = to RFC >> 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The = value 4 >> points to RFC 5566 and not to RFC4302, RFC4303. >=20 > In fact, I had ever followed the above logic by specifying the BGP = signaling for MPLS-in-UDP in a separate doc = (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00 = ) which has = been moved to BESS WG (see = https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00 = ) recently. = However=85 >=20 I am not implying that a new I-D is necessarily required. I am saying = that: 1. It seems a step was skipped with this Errata, where a BGP parameter = points to a data plane definition, and 2. It appears to be technically incorrect, since there are two potential = modes (with and without DTLS) but one entry only. Thanks, =97 Carlos. > Best regards, > Xiaohu >=20 >> There is another technical problem with the current approach: RFC = 7510 >> specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS >> respectively. To which one of these two does the BGP Tunnel = Encapsulation >> Attribute Tunnel Type value of 13 correspond to? Do you actually need = two >> Types? Further, do you need to consider the LB from RFC 5640? >>=20 >> Please see more inline. >>=20 >>> On Apr 28, 2015, at 8:34 AM, Adrian Farrel = wrote: >>>=20 >>> Hi Carlos, >>>=20 >>> Since I raised the issue... >>>=20 >>> The text that was omitted was agreed for inclusion between the RFC >>> Editor, IANA, and responsible AD before the publication of the RFC, >>> but was fumbled by the RFC Editor. >>>=20 >>> The RFC Editor requested this report to be submitted to resolve this >>> issue, and I checked with the ADs before I posted it. >>>=20 >>> The problem it solves is that the existing registry entry points at = an >>> I-D that caused the allocation of the code point, but that I-D is = not >>> a good reference for explaining what "MPLS in UDP" is. This document >>> provides a better indication. >>>=20 >>=20 >> The reference should not explain what "MPLS in UDP" is. The reference = should >> explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 = for MPLS >> in UDP. >>=20 >>> You said... >>>=20 >>>> RFC 7510 states that it =B3specifies an IP-based encapsulation for >>>> MPLS, called MPLS-in-UDP=B2 but there is no mention to the >>>> specification of any signaling associated to setting up said >>>> encapsulation. In other words, it self-concerns itself with the = encap. >>>=20 >>> That is correct. And there is no attempt to define any signaling or >>> add any mention of signaling to this document. >>>=20 >>> This is not a forward pointer, but a request to include a backward >>> pointer. That is, it is a request to update the entry that already >>> exists in the registry with a pointer to this document so that = people >>> can see what "MPLS in UDP" is when they encounter the value in the = registry. >>>=20 >>=20 >> I understand. My comment is that the reference should not be to "MPLS = in >> UDP". The same way that the Type 1 does not point to RFC 3931. >>=20 >>>> Further, there is no mention in RFC 7510 of =B3BGP=B2 and no = reference to >>>> RFC 5512. For a document specifying a BGP Tunnel Encapsulation >>>> Attribute Tunnel Type, I=B9d expect a reference (normative) to RFC = 5512 >>>> (such as in RFC 5566). >>>=20 >>> This document does not specify a BGP Tunnel Encapsulation Attribute >>> and there is no request for it to make such a specification. >>>=20 >>> References could be included, but they would be pointless because >>> there is nothing to hook the references to. The *only* change >>> requested is to attach a pointer to the existing entry in the = registry. >>>=20 >>>> Lastly, the IANA page points to a different document: >>>> http://www.iana.org/assignments/bgp-parameters/bgp- >>>> parameters.xhtml#tunnel- >>>> types >>>>=20 >>>> Value Name Reference >>>> 13 MPLS in UDP Encapsulation = [draft-ietf-l3vpn-end-system] >>>=20 >>> Yes. >>> Have you read that document? >>>=20 >>> This errata report does not request removal of that reference. It >>> requests the addition of an extra reference. How is that a problem? >>>=20 >>=20 >> I see not problem with the addition of a reference in an IANA = registry. >>=20 >> I do see a problem with modifying the RFC by way of an errata. >>=20 >>> For those of you who have read around the subject, you may recall a >>> prolonged series of emails across a number of mailing lists where a >>> number of different new I-Ds were proposed to give a more = substantive >> reference for the tunnel type. >>> This errata report solves that issue without needing further = documents. >>>=20 >>=20 >> Can the reference be added without the Erratum? That seems possible = to me. >>=20 >>> You may also like to note that we are dealing with a FCFS registry >>> where the documents supplied as references do not always provide a >>> good explanation. Is it better to leave the registry with a poor >>> reference, or to add a somewhat better one? >>>=20 >>>> Net-net, this RFC is not the right place to be a pointer for this >>>> assignment. >>>=20 >>> I respect your right to hold that opinion, but I don't think you = have >>> given any valid reasons for holding it. Perhaps this lack is caused = by >>> unfamiliarity with FCFS registries. >>>=20 >>=20 >> I am happy to be educated. I re-read the FCFS definition form RFC = 5226. Why >> does RFC 7510 need to be modified for this? >>=20 >> Thanks, >>=20 >> - Carlos. >>=20 >>> Adrian --Apple-Mail=_FB57CA97-2485-4FF7-B5A1-546707346D4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Xiaohu,

On Apr 29, 2015, at 4:40 AM, = Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,

-----Original = Message-----
From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Wednesday, = April 29, 2015 2:58 AM
To: Adrian Farrel
Cc: = Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper.net; = Lucy
yong; Ross Callon; Black, David; Alia Atlas; = BRUNGARD, DEBORAH A; Alvaro
Retana (aretana); George = Swallow (swallow); mpls@ietf.org
Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 = (4350)

Hi, Adrian,

Thanks for the additional context. Note that I did not object = any changes made
to the registry itself (although I still = think that pointing to RFC 7510 is incorrect),
only to the = errata. Modifying the data plane document to include an IANA action
for BGP sounds off.

In other = words, I see two problems with the approach from the errata (or = really
two sides of the same issue):

1. RFC 7510 specifies the data plane encapsulation, and not = the BGP signaling. As
such, it does not make for a good = reference for the BGP Tunnel Encapsulation
Attribute = Tunnel Type 13.

2. Existing entries in the = "BGP Tunnel Encapsulation Attribute Tunnel Types"
registry = point to the documents which specify how that attribute is used.

For example, the value 1, L2TPv3 over IP, = points to RFC 5512 and not to RFC
3931. The value 2, GRE, = points to RFC 5512 and not to RFC 2784. The value 4
points = to RFC 5566 and not to RFC4302, RFC4303.

In fact, I had ever followed the above logic by = specifying the BGP signaling for MPLS-in-UDP in a separate doc = (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00= ) which has been moved to BESS = WG (see https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00) recently. However=85


I am not implying that a new I-D is necessarily = required. I am saying that:
1. It seems a step was skipped = with this Errata, where a BGP parameter points to a data plane = definition, and
2. It appears to be technically incorrect, = since there are two potential modes (with and without DTLS) but one = entry only.

Thanks,

=97 Carlos.

Best regards,
Xiaohu

There is another = technical problem with the current approach: RFC 7510
specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with = DTLS
respectively. To which one of these two does the BGP = Tunnel Encapsulation
Attribute Tunnel Type value of 13 = correspond to? Do you actually need two
Types? Further, do = you need to consider the LB from RFC 5640?

Please see more inline.

On Apr 28, 2015, at 8:34 = AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Carlos,

Since I raised the = issue...

The text that was omitted was = agreed for inclusion between the RFC
Editor, IANA, and = responsible AD before the publication of the RFC,
but was = fumbled by the RFC Editor.

The RFC Editor = requested this report to be submitted to resolve this
issue,= and I checked with the ADs before I posted it.

The problem it solves is that the existing registry entry = points at an
I-D that caused the allocation of the code = point, but that I-D is not
a good reference for explaining = what "MPLS in UDP" is. This document
provides a better = indication.


The = reference should not explain what "MPLS in UDP" is. The reference = should
explain what is the BGP Tunnel Encapsulation = Attribute Tunnel Type 13 for MPLS
in UDP.

You said...

RFC 7510 = states that it =B3specifies an IP-based encapsulation for
MPLS, called MPLS-in-UDP=B2 but there is no mention to the
specification of any signaling associated to setting up = said
encapsulation. In other words, it self-concerns = itself with the encap.

That is = correct. And there is no attempt to define any signaling or
add any mention of signaling to this document.

This is not a forward pointer, but a request = to include a backward
pointer. That is, it is a request to = update the entry that already
exists in the registry with = a pointer to this document so that people
can see what = "MPLS in UDP" is when they encounter the value in the registry.


I understand. My = comment is that the reference should not be to "MPLS in
UDP". The same way that the Type 1 does not point to RFC = 3931.

Further, there is no = mention in RFC 7510 of =B3BGP=B2 and no reference to
RFC = 5512. For a document specifying a BGP Tunnel Encapsulation
Attribute Tunnel Type, I=B9d expect a reference (normative) = to RFC 5512
(such as in RFC 5566).

This document does not specify a = BGP Tunnel Encapsulation Attribute
and there is no request = for it to make such a specification.

References could be included, but they would be pointless = because
there is nothing to hook the references to. The = *only* change
requested is to attach a pointer to the = existing entry in the registry.

Lastly, the IANA page points to a different = document:
http://www.iana.org/assignments/bgp-parameters/bgp-
parameters.xhtml#tunnel-
types

Value  Name  = Reference
13  MPLS in = UDP Encapsulation  = [draft-ietf-l3vpn-end-system]

Yes.
Have you read that document?

This errata report does not request removal of = that reference. It
requests the addition of an extra = reference. How is that a problem?


I see not problem with the = addition of a reference in an IANA registry.

I do see a problem with modifying the RFC by way of an = errata.

For those of you who have read around the subject, you may = recall a
prolonged series of emails across a number of = mailing lists where a
number of different new I-Ds were = proposed to give a more substantive
reference = for the tunnel type.
This errata report solves that issue without needing further = documents.


Can = the reference be added without the Erratum? That seems possible to = me.

You = may also like to note that we are dealing with a FCFS registry
where the documents supplied as references do not always = provide a
good explanation. Is it better to leave the = registry with a poor
reference, or to add a somewhat = better one?

Net-net, this RFC is not the right place to be a pointer for = this
assignment.

I= respect your right to hold that opinion, but I don't think you have
given any valid reasons for holding it. Perhaps this lack is = caused by
unfamiliarity with FCFS registries.


I am happy to be = educated. I re-read the FCFS definition form RFC 5226. Why
does RFC 7510 need to be modified for this?

Thanks,

- Carlos.

Adrian

= --Apple-Mail=_FB57CA97-2485-4FF7-B5A1-546707346D4E-- --Apple-Mail=_CC2691C3-DC7B-42DA-A7ED-9A62C870E402 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVBL/kACgkQtfDPGTp3USxXAgCfebqQoAHzW9D8QOf8At6h2Ko9 zP8An3fB9kjX79YAMOx1ejx8pfVDxOSh =1XEC -----END PGP SIGNATURE----- --Apple-Mail=_CC2691C3-DC7B-42DA-A7ED-9A62C870E402-- From nobody Wed Apr 29 14:22:31 2015 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 476C01A1AD3; Wed, 29 Apr 2015 14:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 DIkpr8xugCle; Wed, 29 Apr 2015 14:22:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885CA1A0068; Wed, 29 Apr 2015 14:22:22 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BLUPR05MB787.namprd05.prod.outlook.com (10.141.209.146) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 21:22:02 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0148.008; Wed, 29 Apr 2015 21:22:01 +0000 From: Ross Callon To: "Carlos Pignataro (cpignata)" , Xiaohu Xu Thread-Topic: [mpls] [Editorial Errata Reported] RFC7510 (4350) Thread-Index: AQHQgSfXIw7C8F2c50G+m+t5zv5buZ1iEIyAgAAw3wCAABujgIAAazmAgADluICAALP6AIAAGT1w Date: Wed, 29 Apr 2015 21:22:01 +0000 Message-ID: References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> <6A69A0A7-6C76-4AB3-94A6-0D123DFE8459@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08329BF2@NKGEML512-MBS.china.huawei.com> <36AD6E96-92BE-4040-A7F0-F31570CE166E@cisco.com> In-Reply-To: <36AD6E96-92BE-4040-A7F0-F31570CE166E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB787; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB787; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB787; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(51914003)(24454002)(377454003)(13464003)(164054003)(46102003)(93886004)(5890100001)(99286002)(5001960100002)(50986999)(92566002)(19580405001)(102836002)(18717965001)(15975445007)(106116001)(76176999)(76576001)(122556002)(2950100001)(19609705001)(33656002)(5001770100001)(2656002)(19300405004)(86362001)(40100003)(2900100001)(19580395003)(87936001)(16236675004)(62966003)(66066001)(74316001)(19617315012)(19625215002)(77156002)(54356999)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB787; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1430882E5AAD51E40C603AC6A5D70BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 21:22:01.5389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB787 Archived-At: Cc: "mpls@ietf.org" , "Black, David" , "bess@ietf.org" , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 29 Apr 2015 21:22:29 -0000 --_000_BY1PR0501MB1430882E5AAD51E40C603AC6A5D70BY1PR0501MB1430_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I may be a bit confused here regarding what sort of references are intended= to be listed in the registry. Looking at the "Border Gateway Protocol (BGP) Parameters", and scrolling do= wn to "BGP Tunnel Encapsulation Attribute Tunnel Types", I see entries for = various encapsulation types with various references. As some examples: For the GRE tunnel type, I see a reference to RFC5512. RFC 5512 is "The BGP= Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute", and is spe= cifically not the RFC that defines GRE. For the IPsec in Tunnel-mode tunnel type, I see a reference to RFC 5566. Ag= ain RFC 5566 is not the RFC that specifies IPsec in Tunnel-mode. For the VXLAN tunnel type, I see a reference to draft-sd-l2vpn-evpn-overlay= . One issue is that this is an out of date reference (draft-sd-l2vpn-evpn-o= verlay has been replaced by draft-ietf-bess-evpn-overlay). More importantly= , this again is not the document that defines VXLAN. Rather, draft-ietf-bes= s-evpn-overlay talks about how to use various encapsulations (of which VXLA= N is one) along with BGP signaling to accomplish something. Thus to me, referencing RFC 7510 in this particular registry is not the sam= e sort of reference that is included along with the other tunnel types. How= ever, I don't see any problem with referencing the document that defines th= e tunnel method as an additional reference for each entry. If we are going = to do this then perhaps we (for some definition of "we") should also add ot= her references to the registry, specifically the document that defines the = tunnel mechanism for each of the other tunnel types. Ross (speaking as co-author of RFC 7510) From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Wednesday, April 29, 2015 3:25 PM To: Xiaohu Xu Cc: Adrian Farrel; Loa Andersson; RFC Errata System; Nischal Sheth; Lucy yo= ng; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro Reta= na (aretana); George Swallow (swallow); mpls@ietf.org; bess@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) Hi Xiaohu, On Apr 29, 2015, at 4:40 AM, Xuxiaohu > wrote: Hi Carlos, -----Original Message----- From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Wednesday, April 29, 2015 2:58 AM To: Adrian Farrel Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper.net; Lucy yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro Retana (aretana); George Swallow (swallow); mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) Hi, Adrian, Thanks for the additional context. Note that I did not object any changes m= ade to the registry itself (although I still think that pointing to RFC 7510 is= incorrect), only to the errata. Modifying the data plane document to include an IANA ac= tion for BGP sounds off. In other words, I see two problems with the approach from the errata (or re= ally two sides of the same issue): 1. RFC 7510 specifies the data plane encapsulation, and not the BGP signali= ng. As such, it does not make for a good reference for the BGP Tunnel Encapsulatio= n Attribute Tunnel Type 13. 2. Existing entries in the "BGP Tunnel Encapsulation Attribute Tunnel Types= " registry point to the documents which specify how that attribute is used. For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to RFC 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The value 4 points to RFC 5566 and not to RFC4302, RFC4303. In fact, I had ever followed the above logic by specifying the BGP signalin= g for MPLS-in-UDP in a separate doc (https://tools.ietf.org/html/draft-xu-s= oftwire-encaps-udp-00) which has been moved to BESS WG (see https://tools.i= etf.org/html/draft-xu-bess-encaps-udp-00) recently. However... I am not implying that a new I-D is necessarily required. I am saying that: 1. It seems a step was skipped with this Errata, where a BGP parameter poin= ts to a data plane definition, and 2. It appears to be technically incorrect, since there are two potential mo= des (with and without DTLS) but one entry only. Thanks, - Carlos. Best regards, Xiaohu There is another technical problem with the current approach: RFC 7510 specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS respectively. To which one of these two does the BGP Tunnel Encapsulation Attribute Tunnel Type value of 13 correspond to? Do you actually need two Types? Further, do you need to consider the LB from RFC 5640? Please see more inline. On Apr 28, 2015, at 8:34 AM, Adrian Farrel > wrote: Hi Carlos, Since I raised the issue... The text that was omitted was agreed for inclusion between the RFC Editor, IANA, and responsible AD before the publication of the RFC, but was fumbled by the RFC Editor. The RFC Editor requested this report to be submitted to resolve this issue, and I checked with the ADs before I posted it. The problem it solves is that the existing registry entry points at an I-D that caused the allocation of the code point, but that I-D is not a good reference for explaining what "MPLS in UDP" is. This document provides a better indication. The reference should not explain what "MPLS in UDP" is. The reference shoul= d explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 for M= PLS in UDP. You said... RFC 7510 states that it =B3specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP=B2 but there is no mention to the specification of any signaling associated to setting up said encapsulation. In other words, it self-concerns itself with the encap. That is correct. And there is no attempt to define any signaling or add any mention of signaling to this document. This is not a forward pointer, but a request to include a backward pointer. That is, it is a request to update the entry that already exists in the registry with a pointer to this document so that people can see what "MPLS in UDP" is when they encounter the value in the registry= . I understand. My comment is that the reference should not be to "MPLS in UDP". The same way that the Type 1 does not point to RFC 3931. Further, there is no mention in RFC 7510 of =B3BGP=B2 and no reference to RFC 5512. For a document specifying a BGP Tunnel Encapsulation Attribute Tunnel Type, I=B9d expect a reference (normative) to RFC 5512 (such as in RFC 5566). This document does not specify a BGP Tunnel Encapsulation Attribute and there is no request for it to make such a specification. References could be included, but they would be pointless because there is nothing to hook the references to. The *only* change requested is to attach a pointer to the existing entry in the registry. Lastly, the IANA page points to a different document: http://www.iana.org/assignments/bgp-parameters/bgp- parameters.xhtml#tunnel- types Value Name Referenc= e 13 MPLS in UDP Encapsulation [draft-ietf-l3vpn-end-sys= tem] Yes. Have you read that document? This errata report does not request removal of that reference. It requests the addition of an extra reference. How is that a problem? I see not problem with the addition of a reference in an IANA registry. I do see a problem with modifying the RFC by way of an errata. For those of you who have read around the subject, you may recall a prolonged series of emails across a number of mailing lists where a number of different new I-Ds were proposed to give a more substantive reference for the tunnel type. This errata report solves that issue without needing further documents. Can the reference be added without the Erratum? That seems possible to me. You may also like to note that we are dealing with a FCFS registry where the documents supplied as references do not always provide a good explanation. Is it better to leave the registry with a poor reference, or to add a somewhat better one? Net-net, this RFC is not the right place to be a pointer for this assignment. I respect your right to hold that opinion, but I don't think you have given any valid reasons for holding it. Perhaps this lack is caused by unfamiliarity with FCFS registries. I am happy to be educated. I re-read the FCFS definition form RFC 5226. Why does RFC 7510 need to be modified for this? Thanks, - Carlos. Adrian --_000_BY1PR0501MB1430882E5AAD51E40C603AC6A5D70BY1PR0501MB1430_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I may be a bit confused h= ere regarding what sort of references are intended to be listed in the regi= stry.

 <= /p>

Looking at the “Bor= der Gateway Protocol (BGP) Parameters”, and scrolling down to “= BGP Tunnel Encapsulation Attribute Tunnel Types”, I see entries for v= arious encapsulation types with various references. As some examples: =

 <= /p>

For the GRE tunnel type, = I see a reference to RFC5512. RFC 5512 is “The BGP Encapsulation SAFI= and the BGP Tunnel Encapsulation Attribute”, and is specifically not the RFC that defines GRE.

 <= /p>

For the IPsec in Tunnel-m= ode tunnel type, I see a reference to RFC 5566. Again RFC 5566 is not the R= FC that specifies IPsec in Tunnel-mode.

 <= /p>

For the VXLAN tunnel type= , I see a reference to draft-sd-l2vpn-evpn-overlay. One issue is that this = is an out of date reference (draft-sd-l2vpn-evpn-overlay has been replaced by draft-ietf-bess-evpn-overlay). More importantly, this= again is not the document that defines VXLAN. Rather, draft-ietf-bess-evpn= -overlay talks about how to use various encapsulations (of which VXLAN is o= ne) along with BGP signaling to accomplish something.

 <= /p>

Thus to me, referencing R= FC 7510 in this particular registry is not the same sort of reference that = is included along with the other tunnel types. However, I don’t see any problem with referencing the document that defines t= he tunnel method as an additional reference for each entry. If we are going= to do this then perhaps we (for some definition of “we”) shoul= d also add other references to the registry, specifically the document that defines the tunnel mechanism for each of the other tunne= l types.

 <= /p>

Ross (speaking as co-auth= or of RFC 7510)

 <= /p>

From: Carlos P= ignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Wednesday, April 29, 2015 3:25 PM
To: Xiaohu Xu
Cc: Adrian Farrel; Loa Andersson; RFC Errata System; Nischal Sheth; = Lucy yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alva= ro Retana (aretana); George Swallow (swallow); mpls@ietf.org; bess@ietf.org=
Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)<= /o:p>

 

Hi Xiaohu,

 

On Apr 29, 2015, at 4:40 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:<= /p>

 

Hi Carlos,


-----Original Message-----
From: Carlos Pignataro (cpignata) [ma= ilto:cpignata@cisco.com]
Sent: Wednesday, April 29, 2015 2:58 AM
To: Adrian Farrel
Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper= .net; Lucy
yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro Retana (aretana); George Swallow (swallow); mpls@ietf.org
Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350)

Hi, Adrian,

Thanks for the additional context. Note that I did not object any changes m= ade
to the registry itself (although I still think that pointing to RFC 7510 is= incorrect),
only to the errata. Modifying the data plane document to include an IANA ac= tion
for BGP sounds off.

In other words, I see two problems with the approach from the errata (or re= ally
two sides of the same issue):

1. RFC 7510 specifies the data plane encapsulation, and not the BGP signali= ng. As
such, it does not make for a good reference for the BGP Tunnel Encapsulatio= n
Attribute Tunnel Type 13.

2. Existing entries in the "BGP Tunnel Encapsulation Attribute Tunnel = Types"
registry point to the documents which specify how that attribute is used.
For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not to RFC=
3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The value 4=
points to RFC 5566 and not to RFC4302, RFC4303.


In fact, I had ever followed the above logic by specifying the BGP signalin= g for MPLS-in-UDP in a separate doc (https://tools.ietf.o= rg/html/draft-xu-softwire-encaps-udp-00) which has been moved to BESS WG (see=  https://tools.ietf.org/html/draft-xu-bess-encaps= -udp-00) recently. However…

 

I am not implying that a new I-D is necessarily requ= ired. I am saying that:

1. It seems a step was skipped with this Errata, whe= re a BGP parameter points to a data plane definition, and

2. It appears to be technically incorrect, since the= re are two potential modes (with and without DTLS) but one entry only.=

 

Thanks,

 

— Carlos.


Best regards,
Xiaohu


There is another technical problem wit= h the current approach: RFC 7510
specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS
respectively. To which one of these two does the BGP Tunnel Encapsulation Attribute Tunnel Type value of 13 correspond to? Do you actually need two Types? Further, do you need to consider the LB from RFC 5640?

Please see more inline.


On Apr = 28, 2015, at 8:34 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Carlos,

Since I raised the issue...

The text that was omitted was agreed for inclusion between the RFC
Editor, IANA, and responsible AD before the publication of the RFC,
but was fumbled by the RFC Editor.

The RFC Editor requested this report to be submitted to resolve this
issue, and I checked with the ADs before I posted it.

The problem it solves is that the existing registry entry points at an
I-D that caused the allocation of the code point, but that I-D is not
a good reference for explaining what "MPLS in UDP" is. This docum= ent
provides a better indication.


The reference should not explain what "MPLS in UDP" is. The refer= ence should
explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 for M= PLS
in UDP.


You said...


RFC 7510 states that it =B3specifies a= n IP-based encapsulation for
MPLS, called MPLS-in-UDP=B2 but there is no mention to the
specification of any signaling associated to setting up said
encapsulation. In other words, it self-concerns itself with the encap.=


That is correct. And there is no attempt to define any signaling or
add any mention of signaling to this document.

This is not a forward pointer, but a request to include a backward
pointer. That is, it is a request to update the entry that already
exists in the registry with a pointer to this document so that people
can see what "MPLS in UDP" is when they encounter the value in th= e registry.


I understand. My comment is that the reference should not be to "MPLS = in
UDP". The same way that the Type 1 does not point to RFC 3931.


Further, there is no mention in RFC 75= 10 of =B3BGP=B2 and no reference to
RFC 5512. For a document specifying a BGP Tunnel Encapsulation
Attribute Tunnel Type, I=B9d expect a reference (normative) to RFC 5512
(such as in RFC 5566).


This document does not specify a BGP Tunnel Encapsulation Attribute
and there is no request for it to make such a specification.

References could be included, but they would be pointless because
there is nothing to hook the references to. The *only* change
requested is to attach a pointer to the existing entry in the registry.


Lastly, the IANA page points to a diff= erent document:
http://www.= iana.org/assignments/bgp-parameters/bgp-
parameters.xhtml#tunnel-
types

Value     Name          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Reference
13           MPLS in UDP Encapsulation = ;      =      [draft-ietf-l3vpn-end-system]


Yes.
Have you read that document?

This errata report does not request removal of that reference. It
requests the addition of an extra reference. How is that a problem?


I see not problem with the addition of a reference in an IANA registry.

I do see a problem with modifying the RFC by way of an errata.


For those of you who have read around = the subject, you may recall a
prolonged series of emails across a number of mailing lists where a
number of different new I-Ds were proposed to give a more substantive<= /o:p>

reference for the tunnel type.

This er= rata report solves that issue without needing further documents.=


Can the reference be added without the Erratum? That seems possible to me.<= br>

You may also like to note that we are = dealing with a FCFS registry
where the documents supplied as references do not always provide a
good explanation. Is it better to leave the registry with a poor
reference, or to add a somewhat better one?


Net-net, this RFC is not the right pla= ce to be a pointer for this
assignment.


I respect your right to hold that opinion, but I don't think you have
given any valid reasons for holding it. Perhaps this lack is caused by
unfamiliarity with FCFS registries.


I am happy to be educated. I re-read the FCFS definition form RFC 5226. Why=
does RFC 7510 need to be modified for this?

Thanks,

- Carlos.


Adrian

 

--_000_BY1PR0501MB1430882E5AAD51E40C603AC6A5D70BY1PR0501MB1430_-- From nobody Wed Apr 29 14:30:14 2015 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 4FF131A6FEA; Wed, 29 Apr 2015 14:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 FwqSTJtNtYXt; Wed, 29 Apr 2015 14:30:08 -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 ED27F1A6EF2; Wed, 29 Apr 2015 14:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39269; q=dns/txt; s=iport; t=1430343008; x=1431552608; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=58uHjwVtPgY6KcjwMqTIx8M1kLAOiS4LD4tIDl8ItyU=; b=l9jFwWnuni0aO6VqwxXZrKShIOc5Q85W+vxEflz1oLjgdJdq9FifQH8t UlZrixR/DNHBZTrtGGlJ8vP4P8JnTpPuilnZglBMvig1vxT6tKwNcuHzs Ek3aiU2k0x6XadAhLOAdNR4JeqjK2XbU/dy4TcBqp7b2RExu1qbCDVH3L k=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CCBAC2TEFV/40NJK1cgkVHU1wFxRVmCYFThgQCgUU4FAEBAQEBAQGBCoQgAQEBAwEnRwsFBwQCAQgOAwQBAQEgAQYHMhQJCAIEDgUJBYgVCA3IBAEBAQEBAQEBAQEBAQEBAQEBAQEBAReKNoECgT2DRAQGAQaDEYEWBY9GgiSBd4E4WoY/gSODSYJxhm+DXINQI4IHDQ+BUW+BRIEBAQEB X-IronPort-AV: E=Sophos;i="5.11,672,1422921600"; d="asc'?scan'208,217";a="145707398" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 29 Apr 2015 21:30:06 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3TLU6Qi005715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 21:30:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.22]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 16:30:06 -0500 From: "Carlos Pignataro (cpignata)" To: Ross Callon Thread-Topic: [mpls] [Editorial Errata Reported] RFC7510 (4350) Thread-Index: AQHQgSfbd29X5R9FSUyEbRgAx5Ve851iZF2A///tcgCAAF8RgIAAazmAgADluICAALP5AIAAIMeAgAACQAA= Date: Wed, 29 Apr 2015 21:30:05 +0000 Message-ID: <2C403BA2-5671-4F21-81D1-F89B2D389FC1@cisco.com> References: <20150427202110.525FF180092@rfc-editor.org> <553F3E2D.4060208@pi.nu> <00d501d081af$b0a7ef00$11f7cd00$@olddog.co.uk> <6A69A0A7-6C76-4AB3-94A6-0D123DFE8459@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08329BF2@NKGEML512-MBS.china.huawei.com> <36AD6E96-92BE-4040-A7F0-F31570CE166E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.46] Content-Type: multipart/signed; boundary="Apple-Mail=_E512078E-B317-4986-AA32-D9FF29804FC8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "Black, David" , "bess@ietf.org" , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) 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, 29 Apr 2015 21:30:12 -0000 --Apple-Mail=_E512078E-B317-4986-AA32-D9FF29804FC8 Content-Type: multipart/alternative; boundary="Apple-Mail=_6473ECBE-E0DA-4292-A227-CEDBE16269E7" --Apple-Mail=_6473ECBE-E0DA-4292-A227-CEDBE16269E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ross, I agree with the reasoning you lay out =97 but I would add that there is = a difference between updating an IANA registry with an extra citation = (mostly harmless, possibly useful), versus updating a Standards Track = RFC with an Erratum. I would further add that a reference description = for how to use the Tunnel Type 13 is still missing, as RFC 7510 does not = accomplish that. Thanks! =97 Carlos (speaking as Carlos) > On Apr 29, 2015, at 5:22 PM, Ross Callon wrote: >=20 > I may be a bit confused here regarding what sort of references are = intended to be listed in the registry. >=20 > Looking at the =93Border Gateway Protocol (BGP) Parameters=94, and = scrolling down to =93BGP Tunnel Encapsulation Attribute Tunnel Types=94, = I see entries for various encapsulation types with various references. = As some examples: >=20 > For the GRE tunnel type, I see a reference to RFC5512. RFC 5512 is = =93The BGP Encapsulation SAFI and the BGP Tunnel Encapsulation = Attribute=94, and is specifically not the RFC that defines GRE. >=20 > For the IPsec in Tunnel-mode tunnel type, I see a reference to RFC = 5566. Again RFC 5566 is not the RFC that specifies IPsec in Tunnel-mode. >=20 > For the VXLAN tunnel type, I see a reference to = draft-sd-l2vpn-evpn-overlay. One issue is that this is an out of date = reference (draft-sd-l2vpn-evpn-overlay has been replaced by = draft-ietf-bess-evpn-overlay). More importantly, this again is not the = document that defines VXLAN. Rather, draft-ietf-bess-evpn-overlay talks = about how to use various encapsulations (of which VXLAN is one) along = with BGP signaling to accomplish something. >=20 > Thus to me, referencing RFC 7510 in this particular registry is not = the same sort of reference that is included along with the other tunnel = types. However, I don=92t see any problem with referencing the document = that defines the tunnel method as an additional reference for each = entry. If we are going to do this then perhaps we (for some definition = of =93we=94) should also add other references to the registry, = specifically the document that defines the tunnel mechanism for each of = the other tunnel types. >=20 > Ross (speaking as co-author of RFC 7510) >=20 > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Wednesday, April 29, 2015 3:25 PM > To: Xiaohu Xu > Cc: Adrian Farrel; Loa Andersson; RFC Errata System; Nischal Sheth; = Lucy yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; = Alvaro Retana (aretana); George Swallow (swallow); mpls@ietf.org; = bess@ietf.org > Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) >=20 > Hi Xiaohu, >=20 > On Apr 29, 2015, at 4:40 AM, Xuxiaohu > wrote: >=20 > Hi Carlos, >=20 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Sent: Wednesday, April 29, 2015 2:58 AM > To: Adrian Farrel > Cc: Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper.net = ; Lucy > yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, DEBORAH A; = Alvaro > Retana (aretana); George Swallow (swallow); mpls@ietf.org = > Subject: Re: [mpls] [Editorial Errata Reported] RFC7510 (4350) >=20 > Hi, Adrian, >=20 > Thanks for the additional context. Note that I did not object any = changes made > to the registry itself (although I still think that pointing to RFC = 7510 is incorrect), > only to the errata. Modifying the data plane document to include an = IANA action > for BGP sounds off. >=20 > In other words, I see two problems with the approach from the errata = (or really > two sides of the same issue): >=20 > 1. RFC 7510 specifies the data plane encapsulation, and not the BGP = signaling. As > such, it does not make for a good reference for the BGP Tunnel = Encapsulation > Attribute Tunnel Type 13. >=20 > 2. Existing entries in the "BGP Tunnel Encapsulation Attribute Tunnel = Types" > registry point to the documents which specify how that attribute is = used. >=20 > For example, the value 1, L2TPv3 over IP, points to RFC 5512 and not = to RFC > 3931. The value 2, GRE, points to RFC 5512 and not to RFC 2784. The = value 4 > points to RFC 5566 and not to RFC4302, RFC4303. >=20 > In fact, I had ever followed the above logic by specifying the BGP = signaling for MPLS-in-UDP in a separate doc = (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00 = ) which has = been moved to BESS WG (see = https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00 = ) recently. = However=85 >=20 >=20 > I am not implying that a new I-D is necessarily required. I am saying = that: > 1. It seems a step was skipped with this Errata, where a BGP parameter = points to a data plane definition, and > 2. It appears to be technically incorrect, since there are two = potential modes (with and without DTLS) but one entry only. >=20 > Thanks, >=20 > =97 Carlos. >=20 >=20 > Best regards, > Xiaohu >=20 >=20 > There is another technical problem with the current approach: RFC 7510 > specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with DTLS > respectively. To which one of these two does the BGP Tunnel = Encapsulation > Attribute Tunnel Type value of 13 correspond to? Do you actually need = two > Types? Further, do you need to consider the LB from RFC 5640? >=20 > Please see more inline. >=20 >=20 > On Apr 28, 2015, at 8:34 AM, Adrian Farrel > wrote: >=20 > Hi Carlos, >=20 > Since I raised the issue... >=20 > The text that was omitted was agreed for inclusion between the RFC > Editor, IANA, and responsible AD before the publication of the RFC, > but was fumbled by the RFC Editor. >=20 > The RFC Editor requested this report to be submitted to resolve this > issue, and I checked with the ADs before I posted it. >=20 > The problem it solves is that the existing registry entry points at an > I-D that caused the allocation of the code point, but that I-D is not > a good reference for explaining what "MPLS in UDP" is. This document > provides a better indication. >=20 >=20 > The reference should not explain what "MPLS in UDP" is. The reference = should > explain what is the BGP Tunnel Encapsulation Attribute Tunnel Type 13 = for MPLS > in UDP. >=20 >=20 > You said... >=20 >=20 > RFC 7510 states that it =B3specifies an IP-based encapsulation for > MPLS, called MPLS-in-UDP=B2 but there is no mention to the > specification of any signaling associated to setting up said > encapsulation. In other words, it self-concerns itself with the encap. >=20 > That is correct. And there is no attempt to define any signaling or > add any mention of signaling to this document. >=20 > This is not a forward pointer, but a request to include a backward > pointer. That is, it is a request to update the entry that already > exists in the registry with a pointer to this document so that people > can see what "MPLS in UDP" is when they encounter the value in the = registry. >=20 >=20 > I understand. My comment is that the reference should not be to "MPLS = in > UDP". The same way that the Type 1 does not point to RFC 3931. >=20 >=20 > Further, there is no mention in RFC 7510 of =B3BGP=B2 and no reference = to > RFC 5512. For a document specifying a BGP Tunnel Encapsulation > Attribute Tunnel Type, I=B9d expect a reference (normative) to RFC = 5512 > (such as in RFC 5566). >=20 > This document does not specify a BGP Tunnel Encapsulation Attribute > and there is no request for it to make such a specification. >=20 > References could be included, but they would be pointless because > there is nothing to hook the references to. The *only* change > requested is to attach a pointer to the existing entry in the = registry. >=20 >=20 > Lastly, the IANA page points to a different document: > http://www.iana.org/assignments/bgp-parameters/bgp- = > parameters.xhtml#tunnel- > types >=20 > Value Name = Reference > 13 MPLS in UDP Encapsulation = [draft-ietf-l3vpn-end-system] >=20 > Yes. > Have you read that document? >=20 > This errata report does not request removal of that reference. It > requests the addition of an extra reference. How is that a problem? >=20 >=20 > I see not problem with the addition of a reference in an IANA = registry. >=20 > I do see a problem with modifying the RFC by way of an errata. >=20 >=20 > For those of you who have read around the subject, you may recall a > prolonged series of emails across a number of mailing lists where a > number of different new I-Ds were proposed to give a more substantive > reference for the tunnel type. >=20 > This errata report solves that issue without needing further = documents. >=20 >=20 > Can the reference be added without the Erratum? That seems possible to = me. >=20 >=20 > You may also like to note that we are dealing with a FCFS registry > where the documents supplied as references do not always provide a > good explanation. Is it better to leave the registry with a poor > reference, or to add a somewhat better one? >=20 >=20 > Net-net, this RFC is not the right place to be a pointer for this > assignment. >=20 > I respect your right to hold that opinion, but I don't think you have > given any valid reasons for holding it. Perhaps this lack is caused by > unfamiliarity with FCFS registries. >=20 >=20 > I am happy to be educated. I re-read the FCFS definition form RFC = 5226. Why > does RFC 7510 need to be modified for this? >=20 > Thanks, >=20 > - Carlos. >=20 >=20 > Adrian --Apple-Mail=_6473ECBE-E0DA-4292-A227-CEDBE16269E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ross,

I = agree with the reasoning you lay out =97 but I would add that there is a = difference between updating an IANA registry with an extra citation = (mostly harmless, possibly useful), versus updating a Standards = Track RFC with an Erratum. I would further add that a reference = description for how to use the Tunnel Type 13 is still missing, as RFC = 7510 does not accomplish that.

Thanks!

=97 Carlos (speaking as = Carlos)

On Apr 29, 2015, at 5:22 PM, Ross Callon = <rcallon@juniper.net> wrote:

I may be a bit confused here regarding = what sort of references are intended to be listed in the registry.
 
Looking at the =93Border = Gateway Protocol (BGP) Parameters=94, and scrolling down to =93BGP = Tunnel Encapsulation Attribute Tunnel Types=94, I see entries for = various encapsulation types with various references. As some = examples: 
 
For the GRE tunnel = type, I see a reference to RFC5512. RFC 5512 is =93The BGP Encapsulation = SAFI and the BGP Tunnel Encapsulation Attribute=94, and is specifically = not the RFC that defines GRE. 
 
For the IPsec in = Tunnel-mode tunnel type, I see a reference to RFC 5566. Again RFC 5566 = is not the RFC that specifies IPsec in Tunnel-mode.
 
For the VXLAN tunnel = type, I see a reference to draft-sd-l2vpn-evpn-overlay. One issue is = that this is an out of date reference (draft-sd-l2vpn-evpn-overlay has = been replaced by draft-ietf-bess-evpn-overlay). More importantly, this = again is not the document that defines VXLAN. Rather, = draft-ietf-bess-evpn-overlay talks about how to use various = encapsulations (of which VXLAN is one) along with BGP signaling to = accomplish something. 
 
Thus to me, referencing = RFC 7510 in this particular registry is not the same sort of reference = that is included along with the other tunnel types. However, I don=92t = see any problem with referencing the document that defines the tunnel = method as an additional reference for each entry. If we are going to do = this then perhaps we (for some definition of =93we=94) should also add = other references to the registry, specifically the document that defines = the tunnel mechanism for each of the other tunnel types.
 
Ross (speaking as = co-author of RFC 7510)
 
From: Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] 
Sent: Wednesday, April 29, 2015 = 3:25 PM
To: Xiaohu Xu
Cc: Adrian Farrel; Loa = Andersson; RFC Errata System; Nischal Sheth; Lucy yong; Ross Callon; = Black, David; Alia Atlas; BRUNGARD, DEBORAH A; Alvaro Retana (aretana); = George Swallow (swallow); mpls@ietf.org; bess@ietf.org
Subject: Re: [mpls] [Editorial = Errata Reported] RFC7510 (4350)
 
Hi Xiaohu,
 
On = Apr 29, 2015, at 4:40 AM, Xuxiaohu <xuxiaohu@huawei.com> = wrote:
 
Hi Carlos,


-----Original Message-----
From: = Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Wednesday, = April 29, 2015 2:58 AM
To: Adrian Farrel
Cc: = Loa Andersson; RFC Errata System; Xuxiaohu; nsheth@juniper.net; Lucy
yong; Ross Callon; Black, David; Alia Atlas; BRUNGARD, = DEBORAH A; Alvaro
Retana (aretana); George Swallow = (swallow); mpls@ietf.org
Subject: Re: = [mpls] [Editorial Errata Reported] RFC7510 (4350)

Hi, Adrian,

Thanks for the = additional context. Note that I did not object any changes made
to the registry itself (although I still think that pointing = to RFC 7510 is incorrect),
only to the errata. Modifying = the data plane document to include an IANA action
for BGP = sounds off.

In other words, I see two = problems with the approach from the errata (or really
two = sides of the same issue):

1. RFC 7510 = specifies the data plane encapsulation, and not the BGP signaling. As
such, it does not make for a good reference for the BGP = Tunnel Encapsulation
Attribute Tunnel Type 13.

2. Existing entries in the "BGP Tunnel = Encapsulation Attribute Tunnel Types"
registry point to = the documents which specify how that attribute is used.

For example, the value 1, L2TPv3 over IP, points to RFC 5512 = and not to RFC
3931. The value 2, GRE, points to RFC 5512 = and not to RFC 2784. The value 4
points to RFC 5566 and = not to RFC4302, RFC4303.

In fact, = I had ever followed the above logic by specifying the BGP signaling for = MPLS-in-UDP in a separate doc (https://tools.ietf.org/html/draft-xu-softwire-encaps-udp-00) which has been moved to BESS WG (see https://tools.ietf.org/html/draft-xu-bess-encaps-udp-00<= /a>) recently. However=85

 
1. It seems a step was skipped with this = Errata, where a BGP parameter points to a data plane definition, and
Thanks,
=97 Carlos.


Best regards,
Xiaohu


There is another = technical problem with the current approach: RFC 7510
specifies two UDP ports, for MPLS-in-UDP and MPLS-in-UDP with = DTLS
respectively. To which one of these two does the BGP = Tunnel Encapsulation
Attribute Tunnel Type value of 13 = correspond to? Do you actually need two
Types? Further, do = you need to consider the LB from RFC 5640?

Please see more inline.


On Apr 28, 2015, at 8:34 AM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:

Hi Carlos,

Since I raised the issue...

The = text that was omitted was agreed for inclusion between the RFC
Editor, IANA, and responsible AD before the publication of = the RFC,
but was fumbled by the RFC Editor.

The RFC Editor requested this report to be = submitted to resolve this
issue, and I checked with the = ADs before I posted it.

The problem it = solves is that the existing registry entry points at an
I-D = that caused the allocation of the code point, but that I-D is not
a good reference for explaining what "MPLS in UDP" is. This = document
provides a better indication.


The reference should not explain what "MPLS in = UDP" is. The reference should
explain what is the BGP = Tunnel Encapsulation Attribute Tunnel Type 13 for MPLS
in = UDP.


You said...


RFC 7510 states that it =B3specifies an IP-based = encapsulation for
MPLS, called MPLS-in-UDP=B2 but there is = no mention to the
specification of any signaling = associated to setting up said
encapsulation. In other = words, it self-concerns itself with the encap.


That is correct. And there is no = attempt to define any signaling or
add any mention of = signaling to this document.

This is not a = forward pointer, but a request to include a backward
pointer. That is, it is a request to update the entry that = already
exists in the registry with a pointer to this = document so that people
can see what "MPLS in UDP" is when = they encounter the value in the registry.


I understand. My comment is that the reference = should not be to "MPLS in
UDP". The same way that the Type = 1 does not point to RFC 3931.


Further, there is no = mention in RFC 7510 of =B3BGP=B2 and no reference to
RFC = 5512. For a document specifying a BGP Tunnel Encapsulation
Attribute Tunnel Type, I=B9d expect a reference (normative) = to RFC 5512
(such as in RFC 5566).

This document does not specify a = BGP Tunnel Encapsulation Attribute
and there is no request = for it to make such a specification.

References could be included, but they would be pointless = because
there is nothing to hook the references to. The = *only* change
requested is to attach a pointer to the = existing entry in the registry.


Lastly, the IANA page points to a different = document:
http://www.iana.org/assignments/bgp-parameters/bgp-
parameters.xhtml#tunnel-
types

Value     Name         &= nbsp;           &nb= sp;            = ;            &= nbsp;      Reference
13         &= nbsp; MPLS in = UDP Encapsulation         &= nbsp;  [draft-ietf-l3vpn-end-= system]


Yes.
Have you read = that document?

This errata report does not = request removal of that reference. It
requests the = addition of an extra reference. How is that a problem?


I see not problem with the addition of a = reference in an IANA registry.

I do see a = problem with modifying the RFC by way of an errata.


For those of you who = have read around the subject, you may recall a
prolonged = series of emails across a number of mailing lists where a
number of different new I-Ds were proposed to give a more = substantive
reference for the tunnel type.

This errata report solves that issue without = needing further documents.


Can the = reference be added without the Erratum? That seems possible to me.


You may also like to note that we are dealing with a FCFS = registry
where the documents supplied as references do not = always provide a
good explanation. Is it better to leave = the registry with a poor
reference, or to add a somewhat = better one?


Net-net, this RFC is not the right place to be a pointer for = this
assignment.


I respect = your right to hold that opinion, but I don't think you have
given any valid reasons for holding it. Perhaps this lack is = caused by
unfamiliarity with FCFS registries.


I am happy to be educated. I re-read the FCFS = definition form RFC 5226. Why
does RFC 7510 need to be = modified for this?

Thanks,

- Carlos.


Adrian
<= /div>
= --Apple-Mail=_6473ECBE-E0DA-4292-A227-CEDBE16269E7-- --Apple-Mail=_E512078E-B317-4986-AA32-D9FF29804FC8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVBTVwACgkQtfDPGTp3USwqRgCgwaicx4Sh0RcD7z+b2SHOxxX4 1IEAn09bpb7mfwNHN8pdvmeeXYLSqAnh =MUuV -----END PGP SIGNATURE----- --Apple-Mail=_E512078E-B317-4986-AA32-D9FF29804FC8-- From nobody Thu Apr 30 00:41:20 2015 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 DFE201ACEBA for ; Thu, 30 Apr 2015 00:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 E6_h2Hn-5lty for ; Thu, 30 Apr 2015 00:41:16 -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 F16561ACEB2 for ; Thu, 30 Apr 2015 00:41:15 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 71C3218013E6; Thu, 30 Apr 2015 09:41:14 +0200 (CEST) Message-ID: <5541DC9A.5000200@pi.nu> Date: Thu, 30 Apr 2015 09:41:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Aissaoui, Mustapha (Mustapha)" , "mpls@ietf.org" References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 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, 30 Apr 2015 07:41:19 -0000 Mustapha, That is still not a definition possible to refrence. I've always been a bit confused by the distinction between "static" and "dynamic", especially when it comes to labels, a bit less so if we talk about LSPs. To me the term "static" and "dynamic" seems to indicate how long lived or how easy they are to change. If an NMS or any centralized controller instal and remove LSPs/labels with the same frequency as e.g. LDP are they still "static"? I agree that there is a possible classification of "configured LSPs/labels" vs. "signaled LSPs/labels". In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses configured labels. Would that terminology be acceptable for you? /Loa On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: > Hi Loa, > By static label, I meant a label which is assigned to a LSP or a PW by configuration and not by a control plane protocol. I believe this is what is being described in this draft but let me know if I am wrong. > > Regards, > Mustapha. > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Wednesday, April 29, 2015 3:21 AM >> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org >> Cc: Nevil Brownlee >> Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >> >> Mustapha, >> >> in line please. >> >> On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: >>> Dear all, >>> I was asked to review this draft which is intended to be handled in the >> Independent Stream. Below are my comments to the authors. >>> >>> Members of this list can also provide comments to the authors. Please copy the >> Independent Submission Editorial Board at the following address: >>> rfc-ise@rfc-editor.org >>> >>> Regards, >>> Mustapha. >>> ---------------------------- >>> https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 >>> >>> 1. Overall comment: >>> This document describes how a guaranteed bandwidth service can be deployed >> in a MPLS network by partitioning the network resources into two managed layers, >> referred to as strata. The guaranteed service layer is referred to as "Hard Pipe" >> stratum. >>> >>> The management of the resources and the placement of the MPLS tunnels and >> services into the "Hard Pipe" stratum are performed with a management system. >> Thus the transport and service labels are static but this important information has >> not been stated upfront in the document. >> >> Do you have a a definition of "static labels" that we can refer to? >> >> /Loa >> Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference to T- >> LDP signaled labels in Section 3 adds to the confusion. >>> >> >>> I propose that the Introduction and Scope sections be explicit about the >> framework used to achieve the "Hard Pipe" stratum, that is by means of a >> management system and static transport and service labels. >>> >>> In fact, I would think the document value would be in describing more details of >> the framework including configuration aspects, resource and service management >> including resilience. These aspects have not been sufficiently addressed and the >> focus was more on how to use MPLS labels to differentiate the two strata. >>> >>> 2. Section 1.1 - Scope: >>> As part of the second bullet, I cannot find in the document how a router protects >> the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum overbooks a >> link. Having a separate label for the guaranteed service is not sufficient. The >> authors should describe if LSP pre-emption and/or QoS markings are used to >> differentiate the treatment across the strata. >>> >>> 3. Section 3: >>> If the document objective is to describe the framework used, then this section >> should begin by explaining the initial configuration performed by the NMS to lay >> the ground for the building of the two stratums. This includes the partitioning of the >> links, the assignment of transport and service label ranges in the routers, the >> overbooking strategy, etc. >>> >>> Then, you can discuss how a guaranteed service is configured in the network >> using static transport labels and static service labels. This should cover the >> placement of the working and backup paths since Section 6 mentions MPLS-TP >> protection is used. >>> >>> Next, a description of how the transport LSP and service are monitored for >> continuity and defects. >>> >>> Finally, the behavior when resources are overbooked and what services are pre- >> empted or degraded should be described. >>> ------------------------------------ >>> >>> _______________________________________________ >>> 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 -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 30 05:52:30 2015 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 B98541B29CB for ; Thu, 30 Apr 2015 05:52:28 -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 phPsUGsCPbYI for ; Thu, 30 Apr 2015 05:52:26 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A9F1B29AD for ; Thu, 30 Apr 2015 05:52:25 -0700 (PDT) Received: by wgso17 with SMTP id o17so61242984wgs.1 for ; Thu, 30 Apr 2015 05:52:24 -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=fsT61LgkwZVf6LqMLASnBsl7fiS8zRnDxJBHkyoVTsQ=; b=B91dIa8xwgsSS91ffr83Jyi9Sqg3FJhSHYcABBOcFd6t3taKtY1RLfIBMiaWmoaMmV 6mMTSg0McVLTMtHSW2GsDGq6VODHESCmeTwekFKccCZZMFe61aUrEql8p5YTIahxHZzb hTA/i0wTXGQ/D6lEUQ/GYFAz1HbGSDpaYBknaJqpbJlfgiZb2LPFlwXX03aLogG3ihY8 0hPGyLMri5GRK5Gz0FdtVMF502ras4WyFLMrHGklw6KbvVhGhF0kZtfjBCLkPzU8nC4m kTqIFJZfnpd31YfL5ZWAp9Y+xnwe+iRmcn09S+fhvR9QmAwv0KEVkDpsmKsRhQWDnfSN ro7A== X-Received: by 10.194.78.12 with SMTP id x12mr8063614wjw.112.1430398344241; Thu, 30 Apr 2015 05:52:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.182.215 with HTTP; Thu, 30 Apr 2015 05:52:03 -0700 (PDT) In-Reply-To: <5541DC9A.5000200@pi.nu> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> From: "Andrew G. Malis" Date: Thu, 30 Apr 2015 08:52:03 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7bd917523227e30514f09160 Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 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, 30 Apr 2015 12:52:28 -0000 --047d7bd917523227e30514f09160 Content-Type: text/plain; charset=UTF-8 Loa, I think the reference that you're looking for is section 3.11 of RFC 5921. Cheers, Andy On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson wrote: > Mustapha, > > That is still not a definition possible to refrence. > > I've always been a bit confused by the distinction between "static" and > "dynamic", especially when it comes to labels, a bit less so if we talk > about LSPs. > > To me the term "static" and "dynamic" seems to indicate how long lived > or how easy they are to change. > > If an NMS or any centralized controller instal and remove LSPs/labels > with the same frequency as e.g. LDP are they still "static"? > > I agree that there is a possible classification of "configured > LSPs/labels" vs. "signaled LSPs/labels". > > In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses > configured labels. > > Would that terminology be acceptable for you? > > /Loa > > > On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote: > >> Hi Loa, >> By static label, I meant a label which is assigned to a LSP or a PW by >> configuration and not by a control plane protocol. I believe this is what >> is being described in this draft but let me know if I am wrong. >> >> Regards, >> Mustapha. >> >> -----Original Message----- >>> From: Loa Andersson [mailto:loa@pi.nu] >>> Sent: Wednesday, April 29, 2015 3:21 AM >>> To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org >>> Cc: Nevil Brownlee >>> Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 >>> >>> Mustapha, >>> >>> in line please. >>> >>> On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote: >>> >>>> Dear all, >>>> I was asked to review this draft which is intended to be handled in the >>>> >>> Independent Stream. Below are my comments to the authors. >>> >>>> >>>> Members of this list can also provide comments to the authors. Please >>>> copy the >>>> >>> Independent Submission Editorial Board at the following address: >>> >>>> rfc-ise@rfc-editor.org >>>> >>>> Regards, >>>> Mustapha. >>>> ---------------------------- >>>> https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01 >>>> >>>> 1. Overall comment: >>>> This document describes how a guaranteed bandwidth service can be >>>> deployed >>>> >>> in a MPLS network by partitioning the network resources into two managed >>> layers, >>> referred to as strata. The guaranteed service layer is referred to as >>> "Hard Pipe" >>> stratum. >>> >>>> >>>> The management of the resources and the placement of the MPLS tunnels >>>> and >>>> >>> services into the "Hard Pipe" stratum are performed with a management >>> system. >>> Thus the transport and service labels are static but this important >>> information has >>> not been stated upfront in the document. >>> >>> Do you have a a definition of "static labels" that we can refer to? >>> >>> /Loa >>> Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference >>> to T- >>> LDP signaled labels in Section 3 adds to the confusion. >>> >>>> >>>> >>> I propose that the Introduction and Scope sections be explicit about the >>>> >>> framework used to achieve the "Hard Pipe" stratum, that is by means of a >>> management system and static transport and service labels. >>> >>>> >>>> In fact, I would think the document value would be in describing more >>>> details of >>>> >>> the framework including configuration aspects, resource and service >>> management >>> including resilience. These aspects have not been sufficiently addressed >>> and the >>> focus was more on how to use MPLS labels to differentiate the two strata. >>> >>>> >>>> 2. Section 1.1 - Scope: >>>> As part of the second bullet, I cannot find in the document how a >>>> router protects >>>> >>> the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum >>> overbooks a >>> link. Having a separate label for the guaranteed service is not >>> sufficient. The >>> authors should describe if LSP pre-emption and/or QoS markings are used >>> to >>> differentiate the treatment across the strata. >>> >>>> >>>> 3. Section 3: >>>> If the document objective is to describe the framework used, then this >>>> section >>>> >>> should begin by explaining the initial configuration performed by the >>> NMS to lay >>> the ground for the building of the two stratums. This includes the >>> partitioning of the >>> links, the assignment of transport and service label ranges in the >>> routers, the >>> overbooking strategy, etc. >>> >>>> >>>> Then, you can discuss how a guaranteed service is configured in the >>>> network >>>> >>> using static transport labels and static service labels. This should >>> cover the >>> placement of the working and backup paths since Section 6 mentions >>> MPLS-TP >>> protection is used. >>> >>>> >>>> Next, a description of how the transport LSP and service are monitored >>>> for >>>> >>> continuity and defects. >>> >>>> >>>> Finally, the behavior when resources are overbooked and what services >>>> are pre- >>>> >>> empted or degraded should be described. >>> >>>> ------------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >>> >> > -- > > > 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 > --047d7bd917523227e30514f09160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

I think the reference that you'= ;re looking for is section 3.11 of RFC 5921.

Cheer= s,
Andy


=
On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson <= span dir=3D"ltr"><loa@pi.= nu> wrote:
Mustapha,

That is still not a definition possible to refrence.

I've always been a bit confused by the distinction between "static= " and
"dynamic", especially when it comes to labels, a bit less so if w= e talk
about LSPs.

To me the term=C2=A0 "static" and "dynamic" seems to in= dicate how long lived
or how easy they are to change.

If an NMS or any centralized controller instal and remove LSPs/labels
with the same frequency as e.g. LDP are they still "static"?

I agree that there is a possible classification of "configured LSPs/la= bels" vs. "signaled LSPs/labels".

In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses
configured labels.

Would that terminology be acceptable for you?

/Loa


On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote:
Hi Loa,
By static label, I meant a label which is assigned to a LSP or a PW by conf= iguration and not by a control plane protocol. I believe this is what is be= ing described in this draft but let me know if I am wrong.

Regards,
Mustapha.

-----Original Message-----
From: Loa Andersson [mailto:= loa@pi.nu]
Sent: Wednesday, April 29, 2015 3:21 AM
To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org
Cc: Nevil Brownlee
Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01

Mustapha,

in line please.

On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote:
Dear all,
I was asked to review this draft which is intended to be handled in the
Independent Stream. Below are my comments to the authors.

Members of this list can also provide comments to the authors. Please copy = the
Independent Submission Editorial Board at the following address:
rfc-ise@rfc-edi= tor.org

Regards,
Mustapha.
----------------------------
https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01

1. Overall comment:
This document describes how a guaranteed bandwidth service can be deployed<= br>
in a MPLS network by partitioning the network resources into two managed la= yers,
referred to as strata. The=C2=A0 guaranteed service layer is referred to as= "Hard Pipe"
stratum.

The management of the resources and the placement of the MPLS tunnels and
services into the=C2=A0 "Hard Pipe" stratum are performed with a = management system.
Thus the transport and service labels are static but this important informa= tion has
not been stated upfront in the document.

Do you have a a definition of "static labels" that we can refer t= o?

/Loa
Only in section 6 that MPLS-TP was mentioned. Furthermore, the reference to= T-
LDP signaled labels in Section 3 adds to the confusion.


I propose that the Introduction and Scope sections be explicit about the
framework used to achieve the "Hard Pipe" stratum, that is by mea= ns of a
management system and static transport and service labels.

In fact, I would think the document value would be in describing more detai= ls of
the framework including configuration aspects, resource and service managem= ent
including resilience. These aspects have not been sufficiently addressed an= d the
focus was more on how to use MPLS labels to differentiate the two strata.

2. Section 1.1 - Scope:
As part of the second bullet, I cannot find in the document how a router pr= otects
the traffic of the "Hard Pipe" stratum if the "Normal IP/MPL= S" stratum overbooks a
link. Having a separate label for the guaranteed service is not sufficient.= The
authors should describe if LSP pre-emption and/or QoS markings are used to<= br> differentiate the treatment across the strata.

3. Section 3:
If the document objective is to describe the framework used, then this sect= ion
should begin by explaining the initial configuration performed by the NMS t= o lay
the ground for the building of the two stratums. This includes the partitio= ning of the
links, the assignment of transport and service label ranges in the routers,= the
overbooking strategy, etc.

Then, you can discuss how a guaranteed service is configured in the network=
using static transport labels and static service labels. This should cover = the
placement of the working and backup paths since Section 6 mentions MPLS-TP<= br> protection is used.

Next, a description of how the transport LSP and service are monitored for<= br>
continuity and defects.

Finally, the behavior when resources are overbooked and what services are p= re-
empted or degraded should be described.
------------------------------------

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


--


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=A0 email: 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=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--


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=A0 email: 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=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

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

--047d7bd917523227e30514f09160-- From nobody Thu Apr 30 06:43:07 2015 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 BE94F1B2A5B for ; Thu, 30 Apr 2015 06:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 UkT8Tjq_YHsM for ; Thu, 30 Apr 2015 06:43:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FAD1B2A4A for ; Thu, 30 Apr 2015 06:42:38 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 295844D3922CB; Thu, 30 Apr 2015 13:42:33 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t3UDgP3w018150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 09:42:32 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 09:42:29 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "Andrew G. Malis" , Loa Andersson Thread-Topic: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 Thread-Index: AdCBzIr6SsqnVpHOQqOMLXhwS/KfnQAogseAAAwv7YAAKVIdvwABTeSg Date: Thu, 30 Apr 2015 13:42:28 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> 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.17] Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340D948345F6US70UWXCHMBA01z_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , Nevil Brownlee Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01 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, 30 Apr 2015 13:43:04 -0000 --_000_4A79394211F1AF4EB57D998426C9340D948345F6US70UWXCHMBA01z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFuZHkgZm9yIHRoZSByZWZlcmVuY2UuIEluZGVlZCwgSSB3YXMgcmVmZXJyaW5nIHRv IGFzc2lnbm1lbnQgb2YgaW5pdGlhbCBsYWJlbCBhbmQgb2YgYW55IHN1YnNlcXVlbnQgbGFiZWwg Y2hhbmdlIG9mIGFuIExTUCBvciBhIFBXIGJ5IGNvbmZpZ3VyYXRpb24uIFRoaXMgaXMgc29tZXRp bWVzIHJlZmVycmVkIHRvIGFzIOKAnG1hbnVhbOKAnSBjb25maWd1cmF0aW9uIGFuZCB0aGUgTFNQ IG9yIFBXIGlzIHJlZmVycmVkIHRvIGFzIHN0YXRpYy4NCg0KVGhhdCBkZWZpbml0aW9uIGZpdHMg SSBiZWxpZXZlIHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIGRyYWZ0LWhhby1tcGxzLWlwLWhh cmQtcGlwZS0wMSBidXQgTG9hIGNhbiBjb25maXJtLg0KDQpSZWdhcmRzLA0KTXVzdGFwaGEuDQoN CkZyb206IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KU2VudDog VGh1cnNkYXksIEFwcmlsIDMwLCAyMDE1IDg6NTIgQU0NClRvOiBMb2EgQW5kZXJzc29uDQpDYzog QWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IG1wbHNAaWV0Zi5vcmc7IE5ldmlsIEJyb3du bGVlDQpTdWJqZWN0OiBSZTogW21wbHNdIFJldmlldyBvZiBkcmFmdC1oYW8tbXBscy1pcC1oYXJk LXBpcGUtMDENCg0KTG9hLA0KDQpJIHRoaW5rIHRoZSByZWZlcmVuY2UgdGhhdCB5b3UncmUgbG9v a2luZyBmb3IgaXMgc2VjdGlvbiAzLjExIG9mIFJGQyA1OTIxLg0KDQpDaGVlcnMsDQpBbmR5DQoN Cg0KT24gVGh1LCBBcHIgMzAsIDIwMTUgYXQgMzo0MSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNCk11c3RhcGhhLA0KDQpUaGF0IGlzIHN0aWxs IG5vdCBhIGRlZmluaXRpb24gcG9zc2libGUgdG8gcmVmcmVuY2UuDQoNCkkndmUgYWx3YXlzIGJl ZW4gYSBiaXQgY29uZnVzZWQgYnkgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gInN0YXRpYyIgYW5k DQoiZHluYW1pYyIsIGVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byBsYWJlbHMsIGEgYml0IGxl c3Mgc28gaWYgd2UgdGFsaw0KYWJvdXQgTFNQcy4NCg0KVG8gbWUgdGhlIHRlcm0gICJzdGF0aWMi IGFuZCAiZHluYW1pYyIgc2VlbXMgdG8gaW5kaWNhdGUgaG93IGxvbmcgbGl2ZWQNCm9yIGhvdyBl YXN5IHRoZXkgYXJlIHRvIGNoYW5nZS4NCg0KSWYgYW4gTk1TIG9yIGFueSBjZW50cmFsaXplZCBj b250cm9sbGVyIGluc3RhbCBhbmQgcmVtb3ZlIExTUHMvbGFiZWxzDQp3aXRoIHRoZSBzYW1lIGZy ZXF1ZW5jeSBhcyBlLmcuIExEUCBhcmUgdGhleSBzdGlsbCAic3RhdGljIj8NCg0KSSBhZ3JlZSB0 aGF0IHRoZXJlIGlzIGEgcG9zc2libGUgY2xhc3NpZmljYXRpb24gb2YgImNvbmZpZ3VyZWQgTFNQ cy9sYWJlbHMiIHZzLiAic2lnbmFsZWQgTFNQcy9sYWJlbHMiLg0KDQpJbiB0aGF0IHRlcm1pbm9s b2d5IEknZCBzYXkgdGhhdCBkcmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUgdXNlcw0KY29uZmln dXJlZCBsYWJlbHMuDQoNCldvdWxkIHRoYXQgdGVybWlub2xvZ3kgYmUgYWNjZXB0YWJsZSBmb3Ig eW91Pw0KDQovTG9hDQoNCg0KT24gMjAxNS0wNC0yOSAxOToyNiwgQWlzc2FvdWksIE11c3RhcGhh IChNdXN0YXBoYSkgd3JvdGU6DQpIaSBMb2EsDQpCeSBzdGF0aWMgbGFiZWwsIEkgbWVhbnQgYSBs YWJlbCB3aGljaCBpcyBhc3NpZ25lZCB0byBhIExTUCBvciBhIFBXIGJ5IGNvbmZpZ3VyYXRpb24g YW5kIG5vdCBieSBhIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wuIEkgYmVsaWV2ZSB0aGlzIGlzIHdo YXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgYnV0IGxldCBtZSBrbm93IGlmIEkg YW0gd3JvbmcuDQoNClJlZ2FyZHMsDQpNdXN0YXBoYS4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGku bnU+XQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyOSwgMjAxNSAzOjIxIEFNDQpUbzogQWlzc2Fv dWksIE11c3RhcGhhIChNdXN0YXBoYSk7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+DQpDYzogTmV2aWwgQnJvd25sZWUNClN1YmplY3Q6IFJlOiBbbXBsc10gUmV2aWV3IG9mIGRy YWZ0LWhhby1tcGxzLWlwLWhhcmQtcGlwZS0wMQ0KDQpNdXN0YXBoYSwNCg0KaW4gbGluZSBwbGVh c2UuDQoNCk9uIDIwMTUtMDQtMjggMTg6MDEsIEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEp IHdyb3RlOg0KRGVhciBhbGwsDQpJIHdhcyBhc2tlZCB0byByZXZpZXcgdGhpcyBkcmFmdCB3aGlj aCBpcyBpbnRlbmRlZCB0byBiZSBoYW5kbGVkIGluIHRoZQ0KSW5kZXBlbmRlbnQgU3RyZWFtLiBC ZWxvdyBhcmUgbXkgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMuDQoNCk1lbWJlcnMgb2YgdGhpcyBs aXN0IGNhbiBhbHNvIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMuIFBsZWFzZSBjb3B5 IHRoZQ0KSW5kZXBlbmRlbnQgU3VibWlzc2lvbiBFZGl0b3JpYWwgQm9hcmQgYXQgdGhlIGZvbGxv d2luZyBhZGRyZXNzOg0KcmZjLWlzZUByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWlzZUByZmMt ZWRpdG9yLm9yZz4NCg0KUmVnYXJkcywNCk11c3RhcGhhLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhby1tcGxzLWlwLWhh cmQtcGlwZS0wMQ0KDQoxLiBPdmVyYWxsIGNvbW1lbnQ6DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBob3cgYSBndWFyYW50ZWVkIGJhbmR3aWR0aCBzZXJ2aWNlIGNhbiBiZSBkZXBsb3llZA0KaW4g YSBNUExTIG5ldHdvcmsgYnkgcGFydGl0aW9uaW5nIHRoZSBuZXR3b3JrIHJlc291cmNlcyBpbnRv IHR3byBtYW5hZ2VkIGxheWVycywNCnJlZmVycmVkIHRvIGFzIHN0cmF0YS4gVGhlICBndWFyYW50 ZWVkIHNlcnZpY2UgbGF5ZXIgaXMgcmVmZXJyZWQgdG8gYXMgIkhhcmQgUGlwZSINCnN0cmF0dW0u DQoNClRoZSBtYW5hZ2VtZW50IG9mIHRoZSByZXNvdXJjZXMgYW5kIHRoZSBwbGFjZW1lbnQgb2Yg dGhlIE1QTFMgdHVubmVscyBhbmQNCnNlcnZpY2VzIGludG8gdGhlICAiSGFyZCBQaXBlIiBzdHJh dHVtIGFyZSBwZXJmb3JtZWQgd2l0aCBhIG1hbmFnZW1lbnQgc3lzdGVtLg0KVGh1cyB0aGUgdHJh bnNwb3J0IGFuZCBzZXJ2aWNlIGxhYmVscyBhcmUgc3RhdGljIGJ1dCB0aGlzIGltcG9ydGFudCBp bmZvcm1hdGlvbiBoYXMNCm5vdCBiZWVuIHN0YXRlZCB1cGZyb250IGluIHRoZSBkb2N1bWVudC4N Cg0KRG8geW91IGhhdmUgYSBhIGRlZmluaXRpb24gb2YgInN0YXRpYyBsYWJlbHMiIHRoYXQgd2Ug Y2FuIHJlZmVyIHRvPw0KDQovTG9hDQpPbmx5IGluIHNlY3Rpb24gNiB0aGF0IE1QTFMtVFAgd2Fz IG1lbnRpb25lZC4gRnVydGhlcm1vcmUsIHRoZSByZWZlcmVuY2UgdG8gVC0NCkxEUCBzaWduYWxl ZCBsYWJlbHMgaW4gU2VjdGlvbiAzIGFkZHMgdG8gdGhlIGNvbmZ1c2lvbi4NCg0KDQpJIHByb3Bv c2UgdGhhdCB0aGUgSW50cm9kdWN0aW9uIGFuZCBTY29wZSBzZWN0aW9ucyBiZSBleHBsaWNpdCBh Ym91dCB0aGUNCmZyYW1ld29yayB1c2VkIHRvIGFjaGlldmUgdGhlICJIYXJkIFBpcGUiIHN0cmF0 dW0sIHRoYXQgaXMgYnkgbWVhbnMgb2YgYQ0KbWFuYWdlbWVudCBzeXN0ZW0gYW5kIHN0YXRpYyB0 cmFuc3BvcnQgYW5kIHNlcnZpY2UgbGFiZWxzLg0KDQpJbiBmYWN0LCBJIHdvdWxkIHRoaW5rIHRo ZSBkb2N1bWVudCB2YWx1ZSB3b3VsZCBiZSBpbiBkZXNjcmliaW5nIG1vcmUgZGV0YWlscyBvZg0K dGhlIGZyYW1ld29yayBpbmNsdWRpbmcgY29uZmlndXJhdGlvbiBhc3BlY3RzLCByZXNvdXJjZSBh bmQgc2VydmljZSBtYW5hZ2VtZW50DQppbmNsdWRpbmcgcmVzaWxpZW5jZS4gVGhlc2UgYXNwZWN0 cyBoYXZlIG5vdCBiZWVuIHN1ZmZpY2llbnRseSBhZGRyZXNzZWQgYW5kIHRoZQ0KZm9jdXMgd2Fz IG1vcmUgb24gaG93IHRvIHVzZSBNUExTIGxhYmVscyB0byBkaWZmZXJlbnRpYXRlIHRoZSB0d28g c3RyYXRhLg0KDQoyLiBTZWN0aW9uIDEuMSAtIFNjb3BlOg0KQXMgcGFydCBvZiB0aGUgc2Vjb25k IGJ1bGxldCwgSSBjYW5ub3QgZmluZCBpbiB0aGUgZG9jdW1lbnQgaG93IGEgcm91dGVyIHByb3Rl Y3RzDQp0aGUgdHJhZmZpYyBvZiB0aGUgIkhhcmQgUGlwZSIgc3RyYXR1bSBpZiB0aGUgIk5vcm1h bCBJUC9NUExTIiBzdHJhdHVtIG92ZXJib29rcyBhDQpsaW5rLiBIYXZpbmcgYSBzZXBhcmF0ZSBs YWJlbCBmb3IgdGhlIGd1YXJhbnRlZWQgc2VydmljZSBpcyBub3Qgc3VmZmljaWVudC4gVGhlDQph dXRob3JzIHNob3VsZCBkZXNjcmliZSBpZiBMU1AgcHJlLWVtcHRpb24gYW5kL29yIFFvUyBtYXJr aW5ncyBhcmUgdXNlZCB0bw0KZGlmZmVyZW50aWF0ZSB0aGUgdHJlYXRtZW50IGFjcm9zcyB0aGUg c3RyYXRhLg0KDQozLiBTZWN0aW9uIDM6DQpJZiB0aGUgZG9jdW1lbnQgb2JqZWN0aXZlIGlzIHRv IGRlc2NyaWJlIHRoZSBmcmFtZXdvcmsgdXNlZCwgdGhlbiB0aGlzIHNlY3Rpb24NCnNob3VsZCBi ZWdpbiBieSBleHBsYWluaW5nIHRoZSBpbml0aWFsIGNvbmZpZ3VyYXRpb24gcGVyZm9ybWVkIGJ5 IHRoZSBOTVMgdG8gbGF5DQp0aGUgZ3JvdW5kIGZvciB0aGUgYnVpbGRpbmcgb2YgdGhlIHR3byBz dHJhdHVtcy4gVGhpcyBpbmNsdWRlcyB0aGUgcGFydGl0aW9uaW5nIG9mIHRoZQ0KbGlua3MsIHRo ZSBhc3NpZ25tZW50IG9mIHRyYW5zcG9ydCBhbmQgc2VydmljZSBsYWJlbCByYW5nZXMgaW4gdGhl IHJvdXRlcnMsIHRoZQ0Kb3ZlcmJvb2tpbmcgc3RyYXRlZ3ksIGV0Yy4NCg0KVGhlbiwgeW91IGNh biBkaXNjdXNzIGhvdyBhIGd1YXJhbnRlZWQgc2VydmljZSBpcyBjb25maWd1cmVkIGluIHRoZSBu ZXR3b3JrDQp1c2luZyBzdGF0aWMgdHJhbnNwb3J0IGxhYmVscyBhbmQgc3RhdGljIHNlcnZpY2Ug bGFiZWxzLiBUaGlzIHNob3VsZCBjb3ZlciB0aGUNCnBsYWNlbWVudCBvZiB0aGUgd29ya2luZyBh bmQgYmFja3VwIHBhdGhzIHNpbmNlIFNlY3Rpb24gNiBtZW50aW9ucyBNUExTLVRQDQpwcm90ZWN0 aW9uIGlzIHVzZWQuDQoNCk5leHQsIGEgZGVzY3JpcHRpb24gb2YgaG93IHRoZSB0cmFuc3BvcnQg TFNQIGFuZCBzZXJ2aWNlIGFyZSBtb25pdG9yZWQgZm9yDQpjb250aW51aXR5IGFuZCBkZWZlY3Rz Lg0KDQpGaW5hbGx5LCB0aGUgYmVoYXZpb3Igd2hlbiByZXNvdXJjZXMgYXJlIG92ZXJib29rZWQg YW5kIHdoYXQgc2VydmljZXMgYXJlIHByZS0NCmVtcHRlZCBvciBkZWdyYWRlZCBzaG91bGQgYmUg ZGVzY3JpYmVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcg bGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzps b2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDcz OSUyMDgxJTIwMjElMjA2ND4NCg0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAg ICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5o dWF3ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBs b2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIx JTIwNjQ+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= --_000_4A79394211F1AF4EB57D998426C9340D948345F6US70UWXCHMBA01z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFt ZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhh bmtzIEFuZHkgZm9yIHRoZSByZWZlcmVuY2UuIEluZGVlZCwgSSB3YXMgcmVmZXJyaW5nIHRvIGFz c2lnbm1lbnQgb2YgaW5pdGlhbCBsYWJlbCBhbmQgb2YgYW55IHN1YnNlcXVlbnQgbGFiZWwgY2hh bmdlIG9mIGFuIExTUCBvciBhIFBXIGJ5IGNvbmZpZ3VyYXRpb24uIFRoaXMgaXMgc29tZXRpbWVz DQogcmVmZXJyZWQgdG8gYXMg4oCcbWFudWFs4oCdIGNvbmZpZ3VyYXRpb24gYW5kIHRoZSBMU1Ag b3IgUFcgaXMgcmVmZXJyZWQgdG8gYXMgc3RhdGljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlRoYXQgZGVmaW5pdGlvbiBmaXRzIEkgYmVsaWV2ZSB3aGF0IGlzIGJlaW5nIGRl c2NyaWJlZCBpbiBkcmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUtMDEgYnV0IExvYSBjYW4gY29u ZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPk11c3RhcGhhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHJldyBHLiBN YWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBBcHJpbCAzMCwgMjAxNSA4OjUyIEFNPGJyPg0KPGI+VG86PC9iPiBMb2EgQW5kZXJzc29u PGJyPg0KPGI+Q2M6PC9iPiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgbXBsc0BpZXRm Lm9yZzsgTmV2aWwgQnJvd25sZWU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxzXSBSZXZp ZXcgb2YgZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvYSw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIHJlZmVyZW5jZSB0aGF0IHlv dSdyZSBsb29raW5nIGZvciBpcyBzZWN0aW9uIDMuMTEgb2YgUkZDIDU5MjEuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IEFwciAzMCwgMjAxNSBhdCAzOjQxIEFNLCBMb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJtYWls dG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NdXN0YXBoYSw8YnI+DQo8YnI+DQpU aGF0IGlzIHN0aWxsIG5vdCBhIGRlZmluaXRpb24gcG9zc2libGUgdG8gcmVmcmVuY2UuPGJyPg0K PGJyPg0KSSd2ZSBhbHdheXMgYmVlbiBhIGJpdCBjb25mdXNlZCBieSB0aGUgZGlzdGluY3Rpb24g YmV0d2VlbiAmcXVvdDtzdGF0aWMmcXVvdDsgYW5kPGJyPg0KJnF1b3Q7ZHluYW1pYyZxdW90Oywg ZXNwZWNpYWxseSB3aGVuIGl0IGNvbWVzIHRvIGxhYmVscywgYSBiaXQgbGVzcyBzbyBpZiB3ZSB0 YWxrPGJyPg0KYWJvdXQgTFNQcy48YnI+DQo8YnI+DQpUbyBtZSB0aGUgdGVybSZuYnNwOyAmcXVv dDtzdGF0aWMmcXVvdDsgYW5kICZxdW90O2R5bmFtaWMmcXVvdDsgc2VlbXMgdG8gaW5kaWNhdGUg aG93IGxvbmcgbGl2ZWQ8YnI+DQpvciBob3cgZWFzeSB0aGV5IGFyZSB0byBjaGFuZ2UuPGJyPg0K PGJyPg0KSWYgYW4gTk1TIG9yIGFueSBjZW50cmFsaXplZCBjb250cm9sbGVyIGluc3RhbCBhbmQg cmVtb3ZlIExTUHMvbGFiZWxzPGJyPg0Kd2l0aCB0aGUgc2FtZSBmcmVxdWVuY3kgYXMgZS5nLiBM RFAgYXJlIHRoZXkgc3RpbGwgJnF1b3Q7c3RhdGljJnF1b3Q7Pzxicj4NCjxicj4NCkkgYWdyZWUg dGhhdCB0aGVyZSBpcyBhIHBvc3NpYmxlIGNsYXNzaWZpY2F0aW9uIG9mICZxdW90O2NvbmZpZ3Vy ZWQgTFNQcy9sYWJlbHMmcXVvdDsgdnMuICZxdW90O3NpZ25hbGVkIExTUHMvbGFiZWxzJnF1b3Q7 Ljxicj4NCjxicj4NCkluIHRoYXQgdGVybWlub2xvZ3kgSSdkIHNheSB0aGF0IGRyYWZ0LWhhby1t cGxzLWlwLWhhcmQtcGlwZSB1c2VzPGJyPg0KY29uZmlndXJlZCBsYWJlbHMuPGJyPg0KPGJyPg0K V291bGQgdGhhdCB0ZXJtaW5vbG9neSBiZSBhY2NlcHRhYmxlIGZvciB5b3U/PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi9Mb2E8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQpPbiAyMDE1LTA0LTI5IDE5OjI2LCBBaXNzYW91aSwgTXVzdGFwaGEg KE11c3RhcGhhKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgTG9hLDxicj4NCkJ5IHN0YXRpYyBsYWJlbCwg SSBtZWFudCBhIGxhYmVsIHdoaWNoIGlzIGFzc2lnbmVkIHRvIGEgTFNQIG9yIGEgUFcgYnkgY29u ZmlndXJhdGlvbiBhbmQgbm90IGJ5IGEgY29udHJvbCBwbGFuZSBwcm90b2NvbC4gSSBiZWxpZXZl IHRoaXMgaXMgd2hhdCBpcyBiZWluZyBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBidXQgbGV0IG1l IGtub3cgaWYgSSBhbSB3cm9uZy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCk11c3RhcGhhLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxv YUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT5dPGJyPg0KU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAyOSwgMjAxNSAzOjIxIEFNPGJyPg0KVG86IEFpc3Nhb3VpLCBNdXN0YXBoYSAo TXVzdGFwaGEpOyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KbXBsc0BpZXRmLm9yZzwvYT48YnI+DQpDYzogTmV2aWwgQnJvd25sZWU8YnI+DQpTdWJqZWN0 OiBSZTogW21wbHNdIFJldmlldyBvZiBkcmFmdC1oYW8tbXBscy1pcC1oYXJkLXBpcGUtMDE8YnI+ DQo8YnI+DQpNdXN0YXBoYSw8YnI+DQo8YnI+DQppbiBsaW5lIHBsZWFzZS48YnI+DQo8YnI+DQpP biAyMDE1LTA0LTI4IDE4OjAxLCBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKSB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLDxicj4NCkkgd2Fz IGFza2VkIHRvIHJldmlldyB0aGlzIGRyYWZ0IHdoaWNoIGlzIGludGVuZGVkIHRvIGJlIGhhbmRs ZWQgaW4gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlcGVuZGVu dCBTdHJlYW0uIEJlbG93IGFyZSBteSBjb21tZW50cyB0byB0aGUgYXV0aG9ycy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk1lbWJlcnMgb2YgdGhpcyBsaXN0IGNh biBhbHNvIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMuIFBsZWFzZSBjb3B5IHRoZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5kZXBlbmRlbnQgU3VibWlzc2lv biBFZGl0b3JpYWwgQm9hcmQgYXQgdGhlIGZvbGxvd2luZyBhZGRyZXNzOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRv ci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtaXNlQHJmYy1lZGl0b3Iub3JnPC9hPjxicj4NCjxi cj4NClJlZ2FyZHMsPGJyPg0KTXVzdGFwaGEuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYW8t bXBscy1pcC1oYXJkLXBpcGUtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFvLW1wbHMtaXAtaGFyZC1waXBlLTAxPC9hPjxicj4NCjxicj4NCjEu IE92ZXJhbGwgY29tbWVudDo8YnI+DQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBndWFy YW50ZWVkIGJhbmR3aWR0aCBzZXJ2aWNlIGNhbiBiZSBkZXBsb3llZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gYSBNUExTIG5ldHdvcmsgYnkgcGFydGl0aW9uaW5nIHRo ZSBuZXR3b3JrIHJlc291cmNlcyBpbnRvIHR3byBtYW5hZ2VkIGxheWVycyw8YnI+DQpyZWZlcnJl ZCB0byBhcyBzdHJhdGEuIFRoZSZuYnNwOyBndWFyYW50ZWVkIHNlcnZpY2UgbGF5ZXIgaXMgcmVm ZXJyZWQgdG8gYXMgJnF1b3Q7SGFyZCBQaXBlJnF1b3Q7PGJyPg0Kc3RyYXR1bS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBtYW5hZ2VtZW50IG9mIHRoZSBy ZXNvdXJjZXMgYW5kIHRoZSBwbGFjZW1lbnQgb2YgdGhlIE1QTFMgdHVubmVscyBhbmQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNlcnZpY2VzIGludG8gdGhlJm5ic3A7ICZx dW90O0hhcmQgUGlwZSZxdW90OyBzdHJhdHVtIGFyZSBwZXJmb3JtZWQgd2l0aCBhIG1hbmFnZW1l bnQgc3lzdGVtLjxicj4NClRodXMgdGhlIHRyYW5zcG9ydCBhbmQgc2VydmljZSBsYWJlbHMgYXJl IHN0YXRpYyBidXQgdGhpcyBpbXBvcnRhbnQgaW5mb3JtYXRpb24gaGFzPGJyPg0Kbm90IGJlZW4g c3RhdGVkIHVwZnJvbnQgaW4gdGhlIGRvY3VtZW50Ljxicj4NCjxicj4NCkRvIHlvdSBoYXZlIGEg YSBkZWZpbml0aW9uIG9mICZxdW90O3N0YXRpYyBsYWJlbHMmcXVvdDsgdGhhdCB3ZSBjYW4gcmVm ZXIgdG8/PGJyPg0KPGJyPg0KL0xvYTxicj4NCk9ubHkgaW4gc2VjdGlvbiA2IHRoYXQgTVBMUy1U UCB3YXMgbWVudGlvbmVkLiBGdXJ0aGVybW9yZSwgdGhlIHJlZmVyZW5jZSB0byBULTxicj4NCkxE UCBzaWduYWxlZCBsYWJlbHMgaW4gU2VjdGlvbiAzIGFkZHMgdG8gdGhlIGNvbmZ1c2lvbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwcm9wb3NlIHRoYXQgdGhlIEludHJvZHVjdGlvbiBhbmQg U2NvcGUgc2VjdGlvbnMgYmUgZXhwbGljaXQgYWJvdXQgdGhlPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mcmFtZXdvcmsgdXNlZCB0byBhY2hpZXZl IHRoZSAmcXVvdDtIYXJkIFBpcGUmcXVvdDsgc3RyYXR1bSwgdGhhdCBpcyBieSBtZWFucyBvZiBh PGJyPg0KbWFuYWdlbWVudCBzeXN0ZW0gYW5kIHN0YXRpYyB0cmFuc3BvcnQgYW5kIHNlcnZpY2Ug bGFiZWxzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSW4gZmFj dCwgSSB3b3VsZCB0aGluayB0aGUgZG9jdW1lbnQgdmFsdWUgd291bGQgYmUgaW4gZGVzY3JpYmlu ZyBtb3JlIGRldGFpbHMgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRo ZSBmcmFtZXdvcmsgaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gYXNwZWN0cywgcmVzb3VyY2UgYW5k IHNlcnZpY2UgbWFuYWdlbWVudDxicj4NCmluY2x1ZGluZyByZXNpbGllbmNlLiBUaGVzZSBhc3Bl Y3RzIGhhdmUgbm90IGJlZW4gc3VmZmljaWVudGx5IGFkZHJlc3NlZCBhbmQgdGhlPGJyPg0KZm9j dXMgd2FzIG1vcmUgb24gaG93IHRvIHVzZSBNUExTIGxhYmVscyB0byBkaWZmZXJlbnRpYXRlIHRo ZSB0d28gc3RyYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K Mi4gU2VjdGlvbiAxLjEgLSBTY29wZTo8YnI+DQpBcyBwYXJ0IG9mIHRoZSBzZWNvbmQgYnVsbGV0 LCBJIGNhbm5vdCBmaW5kIGluIHRoZSBkb2N1bWVudCBob3cgYSByb3V0ZXIgcHJvdGVjdHM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSB0cmFmZmljIG9mIHRoZSAmcXVv dDtIYXJkIFBpcGUmcXVvdDsgc3RyYXR1bSBpZiB0aGUgJnF1b3Q7Tm9ybWFsIElQL01QTFMmcXVv dDsgc3RyYXR1bSBvdmVyYm9va3MgYTxicj4NCmxpbmsuIEhhdmluZyBhIHNlcGFyYXRlIGxhYmVs IGZvciB0aGUgZ3VhcmFudGVlZCBzZXJ2aWNlIGlzIG5vdCBzdWZmaWNpZW50LiBUaGU8YnI+DQph dXRob3JzIHNob3VsZCBkZXNjcmliZSBpZiBMU1AgcHJlLWVtcHRpb24gYW5kL29yIFFvUyBtYXJr aW5ncyBhcmUgdXNlZCB0bzxicj4NCmRpZmZlcmVudGlhdGUgdGhlIHRyZWF0bWVudCBhY3Jvc3Mg dGhlIHN0cmF0YS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjMu IFNlY3Rpb24gMzo8YnI+DQpJZiB0aGUgZG9jdW1lbnQgb2JqZWN0aXZlIGlzIHRvIGRlc2NyaWJl IHRoZSBmcmFtZXdvcmsgdXNlZCwgdGhlbiB0aGlzIHNlY3Rpb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnNob3VsZCBiZWdpbiBieSBleHBsYWluaW5nIHRoZSBpbml0aWFs IGNvbmZpZ3VyYXRpb24gcGVyZm9ybWVkIGJ5IHRoZSBOTVMgdG8gbGF5PGJyPg0KdGhlIGdyb3Vu ZCBmb3IgdGhlIGJ1aWxkaW5nIG9mIHRoZSB0d28gc3RyYXR1bXMuIFRoaXMgaW5jbHVkZXMgdGhl IHBhcnRpdGlvbmluZyBvZiB0aGU8YnI+DQpsaW5rcywgdGhlIGFzc2lnbm1lbnQgb2YgdHJhbnNw b3J0IGFuZCBzZXJ2aWNlIGxhYmVsIHJhbmdlcyBpbiB0aGUgcm91dGVycywgdGhlPGJyPg0Kb3Zl cmJvb2tpbmcgc3RyYXRlZ3ksIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NClRoZW4sIHlvdSBjYW4gZGlzY3VzcyBob3cgYSBndWFyYW50ZWVkIHNlcnZpY2Ug aXMgY29uZmlndXJlZCBpbiB0aGUgbmV0d29yazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dXNpbmcgc3RhdGljIHRyYW5zcG9ydCBsYWJlbHMgYW5kIHN0YXRpYyBzZXJ2aWNl IGxhYmVscy4gVGhpcyBzaG91bGQgY292ZXIgdGhlPGJyPg0KcGxhY2VtZW50IG9mIHRoZSB3b3Jr aW5nIGFuZCBiYWNrdXAgcGF0aHMgc2luY2UgU2VjdGlvbiA2IG1lbnRpb25zIE1QTFMtVFA8YnI+ DQpwcm90ZWN0aW9uIGlzIHVzZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpOZXh0LCBhIGRlc2NyaXB0aW9uIG9mIGhvdyB0aGUgdHJhbnNwb3J0IExTUCBhbmQg c2VydmljZSBhcmUgbW9uaXRvcmVkIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Y29udGludWl0eSBhbmQgZGVmZWN0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCkZpbmFsbHksIHRoZSBiZWhhdmlvciB3aGVuIHJlc291cmNlcyBhcmUg b3ZlcmJvb2tlZCBhbmQgd2hhdCBzZXJ2aWNlcyBhcmUgcHJlLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+ZW1wdGVkIG9yIGRlZ3JhZGVkIHNob3VsZCBiZSBkZXNjcmliZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBs cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KLS08YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6IDxhIGhyZWY9Im1haWx0bzpsb2FAbWFpbDAx Lmh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT48 YnI+DQpTZW5pb3IgTVBMUyBFeHBlcnQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQHBpLm51PC9h Pjxicj4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpJm5ic3A7ICZuYnNwOyAmbmJz cDtwaG9uZTogPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0IiB0YXJnZXQ9 Il9ibGFuayI+DQomIzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWls MDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29tPC9h Pjxicj4NClNlbmlvciBNUExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8 L2E+PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZu YnNwO3Bob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRhcmdl dD0iX2JsYW5rIj4NCiYjNDM7NDYgNzM5IDgxIDIxIDY0PC9hPjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A79394211F1AF4EB57D998426C9340D948345F6US70UWXCHMBA01z_-- From nobody Thu Apr 30 10:21:48 2015 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 C650A1AC82C; Thu, 30 Apr 2015 10:21: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 c9cpClZ1f3Em; Thu, 30 Apr 2015 10:21:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8AE1B2E63; Thu, 30 Apr 2015 10:21:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430172144.2030.23494.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 10:21:44 -0700 Archived-At: Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to RFC 4090 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, 30 Apr 2015 17:21:47 -0000 Dear Alia Atlas, George Swallow, Ping Pan: An IPR disclosure that pertains to your RFC entitled "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (RFC4090) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2589/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to RFC 4090" Thank you IETF Secretariat From nobody Thu Apr 30 11:42:27 2015 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 550F11B2EB0; Thu, 30 Apr 2015 11:42:25 -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 NxieTIQHv35H; Thu, 30 Apr 2015 11:42:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 199DB1B2EB9; Thu, 30 Apr 2015 11:42:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430184222.14555.96844.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 11:42:22 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kompella-mpls-larp-03.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, 30 Apr 2015 18:42:25 -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 Distribution Using ARP Authors : Kireeti Kompella Balaji Rajagopalan George Swallow Filename : draft-kompella-mpls-larp-03.txt Pages : 12 Date : 2015-04-30 Abstract: This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS, which is a key goal of the MPLS Fabric architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-kompella-mpls-larp-03 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-kompella-mpls-larp-03 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 Apr 30 11:48:46 2015 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 C3CA71B2EE3 for ; Thu, 30 Apr 2015 11:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0PImU0q6hcQ0 for ; Thu, 30 Apr 2015 11:48:43 -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 5A9421B2EE0 for ; Thu, 30 Apr 2015 11:48:38 -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 BVN39446; Thu, 30 Apr 2015 18:48:37 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 30 Apr 2015 19:48:36 +0100 Received: from SZXEMA507-MBS.china.huawei.com ([169.254.6.245]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Fri, 1 May 2015 02:48:29 +0800 From: "Hejia (Jia)" To: "mpls-chairs@tools.ietf.org" , "draft-cui-mpls-tp-mfp-use-case-and-requirements@tools.ietf.org" , "Tarek Saad (tsaad) (tsaad@cisco.com)" Thread-Topic: [mpls] MPLS-RT: review draft-cui-mpls-tp-mfp-use-case-and-requirements Thread-Index: AdCBEkfRWmDxoH6BS+CweN6nbjZ39gAtqGVb Date: Thu, 30 Apr 2015 18:48:30 +0000 Message-ID: <735916399E11684EAF4EB4FB376B719551B5BC5E@szxema507-mbs.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B962C8D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B962C8D@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.233.78] Content-Type: multipart/alternative; boundary="_000_735916399E11684EAF4EB4FB376B719551B5BC5Eszxema507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT: review draft-cui-mpls-tp-mfp-use-case-and-requirements 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, 30 Apr 2015 18:48:45 -0000 --_000_735916399E11684EAF4EB4FB376B719551B5BC5Eszxema507mbschi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, I have finished reviewing draft-cui-mpls-tp-mfp-use-case-and-requirements a= s the member of MPLS Review team and have the following comments: * Is the document coherent? Yes. It describes the rational to complement current MPLS-TP linear protect= ion mechanisms with m:n protection scheme. * Is it useful (i.e., is it likely to be actually useful in operational net= works), and is the document technically sound? Yes, but it is useful in specific scenarios as indicated by the draft, not = all cases. And it may cost much more resources than usual 1+1/1:1 protectio= n, depending on the value m for example in case of m:1 protection. Therefor= e, it is better to point out as well in the draft the resource cost for m:1= and m:n protection for deployment consideration. * Is the document ready to be considered for WG adoption? Yes. But I have the following comments which appreciate consideration when = further developing this document. 1) Broadcast bridge: The description of broadcast bridge in Section 3 =93At the Node A and in the absence of faults, traffic is transported over = its respective working entity and may be simultaneously transported over on= e of its protection entities (in case of a broadcast bridge),=85.=94 However, in both ITU-T G.870 and IETF RFC4427, only in the event of protect= ion switching (e.g. in case of fault on the working entity) the normal traf= fic signal is additionally connected to the protection transport entity in = case of a broadcast bridge. Therefore, it is suggested to adjust the descri= ption in this paragraph to follow the definition in RFC4427 and ITU G.870 a= bout broadcast bridge. 2) Resource cost for m:1 and m:n protection As indicated above, it is suggested to add consideration for resource cost = of m:1 and m:n protection in Section 4.1 and Section 4.2 respectively. 3) =93Must=94 or =93May(optional)=94? Section 5 uses =93Must=94 to describe the requirements of MPLS-TP m:1 and m= :n. I=92m wondering if it is more reasonable to use =93May (optional)=94 si= nce it is more typical in some special use cases. B.R. Jia --_000_735916399E11684EAF4EB4FB376B719551B5BC5Eszxema507mbschi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have finished reviewing draft-cui-mpls-tp-m= fp-use-case-and-requirements as the member of MPLS Review team and have the following comments:

  

* Is the document coherent?

Yes. It describes the rational to complement current MPLS-TP linear protect= ion mechanisms with m:n protection scheme.


* Is it useful (i.e., is it likely to be actually useful in operational net= works), and is the document technically sound?

Yes, but it is useful in specific scenarios as indicated by the draft, not all cases. And it may cost much more resour= ces than usual 1+1/1:1 protection, depending on the value m for example= in case of m:1 protection. Therefore, it is better to point out as well in= the draft the resource cost for m:1 and m:n protection for deployment consideration. =

 

 

* Is the document ready to be considered for WG adoption?

Yes. But I have the following comments which appreciate consideration when further developing this document.=

 

1)  = ;  Broadcast bridge:

The description of broadcast bridge in Section 3=

=93At t= he Node A and in the absence of faults, traffic is transported over its respective= working entity and may be simultaneously transported over one of its prote= ction entities (in case of a broadcast bridge),=85.=94

However, in both ITU-T G.870 and IETF RFC4427, o= nly in the event of protection switching (e.g. in case of fault on the working entity) the normal traffic signal is= additionally connected to the protection transport entity in case of a bro= adcast bridge. Therefore, it is suggested to adjust the description in this= paragraph to follow the definition in RFC4427 and ITU G.870 about broadcast bridge.<= /span>

 

2)  = ;  Resource cost for m= :1 and m:n protection

As indicated above, it is suggested to add consi= deration for resource cost of m:1 and m:n protection in Section 4.1 and Section 4.2 respectively.<= /span>

 

3)  = ;  =93Must=94 or =93May(optional)= =94?

Section 5 uses =93Must=94 to describe the requirements of MPLS-TP m:1 and m:n. I=92m wondering if it is more rea= sonable to use =93May (optional)=94 since it is more typical in some specia= l use cases.

 

B.R.

Jia

--_000_735916399E11684EAF4EB4FB376B719551B5BC5Eszxema507mbschi_--