From nobody Mon Jun 2 05:38:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E311A030B for ; Mon, 2 Jun 2014 05:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y2Wm0vks9xS for ; Mon, 2 Jun 2014 05:38:44 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16B11A0218 for ; Mon, 2 Jun 2014 05:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6688; q=dns/txt; s=iport; t=1401712719; x=1402922319; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=aVWeovNLbgJAXMpVlceJUfDoyet1efr7NSz7WWke/Mk=; b=BKlUKvoUvIAGxlaug/KN9nEh0rPfDw1dRBAI06yqm8b/vf7f6gUpVant AZDxOfc4sq0ZP2ftmMDcxvKD4O8WhObxIXJ52xQGD+aP+p0bLoZSv7W73 YVqPWCnJ+YslGkDTX2qae71YR+1CQh0NYEdUMThr5jRgY78zH1SD97eyk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIJvjFOtJA2M/2dsb2JhbABZgwdSWIJsuC6HORp3FnSCJQEBAQQBAQExNwMLDgQBCBgEKAQZDAsnBA4FiEINk2qcGAakRhMEBIEgiA+EPQoHAR0YG4J2gVEEmgCTLYM4gW0JFyI X-IronPort-AV: E=Sophos;i="4.98,957,1392163200"; d="scan'208";a="49365142" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 02 Jun 2014 12:38:37 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s52Ccbeu007864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 12:38:37 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 2 Jun 2014 07:38:37 -0500 From: "Tarek Saad (tsaad)" To: Sriganesh Kini Thread-Topic: [mpls] MPLS-RT review of draft-tsaad-mpls-p2mp-loose-path-reopt Thread-Index: AQHPfl+Sg1btUg1vD0GdquMf3oWi8g== Date: Mon, 2 Jun 2014 12:38:36 +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.1.140326 x-originating-ip: [10.21.79.99] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dDAqAxFfIwdi8vFhlecM_uLKO5c Cc: "draft-tsaad-mpls-p2mp-loose-path-reopt@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-tsaad-mpls-p2mp-loose-path-reopt 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, 02 Jun 2014 12:38:46 -0000 SGkgU3JpLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2UgZmlu ZCByZXNwb25zZXMgaW5saW5lLg0KDQpPbiAyMDE0LTA1LTE5LCA2OjEwIFBNLCAiU3JpZ2FuZXNo IEtpbmkiIDxzcmlnYW5lc2gua2luaUBlcmljc3Nvbi5jb20+DQp3cm90ZToNCg0KPkhlbGxvLA0K Pg0KPlNvbWUgcmV2aWV3IGNvbW1lbnRzIGFyZSBiZWxvdy4gT3ZlcmFsbCwgdGhlIGRyYWZ0IGlz IGFkZHJlc3NpbmcgYQ0KPnVzZWZ1bC1wcm9ibGVtIGJ1dCBpcyBub3QgY29oZXJlbnQuIEkgdGhp bmsgdGhlIHByb2JsZW0gc3RhdGVtZW50IGhhcyB0bw0KPmJlIGNsZWFybHkgZGVmaW5lZCBhbmQg dGVybWlub2xvZ3kgZml4ZWQgYmVmb3JlIHRoZSBkcmFmdCBwcm9jZWVkcyB0byBXRw0KPmFjY2Vw dGFuY2UgY2FsbC4NCj4NCj4NCj4xLiBBYnN0cmFjdCBzaG91bGQgc3RhdGUgdGhhdCB0aGUgc3Bl Y2lmaWMgbGltaXRhdGlvbiBiZWluZyBhZGRyZXNzZWQgaXMNCj5vbmUgb2YgdHJlZS1vcHRpbWl6 YXRpb24gYXMgb3Bwb3NlZCB0byB0aGUgaW5kaXZpZHVhbCBzdWItTFNQDQo+cmUtb3B0aW1pemF0 aW9uIHRoYXQgaXMgYWxyZWFkeSBkZWZpbmVkLg0KW1RTXTogd2lsbCByZXZpc2UgdG86DQoiRm9y IGEgVHJhZmZpYyBFbmdpbmVlcmVkIChURSkgcG9pbnQtdG8tbXVsdGlwb2ludCAoUDJNUCkgTGFi ZWwgU3dpdGNoZWQNClBhdGggKExTUCksIGl0IGlzIHByZWZlcmFibGUgaW4gc29tZSBjYXNlcyB0 byByZS1ldmFsdWF0ZSBhbmQgcmVvcHRpbWl6ZQ0KdGhlIGVudGlyZSBQMk1QLVRFIExTUCBieSBy ZXNpZ25hbGluZyBhbGwgaXRzIFMyTCBzdWItTFNQKHMpLiBFeGlzdGluZw0KbWVjaGFuaXNtcyBh bGxvdyB0aGUgcGF0aCByZS1ldmFsdWF0aW9uIGFuZCB0aGUgc2lnbmFsbGluZyBvZiBhIHRoZQ0K bm90aWZpY2F0aW9uIG9mIHByZWZlcnJlZCBwYXRoIGV4aXN0cyBmb3IgYSBzaW5nbGUgUzJMIHN1 Yi1MU1Agb25seS4NCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIFJTVlAtVEUgc2lnbmFsaW5nIGV4 dGVuc2lvbnMgdG8gYWxsb3cgYW4gaW5ncmVzcw0KTGFiZWwgU3dpdGNoaW5nIFJvdXRlciAoTFNS KSBvZiBhIFAyTVAtVEUgTFNQIHRvIHRyaWdnZXIgdGhlIHJlLWV2YWx1YXRpb24NCm9mIHRoZSBl bnRpcmUgTFNQIHRyZWUgY29udGFpbmluZyBvbmUgb3JlIG1vcmUgUzJMIHN1Yi1MU1BzIHdob3Nl IHBhdGhzDQphcmUgbG9vc2UgKG9yIGFic3RyYWN0KSBob3AgZXhwYW5kZWQsIGFuZCBmb3IgYSBt aWRwb2ludCBMU1IgdG8gc2lnbmFsIHRvDQp0aGUgaW5ncmVzcyBMU1IgdGhhdCBhIGJldHRlciB0 cmVlIGV4aXN0cyBmb3IgdGhlIGVudGlyZSBQMk1QLVRFIExTUC4iDQoNCg0KPg0KPjIuIFRoZSAi ZWdyZXNzIGJvcmRlciIgbm9kZSB1c2VkIGluIFBnLTMgYnVsbGV0LTEgc2hvdWxkIGJlIGRlZmlu ZWQuIEkgYW0NCj5hc3N1bWluZyB5b3UgaW50ZW5kZWQgdG8gc2F5IG1pZC1wb2ludCBMU1Igb2Yg UkZDIDQ3MzYgPw0KW1RTXTogY29ycmVjdC4gV2lsbCBjaGFuZ2UuDQoNCg0KPg0KPjMuIFBnLTMg bGFzdCBwYXJhLiBSRkMgNDczNiBzdGF0ZXMgdGhhdCByZW9wdGltaXphdGlvbiBpcyBmb3IgYSBw cmVmZXJhYmxlDQo+cGF0aCBpLmUuIHNob3J0ZXIgcGF0aC4gVGhpcyBzaG91bGQgYmUgcmUtZGVm aW5lZCBmb3IgYSBQMk1QIExTUCBzbyB0aGF0DQo+dGhlIG5vdGlvbiBvZiBwcmVmZXJhYmxlIGlz IGNsZWFyLiBUaGlzIGlzIGNyaXRpY2FsIHRvIGRlZmluZSB0aGUgcHJvYmxlbQ0KPnN0YXRlbWVu dC4NCltUU106IHRoZSBkZWZpbml0aW9uIG9mIKGwcHJlZmVyYWJsZaGxIG9yIG9wdGltYWwgaXMg bG9jYWwgZnVuY3Rpb24vcG9saWN5DQp0byB0aGUgKG1pZC1wb2ludCkgcGF0aCBleHBhbmRpbmcg TFNSLiBJTU8sIHNob3VsZCByZW1haW4gYmV5b25kIHRoZSBzY29wZQ0Kb2YgdGhpcyBkcmFmdC4g RXZlbiBSRkM0NzM2IG1lbnRpb25zIKGwc2hvcnRlciBwYXRoobEgYXMgYW4gobBleGFtcGxlIiBv Zg0KbW9yZSBwcmVmZXJhYmxlIHBhdGguIFRoZSBwcm9wb3NlZCBleHRlbnNpb25zIGluIHRoaXMg ZHJhZnQgYXJlIGxpbWl0ZWQgdG8NCnByb2NlZHVyZXMgdG8gdHJpZ2dlci9yZWxheS9yZXNwb25z ZSBvZiB0aGUgcmVxdWVzdC9ub3RpZnkgb2YgYSBiZXR0ZXINCnAybXAgdHJlZSBhdmFpbGFiaWxp dHkuDQoNCg0KPg0KPjQuIFBnLTQgYnVsbGV0LTEuICBXaGF0IGlzIHRoZSAncXVlcnknIGJlaW5n IHJlZmVycmVkIHRvIGhlcmU/IElzIGl0IHBhdGgNCj5yZS1ldmFsdWF0aW9uIHJlcXVlc3QgPw0K W1RTXTogeWVzLCB0aGlzIHdpbGwgYmUgcmVwbGFjZWQgYnkgdHJpZ2dlciAiYSByZS1ldmFsdWF0 aW9uIHJlcXVlc3ShsS4NCg0KDQo+DQo+NS4gUGctNCBzZWMgMS4gQSBmaWd1cmUgdG8gaWxsdXN0 cmF0ZSB0aGUgcHJvYmxlbXMgd291bGQgYmUgdmVyeSB1c2VmdWwuDQo+DQo+Ni4gUGctNSBzZWN0 aW9uLTMgbGFzdCBwYXJhLiAiLi4ucmUtZXZhbHVhdGluZyBsb29zZWx5IGV4cGFuZGVkIHBhdGhz IG9mDQo+YWxsIFMyTCBzdWItTFNQKHMpLi4uIi4gU2hvdWxkbid0IHRoZSBQYXRoRXJyIGJlIHNl bnQgZXZlbiBpZiBhIHNpbmdsZSBTMkwNCj5zdWItTFNQIGNhbiBiZSByZS1vcHRpbWl6ZWQuIFdo eSBzaG91bGQgJ2FsbCcgYmUgcmUtZXZhbHVhdGVkID8NCltUU106IEFuIGV4YW1wbGUgaXMgd2hl biBjb21wdXRpbmcgdGhlIFAyTVAgbWluaW11bSBjb3N0IHRyZWUgKE1DVCmhqiBhcw0Kb3Bwb3Nl ZCB0byB0aGUgdHJlZSBvZiBTaG9ydGVzdCBQYXRocyAoU1Apcy4gVGhlIGZvcm1lciwgYXR0ZW1w dHMgdG8NCm1pbmltaXplIHRoZSBjb3N0IG9mIHRoZSB0cmVlIHRvIHJlYWNoIKGwYWxsobEgZGVz dGluYXRpb25zLCB3aGlsZSB0aGUNCmxhdHRlciBtaW5pbWl6ZXMgdGhlIGNvc3Qgb2YgYSBwYXRo IHRvIGEgc2luZ2xlIGRlc3RpbmF0aW9uIKGqIGZyb20gZWFjaA0KaW5kZXBlbmRlbnQgb2YgdGhl IHRyZWUgY29zdC4NCg0KDQo+DQo+Ny4gRG8gdGhlIHByb2NlZHVyZXMgaW4gdGhpcyBkcmFmdCBn dWFyYW50ZWUgJ2dsb2JhbCBvcHRpbWl6YXRpb24nID8NCltUU106IE5vdCBuZWNlc3NhcmlseSwg ZXNwZWNpYWxseSBnaXZlbiB0aGUgbWlkLXBvaW50IExTUiBoYXMgYXJlYSBsb2NhbA0KdG9wb2xv Z3kgdmlzaWJpbGl0eSBvbmx5LiBBZ2FpbiwgSSBiZWxpZXZlIHRoaXMgaXMgdG8gYmUga2VwdCBi ZXlvbmQgdGhlDQpzY29wZSBvZiB0aGUgZHJhZnQuDQoNClJlZ2FyZHMsDQpUYXJlaw0KDQo+DQo+ DQo+DQo+VGhhbmtzDQo+U3JpDQo+DQo+DQo+T24gNC8yMi8xNCA2OjQ1IEFNLCAiTG9hIEFuZGVy c3NvbiIgPGxvYUBwaS5udT4gd3JvdGU6DQo+DQo+PkFsbCwNCj4+DQo+Pkkgd2FzIHRvIGNvbnNl cnZhdGl2ZSBzZW5kaW5nIHRoaXMgb3V0LCBhdXRob3JzLCBjby1jaGFpcnMgYW5kDQo+PndnIHNl Y3JldGFyeSBzaG91bGQgaGF2ZSBiZWVuIGNvcGllZC4NCj4+DQo+Pi9Mb2ENCj4+DQo+Pk9uIDIw MTQtMDQtMjIgMTQ6NTEsIExvYSBBbmRlcnNzb24gd3JvdGU6DQo+Pj4gQ3VydGlzLCBYaWFvaHUs IFNyaSwgVGhvbWFzLA0KPj4+DQo+Pj4gWW91IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBhbiBNUExT IFJldmlldyB0ZWFtIHJldmlld2VycyBmb3INCj4+PiBkcmFmdC10c2FhZC1tcGxzLXAybXAtbG9v c2UtcGF0aC1yZW9wdC4NCj4+Pg0KPj4+IE5vdGUgdG8gYXV0aG9yczogWW91IGhhdmUgYmVlbiBD Q6n2ZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+Pj4gdGhhdCB0aGlzIHJl dmlldyBpcyBnb2luZyBvbi4gSG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBvd24N Cj4+PiBkb2N1bWVudC4NCj4+Pg0KPj4+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhl ciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQo+Pj51c2VmdWwNCj4+PiAoaWUsIGlz IGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9uYWwgbmV0d29ya3Mp LCBhbmQNCj4+PmlzDQo+Pj4gdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kPyAgV2UgYXJl IGludGVyZXN0ZWQgaW4ga25vd2luZyB3aGV0aGVyDQo+Pj4gdGhlIGRvY3VtZW50IGlzIHJlYWR5 IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uIChpZSwgaXQgZG9lc26p9nQNCj4+PiBo YXZlIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZSBhIGdvb2Qgc3Rh cnQpLg0KPj4+DQo+Pj4gUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9jdW1lbnQgYXV0 aG9ycywgV0cgY28tY2hhaXJzIGFuZA0KPj4+IHNlY3JldGFyeSwgYW5kIENDqfZkIHRvIHRoZSBN UExTIFdHIGVtYWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgY29tbWVudHMNCj4+PiBtYXkgYmUgc2Vu dCBwcml2YXRlbHkgdG8gb25seSB0aGUgV0cgY2hhaXJzLg0KPj4+DQo+Pj4gQXJlIHlvdSBhYmxl IHRvIHJldmlldyB0aGlzIGRyYWZ0IGJ5IE1heSA3LCAyMDE0Pw0KPj4+DQo+Pj4gVGhhbmtzLCBM b2ENCj4+PiAoYXMgTVBMUyBXRyBjaGFpcikNCj4+Pg0KPj4+DQo+Pg0KPj4tLSANCj4+DQo+Pg0K Pj5Mb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEu aHVhd2VpLmNvbQ0KPj5TZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAg IGxvYUBwaS5udQ0KPj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6 ICs0NiA3MzkgODEgMjEgNjQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPm1wbHMgbWFpbGluZyBsaXN0DQo+bXBsc0BpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= From nobody Mon Jun 2 06:13:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6CA1A032A; Mon, 2 Jun 2014 06:13: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 KrE1ETEt5aS9; Mon, 2 Jun 2014 06:13:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C18A61A0325; Mon, 2 Jun 2014 06:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602131336.21111.90325.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 06:13:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BpmNsQidriABmKHQPA3ekhuX11g Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-10.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: Mon, 02 Jun 2014 13:13:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-10.txt Pages : 40 Date : 2014-06-02 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-10 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 Mon Jun 2 11:03:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CA11A0341; Mon, 2 Jun 2014 11:03:54 -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 lxa9jqgRO_ik; Mon, 2 Jun 2014 11:03:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADA51A0282; Mon, 2 Jun 2014 11:03:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602180353.4266.39400.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 11:03:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dRP1hoMq8WtqJA_5-cVDowfS1kI Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-11.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: Mon, 02 Jun 2014 18:03:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-11.txt Pages : 40 Date : 2014-06-02 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-11 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 Mon Jun 2 11:17:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97081A035A for ; Mon, 2 Jun 2014 11:17:25 -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 ij4RemWqgFT7 for ; Mon, 2 Jun 2014 11:17:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4583D1A0341 for ; Mon, 2 Jun 2014 11:17:23 -0700 (PDT) Received: from BLUPR05CA0076.namprd05.prod.outlook.com (10.141.20.46) by BLUPR05MB102.namprd05.prod.outlook.com (10.255.214.20) with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 2 Jun 2014 18:17:16 +0000 Received: from BY2FFO11FD016.protection.gbl (2a01:111:f400:7c0c::148) by BLUPR05CA0076.outlook.office365.com (2a01:111:e400:855::46) with Microsoft SMTP Server (TLS) id 15.0.949.11 via Frontend Transport; Mon, 2 Jun 2014 18:17:13 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.148) with Microsoft SMTP Server (TLS) id 15.0.949.9 via Frontend Transport; Mon, 2 Jun 2014 18:17:13 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Jun 2014 11:16:22 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s52IGKn30439; Mon, 2 Jun 2014 11:16:20 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201406021816.s52IGKn30439@magenta.juniper.net> To: , , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99207.1401732980.1@juniper.net> Date: Mon, 2 Jun 2014 11:16:20 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(189002)(199002)(377424004)(37854004)(15975445006)(81542001)(77982001)(99396002)(46406003)(84676001)(81342001)(46102001)(47776003)(20776003)(64706001)(80022001)(79102001)(1941001)(50466002)(44976005)(83322001)(19580405001)(19580395003)(68736004)(69596002)(97736001)(97756001)(4396001)(21056001)(76482001)(6806004)(23726002)(16796002)(31966008)(50986999)(92726001)(2201001)(92566001)(81156002)(87936001)(15202345003)(54356999)(74502001)(77096999)(102836001)(86362001)(74662001)(83072002)(85852003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB102; H:P-EMF03-SAC.jnpr.net; FPR:; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0230B09AC4 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4SCCTYIx4N-JgiEgGUfgOR0G1co Cc: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-seamless-mcast-11.txt is ready for WG LC 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, 02 Jun 2014 18:17:26 -0000 Dear WG chairs, The authors of draft-ietf-mpls-seamless-mcast-11.txt would like to ask you to issue WG LC on the draft. Yakov. ------- Forwarded Message Date: Mon, 02 Jun 2014 11:03:53 -0700 From: To: cc: Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group o f the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-11.txt Pages : 40 Date : 2014-06-02 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------- End of Forwarded Message From nobody Mon Jun 2 19:25:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96111A0035; Mon, 2 Jun 2014 19:25:04 -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 E1wpwZP3dM96; Mon, 2 Jun 2014 19:25:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 750E71A002D; Mon, 2 Jun 2014 19:25:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140603022503.9461.93092.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 19:25:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gsGn1Z16O49I4zYzYsnK9i_w528 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-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, 03 Jun 2014 02:25: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 : LDP Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-08.txt Pages : 14 Date : 2014-06-02 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-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 Mon Jun 2 20:17:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F061A0062 for ; Mon, 2 Jun 2014 20:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp3SEfGAZ2Ap for ; Mon, 2 Jun 2014 20:17:26 -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 71FBF1A0058 for ; Mon, 2 Jun 2014 20:17:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT77214; Tue, 03 Jun 2014 03:17:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 04:16:30 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 04:17:17 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 11:17:12 +0800 From: Mach Chen To: "erosen@cisco.com" Thread-Topic: [mpls] MPLS-RT review of draft-chen-mpls-source-label Thread-Index: AQHPe1o/FzzLYOran0u7hpVpoFCIa5terSvA Date: Tue, 3 Jun 2014 03:17:11 +0000 Message-ID: References: Your message of Fri, 16 May 2014 06:46:52 -0000. <30111.1401380562@erosen-lnx> In-Reply-To: <30111.1401380562@erosen-lnx> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/1VUO2efpbZOJHdNWZ33dv5dqYgU Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 03:17:31 -0000 Hi Eric, Thanks for your comments! We are preparing an update to address the comments from the MPLS-RT reviewe= rs and you. Regarding how to prevent SLC and LS leaking outside to the unintended nodes= and/or domains, we have the following thoughts: 1) Naturally, IGP based SLC negotiation and SL distribution will not leak t= he SLC and SL outside an IGP domain, should be no more concerns here;=20 2) LDP based LSC negotiation, normally LDP is running within an AS, althoug= h as you said, technically, it may running across domains and leak the SLC = outside domain. As you suggested, we will add some text to the LDP based SL= C part to discuss this. 3) For inter-AS scenario, presumably, BGP will be used for SLC negotiation = and SL distribution, we are considering to use non-transitive attribute + p= olicy control (e.g., as the way AIGP uses ) to prevent SLC and SL leaking o= utside to the unintended domain(s).=20 Thanks, Mach > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, May 30, 2014 12:23 AM > To: Mach Chen > Cc: mpls@ietf.org > Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label >=20 > Mach> My point is that the distribution mechanisms should be defined in > Mach> separate documents >=20 > I don't think anyone is really concerned right now with the number of doc= uments > used to define the "source label" mechanisms. The issue at hand is wheth= er > the "source label" proposal is architecturally sound. Any proposal that = uses > scoped identifiers has to provide mechanisms that prevent the identifiers= from > leaking out of their intended scope, either via the control plane or the = data plane. > Right now there is no draft or set of drafts that we can look at to see h= ow the > scoping is enforced. The source-label draft is just one piece of the arc= hitecture, > and I don't think it can be accepted until we can determine whether the > architecture can be completed. >=20 > If one looks at the two proposed distribution mechanisms for which there = are > internet drafts (draft-chen-isis-source-label and draft-chen-ospf-source-= label), > we see that these two proposals only distribute the labels within a singl= e IGP > domain. Since the scope of a source label is not restricted to a single = IGP > domain, we can conclude that these two proposals are not, by themselves, > adequate. >=20 > The drafts also don't seem to have any procedures for dealing with the ca= se > where two nodes advertise the same source label. >=20 > Mach> There may need other solutions (e.g., BGP extensions) for the > Mach> distribution in that case. This should be discussed when we start > Mach> to define the distribution mechanisms. >=20 > I think we need to see the proposal for the BGP extensions before the > source-label draft can be considered. That is, I don't think the WG shou= ld > accept the SL draft until some progress has been made in defining the > distribution mechanisms. >=20 > Xiaohu> the SL advertisement could be done by a centralized mapping > Xiaohu> server >=20 > Sure, one could imagine a provisioning system that knows exactly which eg= ress > LSRs need to know the source labels for which ingress LSRs, and would pro= vision > the LSR accordingly. However, unless the draft is going to say that sour= ce labels > MUST NOT be used unless there is such provisioning system, this doesn't r= eally > help. Also, this doesn't address the issue of source labels in the data = plane > leaking outside the domain. >=20 > Eric> The ingress would have know, not only that the egress is capable > Eric> of processing the source label, but that the egress will interpret > Eric> the source label in the proper scope. The draft doesn't address > Eric> the issue of how to ensure that ingress and egress agree on the > Eric> intended scope of the label. >=20 > Mach> For single domain case, the SLC will be only exchanged among the > Mach> LSRs within the domain, when the ingress knows the egress can > Mach> support SLC, it implicit indicates that the egress will interpret > Mach> the SL in the same scope of itself. >=20 > Mach> Actually, even for multiple domains, it is still the case, since > Mach> SL will be used across domains, the SL space should be shared by > Mach> the domains. >=20 > The question is, how does the ingress LSR know that the egress LSR is in = the same > domain, or in a domain that shares the same SL space? I think you're ass= uming > that the capability advertisement from the egress will not cross the doma= in > boundary. Given that assumption, if an ingress LSR sees an SL capability > advertisement from an egress LSR, the ingress could assume that the egres= s is in > the same domain. However, the SLC signaling mechanisms described in the > draft do not prevent the SL Capability signal from crossing a domain boun= dary. > On the contrary, the mechanisms described in the draft will cause the SLC= to be > signaled from egress to ingress with no regard for domain boundaries. >=20 > Consider, for instance, the LDP extensions. From section 6.1.1: >=20 > "If all the advertised Mappings for F include the SLC TLV, then X > MUST advertise its Mapping for F with the SLC TLV." >=20 > This will cause the SLC to go from egress to ingress, with no regard for > domain boundaries. Perhaps the above should say "MAY advertise", and > should have some discussion of policy. >=20 > Section 6.1.2 proposes a BGP path attribute to signal the SL Capability: >=20 > "When Border Gateway Protocol (BGP) [RFC4271] is used for distributin= g > Network Layer Reachability Information (NLRI) as described in, for > example, [RFC3107], [RFC4364], the BGP UPDATE message may include the > SLC attribute as part of the Path Attributes. This is an optional, > transitive BGP attribute of value TBD3. The inclusion of this attrib= ute > with an NLRI indicates that the advertising BGP router can process > Source Labels as an egress LSR for all routes in that NLRI. >=20 > ... >=20 > Suppose a BGP speaker T receives an UPDATE U with the SLC attribute. = T > has two choices. T can simply re-advertise U with the SLC attribute = if > either of the following is true: >=20 > B1: T does not change the NEXT_HOP attribute OR >=20 > B2: T simply swaps labels without popping the entire label stack and > processing the payload below." >=20 > Note that if the SLC attribute is an optional transitive attribute, then = if T does not > understand this attribute, T will pass it along even if conditions B1 and= B2 do not > hold. (Perhaps the attribute needs to be > non-transitive.) >=20 > B2 is a little hard to understand. Let P be the prefix in the NLRI of up= date U. I > think the intention is that the SLC attribute be left on by T if each of = T's installed > routes to P has the SLC attribute. (B2 as written seems to be about the = data > plane, but the context of this section is the control plane.) >=20 > Even if B1 does hold, it may still be incorrect for router T to pass alon= g the SLC. > For example, suppose the data path from R1 to R2 is as follows: >=20 > R1---ASBR1---ASBR2---R2 >=20 > but suppose that R1 and R2 exchange VPN routes through a different path: >=20 > R1---T1---T2---R2 >=20 > where T1 and T2 aren't in the data path at all. This could occur in an "= option C" > type of interconnect. (RFC4364 section 10 option c.) Suppose that R1 and= R2 are > in different domains. T1 and T2 would leave the next hop unchanged. Whe= n > R1 has data to send to P, it would find R2 to be the next hop, and then w= ould do > recursive route resolution to find that ASBR1 is its next hop to R2. In = this > scenario, R1's route to P would have the SLC attribute, but R2 would not = properly > interpret R1's source label. >=20 > To make this work at all, you'd have to mandate that the SLC attribute be > attached to a route that travels along the data path (i.e., goes through = the ASBRs), > and there would have to be policy at the ASBRs that strips off the SLC if= the > ASBRs are at a domain boundary. The proper behavior when recursive route > resolution is done would also have to be specified. >=20 > I'm having some trouble understanding the following paragraph from the dr= aft: >=20 > "However, if T changes the NEXT_HOP attribute for U and in the data pl= ane > pops the entire label stack to process the payload, T MAY include an S= LC > attribute for UPDATE U' if both of the following are true:" >=20 > C1: T sets the NEXT_HOP attribute of U' to itself AND >=20 > C2: T can process source labels. Otherwise, T MUST remove the SLC > attribute." >=20 > The term UPDATE U' doesn't appear to have been defined anywhere, though I > assume this is meant to be the update you get when you take Update U and > change the next hop. Does the phrase "and in the data plane pops the ent= ire > label stack to process the payload" mean that T is the egress LSR for the= prefix in > U's NLRI? If so, I don't think this entire paragraph is needed, as T wil= l be > originating an Update for that prefix, and will include the SLC attribute= if > necessary. >=20 > Eric> With no structure and no "domain identifier" in the source label, > Eric> it is very easy end up with non-unique labels within a domain. >=20 > Mach> There are also many non-structure cases, for example, Router ID, > Mach> Segment ID, VE ID of BGP VPLS > Mach> (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), they work fine= . >=20 > I have to admit that I have always regarded the VPLS VE IDs as a very bad= idea. > However, they do have a well-defined scope, namely a single VPLS. > RT-based mechanisms are used to constrain their distribution so that they= don't > leak unintentionally into other VPLSes. And the VE IDs do not appear in = the > data packets. These characteristics make it possible to get away with an > unstructured identifier space. SLs don't seem to have a well-defined sco= pe, or a > well-defined distribution mechanism, and they do get carried by data pack= ets. > Leakage out of the intended domain is thus much more of a problem. So I = don't > think SLs can be compared to VPLS VE IDs. >=20 > With regard to router ids, if you've ever followed any of the vituperativ= e > discussions that arise when router ids are discussed (e.g., when discussi= ng > whether a 32-bit id is appropriate for an IPv6-based protocol), you'll se= e that > there are quite a few issues in the management of that numbering space. >=20 > Mach> In addition, even for your RT example, for L3VPN inter-AS > Mach> scenario, the RT has to be considered as single space, the domain > Mach> identifier does not help here. >=20 > RTs are structured so that a SP can allocate RT values that are globally = unique, not > just unique within a domain. So a "domain identifier" is not needed. I = believe > it is true that some SPs use RTs that are not globally unique, but that = is a choice > they have made for themselves, not a choice that is forced upon them by t= he > architecture. >=20 > Eric> One might also ask why there is a need to use a 20-bit label to > Eric> identify a node, instead of using some other format. >=20 > Mach> We are talking about identifying the source of an LSP, and the > Mach> label stack is the MPLS header and there are only labels, then > Mach> seems that a label to identify the ingress LSR is a naturally choic= e. >=20 > A couple of other possibilities come readily to mind: >=20 > - Treat the SLI as the bottom of the stack, and follow it with a 32-bit > address (or even a 128-bit address) of the ingress. (Or maybe use > something based on the "generic associated channel".) >=20 > - Use two label stack entries and stuff a 32-bit "router id" in them, > using more per-packet overhead but eliminating the need to manage a 20-= bit > domain-wide numbering space. >=20 > But perhaps the use case is easier to implement if the SL fits into the s= ame > 20 bits usually used for labels. If so, that would be worth mentioning. >=20 > With regard to the name, >=20 > Xiaohu> What about IIL (Ingress Identification Label)? >=20 > I do like that better. >=20 > However, getting all the details right is going to be a lot of work, espe= cially for > something that has only one use case, and a controversial one at that. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Tue Jun 3 00:44:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9BE1A0114 for ; Tue, 3 Jun 2014 00:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Keq_GYuHBS-8 for ; Tue, 3 Jun 2014 00:44:28 -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 6C1C21A0043 for ; Tue, 3 Jun 2014 00:44:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT97129; Tue, 03 Jun 2014 07:44:18 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 08:43:32 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 08:44:16 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 15:44:08 +0800 From: Mach Chen To: Sam Aldrin , Qin Wu Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPetoSTxrg68FQmkaRw0Zt1ecvRZtXNh5A Date: Tue, 3 Jun 2014 07:44:07 +0000 Message-ID: References: <52C795FE.7060801@pi.nu> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/jjle1weOCrN_8Qd37ntEkPGx3ec Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:44:29 -0000 Hi Sam, Thanks for considering my comments! See my reply inline... Sniped the resolved parts. >=20 >=20 > 2) From Mach Chen >=20 > Hi Authors, >=20 > I just reviewed the draft, here are my comments, hope this help. >=20 > General comments: > It would be better if you could adjust the structure of the draft to put = Section 3 > behind Section 5. Then the reader will not need to check definitions of t= he > Messages and TLVs in the back and then return back keep reading the docum= ent. >=20 > ##RESP - I feel it is good to have description before the actual format d= efinition. > Either case, one has to go back and forth to understand completely. Is th= ere any > hard preference to your suggestion? That's my personal feeling when I read the draft, but I am fine with the cu= rrent structure.=20 >=20 > Specific comments: >=20 > 6. Section 3.2.1 >=20 > 6.1 In the middle of third paragraph: >=20 > "If the Proxy LSR is a Budnode but not > requested to return a Proxy reply, the Proxy LSR should send packets > to the downstream neighbors (no Echo reply is sent to the Proxy > Initiator to indicate that the Proxy LSR is an egress). > " >=20 > What packets will be sent to the downstream neighbors? >=20 > ##RESP: "MPLS Echo Request" It's better to make it more explicit. > 8. Section 3.2.4.2 >=20 > "If any additional labels are pushed > onto the stack, their TTLs are set to 255." >=20 > what's this case? Can you clarify more about the case? >=20 > ##RESP: Don't want to requester have have control of the ttls for tunnel= s not > relevant to the FEC being tested. It's better to add some clarification text. Best regards, Mach From nobody Tue Jun 3 01:08:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF31A0170 for ; Tue, 3 Jun 2014 01:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mpSTfTKpogd for ; Tue, 3 Jun 2014 01:08:37 -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 ED3631A0167 for ; Tue, 3 Jun 2014 01:08:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT99960; Tue, 03 Jun 2014 08:08:26 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 09:07:26 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 09:08:10 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 16:07:59 +0800 From: Qin Wu To: Sam Aldrin , Mach Chen Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-proxy-lsp-ping Thread-Index: AQHPCQpF8EKV6TDHQ0CJk57HMDs40pqJm0iAgM2AaYCACNc+MA== Date: Tue, 3 Jun 2014 08:07:59 +0000 Message-ID: References: <52C795FE.7060801@pi.nu> 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.138.41.117] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ecXrxf65c7qi2sH4NGi8fNFQgMs Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u?= =?gb2312?b?IGRyYWZ0LWlldGYtbXBscy1wcm94eS1sc3AtcGluZw==?= 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, 03 Jun 2014 08:08:39 -0000 SGksIFNhbToNClRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50cy4NClNlZSBteSByZXBs eSBiZWxvdy4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBTYW0gQWxkcmluIFttYWlsdG86 YWxkcmluLmlldGZAZ21haWwuY29tXSANCreiy83KsbzkOiAyMDE0xOo11MIyOcjVIDk6MDQNCsrV vP7IyzogTWFjaCBDaGVuOyBRaW4gV3UNCrOty806IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZzsg bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1wcm94eS1sc3AtcGlu Z0B0b29scy5pZXRmLm9yZw0K1vfM4jogUmU6IFttcGxzXSBXb3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLW1wbHMtcHJveHktbHNwLXBpbmcNCg0KSGkgTWFjaCBhbmQgUWluLA0K DQpQbGVhc2UgZmluZCByZXNwb25zZSB0byBjb21tZW50cyBlbWJlZGRlZCB3aXRoICMjUkVTUC4N ClNvcnJ5IGl0IHRvb2sgYSB3aGlsZSB0byByZXNwb25kIGJ1dCBoZXJlIGl0IGlzIGFueXdheS4N CkxldCBrbm93IGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIHF1ZXN0aW9ucy4gV2Ugd291bGQgbGlr ZSB0byBtYWtlIGVkaXRzLCBjbG9zZSBhbGwgb3BlbiBpdGVtcyBhbmQgc3VibWl0IGEgbmV3IHZl cnNpb24gb2YgdGhlIGRyYWZ0IHRvIGNvbXBsZXRlIExDLg0KDQoNCkNvbW1lbnRzIGZyb20gUWlu Og0KDQojMQ0KSGksIGF1dGhvcnM6DQpIYXZlIGEgcXVpY2sgbG9vayBhdCB0aGlzIGRyYWZ0LCBJ dCBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHByb3h5IExTUiBkb2Vzbid0IG5lZWQgdG8gd2FpdCBm b3IgVGhlIHJlc3VsdCBvZiBNUExTIGVjaG8gcmVseSBhbmQgdGhlbiBzZW5kIE1QTFMgcHJveHkg cGluZyByZXBseT8NCkkga25vdyB0aGUgZHJhZnQgc2F5cyB0aGUgcmVjZWl2ZXJzIHByb2Nlc3Mg dGhlIE1QTFMgZWNobyByZXF1ZXN0LCBzZW5kaW5nIHRoZWlyIE1QTFMgZWNobyByZXBsaWVzIGRp cmVjdGx5IGJhY2sgdG8gdGhlIGluaXRpYXRvciwgaG93ZXZlciB3aHkgYnlwYXNzIHByb3h5IExT Uj8NCldoYXQgYWJvdXQgTVBMUyBlY2hvIHJlcXVlc3QgaW5pdGlhdGluZyBieSBwcm94eSBMU1Ig aXMgbG9zdD8gSG93IGRvZXMgdGhlIGluaXRpYXRvciBrbm93IHRoZSBsb3N0IG9mIE1QTFMgZWNo byByZXF1ZXN0IG9yIHJlcGx5Pw0KV2hhdCBhbSBJIG1pc3Npbmc/DQoNCiMjUkVTUDogICBMU1Ag cGluZyBpcyBkZXNpZ25lZCB3aXRoIGluaXRpYXRvciBpbml0aWF0aW5nIHRoZSByZXF1ZXN0IGFu ZCBtYWludGFpbmluZyB0aGUgc3RhdGUgZm9yIHRoZSBzYW1lLiBBbGwgdGhlIHRyYW5zaXQgb3Ig cmVzcG9uZGluZyByb3V0ZXIgZG8gbm90IG1haW50YWluIGFueSBzdGF0ZS4gUmVxdWlyaW5nIFBy b3h5IExTUnMgdG8gbWFuYWdlIHJlbGF5aW5nIHRoZSByZXNwb25zZSB3b3VsZCByZXF1aXJlIGl0 IHRvIG1haW50YWluIHN0YXRlIGZvciB0aGUgZW50aXJlIHRyYW5zYWN0aW9uLCAgaW5jbHVkaW5n IHJlcXVpcmluZyB0aGUgYSB0aW1lb3V0IHRvIGJlIHN1cHBsaWVkIGJ5IHRoZSBpbml0aWF0b3Iu IFRoaXMgd2lsbCByZXF1aXJlIHRoZSBjaGFuZ2UgaW4gYXJjaGl0ZWN0dXJlLCB3aGljaCB0aGlz IGRyYWZ0IGlzIGRlZmluaXRlbHkgbm90IGludGVuZGluZyB0byBkby4NCg0KW1Fpbl06IE9rYXku IFRoYW5rcyBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLiBJIGNhbiBsaXZlIHdpdGggdGhpcy4NCg0K IzINCkFsc28gaXQgaXMgbm90IHZlcnkgY2xlYXIgdG8gbWUgaG93IHRvIHVzZSByZXBseSBtb2Rl IDUsIGFsdGhvdWdoIHRoZSBkcmFmdCBzYXlzICINCklmIHRoZSBSZXBseSBNb2RlIG9mIHRoZSBt ZXNzYWdlIGhlYWRlciBpcyAxIG9yIGlzIDUgYW5kIG5vIGVycm9ycyBvciBtb2RpZmljYXRpb25z IGhhdmUgb2NjdXJyZWQgbm8gTVBMUyBwcm94eSBwaW5nIHJlcGx5IGlzIHNlbnQuDQoiDQojI1JF U1A6ICBUaGVyZSBpcyBubyBtZW50aW9uIG9mIHJlcGx5IG1vZGUgNS4gV2hpY2ggZG9jdW1lbnQg YXJlIHlvdSByZWZlcnJpbmcgdG8/IFRoZSBkb2N1bWVudCByZWZlcnMgb25seSB0byBtb2RlIDEs IHdoZXJlLCBubyByZXBseSBTSE9VTEQgYmUgc2VudCBmb3IgdGhhdCBtb2RlLg0KDQogICBJZiB0 aGUgUmVwbHkgTW9kZSBvZiB0aGUgUHJveHkgUmVxdWVzdCBtZXNzYWdlIGhlYWRlciBpcyAiMSAt IGRvIG5vdA0KICAgcmVwbHkiLCBubyBNUExTIHByb3h5IHBpbmcgcmVwbHkgaXMgc2VudC4gIE90 aGVyd2lzZSBhbiBNUExTIHByb3h5DQogICBwaW5nIHJlcGx5IG1lc3NhZ2Ugb3IgTVBMUyBlY2hv IHJlcXVlc3Qgc2hvdWxkIGJlIHNlbnQgYXMgZGVzY3JpYmVkDQogICBiZWxvdy4NCg0KW1Fpbl06 IEkgYW0gcmVmZXJyZWQgdG8gdGhpcyBkb2N1bWVudCwgbGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlv biAzLjIgZGlkIG1lbnRpb25zIHVzaW5nIHJlcGx5IG1vZGUgNS4NCg0KIzMNCkl0IGxvb2tzIHRv IG1lIGlmIG5vIE1QTFMgcHJveHkgcGluZyByZWx5IG5lZWRzIHRvIGJlIHNlbnQsIHdoeSBkZWZp bmUgcmVwbHkgbW9kZSA1Pw0KIyMjUkVTUDogIE5vIG1lbnRpb24gb2YgcmVwbHkgbW9kZSA1LiBJ ZiB5b3UgYXJlIHJlZmVycmluZyB0byByZXBseSBtb2RlIDEsIHRoZSBxdWVzdGlvbiBpcyBmb3Ig UkZDNDM3OS4gQWxsIEkgY2FuIHNheSBpcywgaXQgaXMgdGhlcmUgdG8gY2hlY2sgdW5pZGlyZWN0 aW9uYWwgZXJyb3JzLiANCg0KW1Fpbl06IFNlZSBhYm92ZS4NCg0KIzQNCkFsc28gdGhlcmUgYXJl IGEgbG90IG9mIG5pdHMgYW5kIHR5cG9zIHRoYXQgbmVlZCB0byBiZSBmaXhlZCwgcy8gbGltaXRp bmcgdGhlIHRoZSBudW1iZXIvIGxpbWl0aW5nIHRoZSBudW1iZXIgcy8gbW90aXZhdG9uLyBtb3Rp dmF0aW9uIHMvIGFuZCBhbmQgYWxsIGF1dGhvLXJpemF0aW9uLyBhbmQgYWxsIGF1dGhvcml6YXRp b24gcy8gUHByb2NlZHVyZXMvIFByb2NlZHVyZXMgcy8gc3ViLW9iamV4dHMvIHN1Yi1vYmplY3Rz IHMvIG1vZGlmaWNhdG9ucyAvbW9kaWZpY2F0aW9ucyBzLyBkZWNyaWJlZC8gZGVzY3JpYmVkIHMv IGFzc2lnbWVudHMvYXNzaWdubWVudHMNCg0KIyNSRVNQOiBBY2sNCg0KIzUNCkluIHNlY3Rpb24g NS4yLCB0aGVyZSBpcyBubyBkZWZpbml0aW9uIG9mIHJlcGx5IHRvIGFkZHJlc3MgZmllbGQsIEkg dGhpbmsgaXQgc2hvdWxkIGJlIGRlZmluZWQgYXMgaW5pdGlhdG9yIGFkZHJlc3MNCg0KIyNSRVNQ OiAgVGhpcyBpcyB0aGUgYWRkcmVzcyB0aGUgZWNobyByZXBseSBzaG91bGQgYmUgc2VudCB0bywg IG1vc3QgbGlrZWx5IHRoZSBpbml0aWF0b3IsIGJ1dCBjb3VsZCBiZSBzb21ldGhpbmcgZWxzZS4g V2Ugd2lsbCBhZGQgdGV4dCBmb3IgdGhlIGZpZWxkLg0KDQpbUWluXTogTG9va3MgZ29vZC4NCiM2 DQpGb3IgRG93bnN0cmVhbSBNYXBwaW5nIG9iamVjdHMsIGl0IGlzIGJldHRlciB0byBhZGQgYSBy ZWZlcmVuY2UgdG8gUkZDNDM3OS4NClRoZSByZWZlcmVuY2VzIFtNY3N0UGluZ10gW21MRFBdIGFy ZSBub3cgb3V0ZGF0ZWQgYW5kIG5lZWQgdG8gYmUgdXBkYXRlZCB0byB0aGUgY29ycmVzcG9uZGlu ZyBSRkMuDQojI1JFU1AgLSBBY2suIFdpbGwgYWRkIHJlZmVyZW5jZXMuDQoNClJlZ2FyZHMhDQot UWluICANCg0KDQoNCj09PT09PQ0K From nobody Tue Jun 3 18:19:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCBF1A0004; Tue, 3 Jun 2014 18:19: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, 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 yM8fBCKKCATJ; Tue, 3 Jun 2014 18:19:40 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A03E1A03B9; Tue, 3 Jun 2014 18:19:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D862D2414AB; Tue, 3 Jun 2014 18:19:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 19B59241489; Tue, 3 Jun 2014 18:19:33 -0700 (PDT) Message-ID: <538E7425.2080305@joelhalpern.com> Date: Tue, 03 Jun 2014 21:19:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org, "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/I7LTJnCSeC4vcTZA-6QVgGLrvFs Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-ldp-hello-crypto-auth-08.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, 04 Jun 2014 01:19:42 -0000 [Apologies, this review was due two weeks ago. On the other hand, you have reved it 3 times during my laggard behavior.] Hello mpls WG, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-ldp-hello-crypto-auth-08.txt Reviewer: Joel M. Halpern Review Date: 3-June-2014 IETF LC End Date: closed Intended Status: Standards Track This document is basically ready for publication, but has nits that should be considered prior to publication. The one nit is that I could not find the text indicating that if a receiver receives an unauthenticated LDP Hello packet, and is expecting authentication to be used (either always, or with the source the packet claims to be from) then the hello packet should be silently discarded. Yours, Joel From nobody Tue Jun 3 18:28:57 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D271A00B8; Tue, 3 Jun 2014 18:28: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_74=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 94rVmfaShqtw; Tue, 3 Jun 2014 18:28:54 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB711A008B; Tue, 3 Jun 2014 18:28:53 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id eb12so7000779oac.25 for ; Tue, 03 Jun 2014 18:28:48 -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=9lmkadOgk61yfYChSpc3i0/oGjWU8gpes2aw+lflSLk=; b=JK0SRZnKWOAayJc0MO+MD4lz0Xbi8f5dEK9CO+o5QomNcCCpMxamHtsSVqCu29KZea bRvtDRM1SctEv4gEwtS2FadrIq+89UAVN4IL/hiFNgGEzv2rgoFG8fiDZMPsNloTl/KB VyrnfCPGTRBhR+sRA+B9H2P8cRrDA/nNXj4zj1SenHJHAD5zbUWAIBSTFh9B4ZOK+txq 4tdebsrDRSuXO+ShFeGA749cnPQVp9KRRRtT7YUboc2EQwIeR3nH0JJ7DWI/ELmyT7qw S/Z5C8ktDOmrbjk0fbQ0D1J+2XAr/9YRxFF5CobmEuE2SXhPQDlLAPTLqqnZchEsHrDk to6g== MIME-Version: 1.0 X-Received: by 10.60.56.98 with SMTP id z2mr52023806oep.62.1401845327993; Tue, 03 Jun 2014 18:28:47 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 3 Jun 2014 18:28:47 -0700 (PDT) In-Reply-To: <538E7425.2080305@joelhalpern.com> References: <538E7425.2080305@joelhalpern.com> Date: Wed, 4 Jun 2014 06:58:47 +0530 Message-ID: From: Manav Bhatia To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c22172ce237b04faf88cf8 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/CcsFxuVWQkFPUtpUdZUzJHJ_gYY Cc: "rtg-dir@ietf.org" , draft-ietf-mpls-ldp-hello-crypto-auth@tools.ietf.org, "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-ldp-hello-crypto-auth-08.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, 04 Jun 2014 01:28:55 -0000 --001a11c22172ce237b04faf88cf8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joel, Thanks for the review. I am surprised we dont have this covered. If its not there, then we'll add text to log an error message+drop packet as opposed to silently discarding the packet. Cheers, Manav On Wed, Jun 4, 2014 at 6:49 AM, Joel M. Halpern wrote= : > [Apologies, this review was due two weeks ago. On the other hand, you > have reved it 3 times during my laggard behavior.] > > Hello mpls WG, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8B http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-mpls-ldp-hello-crypto-auth-08.txt > Reviewer: Joel M. Halpern > Review Date: 3-June-2014 > IETF LC End Date: closed > Intended Status: Standards Track > > This document is basically ready for publication, but has nits that shoul= d > be considered prior to publication. > > The one nit is that I could not find the text indicating that if a > receiver receives an unauthenticated LDP Hello packet, and is expecting > authentication to be used (either always, or with the source the packet > claims to be from) then the hello packet should be silently discarded. > > Yours, > Joel > --001a11c22172ce237b04faf88cf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Thanks for the review.

I am surprised we dont have this covered. If its not ther= e, then we'll add text to log an error message+drop packet as opposed t= o silently discarding the packet.

Cheers, Manav

On Wed, Jun 4, 2014 at 6:49 AM, Joel M. Hal= pern <jmh@joelhalpern.com> wrote:
[Apologies, this review was due two weeks ag= o. =C2=A0On the other hand, you have reved it 3 times during my laggard beh= avior.]

Hello mpls WG,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see =E2= =80=8B http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<= /a>

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

Document: draft-ietf-mpls-ldp-hello-crypto-auth-08.txt
Reviewer: Joel M. Halpern
Review Date: 3-June-2014
IETF LC End Date: closed
Intended Status: Standards Track

This document is basically ready for publication, but has nits that should = be considered prior to publication.

The one nit is that I could not find the text indicating that if a receiver= receives an unauthenticated LDP Hello packet, and is expecting authenticat= ion to be used (either always, or with the source the packet claims to be f= rom) then the hello packet should be silently discarded.

Yours,
Joel

--001a11c22172ce237b04faf88cf8-- From nobody Wed Jun 4 03:29:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C471A0298 for ; Wed, 4 Jun 2014 03:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIZvQQmp188V for ; Wed, 4 Jun 2014 03:29:11 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5621A0293 for ; Wed, 4 Jun 2014 03:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6883; q=dns/txt; s=iport; t=1401877745; x=1403087345; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HCU/Z3QAkdy1iyubzx07BC1nk6E86vvuZxjBbZuOgBM=; b=RwKhjcCgel1X9aToyBuD7EU9QL1pCndOI/BqNA3PJMfh0fJ1wZAVBsPx 1iKbnueg9wTbA4Opw5jP2G8BKTLVMCqQNvKMfbYme/d3uSaaE/kVSBhDj wNN8Aips3glmGuehlFdgPxgY738QFXJWk5OQ9uZXbxiiQQbc+z5UoWQwP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAAn0jlOtJssW/2dsb2JhbABZg1nDSwGBIXSCJQEBAQQnETYFBQEMBAsRBAEBAQkWCAcJAwIBAgE0CQgGAQwBBQIBAReIJw2zTp51F44wIgcGhDoBA5oPkzaDOWs X-IronPort-AV: E=Sophos;i="4.98,972,1392163200"; d="scan'208";a="74215046" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Jun 2014 10:29:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s54AT2W8014394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2014 10:29:03 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s54AT2xt025549; Wed, 4 Jun 2014 11:29:02 +0100 (BST) Message-ID: <538EF4EE.7000809@cisco.com> Date: Wed, 04 Jun 2014 11:29:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gregory Mirsky , "MORTON, ALFRED C (AL)" , Eric Gray , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> <537F66C3.4070203@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> <2845723087023D4CB5114223779FA9C8017992C1F2@njfpsrvexg8.research.att.com> <7347100B5761DC41A166AC17F22DF1121B7C2C04@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7C2C04@eusaamb103.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Wr70uqL4LpgiLW5LYPZJN0vqsNM Cc: "mpls@ietf.org" , "draft-ietf-lmap-framework@tools.ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:29:13 -0000 On 25/05/2014 01:14, Gregory Mirsky wrote: > Dear Al, > thank you for your analysis of the draft and its correlation with the LMAP framework. > I think that the RFC 6374 gives option for the responder, Measurement Peer (MP) in LMAP framework terminology, to send measurement result to an arbitrary destination, not only to the Querier, Measurement Agent (MA). Yes it does, although as written not to multiple collectors. Do you need that? If so I would need to use a modified TLV with the both the address and the port since the port will be address dependent. - Stewart > Though such scenario is not considered for MP in the LMAP framework, I believe we can still refer to that node as Data Collector because MA instructed MP perhaps based on information received from the Measurement Controller. > During our discussion Stewart asked if there could be case of multiple Data Collectors for the given Measurement Task. That is when I referred to the LMAP framework as I believe that it allows to associate multiple Data Collectors with the Measurement Task. Is my understanding correct? > > Regards, > Greg > > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Friday, May 23, 2014 10:14 AM > To: Eric Gray; stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-udp-return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > Eric, Stewart, > > It seems to me (after scanning the draft) that the MPLS-PLDM could be treated as the out-of-scope measurement traffic/protocol in the LMAP Framework Figure 1 below (Where IPPM is currently used as the out-of-scope example): > > ^ > | > Active +-------------+ IPPM > +---------------+ Measurement | Measurement | Scope > | Measurement |<------------>| Peer | | > | Agent | Traffic +-------------+ v > +------->| | ^ > | +---------------+ | > | ^ | | > | Instruction | | Report | > | | +-----------------+ | > | | | | > | | v LMAP > | +------------+ +------------+ Scope > | | Controller | | Collector | | > | +------------+ +------------+ v > | ^ ^ | ^ > | | | | | > | | +----------+ | | > | | | v | > +------------+ +----------+ +--------+ +----------+ | > |Bootstrapper| |Subscriber|--->| data |<---|repository| Out > +------------+ |parameter | |analysis| +----------+ of > |database | | tools | Scope > +----------+ +--------+ | > | > > The MPLS-PLDM Querier could be co-located with a Measurement Agent, and assuming the Querier performs all the coordination, including arranging to return the response message to a port co-located with the same Measurement Agent (or configuration takes the role of signaling), then the MPLS-PLDM responder could be treated as a Measurement Peer. The LMAP Control and Report protocols provision and collect results from the Querier, taking the role of a "management system" mentioned in the draft. > > hope this helps, > Al > > > > >> -----Original Message----- >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> Sent: Friday, May 23, 2014 11:47 AM >> To: stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-udp- >> return@tools.ietf.org >> Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org >> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> >> Stewart, >> >> I understand your point. But the question is not whether or not it >> will work, but rather whether or not there is consensus to do it this >> way. >> >> On any given day, it is trivial to come up with any number of >> approaches for doing something (whatever that something is) that will >> _work_ - which is not the same as saying that we should all pour >> energy into any of those ideas. >> >> I also understand the pressures associated with customer >> requirements, but don't see why the customer(s) behind your >> requirements should have the last word on which approach should be >> used - based solely on those requirements. >> >> That approach leads to a point-solution that has a definite non-zero >> cost. As a general approach, the continuous generation of point >> solutions has its own scaling issues. >> >> It is my hope that someone will have the energy to put together a >> draft to propose an alternative based on LMAP. I personally do not >> have either the energy or the bandwidth. In fact, I don't have the >> bandwidth or the energy to continue in >> this discussion. I sincerely hope and intend this will be my last post >> on this topic. >> >> If there is insufficient interest in developing the scaled-down >> version of an LMAP-based proposal - either within the MPLS working >> group, or among the LMAP framework authors - before the Toronto >> meeting, or there is not a number of like objections raised on the >> MPLS mailing list, then it would seem that the WG default consensus >> is to proceed with your draft. >> >> Believe it or not, I personally can live with that. >> >> -- >> Eric >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Friday, May 23, 2014 11:18 AM >> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp- >> return@tools.ietf.org >> Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org >> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> Importance: High >> >> Eric >> >> I think the onus is on you as the objector to provide me with a >> pointer to a specific protocol alternative not a framework, or to show >> why this simple addition of four bytes will not work in the manner that I describe. >> >> Stewart > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Wed Jun 4 04:44:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865251A01B3; Wed, 4 Jun 2014 04:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 k88KkEIFzMID; Wed, 4 Jun 2014 04:44:40 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A711A016D; Wed, 4 Jun 2014 04:44:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s54BiVpA027370; Wed, 4 Jun 2014 12:44:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s54BiUgM027350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jun 2014 12:44:30 +0100 From: "Adrian Farrel" To: "'Joel M. Halpern'" , , , , References: <538E7425.2080305@joelhalpern.com> In-Reply-To: <538E7425.2080305@joelhalpern.com> Date: Wed, 4 Jun 2014 12:44:26 +0100 Message-ID: <066c01cf7fea$56f70da0$04e528e0$@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: AQLEWoqnfnvbVBUgepwSQyHeIVch7Zl3Hv9g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20736.006 X-TM-AS-Result: No--14.584-10.0-31-10 X-imss-scan-details: No--14.584-10.0-31-10 X-TMASE-MatchedRID: QW5G6BKkLTqnykMun0J1wpmug812qIbz4mci32NdMLJ6GeWCu+JlEMLm p4jPUF8tQIrDavfhGmx1Bz1Y4U1qS+yt+a9Mtf+eq0reih3E9rFWjiXAsVR2KyJ8zskw0dbrGFP rgGlCsZJUrcWeEVrK/Tmm/+nv0wXV1ddezVny+QK8coKUcaOOvSTbbsi+pqSFHITqvaivgBouu9 HtoCYkWPll77CGGGb1VPphuu9CvFW+yUveM5Vvpa91/YHX0i1l+W1UJfANmI4cQXgzaVXEcgEtZ aNsZVIx4vM1YF6AJbbSFZyaJmMIRrew1twePJJB3QfwsVk0UbtuRXh7bFKB7pakosaP+Ylc1m1Q OREZL+9cG4ieweSfpbye3hqMCm8tsBTJSD2iAW0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/peqORh1FrgsPne09rzrVsFP9dmk Subject: Re: [mpls] [RTG-DIR] Routing directorate review of draft-ietf-mpls-ldp-hello-crypto-auth-08.txt 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, 04 Jun 2014 11:44:42 -0000 Thanks Joel! I have added your nit to my IESG evaluation as a Comment so that we = don't drop it. Cheers, Adrian > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. = Halpern > Sent: 04 June 2014 02:20 > To: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; = draft-ietf-mpls-ldp-hello-crypto- > auth@tools.ietf.org; mpls@ietf.org > Subject: Re: [RTG-DIR] Routing directorate review of = draft-ietf-mpls-ldp-hello- > crypto-auth-08.txt >=20 > [Apologies, this review was due two weeks ago. On the other hand, you > have reved it 3 times during my laggard behavior.] >=20 > Hello mpls WG, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see=20 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, = it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them = through > discussion or by updating the draft. >=20 > Document: draft-ietf-mpls-ldp-hello-crypto-auth-08.txt > Reviewer: Joel M. Halpern > Review Date: 3-June-2014 > IETF LC End Date: closed > Intended Status: Standards Track >=20 > This document is basically ready for publication, but has nits that > should be considered prior to publication. >=20 > The one nit is that I could not find the text indicating that if a > receiver receives an unauthenticated LDP Hello packet, and is = expecting > authentication to be used (either always, or with the source the = packet > claims to be from) then the hello packet should be silently discarded. >=20 > Yours, > Joel From nobody Wed Jun 4 20:53:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A281A01C1 for ; Wed, 4 Jun 2014 20:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta9KSHin9p_6 for ; Wed, 4 Jun 2014 20:53:17 -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 835141A001E for ; Wed, 4 Jun 2014 20:53:17 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A1B121802AAB for ; Thu, 5 Jun 2014 05:53:09 +0200 (CEST) Message-ID: <538FE9A1.7010303@pi.nu> Date: Thu, 05 Jun 2014 05:53:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <15721.1401823067@sandelman.ca> In-Reply-To: <15721.1401823067@sandelman.ca> X-Forwarded-Message-Id: <15721.1401823067@sandelman.ca> Content-Type: multipart/mixed; boundary="------------040806090809060904030709" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/yF8r_0IcgJX71FN1uTKTmMYH9m4 Subject: [mpls] Fwd: second call: NomCom 2014-2015 Call for Volunteers 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, 05 Jun 2014 03:53:19 -0000 This is a multi-part message in MIME format. --------------040806090809060904030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group, Please consider volunteering for the NomCom. /Loa for the wg chairs -------- Original Message -------- Subject: second call: NomCom 2014-2015 Call for Volunteers Date: Tue, 03 Jun 2014 15:17:47 -0400 From: Michael Richardson To: ietf@ietf.org, WG Chairs The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). This is the second call for volunteers. (and you may have seen it more than once) If your name is on the below, then you have volunteered and are qualified. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 54 volunteers so far. The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: Your Full Name: __________-- Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ [] Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel DHRUV DHODY Dacheng Zhang Dapeng Liu Donald Eastlake Eric VYNCKE Fernando Gont Fred Baker Gonzalo Salgueiro Hongyu Li Hosnieh Rafiee Hugo Salgado John E Drake John Levine John Scudder Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Yong Mach Chen Mark Townsley Matt Lepinski Mehmet Ersue Melinda Shore Min Ye Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Yee Ralph Droms Ron Bonica Ross Callon Ross Finlayson Sam K. Aldrin Sanjay Mishra Sheng JIANG Shucheng Liu Stephan Friedl Stephan Wenger Stephen Kent Suhas Nandakumar Tim Wicinski Tissa Senevirathne Toerless Eckert Wassim Haddad Xiaohu XU Yuanlong Jiang -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --------------040806090809060904030709 Content-Type: application/pgp-signature; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIg KEdOVS9MaW51eCkNCg0KaVFFVkF3VUJVNDRmV0lDTGNQdmQwTjFsQVFJYXJRZitMRmdXcExD Y3VtTGRQMGtwcXIwYlA2eVlub0xqUEhXSw0KdDE0UDZ3Wi8vNWJhdEt3UlI3V09VbHduamU0 SEwydzQ4TjBpMzl5OUtVYVJndVJRT29ZR1VqdGdXMHVDRm9aVQ0KcnoveUF6VzZYNXIyakhD QWNGUFU1TlIrWWFuSXBYWXo5NXo4UmlHL2IrdFFueG1kV0ltdW9RTGJsbWRCNWZzZg0KTS9l Z1ZscTVIOHJZa1FneDZLN3JMRHlhcTFZSWd2Q0MvYjFmd2lmZmlyRjAzZGl3QmJLN054cndp eEk4UTZmLw0KQkJVTEJINnMxdUgzNnpVY0QveE4vd1FqNjMxdjZrM2FGYzhhZm45RXJSNVhE cFdzalRiakpJa2k3ajZxdFlPZg0KRTNXYzhSR1ZKME1UYTBhV2lBbkR0NGlhWlhSUzI5NEJZ aWxDVjlYT1I5UDMxSWJ4WFgvbnpRPT0NCj0vem83DQotLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS0NCg== --------------040806090809060904030709-- From nobody Wed Jun 4 22:20:58 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2153B1A03E4 for ; Wed, 4 Jun 2014 22:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeZ9_YQpR6ti for ; Wed, 4 Jun 2014 22:20:56 -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 E2B641A01A6 for ; Wed, 4 Jun 2014 22:20:55 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A98F61802AAB; Thu, 5 Jun 2014 07:20:46 +0200 (CEST) Message-ID: <538FFE2A.4010406@pi.nu> Date: Thu, 05 Jun 2014 07:20:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5379D3A8.5020507@pi.nu> In-Reply-To: <5379D3A8.5020507@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/l-fNstC460LWnhV28Alo5MnT2rw Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 05 Jun 2014 05:20:57 -0000 Working Group, draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call that was intended to be closed last Monday (June 2nd). Hopwever, there has not be a single response! I cn't make up my mind how to interprete this - either the wg have lost interest in the draft (which would surprise me greatly) or everybody thinks the draft is perfect (which would also be a surprise). I will therefore extend the wglc until June 16 and invite also positive responses (e.g. "I think this document is ready for publication!"). /Loa for the wg chairs On 2014-05-19 11:49, Loa Andersson wrote: > Working Group, > > This is to initiate a working group last call on > draft-ietf-mpls-lsp-ping-relay-reply. > > There are two IPR disclosures against this document. The author has > stated that he is unaware of any other IPRs that relate to this > document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends June 2, 2014. > > /Loa > for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 5 01:22:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC011A00F8 for ; Thu, 5 Jun 2014 01:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.5 X-Spam-Level: X-Spam-Status: No, score=-99.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 FTyC5GCJZZKp for ; Thu, 5 Jun 2014 01:22:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0A1A00A9 for ; Thu, 5 Jun 2014 01:22:20 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id C64961286FD1 for ; Thu, 5 Jun 2014 16:22:00 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2FDD5CDE555; Thu, 5 Jun 2014 16:22:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s558FtKv046707; Thu, 5 Jun 2014 16:17:01 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <538FFE2A.4010406@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Thu, 5 Jun 2014 14:57:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 16:17:03, Serialize complete at 2014-06-05 16:17:03 Content-Type: multipart/alternative; boundary="=_alternative 002674CD48257CEE_=" X-MAIL: mse01.zte.com.cn s558FtKv046707 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KSBybpxSAg329hXqZR6xemssGww Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 05 Jun 2014 08:22:24 -0000 This is a multipart message in MIME format. --=_alternative 002674CD48257CEE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c3VwcG9ydA0KDQoNCg0KDQpMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IA0Kt6K8/sjLOiAgIm1w bHMiIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQoyMDE0LTA2LTA1IDEzOjIwDQoNCsrVvP7Iyw0K Im1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0Ks63LzQ0KIjxtcGxzLWFkc0B0b29scy5p ZXRmLm9yZz4iLCAibXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIA0KPG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnPiwgDQoiZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5QHRv b2xzLmlldGYub3JnIiANCjxkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHlAdG9v bHMuaWV0Zi5vcmc+DQrW98ziDQpbbXBsc10gU3RpbGwgT3BlbiAtIFJlOiBXb3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBvbiANCmRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseQ0KDQoN Cg0KDQoNCg0KV29ya2luZyBHcm91cCwNCg0KZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5 LXJlcGx5IGlzIGluIGEgd29ya2luZyBncm91cCBsYXN0DQpjYWxsIHRoYXQgd2FzIGludGVuZGVk IHRvIGJlIGNsb3NlZCBsYXN0IE1vbmRheSAoSnVuZSAybmQpLg0KDQpIb3B3ZXZlciwgdGhlcmUg aGFzIG5vdCBiZSBhIHNpbmdsZSByZXNwb25zZSENCg0KSSBjbid0IG1ha2UgdXAgbXkgbWluZCBo b3cgdG8gaW50ZXJwcmV0ZSB0aGlzIC0gZWl0aGVyIHRoZSB3ZyBoYXZlDQpsb3N0IGludGVyZXN0 IGluIHRoZSBkcmFmdCAod2hpY2ggd291bGQgc3VycHJpc2UgbWUgZ3JlYXRseSkgb3INCmV2ZXJ5 Ym9keSB0aGlua3MgdGhlIGRyYWZ0IGlzIHBlcmZlY3QgKHdoaWNoIHdvdWxkIGFsc28gYmUgYSBz dXJwcmlzZSkuDQoNCkkgd2lsbCB0aGVyZWZvcmUgZXh0ZW5kIHRoZSB3Z2xjIHVudGlsIEp1bmUg MTYgYW5kIGludml0ZSBhbHNvIHBvc2l0aXZlDQpyZXNwb25zZXMgKGUuZy4gIkkgdGhpbmsgdGhp cyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24hIikuDQoNCi9Mb2ENCmZvciB0aGUg d2cgY2hhaXJzDQoNCk9uIDIwMTQtMDUtMTkgMTE6NDksIExvYSBBbmRlcnNzb24gd3JvdGU6DQo+ IFdvcmtpbmcgR3JvdXAsDQo+DQo+IFRoaXMgaXMgdG8gaW5pdGlhdGUgYSB3b3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBvbg0KPiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHkuDQo+ DQo+IFRoZXJlIGFyZSB0d28gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVudC4g VGhlIGF1dGhvciBoYXMNCj4gc3RhdGVkIHRoYXQgaGUgaXMgdW5hd2FyZSBvZiBhbnkgb3RoZXIg SVBScyB0aGF0IHJlbGF0ZSB0byB0aGlzDQo+IGRvY3VtZW50Lg0KPg0KPiBQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZyku DQo+DQo+IFRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBKdW5lIDIsIDIwMTQuDQo+ DQo+IC9Mb2ENCj4gZm9yIHRoZSBNUExTIHdnIGNoYWlycw0KDQotLSANCg0KDQpMb2EgQW5kZXJz c29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0K U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1 YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2 NA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBs cyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAg SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVu dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFu ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJl cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg bm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 002674CD48257CEE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnN1cHBvcnQ8YnI+DQo8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG9hIEFuZGVy c3NvbiAmbHQ7bG9hQHBpLm51Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDsmcXVvdDttcGxzJnF1b3Q7ICZsdDttcGxzLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTQtMDYtMDUgMTM6MjA8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0Bp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OyZsdDttcGxzLWFkc0B0b29scy5p ZXRmLm9yZyZndDsmcXVvdDssDQomcXVvdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZxdW90 OyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LA0KJnF1b3Q7ZHJhZnQtaWV0Zi1t cGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5QHRvb2xzLmlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1p ZXRmLW1wbHMtbHNwLXBpbmctcmVsYXktcmVwbHlAdG9vbHMuaWV0Zi5vcmcmZ3Q7PC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5bbXBsc10gU3RpbGwgT3BlbiAtIFJlOiBXb3JraW5nIGdyb3VwDQpsYXN0IGNh bGwgb24gZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5PC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5Xb3JraW5nIEdyb3Vw LDxicj4NCjxicj4NCmRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxheS1yZXBseSBpcyBpbiBh IHdvcmtpbmcgZ3JvdXAgbGFzdDxicj4NCmNhbGwgdGhhdCB3YXMgaW50ZW5kZWQgdG8gYmUgY2xv c2VkIGxhc3QgTW9uZGF5IChKdW5lIDJuZCkuPGJyPg0KPGJyPg0KSG9wd2V2ZXIsIHRoZXJlIGhh cyBub3QgYmUgYSBzaW5nbGUgcmVzcG9uc2UhPGJyPg0KPGJyPg0KSSBjbid0IG1ha2UgdXAgbXkg bWluZCBob3cgdG8gaW50ZXJwcmV0ZSB0aGlzIC0gZWl0aGVyIHRoZSB3ZyBoYXZlPGJyPg0KbG9z dCBpbnRlcmVzdCBpbiB0aGUgZHJhZnQgKHdoaWNoIHdvdWxkIHN1cnByaXNlIG1lIGdyZWF0bHkp IG9yPGJyPg0KZXZlcnlib2R5IHRoaW5rcyB0aGUgZHJhZnQgaXMgcGVyZmVjdCAod2hpY2ggd291 bGQgYWxzbyBiZSBhIHN1cnByaXNlKS48YnI+DQo8YnI+DQpJIHdpbGwgdGhlcmVmb3JlIGV4dGVu ZCB0aGUgd2dsYyB1bnRpbCBKdW5lIDE2IGFuZCBpbnZpdGUgYWxzbyBwb3NpdGl2ZTxicj4NCnJl c3BvbnNlcyAoZS5nLiAmcXVvdDtJIHRoaW5rIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1 YmxpY2F0aW9uISZxdW90OykuPGJyPg0KPGJyPg0KL0xvYTxicj4NCmZvciB0aGUgd2cgY2hhaXJz PGJyPg0KPGJyPg0KT24gMjAxNC0wNS0xOSAxMTo0OSwgTG9hIEFuZGVyc3NvbiB3cm90ZTo8YnI+ DQomZ3Q7IFdvcmtpbmcgR3JvdXAsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBpcyB0byBpbml0 aWF0ZSBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0KJmd0OyBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctcmVsYXktcmVwbHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUgYXJlIHR3 byBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50LiBUaGUgYXV0aG9yIGhhczxi cj4NCiZndDsgc3RhdGVkIHRoYXQgaGUgaXMgdW5hd2FyZSBvZiBhbnkgb3RoZXIgSVBScyB0aGF0 IHJlbGF0ZSB0byB0aGlzPGJyPg0KJmd0OyBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlzdCAobXBs c0BpZXRmLm9yZykuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBlbmRzIEp1bmUgMiwgMjAxNC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAvTG9hPGJyPg0KJmd0 OyBmb3IgdGhlIE1QTFMgd2cgY2hhaXJzPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KPGJyPg0K TG9hIEFuZGVyc3NvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtlbWFpbDogbG9hQG1haWww MS5odWF3ZWkuY29tPGJyPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0 YW50KSAmbmJzcDsgJm5ic3A7IHBob25lOiArNDYgNzM5IDgxIDIxIDY0PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1h aWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg0KPGJyPjxwcmU+ PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJ ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v dGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZv bnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMg aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5 b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlm eSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 002674CD48257CEE_=-- From nobody Thu Jun 5 08:52:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781B01A0167; Thu, 5 Jun 2014 08:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czsNL8t-u4wn; Thu, 5 Jun 2014 08:52:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77B1A0239; Thu, 5 Jun 2014 08:51:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: simon.delord@alcatel-lucent.com, wayne.caowei@huawei.com, frederic.jounay@orange.ch, ning.so@tatacommunications.com, mach.chen@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140605155157.10939.37363.idtracker@ietfa.amsl.com> Date: Thu, 05 Jun 2014 08:51:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nT0ZDp6yCbZNgX4v-eXnKf1t8w8 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 7110 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, 05 Jun 2014 15:52:01 -0000 Dear Simon DeLord, Wei Cao, Frederic JOUNAY, So Ning, Mach Chen: An IPR disclosure that pertains to your RFC entitled "Return Path Specified Label Switched Path (LSP) Ping" (RFC7110) was submitted to the IETF Secretariat on 2014-06-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2367/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 7110.""); The IETF Secretariat From nobody Thu Jun 5 10:02:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7541A017F for ; Thu, 5 Jun 2014 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EAtGNt5-gzdn for ; Thu, 5 Jun 2014 10:02:42 -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 A7D9C1A0171 for ; Thu, 5 Jun 2014 10:02:41 -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 s55H2XRE002450 for ; Thu, 5 Jun 2014 18:02:33 +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 s55H2U33002407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jun 2014 18:02:31 +0100 From: "Adrian Farrel" To: References: <20140605155157.10939.37363.idtracker@ietfa.amsl.com> In-Reply-To: <20140605155157.10939.37363.idtracker@ietfa.amsl.com> Date: Thu, 5 Jun 2014 18:02:30 +0100 Message-ID: <001d01cf80df$f12156b0$d3640410$@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: AQJOzCeGYFBm3F5fq6DeD8NEbVIY/ppkHmog Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20740.000 X-TM-AS-Result: No--4.434-10.0-31-10 X-imss-scan-details: No--4.434-10.0-31-10 X-TMASE-MatchedRID: Uu3ZxWwlOVKopzASH6BHT+G5dRZCgxC3t3aeg7g/usAutoY2UtFqGORv cIFrxqtm6fgsdTBg6N+oz7RlpzjJCEjQugR8Lz5wz4XVyhFFZHIZskwWqoib3KHP/60e74NCwbs dEe0NBScAZ708um2VX5gDhmkIBPAned6FhOj8IzpT46Ow+EhYOOp5yOkivZIXWgVUTdCRnKUtEj 3j0kH0Y+fOVcxjDhcwAYt5KiTiutkLbigRnpKlKZvjAepGmdoOryKWyDmSxnDf6Tb1YWRFYlU6Z gykj5J9rdhCsQE/tXT1S2v9nW1Q012j12S5FOaJOH4xa+tuA8lSGH6/jiCPm69a7NXKV3WM9HmA sM11v0u45mjKIIYY3xiCad9aBKWfm9p/RC99TJ4LxcqOxVsmNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/mMRRzUVSAE_LO_yTX3F0zcVg3xE Subject: [mpls] FW: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 7110 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, 05 Jun 2014 17:02:45 -0000 Hi, It looks to me that this disclosure is an update to the disclosure = against the I-D so that it is recorded directly against the RFC. Adrian > -----Original Message----- > From: IETF Secretariat [mailto:ietf-ipr@ietf.org] > Sent: 05 June 2014 16:52 > To: simon.delord@alcatel-lucent.com; wayne.caowei@huawei.com; > frederic.jounay@orange.ch; ning.so@tatacommunications.com; > mach.chen@huawei.com > Cc: adrian@olddog.co.uk; akatlas@gmail.com; loa@pi.nu; = swallow@cisco.com; > rcallon@juniper.net; mpls@ietf.org; ipr-announce@ietf.org > Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement = about IPR > related to RFC 7110 >=20 >=20 > Dear Simon DeLord, Wei Cao, Frederic JOUNAY, So Ning, Mach Chen: >=20 > An IPR disclosure that pertains to your RFC entitled "Return Path = Specified > Label Switched Path (LSP) Ping" (RFC7110) was submitted to the IETF = Secretariat > on 2014-06-05 and has been posted on the "IETF Page of Intellectual = Property > Rights Disclosures" (https://datatracker.ietf.org/ipr/2367/). The = title of the > IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR = related to > RFC 7110.""); >=20 > The IETF Secretariat From nobody Thu Jun 5 18:47:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC601A0380 for ; Thu, 5 Jun 2014 18:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.45 X-Spam-Level: X-Spam-Status: No, score=-98.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] 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 0z6qQN2d5nYo for ; Thu, 5 Jun 2014 18:47:32 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6C52B1A037C for ; Thu, 5 Jun 2014 18:47:32 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 9DA911924BE0 for ; Fri, 6 Jun 2014 09:47:15 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D6B05CC989C; Fri, 6 Jun 2014 09:47:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s561lB6C055134; Fri, 6 Jun 2014 09:47:11 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) To: Loa Andersson MIME-Version: 1.0 X-KeepSent: BF6E8F86:718E2ADD-48257CEF:00077725; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: chen.ran@zte.com.cn Date: Fri, 6 Jun 2014 09:47:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-06 09:47:12, Serialize complete at 2014-06-06 09:47:12 Content-Type: multipart/alternative; boundary="=_alternative 0009B93848257CEF_=" X-MAIL: mse01.zte.com.cn s561lB6C055134 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/y97noZ79BFJFmvruDT8dP5bgQ5o Cc: "mpls@ietf.org" Subject: [mpls] =?gb2312?b?UmWjuiBTdGlsbCBPcGVuIC0gUmU6IFdvcmtpbmcgZ3Jv?= =?gb2312?b?dXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1yZWxh?= =?gb2312?b?eS1yZXBseQ==?= 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, 06 Jun 2014 01:47:35 -0000 This is a multipart message in MIME format. --=_alternative 0009B93848257CEF_= Content-Type: text/plain; charset="US-ASCII" Support. Ran Chen > -----Original Message----- > Message: 2 > Date: Thu, 05 Jun 2014 07:20:42 +0200 > From: Loa Andersson > To: "mpls@ietf.org" > Cc: "" , > "mpls-chairs@tools.ietf.org" , > "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" > > Subject: [mpls] Still Open - Re: Working group last call on > draft-ietf-mpls-lsp-ping-relay-reply > Message-ID: <538FFE2A.4010406@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group, > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last > call that was intended to be closed last Monday (June 2nd). > > Hopwever, there has not be a single response! > > I cn't make up my mind how to interprete this - either the wg have > lost interest in the draft (which would surprise me greatly) or > everybody thinks the draft is perfect (which would also be a surprise). > > I will therefore extend the wglc until June 16 and invite also positive > responses (e.g. "I think this document is ready for publication!"). > > /Loa > for the wg chairs > > On 2014-05-19 11:49, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a working group last call on > > draft-ietf-mpls-lsp-ping-relay-reply. > > > > There are two IPR disclosures against this document. The author has > > stated that he is unaware of any other IPRs that relate to this > > document. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > This working group last call ends June 2, 2014. > > > > /Loa > > for the MPLS wg chairs > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --=_alternative 0009B93848257CEF_= Content-Type: text/html; charset="US-ASCII" Support.
Ran Chen

> -----Original Message-----
> Message: 2
> Date: Thu, 05 Jun 2014 07:20:42 +0200
> From: Loa Andersson <loa@pi.nu>
> To: "mpls@ietf.org" <mpls@ietf.org>
> Cc: "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org>,
>    "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>,
>    "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org"
>    <draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org>
> Subject: [mpls] Still Open - Re: Working group last call on
>    draft-ietf-mpls-lsp-ping-relay-reply
> Message-ID: <538FFE2A.4010406@pi.nu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Working Group,
>
> draft-ietf-mpls-lsp-ping-relay-reply is in a working group last
> call that was intended to be closed last Monday (June 2nd).
>
> Hopwever, there has not be a single response!
>
> I cn't make up my mind how to interprete this - either the wg have
> lost interest in the draft (which would surprise me greatly) or
> everybody thinks the draft is perfect (which would also be a surprise).
>
> I will therefore extend the wglc until June 16 and invite also positive
> responses (e.g. "I think this document is ready for publication!").
>
> /Loa
> for the wg chairs
>
> On 2014-05-19 11:49, Loa Andersson wrote:
> > Working Group,
> >
> > This is to initiate a working group last call on
> > draft-ietf-mpls-lsp-ping-relay-reply.
> >
> > There are two IPR disclosures against this document. The author has
> > stated that he is unaware of any other IPRs that relate to this
> > document.
> >
> > Please send your comments to the mpls wg mailing list (mpls@ietf.org).
> >
> > This working group last call ends June 2, 2014.
> >
> > /Loa
> > for the MPLS wg chairs
>
> --
>
>
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>
> --=_alternative 0009B93848257CEF_=-- From nobody Thu Jun 5 19:29:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46ED11A03BD; Thu, 5 Jun 2014 19:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSBCoyd8m6cH; Thu, 5 Jun 2014 19:29:15 -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 E30A21A03BB; Thu, 5 Jun 2014 19:29:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW83388; Fri, 06 Jun 2014 02:29:07 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 03:28:13 +0100 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, 6 Jun 2014 03:29:04 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 10:28:57 +0800 From: Xuxiaohu To: Hannes Gredler Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAKATQMAATqAigAARemRw Date: Fri, 6 Jun 2014 02:28:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EB7D@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <9818_1401797825_538DBCC1_9818_12387_1_9E32478DFA9976438E7A22F69B08FF920133A5@OPEXCLILM34.corporate.adroot.infra.ftgroup> 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.98.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Gch_CLJ_l4XcqYBbzNP_O4TzD38 Cc: "mpls@ietf.org" , "isis-chairs@tools.ietf.org" , "draft-xu-isis-mpls-elc@tools.ietf.org" , "" , "isis-wg@ietf.org list" Subject: Re: [mpls] [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 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, 06 Jun 2014 02:29:17 -0000 Hi Hannes, It seems that you are not talking about the particular ELC concept as defin= ed in RFC6790 (i..e, the capability of recognizing the ELI and popping that= ELI and the following EL). Instead, it seems that you are talking about so= mething else related to the capability of accessing the maximum label stack= depth. As for the granularity of the ELC advertisement (i.e., per-node basis or pe= r-interface-board basis), it has been discussed before. Although the ELC is= interface-board related, since it's almost impossible to determine at whic= h interface a packet destined for one of the router's addresses would arriv= e (e.g., a MPLS packet with the top label being a node segment ID of a give= n LSR), the feasible way of advertising the ELC is: the egress LSR SHOULD n= ot advertise its ELC unless all of its interface-boards have the ELC. By th= e way, this is exactly the same way that can be supported by RFC6790, IMHO. Best regards, Xiaohu=20 > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredl= er > Sent: Thursday, June 05, 2014 5:47 PM > To: Xuxiaohu > Cc: isis-chairs@tools.ietf.org; ; > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org list > Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-= 00 >=20 > >=20 > i'm discomfortable with the *granularity* of the cap-advertisement: >=20 > rather than saying: >=20 > "i can crawl as deep as you like on any of my interfaces" >=20 > i'd like to announce: >=20 > "i can crawl for EL up to labels deep on interface XYZ" >=20 >=20 > /hannes >=20 > On Jun 3, 2014, at 2:17 PM, > wrote: >=20 > > Hi, > > > > IMHO, before defining the capability, I would be more interrested on se= eing > some progress on a solution for EL over SPRING. A draft exists with multi= ple > options, maybe we should wait for one option to have consensus before > worrying about ELC encoding (quite easy part of the EL for SPRING). > > > > > > Stephane > > > > -----Message d'origine----- > > De : Isis-wg [mailto:isis-wg-bounces@ietf.org] De la part de Xuxiaohu > > Envoy=E9 : samedi 31 mai 2014 10:05 =C0 : isis-chairs@tools.ietf.org Cc= : > > draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org Objet : > > [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00 > > > > Hi WG co-chairs, > > > > This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) descr= ibes how > to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRIN= G > networks. Since > (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00= ) has > been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, w= e hope > you could consider the WG adoption for this draft as well. > > > > Best regards, > > Xiaohu (on behalf of all-authors) > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > > _____________________________________________________________ > _________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri Jun 6 13:14:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D531A026E; Fri, 6 Jun 2014 13:14:12 -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 Vf71b1GvNgAA; Fri, 6 Jun 2014 13:14:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0DD1A023E; Fri, 6 Jun 2014 13:14:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606201410.24610.39806.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 13:14:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4UsMD79HopabSc_ghHc8jO7D7QU Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-12.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:14:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-12.txt Pages : 42 Date : 2014-06-06 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 14:16:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460B41A027C for ; Fri, 6 Jun 2014 14:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3tTem9rzoSD for ; Fri, 6 Jun 2014 14:15:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F701A0274 for ; Fri, 6 Jun 2014 14:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6174; q=dns/txt; s=iport; t=1402089327; x=1403298927; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bddKG92WTu8B2pI/O7NRJI85FWCCo7I1MJBeg5y0cr0=; b=aTaOTjfk9iO+FAhXivqF6uXXToBVqTzBeYFE0TZcjV46espZbdFWGUnQ sAVKfgf22QxjC8y5osTw+3i6dge5PbcSf704YKgBHezPDOCE0z0kE48cj G2XlIuOoPaZd29boVMDakSmWax8c3wt6EdnVeWHc+W+kwEQiJqDlzmnBJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQIADQuklOtJA2G/2dsb2JhbABZgmkkUllzu1qHPAGBBxZ1hAMBAQEEAQEBNzEDCwwCAgIBCBEEAQEBChQJBxsMCxQJCAIEAQ0FCIg6AQzNSRMEBI4DEQEfMQcGgyWBFgStYYF8gUCBdjk X-IronPort-AV: E=Sophos;i="4.98,991,1392163200"; d="scan'208";a="50957930" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 06 Jun 2014 21:15:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s56LFQWJ027995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 21:15:26 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 16:15:26 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply Thread-Index: AQHPgH3yB3j9F0ZJHUKhGRn4Twxer5tkQO5A Date: Fri, 6 Jun 2014 21:15:25 +0000 Message-ID: References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> In-Reply-To: <538FFE2A.4010406@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/id8Xa-AuWqthyp34pXXD-33QJVo Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: Re: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 06 Jun 2014 21:15:41 -0000 Hi Loa, Authors, I have some comments and questions (and my apologies if questions have alre= ady been answered before). Section 3.2: The K bit may be set by ASBRs whose address would be kept in the stack if necessary. This is the only statement that I found regarding how responder is to decid= e the setting of the K bit. I read it as "Set K bit if I'm likely to be a r= elay point". I understand the motive behind this bit, but realistically it = seems a bit difficult to use, i.e. unless responder has some topology aware= ness, it's just simpler to just to set the K bit. Can you provide more thou= ghts on exactly how you intended to use this bit? On a related note, I did not find any texts around usage of K bit and Unspe= cified Address Type, which probably should be considered invalid. If you ag= ree, it would be good to add texts to enforce this. Section 4.2: , and the address entry of the replying LSR MUST be added at the bottom of the stack. The loop prevention paragraph in section 4.4 has a strict check that receiv= ed source IP address must be found in the address stack of the Relay Node A= ddress Stack TLV. In that case, above statement in section 4.2 should be ti= ghtened that source IP address of transmitted packet must be used as the "a= ddress entry of the replying LSR". Otherwise valid reply may be dropped by = a relay node. =09 Section 4.2: If the replying LSR is configured to hide its routable address information, the address entry added in the stack SHOULD be a blank entry with Address Type set to unspecified. The blank address entry in the receiving Echo Request SHOULD be treated as an unroutable address entry. What's the point of adding a blank entry (i.e. Unspecified Address Type)? I= suppose the purpose of this is to let the initiator know the responder is = intentionally hiding it's local address, but is that really necessary? If s= o, what's the point of initiator preserving this blank entry in the Relay N= ode Address Stack TLV in the next Echo Request, just to be deleted by the n= ext responder node? Section 4.4: I didn't see any texts describing what the source IP address of the packet = sent by receiver of Relayed Echo Reply. I'm guessing that we cannot copy re= ceived source IP address as the source IP address of transmitting Echo Repl= y or further Relayed Echo Reply, since that will break the loop prevention = proposed in Section 4.4. However, if we are not preserving the source IP ad= dress from the original responder node, then there's an impact to tracerout= e implementations as they usually print out received source IP addresses (w= hich no longer will be responder addresses). Initiator could do: If (Relay Node Address Stack TLV) { Print last address in the stack } else { Print source IP address } But if the last address in the stack was Unspecified, then traceroute resul= t now can become weaker than it used to be. Alternatively you could do: (1) Preserve the source IP address in received Relayed Echo Reply to transm= itting Echo Reply or Relay Echo Reply. (2) Add one more condition in the loop prevention check. If the first routa= ble address in the Relay Node Address Stack TLV is self, then drop. Not sure if RPF check would be a concerning point, but if not, above should= work and traceroute will remain the same as today. And if you go via this,= then source IP address will always be what would have been placed in the R= elay Node Address Stack TLV by the responder. In that case, the purpose of = Unspecified Address Type becomes questionable. General: The document does not say that Proxy Ping is outside the scope, however I t= hink a bit of additions are needed to make this work with Proxy Ping. For e= xample, first address in the Relay Node Address Stack TLV should be Proxy s= ender, and Proxy receiver (i.e. Echo Request sender) will need to follow th= e Relay Node Address Stack TLV update procedure just like receiver of Echo = Request. General: Any reason why TTL is not copied from received Relay Echo Reply to transmit= ting Echo Reply or Relay Echo Reply? Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, June 05, 2014 1:21 AM > To: mpls@ietf.org > Cc: ; mpls-chairs@tools.ietf.org; draft-ietf-mpl= s- > lsp-ping-relay-reply@tools.ietf.org > Subject: [mpls] Still Open - Re: Working group last call on draft-ietf-mp= ls- > lsp-ping-relay-reply >=20 > Working Group, >=20 > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call that= was > intended to be closed last Monday (June 2nd). >=20 > Hopwever, there has not be a single response! >=20 > I cn't make up my mind how to interprete this - either the wg have lost > interest in the draft (which would surprise me greatly) or everybody thin= ks > the draft is perfect (which would also be a surprise). >=20 > I will therefore extend the wglc until June 16 and invite also positive > responses (e.g. "I think this document is ready for publication!"). >=20 > /Loa > for the wg chairs >=20 > On 2014-05-19 11:49, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a working group last call on > > draft-ietf-mpls-lsp-ping-relay-reply. > > > > There are two IPR disclosures against this document. The author has > > stated that he is unaware of any other IPRs that relate to this > > document. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > This working group last call ends June 2, 2014. > > > > /Loa > > for the MPLS wg chairs >=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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jun 8 02:23:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49631A02E7 for ; Sun, 8 Jun 2014 02:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, 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 k1dO6rBE_m0l for ; Sun, 8 Jun 2014 02:23:06 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB06D1A02D0 for ; Sun, 8 Jun 2014 02:23:06 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rl12so4407735iec.35 for ; Sun, 08 Jun 2014 02:22:59 -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=9KWdrFElaa+h/pysA8JI+wlIvPHb2HUfbdFV3/TQTwA=; b=IRObBv6sQb6930myFIGqtTelSMp4ff992Y9JMqttkog3LEFMyZqILmtCaXFQbyYl7y uX23kg39wm8Fd7NIFT5fi3CIyWo76wfoI39A4PIJQ8V+gpsdRgCXgwOKBiGU5+MPKIQM /OSfW4veXi7+MScHewO2eylnDxnVayPKuZe3lqkcIOWtJxQIt1rc1thMlfVxoL9Jo2zd bI1gcHitEhrDCXlPdflGc0thzDDhhqv8R3uc9ShZVYurOmhkWtwG9gduS9qlIBK9zNP5 Z2gN16DwArrmx3/NpUa7p6GRQYOnYrsWIghgOIDCvavWPfil582YBOFNz85A5JJqqHZ6 i07Q== X-Received: by 10.50.153.8 with SMTP id vc8mr22939097igb.16.1402219379079; Sun, 08 Jun 2014 02:22:59 -0700 (PDT) Received: from LIZHONGJ ([140.206.240.67]) by mx.google.com with ESMTPSA id p12sm77971498igx.18.2014.06.08.02.22.51 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 08 Jun 2014 02:22:58 -0700 (PDT) From: "Lizhong Jin" To: "'Nobo Akiya \(nobo\)'" , "'Loa Andersson'" , References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> In-Reply-To: Date: Sun, 8 Jun 2014 17:22:43 +0800 Message-ID: <00ac01cf82fb$3ad42ea0$b07c8be0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFkNImub9tQ9oQH/0/dAlGlBbKZQHTWwX1AWjQmcub4I1D8A== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4koJMycD5vixOWwKtpkG1n9CV7M Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: Re: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 08 Jun 2014 09:23:08 -0000 Hi Nobo, Thank you for the detail review. See inline below. Regards Lizhong > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: 2014=C4=EA6=D4=C27=C8=D5 5:15 > To: Loa Andersson; mpls@ietf.org > Cc: ; mpls-chairs@tools.ietf.org; draft-ietf-mpls- > lsp-ping-relay-reply@tools.ietf.org > Subject: RE: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls- > lsp-ping-relay-reply >=20 > Hi Loa, Authors, >=20 > I have some comments and questions (and my apologies if questions have > already been answered before). >=20 >=20 > Section 3.2: >=20 > The K bit may be set by ASBRs whose address would be > kept in the stack if necessary. >=20 > This is the only statement that I found regarding how responder is to decide > the setting of the K bit. I read it as "Set K bit if I'm likely to be = a relay point". I > understand the motive behind this bit, but realistically it seems a = bit difficult > to use, i.e. unless responder has some topology awareness, it's just simpler > to just to set the K bit. Can you provide more thoughts on exactly how = you > intended to use this bit? [Lizhong] In a network with multiple ASs, and only ASBRs or border nodes = are the potential relay nodes. This maybe the most common case. The original thought is to let all ASBRs to be relay node, and the initiator could discover the ASBR list. So it is suggested to let ASBR (or border node) = to set K bit as a node wide configuration. But we did not restrict other = nodes to set K bit. >=20 > On a related note, I did not find any texts around usage of K bit and > Unspecified Address Type, which probably should be considered invalid. = If > you agree, it would be good to add texts to enforce this. [Lizhong] The usage and protocol operation of K bit and Unspecified = Address Type is described in section 4.2. I did not quite get this comment, = could you give more detail. >=20 >=20 > Section 4.2: >=20 > , and > the address entry of the replying LSR MUST be added at the bottom = of > the stack. >=20 > The loop prevention paragraph in section 4.4 has a strict check that received > source IP address must be found in the address stack of the Relay Node > Address Stack TLV. In that case, above statement in section 4.2 should = be > tightened that source IP address of transmitted packet must be used as = the > "address entry of the replying LSR". Otherwise valid reply may be = dropped by > a relay node. [Lizhong] accepted. Should be tightened that the address added in Relay = Node Address Stack TLV MUST be the source IP address of Relay Echo Reply or = Echo Reply message. >=20 >=20 > Section 4.2: >=20 > If the replying LSR is configured to hide its routable address > information, the address entry added in the stack SHOULD be a blank > entry with Address Type set to unspecified. The blank address = entry > in the receiving Echo Request SHOULD be treated as an unroutable > address entry. >=20 > What's the point of adding a blank entry (i.e. Unspecified Address = Type)? I > suppose the purpose of this is to let the initiator know the responder = is > intentionally hiding it's local address, but is that really necessary? = If so, what's > the point of initiator preserving this blank entry in the Relay Node Address > Stack TLV in the next Echo Request, just to be deleted by the next responder > node? [Lizhong] not only deleted by the next responder, if the replying LSR is = a relayed node, and reply with unspecified address, then the unspecified address will not be deleted by the compress process. As a result, the relayed echo reply will not be successfully sent back to initiator. = Security concern is the main motivation of setting Unspecified Address Type, = since Ping with Relayed Echo Rely could trace every node across domains. If = trace is only used for trouble shooting, in many cases, these hiding LSR will = not influence success of the trouble shooting if they are not relayed node. >=20 >=20 > Section 4.4: >=20 > I didn't see any texts describing what the source IP address of the = packet > sent by receiver of Relayed Echo Reply. I'm guessing that we cannot = copy > received source IP address as the source IP address of transmitting = Echo > Reply or further Relayed Echo Reply, since that will break the loop prevention > proposed in Section 4.4. However, if we are not preserving the source = IP > address from the original responder node, then there's an impact to > traceroute implementations as they usually print out received source = IP > addresses (which no longer will be responder addresses). >=20 > Initiator could do: >=20 > If (Relay Node Address Stack TLV) { > Print last address in the stack > } else { > Print source IP address > } >=20 > But if the last address in the stack was Unspecified, then traceroute result > now can become weaker than it used to be. >=20 > Alternatively you could do: >=20 > (1) Preserve the source IP address in received Relayed Echo Reply to > transmitting Echo Reply or Relay Echo Reply. > (2) Add one more condition in the loop prevention check. If the first routable > address in the Relay Node Address Stack TLV is self, then drop. >=20 > Not sure if RPF check would be a concerning point, but if not, above should > work and traceroute will remain the same as today. And if you go via = this, > then source IP address will always be what would have been placed in = the > Relay Node Address Stack TLV by the responder. In that case, the = purpose of > Unspecified Address Type becomes questionable. [Lizhong] The initiator should print last address in the stack, we = should add this in the text. It could say weaker than legacy traceroute from address displaying point of view. But traceroute is now working in a multi-domain case. Hiding address should be allowed if desired, under = the condition that trouble shooting could still be possible. Then we could = say the new traceroute is stronger than legacy from trouble shooting point = of view. =20 >=20 >=20 > General: >=20 > The document does not say that Proxy Ping is outside the scope, = however I > think a bit of additions are needed to make this work with Proxy Ping. = For > example, first address in the Relay Node Address Stack TLV should be = Proxy > sender, and Proxy receiver (i.e. Echo Request sender) will need to = follow the > Relay Node Address Stack TLV update procedure just like receiver of = Echo > Request. [Lizhong] right, but it seems draft-relay-reply moves faster than draft-proxy-lsp-ping. It would be more reasonable to add the suggested = text to draft-proxy-lsp-ping, right? I could talk this with author of draft-proxy-lsp-ping and chair. Thanks. >=20 >=20 > General: >=20 > Any reason why TTL is not copied from received Relay Echo Reply to > transmitting Echo Reply or Relay Echo Reply? [Lizhong] this is a missing part, and should be added. I think copy is = the right behavior. Thanks. Regards Lizhong >=20 >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: Thursday, June 05, 2014 1:21 AM > > To: mpls@ietf.org > > Cc: ; mpls-chairs@tools.ietf.org; > > draft-ietf-mpls- lsp-ping-relay-reply@tools.ietf.org > > Subject: [mpls] Still Open - Re: Working group last call on > > draft-ietf-mpls- lsp-ping-relay-reply > > > > Working Group, > > > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call > > that was intended to be closed last Monday (June 2nd). > > > > Hopwever, there has not be a single response! > > > > I cn't make up my mind how to interprete this - either the wg have > > lost interest in the draft (which would surprise me greatly) or > > everybody thinks the draft is perfect (which would also be a = surprise). > > > > I will therefore extend the wglc until June 16 and invite also > > positive responses (e.g. "I think this document is ready for publication!"). > > > > /Loa > > for the wg chairs > > > > On 2014-05-19 11:49, Loa Andersson wrote: > > > Working Group, > > > > > > This is to initiate a working group last call on > > > draft-ietf-mpls-lsp-ping-relay-reply. > > > > > > There are two IPR disclosures against this document. The author = has > > > stated that he is unaware of any other IPRs that relate to this > > > document. > > > > > > Please send your comments to the mpls wg mailing list = (mpls@ietf.org). > > > > > > This working group last call ends June 2, 2014. > > > > > > /Loa > > > for the MPLS wg chairs > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jun 8 07:05:01 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4E1A03D2 for ; Sun, 8 Jun 2014 07:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsZ7Rot3B5hy for ; Sun, 8 Jun 2014 07:04:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235991A03CD for ; Sun, 8 Jun 2014 07:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12215; q=dns/txt; s=iport; t=1402236290; x=1403445890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KuA6JwDNsCZlj/hfDl3Nm4ryjjIvIcDf0ewofsPdJCw=; b=FSdet40z0Clfi2H4NGKamnq3eFWxUANzjmHge2SKcSnJSyAzAhCeuItq gZ9OatRPUj3MN20Y+mqEKpMEKuuwuDP366thsUaOAKlE0U7x102fL8JKB MY/xc1emOXZBYh+I6cejeRoXAhlJegJxz3rWjC6ejzpC6mCpuHyUlppk0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAONslFOtJA2M/2dsb2JhbABYgmkkUlmCbLlzhzwBgQMWdYQDAQEBAwEBAQEeAUkDCwwCAgIBCA4DBAEBAQEDBgUYAgMCGwYGCxQJCAIEAQ0FCIgmAwkIAQySVpwfAZh1DYYIEwQEgSOLI4FAEQEfMQcGgmw5gRYEmCePRoV5gXyBQIF2OQ X-IronPort-AV: E=Sophos;i="4.98,998,1392163200"; d="scan'208";a="328373102" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jun 2014 14:04:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s58E4m8B006256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jun 2014 14:04:48 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Sun, 8 Jun 2014 09:04:48 -0500 From: "Nobo Akiya (nobo)" To: Lizhong Jin , "'Loa Andersson'" , "mpls@ietf.org" Thread-Topic: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply Thread-Index: AQHPgH3yB3j9F0ZJHUKhGRn4Twxer5tkQO5AgAMIToD//+7m0A== Date: Sun, 8 Jun 2014 14:04:47 +0000 Message-ID: References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> <00ac01cf82fb$3ad42ea0$b07c8be0$@gmail.com> In-Reply-To: <00ac01cf82fb$3ad42ea0$b07c8be0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.48] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LzE2VntJPwwDecj8yksMNktlB74 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: Re: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 08 Jun 2014 14:05:00 -0000 Hi Lizhong, Thanks for considering my comments. Please see-inline. > -----Original Message----- > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Sunday, June 08, 2014 5:23 AM > To: Nobo Akiya (nobo); 'Loa Andersson'; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-= lsp- > ping-relay-reply@tools.ietf.org > Subject: RE: [mpls] Still Open - Re: Working group last call on draft-iet= f- > mpls-lsp-ping-relay-reply >=20 > Hi Nobo, > Thank you for the detail review. See inline below. >=20 > Regards > Lizhong >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: 2014=1B$BG/=1B(B6=1B$B7n=1B(B7=1B$BF|=1B(B 5:15 > > To: Loa Andersson; mpls@ietf.org > > Cc: ; mpls-chairs@tools.ietf.org; > draft-ietf-mpls- > > lsp-ping-relay-reply@tools.ietf.org > > Subject: RE: [mpls] Still Open - Re: Working group last call on > draft-ietf-mpls- > > lsp-ping-relay-reply > > > > Hi Loa, Authors, > > > > I have some comments and questions (and my apologies if questions have > > already been answered before). > > > > > > Section 3.2: > > > > The K bit may be set by ASBRs whose address would be > > kept in the stack if necessary. > > > > This is the only statement that I found regarding how responder is to > decide > > the setting of the K bit. I read it as "Set K bit if I'm likely to be > > a > relay point". I > > understand the motive behind this bit, but realistically it seems a > > bit > difficult > > to use, i.e. unless responder has some topology awareness, it's just > simpler > > to just to set the K bit. Can you provide more thoughts on exactly how > > you intended to use this bit? > [Lizhong] In a network with multiple ASs, and only ASBRs or border nodes > are the potential relay nodes. This maybe the most common case. The > original thought is to let all ASBRs to be relay node, and the initiator = could > discover the ASBR list. So it is suggested to let ASBR (or border node) t= o set > K bit as a node wide configuration. But we did not restrict other nodes t= o set > K bit.=09 There's a slight conflict then. If the intention of the K bit is to let the= initiator discover ASBRs, then we should have a text that says ASBRs SHOUL= D set the K bit and non-ASBRs MUST NOT set the K bit. Otherwise non-ASBRs s= etting the K bit can give wrong information to the initiator. However, if t= he intention has become more loose (i.e. any node who wants to remain in th= e TLV as the relay node), then perhaps a short text would be helpful. Somet= hing like: Having the K bit set on the relay node address entry causes that entry to be preserved in the Relay Node Address Stack TLV for the entire traceroute operation. A responder node MAY set the K bit to ensure its relay node address entry remains as one of the relay nodes in the Relay Node Address Stack TLV. Some nodes (ex: ASBR) could be configured to always set the K bit, or the module handling MPLS echo requests could discover its K bit use through topology awareness. How a node determines to set the K bit is outside the scope of this document. >=20 > > > > On a related note, I did not find any texts around usage of K bit and > > Unspecified Address Type, which probably should be considered invalid. > > If you agree, it would be good to add texts to enforce this. > [Lizhong] The usage and protocol operation of K bit and Unspecified Addre= ss > Type is described in section 4.2. I did not quite get this comment, could= you > give more detail. What I meant was, do we ever want a relay node address entry that has K bit= set _and_ is Unspecified Address Type? It seems that will just waste space= in the Relay Node Address Stack TLV (and on the wire). I was just asking i= f there's any reason why K bit & Unspecified combination is not restricted. >=20 > > > > > > Section 4.2: > > > > , and > > the address entry of the replying LSR MUST be added at the bottom of > > the stack. > > > > The loop prevention paragraph in section 4.4 has a strict check that > received > > source IP address must be found in the address stack of the Relay Node > > Address Stack TLV. In that case, above statement in section 4.2 should > > be tightened that source IP address of transmitted packet must be used > > as the "address entry of the replying LSR". Otherwise valid reply may > > be dropped > by > > a relay node. > [Lizhong] accepted. Should be tightened that the address added in Relay > Node Address Stack TLV MUST be the source IP address of Relay Echo Reply > or Echo Reply message. Thanks. >=20 > > > > > > Section 4.2: > > > > If the replying LSR is configured to hide its routable address > > information, the address entry added in the stack SHOULD be a blank > > entry with Address Type set to unspecified. The blank address entry > > in the receiving Echo Request SHOULD be treated as an unroutable > > address entry. > > > > What's the point of adding a blank entry (i.e. Unspecified Address Type= )? > I > > suppose the purpose of this is to let the initiator know the responder > > is intentionally hiding it's local address, but is that really > > necessary? If > so, what's > > the point of initiator preserving this blank entry in the Relay Node > Address > > Stack TLV in the next Echo Request, just to be deleted by the next > responder > > node? > [Lizhong] not only deleted by the next responder, if the replying LSR is = a > relayed node, and reply with unspecified address, then the unspecified > address will not be deleted by the compress process. As a result, the > relayed echo reply will not be successfully sent back to initiator. Secur= ity > concern is the main motivation of setting Unspecified Address Type, since > Ping with Relayed Echo Rely could trace every node across domains. If tra= ce > is only used for trouble shooting, in many cases, these hiding LSR will n= ot > influence success of the trouble shooting if they are not relayed node. Ok, based on your answers above and below, blank entry makes sense. Althoug= h I don't see the point of allowing a blank entry have a K bit set. >=20 > > > > > > Section 4.4: > > > > I didn't see any texts describing what the source IP address of the > > packet sent by receiver of Relayed Echo Reply. I'm guessing that we > > cannot copy received source IP address as the source IP address of > > transmitting Echo Reply or further Relayed Echo Reply, since that will > > break the loop > prevention > > proposed in Section 4.4. However, if we are not preserving the source > > IP address from the original responder node, then there's an impact to > > traceroute implementations as they usually print out received source > > IP addresses (which no longer will be responder addresses). > > > > Initiator could do: > > > > If (Relay Node Address Stack TLV) { > > Print last address in the stack > > } else { > > Print source IP address > > } > > > > But if the last address in the stack was Unspecified, then traceroute > result > > now can become weaker than it used to be. > > > > Alternatively you could do: > > > > (1) Preserve the source IP address in received Relayed Echo Reply to > > transmitting Echo Reply or Relay Echo Reply. > > (2) Add one more condition in the loop prevention check. If the first > routable > > address in the Relay Node Address Stack TLV is self, then drop. > > > > Not sure if RPF check would be a concerning point, but if not, above > should > > work and traceroute will remain the same as today. And if you go via > > this, then source IP address will always be what would have been > > placed in the Relay Node Address Stack TLV by the responder. In that > > case, the purpose > of > > Unspecified Address Type becomes questionable. > [Lizhong] The initiator should print last address in the stack, we should= add > this in the text. It could say weaker than legacy traceroute from address > displaying point of view. But traceroute is now working in a multi-domain > case. Hiding address should be allowed if desired, under the condition th= at > trouble shooting could still be possible. Then we could say the new > traceroute is stronger than legacy from trouble shooting point of view. Ok in that case, please add texts for: - Source IP address in Echo Reply and Relay Echo Reply are to be of the add= ress of the node sending those packets (i.e. not copied from received Relay= Echo Reply). - Traceroute address output module will need to conditionally print the add= ress in the Relay Node Address Stack TLV. >=20 > > > > > > General: > > > > The document does not say that Proxy Ping is outside the scope, > > however I think a bit of additions are needed to make this work with > > Proxy Ping. For example, first address in the Relay Node Address Stack > > TLV should be Proxy sender, and Proxy receiver (i.e. Echo Request > > sender) will need to follow > the > > Relay Node Address Stack TLV update procedure just like receiver of > > Echo Request. > [Lizhong] right, but it seems draft-relay-reply moves faster than draft-p= roxy- > lsp-ping. It would be more reasonable to add the suggested text to draft- > proxy-lsp-ping, right? I could talk this with author of draft-proxy-lsp-p= ing > and chair. Thanks. Ah right, I forgot that Proxy has not become RFC yet. Yes I think that'll b= e a good idea to make sure to raise this point to Proxy authors and chairs = so that it gets on some "todo list". >=20 > > > > > > General: > > > > Any reason why TTL is not copied from received Relay Echo Reply to > > transmitting Echo Reply or Relay Echo Reply? > [Lizhong] this is a missing part, and should be added. I think copy is th= e right > behavior. Thanks. Agree. Thanks! -Nobo >=20 > Regards > Lizhong >=20 > > > > > > Thanks! > > > > -Nobo > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > > Sent: Thursday, June 05, 2014 1:21 AM > > > To: mpls@ietf.org > > > Cc: ; mpls-chairs@tools.ietf.org; > > > draft-ietf-mpls- lsp-ping-relay-reply@tools.ietf.org > > > Subject: [mpls] Still Open - Re: Working group last call on > > > draft-ietf-mpls- lsp-ping-relay-reply > > > > > > Working Group, > > > > > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call > > > that was intended to be closed last Monday (June 2nd). > > > > > > Hopwever, there has not be a single response! > > > > > > I cn't make up my mind how to interprete this - either the wg have > > > lost interest in the draft (which would surprise me greatly) or > > > everybody thinks the draft is perfect (which would also be a surprise= ). > > > > > > I will therefore extend the wglc until June 16 and invite also > > > positive responses (e.g. "I think this document is ready for > publication!"). > > > > > > /Loa > > > for the wg chairs > > > > > > On 2014-05-19 11:49, Loa Andersson wrote: > > > > Working Group, > > > > > > > > This is to initiate a working group last call on > > > > draft-ietf-mpls-lsp-ping-relay-reply. > > > > > > > > There are two IPR disclosures against this document. The author > > > > has stated that he is unaware of any other IPRs that relate to > > > > this document. > > > > > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.or= g). > > > > > > > > This working group last call ends June 2, 2014. > > > > > > > > /Loa > > > > for the MPLS wg chairs > > > > > > -- > > > > > > > > > Loa Andersson email: loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jun 8 07:17:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3C1A03DD; Sun, 8 Jun 2014 07:16: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 V3QYZdvTIHdS; Sun, 8 Jun 2014 07:16:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C18C1A03CD; Sun, 8 Jun 2014 07:16:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140608141656.28192.92664.idtracker@ietfa.amsl.com> Date: Sun, 08 Jun 2014 07:16:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/3wVr4J8qylFiODkvFFCgV8Y9oXk Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-13.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 14:16:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Inter-Area P2MP Segmented LSPs Authors : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-13.txt Pages : 42 Date : 2014-06-08 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mcast-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 8 14:24:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF6A1A0435 for ; Sun, 8 Jun 2014 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 yzZvyY4-Di_d for ; Sun, 8 Jun 2014 14:24:41 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DDD1A01D2 for ; Sun, 8 Jun 2014 14:24:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s58LObIl018154; Sun, 8 Jun 2014 22:24:37 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s58LOajn018139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 22:24:37 +0100 From: "Adrian Farrel" To: Date: Sun, 8 Jun 2014 22:24:36 +0100 Message-ID: <049a01cf8360$0d076040$271620c0$@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: Ac+DYAyFUs/dROdIRW6Md7tW88z9RQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20746.002 X-TM-AS-Result: No--4.405-10.0-31-10 X-imss-scan-details: No--4.405-10.0-31-10 X-TMASE-MatchedRID: IW8Rh/B1oKwmMPeO88gK4Jmug812qIbzbv16+gil4jc3Z3efQH+wj0j8 AtVpDcmg30nY8d71auJNZ9FRDRej7dUW1/ttV+ezaNnyr85zWcDiZyLfY10wsqj5v7I4/SgYoP1 oO+0njF6eEENCc9btdGG2/IjfBukAJR61hcW9/TgUEm127/0kJl+PJNkR/r/XuSIn8GC9fqses7 v6moA5qMPSyGkwpDCaYeB/5hLtN7D/xPKSgLvkLcpQKjU7fBXVoprEeoZHCQLOxDyJFXIPjqrMG Tc59AyQ0BiYqrDBjB6ZW4K/UTlwEtfmcY8SPqo8Y7jepwkpr6+7atxTbKDEIJwVp42I+OQBI6qq 9xPsXYjmCdnSgRFdjhndlCPDt8aLlwV2iaAfSWcksSBZTGCrwrTrdaH1ZWqCHOI0tZ7A+B36C0e Ps7A07aLm79W+wVod5YdK/8Ka1/iiccTQ4M56mIViPczriOctCStuYkNX4trAXJk3qOhH1fLdF9 c5+IXmlDS4qddxFr/0HXkbcBsCPEVz21Q9UZ7kh8f9+fd10RPkvmU7gj2frT4n7o4CNd3aPbiTc h0pm34= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/g9e4XmNe7PE4sR506e8vW-mfz34 Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-smp-requirements 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: Sun, 08 Jun 2014 21:24:43 -0000 Hi authors, I have done my usual review of your document having received the publication request. The purpose of my review is to improve the quality of the document and to catch any issues that might otherwise show up during IETF last call, Directorate reviews, or IESG evaluation. This is a pretty good document. Thanks for the effort you have put in, and thanks to Matt for working on the English. He deserves an acknowledgement somewhere in the document. I have only a few issues, and they don't merit a new revision now. So I will start the IETF last call and raise these points to be addressed at that time. Thanks, Adrian --- Could you expand "p2p" where it is first used? --- The very first sentence is hard to parse MPLS transport networks can be characterized as being a network of connections between nodes within a mesh of nodes and the links between them. Maybe try The MPLS Transport Profile (MPLS-TP) provides tools to construct and operate a set of connections between nodes in an MPLS network. The MPLS network is a mesh comprising nodes and the links between them. --- I understand that you want to use RFC 2119 language to clarify the requirements, but RFC 2119 was developed for specifying protocols, so the direct reference and boilerplate quote is incongruous. I suggest you use the language as found in RFC 5654, viz.: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document. --- In Section 5.1 you have the control protocol SHOULD NOT be used as the primary resilience mechanism. I agree, but I think that the term "primary resilience mechanism" may be under defined. Can you do anything to clarify this? Maybe... the control protocol SHOULD NOT be used as the primary mechanism for detecting or reporting network failures, or for initiating or coordinating protection switch-over. That is, it SHOULD NOT be used as the primary resilience mechanism. From nobody Sun Jun 8 14:30:54 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117D11A0435 for ; Sun, 8 Jun 2014 14:30:53 -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 XC2sBlV0GaQ1 for ; Sun, 8 Jun 2014 14:30:51 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791821A01D2 for ; Sun, 8 Jun 2014 14:30:51 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so8056455qgd.33 for ; Sun, 08 Jun 2014 14:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=qRP3k0pYxW41ZFjscn4NZwUH3o5uKjuK4jksOlzAkgo=; b=lzmRbzBUIGJ7YeCL5SypXKk98UO1E34UOXL66t8in6yWy3bvO1DAKQHNfN5+krXivY 8BS+HYClk/lRFCIAA9ORb6ZXzt95K7DsG2G4ZUoqatARoAa8cOUdKfobKWEGue5yCJsK 1WxSDwwg6EcDc+ggG9l+CGo7ALEjS/UMg5705j7qQX/72NqRlE3Dixy1Ztg+1cjO0+8I QHqEfoGJmOfSisG4RZFXJGqS0Cg1IEfKSUUQ+rAhlE9cKbV6vTU/ni+HoMr1f8kxZjGv RUo/dohc8evSMY5y7QWES5G/kleQTpckBLP1lmiHlpzrsfVJf4K2h9kLAKaZhJVuI4K6 FT9g== X-Received: by 10.140.29.226 with SMTP id b89mr26493018qgb.48.1402263050695; Sun, 08 Jun 2014 14:30:50 -0700 (PDT) Received: from [10.237.145.99] (mobile-198-228-199-148.mycingular.net. [198.228.199.148]) by mx.google.com with ESMTPSA id b10sm10407318qgf.7.2014.06.08.14.30.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 14:30:49 -0700 (PDT) References: <049a01cf8360$0d076040$271620c0$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <049a01cf8360$0d076040$271620c0$@olddog.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <30AA7009-8770-470D-9D61-0D58FFB5E053@gmail.com> X-Mailer: iPhone Mail (11D201) From: Sam Aldrin Date: Sun, 8 Jun 2014 17:30:48 -0400 To: "adrian@olddog.co.uk" Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dm1VnNai9yi5Rm_mcKbumhk63dM Cc: "mpls@ietf.org" , "" Subject: Re: [mpls] AD review of draft-ietf-mpls-smp-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: Sun, 08 Jun 2014 21:30:53 -0000 Hi Adrian, Thanks for the feedback and comments. Will definitely add Matt to ack sectio= n. Sorry for missing out to add him in the recent revision. Thanks Sam Sent from my iPhone > On Jun 8, 2014, at 5:24 PM, "Adrian Farrel" wrote: >=20 > Hi authors, >=20 > I have done my usual review of your document having received the > publication request. The purpose of my review is to improve the > quality of the document and to catch any issues that might otherwise > show up during IETF last call, Directorate reviews, or IESG evaluation. >=20 > This is a pretty good document. Thanks for the effort you have put in, > and thanks to Matt for working on the English. He deserves an > acknowledgement somewhere in the document. >=20 > I have only a few issues, and they don't merit a new revision now. > So I will start the IETF last call and raise these points to be=20 > addressed at that time. >=20 > Thanks, > Adrian >=20 > --- >=20 > Could you expand "p2p" where it is first used? >=20 > --- >=20 > The very first sentence is hard to parse >=20 > MPLS transport networks can be characterized as being a network of > connections between nodes within a mesh of nodes and the links > between them.=20 >=20 > Maybe try >=20 > The MPLS Transport Profile (MPLS-TP) provides tools to construct and > operate a set of connections between nodes in an MPLS network. The > MPLS network is a mesh comprising nodes and the links between them. >=20 > --- >=20 > I understand that you want to use RFC 2119 language to clarify the=20 > requirements, but RFC 2119 was developed for specifying protocols, so=20 > the direct reference and boilerplate quote is incongruous. I suggest > you use the language as found in RFC 5654, viz.: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > Although this document is not a protocol specification, the use of > this language clarifies the instructions to protocol designers > producing solutions that satisfy the requirements set out in this > document. >=20 > --- >=20 > In Section 5.1 you have >=20 > the control > protocol SHOULD NOT be used as the primary resilience mechanism. >=20 > I agree, but I think that the term "primary resilience mechanism" may be > under defined. Can you do anything to clarify this? Maybe... >=20 > the control > protocol SHOULD NOT be used as the primary mechanism for detecting or > reporting network failures, or for initiating or coordinating=20 > protection switch-over. That is, it SHOULD NOT be used as the=20 > primary resilience mechanism. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jun 8 17:27:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8921B27A1 for ; Sun, 8 Jun 2014 17:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Df28P6MN36H for ; Sun, 8 Jun 2014 17:27:29 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB341B279D for ; Sun, 8 Jun 2014 17:27:28 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jun 2014 09:27:26 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Mon, 9 Jun 2014 09:27:23 +0900 From: Jeong Ryoo To: Sam Aldrin , "adrian@olddog.co.uk" Thread-Topic: [mpls] AD review of draft-ietf-mpls-smp-requirements Thread-Index: Ac+DYAyFUs/dROdIRW6Md7tW88z9Rf//atoAgADHdMI= Date: Mon, 9 Jun 2014 00:27:22 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A287436EC@SMTP2.etri.info> References: <049a01cf8360$0d076040$271620c0$@olddog.co.uk>, <30AA7009-8770-470D-9D61-0D58FFB5E053@gmail.com> In-Reply-To: <30AA7009-8770-470D-9D61-0D58FFB5E053@gmail.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A287436ECSMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/wP9eSrDpYoAJz96v0Xr603ztb1w Cc: "mpls@ietf.org" Subject: Re: [mpls] AD review of draft-ietf-mpls-smp-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, 09 Jun 2014 00:27:31 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A287436ECSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRyaWFuLCB0aGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpNYXR0IGRlZmluaXRlbHkgZGVzZXJ2 ZXMgYW4gYWNrbm93bGVkZ2VtZW50Lg0KDQpUaGFua3MuDQoNCkplb25nLWRvbmcNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrrs7Trgrgg7IKs656MIDogIlNhbSBBbGRy aW4iIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+DQrrs7Trgrgg64Kg7KecIDogMjAxNC0wNi0wOSAw NjozMTowMyAoICswOTowMCApDQrrsJvripQg7IKs656MIDogYWRyaWFuQG9sZGRvZy5jby51ayA8 YWRyaWFuQG9sZGRvZy5jby51az4NCuywuOyhsCA6IG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5v cmc+LCA8ZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3Jn Pg0K7KCc66qpIDogUmU6IFttcGxzXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMNCg0KDQpIaSBBZHJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIGFu ZCBjb21tZW50cy4gV2lsbCBkZWZpbml0ZWx5IGFkZCBNYXR0IHRvIGFjayBzZWN0aW9uLiBTb3Jy eSBmb3IgbWlzc2luZyBvdXQgdG8gYWRkIGhpbSBpbiB0aGUgcmVjZW50IHJldmlzaW9uLg0KDQpU aGFua3MNClNhbQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24gSnVuIDgsIDIwMTQsIGF0 IDU6MjQgUE0sICJBZHJpYW4gRmFycmVsIiB3cm90ZToNCj4NCj4gSGkgYXV0aG9ycywNCj4NCj4g SSBoYXZlIGRvbmUgbXkgdXN1YWwgcmV2aWV3IG9mIHlvdXIgZG9jdW1lbnQgaGF2aW5nIHJlY2Vp dmVkIHRoZQ0KPiBwdWJsaWNhdGlvbiByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiBteSByZXZpZXcg aXMgdG8gaW1wcm92ZSB0aGUNCj4gcXVhbGl0eSBvZiB0aGUgZG9jdW1lbnQgYW5kIHRvIGNhdGNo IGFueSBpc3N1ZXMgdGhhdCBtaWdodCBvdGhlcndpc2UNCj4gc2hvdyB1cCBkdXJpbmcgSUVURiBs YXN0IGNhbGwsIERpcmVjdG9yYXRlIHJldmlld3MsIG9yIElFU0cgZXZhbHVhdGlvbi4NCj4NCj4g VGhpcyBpcyBhIHByZXR0eSBnb29kIGRvY3VtZW50LiBUaGFua3MgZm9yIHRoZSBlZmZvcnQgeW91 IGhhdmUgcHV0IGluLA0KPiBhbmQgdGhhbmtzIHRvIE1hdHQgZm9yIHdvcmtpbmcgb24gdGhlIEVu Z2xpc2guIEhlIGRlc2VydmVzIGFuDQo+IGFja25vd2xlZGdlbWVudCBzb21ld2hlcmUgaW4gdGhl IGRvY3VtZW50Lg0KPg0KPiBJIGhhdmUgb25seSBhIGZldyBpc3N1ZXMsIGFuZCB0aGV5IGRvbid0 IG1lcml0IGEgbmV3IHJldmlzaW9uIG5vdy4NCj4gU28gSSB3aWxsIHN0YXJ0IHRoZSBJRVRGIGxh c3QgY2FsbCBhbmQgcmFpc2UgdGhlc2UgcG9pbnRzIHRvIGJlDQo+IGFkZHJlc3NlZCBhdCB0aGF0 IHRpbWUuDQo+DQo+IFRoYW5rcywNCj4gQWRyaWFuDQo+DQo+IC0tLQ0KPg0KPiBDb3VsZCB5b3Ug ZXhwYW5kICJwMnAiIHdoZXJlIGl0IGlzIGZpcnN0IHVzZWQ/DQo+DQo+IC0tLQ0KPg0KPiBUaGUg dmVyeSBmaXJzdCBzZW50ZW5jZSBpcyBoYXJkIHRvIHBhcnNlDQo+DQo+IE1QTFMgdHJhbnNwb3J0 IG5ldHdvcmtzIGNhbiBiZSBjaGFyYWN0ZXJpemVkIGFzIGJlaW5nIGEgbmV0d29yayBvZg0KPiBj b25uZWN0aW9ucyBiZXR3ZWVuIG5vZGVzIHdpdGhpbiBhIG1lc2ggb2Ygbm9kZXMgYW5kIHRoZSBs aW5rcw0KPiBiZXR3ZWVuIHRoZW0uDQo+DQo+IE1heWJlIHRyeQ0KPg0KPiBUaGUgTVBMUyBUcmFu c3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcHJvdmlkZXMgdG9vbHMgdG8gY29uc3RydWN0IGFuZA0K PiBvcGVyYXRlIGEgc2V0IG9mIGNvbm5lY3Rpb25zIGJldHdlZW4gbm9kZXMgaW4gYW4gTVBMUyBu ZXR3b3JrLiBUaGUNCj4gTVBMUyBuZXR3b3JrIGlzIGEgbWVzaCBjb21wcmlzaW5nIG5vZGVzIGFu ZCB0aGUgbGlua3MgYmV0d2VlbiB0aGVtLg0KPg0KPiAtLS0NCj4NCj4gSSB1bmRlcnN0YW5kIHRo YXQgeW91IHdhbnQgdG8gdXNlIFJGQyAyMTE5IGxhbmd1YWdlIHRvIGNsYXJpZnkgdGhlDQo+IHJl cXVpcmVtZW50cywgYnV0IFJGQyAyMTE5IHdhcyBkZXZlbG9wZWQgZm9yIHNwZWNpZnlpbmcgcHJv dG9jb2xzLCBzbw0KPiB0aGUgZGlyZWN0IHJlZmVyZW5jZSBhbmQgYm9pbGVycGxhdGUgcXVvdGUg aXMgaW5jb25ncnVvdXMuIEkgc3VnZ2VzdA0KPiB5b3UgdXNlIHRoZSBsYW5ndWFnZSBhcyBmb3Vu ZCBpbiBSRkMgNTY1NCwgdml6LjoNCj4NCj4gVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KPiAiU0hPVUxEIiwgIlNIT1VM RCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KPiBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtS RkMyMTE5XS4NCj4gQWx0aG91Z2ggdGhpcyBkb2N1bWVudCBpcyBub3QgYSBwcm90b2NvbCBzcGVj aWZpY2F0aW9uLCB0aGUgdXNlIG9mDQo+IHRoaXMgbGFuZ3VhZ2UgY2xhcmlmaWVzIHRoZSBpbnN0 cnVjdGlvbnMgdG8gcHJvdG9jb2wgZGVzaWduZXJzDQo+IHByb2R1Y2luZyBzb2x1dGlvbnMgdGhh dCBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzDQo+IGRvY3VtZW50Lg0K Pg0KPiAtLS0NCj4NCj4gSW4gU2VjdGlvbiA1LjEgeW91IGhhdmUNCj4NCj4gdGhlIGNvbnRyb2wN Cj4gcHJvdG9jb2wgU0hPVUxEIE5PVCBiZSB1c2VkIGFzIHRoZSBwcmltYXJ5IHJlc2lsaWVuY2Ug bWVjaGFuaXNtLg0KPg0KPiBJIGFncmVlLCBidXQgSSB0aGluayB0aGF0IHRoZSB0ZXJtICJwcmlt YXJ5IHJlc2lsaWVuY2UgbWVjaGFuaXNtIiBtYXkgYmUNCj4gdW5kZXIgZGVmaW5lZC4gQ2FuIHlv dSBkbyBhbnl0aGluZyB0byBjbGFyaWZ5IHRoaXM/IE1heWJlLi4uDQo+DQo+IHRoZSBjb250cm9s DQo+IHByb3RvY29sIFNIT1VMRCBOT1QgYmUgdXNlZCBhcyB0aGUgcHJpbWFyeSBtZWNoYW5pc20g Zm9yIGRldGVjdGluZyBvcg0KPiByZXBvcnRpbmcgbmV0d29yayBmYWlsdXJlcywgb3IgZm9yIGlu aXRpYXRpbmcgb3IgY29vcmRpbmF0aW5nDQo+IHByb3RlY3Rpb24gc3dpdGNoLW92ZXIuIFRoYXQg aXMsIGl0IFNIT1VMRCBOT1QgYmUgdXNlZCBhcyB0aGUNCj4gcHJpbWFyeSByZXNpbGllbmNlIG1l Y2hhbmlzbS4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A287436ECSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIw cHQiPkFkcmlhbiwgdGhhbmtzIGZvciB5b3VyIHJldmlldy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAyMHB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAy MHB0Ij5NYXR0IGRlZmluaXRlbHkgZGVzZXJ2ZXMgYW4gYWNrbm93bGVkZ2VtZW50LjwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPiZuYnNwOzxicj4NClRoYW5rcy48L2Rpdj4N CjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9 IkxJTkUtSEVJR0hUOiAyMHB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMjBwdCI+PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnQiIHN0 eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJPUkdNQUlMX0NP TlRFTlQiIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxi PuuztOuCuCDsgqzrnowgOiA8L2I+JnF1b3Q7U2FtIEFsZHJpbiZxdW90OyAmbHQ7YWxkcmluLmll dGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPuuztOuCuCDrgqDsp5wgOiA8L2I+MjAxNC0wNi0wOSAw NjozMTowMyAoICYjNDM7MDk6MDAgKTxicj4NCjxiPuuwm+uKlCDsgqzrnowgOiA8L2I+YWRyaWFu QG9sZGRvZy5jby51ayAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs8YnI+DQo8Yj7ssLjsobAg OiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIDxEUkFGVC1JRVRGLU1Q TFMtU01QLVJFUVVJUkVNRU5UUy5BTExAVE9PTFMuSUVURi5PUkc+DQombHQ7ZHJhZnQtaWV0Zi1t cGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPuygnOuq qSA6IDwvYj5SZTogW21wbHNdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVp cmVtZW50czxicj4NCjxicj4NCjxicj4NCkhpIEFkcmlhbiw8YnI+DQo8YnI+DQpUaGFua3MgZm9y IHRoZSBmZWVkYmFjayBhbmQgY29tbWVudHMuIFdpbGwgZGVmaW5pdGVseSBhZGQgTWF0dCB0byBh Y2sgc2VjdGlvbi4gU29ycnkgZm9yIG1pc3Npbmcgb3V0IHRvIGFkZCBoaW0gaW4gdGhlIHJlY2Vu dCByZXZpc2lvbi48YnI+DQo8YnI+DQpUaGFua3M8YnI+DQpTYW08YnI+DQo8YnI+DQpTZW50IGZy b20gbXkgaVBob25lPGJyPg0KPGJyPg0KJmd0OyBPbiBKdW4gOCwgMjAxNCwgYXQgNToyNCBQTSwg JnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OyA8QURSSUFOQE9MRERPRy5DTy5VSz53cm90ZTo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgSGkgYXV0aG9ycyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZl IGRvbmUgbXkgdXN1YWwgcmV2aWV3IG9mIHlvdXIgZG9jdW1lbnQgaGF2aW5nIHJlY2VpdmVkIHRo ZTxicj4NCiZndDsgcHVibGljYXRpb24gcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgbXkgcmV2aWV3 IGlzIHRvIGltcHJvdmUgdGhlPGJyPg0KJmd0OyBxdWFsaXR5IG9mIHRoZSBkb2N1bWVudCBhbmQg dG8gY2F0Y2ggYW55IGlzc3VlcyB0aGF0IG1pZ2h0IG90aGVyd2lzZTxicj4NCiZndDsgc2hvdyB1 cCBkdXJpbmcgSUVURiBsYXN0IGNhbGwsIERpcmVjdG9yYXRlIHJldmlld3MsIG9yIElFU0cgZXZh bHVhdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBpcyBhIHByZXR0eSBnb29kIGRvY3Vt ZW50LiBUaGFua3MgZm9yIHRoZSBlZmZvcnQgeW91IGhhdmUgcHV0IGluLDxicj4NCiZndDsgYW5k IHRoYW5rcyB0byBNYXR0IGZvciB3b3JraW5nIG9uIHRoZSBFbmdsaXNoLiBIZSBkZXNlcnZlcyBh bjxicj4NCiZndDsgYWNrbm93bGVkZ2VtZW50IHNvbWV3aGVyZSBpbiB0aGUgZG9jdW1lbnQuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEkgaGF2ZSBvbmx5IGEgZmV3IGlzc3VlcywgYW5kIHRoZXkgZG9u J3QgbWVyaXQgYSBuZXcgcmV2aXNpb24gbm93Ljxicj4NCiZndDsgU28gSSB3aWxsIHN0YXJ0IHRo ZSBJRVRGIGxhc3QgY2FsbCBhbmQgcmFpc2UgdGhlc2UgcG9pbnRzIHRvIGJlIDxicj4NCiZndDsg YWRkcmVzc2VkIGF0IHRoYXQgdGltZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4N CiZndDsgQWRyaWFuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLTxicj4NCiZndDsgPGJyPg0KJmd0 OyBDb3VsZCB5b3UgZXhwYW5kICZxdW90O3AycCZxdW90OyB3aGVyZSBpdCBpcyBmaXJzdCB1c2Vk Pzxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHZlcnkg Zmlyc3Qgc2VudGVuY2UgaXMgaGFyZCB0byBwYXJzZTxicj4NCiZndDsgPGJyPg0KJmd0OyBNUExT IHRyYW5zcG9ydCBuZXR3b3JrcyBjYW4gYmUgY2hhcmFjdGVyaXplZCBhcyBiZWluZyBhIG5ldHdv cmsgb2Y8YnI+DQomZ3Q7IGNvbm5lY3Rpb25zIGJldHdlZW4gbm9kZXMgd2l0aGluIGEgbWVzaCBv ZiBub2RlcyBhbmQgdGhlIGxpbmtzPGJyPg0KJmd0OyBiZXR3ZWVuIHRoZW0uIDxicj4NCiZndDsg PGJyPg0KJmd0OyBNYXliZSB0cnk8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIE1QTFMgVHJhbnNw b3J0IFByb2ZpbGUgKE1QTFMtVFApIHByb3ZpZGVzIHRvb2xzIHRvIGNvbnN0cnVjdCBhbmQ8YnI+ DQomZ3Q7IG9wZXJhdGUgYSBzZXQgb2YgY29ubmVjdGlvbnMgYmV0d2VlbiBub2RlcyBpbiBhbiBN UExTIG5ldHdvcmsuIFRoZTxicj4NCiZndDsgTVBMUyBuZXR3b3JrIGlzIGEgbWVzaCBjb21wcmlz aW5nIG5vZGVzIGFuZCB0aGUgbGlua3MgYmV0d2VlbiB0aGVtLjxicj4NCiZndDsgPGJyPg0KJmd0 OyAtLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB1bmRlcnN0YW5kIHRoYXQgeW91IHdhbnQgdG8g dXNlIFJGQyAyMTE5IGxhbmd1YWdlIHRvIGNsYXJpZnkgdGhlIDxicj4NCiZndDsgcmVxdWlyZW1l bnRzLCBidXQgUkZDIDIxMTkgd2FzIGRldmVsb3BlZCBmb3Igc3BlY2lmeWluZyBwcm90b2NvbHMs IHNvIDxicj4NCiZndDsgdGhlIGRpcmVjdCByZWZlcmVuY2UgYW5kIGJvaWxlcnBsYXRlIHF1b3Rl IGlzIGluY29uZ3J1b3VzLiBJIHN1Z2dlc3Q8YnI+DQomZ3Q7IHlvdSB1c2UgdGhlIGxhbmd1YWdl IGFzIGZvdW5kIGluIFJGQyA1NjU0LCB2aXouOjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUga2V5 IHdvcmRzICZxdW90O01VU1QmcXVvdDssICZxdW90O01VU1QgTk9UJnF1b3Q7LCAmcXVvdDtSRVFV SVJFRCZxdW90OywgJnF1b3Q7U0hBTEwmcXVvdDssICZxdW90O1NIQUxMIE5PVCZxdW90Oyw8YnI+ DQomZ3Q7ICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxEIE5PVCZxdW90OywgJnF1b3Q7 UkVDT01NRU5ERUQmcXVvdDssICZxdW90O01BWSZxdW90OywgYW5kICZxdW90O09QVElPTkFMJnF1 b3Q7IGluIHRoaXM8YnI+DQomZ3Q7IGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBk ZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLjxicj4NCiZndDsgQWx0aG91Z2ggdGhpcyBk b2N1bWVudCBpcyBub3QgYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLCB0aGUgdXNlIG9mPGJyPg0K Jmd0OyB0aGlzIGxhbmd1YWdlIGNsYXJpZmllcyB0aGUgaW5zdHJ1Y3Rpb25zIHRvIHByb3RvY29s IGRlc2lnbmVyczxicj4NCiZndDsgcHJvZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhl IHJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXM8YnI+DQomZ3Q7IGRvY3VtZW50Ljxicj4NCiZn dDsgPGJyPg0KJmd0OyAtLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gU2VjdGlvbiA1LjEgeW91 IGhhdmU8YnI+DQomZ3Q7IDxicj4NCiZndDsgdGhlIGNvbnRyb2w8YnI+DQomZ3Q7IHByb3RvY29s IFNIT1VMRCBOT1QgYmUgdXNlZCBhcyB0aGUgcHJpbWFyeSByZXNpbGllbmNlIG1lY2hhbmlzbS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhZ3JlZSwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgdGVybSAm cXVvdDtwcmltYXJ5IHJlc2lsaWVuY2UgbWVjaGFuaXNtJnF1b3Q7IG1heSBiZTxicj4NCiZndDsg dW5kZXIgZGVmaW5lZC4gQ2FuIHlvdSBkbyBhbnl0aGluZyB0byBjbGFyaWZ5IHRoaXM/IE1heWJl Li4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHRoZSBjb250cm9sPGJyPg0KJmd0OyBwcm90b2NvbCBT SE9VTEQgTk9UIGJlIHVzZWQgYXMgdGhlIHByaW1hcnkgbWVjaGFuaXNtIGZvciBkZXRlY3Rpbmcg b3I8YnI+DQomZ3Q7IHJlcG9ydGluZyBuZXR3b3JrIGZhaWx1cmVzLCBvciBmb3IgaW5pdGlhdGlu ZyBvciBjb29yZGluYXRpbmcgPGJyPg0KJmd0OyBwcm90ZWN0aW9uIHN3aXRjaC1vdmVyLiBUaGF0 IGlzLCBpdCBTSE9VTEQgTk9UIGJlIHVzZWQgYXMgdGhlIDxicj4NCiZndDsgcHJpbWFyeSByZXNp bGllbmNlIG1lY2hhbmlzbS48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0Bp ZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A287436ECSMTP2etriinfo_-- From nobody Sun Jun 8 18:56:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0484B1B279D for ; Sun, 8 Jun 2014 18:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.75 X-Spam-Level: *** X-Spam-Status: No, score=3.75 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, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, 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 Z0DYsNXTTgem for ; Sun, 8 Jun 2014 18:55:59 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176CD1B278D for ; Sun, 8 Jun 2014 18:55:59 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id r10so4245020pdi.5 for ; Sun, 08 Jun 2014 18:55:58 -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=N++RIYMXtYp0xOdLCXQ6Gat9VmtB2ACIHfe7dkKi0RI=; b=Q3hJHbTa/qS6f46X4WY2J85rV9tKF/KfWSvCSifQUPxGyTm0I148/P1SeENCGJaq4t zznKbGtpylVC7FVzMoxYtVf2Vpv3jaTNp8dxS4uMNaZUvtTN2O9NIdGnU2JIrSdNJG1z aXolD23t/MewcAEAQ6oPdFP0eHFEdbQ/v3sGaW/rJiWy3lfjDWJIFqzs2QGOHNfe7wUR nd1NTUanOhE8Sib/UG4bz3hX8ungNGpIZ7eew/+P0Gjfr8LsJwn2BuRFVTZzpRkbQpXy RYbCil/z4jOMLy0r18R24J8pvI8A4VvoLClpzqa1aFQ4soKmqFx0z0nvCDjdL/ZRiTkS eNCA== X-Received: by 10.66.65.204 with SMTP id z12mr1328074pas.60.1402278958744; Sun, 08 Jun 2014 18:55:58 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id gu1sm60996677pbd.0.2014.06.08.18.55.54 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 08 Jun 2014 18:55:58 -0700 (PDT) From: "Lizhong Jin" To: "'Nobo Akiya \(nobo\)'" , "'Loa Andersson'" , References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> <00ac01cf82fb$3ad42ea0$b07c8be0$@gmail.com> In-Reply-To: Date: Mon, 9 Jun 2014 09:55:51 +0800 Message-ID: <000a01cf8385$f4662e60$dd328b20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFkNImub9tQ9oQH/0/dAlGlBbKZQHTWwX1AWjQmcsDHYWSQgJAVPnCm7cVnFA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/77zD-Eedg9X4ZZeBs4mPLxb63Ns Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: Re: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 09 Jun 2014 01:56:02 -0000 Hi Nobo, Thanks for the quick reply. See inline below. Regards Lizhong > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: 2014=C4=EA6=D4=C28=C8=D5 22:05 > To: Lizhong Jin; 'Loa Andersson'; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-lsp- > ping-relay-reply@tools.ietf.org > Subject: RE: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls- > lsp-ping-relay-reply >=20 > Hi Lizhong, >=20 > Thanks for considering my comments. >=20 > Please see-inline. >=20 > > -----Original Message----- > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > > Sent: Sunday, June 08, 2014 5:23 AM > > To: Nobo Akiya (nobo); 'Loa Andersson'; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; > > draft-ietf-mpls-lsp- ping-relay-reply@tools.ietf.org > > Subject: RE: [mpls] Still Open - Re: Working group last call on > > draft-ietf- mpls-lsp-ping-relay-reply > > > > Hi Nobo, > > Thank you for the detail review. See inline below. > > > > Regards > > Lizhong > > > > > -----Original Message----- > > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > > Sent: 2014=C4=EA6=D4=C27=C8=D5 5:15 > > > To: Loa Andersson; mpls@ietf.org > > > Cc: ; mpls-chairs@tools.ietf.org; > > draft-ietf-mpls- > > > lsp-ping-relay-reply@tools.ietf.org > > > Subject: RE: [mpls] Still Open - Re: Working group last call on > > draft-ietf-mpls- > > > lsp-ping-relay-reply > > > > > > Hi Loa, Authors, > > > > > > I have some comments and questions (and my apologies if questions > > > have already been answered before). > > > > > > > > > Section 3.2: > > > > > > The K bit may be set by ASBRs whose address would be > > > kept in the stack if necessary. > > > > > > This is the only statement that I found regarding how responder is > > > to > > decide > > > the setting of the K bit. I read it as "Set K bit if I'm likely to > > > be a > > relay point". I > > > understand the motive behind this bit, but realistically it seems = a > > > bit > > difficult > > > to use, i.e. unless responder has some topology awareness, it's = just > > simpler > > > to just to set the K bit. Can you provide more thoughts on exactly > > > how you intended to use this bit? > > [Lizhong] In a network with multiple ASs, and only ASBRs or border > > nodes are the potential relay nodes. This maybe the most common = case. > > The original thought is to let all ASBRs to be relay node, and the > > initiator could discover the ASBR list. So it is suggested to let = ASBR > > (or border node) to set K bit as a node wide configuration. But we = did not > restrict other nodes to set > > K bit. >=20 > There's a slight conflict then. If the intention of the K bit is to = let the initiator > discover ASBRs, then we should have a text that says ASBRs SHOULD set = the > K bit and non-ASBRs MUST NOT set the K bit. Otherwise non-ASBRs = setting > the K bit can give wrong information to the initiator. However, if the > intention has become more loose (i.e. any node who wants to remain in = the > TLV as the relay node), then perhaps a short text would be helpful. > Something like: >=20 > Having the K bit set on the relay node address entry causes that > entry to be preserved in the Relay Node Address Stack TLV for the > entire traceroute operation. A responder node MAY set the K bit to > ensure its relay node address entry remains as one of the relay = nodes > in the Relay Node Address Stack TLV. Some nodes (ex: ASBR) could = be > configured to always set the K bit, or the module handling MPLS = echo > requests could discover its K bit use through topology awareness. > How a node determines to set the K bit is outside the scope of this > document. [Lizhong] accepted. Thanks. >=20 > > > > > > > > On a related note, I did not find any texts around usage of K bit > > > and Unspecified Address Type, which probably should be considered > invalid. > > > If you agree, it would be good to add texts to enforce this. > > [Lizhong] The usage and protocol operation of K bit and Unspecified > > Address Type is described in section 4.2. I did not quite get this > > comment, could you give more detail. >=20 > What I meant was, do we ever want a relay node address entry that has = K bit > set _and_ is Unspecified Address Type? It seems that will just waste = space in > the Relay Node Address Stack TLV (and on the wire). I was just asking = if > there's any reason why K bit & Unspecified combination is not = restricted. [Lizhong] got it. You are right, the entry with Unspecified Address Type SHOULD NOT set K bit. Will add this to the text. >=20 > > > > > > > > > > > Section 4.2: > > > > > > , and > > > the address entry of the replying LSR MUST be added at the = bottom of > > > the stack. > > > > > > The loop prevention paragraph in section 4.4 has a strict check = that > > received > > > source IP address must be found in the address stack of the Relay > > > Node Address Stack TLV. In that case, above statement in section = 4.2 > > > should be tightened that source IP address of transmitted packet > > > must be used as the "address entry of the replying LSR". Otherwise > > > valid reply may be dropped > > by > > > a relay node. > > [Lizhong] accepted. Should be tightened that the address added in > > Relay Node Address Stack TLV MUST be the source IP address of Relay > > Echo Reply or Echo Reply message. >=20 > Thanks. >=20 > > > > > > > > > > > Section 4.2: > > > > > > If the replying LSR is configured to hide its routable address > > > information, the address entry added in the stack SHOULD be a = blank > > > entry with Address Type set to unspecified. The blank address entry > > > in the receiving Echo Request SHOULD be treated as an = unroutable > > > address entry. > > > > > > What's the point of adding a blank entry (i.e. Unspecified Address Type)? > > I > > > suppose the purpose of this is to let the initiator know the > > > responder is intentionally hiding it's local address, but is that > > > really necessary? If > > so, what's > > > the point of initiator preserving this blank entry in the Relay = Node > > Address > > > Stack TLV in the next Echo Request, just to be deleted by the next > > responder > > > node? > > [Lizhong] not only deleted by the next responder, if the replying = LSR > > is a relayed node, and reply with unspecified address, then the > > unspecified address will not be deleted by the compress process. As = a > > result, the relayed echo reply will not be successfully sent back to > > initiator. Security concern is the main motivation of setting > > Unspecified Address Type, since Ping with Relayed Echo Rely could > > trace every node across domains. If trace is only used for trouble > > shooting, in many cases, these hiding LSR will not influence success = of the > trouble shooting if they are not relayed node. >=20 > Ok, based on your answers above and below, blank entry makes sense. > Although I don't see the point of allowing a blank entry have a K bit = set. [Lizhong] right, and as the previous comment, will add the restriction = in the text. Thanks. >=20 > > > > > > > > > > > Section 4.4: > > > > > > I didn't see any texts describing what the source IP address of = the > > > packet sent by receiver of Relayed Echo Reply. I'm guessing that = we > > > cannot copy received source IP address as the source IP address of > > > transmitting Echo Reply or further Relayed Echo Reply, since that > > > will break the loop > > prevention > > > proposed in Section 4.4. However, if we are not preserving the > > > source IP address from the original responder node, then there's = an > > > impact to traceroute implementations as they usually print out > > > received source IP addresses (which no longer will be responder > addresses). > > > > > > Initiator could do: > > > > > > If (Relay Node Address Stack TLV) { > > > Print last address in the stack > > > } else { > > > Print source IP address > > > } > > > > > > But if the last address in the stack was Unspecified, then > > > traceroute > > result > > > now can become weaker than it used to be. > > > > > > Alternatively you could do: > > > > > > (1) Preserve the source IP address in received Relayed Echo Reply = to > > > transmitting Echo Reply or Relay Echo Reply. > > > (2) Add one more condition in the loop prevention check. If the > > > first > > routable > > > address in the Relay Node Address Stack TLV is self, then drop. > > > > > > Not sure if RPF check would be a concerning point, but if not, = above > > should > > > work and traceroute will remain the same as today. And if you go = via > > > this, then source IP address will always be what would have been > > > placed in the Relay Node Address Stack TLV by the responder. In = that > > > case, the purpose > > of > > > Unspecified Address Type becomes questionable. > > [Lizhong] The initiator should print last address in the stack, we > > should add this in the text. It could say weaker than legacy > > traceroute from address displaying point of view. But traceroute is > > now working in a multi-domain case. Hiding address should be allowed > > if desired, under the condition that trouble shooting could still be > > possible. Then we could say the new traceroute is stronger than = legacy > from trouble shooting point of view. >=20 > Ok in that case, please add texts for: > - Source IP address in Echo Reply and Relay Echo Reply are to be of = the > address of the node sending those packets (i.e. not copied from = received > Relay Echo Reply). > - Traceroute address output module will need to conditionally print = the > address in the Relay Node Address Stack TLV. [Lizhong] accepted, thanks. >=20 > > > > > > > > > > > General: > > > > > > The document does not say that Proxy Ping is outside the scope, > > > however I think a bit of additions are needed to make this work = with > > > Proxy Ping. For example, first address in the Relay Node Address > > > Stack TLV should be Proxy sender, and Proxy receiver (i.e. Echo > > > Request > > > sender) will need to follow > > the > > > Relay Node Address Stack TLV update procedure just like receiver = of > > > Echo Request. > > [Lizhong] right, but it seems draft-relay-reply moves faster than > > draft-proxy- lsp-ping. It would be more reasonable to add the > > suggested text to draft- proxy-lsp-ping, right? I could talk this = with > > author of draft-proxy-lsp-ping and chair. Thanks. >=20 > Ah right, I forgot that Proxy has not become RFC yet. Yes I think = that'll be a > good idea to make sure to raise this point to Proxy authors and chairs = so that > it gets on some "todo list". [Lizhong] good. >=20 > > > > > > > > > > > General: > > > > > > Any reason why TTL is not copied from received Relay Echo Reply to > > > transmitting Echo Reply or Relay Echo Reply? > > [Lizhong] this is a missing part, and should be added. I think copy = is > > the right behavior. Thanks. >=20 > Agree. >=20 > Thanks! >=20 > -Nobo >=20 > > > > Regards > > Lizhong > > > > > > > > > > > Thanks! > > > > > > -Nobo > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > > > > Andersson > > > > Sent: Thursday, June 05, 2014 1:21 AM > > > > To: mpls@ietf.org > > > > Cc: ; mpls-chairs@tools.ietf.org; > > > > draft-ietf-mpls- lsp-ping-relay-reply@tools.ietf.org > > > > Subject: [mpls] Still Open - Re: Working group last call on > > > > draft-ietf-mpls- lsp-ping-relay-reply > > > > > > > > Working Group, > > > > > > > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last > > > > call that was intended to be closed last Monday (June 2nd). > > > > > > > > Hopwever, there has not be a single response! > > > > > > > > I cn't make up my mind how to interprete this - either the wg = have > > > > lost interest in the draft (which would surprise me greatly) or > > > > everybody thinks the draft is perfect (which would also be a surprise). > > > > > > > > I will therefore extend the wglc until June 16 and invite also > > > > positive responses (e.g. "I think this document is ready for > > publication!"). > > > > > > > > /Loa > > > > for the wg chairs > > > > > > > > On 2014-05-19 11:49, Loa Andersson wrote: > > > > > Working Group, > > > > > > > > > > This is to initiate a working group last call on > > > > > draft-ietf-mpls-lsp-ping-relay-reply. > > > > > > > > > > There are two IPR disclosures against this document. The = author > > > > > has stated that he is unaware of any other IPRs that relate to > > > > > this document. > > > > > > > > > > Please send your comments to the mpls wg mailing list > (mpls@ietf.org). > > > > > > > > > > This working group last call ends June 2, 2014. > > > > > > > > > > /Loa > > > > > for the MPLS wg chairs > > > > > > > > -- > > > > > > > > > > > > Loa Andersson email: = loa@mail01.huawei.com > > > > Senior MPLS Expert loa@pi.nu > > > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Jun 8 20:24:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253FF1B27CB for ; Sun, 8 Jun 2014 20:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n4ItrQ7eM0g for ; Sun, 8 Jun 2014 20:24:46 -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 523361B27CC for ; Sun, 8 Jun 2014 20:24:46 -0700 (PDT) Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A83C518013DA; Mon, 9 Jun 2014 05:24:42 +0200 (CEST) Message-ID: <539528F5.1040906@pi.nu> Date: Mon, 09 Jun 2014 05:24:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BlgH2UoNOwNO8_91cz-ZfPdDzoI Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" Subject: [mpls] Working group last call on draft-ietf-mpls-seamless-mcast 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, 09 Jun 2014 03:24:48 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-seamless-mcast. There are one IPR disclosure against this document. The authors has stated that he is unaware of any other IPRs that relate to this document. Please send your comments to the mpls wg mailing list (mpls@ietf.org). This working group last call ends June 23, 2014. /Loa for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jun 9 07:10:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C3C1A017C; Mon, 9 Jun 2014 07:10: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 64ITIPAF333H; Mon, 9 Jun 2014 07:10:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 239021A0189; Mon, 9 Jun 2014 07:10:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140609141011.5039.22479.idtracker@ietfa.amsl.com> Date: Mon, 09 Jun 2014 07:10:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JMnDb7Zu_psFOn0pFfsaHUIxEW8 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:10:19 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Requirements for MPLS-TP Shared Mesh Protection' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jun 9 07:26:47 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817431A01BC; Mon, 9 Jun 2014 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nmqyh1Emy8Bt; Mon, 9 Jun 2014 07:26: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 6A4AA1A017C; Mon, 9 Jun 2014 07:26:41 -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 s59EQdlD000906; Mon, 9 Jun 2014 15:26: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 s59EQbnr000853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jun 2014 15:26:38 +0100 From: "Adrian Farrel" To: Date: Mon, 9 Jun 2014 15:26:37 +0100 Message-ID: <05fd01cf83ee$d36d6250$7a4826f0$@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: Ac+D7tDjzCAoIa+JQDCWHFBixkgLOg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20748.000 X-TM-AS-Result: No--18.236-10.0-31-10 X-imss-scan-details: No--18.236-10.0-31-10 X-TMASE-MatchedRID: vEvJ7Rh1lGgzx9GDMr0HvzYTypjB3iDVuikHZcC6ceDgq9d1J0a/O0xO 7+3QV5trddLzNY2Nt2JQfV8BOtYTtqNmd7pYp+mtR+GtoiXVeDHomXBvaBu6TpMxNpDOG+h6Cf2 h9A2gFAWPScoCueHJCsSIUbXCYKjGS2my/ooOam/r/EBmiNuXt4GzTdEevOMzEB/Asc4oaYFeSF +P1eXHLQVjXBUVPPkIAGvNFj/ALTkhWGQFjj8epM+ayFtEW0uYhSl7KAXaa8LfUZT83lbkEN/rc nYNDHdsDAy9+p2eZkapekVEr8FUaNcUNjoF7YuVr04R126Gsieau7dML+YtTrV5fSMRD1zqMC/K /e26+Q3s35lYsesx4+x6Uxdi4ACrDCWUT3P4Uqe8coKUcaOOvX0tCKdnhB58vqq8s2MNhPB9j2G wzTE3vSq2rl3dzGQ1A/3R8k/14e0= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VUhMm5Q57QEX0bxlNVbErymPEK0 Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC 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: Mon, 09 Jun 2014 14:26:43 -0000 Here are some comments from my review as AD that need to get handled as part of IETF last call. Thanks, Adrian === Could you expand "p2p" where it is first used? --- The very first sentence is hard to parse MPLS transport networks can be characterized as being a network of connections between nodes within a mesh of nodes and the links between them. Maybe try The MPLS Transport Profile (MPLS-TP) provides tools to construct and operate a set of connections between nodes in an MPLS network. The MPLS network is a mesh comprising nodes and the links between them. --- I understand that you want to use RFC 2119 language to clarify the requirements, but RFC 2119 was developed for specifying protocols, so the direct reference and boilerplate quote is incongruous. I suggest you use the language as found in RFC 5654, viz.: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document. --- In Section 5.1 you have the control protocol SHOULD NOT be used as the primary resilience mechanism. I agree, but I think that the term "primary resilience mechanism" may be under defined. Can you do anything to clarify this? Maybe... the control protocol SHOULD NOT be used as the primary mechanism for detecting or reporting network failures, or for initiating or coordinating protection switch-over. That is, it SHOULD NOT be used as the primary resilience mechanism. > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of The IESG > Sent: 09 June 2014 15:10 > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: > (Requirements for MPLS-TP Shared Mesh Protection) to Informational RFC > > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'Requirements for MPLS-TP Shared Mesh Protection' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-06-23. From nobody Mon Jun 9 17:31:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C521A0286; Mon, 9 Jun 2014 17:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDTQnI6wa1zM; Mon, 9 Jun 2014 17:30:52 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884F91A0274; Mon, 9 Jun 2014 17:30:51 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jun 2014 09:30:44 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Tue, 10 Jun 2014 09:30:45 +0900 From: Jeong Ryoo To: "adrian@olddog.co.uk" , "ietf@ietf.org" Thread-Topic: Last Call: (Requirements for MPLS-TP Shared Mesh Protection) Thread-Index: AQHPhEM3NGkTlg/PBk6h7c52YXMigA== Date: Tue, 10 Jun 2014 00:30:44 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2874391A@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2874391ASMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ju2tLofqwBhAr8f9aoGQvCitfhc Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (Requirements for MPLS-TP Shared Mesh 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, 10 Jun 2014 00:30:58 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2874391ASMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRpcmFuLCB0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQoNClRoZXkgY2VydGFpbmx5IGlt cHJvdmUgdGhlIGRvY3VtZW50LCBhbmQgd2lsbCBiZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIG5leHQg dmVyc2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQrrs7Trgrgg7IKs656MIDogIkFkcmlhbiBGYXJyZWwi IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0K67O064K4IOuCoOynnCA6IDIwMTQtMDYtMDkgMjM6Mjc6 MDggKCArMDk6MDAgKQ0K67Cb64qUIOyCrOuejCA6IGlldGZAaWV0Zi5vcmcgPGlldGZAaWV0Zi5v cmc+DQrssLjsobAgOiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0K7KCc66qpIDogUkU6 IExhc3QgQ2FsbDogKFJlcXVpcmVtZW50cyBmb3IgTVBMUy1UUCBTaGFyZWQgTWVzaCBQcm90ZWN0 aW9uKSB0byBJbmZvcm1hdGlvbmFsIFJGQw0KDQoNCkhlcmUgYXJlIHNvbWUgY29tbWVudHMgZnJv bSBteSByZXZpZXcgYXMgQUQgdGhhdCBuZWVkIHRvIGdldCBoYW5kbGVkIGFzIHBhcnQgb2YNCklF VEYgbGFzdCBjYWxsLg0KDQpUaGFua3MsDQpBZHJpYW4NCg0KPT09DQoNCkNvdWxkIHlvdSBleHBh bmQgInAycCIgd2hlcmUgaXQgaXMgZmlyc3QgdXNlZD8NCg0KLS0tDQoNClRoZSB2ZXJ5IGZpcnN0 IHNlbnRlbmNlIGlzIGhhcmQgdG8gcGFyc2UNCg0KTVBMUyB0cmFuc3BvcnQgbmV0d29ya3MgY2Fu IGJlIGNoYXJhY3Rlcml6ZWQgYXMgYmVpbmcgYSBuZXR3b3JrIG9mDQpjb25uZWN0aW9ucyBiZXR3 ZWVuIG5vZGVzIHdpdGhpbiBhIG1lc2ggb2Ygbm9kZXMgYW5kIHRoZSBsaW5rcw0KYmV0d2VlbiB0 aGVtLg0KDQpNYXliZSB0cnkNCg0KVGhlIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFAp IHByb3ZpZGVzIHRvb2xzIHRvIGNvbnN0cnVjdCBhbmQNCm9wZXJhdGUgYSBzZXQgb2YgY29ubmVj dGlvbnMgYmV0d2VlbiBub2RlcyBpbiBhbiBNUExTIG5ldHdvcmsuIFRoZQ0KTVBMUyBuZXR3b3Jr IGlzIGEgbWVzaCBjb21wcmlzaW5nIG5vZGVzIGFuZCB0aGUgbGlua3MgYmV0d2VlbiB0aGVtLg0K DQotLS0NCg0KSSB1bmRlcnN0YW5kIHRoYXQgeW91IHdhbnQgdG8gdXNlIFJGQyAyMTE5IGxhbmd1 YWdlIHRvIGNsYXJpZnkgdGhlDQpyZXF1aXJlbWVudHMsIGJ1dCBSRkMgMjExOSB3YXMgZGV2ZWxv cGVkIGZvciBzcGVjaWZ5aW5nIHByb3RvY29scywgc28NCnRoZSBkaXJlY3QgcmVmZXJlbmNlIGFu ZCBib2lsZXJwbGF0ZSBxdW90ZSBpcyBpbmNvbmdydW91cy4gSSBzdWdnZXN0DQp5b3UgdXNlIHRo ZSBsYW5ndWFnZSBhcyBmb3VuZCBpbiBSRkMgNTY1NCwgdml6LjoNCg0KVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMNCmRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4g UkZDIDIxMTkgW1JGQzIxMTldLg0KQWx0aG91Z2ggdGhpcyBkb2N1bWVudCBpcyBub3QgYSBwcm90 b2NvbCBzcGVjaWZpY2F0aW9uLCB0aGUgdXNlIG9mDQp0aGlzIGxhbmd1YWdlIGNsYXJpZmllcyB0 aGUgaW5zdHJ1Y3Rpb25zIHRvIHByb3RvY29sIGRlc2lnbmVycw0KcHJvZHVjaW5nIHNvbHV0aW9u cyB0aGF0IHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMNCmRvY3VtZW50 Lg0KDQotLS0NCg0KSW4gU2VjdGlvbiA1LjEgeW91IGhhdmUNCg0KdGhlIGNvbnRyb2wNCnByb3Rv Y29sIFNIT1VMRCBOT1QgYmUgdXNlZCBhcyB0aGUgcHJpbWFyeSByZXNpbGllbmNlIG1lY2hhbmlz bS4NCg0KSSBhZ3JlZSwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgdGVybSAicHJpbWFyeSByZXNpbGll bmNlIG1lY2hhbmlzbSIgbWF5IGJlDQp1bmRlciBkZWZpbmVkLiBDYW4geW91IGRvIGFueXRoaW5n IHRvIGNsYXJpZnkgdGhpcz8gTWF5YmUuLi4NCg0KdGhlIGNvbnRyb2wNCnByb3RvY29sIFNIT1VM RCBOT1QgYmUgdXNlZCBhcyB0aGUgcHJpbWFyeSBtZWNoYW5pc20gZm9yIGRldGVjdGluZyBvcg0K cmVwb3J0aW5nIG5ldHdvcmsgZmFpbHVyZXMsIG9yIGZvciBpbml0aWF0aW5nIG9yIGNvb3JkaW5h dGluZw0KcHJvdGVjdGlvbiBzd2l0Y2gtb3Zlci4gVGhhdCBpcywgaXQgU0hPVUxEIE5PVCBiZSB1 c2VkIGFzIHRoZQ0KcHJpbWFyeSByZXNpbGllbmNlIG1lY2hhbmlzbS4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgVGhlIElFU0cNCj4gU2VudDogMDkgSnVuZSAyMDE0IDE1OjEwDQo+ IFRvOiBJRVRGLUFubm91bmNlDQo+IENjOiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFttcGxz XSBMYXN0IENhbGw6DQo+IChSZXF1aXJlbWVudHMgZm9yIE1QTFMtVFAgU2hhcmVkIE1lc2ggUHJv dGVjdGlvbikgdG8gSW5mb3JtYXRpb25hbCBSRkMNCj4NCj4gVGhlIElFU0cgaGFzIHJlY2VpdmVk IGEgcmVxdWVzdCBmcm9tIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBXRw0KPiAo bXBscykgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCj4gLSAnUmVxdWlyZW1l bnRzIGZvciBNUExTLVRQIFNoYXJlZCBNZXNoIFByb3RlY3Rpb24nDQo+IGFzIEluZm9ybWF0aW9u YWwgUkZDDQo+DQo+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4 dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KPiBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlv bi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQo+IGlldGZAaWV0Zi5v cmcgbWFpbGluZyBsaXN0cyBieSAyMDE0LTA2LTIzLg0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2874391ASMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIw cHQiPkFkaXJhbiwgdGhhbmsgeW91IGZvciB5b3VyJm5ic3A7Y29tbWVudHMuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMjBwdCI+VGhleSBjZXJ0YWlubHkgaW1wcm92ZSB0aGUmbmJzcDtkb2N1bWVudCwg YW5kIHdpbGwgYmUgaW5jb3Jwb3JhdGVkIGluIHRoZSBuZXh0IHZlcnNpb24uPC9kaXY+DQo8ZGl2 IHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMjBwdCI+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDIwcHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPkpl b25nLWRvbmc8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij48YnI+DQo8YnI+ DQombmJzcDs8L2Rpdj4NCjxkaXYgaWQ9Ik1haWxTaWduU2VudCIgc3R5bGU9IkxJTkUtSEVJR0hU OiAyMHB0Ij48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9Ik9SR01BSUxfQ09OVEVOVCIgc3R5bGU9IkxJ TkUtSEVJR0hUOiAyMHB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPGI+67O064K4IOyCrOuejCA6 IDwvYj4mcXVvdDtBZHJpYW4gRmFycmVsJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0 Ozxicj4NCjxiPuuztOuCuCDrgqDsp5wgOiA8L2I+MjAxNC0wNi0wOSAyMzoyNzowOCAoICYjNDM7 MDk6MDAgKTxicj4NCjxiPuuwm+uKlCDsgqzrnowgOiA8L2I+aWV0ZkBpZXRmLm9yZyAmbHQ7aWV0 ZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj7ssLjsobAgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBs c0BpZXRmLm9yZyZndDs8YnI+DQo8Yj7soJzrqqkgOiA8L2I+UkU6IExhc3QgQ2FsbDogPERSQUZU LUlFVEYtTVBMUy1TTVAtUkVRVUlSRU1FTlRTLTA1LlRYVD4oUmVxdWlyZW1lbnRzIGZvciBNUExT LVRQIFNoYXJlZCBNZXNoIFByb3RlY3Rpb24pIHRvIEluZm9ybWF0aW9uYWwgUkZDPGJyPg0KPGJy Pg0KPGJyPg0KSGVyZSBhcmUgc29tZSBjb21tZW50cyBmcm9tIG15IHJldmlldyBhcyBBRCB0aGF0 IG5lZWQgdG8gZ2V0IGhhbmRsZWQgYXMgcGFydCBvZjxicj4NCklFVEYgbGFzdCBjYWxsLjxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpBZHJpYW48YnI+DQo8YnI+DQo9PT08YnI+DQo8YnI+DQpDb3Vs ZCB5b3UgZXhwYW5kICZxdW90O3AycCZxdW90OyB3aGVyZSBpdCBpcyBmaXJzdCB1c2VkPzxicj4N Cjxicj4NCi0tLTxicj4NCjxicj4NClRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlIGlzIGhhcmQgdG8g cGFyc2U8YnI+DQo8YnI+DQpNUExTIHRyYW5zcG9ydCBuZXR3b3JrcyBjYW4gYmUgY2hhcmFjdGVy aXplZCBhcyBiZWluZyBhIG5ldHdvcmsgb2Y8YnI+DQpjb25uZWN0aW9ucyBiZXR3ZWVuIG5vZGVz IHdpdGhpbiBhIG1lc2ggb2Ygbm9kZXMgYW5kIHRoZSBsaW5rczxicj4NCmJldHdlZW4gdGhlbS4g PGJyPg0KPGJyPg0KTWF5YmUgdHJ5PGJyPg0KPGJyPg0KVGhlIE1QTFMgVHJhbnNwb3J0IFByb2Zp bGUgKE1QTFMtVFApIHByb3ZpZGVzIHRvb2xzIHRvIGNvbnN0cnVjdCBhbmQ8YnI+DQpvcGVyYXRl IGEgc2V0IG9mIGNvbm5lY3Rpb25zIGJldHdlZW4gbm9kZXMgaW4gYW4gTVBMUyBuZXR3b3JrLiBU aGU8YnI+DQpNUExTIG5ldHdvcmsgaXMgYSBtZXNoIGNvbXByaXNpbmcgbm9kZXMgYW5kIHRoZSBs aW5rcyBiZXR3ZWVuIHRoZW0uPGJyPg0KPGJyPg0KLS0tPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5k IHRoYXQgeW91IHdhbnQgdG8gdXNlIFJGQyAyMTE5IGxhbmd1YWdlIHRvIGNsYXJpZnkgdGhlIDxi cj4NCnJlcXVpcmVtZW50cywgYnV0IFJGQyAyMTE5IHdhcyBkZXZlbG9wZWQgZm9yIHNwZWNpZnlp bmcgcHJvdG9jb2xzLCBzbyA8YnI+DQp0aGUgZGlyZWN0IHJlZmVyZW5jZSBhbmQgYm9pbGVycGxh dGUgcXVvdGUgaXMgaW5jb25ncnVvdXMuIEkgc3VnZ2VzdDxicj4NCnlvdSB1c2UgdGhlIGxhbmd1 YWdlIGFzIGZvdW5kIGluIFJGQyA1NjU0LCB2aXouOjxicj4NCjxicj4NClRoZSBrZXkgd29yZHMg JnF1b3Q7TVVTVCZxdW90OywgJnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1 b3Q7LCAmcXVvdDtTSEFMTCZxdW90OywgJnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LDxicj4NCiZxdW90 O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxEIE5PVCZxdW90OywgJnF1b3Q7UkVDT01NRU5ERUQm cXVvdDssICZxdW90O01BWSZxdW90OywgYW5kICZxdW90O09QVElPTkFMJnF1b3Q7IGluIHRoaXM8 YnI+DQpkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAy MTE5IFtSRkMyMTE5XS48YnI+DQpBbHRob3VnaCB0aGlzIGRvY3VtZW50IGlzIG5vdCBhIHByb3Rv Y29sIHNwZWNpZmljYXRpb24sIHRoZSB1c2Ugb2Y8YnI+DQp0aGlzIGxhbmd1YWdlIGNsYXJpZmll cyB0aGUgaW5zdHJ1Y3Rpb25zIHRvIHByb3RvY29sIGRlc2lnbmVyczxicj4NCnByb2R1Y2luZyBz b2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzPGJy Pg0KZG9jdW1lbnQuPGJyPg0KPGJyPg0KLS0tPGJyPg0KPGJyPg0KSW4gU2VjdGlvbiA1LjEgeW91 IGhhdmU8YnI+DQo8YnI+DQp0aGUgY29udHJvbDxicj4NCnByb3RvY29sIFNIT1VMRCBOT1QgYmUg dXNlZCBhcyB0aGUgcHJpbWFyeSByZXNpbGllbmNlIG1lY2hhbmlzbS48YnI+DQo8YnI+DQpJIGFn cmVlLCBidXQgSSB0aGluayB0aGF0IHRoZSB0ZXJtICZxdW90O3ByaW1hcnkgcmVzaWxpZW5jZSBt ZWNoYW5pc20mcXVvdDsgbWF5IGJlPGJyPg0KdW5kZXIgZGVmaW5lZC4gQ2FuIHlvdSBkbyBhbnl0 aGluZyB0byBjbGFyaWZ5IHRoaXM/IE1heWJlLi4uPGJyPg0KPGJyPg0KdGhlIGNvbnRyb2w8YnI+ DQpwcm90b2NvbCBTSE9VTEQgTk9UIGJlIHVzZWQgYXMgdGhlIHByaW1hcnkgbWVjaGFuaXNtIGZv ciBkZXRlY3Rpbmcgb3I8YnI+DQpyZXBvcnRpbmcgbmV0d29yayBmYWlsdXJlcywgb3IgZm9yIGlu aXRpYXRpbmcgb3IgY29vcmRpbmF0aW5nIDxicj4NCnByb3RlY3Rpb24gc3dpdGNoLW92ZXIuIFRo YXQgaXMsIGl0IFNIT1VMRCBOT1QgYmUgdXNlZCBhcyB0aGUgPGJyPg0KcHJpbWFyeSByZXNpbGll bmNlIG1lY2hhbmlzbS48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgVGhlIElFU0c8YnI+DQomZ3Q7IFNlbnQ6IDA5IEp1bmUgMjAxNCAxNToxMDxicj4N CiZndDsgVG86IElFVEYtQW5ub3VuY2U8YnI+DQomZ3Q7IENjOiBtcGxzQGlldGYub3JnPGJyPg0K Jmd0OyBTdWJqZWN0OiBbbXBsc10gTGFzdCBDYWxsOiA8RFJBRlQtSUVURi1NUExTLVNNUC1SRVFV SVJFTUVOVFMtMDUuVFhUPjxicj4NCiZndDsgKFJlcXVpcmVtZW50cyBmb3IgTVBMUy1UUCBTaGFy ZWQgTWVzaCBQcm90ZWN0aW9uKSB0byBJbmZvcm1hdGlvbmFsIFJGQzxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIE11bHRpcHJvdG9j b2wgTGFiZWwgU3dpdGNoaW5nIFdHPGJyPg0KJmd0OyAobXBscykgdG8gY29uc2lkZXIgdGhlIGZv bGxvd2luZyBkb2N1bWVudDo8YnI+DQomZ3Q7IC0gJ1JlcXVpcmVtZW50cyBmb3IgTVBMUy1UUCBT aGFyZWQgTWVzaCBQcm90ZWN0aW9uJzxicj4NCiZndDsgPERSQUZULUlFVEYtTVBMUy1TTVAtUkVR VUlSRU1FTlRTLTA1LlRYVD5hcyBJbmZvcm1hdGlvbmFsIFJGQzxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtz LCBhbmQgc29saWNpdHM8YnI+DQomZ3Q7IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQ bGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGU8YnI+DQomZ3Q7IGlldGZAaWV0 Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDE0LTA2LTIzLjxicj4NCjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2874391ASMTP2etriinfo_-- From nobody Tue Jun 10 00:14:19 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC391A01EC; Tue, 10 Jun 2014 00:14:14 -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 OccSNV_BH61Q; Tue, 10 Jun 2014 00:14:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD38A1A0070; Tue, 10 Jun 2014 00:14:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610071412.6466.24044.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 00:14:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ES7r9s0tpXf_apkv73Hob6Ci6Qw Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-06.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, 10 Jun 2014 07:14:14 -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 : Requirements for MPLS-TP Shared Mesh Protection Authors : Yaacov Weingarten Sam Aldrin Ping Pan Jeong-dong Ryoo Greg Mirsky Filename : draft-ietf-mpls-smp-requirements-06.txt Pages : 14 Date : 2014-06-10 Abstract: This document presents the basic network objectives for the behavior of shared mesh protection (SMP) which are not based on control plane support. This is an expansion of the basic requirements presented in RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-smp-requirements-06 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 Jun 10 05:19:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F531A007F for ; Tue, 10 Jun 2014 05:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI32jh5uVMuy for ; Tue, 10 Jun 2014 05:19:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADB61A0032 for ; Tue, 10 Jun 2014 05:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15022; q=dns/txt; s=iport; t=1402402780; x=1403612380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yOpHemAuEmBFQTAdpqCqSzI6yH1qHww+pFVmiPkF7ME=; b=ZVeQlbS4i19jofrx7vWi41zpAKt8IVPm3M2tTPRtk1hYOzHB+9M5kjZZ h6wjYZCono2EuZwpbNDssoZUI+PO1xFnTAwp7ze6IKmfcgye+3XLj2UtA ivLIuUt1RvR+xbEWsVrw8OJlyRxFO9J04j5z/vCqwcDZ16Vt7Y2jywSKX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJL2llOtJV2P/2dsb2JhbABZgmkkUlmCbLlYhzwBgQwWdYQDAQEBBAEBAR4BSQMLDAICAgEIDgMEAQEBAQMGBRgCAwIbBgYLFAkIAgQBDQUIiCYDEQEMj2ycHwGZKQ2FRxMEBIEjiwCBQBEBHzEHBoJsOYEWBJgqj0aFeYF8gUCBdjk X-IronPort-AV: E=Sophos;i="4.98,1008,1392163200"; d="scan'208";a="331941170" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jun 2014 12:19:39 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5ACJdF7012733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 12:19:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 07:19:39 -0500 From: "Nobo Akiya (nobo)" To: Lizhong Jin , "'Loa Andersson'" , "mpls@ietf.org" Thread-Topic: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply Thread-Index: AQHPgH3yB3j9F0ZJHUKhGRn4Twxer5tkQO5AgAMIToD//+7m0IABJpWAgAHro6A= Date: Tue, 10 Jun 2014 12:19:38 +0000 Message-ID: References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> <00ac01cf82fb$3ad42ea0$b07c8be0$@gmail.com> <000a01cf8385$f4662e60$dd328b20$@gmail.com> In-Reply-To: <000a01cf8385$f4662e60$dd328b20$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.71] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/0YciKVgbPDbEGnv5kkLctUTIEVo Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: Re: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 10 Jun 2014 12:19:43 -0000 Hi Loa, Lizhong has agreed to address my comments, and I'm happy (i.e. yes/support)= for this document to progress once the new version is posted. Thanks! -Nobo > -----Original Message----- > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Sunday, June 08, 2014 9:56 PM > To: Nobo Akiya (nobo); 'Loa Andersson'; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-= lsp- > ping-relay-reply@tools.ietf.org > Subject: RE: [mpls] Still Open - Re: Working group last call on draft-iet= f- > mpls-lsp-ping-relay-reply >=20 > Hi Nobo, > Thanks for the quick reply. See inline below. >=20 > Regards > Lizhong >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: 2014=1B$BG/=1B(B6=1B$B7n=1B(B8=1B$BF|=1B(B 22:05 > > To: Lizhong Jin; 'Loa Andersson'; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; > draft-ietf-mpls-lsp- > > ping-relay-reply@tools.ietf.org > > Subject: RE: [mpls] Still Open - Re: Working group last call on > draft-ietf-mpls- > > lsp-ping-relay-reply > > > > Hi Lizhong, > > > > Thanks for considering my comments. > > > > Please see-inline. > > > > > -----Original Message----- > > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > > > Sent: Sunday, June 08, 2014 5:23 AM > > > To: Nobo Akiya (nobo); 'Loa Andersson'; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; > > > draft-ietf-mpls-lsp- ping-relay-reply@tools.ietf.org > > > Subject: RE: [mpls] Still Open - Re: Working group last call on > > > draft-ietf- mpls-lsp-ping-relay-reply > > > > > > Hi Nobo, > > > Thank you for the detail review. See inline below. > > > > > > Regards > > > Lizhong > > > > > > > -----Original Message----- > > > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > > > Sent: 2014=1B$BG/=1B(B6=1B$B7n=1B(B7=1B$BF|=1B(B 5:15 > > > > To: Loa Andersson; mpls@ietf.org > > > > Cc: ; mpls-chairs@tools.ietf.org; > > > draft-ietf-mpls- > > > > lsp-ping-relay-reply@tools.ietf.org > > > > Subject: RE: [mpls] Still Open - Re: Working group last call on > > > draft-ietf-mpls- > > > > lsp-ping-relay-reply > > > > > > > > Hi Loa, Authors, > > > > > > > > I have some comments and questions (and my apologies if questions > > > > have already been answered before). > > > > > > > > > > > > Section 3.2: > > > > > > > > The K bit may be set by ASBRs whose address would be > > > > kept in the stack if necessary. > > > > > > > > This is the only statement that I found regarding how responder is > > > > to > > > decide > > > > the setting of the K bit. I read it as "Set K bit if I'm likely to > > > > be a > > > relay point". I > > > > understand the motive behind this bit, but realistically it seems > > > > a bit > > > difficult > > > > to use, i.e. unless responder has some topology awareness, it's > > > > just > > > simpler > > > > to just to set the K bit. Can you provide more thoughts on exactly > > > > how you intended to use this bit? > > > [Lizhong] In a network with multiple ASs, and only ASBRs or border > > > nodes are the potential relay nodes. This maybe the most common case. > > > The original thought is to let all ASBRs to be relay node, and the > > > initiator could discover the ASBR list. So it is suggested to let > > > ASBR (or border node) to set K bit as a node wide configuration. But > > > we did > not > > restrict other nodes to set > > > K bit. > > > > There's a slight conflict then. If the intention of the K bit is to > > let > the initiator > > discover ASBRs, then we should have a text that says ASBRs SHOULD set > > the K bit and non-ASBRs MUST NOT set the K bit. Otherwise non-ASBRs > > setting the K bit can give wrong information to the initiator. > > However, if the intention has become more loose (i.e. any node who > > wants to remain in the TLV as the relay node), then perhaps a short tex= t > would be helpful. > > Something like: > > > > Having the K bit set on the relay node address entry causes that > > entry to be preserved in the Relay Node Address Stack TLV for the > > entire traceroute operation. A responder node MAY set the K bit to > > ensure its relay node address entry remains as one of the relay node= s > > in the Relay Node Address Stack TLV. Some nodes (ex: ASBR) could be > > configured to always set the K bit, or the module handling MPLS echo > > requests could discover its K bit use through topology awareness. > > How a node determines to set the K bit is outside the scope of this > > document. > [Lizhong] accepted. Thanks. >=20 > > > > > > > > > > > > > On a related note, I did not find any texts around usage of K bit > > > > and Unspecified Address Type, which probably should be considered > > invalid. > > > > If you agree, it would be good to add texts to enforce this. > > > [Lizhong] The usage and protocol operation of K bit and Unspecified > > > Address Type is described in section 4.2. I did not quite get this > > > comment, could you give more detail. > > > > What I meant was, do we ever want a relay node address entry that has > > K > bit > > set _and_ is Unspecified Address Type? It seems that will just waste > > space > in > > the Relay Node Address Stack TLV (and on the wire). I was just asking > > if there's any reason why K bit & Unspecified combination is not restri= cted. > [Lizhong] got it. You are right, the entry with Unspecified Address Type > SHOULD NOT set K bit. Will add this to the text. >=20 > > > > > > > > > > > > > > > > > Section 4.2: > > > > > > > > , and > > > > the address entry of the replying LSR MUST be added at the > > > > bottom > of > > > > the stack. > > > > > > > > The loop prevention paragraph in section 4.4 has a strict check > > > > that > > > received > > > > source IP address must be found in the address stack of the Relay > > > > Node Address Stack TLV. In that case, above statement in section > > > > 4.2 should be tightened that source IP address of transmitted > > > > packet must be used as the "address entry of the replying LSR". > > > > Otherwise valid reply may be dropped > > > by > > > > a relay node. > > > [Lizhong] accepted. Should be tightened that the address added in > > > Relay Node Address Stack TLV MUST be the source IP address of Relay > > > Echo Reply or Echo Reply message. > > > > Thanks. > > > > > > > > > > > > > > > > > Section 4.2: > > > > > > > > If the replying LSR is configured to hide its routable address > > > > information, the address entry added in the stack SHOULD be a bl= ank > > > > entry with Address Type set to unspecified. The blank address > entry > > > > in the receiving Echo Request SHOULD be treated as an unroutable > > > > address entry. > > > > > > > > What's the point of adding a blank entry (i.e. Unspecified Address > Type)? > > > I > > > > suppose the purpose of this is to let the initiator know the > > > > responder is intentionally hiding it's local address, but is that > > > > really necessary? If > > > so, what's > > > > the point of initiator preserving this blank entry in the Relay > > > > Node > > > Address > > > > Stack TLV in the next Echo Request, just to be deleted by the next > > > responder > > > > node? > > > [Lizhong] not only deleted by the next responder, if the replying > > > LSR is a relayed node, and reply with unspecified address, then the > > > unspecified address will not be deleted by the compress process. As > > > a result, the relayed echo reply will not be successfully sent back > > > to initiator. Security concern is the main motivation of setting > > > Unspecified Address Type, since Ping with Relayed Echo Rely could > > > trace every node across domains. If trace is only used for trouble > > > shooting, in many cases, these hiding LSR will not influence success > > > of > the > > trouble shooting if they are not relayed node. > > > > Ok, based on your answers above and below, blank entry makes sense. > > Although I don't see the point of allowing a blank entry have a K bit s= et. > [Lizhong] right, and as the previous comment, will add the restriction in= the > text. Thanks. >=20 > > > > > > > > > > > > > > > > > Section 4.4: > > > > > > > > I didn't see any texts describing what the source IP address of > > > > the packet sent by receiver of Relayed Echo Reply. I'm guessing > > > > that we cannot copy received source IP address as the source IP > > > > address of transmitting Echo Reply or further Relayed Echo Reply, > > > > since that will break the loop > > > prevention > > > > proposed in Section 4.4. However, if we are not preserving the > > > > source IP address from the original responder node, then there's > > > > an impact to traceroute implementations as they usually print out > > > > received source IP addresses (which no longer will be responder > > addresses). > > > > > > > > Initiator could do: > > > > > > > > If (Relay Node Address Stack TLV) { > > > > Print last address in the stack > > > > } else { > > > > Print source IP address > > > > } > > > > > > > > But if the last address in the stack was Unspecified, then > > > > traceroute > > > result > > > > now can become weaker than it used to be. > > > > > > > > Alternatively you could do: > > > > > > > > (1) Preserve the source IP address in received Relayed Echo Reply > > > > to transmitting Echo Reply or Relay Echo Reply. > > > > (2) Add one more condition in the loop prevention check. If the > > > > first > > > routable > > > > address in the Relay Node Address Stack TLV is self, then drop. > > > > > > > > Not sure if RPF check would be a concerning point, but if not, > > > > above > > > should > > > > work and traceroute will remain the same as today. And if you go > > > > via this, then source IP address will always be what would have > > > > been placed in the Relay Node Address Stack TLV by the responder. > > > > In that case, the purpose > > > of > > > > Unspecified Address Type becomes questionable. > > > [Lizhong] The initiator should print last address in the stack, we > > > should add this in the text. It could say weaker than legacy > > > traceroute from address displaying point of view. But traceroute is > > > now working in a multi-domain case. Hiding address should be allowed > > > if desired, under the condition that trouble shooting could still be > > > possible. Then we could say the new traceroute is stronger than > > > legacy > > from trouble shooting point of view. > > > > Ok in that case, please add texts for: > > - Source IP address in Echo Reply and Relay Echo Reply are to be of > > the address of the node sending those packets (i.e. not copied from > > received Relay Echo Reply). > > - Traceroute address output module will need to conditionally print > > the address in the Relay Node Address Stack TLV. > [Lizhong] accepted, thanks. >=20 > > > > > > > > > > > > > > > > > General: > > > > > > > > The document does not say that Proxy Ping is outside the scope, > > > > however I think a bit of additions are needed to make this work > > > > with Proxy Ping. For example, first address in the Relay Node > > > > Address Stack TLV should be Proxy sender, and Proxy receiver (i.e. > > > > Echo Request > > > > sender) will need to follow > > > the > > > > Relay Node Address Stack TLV update procedure just like receiver > > > > of Echo Request. > > > [Lizhong] right, but it seems draft-relay-reply moves faster than > > > draft-proxy- lsp-ping. It would be more reasonable to add the > > > suggested text to draft- proxy-lsp-ping, right? I could talk this > > > with author of draft-proxy-lsp-ping and chair. Thanks. > > > > Ah right, I forgot that Proxy has not become RFC yet. Yes I think > > that'll > be a > > good idea to make sure to raise this point to Proxy authors and chairs > > so > that > > it gets on some "todo list". > [Lizhong] good. >=20 > > > > > > > > > > > > > > > > > General: > > > > > > > > Any reason why TTL is not copied from received Relay Echo Reply to > > > > transmitting Echo Reply or Relay Echo Reply? > > > [Lizhong] this is a missing part, and should be added. I think copy > > > is the right behavior. Thanks. > > > > Agree. > > > > Thanks! > > > > -Nobo > > > > > > > > Regards > > > Lizhong > > > > > > > > > > > > > > > Thanks! > > > > > > > > -Nobo > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > > > > > Andersson > > > > > Sent: Thursday, June 05, 2014 1:21 AM > > > > > To: mpls@ietf.org > > > > > Cc: ; mpls-chairs@tools.ietf.org; > > > > > draft-ietf-mpls- lsp-ping-relay-reply@tools.ietf.org > > > > > Subject: [mpls] Still Open - Re: Working group last call on > > > > > draft-ietf-mpls- lsp-ping-relay-reply > > > > > > > > > > Working Group, > > > > > > > > > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last > > > > > call that was intended to be closed last Monday (June 2nd). > > > > > > > > > > Hopwever, there has not be a single response! > > > > > > > > > > I cn't make up my mind how to interprete this - either the wg > > > > > have lost interest in the draft (which would surprise me > > > > > greatly) or everybody thinks the draft is perfect (which would > > > > > also be a > surprise). > > > > > > > > > > I will therefore extend the wglc until June 16 and invite also > > > > > positive responses (e.g. "I think this document is ready for > > > publication!"). > > > > > > > > > > /Loa > > > > > for the wg chairs > > > > > > > > > > On 2014-05-19 11:49, Loa Andersson wrote: > > > > > > Working Group, > > > > > > > > > > > > This is to initiate a working group last call on > > > > > > draft-ietf-mpls-lsp-ping-relay-reply. > > > > > > > > > > > > There are two IPR disclosures against this document. The > > > > > > author has stated that he is unaware of any other IPRs that > > > > > > relate to this document. > > > > > > > > > > > > Please send your comments to the mpls wg mailing list > > (mpls@ietf.org). > > > > > > > > > > > > This working group last call ends June 2, 2014. > > > > > > > > > > > > /Loa > > > > > > for the MPLS wg chairs > > > > > > > > > > -- > > > > > > > > > > > > > > > Loa Andersson email: loa@mail01.huawei.com > > > > > Senior MPLS Expert loa@pi.nu > > > > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls >=20 From nobody Tue Jun 10 10:23:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAE81A01B6 for ; Tue, 10 Jun 2014 10:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 U3V5AznHxHYm for ; Tue, 10 Jun 2014 10:22:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id CB1E21A00E9 for ; Tue, 10 Jun 2014 10:22:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4F1BB1801C0; Tue, 10 Jun 2014 10:21:50 -0700 (PDT) To: eric.gray@ericsson.com, nitinb@juniper.net, sboutros@cisco.com, raggarwa_1@yahoo.com, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140610172150.4F1BB1801C0@rfc-editor.org> Date: Tue, 10 Jun 2014 10:21:50 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Glr7dW5gL5scq-t5ynYL_l0ut-o Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6426 (4012) 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, 10 Jun 2014 17:22:42 -0000 The following errata report has been submitted for RFC6426, "MPLS On-Demand Connectivity Verification and Route Tracing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6426&eid=4012 -------------------------------------- Type: Technical Reported by: Gregory Mirsky Section: 7 Original Text ------------- Corrected Text -------------- 7.6 New Global Flags Bit RFC 6425 defines a registry for Global Flags under Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping Parameters. This document defines a new Global Flag, Validate Reverse Path (R) that needs to be added to that registry, as follows: Bit number | Name | Reference ------------+----------------------------+-------------- 13 | Validate Reverse Path | [RFC 6426] Notes ----- "Global Flags" registry was created per request of RFC 6425, not RFC 4379 and did not yet existed when RFC 6426 was published. This "race condition" has to be fixed to avoid possible name-space collision between RFC 6426 and new extensions to LSP ping. Instructions: ------------- This errata 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. -------------------------------------- RFC6426 (draft-ietf-mpls-tp-on-demand-cv-07) -------------------------------------- Title : MPLS On-Demand Connectivity Verification and Route Tracing Publication Date : November 2011 Author(s) : E. Gray, N. Bahadur, S. Boutros, R. Aggarwal Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jun 10 10:51:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB21A0259 for ; Tue, 10 Jun 2014 10:51:28 -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_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 0KhEjCSZ1loe for ; Tue, 10 Jun 2014 10:51:26 -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 A85DD1A024D for ; Tue, 10 Jun 2014 10:51:26 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-8d-5396f2647186 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D7.9E.11744.462F6935; Tue, 10 Jun 2014 13:56:21 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 13:51:18 -0400 From: Eric Gray To: RFC Errata System , "nitinb@juniper.net" , "sboutros@cisco.com" , "raggarwa_1@yahoo.com" , "akatlas@gmail.com" , "adrian@olddog.co.uk" , "loa@pi.nu" , "swallow@cisco.com" , "rcallon@juniper.net" Thread-Topic: [Technical Errata Reported] RFC6426 (4012) Thread-Index: AQHPhNCXWTgc9xmmQk24z+HQvjPXnZtqnuLA Date: Tue, 10 Jun 2014 17:51:17 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632ADB421@eusaamb107.ericsson.se> References: <20140610172150.4F1BB1801C0@rfc-editor.org> In-Reply-To: <20140610172150.4F1BB1801C0@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXSPt27qp2nBBk83SVv86LnBbPHp4SVm i39z5zBb3Fq6ktWiobedzWLRpStsFn9XXGGxaNr/lc3i2JRPjBa3pzQxOnB5TPm9kdVj56y7 7B5Llvxk8rjedJXdY8XmlYwes6a3sXk0tB1j9Zg16zBTAEcUl01Kak5mWWqRvl0CV8aqq2IF 80QrJrwWbGB8I9DFyMkhIWAiMXPGR2YIW0ziwr31bF2MXBxCAkcZJSb82QXlLGeU+NfyD6yK TUBD4tidtYwgCRGBVmaJTU+3MYEkmAWCJTZfOsQIYgsLmEvcX/aSHcQWEbCQeL/9LxOEbSTR cGgCG4jNIqAq0fuuGyzOK+ArcWXNClYQWwio9+y1TSwgNidQ7/UdvWD1jEDnfT+1BmqXuMSt J/OZIM4WkFiy5zzUC6ISLx//Y4WwlSQ+/p7PDlGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKB UWwWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRoabGIERe0yCzXEH44JPlocYBTgYlXh4Fa5P CxZiTSwrrsw9xCjNwaIkzrvnWlWwkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbWSQV9x2of qSwNbtJ+HhxmWSfPe7r34zGBPSs/l6s8X3b69isRlmDR2b5vy+ZlX2C6qXK1RVNvr2ra9Pu/ OPfs/bzJ6vLJ8nUPdb2v8SyITdDn13B8l96yWPR8ziftj+dyk2RbrRn/xHGGH5MONKqv3C3Y sFc5jNFF83p674t3ZTvz7mn/k1BiKc5INNRiLipOBADTjBSvuQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/VT2ZfVJyWWnO7SPekA-CsHhRL1s Cc: "mpls@ietf.org" Subject: Re: [mpls] [Technical Errata Reported] RFC6426 (4012) 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, 10 Jun 2014 17:51:29 -0000 As a co-author of RFC 6426, I agree that this is an issue that should be fi= xed, in order to=20 avoid a name-space collision. Already there is a draft that attempts to us= e the same=20 bit for a separate and distinct purpose. -- Eric -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Tuesday, June 10, 2014 1:22 PM To: Eric Gray; nitinb@juniper.net; sboutros@cisco.com; raggarwa_1@yahoo.com= ; akatlas@gmail.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rca= llon@juniper.net Cc: Gregory Mirsky; mpls@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC6426 (4012) Importance: High The following errata report has been submitted for RFC6426, "MPLS On-Demand= Connectivity Verification and Route Tracing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6426&eid=3D4012 -------------------------------------- Type: Technical Reported by: Gregory Mirsky Section: 7 Original Text ------------- Corrected Text -------------- 7.6 New Global Flags Bit RFC 6425 defines a registry for Global Flags under Multi-Protocol Label Swi= tching (MPLS) Label Switched Path (LSP) Ping Parameters. This document defines a new Global Flag, "Validate Reverse Path (R)" that needs to be added to that registry, as follows: Bit number | Name | Reference ------------+----------------------------+-------------- 13 | Validate Reverse Path | [RFC 6426] Notes ----- "Global Flags" registry was created per request of RFC 6425, not RFC 4379 a= nd did not yet existed when RFC 6426 was published. This "race condition" h= as to be fixed to avoid possible name-space collision between RFC 6426 and = new extensions to LSP ping. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary.=20 -------------------------------------- RFC6426 (draft-ietf-mpls-tp-on-demand-cv-07) -------------------------------------- Title : MPLS On-Demand Connectivity Verification and Route Tr= acing Publication Date : November 2011 Author(s) : E. Gray, N. Bahadur, S. Boutros, R. Aggarwal Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jun 10 13:36:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC771A02E0 for ; Tue, 10 Jun 2014 13:36:24 -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 zyr4pGjgBkDB for ; Tue, 10 Jun 2014 13:36:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B003C1A02DA for ; Tue, 10 Jun 2014 13:36:20 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 10 Jun 2014 20:36:18 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Tue, 10 Jun 2014 20:36:17 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Improving and Restructuring the Routing Area Thread-Index: AQHPhOZLafoij3+aqkKhXgVuYb6Fv5tqzN8Q Date: Tue, 10 Jun 2014 20:36:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(69234005)(164054003)(199002)(189002)(19609705001)(21056001)(76576001)(19625215002)(18717965001)(81542001)(74502001)(87936001)(99286001)(92566001)(15975445006)(2656002)(83072002)(85852003)(76482001)(19300405004)(16236675004)(81342001)(64706001)(46102001)(74662001)(54356999)(99396002)(80022001)(101416001)(31966008)(99936001)(4396001)(19580395003)(33646001)(74316001)(77982001)(66066001)(20776003)(50986999)(19580405001)(77096999)(15202345003)(86362001)(79102001)(83322001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: multipart/mixed; boundary="_004_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SqTSqe6B7oSG8yaKZMW5zi8hRks Subject: [mpls] FW: Improving and Restructuring the Routing Area 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, 10 Jun 2014 20:36:24 -0000 --_004_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_ Content-Type: multipart/alternative; boundary="_000_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_" --_000_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLiBGb3IgdGhvc2UgaW50ZXJlc3RlZCwgaXQgaXMgcHJvYmFibHkgYmVzdCB0byBqb2luIHRo ZSByb3V0aW5nLWRpc2N1c3Npb24gZW1haWwgbGlzdCByYXRoZXIgdGhhbiBkaXNjdXNzaW5nIHRo aXMgb24gdGhlIE1QTFMgbGlzdC4gTVBMUyBwYXJ0aWNpcGFudHMgbWlnaHQgbm90aWNlIHRoZSBw aHJhc2Ug4oCcU3BsaXQgZ2lhbnQgd29ya2luZyBncm91cHPigKbigJ0gaW4gdGhlIGVtYWlsIGJl bG93Lg0KDQpUaGFua3MsIFJvc3MNCg0KRnJvbTogcm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86 cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0 bGFzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDM6NTggUE0NClRvOiByb3V0aW5nLWRp c2N1c3Npb25AaWV0Zi5vcmcNClN1YmplY3Q6IEltcHJvdmluZyBhbmQgUmVzdHJ1Y3R1cmluZyB0 aGUgUm91dGluZyBBcmVhDQoNClRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhlIFJvdXRpbmcgQXJl YSwNCg0KQWRyaWFuIGFuZCBJIGFyZSB3b3JraW5nIG9uIGltcHJvdmluZyB0aGUgcXVhbGl0eSwg c3BlZWQsIGFuZA0KZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBpbiB0aGUgSUVURiBS b3V0aW5nIEFyZWEuICBUaGVyZSBhcmUNCnRocmVlIGluaXRpYXRpdmVzIHRoYXQgd2UgYXJlIHdv cmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWENCnNwZWNpZmljIFdHIGNoYWlyIHRyYWlu aW5nLCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0aGUNCmFyZWEuDQoN CkZpcnN0LCB3ZSBpbnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9yYXRlIG1vcmUgcHJv YWN0aXZlbHkgYnkNCmludHJvZHVjaW5nIGEgV29ya2luZyBHcm91cCBEcmFmdCBRdWFsaXR5IEFz c3VyYW5jZSAoV0cgRHJhZnQgUUEpDQpwcm9jZXNzIHdoZXJlIHRoZSBzYW1lIHNlbGVjdGVkIHJv dXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVyIHdpbGwgcmV2aWV3DQphIGRyYWZ0IGR1cmluZyBXRyBk cmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gIFRoZSBwcm9jZXNzDQp3aWxs IGJlIGRvY3VtZW50ZWQgb24gdGhlIFJvdXRpbmcgQXJlYSB3aWtpDQooaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpKS4gIFRoaXMgc2hvdWxkIGFsbG93DQpkaXJl Y3RvcmF0ZSByZXZpZXdzIHRvIHJlcG9ydCB0ZWNobmljYWwgaXNzdWVzIHRoYXQgY2FuIGFjdHVh bGx5IGdldA0KZml4ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxlbnQgb2YgYnVnIHJl cG9ydHMpIGFzIG9wcG9zZWQgdG8NCmp1c3Qgbm90aW5nIHRoZSBjb25jZXJucyBpbiB0aGUgZHJh ZnRzIChlcXVpdmFsZW50IG9mIHJlbGVhc2Ugbm90ZXMpLg0KDQpTZWNvbmQsIGFzIHdhcyBkaXNj dXNzZWQgZHVyaW5nIHRoZSByZWNlbnQgSUVTRyByZXRyZWF0LCBpbiBhZGRpdGlvbg0KdG8gdGhl IElFVEYtd2lkZSBXRyBjaGFpciB0cmFpbmluZywgd2UgaW50ZW5kIHRvIGhhdmUgYSBzZXJpZXMg b2YNCnRyYWluaW5nIHNlc3Npb25zIGZvciBXRyBDaGFpcnMgaW4gdGhlIFJvdXRpbmcgQXJlYSBh ZGRyZXNzaW5nIHRvcGljcw0Kc3VjaCBhcyBqdWRnaW5nIGNvbnNlbnN1cywgcHJvamVjdCBtYW5h Z2VtZW50LCBtb3RpdmF0aW5nIHZvbHVudGVlcnMsDQp1c2luZyB0aGUgZGF0YXRyYWNrZXIgKHZp YSBhIHNhbmRib3ggdmVyc2lvbiB0aGF0IGNhbiBiZSBwbGF5ZWQNCndpdGggc2FmZWx5KSwgYW5k IHNoYXJpbmcgZXhwZXJpZW5jZXMgYmV0d2VlbiBXRyBjaGFpcnMuDQoNClRoaXJkLCB3ZSBpbnRl bmQgdG8gcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlIFJvdXRpbmcgYXJlYS4N CldlIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZm9jdXMgb24gYXJlYXMgd2hlcmUgdGhl cmUgaXMgYWN0aXZlDQppbnRlcmVzdCBpbiBzdGFuZGFyZGl6YXRpb24gYW5kIHRvIGJlIG9wZW4g YW5kIGFibGUgdG8gYWNjZXB0IG5ldyB3b3JrDQppbnRvIHRoZSBhcmVhLiAgQXMgeW91IGtub3cs IHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzDQoobnZvMywgaTJycywgc2Zj LCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3ZSBuZWVkIHRvDQpi ZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0IGNvbWVzIGluLiAg V2Ugd291bGQNCmFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwtdG8tbm9pc2UgcmF0aW8g ZXhwZXJpZW5jZWQgYnkNCnBhcnRpY2lwYW50cyBpbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcgZ3Jv dXBzIGFuZCBpbXByb3ZlIHRoZSBxdWFudGl0eQ0KYW5kIHF1YWxpdHkgb2YgZGlzY3Vzc2lvbiBh bmQgcmV2aWV3cy4gIEl0IGlzIGxpa2VseSB0aGF0IG5vdCBhbGwgV0dzDQppbiB0aGUgUm91dGlu ZyBBcmVhIHdpbGwgYmUgZGlyZWN0bHkgYWZmZWN0ZWQuDQoNCkhlcmUgaXMgdGhlIHRpbWUtbGlu ZSBmb3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuDQoNCiAgIE5PVzogcHVibGljIGRpc2N1c3Npb24g b24gcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPG1haWx0bzpyb3V0aW5nLWRpc2N1c3Npb25A aWV0Zi5vcmc+IGFib3V0IGhvdyB0bw0KICAgcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMg dG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9ucy4NCiAgIEFkZGl0aW9uYWwgZm9jdXNlZCBkaXNj dXNzaW9ucyBhcmUgZXhwZWN0ZWQgb24gdGhlDQogICBydGctY2hhaXJzQGlldGYub3JnPG1haWx0 bzpydGctY2hhaXJzQGlldGYub3JnPiBhbmQgcnRnLWRpckBpZXRmLm9yZzxtYWlsdG86cnRnLWRp ckBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cy4NCg0KICAgSW4gVG9yb250bzogVGhlcmUgd2lsbCBi ZSBtZWV0aW5ncyB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIHRoZQ0KICAgUm91dGluZyBEaXJlY3Rv cmF0ZSB0byBnZXQgdGhlIGlkZWFzIGRlc2NyaWJlZCBhbmQgYWdyZWVkIHVwb24uDQoNCiAgIEF0 IHRoZSBSb3V0aW5nIEFyZWEgTWVldGluZyBpbiBUb3JvbnRvOiBEaXNjdXNzIHRoZSBzZXQgb2YN CiAgIHJlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRlbnQgaW4gdGhlIFJv dXRpbmcgQXJlYQ0KICAgbWVldGluZy4NCg0KICAgU2VwdGVtYmVyIDIwMTQ6IEJhc2VkIHVwb24g dGhlIGZlZWRiYWNrLCBzdWdnZXN0aW9ucywgYW5kDQogICBkaXNjdXNzaW9uLCBBZHJpYW4gYW5k IEkgZmluYWxpemUgdGhlIHJlb3JnYW5pemVkIFdHIGNoYXJ0ZXJzLiAgV2UNCiAgIHN0YXJ0IHRo ZSBpbnRlcm5hbCBJRVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyByZXZpZXdzLg0KDQogICBPY3Rv YmVyIDIwMTQ6IEZvcm1hbCByZWNoYXJ0ZXJpbmcgcHJvY2VzcyBjb21wbGV0ZXMuDQoNCiAgIElu IEhvbm9sdWx1OiBUaGUgbmV3IHNldCBvZiBXR3MgbWVldC4NCg0KICAgQWZ0ZXIgSG9ub2x1bHU6 IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55IGlzc3VlcyBhbmQgY2hhcnRlcg0KICAgdXBkYXRl cyBiYXNlZCB1cG9uIGEgZmV3IG1vbnRocyBvZiBleHBlcmllbmNlLg0KDQpIZXJlIGFyZSB0aGUg bW90aXZhdGlvbnMgdGhhdCBBZHJpYW4gYW5kIEkgd291bGQgbGlrZSB0byBiZSBjb25zaWRlcmVk DQp3aGVuIGNvbWluZyB1cCB3aXRoIGlkZWFzIGZvciBob3cgdGhlIFdHcyBzaG91bGQgYmUgcmVv cmdhbml6ZWQuDQoNCiAgIDEpIE1vdmUgdG93YXJkcyBvcmdhbml6aW5nIHdvcmtpbmcgZ3JvdXBz IG9uIGZ1bmN0aW9uYWwNCiAgIHJlc3BvbnNpYmlsaXRpZXMgcmF0aGVyIHRoYW4gc2NvcGluZyB0 aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy4NCg0KICAgMikgU3BsaXQgZ2lhbnQgd29ya2luZyBn cm91cHMgc28gcmVsZXZhbnQgd29yayBpcyBkb25lIGluIG9uZSBwbGFjZQ0KICAgYW5kIHRoZXJl IGlzIGFuIGltcHJvdmVkIHNpZ25hbC10by1ub2lzZSByYXRpbyBmb3IgcGFydGljaXBhbnRzIHdo bw0KICAgYXJlIG9ubHkgaW50ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBjdXJyZW50IHdvcmtp bmcgZ3JvdXAncyB3b3JrLg0KDQogICAzKSBDcmVhdGUgc3luZXJnaWVzIGZvciBzY2F0dGVyZWQg ZnVuY3Rpb25hbGl0eSAoZXhhbXBsZSBpZGVhczoNCiAgIE9BTSwgRlJSLCB0cmFmZmljLWVuZ2lu ZWVyaW5nKQ0KDQogICA0KSBDcmVhdGUgYSBESVNQQVRDSCB3b3JraW5nIGdyb3VwIGZvciBjbGVh ciBuZXcgaWRlYSBkaXNjdXNzaW9uOw0KICAgcnRnd2cgc2VydmVzIHNvbWUgb2YgdGhpcyBwdXJw b3NlIGJ1dCBkb2Vzbid0IGhhdmUgYSBjbGVhciBwcm9jZXNzDQogICBhbmQgaXNuJ3QgZHJhd2lu ZyBpbiB0aGUgbmV3IGlkZWFzLg0KDQogICA1KSBGb2N1cyBSb3V0aW5nIEFyZWEgdGltZSBvbiBk ZXNpZ24gY2VudGVycyByYXRoZXIgdGhhbiBvbiBmYXINCiAgIGNvcm5lciBjYXNlcy4NCg0KICAg NikgRWFjaCB3b3JraW5nIGdyb3VwIHNob3VsZCBoYXZlIGNsZWFyLCB3ZWxsIGRlZmluZWQsIGFu ZCBhY2hpZXZhYmxlIGdvYWxzLg0KDQpOb3RpbmcgdGhhdCB0aGUgUm91dGluZyBBcmVhIGhhcyBp bmhlcml0ZWQgc29tZSBvZiBpdHMgV0cgc3RydWN0dXJlDQpmcm9tIHRoZSBzdWItSVAgYXJlYSwg aXQgaXMgbm90IGEgZ29hbCB0byBmb3JjZSBJUCByb3V0aW5nIGFuZCBNUExTDQpyb3V0aW5nIHRv IHJlbWFpbiBzZXBhcmF0ZWQuDQoNClRoZSBnb2FsIG9mIHRoaXMgcmVvcmdhbml6YXRpb24gaXMg bm90IGNsb3Npbmcgd29ya2luZyBncm91cHMuICBBZHJpYW4NCmFuZCBBbGlhIGFyZSBwZXJmZWN0 bHkgY2FwYWJsZSBvZiBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBzIHdpdGhvdXQgZ29pbmcNCnRocm91 Z2ggcmVzdHJ1Y3R1cmluZy4NCg0KRm9yIHRob3NlIG9mIHlvdSB0aGF0IGhhdmUgcmVhZCB0aGlz IGZhciwgdGhhbmsgeW91LiAgR2V0dGluZyB0aGlzIDgwJQ0KcmlnaHQgaXMgZ29pbmcgdG8gdGFr ZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lvbiBhbmQgdGhvdWdodC4gIFdlIGFsbA0Kd29yayBpbiB0 aGUgUm91dGluZyBBcmVhIHRvZ2V0aGVyIHdpdGggZGlmZmVyZW50IHBlcnNwZWN0aXZlcy4gIFBs ZWFzZQ0KdGhpbmsgY2FyZWZ1bGx5IGFuZCBoZWxwIHVzIGhhdmUgYSBoaWdobHkgZm9jdXNlZCBk aXNjdXNzaW9uLg0KDQpUaGFua3MsDQpBbGlhIGFuZCBBZHJpYW4NCg0K --_000_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_ 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 ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GWUkuIEZvciB0aG9zZSBpbnRlcmVzdGVkLCBpdCBpcyBw cm9iYWJseSBiZXN0IHRvIGpvaW4gdGhlIHJvdXRpbmctZGlzY3Vzc2lvbiBlbWFpbCBsaXN0IHJh dGhlciB0aGFuIGRpc2N1c3NpbmcgdGhpcyBvbiB0aGUgTVBMUyBsaXN0LiBNUExTIHBhcnRpY2lw YW50cyBtaWdodA0KIG5vdGljZSB0aGUgcGhyYXNlIOKAnFNwbGl0IGdpYW50IHdvcmtpbmcgZ3Jv dXBz4oCm4oCdIGluIHRoZSBlbWFpbCBiZWxvdy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsIFJvc3MNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gcm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9u LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsaWEgQXRsYXM8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCAzOjU4IFBNPGJyPg0KPGI+VG86PC9i PiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW1wcm92 aW5nIGFuZCBSZXN0cnVjdHVyaW5nIHRoZSBSb3V0aW5nIEFyZWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBhbGwgcGFydGljaXBhbnRzIGlu IHRoZSBSb3V0aW5nIEFyZWEsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFkcmlhbiBhbmQgSSBhcmUgd29ya2luZyBvbiBpbXByb3ZpbmcgdGhl IHF1YWxpdHksIHNwZWVkLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmV4cGVyaWVuY2Ugb2YgZ2V0dGluZyB3b3JrIGRvbmUgaW4gdGhlIElF VEYgUm91dGluZyBBcmVhLiAmbmJzcDtUaGVyZSBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRocmVlIGluaXRpYXRpdmVzIHRoYXQgd2UgYXJl IHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNwZWNpZmljIFdHIGNoYWlyIHRyYWluaW5n LCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0aGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZWEuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0LCB3ZSBpbnRl bmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9yYXRlIG1vcmUgcHJvYWN0aXZlbHkgYnk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludHJvZHVj aW5nIGEgV29ya2luZyBHcm91cCBEcmFmdCBRdWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQgUUEp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9j ZXNzIHdoZXJlIHRoZSBzYW1lIHNlbGVjdGVkIHJvdXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVyIHdp bGwgcmV2aWV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hIGRyYWZ0IGR1cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3Qg Y2FsbC4gJm5ic3A7VGhlIHByb2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPndpbGwgYmUgZG9jdW1lbnRlZCBvbiB0aGUgUm91dGluZyBBcmVh IHdpa2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pig8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2ki Pmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraTwvYT4pLiAmbmJz cDtUaGlzIHNob3VsZCBhbGxvdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ZGlyZWN0b3JhdGUgcmV2aWV3cyB0byByZXBvcnQgdGVjaG5pY2FsIGlz c3VlcyB0aGF0IGNhbiBhY3R1YWxseSBnZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZpeGVkIGVhcmx5IGluIHRoZSBwcm9jZXNzIChlcXVpdmFs ZW50IG9mIGJ1ZyByZXBvcnRzKSBhcyBvcHBvc2VkIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5qdXN0IG5vdGluZyB0aGUgY29uY2VybnMgaW4g dGhlIGRyYWZ0cyAoZXF1aXZhbGVudCBvZiByZWxlYXNlIG5vdGVzKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kLCBhcyB3YXMgZGlz Y3Vzc2VkIGR1cmluZyB0aGUgcmVjZW50IElFU0cgcmV0cmVhdCwgaW4gYWRkaXRpb248bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIHRoZSBJRVRG LXdpZGUgV0cgY2hhaXIgdHJhaW5pbmcsIHdlIGludGVuZCB0byBoYXZlIGEgc2VyaWVzIG9mPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cmFpbmlu ZyBzZXNzaW9ucyBmb3IgV0cgQ2hhaXJzIGluIHRoZSBSb3V0aW5nIEFyZWEgYWRkcmVzc2luZyB0 b3BpY3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnN1Y2ggYXMganVkZ2luZyBjb25zZW5zdXMsIHByb2plY3QgbWFuYWdlbWVudCwgbW90aXZhdGlu ZyB2b2x1bnRlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dXNpbmcgdGhlIGRhdGF0cmFja2VyICh2aWEgYSBzYW5kYm94IHZlcnNpb24gdGhh dCBjYW4gYmUgcGxheWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj53aXRoIHNhZmVseSksIGFuZCBzaGFyaW5nIGV4cGVyaWVuY2VzIGJldHdlZW4g V0cgY2hhaXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlyZCwgd2UgaW50ZW5kIHRvIHJlb3JnYW5pemUgdGhlIHdvcmtpbmcgZ3JvdXBz IGluIHRoZSBSb3V0aW5nIGFyZWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZSBmZWVsIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGZvY3VzIG9u IGFyZWFzIHdoZXJlIHRoZXJlIGlzIGFjdGl2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50ZXJlc3QgaW4gc3RhbmRhcmRpemF0aW9uIGFuZCB0 byBiZSBvcGVuIGFuZCBhYmxlIHRvIGFjY2VwdCBuZXcgd29yazxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50byB0aGUgYXJlYS4gJm5ic3A7QXMg eW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4obnZvMywgaTJycywg c2ZjLCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3ZSBuZWVkIHRv PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iZSBv cGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0IGNvbWVzIGluLiAmbmJz cDtXZSB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YWxzbyBsaWtlIHRvIGltcHJvdmUgdGhlIHNpZ25hbC10by1ub2lzZSByYXRpbyBleHBl cmllbmNlZCBieTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+cGFydGljaXBhbnRzIGluIHRoZSBkaWZmZXJlbnQgd29ya2luZyBncm91cHMgYW5kIGlt cHJvdmUgdGhlIHF1YW50aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5hbmQgcXVhbGl0eSBvZiBkaXNjdXNzaW9uIGFuZCByZXZpZXdzLiAmbmJz cDtJdCBpcyBsaWtlbHkgdGhhdCBub3QgYWxsIFdHczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gdGhlIFJvdXRpbmcgQXJlYSB3aWxsIGJlIGRp cmVjdGx5IGFmZmVjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IZXJlIGlzIHRoZSB0aW1lLWxpbmUgZm9yIHJlb3JnYW5pemluZyB0aGUg V0dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7Tk9XOiBwdWJsaWMgZGlzY3Vzc2lvbiBvbiA8YSBocmVmPSJtYWlsdG86 cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnIj4NCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9y ZzwvYT4gYWJvdXQgaG93IHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMg dG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBZGRpdGlvbmFsIGZvY3VzZWQg ZGlzY3Vzc2lvbnMgYXJlIGV4cGVjdGVkIG9uIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpy dGctY2hhaXJzQGlldGYub3JnIj5ydGctY2hhaXJzQGlldGYub3JnPC9hPiBhbmQNCjxhIGhyZWY9 Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGlyQGlldGYub3JnPC9hPiBtYWlsaW5nIGxp c3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7SW4gVG9yb250bzogVGhlcmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRoIHRo ZSBXRyBjaGFpcnMgYW5kIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1JvdXRpbmcgRGlyZWN0b3JhdGUgdG8gZ2V0IHRo ZSBpZGVhcyBkZXNjcmliZWQgYW5kIGFncmVlZCB1cG9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7QXQgdGhlIFJvdXRp bmcgQXJlYSBNZWV0aW5nIGluIFRvcm9udG86IERpc2N1c3MgdGhlIHNldCBvZjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Jl b3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRlbnQgaW4gdGhlIFJvdXRpbmcg QXJlYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO21lZXRpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtTZXB0ZW1iZXIgMjAxNDogQmFzZWQgdXBv biB0aGUgZmVlZGJhY2ssIHN1Z2dlc3Rpb25zLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtkaXNjdXNzaW9uLCBBZHJp YW4gYW5kIEkgZmluYWxpemUgdGhlIHJlb3JnYW5pemVkIFdHIGNoYXJ0ZXJzLiAmbmJzcDtXZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO3N0YXJ0IHRoZSBpbnRlcm5hbCBJRVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyByZXZp ZXdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7T2N0b2JlciAyMDE0OiBGb3JtYWwgcmVjaGFydGVyaW5nIHByb2Nlc3Mg Y29tcGxldGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7SW4gSG9ub2x1bHU6IFRoZSBuZXcgc2V0IG9mIFdHcyBtZWV0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7QWZ0ZXIgSG9ub2x1bHU6IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55IGlz c3VlcyBhbmQgY2hhcnRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3VwZGF0ZXMgYmFzZWQgdXBvbiBhIGZldyBtb250aHMg b2YgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGVyZSBhcmUgdGhlIG1vdGl2YXRpb25zIHRoYXQgQWRyaWFuIGFuZCBJIHdv dWxkIGxpa2UgdG8gYmUgY29uc2lkZXJlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlbiBjb21pbmcgdXAgd2l0aCBpZGVhcyBmb3IgaG93IHRo ZSBXR3Mgc2hvdWxkIGJlIHJlb3JnYW5pemVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7MSkgTW92ZSB0b3dhcmRzIG9y Z2FuaXppbmcgd29ya2luZyBncm91cHMgb24gZnVuY3Rpb25hbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Jlc3BvbnNpYmls aXRpZXMgcmF0aGVyIHRoYW4gc2NvcGluZyB0aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOzIpIFNwbGl0IGdpYW50IHdvcmtpbmcgZ3JvdXBzIHNvIHJlbGV2YW50IHdvcmsgaXMg ZG9uZSBpbiBvbmUgcGxhY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthbmQgdGhlcmUgaXMgYW4gaW1wcm92ZWQgc2lnbmFs LXRvLW5vaXNlIHJhdGlvIGZvciBwYXJ0aWNpcGFudHMgd2hvPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YXJlIG9ubHkgaW50 ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBjdXJyZW50IHdvcmtpbmcgZ3JvdXAncyB3b3JrLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7MykgQ3JlYXRlIHN5bmVyZ2llcyBmb3Igc2NhdHRlcmVkIGZ1bmN0aW9uYWxpdHkg KGV4YW1wbGUgaWRlYXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7T0FNLCBGUlIsIHRyYWZmaWMtZW5naW5lZXJpbmcpPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDs0KSBDcmVhdGUgYSBESVNQQVRDSCB3b3JraW5nIGdyb3VwIGZvciBjbGVhciBuZXcg aWRlYSBkaXNjdXNzaW9uOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3J0Z3dnIHNlcnZlcyBzb21lIG9mIHRoaXMgcHVycG9z ZSBidXQgZG9lc24ndCBoYXZlIGEgY2xlYXIgcHJvY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FuZCBpc24ndCBkcmF3 aW5nIGluIHRoZSBuZXcgaWRlYXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs1KSBGb2N1cyBSb3V0aW5nIEFyZWEgdGlt ZSBvbiBkZXNpZ24gY2VudGVycyByYXRoZXIgdGhhbiBvbiBmYXI8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjb3JuZXIgY2Fz ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDs2KSBFYWNoIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGhhdmUgY2xlYXIsIHdl bGwgZGVmaW5lZCwgYW5kIGFjaGlldmFibGUgZ29hbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGluZyB0aGF0IHRoZSBSb3V0aW5nIEFy ZWEgaGFzIGluaGVyaXRlZCBzb21lIG9mIGl0cyBXRyBzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZyb20gdGhlIHN1Yi1JUCBhcmVh LCBpdCBpcyBub3QgYSBnb2FsIHRvIGZvcmNlIElQIHJvdXRpbmcgYW5kIE1QTFM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJvdXRpbmcgdG8gcmVt YWluIHNlcGFyYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGdvYWwgb2YgdGhpcyByZW9yZ2FuaXphdGlvbiBpcyBub3QgY2xvc2lu ZyB3b3JraW5nIGdyb3Vwcy4gJm5ic3A7QWRyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgQWxpYSBhcmUgcGVyZmVjdGx5IGNhcGFibGUg b2YgY2xvc2luZyB3b3JraW5nIGdyb3VwcyB3aXRob3V0IGdvaW5nPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aHJvdWdoIHJlc3RydWN0dXJpbmcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZv ciB0aG9zZSBvZiB5b3UgdGhhdCBoYXZlIHJlYWQgdGhpcyBmYXIsIHRoYW5rIHlvdS4gJm5ic3A7 R2V0dGluZyB0aGlzIDgwJTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+cmlnaHQgaXMgZ29pbmcgdG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lv biBhbmQgdGhvdWdodC4gJm5ic3A7V2UgYWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3JrIGluIHRoZSBSb3V0aW5nIEFyZWEgdG9nZXRoZXIg d2l0aCBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLiAmbmJzcDtQbGVhc2U8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaW5rIGNhcmVmdWxseSBhbmQg aGVscCB1cyBoYXZlIGEgaGlnaGx5IGZvY3VzZWQgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxpYSBhbmQgQWRyaWFu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_-- --_004_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=169; creation-date="Tue, 10 Jun 2014 19:58:06 GMT"; modification-date="Tue, 10 Jun 2014 19:58:06 GMT" Content-ID: <54B48085F7C55C4FA4E428EA2638016E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJvdXRpbmct ZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QNCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb3V0aW5nLWRpc2N1c3Npb24NCg== --_004_cc95287357394b17ae18bb3f27f49ae7CO2PR05MB636namprd05pro_-- From nobody Tue Jun 10 13:45:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817191A0439 for ; Tue, 10 Jun 2014 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAwAxJJ-Qwp3 for ; Tue, 10 Jun 2014 13:45: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 6378B1A02FB for ; Tue, 10 Jun 2014 13:45:20 -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 BFG96937; Tue, 10 Jun 2014 20:45:18 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 21:45:17 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.7]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 13:45:12 -0700 From: Huaimo Chen To: Autumn Liu , Yimin Shen , Ross Callon , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSV8o/K71U51ukWB9kHnTmwa65s34q2AgAkYsaCAF+H7gIASEs9Q Date: Tue, 10 Jun 2014 20:45:10 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C73DE9@SJCEML701-CHM.china.huawei.com> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C68100@SJCEML703-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.254] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C73DE9SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/IurQCBUAsLdRpx0_3f4EhhA75_k Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 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, 10 Jun 2014 20:45:26 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C73DE9SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Autumn, Thanks for your comments! My answers/explanations are inline below. Best Regards, Huaimo From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, May 29, 2014 8:22 PM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, Thanks for your reply. Please see my comments inline. -Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Wednesday, May 14, 2014 8:17 PM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Thanks for your questions! My answers are inline below. Best Regards, Huaimo From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, May 08, 2014 8:44 PM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, I have some questions. 1) How Inner label (vpn label) acquired on primary egress node is sent= to backup egress node? Via PATH message for backup LSP? which object is us= ed? How this label is processed? How this label is maintained? [Huaimo] An inner label (such as VPN label) allocated on the primary egress= node may be sent to the backup egress node in one of a few ways. One way i= s to use BGP to send the inner label to the backup egress node from the pri= mary egress node. Alternatively, the inner label may be sent from the prima= ry egress node to the upstream node of the primary egress node through an E= GRESS-BACKUP object in RESV message and then the upstream node sends the in= ner label to the backup egress node via an EGRESS-BACKUP object in the PAT= H message for the backup LSP. When the backup egress node receives the inne= r label as a UA label originally from the primary egress, it adds a forward= ing entry with the label into the LFIB for the primary egress node. When th= e backup egress node receives a packet from the backup LSP, it uses the top= label as a context label to find the LFIB for the primary egress node and = the inner label to deliver the packet to the same destination as the primar= y egress node according to the LFIB. Note that exactly how the inner label is sent from the primary egress node = to the backup egress node is out of scope for this document. I understand that this is out of scope of this document, but it is still no= t clear to me how inner label is going to be processed, maintained and prog= rammed. If bgp is used to send the inner label from primary egress node to = backup egress node, how bgp know there is backup egress node? Even this is = possible, the egress protection on the rsvp level should make this transpar= ent to bgp and any other applications using rsvp. If the alternative way yo= u described is used, it seems that rsvp will program a bgp entry in forward= ing plane, I don't think this is desired behavior either. [Huaimo 2] The inner label is processed by rsvp on the upstream node of the= primary egress in a way similar to the existing way for the intermediate n= ode protection. For protecting an intermediate node such as node X using f= acility backup, the upstream node of the node X will use the label allocate= d by the next hop node of X as the inner label . For protecting the primary= egress node, the upstream node of the primary egress will use the label al= located by the primary egress as the inner label . There is an object calle= d EGRESS_BACKUP object, which contains the primary egress IP address and th= e backup egress IP address. This object will be sent to the primary egress = by rsvp. At the primary egress, this information can be sent to any protoco= l, which is responsible for delivering the inner label as a upstream assign= ed label to the backup egress. The rsvp will not program any forwarding ent= ries on the backup egress for this inner label as a UA label. 2) How PLR can acquire a path to backup egress node, its address is th= e same as primary egress node? [Huaimo] PLR gets the backup egress node first and then computes a path fro= m the PLR to the backup egress node. The backup egress node may be configur= ed by an operator on the ingress of the primary LSP. If it is configured, t= he ingress will include the backup egress node in the PATH message through = using EGRESS_BACKUP object. If the backup egress node is not given by the o= perator, the PLR tries to find the backup egress node, which is not the pri= mary egress node but has the same IP address as the destination IP address = of the LSP. Note that the primary egress node and the backup egress node S= HOULD have a same local address configured, and the cost to the local addre= ss on the backup egress node SHOULD be much bigger than the cost to the loc= al address on the primary egress node. The question is not about knowing the backup egress node, it is how to get = a route to backup egress node given the fact that the backup egress node ha= s the same address of the primary egress node. [Huaimo 2] The PLR computes a shortest constrained path to that address. Si= nce the cost to that address from the primary egress node is much bigger, t= he PLR will get the path to that address through the backup egress node. 3) Does PLR sends the PATH message for primary LSP to backup egress no= de? [Huaimo] No. Then how the state of primary LSP on upstream node of the primary egress no= de is maintained after failure occurs? [Huaimo 2] The upstream node may continue to send the resv message to its u= pstream node along the primary LSP after the failure of the primary egress. Thanks, Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, May 06, 2014 5:20 AM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_5316A0AB3C851246A7CA5758973207D445C73DE9SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Autumn,

 <= /p>

Thanks for your comments!

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Autumn L= iu [mailto:autumn.liu@ericsson.com]
Sent: Thursday, May 29, 2014 8:22 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 

Thanks for your reply. Plea= se see my comments inline.

-Autumn

 <= /p>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Wednesday, May 14, 2014 8:17 PM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 <= /p>

Thanks for your questions!

My answers are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Autumn L= iu [mailto:autumn.liu@ericsson.c= om]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 

I have some questions.

1= )   &= nbsp;  How Inner label (vpn label) acq= uired on primary egress node is sent to backup egress node? Via PATH messag= e for backup LSP? which object is used? How this label is processed? How this label is maintained?

[Huaimo] An inner label (= such as VPN label) allocated on the primary egress node may be sent to the = backup egress node in one of a few ways. One way is to use BGP to send the inner label to the backup egress node from the primary egr= ess node. Alternatively, the inner label may be sent from the primary egres= s node to the upstream node of the primary egress node through an EGRESS-BA= CKUP object in RESV message and then the upstream node sends the inner label to the backup egress node via=  an EGRESS-BACKUP object in the PATH message for the backup LSP. When= the backup egress node receives the inner label as a UA label originally f= rom the primary egress, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the b= ackup egress node receives a packet from the backup LSP, it uses the top la= bel as a context label to find the LFIB for the primary egress node and the= inner label to deliver the packet to the same destination as the primary egress node according to the LFIB. =  

Note that exactly how the= inner label is sent from the primary egress node to the backup egress node= is out of scope for this document.

 <= /p>

I understand that this is o= ut of scope of this document, but it is still not clear to me how inner lab= el is going to be processed, maintained and programmed. If bgp is used to send the inner label from primary egress node to backup = egress node, how bgp know there is backup egress node? Even this is possibl= e, the egress protection on the rsvp level should make this transparent to = bgp and any other applications using rsvp. If the alternative way you described is used, it seems that rsvp wil= l program a bgp entry in forwarding plane, I don’t think this is desi= red behavior either.

 <= /p>

[Huaimo 2] The inner labe= l is processed by rsvp on the upstream node of the primary egress in a way = similar to the existing way for the intermediate node protection.  For protecting an intermediate node such as node X using facility ba= ckup, the upstream node of the node X will use the label allocated by the n= ext hop node of X as the inner label . For protecting the primary egress no= de, the upstream node of the primary egress will use the label allocated by the primary egress as the inner lab= el . There is an object called EGRESS_BACKUP object, which contains the pri= mary egress IP address and the backup egress IP address. This object will b= e sent to the primary egress by rsvp. At the primary egress, this information can be sent to any protocol,= which is responsible for delivering the inner label as a upstream assigned= label to the backup egress. The rsvp will not program any forwarding entri= es on the backup egress for this inner label as a UA label.

 <= /p>

2) &= nbsp;    How PLR can acquire= a path to backup egress node, its address is the same as primary egress no= de?

[Huaimo] PLR gets the bac= kup egress node first and then computes a path from the PLR to the backup e= gress node. The backup egress node may be configured by an operator on the ingress of the primary LSP. If it is configured, the in= gress will include the backup egress node in the PATH message through using= EGRESS_BACKUP object. If the backup egress node is not given by the operat= or, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP addr= ess as the destination IP address of the LSP.  Note that the primary e= gress node and the backup egress node SHOULD have a same local address conf= igured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local= address on the primary egress node.

 <= /p>

The question is not about k= nowing the backup egress node, it is how to get a route to backup egress no= de given the fact that the backup egress node has the same address of the primary egress node.

 <= /p>

[Huaimo 2] The PLR comput= es a shortest constrained path to that address. Since the cost to that addr= ess from the primary egress node is much bigger, the PLR will get the path to that address through the backup egress node.

 

3) &= nbsp;    Does PLR sends the = PATH message for primary LSP to backup egress node?

[Huaimo] No.

 <= /p>

Then how the state of primary LSP on up= stream node of the primary egress node is maintained after failure occurs?<= o:p>

[Huaimo 2] The upstream n= ode may continue to send the resv message to its upstream node along the pr= imary LSP after the failure of the primary egress.

 <= /p>

Thanks,

Autumn

 <= /span>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_5316A0AB3C851246A7CA5758973207D445C73DE9SJCEML701CHMchi_-- From nobody Tue Jun 10 21:45:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBE91A036B for ; Tue, 10 Jun 2014 21:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaUNutcCb0Jd for ; Tue, 10 Jun 2014 21:45: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 59A541A036A for ; Tue, 10 Jun 2014 21:45:32 -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 BIH27443; Wed, 11 Jun 2014 04:45:31 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 05:45:30 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 12:45:27 +0800 From: Qin Wu To: "mpls@ietf.org" Thread-Topic: Introduction to TIME Mailing List Thread-Index: Ac+Ed/EqiWfsJ33vSgy5XLhDzjJJGgAt93xQ Date: Wed, 11 Jun 2014 04:45:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4-A90enuplhA7oBd97cMKq_7swc Subject: Re: [mpls] Introduction to TIME Mailing List 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, 11 Jun 2014 04:45:35 -0000 --_004_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_" --_000_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RllJLg0KDQq3orz+yMs6IFRpbWUgW21haWx0bzp0aW1lLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g UWluIFd1DQq3osvNyrG85DogMjAxNMTqNtTCMTDI1SAxNDo0OA0KytW8/sjLOiB0aW1lQGlldGYu b3JnDQqzrcvNOiBSb21hc2NhbnUsIERhbiAoRGFuKTsgTWlzaGFlbCBXZXhsZXINCtb3zOI6IFtU aW1lXSBJbnRyb2R1Y3Rpb24gdG8gVElNRSBNYWlsaW5nIExpc3QNCg0KRGVhciBhbGwsDQoNCg0K VGhpcyBpcyB0byBpbnRyb2R1Y2UgdGhlIFRJTUUgbWFpbGluZyBsaXN0LiBUSU1FIHN0YW5kcyBm b3IgobBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIGluIE11bHRpLUxheWVyIE5ldHdvcmsgRW50 aXR5obEgLg0KDQoNClRoaXMgbWFpbGluZyBsaXN0IGlzIG5ld2x5IGNyZWF0ZWQgYXMgYSByZXN1 bHQgb2YgYSBCT0YgcmVxdWVzdCBwcm9wb3NhbCB0byBPUFMgQXJlYSByZWNlbnRseS4gSGVyZSBp cyBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIGluDQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAN CmFuZCB3ZSBhcmUgbG9va2luZyBmb3IgZGlzY3Vzc2lvbiBhbmQgZmVlZGJhY2sgb24gdGhpcyBs aXN0LCBhcyB3ZWxsIGFzIGV4cGVjdGluZyB0byBoYW1tZXIgb3V0IGEgY29uY3JldGUgc2NvcGUg YW5kIGdldCB0aGUgZmlyc3QgdmVyc2lvbiBvZiBkcmFmdA0KY2hhcnRlciBjb21pbmcgb3V0IHRo cm91Z2ggdGhpcyBkaXNjdXNzaW9uIC4NCg0KQmFja2dyb3VuZDoNCg0KICBUaGUgYmFzaWMgY29u Y2VwdHMgb2YgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVuYW5jZSAoT0FN KSBhbmQgdGhlDQogICBmdW5jdGlvbmFsIHJvbGVzIGluIG1vbml0b3JpbmcgYW5kIGRpYWdub3Np bmcgdGhlIGJlaGF2aW9yIG9mIHRlbGVjb21tdW5pY2F0aW9ucyBuZXR3b3Jrcw0KICAgaGF2ZSBi ZWVuIGxvbmcgdGVybSBzdHVkaWVkIGF0IHRoZSBMYXllciAxJjIgJiBMYXllciAzIGxldmVscy4g IFRoZSBjdXJyZW50IHByYWN0aWNlIGlzIHRoYXQNCiAgIG1hbnkgdGVjaG5vbG9naWVzIGFuZCBs YXllcnMgaGF2ZSB0aGVpciBvd24gT0FNIHByb3RvY29scy4gICBUaGVyZSBpcyBsaXR0bGUgb3Ig bm8NCiAgIHJlLXVzZSBvZiBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgZm9yIGVhY2ggZXhpc3Rpbmcg T0FNIHByb3RvY29sLiBWZW5kb3JzIGFuZCBvcGVyYXRvcnMgd2FzdGUNCmEgbG90IHRocm91Z2gg dGhlIHdob2xlIE9BTSBsaWZlLWN5Y2xlIHdoZW4gYSBuZXcgdGVjaG5vbG9neSBpcyBpbnRyb2R1 Y2VkLiBJbnRlZ3JhdGlvbiBvZiBPQU0NCmFjcm9zcyBtdWx0aXBsZSB0ZWNobm9sb2dpZXMgaXMg ZXh0cmVtZWx5IGRpZmZpY3VsdC4gV2hlbiBoYXZpbmcgbmV0d29ya3Mgd2l0aCBtb3JlIHRoYW4g b25lIHRlY2hub2xvZ3ksDQptYWludGVuYW5jZSBhbmQgdHJvdWJsZXNob290aW5nIGFyZSBkb25l IHBlciB0ZWNobm9sb2d5DQogICBhbmQgbGF5ZXIsIG9wZXJhdGlvbiBwcm9jZXNzIGNhbiBiZSB2 ZXJ5IGN1bWJlcnNvbWUuIEluIG1hbnkgY2FzZXMgaXQgaXMgZGVzaXJhYmxlIHRvIGhhdmUgYQ0K ICAgZ2VuZXJpYyBPQU0gdG8gY292ZXIgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nIHRlY2hub2xv Z2llcy4gR2VuZXJpYyBPQU0gdG9vbHMgc2hvdWxkIGJlDQogICBkZXBsb3llZCBvdmVyIHZhcmlv dXMgZW5jYXBzdWxhdGluZyBwcm90b2NvbHMsIGFuZCBpbiB2YXJpb3VzIG1lZGl1bSB0eXBlcy4N Cg0KICAgQW4gZXhhbXBsZSBvZiBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCBhIGdlbmVyaWMgYW5k IGludGVncmF0ZWQgT0FNIHByb3RvY29sIHdvdWxkIGJlDQogICB2YWx1YWJsZSBpcyBTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nLiBBIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgaXMgY29tcG9z ZWQgYnkgYSBzZXJpZXMgb2YNCiAgIHNlcnZpY2UgRnVuY3Rpb25zLCB0aGF0IGNhbiBhY3QgaW4g ZGlmZmVyZW50IGxheWVycyBidXQgcHJvdmlkaW5nIGFuIGVuZC10by1lbmQgY2hhaW4gb3IgcGF0 aA0KICAgZnJvbSBhIHNvdXJjZSB0byBkZXN0aW5hdGlvbiBpbiBhIGdpdmVuIG9yZGVyLiAgSW4g c2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBFbnZpcm9ubWVudCwgaXQgaXMNCiAgIG5lY2Vzc2Fy eSB0byBwcm92aWRlIGVuZCB0byBlbmQgT0FNIGFjcm9zcyBjZXJ0YWluIG9yIGFsbCBlbnRpdGll cyBhbmQgaW52b2x2aW5nIG1hbnkgbGF5ZXJzLg0KICAgT0FNIGluZm9ybWF0aW9uIHNob3VsZCBi ZSBleGNoYW5nZWQgYmV0d2VlbiBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgbGF5ZXJz IHdoaWxlDQogICB1c2luZyB2YXJpb3VzIGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLiAgSW4gc29t ZSBjYXNlcyBPQU0gc2hvdWxkIGNyb3NzIGRpZmZlcmVudA0KICAgYWRtaW5pc3RyYXRpb24gYW5k L29yIG1haW50ZW5hbmNlIGRvbWFpbnMuDQoNClRoZSBwdXJwb3NlIG9mIHRoZSBsaXN0Og0KDQog ICAxLnVuZGVyc3RhbmRpbmcgYW5kIGRpc2N1c3NpbmcgdGhlIHRpbWVzIHdoZW4gYW4gT0FNDQog ICBwcm90b2NvbCBjYW4gYmUgdHVuZWQgYW5kIG9wdGltaXNlZCBmb3IgYSBzcGVjaWZpYyBkYXRh IHBsYW5lIChmb3IgZXhhbXBsZSwgT0FNIGluIGEgcGFja2V0DQogICBuZXR3b3JrIGNhbiBiZSB2 ZXJ5IGRpZmZlcmVudCBmcm9tIE9BTSBpbiBhIGNpcmN1aXQgc3dpdGNoZWQgbmV0d29yayBiZWNh dXNlIG9mIHRoZQ0KICAgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV0d29yaykN Cg0KMi5hbmQgc2Vla2luZyB0aGUgYmVzdCB3YXlzOg0KDQogICAgICAgIE8gRXhjaGFuZ2UgT0FN IGluZm9ybWF0aW9uIGF0IHRoZSBzZXJ2aWNlIGxheWVyIGF0b3Agb2YgbGF5ZXIgMw0KDQpPIEFi c3RyYWN0IE9BTSBpbmZvcm1hdGlvbiBjb21tb24gdG8gZGlmZmVyZW50IGxheWVyDQoNCk8gUHJv dmlkZSB0aGVtIHZpYSB1bmlmaWVkIGludGVyZmFjZSB0byBtYW5hZ2VtZW50IGVudGl0aWVzLg0K DQpPIFNldCB1cCBNYWludGVuYW5jZSBEb21haW5zIChNRCkgYW5kIE1haW50ZW5hbmNlIEludGVy bWVkaWF0ZSBQb2ludHMgKE1JUCkNCg0KTyBFbmFibGUgT0FNIGZ1bmN0aW9uIGF0IGRpZmZlcmVu dCBsYXllciBpbiB0aGUgbXVsdGktbGF5ZXIgbmV0d29yaw0KDQpPIEFjdGl2YXRlIE9BTSBmdW5j dGlvbiBhIGRpZmZlcmVudCBsYXllciBhbmQgcHJvdmlkZSByZXN1bHRzIHRvIG1hbmFnZW1lbnQg ZW50aXR5DQoNClRoaXMgbWFpbGluZyBsaXN0IGlzIGludGVuZGVkIHRvIGVuYWJsZSBkaXNjdXNz aW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUsIHVzZS1jYXNlcy9hcHBsaWNhYmlsaXR5LCBhbmQNCnJl cXVpcmVtZW50cyB0aGF0IHByb3ZpZGUgZ2VuZXJpYyBhbmQgaW50ZWdyYXRlZCBPQU0gY292ZXJp bmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgdGVjaG5vbG9naWVzLg0KDQpPIEFuYWx5 c2UgYW5kIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCBtb3RpdmF0aW9ucyBhbmQgb3Bwb3J0dW5p dGllcyBmb3Igb3B0aW1pc2F0aW9uIG9mIE9BTSBpbiBkaWZmZXJlbnQNCnRlY2hub2xvZ3kgbmV0 d29ya3MsIGFuZCB0aGUgdHJhZGUtb2ZmcyBiZXR3ZWVuIHRob3NlIG9wdGltaXNhdGlvbnMgYW5k IHRoZQ0KIG92ZXJhbGwgYWR2YW50YWdlIG9mIGEgZ2VuZXJpYyBPQU0gbWVjaGFuaXNtLg0KDQpP IFNldCBvdXQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBhcmNoaXRlY3R1cmUgZm9yIHRoZQ0K ICAgICBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIGluIHRoZSBtdWx0aS1sYXllciBuZXR3b3Jr IGFuZCBvdXRsaW5lcyB0aGUgcHJvYmxlbXMNCiAgICAgZW5jb3VudGVyZWQgd2l0aCBleGlzdGlu ZyBPQU0gcHJvdG9jb2wgdmFyaWV0eSBhbmQgdGhlaXIgaW1wYWN0IG9uIGludHJvZHVjdGlvbiBv ZiBuZXcgdGVjaG5vbG9naWVzLg0KDQpZb3UgY2FuIHN1YnNjcmliZSB0byB0aGUgbGlzdCBhdDog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aW1lLg0KDQoNClRvIHBvc3Qg YSBtZXNzYWdlIHRvIGFsbCB0aGUgbGlzdCBtZW1iZXJzLCBzZW5kIGVtYWlsIHRvIHRpbWUgYXQg aWV0Zi5vcmcuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpRaW4mRGFuDQo= --_000_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

FYI.

&n= bsp;

=B7=A2=BC=FE=C8=CB: Time [mailto:time-bounces@ietf.org] =B4=FA=B1=ED = Qin Wu
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA6=D4=C2<= span lang=3D"EN-US">10=C8=D5 14:48
=CA=D5=BC=FE=C8=CB: time@ietf.org
=B3=AD=CB=CD: Romascanu, Dan (Dan); Mishael Wexler
=D6=F7=CC=E2: [Time] Introduction to TIME Mailing List

 

Dear all,

 

 

This is to introduce the TIME m= ailing list. TIME stands for =A1=B0Transport Independent OAM in Multi-Layer= Network Entity=A1=B1 .

 

This mailing list is newly c= reated as a result of a BOF request proposal to OPS Area recently. Here is = an initial description of the problem in

https://datatracker.iet= f.org/doc/draft-ww-opsawg-multi-layer-oam-00

and we are looking for discussi= on and feedback on this list, as well as expecting to hammer out a concrete= scope and get the first version of draft

charter coming out through this= discussion .

 

Background:

 

  The basic concepts of Op= erations, Administration, and Maintenance (OAM) and the

   functional roles i= n monitoring and diagnosing the behavior of telecommunications networks

   have been lon= g term studied at the Layer 1&2 & Layer 3 levels.  The current= practice is that

   many technolo= gies and layers have their own OAM protocols.   There is little o= r no

   re-use of software= and hardware for each existing OAM protocol. Vendors and operators waste

a= lot through the whole OAM life-cycle when a new technology is introduced. = Integration of OAM

a= cross multiple technologies is extremely difficult. When having networks wi= th more than one technology,

m= aintenance and troubleshooting are done per technology

   and layer, operati= on process can be very cumbersome. In many cases it is desirable to have a

   generic OAM t= o cover heterogeneous networking technologies. Generic OAM tools should be<= o:p>

   deployed over vari= ous encapsulating protocols, and in various medium types.=

 

   An example of an e= nvironment in which a generic and integrated OAM protocol would be

   valuable is S= ervice Function Chaining. A Service Function Chaining is composed by a seri= es of

   service Functions,= that can act in different layers but providing an end-to-end chain or path=

   from a source to d= estination in a given order.  In service function chaining Environment= , it is

   necessary to provi= de end to end OAM across certain or all entities and involving many layers.=  

   OAM informati= on should be exchanged between service functions in different layers while

   using various= encapsulating protocols.  In some cases OAM should cross different

   administratio= n and/or maintenance domains.

 

The purpose of the list:

 

   1.understanding an= d discussing the times when an OAM

   protocol can = be tuned and optimised for a specific data plane (for example, OAM in a pac= ket

   network can b= e very different from OAM in a circuit switched network because of the

   different cha= racteristics of the network)

 

2= .and seeking the best ways:

<= o:p> 

      =   O Exchange OAM information at the service layer atop of layer 3

 

O = Abstract OAM information common to different layer

 

O = Provide them via unified interface to management entities.

 

O = Set up Maintenance Domains (MD) and Maintenance Intermediate Points (MIP)

 

O = Enable OAM function at different layer in the multi-layer network

 

O = Activate OAM function a different layer and provide results to management e= ntity

 

This mailing list is intended t= o enable discussion of the architecture, use-cases/applicability, and

requirements that provide gener= ic and integrated OAM covering various heterogeneous network technologies.<= o:p>

 

O = Analyse and understand the different motivations and opportunities for opti= misation of OAM in different

te= chnology networks, and the trade-offs between those optimisations and the

&n= bsp;overall advantage of a generic OAM mechanism.

 

O = Set out the problem statement and architecture for the

     Transp= ort Independent OAM in the multi-layer network and outlines the problems

     encoun= tered with existing OAM protocol variety and their impact on introduction o= f new technologies.

 

You can subscribe to the list a= t: https://www.ietf.org/mailman/listinfo/time.

 

 

To post a message to all the li= st members, send email to time at ietf.org.

 

 

Best Regards,=

 

Qin&Dan

--_000_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_-- --_004_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 10 Jun 2014 07:00:08 GMT"; modification-date="Tue, 10 Jun 2014 07:00:08 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRpbWUgbWFp bGluZyBsaXN0DQpUaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RpbWUNCg== --_004_B8F9A780D330094D99AF023C5877DABA84549D66nkgeml501mbschi_-- From nobody Thu Jun 12 05:39:38 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77B11B29FB; Thu, 12 Jun 2014 05:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXaVatVzyZDh; Thu, 12 Jun 2014 05:39:35 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCB71B29F2; Thu, 12 Jun 2014 05:39:34 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id s5CCdW1F020786; Thu, 12 Jun 2014 21:39:32 +0900 (JST) Received: from mailsv4.nec.co.jp (imss61.nec.co.jp [10.7.69.156]) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) with ESMTP id s5CCdWJ19112; Thu, 12 Jun 2014 21:39:32 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id s5CCdWX7028811; Thu, 12 Jun 2014 21:39:32 +0900 (JST) Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.144] [10.38.151.144]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-224829; Thu, 12 Jun 2014 21:38:50 +0900 Received: from BPXM18GP.gisp.nec.co.jp ([169.254.2.157]) by BPXC16GP.gisp.nec.co.jp ([10.38.151.144]) with mapi id 14.02.0328.011; Thu, 12 Jun 2014 21:38:50 +0900 From: Zhenlong Cui To: "ietf@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPhHutNkgrELnVbkObxDn6WHeuXJttaMCg Date: Thu, 12 Jun 2014 12:38:49 +0000 Message-ID: References: <20140610071412.6466.24044.idtracker@ietfa.amsl.com> In-Reply-To: <20140610071412.6466.24044.idtracker@ietfa.amsl.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.38.126.83] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/8WYMycCjaUkIxkdkFCuFeX1EQU0 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:39:36 -0000 Hi authors, Both 1:n and n:1 are described in your draft. Could you explain "n:1, 1:n, m:n" where it is first used? 1:n protection and m:n protection are defined in G.808.1 and RFC 4427, bu= t I can't find a definition for n:1. Best regards, zhenlong > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org > Sent: Tuesday, June 10, 2014 4:14 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiprotocol Label Switching Working G= roup of the IETF. >=20 > Title : Requirements for MPLS-TP Shared Mesh Protection > Authors : Yaacov Weingarten > Sam Aldrin > Ping Pan > Jeong-dong Ryoo > Greg Mirsky > Filename : draft-ietf-mpls-smp-requirements-06.txt > Pages : 14 > Date : 2014-06-10 >=20 > Abstract: > This document presents the basic network objectives for the behavior > of shared mesh protection (SMP) which are not based on control plane > support. This is an expansion of the basic requirements presented in > RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC > 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". > This document is to be used as a basis for the definition of any > mechanism that would be used to implement SMP for MPLS-TP data paths, > in networks that delegate executive action for resiliency to the data > plane. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-smp-requirements/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-smp-requirements-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-smp-requirements-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available > at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jun 12 06:42:20 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E41B2A30; Thu, 12 Jun 2014 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0N0hNZLQcjE; Thu, 12 Jun 2014 06:42:18 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CA31B2A2A; Thu, 12 Jun 2014 06:42:17 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5CDgDuC012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2014 08:42:14 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5CDg9ap028150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 15:42:12 +0200 Received: from [172.27.221.50] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 12 Jun 2014 15:42:09 +0200 Message-ID: <5399AE30.3020703@alcatel-lucent.com> Date: Thu, 12 Jun 2014 15:42:08 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , , Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ssLSjRkO07kyDwTmgRWKLssN__I Cc: l3vpn-chairs@tools.ietf.org, mpls-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:42:19 -0000 Working Groups, This is to start a 2-week Working Group Last Call in three Working Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. The draft has been made a WG Document by WG Chairs decision. In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs), an optional transitive BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is specified. This BGP attribute uses an octet field to specify the PMSI tunnel type. RFC 6514 allocates the values 0-7. There now is need to make further code point allocations from this name space. In particular, draft-ietf-mpls-seamless-mcast needs to make such an allocation. That draft is currently in WG Last Call in the MPLS Working Group. draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these code points. The registry is created in the "Border Gateway Protocol (BGP) Parameters" registry. Please send comments to the l3vpn mailing list (l3vpn@ietf.org). The WG LC will end on Friday the 27th of June. Martin, on behalf of the WGs co-chairs From nobody Thu Jun 12 07:11:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097981B2A53 for ; Thu, 12 Jun 2014 07:10:51 -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_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 AdGOWNnfgdFt for ; Thu, 12 Jun 2014 07:10:47 -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 AAC2A1B2A4D for ; Thu, 12 Jun 2014 07:10:46 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-36-539964020a3c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.28.27529.20469935; Thu, 12 Jun 2014 10:25:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 10:10:37 -0400 From: Autumn Liu To: Huaimo Chen , Yimin Shen , "Ross Callon" , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSWCEEuEYsttJkWkfWQejQJT9Zs34q2AgAkYsaCAF+H7gIASEs9QgALJw6A= Date: Thu, 12 Jun 2014 14:10:37 +0000 Message-ID: References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C68100@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C73DE9@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C73DE9@SJCEML701-CHM.china.huawei.com> Accept-Language: zh-CN, 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_E4F89EAEF1386F42AA8E6FB5C35399A61C14DE09eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPuC5zysxgg0df2C22Pr3CaHFr6UpW i78rrrBYbF/+jcWBxaPlyFtWjyVLfjJ5XG+6yh7AHMVlk5Kak1mWWqRvl8CVsWbTHJaCqbOY Kh7deMfUwPj5G2MXIyeHhICJxIn101khbDGJC/fWs3UxcnEICRxllGhY+JEJwlnOKPGlYzIT SBWbgJbEvv3v2EESIgITGCVe/rkK5HBwCAuYSWx+bwVSIyJgLnHtwgE2CNtP4tibiWAbWARU JZbe+sMMYvMK+Eqca/4HtW0bm8SKie1gCzgFwiQuL//DDmIzCshKTHt0HyzOLCAucevJfCaI UwUkluw5zwxhi0q8fPwP6gUliUlLz7GC3MMskC+xeUMhxC5BiZMzn7BMYBSZhWTSLISqWUiq IEp0JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHKXFqWW56UYGmxiB8XVMgk13B+Oel5aH GAU4GJV4eB8kzAgWYk0sK67MPcQozcGiJM6rfbMqWEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAPjevYlkv5hq4/kNtht3GyxifEmt7HHhfuLftx4lsIlP9FOQKbV41CK0MqAnADrp7PNIn3e 3hC5ckLpsGzoodabWx9MVW7kkOnnXq3VKL9P11fcb7OL3mePaYVfDaLTxJ0+naz1j9u20r7b qC6yv1Hl8l6d/Yx6R5buYlx9mkHgp1H7SjafWDYlluKMREMt5qLiRAABmIG8kAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/X6f2mxR9RN6D6HS0VpUvO3w3bI4 Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 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, 12 Jun 2014 14:10:51 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C14DE09eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, Thanks for your reply. Please see my comment inline. Autumn From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, May 08, 2014 8:44 PM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, I have some questions. 1) How Inner label (vpn label) acquired on primary egress node is sent= to backup egress node? Via PATH message for backup LSP? which object is us= ed? How this label is processed? How this label is maintained? [Huaimo] An inner label (such as VPN label) allocated on the primary egress= node may be sent to the backup egress node in one of a few ways. One way i= s to use BGP to send the inner label to the backup egress node from the pri= mary egress node. Alternatively, the inner label may be sent from the prima= ry egress node to the upstream node of the primary egress node through an E= GRESS-BACKUP object in RESV message and then the upstream node sends the in= ner label to the backup egress node via an EGRESS-BACKUP object in the PAT= H message for the backup LSP. When the backup egress node receives the inne= r label as a UA label originally from the primary egress, it adds a forward= ing entry with the label into the LFIB for the primary egress node. When th= e backup egress node receives a packet from the backup LSP, it uses the top= label as a context label to find the LFIB for the primary egress node and = the inner label to deliver the packet to the same destination as the primar= y egress node according to the LFIB. Note that exactly how the inner label is sent from the primary egress node = to the backup egress node is out of scope for this document. I understand that this is out of scope of this document, but it is still no= t clear to me how inner label is going to be processed, maintained and prog= rammed. If bgp is used to send the inner label from primary egress node to = backup egress node, how bgp know there is backup egress node? Even this is = possible, the egress protection on the rsvp level should make this transpar= ent to bgp and any other applications using rsvp. If the alternative way yo= u described is used, it seems that rsvp will program a bgp entry in forward= ing plane, I don't think this is desired behavior either. [Huaimo 2] The inner label is processed by rsvp on the upstream node of the= primary egress in a way similar to the existing way for the intermediate n= ode protection. For protecting an intermediate node such as node X using f= acility backup, the upstream node of the node X will use the label allocate= d by the next hop node of X as the inner label . For protecting the primary= egress node, the upstream node of the primary egress will use the label al= located by the primary egress as the inner label . There is an object calle= d EGRESS_BACKUP object, which contains the primary egress IP address and th= e backup egress IP address. This object will be sent to the primary egress = by rsvp. At the primary egress, this information can be sent to any protoco= l, which is responsible for delivering the inner label as a upstream assign= ed label to the backup egress. The rsvp will not program any forwarding ent= ries on the backup egress for this inner label as a UA label. I don't think this is the similar case as the protection on intermediate no= de. Intermediate node would not look at the inner label at all while egress= node would because the outer label is popped on the egress node. If there = is no entry on the forwarding entries, how traffic is going forward from ba= ckup egress node? 2) How PLR can acquire a path to backup egress node, its address is th= e same as primary egress node? [Huaimo] PLR gets the backup egress node first and then computes a path fro= m the PLR to the backup egress node. The backup egress node may be configur= ed by an operator on the ingress of the primary LSP. If it is configured, t= he ingress will include the backup egress node in the PATH message through = using EGRESS_BACKUP object. If the backup egress node is not given by the o= perator, the PLR tries to find the backup egress node, which is not the pri= mary egress node but has the same IP address as the destination IP address = of the LSP. Note that the primary egress node and the backup egress node S= HOULD have a same local address configured, and the cost to the local addre= ss on the backup egress node SHOULD be much bigger than the cost to the loc= al address on the primary egress node. The question is not about knowing the backup egress node, it is how to get = a route to backup egress node given the fact that the backup egress node ha= s the same address of the primary egress node. [Huaimo 2] The PLR computes a shortest constrained path to that address. Si= nce the cost to that address from the primary egress node is much bigger, t= he PLR will get the path to that address through the backup egress node. Why PLR does not choose the path to primary egress node, the cost is not lo= wer? 3) Does PLR sends the PATH message for primary LSP to backup egress no= de? [Huaimo] No. Then how the state of primary LSP on upstream node of the primary egress no= de is maintained after failure occurs? [Huaimo 2] The upstream node may continue to send the resv message to its u= pstream node along the primary LSP after the failure of the primary egress. Which upstream node continues send resv message when primary egress fails? Thanks, Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, May 06, 2014 5:20 AM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_E4F89EAEF1386F42AA8E6FB5C35399A61C14DE09eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,

 

Thanks for your reply. Plea= se see my comment inline.

Autumn

 

From: Autumn L= iu [mailto:autumn.liu@ericsson.c= om]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 

I have some questions.

1= )   &= nbsp;  How Inner label (vpn label) acq= uired on primary egress node is sent to backup egress node? Via PATH messag= e for backup LSP? which object is used? How this label is processed? How this label is maintained?

[Huaimo] An inner label (= such as VPN label) allocated on the primary egress node may be sent to the = backup egress node in one of a few ways. One way is to use BGP to send the inner label to the backup egress node from the primary egr= ess node. Alternatively, the inner label may be sent from the primary egres= s node to the upstream node of the primary egress node through an EGRESS-BA= CKUP object in RESV message and then the upstream node sends the inner label to the backup egress node via=  an EGRESS-BACKUP object in the PATH message for the backup LSP. When= the backup egress node receives the inner label as a UA label originally f= rom the primary egress, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the b= ackup egress node receives a packet from the backup LSP, it uses the top la= bel as a context label to find the LFIB for the primary egress node and the= inner label to deliver the packet to the same destination as the primary egress node according to the LFIB. =  

Note that exactly how the= inner label is sent from the primary egress node to the backup egress node= is out of scope for this document.

 <= /p>

I understand that this is o= ut of scope of this document, but it is still not clear to me how inner lab= el is going to be processed, maintained and programmed. If bgp is used to send the inner label from primary egress node to backup = egress node, how bgp know there is backup egress node? Even this is possibl= e, the egress protection on the rsvp level should make this transparent to = bgp and any other applications using rsvp. If the alternative way you described is used, it seems that rsvp wil= l program a bgp entry in forwarding plane, I don’t think this is desi= red behavior either.

 <= /p>

[Huaimo 2] The inner labe= l is processed by rsvp on the upstream node of the primary egress in a way = similar to the existing way for the intermediate node protection.  For protecting an intermediate node such as node X using facility ba= ckup, the upstream node of the node X will use the label allocated by the n= ext hop node of X as the inner label . For protecting the primary egress no= de, the upstream node of the primary egress will use the label allocated by the primary egress as the inner lab= el . There is an object called EGRESS_BACKUP object, which contains the pri= mary egress IP address and the backup egress IP address. This object will b= e sent to the primary egress by rsvp. At the primary egress, this information can be sent to any protocol,= which is responsible for delivering the inner label as a upstream assigned= label to the backup egress. The rsvp will not program any forwarding entri= es on the backup egress for this inner label as a UA label.

 <= /p>

I don’t think this is= the similar case as the protection on intermediate node. Intermediate node= would not look at the inner label at all while egress node would because the outer label is popped on the egress node. If there is no entry= on the forwarding entries, how traffic is going forward from backup egress= node?

 

2) &= nbsp;    How PLR can acquire= a path to backup egress node, its address is the same as primary egress no= de?

[Huaimo] PLR gets the bac= kup egress node first and then computes a path from the PLR to the backup e= gress node. The backup egress node may be configured by an operator on the ingress of the primary LSP. If it is configured, the in= gress will include the backup egress node in the PATH message through using= EGRESS_BACKUP object. If the backup egress node is not given by the operat= or, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP addr= ess as the destination IP address of the LSP.  Note that the primary e= gress node and the backup egress node SHOULD have a same local address conf= igured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local= address on the primary egress node.

 <= /p>

The question is not about k= nowing the backup egress node, it is how to get a route to backup egress no= de given the fact that the backup egress node has the same address of the primary egress node.

 <= /p>

[Huaimo 2] The PLR comput= es a shortest constrained path to that address. Since the cost to that addr= ess from the primary egress node is much bigger, the PLR will get the path to that address through the backup egress node.

 <= /p>

Why PLR does not choose the= path to primary egress node, the cost is not lower?

 <= /p>

 

3) &= nbsp;    Does PLR sends the = PATH message for primary LSP to backup egress node?

[Huaimo] No.

 <= /p>

Then how the state of primary LSP on up= stream node of the primary egress node is maintained after failure occurs?<= o:p>

[Huaimo 2] The upstream n= ode may continue to send the resv message to its upstream node along the pr= imary LSP after the failure of the primary egress.

 <= /p>

Which upstream node continu= es send resv message when primary egress fails?

 <= /p>

Thanks,

Autumn

 <= /span>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61C14DE09eusaamb103erics_-- From nobody Thu Jun 12 10:01:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211511B27C6; Thu, 12 Jun 2014 10:01: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 0Fzwt5c2vaca; Thu, 12 Jun 2014 10:01:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58CB1B27ED; Thu, 12 Jun 2014 10:01:14 -0700 (PDT) Received: from [172.29.6.121] (66.129.239.13) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 12 Jun 2014 17:01:11 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Date: Thu, 12 Jun 2014 13:00:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5399AE30.3020703@alcatel-lucent.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY2PR04CA060.namprd04.prod.outlook.com (10.141.249.178) To BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02408926C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(51704005)(199002)(189002)(24454002)(377454003)(62966002)(92726001)(74502001)(83072002)(93916002)(86362001)(85852003)(81542001)(19580395003)(4396001)(83322001)(42186004)(19580405001)(81342001)(74662001)(83716003)(66066001)(104166001)(57306001)(46102001)(76482001)(88136002)(79102001)(89996001)(82746002)(77982001)(50226001)(23746002)(80022001)(87286001)(64706001)(87976001)(20776003)(47776003)(99396002)(33656002)(36756003)(50466002)(76176999)(101416001)(50986999)(77156001)(102836001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB721; H:[172.29.6.121]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/9UUISgzKSyJLAa2XAYYzvxFu_5g Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, idr-chairs@tools.ietf.org, l3vpn-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:01:18 -0000 I=92ve read and support publication. =97John On Jun 12, 2014, at 9:42 AM, Martin Vigoureux = wrote: > Working Groups, >=20 > This is to start a 2-week Working Group Last Call in three Working > Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. >=20 > The draft has been made a WG Document by WG Chairs decision. >=20 > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP > VPNs), an optional transitive BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is > specified. This BGP attribute uses an octet field to specify the > PMSI tunnel type. RFC 6514 allocates the values 0-7. >=20 > There now is need to make further code point allocations from this > name space. In particular, draft-ietf-mpls-seamless-mcast > needs to make such an allocation. That draft is currently in WG Last > Call in the MPLS Working Group. >=20 > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called = "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for = these code points. > The registry is created in the "Border Gateway Protocol (BGP) > Parameters" registry. >=20 > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). >=20 > The WG LC will end on Friday the 27th of June. >=20 >=20 > Martin, on behalf of the WGs co-chairs From nobody Thu Jun 12 14:03:37 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19481A02C4; Thu, 12 Jun 2014 14:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 MITb_HF6rH4Q; Thu, 12 Jun 2014 14:03:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 74E901A028B; Thu, 12 Jun 2014 14:03:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 146ED180095; Thu, 12 Jun 2014 14:02:37 -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: <20140612210237.146ED180095@rfc-editor.org> Date: Thu, 12 Jun 2014 14:02:37 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dhHSKw1kLdebZq8eHH7XXKV_7A0 Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7271 on MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators 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, 12 Jun 2014 21:03:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7271 Title: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators Author: J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne Status: Standards Track Stream: IETF Date: June 2014 Mailbox: ryoo@etri.re.kr, eric.gray@ericsson.com, huub.van.helvoort@huawei.com, alessandro.dalessandro@telecomitalia.it, cts@etri.re.kr, eric.osborne@notcom.com Pages: 40 Characters: 87586 Updates: RFC 6378 I-D Tag: draft-ietf-mpls-tp-psc-itu-04.txt URL: http://www.rfc-editor.org/rfc/rfc7271.txt This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. 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 Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 12 14:04:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496641B2839; Thu, 12 Jun 2014 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 aIRPpJvSLxfj; Thu, 12 Jun 2014 14:03:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id AAD571A0276; Thu, 12 Jun 2014 14:03:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77C4918000E; Thu, 12 Jun 2014 14:02:57 -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: <20140612210257.77C4918000E@rfc-editor.org> Date: Thu, 12 Jun 2014 14:02:57 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/gN1P8Z6Wx_5Fa6vIIfFRsm2CUx0 Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7274 on Allocating and Retiring Special-Purpose MPLS Labels 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, 12 Jun 2014 21:03:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7274 Title: Allocating and Retiring Special-Purpose MPLS Labels Author: K. Kompella, L. Andersson, A. Farrel Status: Standards Track Stream: IETF Date: June 2014 Mailbox: kireeti.kompella@gmail.com, loa@mail01.huawei.com, adrian@olddog.co.uk Pages: 11 Characters: 23442 Updates: RFC 3032, RFC 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 5921, RFC 5960, RFC 6391, RFC 6478, RFC 6790 I-D Tag: draft-ietf-mpls-special-purpose-labels-06.txt URL: http://www.rfc-editor.org/rfc/rfc7274.txt Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document. As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for. This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry. This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790. 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 Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 12 17:36:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7488C1A0640 for ; Thu, 12 Jun 2014 17:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FJFDgMcOO8y for ; Thu, 12 Jun 2014 17:36:24 -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 105631A03A7 for ; Thu, 12 Jun 2014 17:36:23 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-1c-5399f4306741 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.03.11744.034F9935; Thu, 12 Jun 2014 20:40:49 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 20:36:16 -0400 From: Gregory Mirsky To: "stbryant@cisco.com" , Eric Gray , "draft-bryant-mpls-oam-udp-return@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-bryant-mpls-oam-udp-return Thread-Index: AQHPU+saEJtSSVJZq0yj4ZIvBeRSWJsJgiEAgEInKQCAAFwCQIABVWGA///Pf7CAAIuugIABAHwAgAAZX4CAAAgEAIAAGD+AgAHBszCAEKkoAIANOM/w Date: Fri, 13 Jun 2014 00:36:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7CDDF9@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> <537F66C3.4070203@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> <2845723087023D4CB5114223779FA9C8017992C1F2@njfpsrvexg8.research.att.com> <7347100B5761DC41A166AC17F22DF1121B7C2C04@eusaamb103.ericsson.se> <538EF4EE.7000809@cisco.com> In-Reply-To: <538EF4EE.7000809@cisco.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+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn67hl5nBBh+2M1pM+vaG2eLW0pWs FueezmF0YPaY8nsjq8eSJT+ZPL5c/swWwBzFZZOSmpNZllqkb5fAlTGx7xFrwV37inX3LzM3 MLbpdjFyckgImEi8+jCHCcIWk7hwbz1bFyMXh5DAUUaJvp0/mCGc5YwSM1rvMYJUsQkYSbzY 2MMOkhAR2MUoMWn1LKAWDg5mAWWJU3dlQGqEBRwkls99xAxiiwg4SnxYcI4Vor6JUWLf4wPs IAkWAVWJrl8rWEB6eQV8Jea+9IBY9pJV4vDKE6wgNZwCmhJ3ZrSCLWYEOu/7qTVgpzILiEvc ejIf6mwBiSV7zjND2KISLx//Y4WwlSQmLT3HClGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZ wCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCPDTYzA6Dkmwea4g3HBJ8tDjAIcjEo8vAmb ZgYLsSaWFVfmHmKU5mBREufdc60qWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjv0Ieq3CQ tP/lg9lH6lOFZkUX7U2MjLj4Kf2hY8WKR7M69MU0DcNDlk7V2qvosMMtfuY7y9aqmnccqmf+ txczFUn4pK1xUhYpmLgmONjpwCUOKY7Q1/u4hTtqbMJEJZaun/yI9/fWXsNVKVHxKs73Qpst hc8qLKv66mRT9WFvr/6CKw/fXVFiKc5INNRiLipOBABYyGwbfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/x_vybodf1lexQP7HmxftwLj_OsI Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 00:36:26 -0000 Hi Stewart, apologize for delayed response. I still believe that though defining new TLV that includes both IP address = and port number is doable it is not the best approach to control MPLS PM se= ssions. RFC 6374 requires control of each and every test/query packet thus = making some tests impossible to execute (e.g. SLM with smaller packet sizes= when TLVs has to be used to provide explicit control). I believe that exte= nding RFC 6374 with Session Control and Data Fetch commands may be reasonab= le alternative to controlling each test packet explicitly through TLVs. True, I don't have document that describes the alternative approach at this= time but would appreciate it be considered and welcome opportunity to disc= uss it in any format. Regards, Greg -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Wednesday, June 04, 2014 3:29 AM To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray; draft-bryant-mpls-oam= -udp-return@tools.ietf.org Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return On 25/05/2014 01:14, Gregory Mirsky wrote: > Dear Al, > thank you for your analysis of the draft and its correlation with the LMA= P framework. > I think that the RFC 6374 gives option for the responder, Measurement Pee= r (MP) in LMAP framework terminology, to send measurement result to an arbi= trary destination, not only to the Querier, Measurement Agent (MA). Yes it does, although as written not to multiple collectors. Do you need th= at? If so I would need to use a modified TLV with the both the address and = the port since the port will be address dependent. - Stewart > Though such scenario is not considered for MP in the LMAP framework, I = believe we can still refer to that node as Data Collector because MA instru= cted MP perhaps based on information received from the Measurement Controll= er. > During our discussion Stewart asked if there could be case of multiple Da= ta Collectors for the given Measurement Task. That is when I referred to th= e LMAP framework as I believe that it allows to associate multiple Data Co= llectors with the Measurement Task. Is my understanding correct? > > Regards, > Greg > > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Friday, May 23, 2014 10:14 AM > To: Eric Gray; stbryant@cisco.com; Gregory Mirsky;=20 > draft-bryant-mpls-oam-udp-return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > Eric, Stewart, > > It seems to me (after scanning the draft) that the MPLS-PLDM could be tre= ated as the out-of-scope measurement traffic/protocol in the LMAP Framework= Figure 1 below (Where IPPM is currently used as the out-of-scope example): > > ^ > | > Active +-------------+ IPPM > +---------------+ Measurement | Measurement | Scope > | Measurement |<------------>| Peer | | > | Agent | Traffic +-------------+ v > +------->| | ^ > | +---------------+ | > | ^ | | > | Instruction | | Report | > | | +-----------------+ | > | | | | > | | v LMAP > | +------------+ +------------+ Scope > | | Controller | | Collector | | > | +------------+ +------------+ v > | ^ ^ | ^ > | | | | | > | | +----------+ | | > | | | v | > +------------+ +----------+ +--------+ +----------+ | > |Bootstrapper| |Subscriber|--->| data |<---|repository| Out > +------------+ |parameter | |analysis| +----------+ of > |database | | tools | Scope > +----------+ +--------+ | > | > > The MPLS-PLDM Querier could be co-located with a Measurement Agent, and a= ssuming the Querier performs all the coordination, including arranging to r= eturn the response message to a port co-located with the same Measurement A= gent (or configuration takes the role of signaling), then the MPLS-PLDM res= ponder could be treated as a Measurement Peer. The LMAP Control and Report= protocols provision and collect results from the Querier, taking the role = of a "management system" mentioned in the draft. > > hope this helps, > Al > > > > >> -----Original Message----- >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> Sent: Friday, May 23, 2014 11:47 AM >> To: stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-udp-=20 >> return@tools.ietf.org >> Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org >> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> >> Stewart, >> >> I understand your point. But the question is not whether or not it=20 >> will work, but rather whether or not there is consensus to do it this=20 >> way. >> >> On any given day, it is trivial to come up with any number of=20 >> approaches for doing something (whatever that something is) that will=20 >> _work_ - which is not the same as saying that we should all pour=20 >> energy into any of those ideas. >> >> I also understand the pressures associated with customer=20 >> requirements, but don't see why the customer(s) behind your=20 >> requirements should have the last word on which approach should be=20 >> used - based solely on those requirements. >> >> That approach leads to a point-solution that has a definite non-zero=20 >> cost. As a general approach, the continuous generation of point=20 >> solutions has its own scaling issues. >> >> It is my hope that someone will have the energy to put together a=20 >> draft to propose an alternative based on LMAP. I personally do not=20 >> have either the energy or the bandwidth. In fact, I don't have the=20 >> bandwidth or the energy to continue in >> this discussion. I sincerely hope and intend this will be my last post >> on this topic. >> >> If there is insufficient interest in developing the scaled-down=20 >> version of an LMAP-based proposal - either within the MPLS working=20 >> group, or among the LMAP framework authors - before the Toronto=20 >> meeting, or there is not a number of like objections raised on the=20 >> MPLS mailing list, then it would seem that the WG default consensus=20 >> is to proceed with your draft. >> >> Believe it or not, I personally can live with that. >> >> -- >> Eric >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Friday, May 23, 2014 11:18 AM >> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-=20 >> return@tools.ietf.org >> Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org >> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> Importance: High >> >> Eric >> >> I think the onus is on you as the objector to provide me with a=20 >> pointer to a specific protocol alternative not a framework, or to=20 >> show why this simple addition of four bytes will not work in the manner = that I describe. >> >> Stewart > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From nobody Thu Jun 12 18:13:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B541A00DF; Thu, 12 Jun 2014 18:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 069X6-YAE_wF; Thu, 12 Jun 2014 18:13:18 -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 889A81B280D; Thu, 12 Jun 2014 18:13:14 -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 BIJ17509; Fri, 13 Jun 2014 01:13:12 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 02:13:11 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 09:13:08 +0800 From: Mach Chen To: Martin Vigoureux , "l3vpn@ietf.org" , "mpls@ietf.org" , "idr@ietf.org" Thread-Topic: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 Thread-Index: AQHPhkQs3nxgXepTRUq4bppM42Rv/JtuPDHQ Date: Fri, 13 Jun 2014 01:13:07 +0000 Message-ID: References: <5399AE30.3020703@alcatel-lucent.com> In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/__crWfFMDBMjAnV6zZYe2LTu4M0 Cc: "l3vpn-chairs@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "idr-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 01:13:20 -0000 I have read the short, clean and useful draft, and I support to publish thi= s document. Best regards, Mach > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Thursday, June 12, 2014 9:42 PM > To: l3vpn@ietf.org; mpls@ietf.org; idr@ietf.org > Cc: l3vpn-chairs@tools.ietf.org; mpls-chairs@tools.ietf.org; > idr-chairs@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 >=20 > Working Groups, >=20 > This is to start a 2-week Working Group Last Call in three Working Groups= (idr, > l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. >=20 > The draft has been made a WG Document by WG Chairs decision. >=20 > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VP= Ns), > an optional transitive BGP attribute called the "P-Multicast Service Inte= rface > Tunnel (PMSI Tunnel) attribute" is specified. This BGP attribute uses an= octet > field to specify the PMSI tunnel type. RFC 6514 allocates the values 0-7= . >=20 > There now is need to make further code point allocations from this name s= pace. > In particular, draft-ietf-mpls-seamless-mcast needs to make such an alloc= ation. > That draft is currently in WG Last Call in the MPLS Working Group. >=20 > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-Mult= icast > Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these code point= s. > The registry is created in the "Border Gateway Protocol (BGP) Parameters" > registry. >=20 > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). >=20 > The WG LC will end on Friday the 27th of June. >=20 >=20 > Martin, on behalf of the WGs co-chairs >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jun 12 18:14:29 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056FF1B2815; Thu, 12 Jun 2014 18:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgGRSOhab0oh; Thu, 12 Jun 2014 18:14:22 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2447F1A00DF; Thu, 12 Jun 2014 18:14:22 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 13 Jun 2014 10:14:15 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Fri, 13 Jun 2014 10:14:17 +0900 From: Jeong Ryoo To: Zhenlong Cui , "ietf@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPhHuwKsEsUoX+VU2zuiKoviH3D5ts1q2AgAFfhFk= Date: Fri, 13 Jun 2014 01:14:16 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28744EF6@SMTP2.etri.info> References: <20140610071412.6466.24044.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28744EF6SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/D-9MxBMRpA7HZ5b-pR_wx8-sCPc Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 01:14:26 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28744EF6SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBaaGVubG9uZywNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudC4NCm46MSBpcyBtZWFudCB0 byBiZSBhIHNwZWNpYWwgY2FzZSBvZiBtOm4sIHdoZXJlIG0gcHJvdGVjdGlvbiBwYXRocyBhcmUg cHJlcGFyZWQgdG8gcHJvdGVjdCBuIHdvcmtpbmcgcGF0aHMsDQphbmQgbWF5IGJlIGV4cHJlc3Nl ZCBiZXR0ZXIgaWYgbToxIGlzIHVzZWQgaW5zdGVhZC4NCkluIG15IG9waW5pb24sIHRoZSBuZXh0 IHZlcnNpb24gb2YgdGhpcyBkcmFmdCBuZWVkcyB0byBpbmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRz Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCuuztOuCuCDsgqzrnowgOiAiWmhlbmxvbmcgQ3VpIiA8Yy1zYWlA YnguanAubmVjLmNvbT4NCuuztOuCuCDrgqDsp5wgOiAyMDE0LTA2LTEyIDIxOjQwOjAyICggKzA5 OjAwICkNCuuwm+uKlCDsgqzrnowgOiBpZXRmQGlldGYub3JnIDxpZXRmQGlldGYub3JnPg0K7LC4 7KGwIDogbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4NCuygnOuqqSA6IFJlOiBbbXBsc10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0DQoNCkhp IGF1dGhvcnMsDQoNCkJvdGggMTpuIGFuZCBuOjEgYXJlIGRlc2NyaWJlZCBpbiB5b3VyIGRyYWZ0 Lg0KDQpDb3VsZCB5b3UgZXhwbGFpbiAibjoxLCAxOm4sIG06biIgd2hlcmUgaXQgaXMgZmlyc3Qg dXNlZD8NCjE6biBwcm90ZWN0aW9uIGFuZCBtOm4gcHJvdGVjdGlvbiBhcmUgZGVmaW5lZCBpbiBH LjgwOC4xIGFuZCBSRkMgNDQyNywgYnV0IEkgY2FuJ3QgZmluZCBhIGRlZmluaXRpb24gZm9yIG46 MS4NCg0KQmVzdCByZWdhcmRzLA0KemhlbmxvbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAs IDIwMTQgNDoxNCBQTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBtcGxzQGll dGYub3JnDQo+IFN1YmplY3Q6IFttcGxzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1wbHMtc21w LXJlcXVpcmVtZW50cy0wNi50eHQNCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRj aGluZyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPiBUaXRsZSA6IFJlcXVpcmVtZW50 cyBmb3IgTVBMUy1UUCBTaGFyZWQgTWVzaCBQcm90ZWN0aW9uDQo+IEF1dGhvcnMgOiBZYWFjb3Yg V2VpbmdhcnRlbg0KPiBTYW0gQWxkcmluDQo+IFBpbmcgUGFuDQo+IEplb25nLWRvbmcgUnlvbw0K PiBHcmVnIE1pcnNreQ0KPiBGaWxlbmFtZSA6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1l bnRzLTA2LnR4dA0KPiBQYWdlcyA6IDE0DQo+IERhdGUgOiAyMDE0LTA2LTEwDQo+DQo+IEFic3Ry YWN0Og0KPiBUaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBiYXNpYyBuZXR3b3JrIG9iamVjdGl2 ZXMgZm9yIHRoZSBiZWhhdmlvcg0KPiBvZiBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uIChTTVApIHdo aWNoIGFyZSBub3QgYmFzZWQgb24gY29udHJvbCBwbGFuZQ0KPiBzdXBwb3J0LiBUaGlzIGlzIGFu IGV4cGFuc2lvbiBvZiB0aGUgYmFzaWMgcmVxdWlyZW1lbnRzIHByZXNlbnRlZCBpbg0KPiBSRkMg NTY1NCAiUmVxdWlyZW1lbnRzIGZvciB0aGUgVHJhbnNwb3J0IFByb2ZpbGUgb2YgTVBMUyIgYW5k IFJGQw0KPiA2MzcyICJNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBTdXJ2aXZhYmls aXR5IEZyYW1ld29yayIuDQo+IFRoaXMgZG9jdW1lbnQgaXMgdG8gYmUgdXNlZCBhcyBhIGJhc2lz IGZvciB0aGUgZGVmaW5pdGlvbiBvZiBhbnkNCj4gbWVjaGFuaXNtIHRoYXQgd291bGQgYmUgdXNl ZCB0byBpbXBsZW1lbnQgU01QIGZvciBNUExTLVRQIGRhdGEgcGF0aHMsDQo+IGluIG5ldHdvcmtz IHRoYXQgZGVsZWdhdGUgZXhlY3V0aXZlIGFjdGlvbiBmb3IgcmVzaWxpZW5jeSB0byB0aGUgZGF0 YQ0KPiBwbGFuZS4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLw0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYNCj4NCj4gQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNg0KPg0KPg0KPiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUNCj4gYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0 DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28744EF6SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIw cHQiPkRlYXIgWmhlbmxvbmcsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+ Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+VGhhbmtzIGZvciB0 aGUgY29tbWVudC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij5uOjEgaXMg bWVhbnQgdG8gYmUgYSBzcGVjaWFsIGNhc2Ugb2YgbTpuLCB3aGVyZSBtIHByb3RlY3Rpb24gcGF0 aHMgYXJlIHByZXBhcmVkIHRvIHByb3RlY3QgbiB3b3JraW5nIHBhdGhzLDwvZGl2Pg0KPGRpdiBz dHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPmFuZCBtYXkgYmUgZXhwcmVzc2VkIGJldHRlciBpZiBt OjEgaXMgdXNlZCBpbnN0ZWFkLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQi PkluIG15IG9waW5pb24sIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhpcyBkcmFmdCBuZWVkcyB0byBp bmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDIwcHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPkJlc3Qg cmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij4mbmJzcDs8L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2 IHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+PGJyPg0KPGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2 IGlkPSJNYWlsU2lnblNlbnQiIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+PGJyPg0KPC9kaXY+ DQo8ZGl2IGlkPSJPUkdNQUlMX0NPTlRFTlQiIHN0eWxlPSJMSU5FLUhFSUdIVDogMjBwdCI+DQo8 aHIgdGFiaW5kZXg9Ii0xIj4NCjxiPuuztOuCuCDsgqzrnowgOiA8L2I+JnF1b3Q7Wmhlbmxvbmcg Q3VpJnF1b3Q7ICZsdDtjLXNhaUBieC5qcC5uZWMuY29tJmd0Ozxicj4NCjxiPuuztOuCuCDrgqDs p5wgOiA8L2I+MjAxNC0wNi0xMiAyMTo0MDowMiAoICYjNDM7MDk6MDAgKTxicj4NCjxiPuuwm+uK lCDsgqzrnowgOiA8L2I+aWV0ZkBpZXRmLm9yZyAmbHQ7aWV0ZkBpZXRmLm9yZyZndDs8YnI+DQo8 Yj7ssLjsobAgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj7soJzrqqkgOiA8L2I+UmU6IFttcGxzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1wbHMtc21w LXJlcXVpcmVtZW50cy0wNi50eHQ8YnI+DQo8YnI+DQpIaSBhdXRob3JzLDxicj4NCjxicj4NCkJv dGggMTpuIGFuZCBuOjEgYXJlIGRlc2NyaWJlZCBpbiB5b3VyIGRyYWZ0Ljxicj4NCjxicj4NCkNv dWxkIHlvdSBleHBsYWluICZxdW90O246MSwgMTpuLCBtOm4mcXVvdDsgd2hlcmUgaXQgaXMgZmly c3QgdXNlZD88YnI+DQoxOm4gcHJvdGVjdGlvbiBhbmQgbTpuIHByb3RlY3Rpb24gYXJlIGRlZmlu ZWQgaW4gRy44MDguMSBhbmQgUkZDIDQ0MjcsIGJ1dCBJIGNhbid0IGZpbmQgYSBkZWZpbml0aW9u IGZvciBuOjEuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCnpoZW5sb25nPGJyPg0KPGJy Pg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogbXBscyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxicj4NCiZndDsgU2VudDogVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA0OjE0IFBN PGJyPg0KJmd0OyBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPGJyPg0KJmd0OyBDYzogbXBsc0Bp ZXRmLm9yZzxicj4NCiZndDsgU3ViamVjdDogW21wbHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt bXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQomZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlIDogUmVxdWlyZW1lbnRzIGZv ciBNUExTLVRQIFNoYXJlZCBNZXNoIFByb3RlY3Rpb248YnI+DQomZ3Q7IEF1dGhvcnMgOiBZYWFj b3YgV2VpbmdhcnRlbjxicj4NCiZndDsgU2FtIEFsZHJpbjxicj4NCiZndDsgUGluZyBQYW48YnI+ DQomZ3Q7IEplb25nLWRvbmcgUnlvbzxicj4NCiZndDsgR3JlZyBNaXJza3k8YnI+DQomZ3Q7IEZp bGVuYW1lIDogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0PGJyPg0KJmd0 OyBQYWdlcyA6IDE0PGJyPg0KJmd0OyBEYXRlIDogMjAxNC0wNi0xMDxicj4NCiZndDsgPGJyPg0K Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7IFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgdGhlIGJhc2lj IG5ldHdvcmsgb2JqZWN0aXZlcyBmb3IgdGhlIGJlaGF2aW9yPGJyPg0KJmd0OyBvZiBzaGFyZWQg bWVzaCBwcm90ZWN0aW9uIChTTVApIHdoaWNoIGFyZSBub3QgYmFzZWQgb24gY29udHJvbCBwbGFu ZTxicj4NCiZndDsgc3VwcG9ydC4gVGhpcyBpcyBhbiBleHBhbnNpb24gb2YgdGhlIGJhc2ljIHJl cXVpcmVtZW50cyBwcmVzZW50ZWQgaW48YnI+DQomZ3Q7IFJGQyA1NjU0ICZxdW90O1JlcXVpcmVt ZW50cyBmb3IgdGhlIFRyYW5zcG9ydCBQcm9maWxlIG9mIE1QTFMmcXVvdDsgYW5kIFJGQzxicj4N CiZndDsgNjM3MiAmcXVvdDtNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBTdXJ2aXZh YmlsaXR5IEZyYW1ld29yayZxdW90Oy48YnI+DQomZ3Q7IFRoaXMgZG9jdW1lbnQgaXMgdG8gYmUg dXNlZCBhcyBhIGJhc2lzIGZvciB0aGUgZGVmaW5pdGlvbiBvZiBhbnk8YnI+DQomZ3Q7IG1lY2hh bmlzbSB0aGF0IHdvdWxkIGJlIHVzZWQgdG8gaW1wbGVtZW50IFNNUCBmb3IgTVBMUy1UUCBkYXRh IHBhdGhzLDxicj4NCiZndDsgaW4gbmV0d29ya3MgdGhhdCBkZWxlZ2F0ZSBleGVjdXRpdmUgYWN0 aW9uIGZvciByZXNpbGllbmN5IHRvIHRoZSBkYXRhPGJyPg0KJmd0OyBwbGFuZS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLzxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7 IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1l bnRzLTA2PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlPGJyPg0KJmd0OyBhdCB0b29scy5pZXRmLm9y Zy48YnI+DQomZ3Q7IDxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy88YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyBtcGxzQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9y Zzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28744EF6SMTP2etriinfo_-- From nobody Thu Jun 12 21:59:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6F21B28C4; Thu, 12 Jun 2014 21:58:44 -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 CsPCfgQHJpdz; Thu, 12 Jun 2014 21:58:39 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045111B28C3; Thu, 12 Jun 2014 21:58:38 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so2805559qac.32 for ; Thu, 12 Jun 2014 21:58:38 -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=GlVnlc7vS4UaCPT5AJxqCaPoyf+CkdGlvTxSXZUx10w=; b=tr6QzFSX8rvCG+ncTK5lLw+yZwZouduqHqfdWtO8mO97wXi+BaQ2zL7BJsx8m5GqDc 0WEVW1O5lAysLJhVDJx5Enb7XFFiPKTCZ3gPbkzojdzUtns7dZSs2yOdvLmP6XD4Rv90 25Rgktk8OQaKuPOwB6rWhhEbiDaxcOk9RQph+dJHp60M/VKCPD9DoRjPSq4WWJ35SUBa rE3pmWSpR9huW4Q7KK+6DVmtuNZIz+aag/ySoKsKqnHRP+AyWtspGbincPQ1riK295kR cf0PEBoFGoTrljL5LuKZ78wcWoumHHDi6yCbPFry3wTHZUN43rEQ6TcTzyGeGXAWiIfe jWlA== X-Received: by 10.229.87.201 with SMTP id x9mr433914qcl.20.1402635518141; Thu, 12 Jun 2014 21:58:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Thu, 12 Jun 2014 21:58:18 -0700 (PDT) In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> References: <5399AE30.3020703@alcatel-lucent.com> From: "Andrew G. Malis" Date: Fri, 13 Jun 2014 00:58:18 -0400 Message-ID: To: Martin Vigoureux Content-Type: multipart/alternative; boundary=001a11337b7acf0d9704fbb08799 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vnZKT3fcM67v3RdeTGp4rNiipAk Cc: "mpls@ietf.org" , L3VPN list , idr@ietf.org, idr-chairs@tools.ietf.org, l3vpn-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:58:44 -0000 --001a11337b7acf0d9704fbb08799 Content-Type: text/plain; charset=UTF-8 This draft has one of this highest usefulness vs. length ratios I've ever seen. I very much support publication. My only comment is that there's an obvious typo in section 3, "secirity". Cheers, Andy On Thu, Jun 12, 2014 at 9:42 AM, Martin Vigoureux < martin.vigoureux@alcatel-lucent.com> wrote: > Working Groups, > > This is to start a 2-week Working Group Last Call in three Working > Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. > > The draft has been made a WG Document by WG Chairs decision. > > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP > VPNs), an optional transitive BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is > specified. This BGP attribute uses an octet field to specify the > PMSI tunnel type. RFC 6514 allocates the values 0-7. > > There now is need to make further code point allocations from this > name space. In particular, draft-ietf-mpls-seamless-mcast > needs to make such an allocation. That draft is currently in WG Last > Call in the MPLS Working Group. > > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called > "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these > code points. > The registry is created in the "Border Gateway Protocol (BGP) > Parameters" registry. > > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). > > The WG LC will end on Friday the 27th of June. > > > Martin, on behalf of the WGs co-chairs > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11337b7acf0d9704fbb08799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft has one of this highest usefulness vs. length r= atios I've ever seen. I very much support publication. My only comment = is that there's an obvious typo in section 3, "secirity".

Cheers,
Andy


On Thu, Jun 12, 2014 at 9:42 AM, Martin = Vigoureux <martin.vigoureux@alcatel-lucent.com> wrote:
Working Groups,

This is to start a 2-week Working Group Last Call in three Working
Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02.
The draft has been made a WG Document by WG Chairs decision.

In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs), an optional transitive BGP attribute called the
"P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is=
specified. =C2=A0This BGP attribute uses an octet field to specify the
PMSI tunnel type. =C2=A0RFC 6514 allocates the values 0-7.

There now is need to make further code point allocations from this
name space. =C2=A0In particular, draft-ietf-mpls-seamless-mcast
needs to make such an allocation. That draft is currently in WG Last
Call in the MPLS Working Group.

draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-M= ulticast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for thes= e code points.
The registry is created in the "Border Gateway Protocol (BGP)
Parameters" registry.

Please send comments to the l3vpn mailing list (l3vpn@ietf.org).

The WG LC will end on Friday the 27th of June.


Martin, on behalf of the WGs co-chairs

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

--001a11337b7acf0d9704fbb08799-- From nobody Thu Jun 12 22:27:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FDF1B28D6 for ; Thu, 12 Jun 2014 22:27: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 sEaS3C32URlF for ; Thu, 12 Jun 2014 22:26:59 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D5F1B28D5 for ; Thu, 12 Jun 2014 22:26:59 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id x12so2851869qac.21 for ; Thu, 12 Jun 2014 22:26: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:from:date:message-id:subject:to :cc:content-type; bh=SudbFStiOO235RTvRIOKIY/a+wviX9CjTyx4BulH2XY=; b=slRTRqo0KxNbjloIwGYbjwYfNqZk/EJ3fQTet4S5C5Yz6iViBujIgV/Ov4amn1BNPj cgOSK+Bl1Lu+6/NpyRl1LPk+1Rg1WA2xvcbbxwpWQu3HHLMfbPomsf0gldRIjLwSDOXO eOle5LtKwmdw7Yu73FPdqfkoNa/7/NLOhfTZsNaNChtlE5Y0qQR28vWcB89SnI5WSJwC cvh8st/8nPMkGAI9FEX6oWZojrUyhqup2iNe4h9nLFllMaDJTL4alDZBW5BLvpF/9IVr 6wle5acq9YaiQsTVvidCNAELlWh2fmTEyGxfKHgqqr29vcysEUDodhoytcOAQrJWG22W 8jvw== X-Received: by 10.224.119.198 with SMTP id a6mr438586qar.39.1402637218674; Thu, 12 Jun 2014 22:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Thu, 12 Jun 2014 22:26:38 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7CDDF9@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B79D6DE@eusaamb103.ericsson.se> <534535F8.6090408@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632A54011@eusaamb107.ericsson.se> <537CC24A.2020803@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0A12@eusaamb103.ericsson.se> <537E2DD7.4020901@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C0FCE@eusaamb103.ericsson.se> <537E7A53.50707@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1052@eusaamb107.ericsson.se> <537F66C3.4070203@cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AC1249@eusaamb107.ericsson.se> <2845723087023D4CB5114223779FA9C8017992C1F2@njfpsrvexg8.research.att.com> <7347100B5761DC41A166AC17F22DF1121B7C2C04@eusaamb103.ericsson.se> <538EF4EE.7000809@cisco.com> <7347100B5761DC41A166AC17F22DF1121B7CDDF9@eusaamb103.ericsson.se> From: "Andrew G. Malis" Date: Fri, 13 Jun 2014 01:26:38 -0400 Message-ID: To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a11c2e6e02afd1404fbb0ed34 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/aM79UYU50cfGbUgk5nl2C979cYs Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 05:27:02 -0000 --001a11c2e6e02afd1404fbb0ed34 Content-Type: text/plain; charset=UTF-8 Greg, I have to admit to not really having read the draft until I saw this discussion, which got me curious to see what all of the fuss was about. So I went and read RFC 6374 and this draft, and also 4656. Given the existence and presumed implementations of 6374, my intuition is that this draft is a small addition to 6374 to fix a case that that had escaped the authors at that time. I would bet that if the Return UDP Port object had originally been included in 6374 to complement the Return Address object, no one would have batted an eyelash. Thus, I have no objection to this draft. The time to have discussed a different approach was during the formation of RFC 6374, not now. Trying to switch to an approach like RFC 4656 now is an extremely heavyweight fix to a very small problem. Cheers, Andy On Thu, Jun 12, 2014 at 8:36 PM, Gregory Mirsky wrote: > Hi Stewart, > apologize for delayed response. > I still believe that though defining new TLV that includes both IP address > and port number is doable it is not the best approach to control MPLS PM > sessions. RFC 6374 requires control of each and every test/query packet > thus making some tests impossible to execute (e.g. SLM with smaller packet > sizes when TLVs has to be used to provide explicit control). I believe that > extending RFC 6374 with Session Control and Data Fetch commands may be > reasonable alternative to controlling each test packet explicitly through > TLVs. > True, I don't have document that describes the alternative approach at > this time but would appreciate it be considered and welcome opportunity to > discuss it in any format. > > Regards, > Greg > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, June 04, 2014 3:29 AM > To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray; > draft-bryant-mpls-oam-udp-return@tools.ietf.org > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > On 25/05/2014 01:14, Gregory Mirsky wrote: > > Dear Al, > > thank you for your analysis of the draft and its correlation with the > LMAP framework. > > I think that the RFC 6374 gives option for the responder, Measurement > Peer (MP) in LMAP framework terminology, to send measurement result to an > arbitrary destination, not only to the Querier, Measurement Agent (MA). > Yes it does, although as written not to multiple collectors. Do you need > that? If so I would need to use a modified TLV with the both the address > and the port since the port will be address dependent. > > - Stewart > > Though such scenario is not considered for MP in the LMAP framework, I > believe we can still refer to that node as Data Collector because MA > instructed MP perhaps based on information received from the Measurement > Controller. > > During our discussion Stewart asked if there could be case of multiple > Data Collectors for the given Measurement Task. That is when I referred to > the LMAP framework as I believe that it allows to associate multiple Data > Collectors with the Measurement Task. Is my understanding correct? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Friday, May 23, 2014 10:14 AM > > To: Eric Gray; stbryant@cisco.com; Gregory Mirsky; > > draft-bryant-mpls-oam-udp-return@tools.ietf.org > > Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > > Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return > > > > Eric, Stewart, > > > > It seems to me (after scanning the draft) that the MPLS-PLDM could be > treated as the out-of-scope measurement traffic/protocol in the LMAP > Framework Figure 1 below (Where IPPM is currently used as the out-of-scope > example): > > > > ^ > > | > > Active +-------------+ IPPM > > +---------------+ Measurement | Measurement | Scope > > | Measurement |<------------>| Peer | | > > | Agent | Traffic +-------------+ v > > +------->| | ^ > > | +---------------+ | > > | ^ | | > > | Instruction | | Report | > > | | +-----------------+ | > > | | | | > > | | v LMAP > > | +------------+ +------------+ Scope > > | | Controller | | Collector | | > > | +------------+ +------------+ v > > | ^ ^ | ^ > > | | | | | > > | | +----------+ | | > > | | | v | > > +------------+ +----------+ +--------+ +----------+ | > > |Bootstrapper| |Subscriber|--->| data |<---|repository| Out > > +------------+ |parameter | |analysis| +----------+ of > > |database | | tools | Scope > > +----------+ +--------+ | > > | > > > > The MPLS-PLDM Querier could be co-located with a Measurement Agent, and > assuming the Querier performs all the coordination, including arranging to > return the response message to a port co-located with the same Measurement > Agent (or configuration takes the role of signaling), then the MPLS-PLDM > responder could be treated as a Measurement Peer. The LMAP Control and > Report protocols provision and collect results from the Querier, taking the > role of a "management system" mentioned in the draft. > > > > hope this helps, > > Al > > > > > > > > > >> -----Original Message----- > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> Sent: Friday, May 23, 2014 11:47 AM > >> To: stbryant@cisco.com; Gregory Mirsky; draft-bryant-mpls-oam-udp- > >> return@tools.ietf.org > >> Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > >> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return > >> > >> Stewart, > >> > >> I understand your point. But the question is not whether or not it > >> will work, but rather whether or not there is consensus to do it this > >> way. > >> > >> On any given day, it is trivial to come up with any number of > >> approaches for doing something (whatever that something is) that will > >> _work_ - which is not the same as saying that we should all pour > >> energy into any of those ideas. > >> > >> I also understand the pressures associated with customer > >> requirements, but don't see why the customer(s) behind your > >> requirements should have the last word on which approach should be > >> used - based solely on those requirements. > >> > >> That approach leads to a point-solution that has a definite > non-zero > >> cost. As a general approach, the continuous generation of point > >> solutions has its own scaling issues. > >> > >> It is my hope that someone will have the energy to put together a > >> draft to propose an alternative based on LMAP. I personally do not > >> have either the energy or the bandwidth. In fact, I don't have the > >> bandwidth or the energy to continue in > >> this discussion. I sincerely hope and intend this will be my last post > >> on this topic. > >> > >> If there is insufficient interest in developing the scaled-down > >> version of an LMAP-based proposal - either within the MPLS working > >> group, or among the LMAP framework authors - before the Toronto > >> meeting, or there is not a number of like objections raised on the > >> MPLS mailing list, then it would seem that the WG default consensus > >> is to proceed with your draft. > >> > >> Believe it or not, I personally can live with that. > >> > >> -- > >> Eric > >> > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] > >> Sent: Friday, May 23, 2014 11:18 AM > >> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp- > >> return@tools.ietf.org > >> Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ietf.org > >> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return > >> Importance: High > >> > >> Eric > >> > >> I think the onus is on you as the objector to provide me with a > >> pointer to a specific protocol alternative not a framework, or to > >> show why this simple addition of four bytes will not work in the manner > that I describe. > >> > >> Stewart > > . > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a11c2e6e02afd1404fbb0ed34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greg,

I have to admit to not really hav= ing read the draft until I saw this discussion, which got me curious to see= what all of the fuss was about. So I went and read RFC 6374 and this draft= , and also=C2=A04656.

Given the existence and presumed implementations of 6374, my in= tuition is that this draft is a small addition to 6374 to fix a case that t= hat had escaped the authors at that time. I would bet that if the Return UD= P Port object had originally been included in 6374 to complement the Return= Address object, no one would have batted an eyelash.=C2=A0

Thus, I have no objection to this draft. The time to ha= ve discussed a different approach was during the formation of RFC 6374, not= now. Trying to switch to an approach like RFC 4656 now is an extremely hea= vyweight fix to a very small problem.

Cheers,
Andy


On Thu, Jun 12, 2014 at 8:36 PM, G= regory Mirsky <gregory.mirsky@ericsson.com> wrote:=
Hi Stewart,
apologize for delayed response.
I still believe that though defining new TLV that includes both IP address = and port number is doable it is not the best approach to control MPLS PM se= ssions. RFC 6374 requires control of each and every test/query packet thus = making some tests impossible to execute (e.g. SLM with smaller packet sizes= when TLVs has to be used to provide explicit control). I believe that exte= nding RFC 6374 with Session Control and Data Fetch commands may be reasonab= le alternative to controlling each test packet explicitly through TLVs.
True, I don't have document that describes the alternative approach at = this time but would appreciate it be considered and welcome opportunity to = discuss it in any format.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg

-----Original Message-----
From: Stewart Bryant [mailto:stbryant= @cisco.com]
Sent: Wednesday, June 04, 2014 3:29 AM
To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray; draft-bryant-mpls-oam-udp-ret= urn@tools.ietf.org
Cc: mpls@ietf.org; draft-ietf-lmap-framework@tools.ie= tf.org
Subject: Re: [mpls] Comments = on draft-bryant-mpls-oam-udp-return

On 25/05/2014 01:14, Gregory Mirsky wrote:
> Dear Al,
> thank you for your analysis of the draft and its correlation with the = LMAP framework.
> I think that the RFC 6374 gives option for the responder, Measurement = Peer (MP) in LMAP framework terminology, to send measurement result to an a= rbitrary destination, not only to the Querier, Measurement Agent (MA).
Yes it does, although as written not to multiple collectors. Do you need th= at? If so I would need to use a modified TLV with the both the address and = the port since the port will be address dependent.

- Stewart
> =C2=A0 Though such scenario is not considered for MP in the LMAP frame= work, I believe we can still refer to that node as Data Collector because M= A instructed MP perhaps based on information received from the Measurement = Controller.
> During our discussion Stewart asked if there could be case of multiple= Data Collectors for the given Measurement Task. That is when I referred to= the LMAP framework as I believe that it allows to associate =C2=A0multiple= Data Collectors with the Measurement Task. Is my understanding correct? >
> =C2=A0 =C2=A0 =C2=A0 Regards,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg
>
> -----Original Message-----
> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
> Sent: Friday, May 23, 2014 10:14 AM
> To: Eric Gray; stbryant@cisco.co= m; Gregory Mirsky;
> dra= ft-bryant-mpls-oam-udp-return@tools.ietf.org
> Cc: mpls@ietf.org; draft-ietf-lmap-framework@too= ls.ietf.org
> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>
> Eric, Stewart,
>
> It seems to me (after scanning the draft) that the MPLS-PLDM could be = treated as the out-of-scope measurement traffic/protocol in the LMAP Framew= ork Figure 1 below (Where IPPM is currently used as the out-of-scope exampl= e):
>
> =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 =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 =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 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Active =C2=A0 =C2=A0+-----= --------+ =C2=A0 =C2=A0IPPM
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+ =C2= =A0Measurement | Measurement | =C2=A0 =C2=A0Scope
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Measurement =C2=A0 |= <------------>| =C2=A0 =C2=A0 Peer =C2=A0 =C2=A0| =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Agent =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 Traffic =C2=A0 =C2=A0+-------------+ =C2=A0 =C2=A0v<= br> > =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 =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 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> =C2=A0 =C2=A0 | =C2=A0Instruction | =C2=A0 =C2=A0 =C2=A0| =C2=A0Report= =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 =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 =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 =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=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LMAP<= br> > =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=A0S= cope
> =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Controller | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Collector | =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=A0v=
> =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 =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 =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 =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| =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> +------------+ =C2=A0 +----------+ =C2=A0 =C2=A0+--------+ =C2=A0 =C2= =A0+----------+ =C2=A0 |
> |Bootstrapper| =C2=A0 |Subscriber|--->| =C2=A0data =C2=A0|<---|r= epository| =C2=A0 Out
> +------------+ =C2=A0 |parameter | =C2=A0 =C2=A0|analysis| =C2=A0 =C2= =A0+----------+ =C2=A0 of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |databa= se =C2=A0| =C2=A0 =C2=A0| tools =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Scope
> =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 =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 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
>
> The MPLS-PLDM Querier could be co-located with a Measurement Agent, an= d assuming the Querier performs all the coordination, including arranging t= o return the response message to a port co-located with the same Measuremen= t Agent (or configuration takes the role of signaling), then the MPLS-PLDM = responder could be treated as a Measurement Peer. =C2=A0The LMAP Control an= d Report protocols provision and collect results from the Querier, taking t= he role of a "management system" mentioned in the draft.
>
> hope this helps,
> Al
>
>
>
>
>> -----Original Message-----
>> From: Eric Gray [mailto:= eric.gray@ericsson.com]
>> Sent: Friday, May 23, 2014 11:47 AM
>> To: stbryant@cisco.com; = Gregory Mirsky; draft-bryant-mpls-oam-udp-
>> return@tools.ietf.org=
>> Cc: mpls@ietf.org; draft-ietf-lmap-framework= @tools.ietf.org
>> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return >>
>> Stewart,
>>
>> =C2=A0 =C2=A0 =C2=A0I understand your point. =C2=A0But the questio= n is not whether or not it
>> will work, but rather whether or not there is consensus to do it t= his
>> way.
>>
>> =C2=A0 =C2=A0 =C2=A0On any given day, it is trivial to come up wit= h any number of
>> approaches for doing something (whatever that something is) that w= ill
>> _work_ - which is not the same as saying that we should all pour >> energy into any of those ideas.
>>
>> =C2=A0 =C2=A0 =C2=A0I also understand the pressures associated wit= h customer
>> requirements, but don't see why the customer(s) behind your >> requirements should have the last word on which approach should be=
>> used - based solely on those requirements.
>>
>> =C2=A0 =C2=A0 =C2=A0That approach leads to a point-solution that h= as a definite non-zero
>> cost. =C2=A0As a general approach, the continuous generation of po= int
>> solutions has its own scaling issues.
>>
>> =C2=A0 =C2=A0 =C2=A0It is my hope that someone will have the energ= y to put together a
>> draft to propose an alternative based on LMAP. =C2=A0I personally = do not
>> have either the energy or the bandwidth. =C2=A0In fact, I don'= t have the
>> bandwidth or the energy to continue in
>> this discussion. =C2=A0 I sincerely hope and intend this will be m= y last post
>> on this topic.
>>
>> =C2=A0 =C2=A0 =C2=A0If there is insufficient interest in developin= g the scaled-down
>> version of an LMAP-based proposal - either within the MPLS working=
>> group, or among the LMAP framework authors - before the Toronto >> meeting, or there is not a number of like objections raised on the=
>> MPLS mailing list, then it would seem that the WG default consensu= s
>> is to proceed with your draft.
>>
>> =C2=A0 =C2=A0 =C2=A0Believe it or not, I personally can live with = that.
>>
>> --
>> Eric
>>
>> -----Original Message-----
>> From: Stewart Bryant [mailto:stbryant@cisco.com]
>> Sent: Friday, May 23, 2014 11:18 AM
>> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-
>> return@tools.ietf.org=
>> Cc: mpls@ietf.org; draft-ietf-lmap-framework= @tools.ietf.org
>> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return >> Importance: High
>>
>> Eric
>>
>> I think the onus is on you as the objector to provide me with a >> pointer to a specific protocol alternative not a framework, or to<= br> >> show why this simple addition of four bytes will not work in the m= anner that I describe.
>>
>> Stewart
> .
>


--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html

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

--001a11c2e6e02afd1404fbb0ed34-- From nobody Fri Jun 13 06:00:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CC61B2851; Fri, 13 Jun 2014 06:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3r-GQSQr299; Fri, 13 Jun 2014 06:00:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19761B2824; Fri, 13 Jun 2014 06:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=97; q=dns/txt; s=iport; t=1402664438; x=1403874038; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=k5NnVrvzabAvkf6lLkKlOb3GKHbYzHsems7sExM1gVo=; b=CeyjFmS/+1KZKULZIljfLMfhtQWr9vHw3ZCVsWbUZ6t8Nx5+tCFwkP6h F+89F0PHauu5UqFml799Z/PSZ6GcCIQu0SKeFFRa3FXhEmRGM1yV+NCA2 YjEc9JRIcNgvQ6tYBEHQqPBSPhGjIbediv9qgFZE6456KnoIX07tDbON/ 0=; X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="332904166" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 13 Jun 2014 13:00:37 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5DD0bvj023603; Fri, 13 Jun 2014 13:00:37 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id BD3C048E; Fri, 13 Jun 2014 09:00:36 -0400 (EDT) From: Eric Rosen To: Martin Vigoureux In-reply-to: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> Date: Fri, 13 Jun 2014 09:00:36 -0400 Message-ID: <10585.1402664436@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/L6Ydp19kY0j9WbJnIW-K5XCUQlk Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, idr-chairs@tools.ietf.org, l3vpn-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:00:39 -0000 I support this document; however, I think it should be categorized as an Update to RFC 6514. From nobody Fri Jun 13 06:55:08 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358B61B2878; Fri, 13 Jun 2014 06:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM32bTFRKGfo; Fri, 13 Jun 2014 06:54:58 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00851A03ED; Fri, 13 Jun 2014 06:54:57 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5DDssmV011366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jun 2014 08:54:55 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5DDssF7022971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 15:54:54 +0200 Received: from [172.27.205.128] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 13 Jun 2014 15:54:53 +0200 Message-ID: <539B02AD.4010309@alcatel-lucent.com> Date: Fri, 13 Jun 2014 15:54:53 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Susan Hares , References: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> <10585.1402664436@erosen-lnx> <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> In-Reply-To: <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/48ogRjbSIU5_ii5Buan6fx0pY64 Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, l3vpn-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:55:00 -0000 Sue, I guess what Eric says is that if it effectively does, then this should be indicated in the header and mentioned in the Abstract/intro. -m Le 13/06/2014 15:49, Susan Hares a crit : > Eric: > > It relates and it updates the IANA section in RFC6514. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen > Sent: Friday, June 13, 2014 9:01 AM > To: Martin Vigoureux > Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org; idr-chairs@tools.ietf.org; > l3vpn-chairs@tools.ietf.org; rtg-ads@tools.ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 > > > I support this document; however, I think it should be categorized as an > Update to RFC 6514. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > From nobody Fri Jun 13 07:32:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809151B2A46; Thu, 12 Jun 2014 07:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 WSvt83IYVzwN; Thu, 12 Jun 2014 07:54:54 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8056C1B2A76; Thu, 12 Jun 2014 07:54:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.96; From: "Susan Hares" To: "'Martin Vigoureux'" , , , References: <5399AE30.3020703@alcatel-lucent.com> In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Date: Thu, 12 Jun 2014 10:54:47 -0400 Message-ID: <009b01cf864e$41ddcde0$c59969a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIS5sn81JJr+QPqDf2XZ37ngvLYSJrmzmAQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Y5bx0OT5tO2d6HFX1jh8sh6LjII X-Mailman-Approved-At: Fri, 13 Jun 2014 07:32:29 -0700 Cc: l3vpn-chairs@tools.ietf.org, mpls-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:54:55 -0000 Support publication. It tells IANA what to do appropriately. Idr chair + L3VPN participant. -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] Sent: Thursday, June 12, 2014 9:42 AM To: l3vpn@ietf.org; mpls@ietf.org; idr@ietf.org Cc: rtg-ads@tools.ietf.org; l3vpn-chairs@tools.ietf.org; mpls-chairs@tools.ietf.org; idr-chairs@tools.ietf.org Subject: WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 Working Groups, This is to start a 2-week Working Group Last Call in three Working Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. The draft has been made a WG Document by WG Chairs decision. In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs), an optional transitive BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is specified. This BGP attribute uses an octet field to specify the PMSI tunnel type. RFC 6514 allocates the values 0-7. There now is need to make further code point allocations from this name space. In particular, draft-ietf-mpls-seamless-mcast needs to make such an allocation. That draft is currently in WG Last Call in the MPLS Working Group. draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for these code points. The registry is created in the "Border Gateway Protocol (BGP) Parameters" registry. Please send comments to the l3vpn mailing list (l3vpn@ietf.org). The WG LC will end on Friday the 27th of June. Martin, on behalf of the WGs co-chairs From nobody Fri Jun 13 07:33:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FA81B2917; Fri, 13 Jun 2014 06:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 xgh0mmrwQq5W; Fri, 13 Jun 2014 06:49:49 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0C1B2919; Fri, 13 Jun 2014 06:49:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: , "'Martin Vigoureux'" References: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> <10585.1402664436@erosen-lnx> In-Reply-To: <10585.1402664436@erosen-lnx> Date: Fri, 13 Jun 2014 09:49:37 -0400 Message-ID: <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDytTMtdGzXD/fNBDUUmShwPcvpCZ0osY0A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/rq7ySfELf2-bPsy2j9C245oRPmw X-Mailman-Approved-At: Fri, 13 Jun 2014 07:33:02 -0700 Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, l3vpn-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:49:51 -0000 Eric: It relates and it updates the IANA section in RFC6514. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen Sent: Friday, June 13, 2014 9:01 AM To: Martin Vigoureux Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org; idr-chairs@tools.ietf.org; l3vpn-chairs@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 I support this document; however, I think it should be categorized as an Update to RFC 6514. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jun 13 07:33:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0061A00FB; Fri, 13 Jun 2014 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 zdP07HPogsiQ; Fri, 13 Jun 2014 07:09:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30A1B2869; Fri, 13 Jun 2014 07:09:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Martin Vigoureux'" , References: Your message of Thu, 12 Jun 2014 15:42:08 +0200. <5399AE30.3020703@alcatel-lucent.com> <10585.1402664436@erosen-lnx> <009101cf870e$5200a6a0$f601f3e0$@ndzh.com> <539B02AD.4010309@alcatel-lucent.com> In-Reply-To: <539B02AD.4010309@alcatel-lucent.com> Date: Fri, 13 Jun 2014 10:09:35 -0400 Message-ID: <009301cf8711$1bf97200$53ec5600$@ndzh.com> 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: AQIS5sn81JJr+QPqDf2XZ37ngvLYSADytTMtAlZsivcDFXmWNJq1X0YQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/JtJweNjks_bwbV3hsn0GHqDy_0c X-Mailman-Approved-At: Fri, 13 Jun 2014 07:33:02 -0700 Cc: mpls@ietf.org, l3vpn@ietf.org, idr@ietf.org, l3vpn-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] [Idr] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:09:43 -0000 Martin: Agreed. I was trying to do a +1 to Eric's suggestion without using it since +1 is now politically incorrect (PI).=20 Sue -----Original Message----- From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com]=20 Sent: Friday, June 13, 2014 9:55 AM To: Susan Hares; erosen@cisco.com Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org; = idr-chairs@tools.ietf.org; l3vpn-chairs@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org Subject: Re: [Idr] [mpls] WG Last Call on = draft-ietf-l3vpn-pmsi-registry-02 Sue, I guess what Eric says is that if it effectively does, then this should = be indicated in the header and mentioned in the Abstract/intro. -m Le 13/06/2014 15:49, Susan Hares a =E9crit : > Eric: > > It relates and it updates the IANA section in RFC6514. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Eric Rosen > Sent: Friday, June 13, 2014 9:01 AM > To: Martin Vigoureux > Cc: mpls@ietf.org; l3vpn@ietf.org; idr@ietf.org;=20 > idr-chairs@tools.ietf.org; l3vpn-chairs@tools.ietf.org;=20 > rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [Idr] [mpls] WG Last Call on=20 > draft-ietf-l3vpn-pmsi-registry-02 > > > I support this document; however, I think it should be categorized as=20 > an Update to RFC 6514. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > From nobody Fri Jun 13 14:15:03 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98301B27F3 for ; Fri, 13 Jun 2014 14:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDhbM1S7EHyp for ; Fri, 13 Jun 2014 14:14:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031841A025A for ; Fri, 13 Jun 2014 14:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3068; q=dns/txt; s=iport; t=1402694085; x=1403903685; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BWCh9V/6mQaY6SW5CUXG1Qvg/kZCy/V3LG7CWpn+gEY=; b=ghARTtKjd6SQ2F2ybNtLBMPGRgdw1xk/4RoJCATG1GTGspzh/sd3XpqW WR9KKnbvvp4+fcudVusUscOu9ZckAAem5HEmyIZt1HtzvikDc2DqB/yHk i7EjHWEsqvJSvT0jN777Rh9XcbsprPAETPyhyyqf72LHhgLD1YPmWxl1p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFACxpm1OtJA2I/2dsb2JhbABagmkkUlmCbMAgARltFnWEAwEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIOQEMsnmfGReBKo0EOAaCbzaBFgSbepIUgz6CMA X-IronPort-AV: E=Sophos;i="5.01,473,1400025600"; d="scan'208";a="329903603" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jun 2014 21:14:44 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5DLEiCh006224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Jun 2014 21:14:44 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 16:14:44 -0500 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsA Date: Fri, 13 Jun 2014 21:14:43 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> In-Reply-To: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4xgiizUgesqP57uxHKqgFZlijwg Subject: [mpls] FW: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:14:54 -0000 RGVhciBNUExTIFdHLA0KDQpPbiBNUExTIGRhdGEgcGxhbmUsIG9uZSBhc3BlY3Qgd2hpY2ggT0FN IGlzIGJsaW5kIHRvIHRyYWZmaWMgYmxhY2sgaG9saW5nIGlzIHdoZW4gTFNQcyBhcmUgdHJhdmVy c2luZyBvdmVyIExBRyBpbnRlcmZhY2VzLiBXZSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgYW4gZXh0 ZW5zaW9uIHRvIFJGQzQzNzkgdG8gcHJvdmlkZSB0aGUgdG9vbCBhbiBhYmlsaXR5IHRvIGRpc2Nv dmVyIGFuZCB0cmF2ZXJzZSBMQUcgbWVtYmVycy4NCg0KSXQgd2lsbCBiZSB2ZXJ5IGhlbHBmdWwg aWYgeW91IGNvdWxkIHJldmlldyB0aGlzIGRvY3VtZW50LCBwcm92aWRlIGNvbW1lbnRzIGFuZCBo ZWxwIHVzIHN0YW5kYXJkaXplIHRoaXMgZXh0ZW5zaW9uLg0KDQpUaGFua3MhDQoNCi1Ob2JvLCBv biBiZWhhbGYgb2YgYXV0aG9ycw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10NCj4gU2VudDogRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDU6MDQgUE0NCj4gVG86IEpvaG4g RS4gRHJha2U7IE5vYm8gQWtpeWEgKG5vYm8pOyBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk7IEdl b3JnZQ0KPiBTd2FsbG93IChzd2FsbG93KTsgQnJ1bm8gRGVjcmFlbmU7IFN0ZXBoYW5lIExpdGtv d3NraTsgQnJ1bm8gRGVjcmFlbmU7DQo+IE5vYm8gQWtpeWEgKG5vYm8pOyBKb2huIERyYWtlOyBT dGVwaGFuZSBMaXRrb3dza2kNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLWxhZy0NCj4gbXVsdGlwYXRoLTAwLnR4dA0KPiAN Cj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ha2l5YS1tcGxzLWxzcC1waW5nLWxh Zy1tdWx0aXBhdGgtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Tm9ibyBBa2l5YSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBO YW1lOgkJZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoDQo+IFJldmlzaW9u OgkwMA0KPiBUaXRsZToJCUxhYmVsIFN3aXRjaGVkIFBhdGggKExTUCkgUGluZy9UcmFjZSBNdWx0 aXBhdGggU3VwcG9ydCBmb3INCj4gTGluayBBZ2dyZWdhdGlvbiBHcm91cCAoTEFHKSBJbnRlcmZh Y2VzDQo+IERvY3VtZW50IGRhdGU6CTIwMTQtMDYtMTMNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6CQkxOA0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy0NCj4gbGFnLW11 bHRpcGF0aC0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLW1wbHMtbHNwLXBpbmctbGFnLQ0KPiBtdWx0aXBhdGgvDQo+ IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ha2l5YS1t cGxzLWxzcC1waW5nLWxhZy0NCj4gbXVsdGlwYXRoLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIE11bHRpcHJvdG9j b2wgTGFiZWwNCj4gICAgU3dpdGNoaW5nIChNUExTKSBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1Ap IFBpbmcgYW5kIFRyYWNlcm91dGUgdG8NCj4gICAgZGVzY3JpYmUgTXVsdGlwYXRoIEluZm9ybWF0 aW9uIGZvciBMaW5rIEFnZ3JlZ2F0aW9uIChMQUcpIG1lbWJlcg0KPiAgICBsaW5rcyBzZXBhcmF0 ZWx5LCB0aHVzIGFsbG93aW5nIE1QTFMgTFNQIFBpbmcgYW5kIFRyYWNlcm91dGUgdG8NCj4gICAg ZGlzY292ZXIgYW5kIGV4ZXJjaXNlIHNwZWNpZmljIHBhdGhzIG9mIGxheWVyIDIgRXF1YWwtQ29z dCBNdWx0aXBhdGgNCj4gICAgKEVDTVApIG92ZXIgTEFHIGludGVyZmFjZXMuDQo+IA0KPiAgICBU aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNDM3OSBhbmQgUkZDNjQyNC4NCj4gDQo+IA0KPiANCj4g DQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jun 13 23:26:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2651B2B7A for ; Fri, 13 Jun 2014 23:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBda9uh1xxYG for ; Fri, 13 Jun 2014 23:26:14 -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 53A101B2B77 for ; Fri, 13 Jun 2014 23:26:14 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F318918015A1 for ; Sat, 14 Jun 2014 08:26:11 +0200 (CEST) Message-ID: <539BEAFB.8020907@pi.nu> Date: Sat, 14 Jun 2014 08:26:03 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <20140613161232.7221.35693.idtracker@ietfa.amsl.com> In-Reply-To: <20140613161232.7221.35693.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140613161232.7221.35693.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XVdSafz86gn7DVqf7FhXhitXNOU Subject: [mpls] Fwd: third call: NomCom 2014-2015 Call for Volunteers 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, 14 Jun 2014 06:26:16 -0000 Working Group, Please consider volunteering for NomCom. /Loa -------- Original Message -------- Subject: third call: NomCom 2014-2015 Call for Volunteers Date: Fri, 13 Jun 2014 09:12:32 -0700 From: NomCom Chair 2014 Reply-To: ietf@ietf.org, nomcom-chair-2014@ietf.org To: IETF Announcement List This is the third call for volunteers. VOLUNTEER NOW: we need to make 200. The DEADLINE is June 26 to volunteer. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). If your name is on the below, then you have volunteered and are qualified. In addition to those who volunteered by email, it also includes those who indicated their willingness to serve on the IETF90 registration form, and whose eligibility has been confirmed. 54 people were confirmed to be eligible, and 70 people were not confirmed based upon the email they have used to register. Those 124 people have been contacted directly. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 123 volunteers so far, and WE NEED TO HAVE 200!!! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: Your Full Name: __________-- Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ [] Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Ari Ker?nen Benson Schliesser Bhumip Khasnabish Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel Charles Perkins Christer Holmberg Craig White DHRUV DHODY Dacheng Zhang Damien Saucez Dapeng Liu Dean Bogdanovic Dimitri Papadimitriou Donald Eastlake Edward Crabbe Emil Ivov Eric Rescorla Eric VYNCKE Fangwei Hu Fatai Zhang Fernando Gont Fred Baker Giles Heron Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Hosnieh Rafiee Hugo Salgado Hui Deng Iuniana Oprescu Jeff Tantsura John Drake John Jason Brzozowski John Levine John Scudder Jon Hudson Jon Mitchell Karen O'Donoghue Karen Seo Kaveh Ranjbar Klaas Wierenga Larry Masinter Lars Eggert Lee Howard Lei Zhu Li Xue Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Lynch Lucy Yong Luigi Iannone Mach Chen Marcelo Bagnulo Mark Townsley Matt Lepinski Matthew Bocci Mehmet Ersue Melinda Shore Michael Jones Min Ye Mingui Zhang Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Lothberg Peter Yee QIN WU Ralph Droms Ron Bonica Ross Callon Ross Finlayson Russ White Sam K. Aldrin Samuel Weiler Sandeep Kumar Sanjay Mishra Scott Mansfield Sheng JIANG Shucheng Liu Simon Pietro Romano Stan Ratliff Stephan Friedl Stephan Wenger Stephen Kent Stewart Bryant Stig Venaas Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Walsh Tim Wicinski Tissa Senevirathne Toerless Eckert Tony Hansen Ulrich Herberg Varun Singh Wassim Haddad Xiaohu XU Yi Zhao Yizhou Li Yong Cui Yuanlong Jiang Yunfei Zhang Zhaohui Zhang Zhen Cao iuniana oprescu From nobody Sun Jun 15 15:53:04 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167FF1B2810; Sun, 15 Jun 2014 15:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDoEP4Tz-bGh; Sun, 15 Jun 2014 15:52:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F21A0289; Sun, 15 Jun 2014 15:52:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140615225259.22994.20172.idtracker@ietfa.amsl.com> Date: Sun, 15 Jun 2014 15:52:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dxf6qgKMhieX7CF3fFstL_1p6t8 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-id-mib-05.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: Sun, 15 Jun 2014 22:53:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB) Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-mpls-tp-oam-id-mib-05.txt Pages : 28 Date : 2014-06-15 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-id-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-oam-id-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-oam-id-mib-05 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 Mon Jun 16 09:37:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58C1A010F for ; Mon, 16 Jun 2014 09:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4HwxnebkTlm for ; Mon, 16 Jun 2014 09:37:06 -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 718871A00DA for ; Mon, 16 Jun 2014 09:37:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM46877; Mon, 16 Jun 2014 16:37:03 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Jun 2014 17:37:02 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.232]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 09:36:49 -0700 From: Huaimo Chen To: "Nobo Akiya (nobo)" , Gregory Mirsky , Yimin Shen , "mpls@ietf.org" Thread-Topic: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 Thread-Index: AQHPiAcqanZlS0+Fi06hpXsnzIjRVJtzMFiAgAClx5A= Date: Mon, 16 Jun 2014 16:36:48 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C74B9A@SJCEML701-CHM.china.huawei.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B773138@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7761F4@eusaamb103.ericsson.se> <75e6f9b9bfd44105a725a98d11e1f968@BY2PR05MB728.namprd05.prod.outlook.com>, <7347100B5761DC41A166AC17F22DF1121B776557@eusaamb103.ericsson.se> <104CBCDD-6440-453E-A224-3FAF4BE75F04@juniper.net> <7347100B5761DC41A166AC17F22DF1121B777091@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C4917F@SJCEML701-CHM.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B7775DE@eusaamb103.ericsson.se> <8E4F5326-58DC-4F16-95A2-F9D6C87DAFF7@juniper.net> <7347100B5761DC41A166AC17F22DF1121B77784D@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C66964@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C7496C@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.194] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6eLHeLhbGXJVIfQC2CIzDbcesC4 Cc: Raveendra Torvi , mengnan 58534 , "Boris.Zhang@telus.com" , "Toy, Mehmet" , "ningso01@gmail.com" , lizhenbin 00147097 , Alia Atlas , Ross Callon , "'Xu, Fengman'" , Quintin zhao Subject: Re: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 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, 16 Jun 2014 16:37:08 -0000 Hi Nobo, Thanks much for your suggestions and comments! It seems that 3.3 "Source Detects Failure" with some changes/enhancemen= ts works for protecting the primary ingress failure of a P2P LSP. 3.3 "Source Detects Failure" may be updated as follows: Source Detects Failure or Source-Detect means that the source is responsible for detecting the failure of the primary ingress of an LSP quickly. The backup ingress is ready to import the traffic from the source into the backup LSP after the backup LSP is up. In normal operations, the source sends the traffic to the primary ingress. When the source detects the failure of the primary ingress, it switches the traffic to the backup ingress, which delivers the traffic to the next hops of the primary ingress through the backup LSP, where the traffic is merged into the primary LSP. After the failure of the primary ingress happens and the backup=20 ingress determines the failure, the backup ingress sends/refreshes=20 PATH messages to the next hop node of the primary ingress of a P2P=20 LSP through the backup LSP as needed. The failure can be determined reliably through checking the Link State Database (LSDB). Best Regards, Huaimo -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Sunday, June 15, 2014 6:03 PM To: Huaimo Chen; Gregory Mirsky; Yimin Shen Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; To= y, Mehmet; LEI LIU; ningno@yahoo.com; Ning So; lizhenbin 00147097; Quintin = zhao; Richard Li Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 Hi Huaimo, > Thanks for your comments! Thanks for responding! Please see in-line. > I believe 3.3 is the only one that works well. 3.1 can black hole the=20 > traffic if the only failure is the link between source and ingress=20 > (i.e. ingress node and link between ingress/backup being alive will=20 > cause source to import the steam to backup, but backup will not import th= e stream to the P2MP tree). >=20 > [Huaimo] It seems that 3.3 "Source Detects Failure" works well for=20 > protecting the primary ingress failure of a P2MP LSP. For a P2P LSP,=20 > 3.3 seems not enough to provide protection for the primary ingress=20 > failure of the LSP because we may need to send/refresh PATH messages=20 > to the next hop node of the primary ingress of the P2P LSP through the=20 > backup LSP when the primary ingress node fails. > In the case that the link between the source and the primary ingress=20 > fails, > 3.1 " Backup and Source Detect Failure" may work well. The source may=20 > locally distinguish between the failure of the primary ingress and=20 > that of the link between the source and the primary ingress. When the=20 > source detects the failure of the link (but not the failure of the=20 > primary ingress), it may continue to send the traffic to the primary=20 > ingress via another link between the source and the primary ingress if th= ere is one. IMHO, what I think we should avoid is creating a solution that relies on tw= o unsynchronized brains making a same decision. If we pursue this, we creat= e a complex problem of how do we ensure two brains make the same decision o= r how do we synchronize the decision by two brains. Additionally, we should= avoid creating a solution that relies on an LSR being able to deterministi= cally differentiate between a link failure and a node failure, this is also= another complex problem. If we can come up with a solution that avoids bot= h of these problems, then the resulting solution should be much more stable= (i.e. able to produce deterministic results). Above, you said (3.1 " Backup and Source Detect Failure" may work well). Su= re it might be easier from signaling perspective, but it's not easy from fa= ilure detection perspective (i.e. has two brain problem). > > 5. Remove the detection modes that do not work from the draft. > > This is a challenging problem for us to have a perfect solution. > > More discussions and comments may be needed. >=20 > Theoretically, all 4 scenarios (3.1-3.4) are interesting. However,=20 > first question that I have (and perhaps should first get discussed) is=20 > do we _need to_ try to support all 4 scenarios and why. One possible=20 > outcome is that folks are sufficiently happy with 3.3, and there are=20 > no further problems to solve. If folks do indeed need other=20 > solution(s) besides 3.3, then I agree that we should discuss some possibi= lities. >=20 > [Huaimo] 3.3 works for protecting the primary ingress failure of a P2MP L= SP. > We may just need to have a solution that works well for protecting the=20 > primary ingress failure of a P2P LSP. Perhaps an alternative way to approach this problem is to figure out how to= do what you are doing with P2MP for P2P, and only use 3.3 as the detection= . Perhaps another way to approach this problem is to figure out how the LSP f= rom primary ingress and corresponding LSP from backup ingress can get assoc= iated so that the two LSPs are always active (i.e. backup ingress can takeo= ver anytime) but share bandwidth reservation (i.e. no bandwidth resources w= asted). This approach also has a benefit of backup ingress being able to ru= n continuity check on the LSP before the takeover, so that backup ingress k= nows that backup LSP is healthy when it takes over. It would be a pity for = the backup ingress to take over but traffic black holes because forwarding = state on the backup ingress or merge-point LSR or elsewhere is bad. > > =A0Is it acceptable to have a detection mode that works well in most= =20 > > of cases and can recover in other corner cases in a short time? >=20 > Is node failure more common than link failure? :) And how "short" are=20 > we talking about? :) >=20 > Perhaps better to check with operators/customers who are asking for this? >=20 > [Huaimo] "short" should mean in ms not in seconds. Thanks for the information. >=20 > I'd be happy to chip in to aid in tackling the problems, but=20 > personally I'd like to know that we do indeed need to solve them. >=20 > [Huaimo] Thanks much for your willing to help! Based on names on this email thread, and list of authors/contributors in th= e document, clearly there's an interest to solve this problem. I am also su= pportive of solving this problem. However, I'm just not convinced that we h= ave come up with the best way to solve this problem [yet]. But I'm just one= person. In my VERY humble opinion, it might be beneficial to articulate the limitat= ions with proposals in this draft and ask for comments/feedback from the co= mmunity with open mind to potentially fresh ideas. Thanks! -Nobo From nobody Mon Jun 16 21:54:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64C01A01D2 for ; Mon, 16 Jun 2014 21:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQHQZxzFZnI8 for ; Mon, 16 Jun 2014 21:54:02 -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 95F391A00A9 for ; Mon, 16 Jun 2014 21:54:02 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1202218015A1; Tue, 17 Jun 2014 06:53:58 +0200 (CEST) Message-ID: <539FC9DF.2000208@pi.nu> Date: Tue, 17 Jun 2014 06:53:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> In-Reply-To: <538FFE2A.4010406@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/_BGu4nk8HrSGva6-Vlkl1l1_oGY Cc: "" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org" Subject: [mpls] Closed -- Re: Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 17 Jun 2014 04:54:04 -0000 Working Group, This working group has been closed, there have been comments. Could the authors please address comments and post a new version of the dcoument. /Loa for the wg chairs On 2014-06-05 07:20, Loa Andersson wrote: > Working Group, > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last > call that was intended to be closed last Monday (June 2nd). > > Hopwever, there has not be a single response! > > I cn't make up my mind how to interprete this - either the wg have > lost interest in the draft (which would surprise me greatly) or > everybody thinks the draft is perfect (which would also be a surprise). > > I will therefore extend the wglc until June 16 and invite also positive > responses (e.g. "I think this document is ready for publication!"). > > /Loa > for the wg chairs > > On 2014-05-19 11:49, Loa Andersson wrote: >> Working Group, >> >> This is to initiate a working group last call on >> draft-ietf-mpls-lsp-ping-relay-reply. >> >> There are two IPR disclosures against this document. The author has >> stated that he is unaware of any other IPRs that relate to this >> document. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> >> This working group last call ends June 2, 2014. >> >> /Loa >> for the MPLS wg chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jun 16 23:04:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCF01A0275 for ; Mon, 16 Jun 2014 23:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, MIME_CHARSET_FARAWAY=2.45, 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 L4WIG5KEmE82 for ; Mon, 16 Jun 2014 23:04:08 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972131A0266 for ; Mon, 16 Jun 2014 23:04:08 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fb1so2892765pad.0 for ; Mon, 16 Jun 2014 23:04:08 -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=CFL/kfjoUjvkpXMn/8CuI5buKaFmOVs6aoe5Pzqwh/Q=; b=CQ2sisTQY428aRlBQNjOsb3+1S6xQkM/GKQcg80U44VWkn7l0lbVOnj2LQwvNV/JmW fCMz8FgntJmbfMA1QvgiVe/EcadOhwLreOqUI04IYo52NE+2kV96kOOeXgPQbtHd2qpl 2ywSr0pUnNErh5P+n8YdcQh9VId25SdEq4+rjsHhjaxs8IJkqBaiPzl2kQOIBLuxK7hO 5THbX/lHxXEivrUuUzLNITENXMQNl6NjEd9nxHNe5ajyeShZjBqYRqZJBZO8uuehPm2j ho2EFURl/sy59q/WkNXM7FWAKC0eIk+v26P4vjfcjcBTmmAM7MCJSBZi3b9T5lUAtNoY fh0A== X-Received: by 10.68.229.68 with SMTP id so4mr29498387pbc.110.1402985048277; Mon, 16 Jun 2014 23:04:08 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id fe3sm21991570pbd.66.2014.06.16.23.04.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 Jun 2014 23:04:07 -0700 (PDT) From: "Lizhong Jin" To: "'Loa Andersson'" , References: <5379D3A8.5020507@pi.nu> <538FFE2A.4010406@pi.nu> <539FC9DF.2000208@pi.nu> In-Reply-To: <539FC9DF.2000208@pi.nu> Date: Tue, 17 Jun 2014 14:04:01 +0800 Message-ID: <017601cf89f1$f2fc5320$d8f4f960$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFkNImub9tQ9oQH/0/dAlGlBbKZQHTWwX1AWRjifGb7wPdAA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Nph-VctAE24Pqn53RCNfK9sMzqY Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org Subject: Re: [mpls] Closed -- Re: Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply 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, 17 Jun 2014 06:04:09 -0000 Hi Loa, all, Thanks for the comments. We will post a new version soon. Regards Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 2014=C4=EA6=D4=C217=C8=D5 12:54 > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; ; VIGOUREUX, > MARTIN (MARTIN); draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org > Subject: Closed -- Re: Still Open - Re: Working group last call on draft-ietf- > mpls-lsp-ping-relay-reply >=20 > Working Group, >=20 > This working group has been closed, there have been comments. Could = the > authors please address comments and post a new version of the = dcoument. >=20 > /Loa > for the wg chairs >=20 > On 2014-06-05 07:20, Loa Andersson wrote: > > Working Group, > > > > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call > > that was intended to be closed last Monday (June 2nd). > > > > Hopwever, there has not be a single response! > > > > I cn't make up my mind how to interprete this - either the wg have > > lost interest in the draft (which would surprise me greatly) or > > everybody thinks the draft is perfect (which would also be a = surprise). > > > > I will therefore extend the wglc until June 16 and invite also > > positive responses (e.g. "I think this document is ready for publication!"). > > > > /Loa > > for the wg chairs > > > > On 2014-05-19 11:49, Loa Andersson wrote: > >> Working Group, > >> > >> This is to initiate a working group last call on > >> draft-ietf-mpls-lsp-ping-relay-reply. > >> > >> There are two IPR disclosures against this document. The author has > >> stated that he is unaware of any other IPRs that relate to this > >> document. > >> > >> Please send your comments to the mpls wg mailing list = (mpls@ietf.org). > >> > >> This working group last call ends June 2, 2014. > >> > >> /Loa > >> for the MPLS wg chairs > > >=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 Mon Jun 16 23:26:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB231A0289 for ; Mon, 16 Jun 2014 23:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km8jvhMij_V1 for ; Mon, 16 Jun 2014 23:26:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D85B1A027F for ; Mon, 16 Jun 2014 23:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=131; q=dns/txt; s=iport; t=1402986402; x=1404196002; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Q5mJaDS4S/WLJQpVdY1+vPpBs4aOO2wJyR+IqY0R/rI=; b=Yf7m+86XYPKhOG0xHKSIuPFY3DoyV/fwFBSk+Z8tC/BCEoSwifY4XMpg L0J3uMLhaYCNC2YSrQXjEurEjJ/ajwj8JW9RjI5Xm6NeADFdd57vjJFOb 29re+BHcxJxh/Pu4v1E1lzrfslMc0/jD+uWaG9JPkZayo81WdorMmfETv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigGAFHen1OtJssW/2dsb2JhbABakUmcZwEBAQEBAQUBmSaBJXWERD+BPgGIVMsvF4VjiRODNIEWAQOaQ5NYg0I7 X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="88986274" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 17 Jun 2014 06:26:40 +0000 Received: from ams-iwijnand-8719.cisco.com (ams-iwijnand-8719.cisco.com [10.55.191.154]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5H6Qd7V010823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2014 06:26:40 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jun 2014 08:26:38 +0200 Message-Id: To: "" , "martin.vigoureux@alcatel-lucent.com Vigoureux" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Ykexsngoy_CxYmOYjG86M9PfcNk Cc: draft-ietf-mpls-mldp-node-protection@tools.ietf.org Subject: [mpls] draft-ietf-mpls-mldp-node-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, 17 Jun 2014 06:26:44 -0000 Dear MPLS chairs, The document has been stable for a while now, could you consider doing a = last-call on it? Thx, Ice. From nobody Mon Jun 16 23:34:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2DE1A0299 for ; Mon, 16 Jun 2014 23:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6hkAE96KwWq for ; Mon, 16 Jun 2014 23:34:41 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2301A0289 for ; Mon, 16 Jun 2014 23:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=174; q=dns/txt; s=iport; t=1402986881; x=1404196481; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=35fqtYFUZkf810uS3GrUv76y1IB3CV9MbZ9NvHbHkAA=; b=OHo9qELvTu7M7TYydlv7wvD+PC3n4RIir8xSmwmTI1dfD/vLKPcyRKZQ Xe6tnojFAOTkBmB78WwnTk28RqESMm37huZNiCMUQ7/PliWIDbYNqYF0X 7XtbZGO4whrLJT0YlXq4kSGFpWkA4ohVLcn33nZL65zKb/bLQurtsjl3h 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGAK7gn1OtJssW/2dsb2JhbABakUmcZwEBAQEBAQUBmRwBCYEldYUDgT4BiFTLLxeFY4kTgzSBFgEDmkOTWINCOw X-IronPort-AV: E=Sophos;i="5.01,492,1400025600"; d="scan'208";a="84257050" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Jun 2014 06:34:39 +0000 Received: from ams-iwijnand-8719.cisco.com (ams-iwijnand-8719.cisco.com [10.55.191.154]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5H6Yc7i026529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2014 06:34:39 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jun 2014 08:34:38 +0200 Message-Id: To: "" , "martin.vigoureux@alcatel-lucent.com Vigoureux" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/SePHpCsJfBGkIBxYPvJUXie_-II Cc: draft-ietf-mpls-mldp-in-band-wildcard-encoding@tools.ietf.org Subject: [mpls] draft-ietf-mpls-mldp-in-band-wildcard-encoding 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, 17 Jun 2014 06:34:42 -0000 Dear MPLS chairs, We don=92t have any updates to this draft pending and we like to move it = forward. Could you consider this draft for a last-call? Thx, Ice.= From nobody Tue Jun 17 02:39:26 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FE41A0345 for ; Tue, 17 Jun 2014 02:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww7VIl1XcS-T for ; Tue, 17 Jun 2014 02:39: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 2CDF21A0341 for ; Tue, 17 Jun 2014 02:39:22 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8CDCC18015A1; Tue, 17 Jun 2014 11:39:19 +0200 (CEST) Message-ID: <53A00CBF.7010605@pi.nu> Date: Tue, 17 Jun 2014 11:39:11 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/32qJy86e_PznoAS3Pg6Z9b1b2Vs Subject: [mpls] working group last call on draft-ietf-mpls-mldp-node-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, 17 Jun 2014 09:39:24 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-mldp-node-protection-01. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are two IPR disclosures against this document. The authors and the working group members have been asked in a separate mail to state whether they are aware of other IPRs that relate to this document. This working group last call ends July 1, 2014. /Loa for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jun 17 10:33:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64281A0115 for ; Tue, 17 Jun 2014 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udn6b2jBqtGR for ; Tue, 17 Jun 2014 10:33:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508F71A002F for ; Tue, 17 Jun 2014 10:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8867; q=dns/txt; s=iport; t=1403026412; x=1404236012; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+KzGSejrOK0ykgTQwCwOgFma/rjijgebmzOMezV+vpU=; b=I2YafnLJebH35eR/VojRQLzf6tJvaZ2PAwekXaIRx4g9CCyTC+nfhcui YmZQyaueDefnbuE3MFoWY7PdmdL7rWl36mwIRQS/m7z8shikDdf5QE7Hn eG9uTILyznH1wXp0Ik/YfwiSBKeEA3dGLLOL0iYbO0JgnjyNRj9s6QNug o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAFt7oFOtJA2I/2dsb2JhbABagmkkgSysZ5ZPAYENFnWEAwEBAQMBaw4FBwQCAQgRBAEBCx0HIRETAQkIAgQBDQUIDAeIEwMJCAHEQg2GNheJQ4MQgTgJEQEfMQcGgyeBFgEDhGMFhR2ORQaPS4YAg0CBdzk X-IronPort-AV: E=Sophos;i="5.01,495,1400025600"; d="scan'208";a="333769350" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jun 2014 17:33:26 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5HHXP1j027467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 17:33:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 12:33:25 -0500 From: "Nobo Akiya (nobo)" To: Huaimo Chen , Gregory Mirsky , Yimin Shen , "mpls@ietf.org" Thread-Topic: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 Thread-Index: AQHPiAdDom4sP4did0mv4Q2gZ/v1RJtyoIOAgAGllQCAAUYOAA== Date: Tue, 17 Jun 2014 17:33:25 +0000 Message-ID: References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B773138@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7761F4@eusaamb103.ericsson.se> <75e6f9b9bfd44105a725a98d11e1f968@BY2PR05MB728.namprd05.prod.outlook.com>, <7347100B5761DC41A166AC17F22DF1121B776557@eusaamb103.ericsson.se> <104CBCDD-6440-453E-A224-3FAF4BE75F04@juniper.net> <7347100B5761DC41A166AC17F22DF1121B777091@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C4917F@SJCEML701-CHM.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B7775DE@eusaamb103.ericsson.se> <8E4F5326-58DC-4F16-95A2-F9D6C87DAFF7@juniper.net> <7347100B5761DC41A166AC17F22DF1121B77784D@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C66964@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C7496C@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C74B9A@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C74B9A@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/5hUpj6t8-PYDxqvSR1pjY6syV7U Cc: Raveendra Torvi , mengnan 58534 , "Boris.Zhang@telus.com" , "Toy, Mehmet" , "ningso01@gmail.com" , lizhenbin 00147097 , Alia Atlas , Ross Callon , "'Xu, Fengman'" , Quintin zhao Subject: Re: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 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, 17 Jun 2014 17:33:33 -0000 Hi Huaimo, My original intent was to highlight the limitations with detections propose= d, and I believe that has been accomplished. Thank you for putting up with = my effort to do so! > After the failure of the primary ingress happens and the backup > ingress determines the failure, the backup ingress sends/refreshes > PATH messages to the next hop node of the primary ingress of a P2P > LSP through the backup LSP as needed. The failure can be determined > reliably through checking the Link State Database (LSDB). Unfortunately, I don't think this additional text solves the problem. The b= ackup ingress needs to know the health of the link between the source and p= rimary ingress. That particular link could very well be outside the TE top= ology (i.e. link is CE to PE[primary ingress]) in which case you do not hav= e the trigger for the backup ingress to send the necessary PATH message. Wi= th LSDB trigger approach, you could be limiting the scope of the solution s= ignificantly. LSP "association" approach (as roughly eluded in my earlier comment) still = rings a nicer sound, but I think, at this point, this document needs RSVP s= ignaling experts to provide comments and possibly alternative ideas. Thanks! -Nobo > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Monday, June 16, 2014 12:37 PM > To: Nobo Akiya (nobo); Gregory Mirsky; Yimin Shen; mpls@ietf.org > Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; = Toy, > Mehmet; LEI LIU; ningso01@gmail.com; lizhenbin 00147097; Quintin zhao; > Richard Li; mengnan 58534; Boris.Zhang@telus.com > Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 >=20 > Hi Nobo, >=20 > Thanks much for your suggestions and comments! >=20 > It seems that 3.3 "Source Detects Failure" with some > changes/enhancements works for protecting the primary ingress failure of = a > P2P LSP. >=20 > 3.3 "Source Detects Failure" may be updated as follows: >=20 > Source Detects Failure or Source-Detect means that the source is > responsible for detecting the failure of the primary ingress of an > LSP quickly. The backup ingress is ready to import the traffic from th= e > source into the backup LSP after the backup LSP is up. >=20 > In normal operations, the source sends the traffic to the primary > ingress. When the source detects the failure of the primary ingress, > it switches the traffic to the backup ingress, which delivers the > traffic to the next hops of the primary ingress through the backup > LSP, where the traffic is merged into the primary LSP. >=20 > After the failure of the primary ingress happens and the backup > ingress determines the failure, the backup ingress sends/refreshes > PATH messages to the next hop node of the primary ingress of a P2P > LSP through the backup LSP as needed. The failure can be determined > reliably through checking the Link State Database (LSDB). >=20 >=20 > Best Regards, > Huaimo > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Sunday, June 15, 2014 6:03 PM > To: Huaimo Chen; Gregory Mirsky; Yimin Shen > Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; = Toy, > Mehmet; LEI LIU; ningno@yahoo.com; Ning So; lizhenbin 00147097; Quintin > zhao; Richard Li > Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 >=20 > Hi Huaimo, >=20 > > Thanks for your comments! >=20 > Thanks for responding! >=20 > Please see in-line. >=20 > > I believe 3.3 is the only one that works well. 3.1 can black hole the > > traffic if the only failure is the link between source and ingress > > (i.e. ingress node and link between ingress/backup being alive will > > cause source to import the steam to backup, but backup will not import > the stream to the P2MP tree). > > > > [Huaimo] It seems that 3.3 "Source Detects Failure" works well for > > protecting the primary ingress failure of a P2MP LSP. For a P2P LSP, > > 3.3 seems not enough to provide protection for the primary ingress > > failure of the LSP because we may need to send/refresh PATH messages > > to the next hop node of the primary ingress of the P2P LSP through the > > backup LSP when the primary ingress node fails. > > In the case that the link between the source and the primary ingress > > fails, > > 3.1 " Backup and Source Detect Failure" may work well. The source may > > locally distinguish between the failure of the primary ingress and > > that of the link between the source and the primary ingress. When the > > source detects the failure of the link (but not the failure of the > > primary ingress), it may continue to send the traffic to the primary > > ingress via another link between the source and the primary ingress if > there is one. >=20 > IMHO, what I think we should avoid is creating a solution that relies on = two > unsynchronized brains making a same decision. If we pursue this, we creat= e > a complex problem of how do we ensure two brains make the same > decision or how do we synchronize the decision by two brains. Additionall= y, > we should avoid creating a solution that relies on an LSR being able to > deterministically differentiate between a link failure and a node failure= , > this is also another complex problem. If we can come up with a solution t= hat > avoids both of these problems, then the resulting solution should be much > more stable (i.e. able to produce deterministic results). >=20 > Above, you said (3.1 " Backup and Source Detect Failure" may work well). > Sure it might be easier from signaling perspective, but it's not easy fro= m > failure detection perspective (i.e. has two brain problem). >=20 > > > 5. Remove the detection modes that do not work from the draft. > > > This is a challenging problem for us to have a perfect solution. > > > More discussions and comments may be needed. > > > > Theoretically, all 4 scenarios (3.1-3.4) are interesting. However, > > first question that I have (and perhaps should first get discussed) is > > do we _need to_ try to support all 4 scenarios and why. One possible > > outcome is that folks are sufficiently happy with 3.3, and there are > > no further problems to solve. If folks do indeed need other > > solution(s) besides 3.3, then I agree that we should discuss some > possibilities. > > > > [Huaimo] 3.3 works for protecting the primary ingress failure of a P2MP > LSP. > > We may just need to have a solution that works well for protecting the > > primary ingress failure of a P2P LSP. >=20 > Perhaps an alternative way to approach this problem is to figure out how = to > do what you are doing with P2MP for P2P, and only use 3.3 as the detectio= n. >=20 > Perhaps another way to approach this problem is to figure out how the LSP > from primary ingress and corresponding LSP from backup ingress can get > associated so that the two LSPs are always active (i.e. backup ingress ca= n > takeover anytime) but share bandwidth reservation (i.e. no bandwidth > resources wasted). This approach also has a benefit of backup ingress bei= ng > able to run continuity check on the LSP before the takeover, so that back= up > ingress knows that backup LSP is healthy when it takes over. It would be = a > pity for the backup ingress to take over but traffic black holes because > forwarding state on the backup ingress or merge-point LSR or elsewhere is > bad. >=20 > > > =A0Is it acceptable to have a detection mode that works well in mos= t > > > of cases and can recover in other corner cases in a short time? > > > > Is node failure more common than link failure? :) And how "short" are > > we talking about? :) > > > > Perhaps better to check with operators/customers who are asking for thi= s? > > > > [Huaimo] "short" should mean in ms not in seconds. >=20 > Thanks for the information. >=20 > > > > I'd be happy to chip in to aid in tackling the problems, but > > personally I'd like to know that we do indeed need to solve them. > > > > [Huaimo] Thanks much for your willing to help! >=20 > Based on names on this email thread, and list of authors/contributors in = the > document, clearly there's an interest to solve this problem. I am also > supportive of solving this problem. However, I'm just not convinced that = we > have come up with the best way to solve this problem [yet]. But I'm just = one > person. >=20 > In my VERY humble opinion, it might be beneficial to articulate the > limitations with proposals in this draft and ask for comments/feedback fr= om > the community with open mind to potentially fresh ideas. >=20 > Thanks! >=20 > -Nobo From nobody Tue Jun 17 16:27:06 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5A31A0170; Tue, 17 Jun 2014 16:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 lS_T_JxB3K4l; Tue, 17 Jun 2014 16:26:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3951A0155; Tue, 17 Jun 2014 16:26:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 058A41801C2; Tue, 17 Jun 2014 16:25:34 -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: <20140617232534.058A41801C2@rfc-editor.org> Date: Tue, 17 Jun 2014 16:25:34 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Mj9f5rWiEqTdZ1_xLhLXMwPeAxk Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7212 on MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 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, 17 Jun 2014 23:26:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7212 Title: MPLS Generic Associated Channel (G-ACh) Advertisement Protocol Author: D. Frost, S. Bryant, M. Bocci Status: Standards Track Stream: IETF Date: June 2014 Mailbox: frost@mm.st, stbryant@cisco.com, matthew.bocci@alcatel-lucent.com Pages: 23 Characters: 52340 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-gach-adv-08.txt URL: http://www.rfc-editor.org/rfc/rfc7212.txt The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. 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 Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jun 17 16:27:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BF81A01BA; Tue, 17 Jun 2014 16:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 Mk-g8bSt74EW; Tue, 17 Jun 2014 16:27:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A992A1A014E; Tue, 17 Jun 2014 16:27:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8DB231801C2; Tue, 17 Jun 2014 16:25:55 -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: <20140617232555.8DB231801C2@rfc-editor.org> Date: Tue, 17 Jun 2014 16:25:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Jc7R-8jF0eFpwiOPAWRv3_84N7Y Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 7213 on MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing 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, 17 Jun 2014 23:27:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7213 Title: MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing Author: D. Frost, S. Bryant, M. Bocci Status: Standards Track Stream: IETF Date: June 2014 Mailbox: frost@mm.st, stbryant@cisco.com, matthew.bocci@alcatel-lucent.com Pages: 9 Characters: 20407 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-ethernet-addressing-08.txt URL: http://www.rfc-editor.org/rfc/rfc7213.txt The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. 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 Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jun 17 20:36:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D6D1A0157 for ; Tue, 17 Jun 2014 20:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQAfHBsBZjL9 for ; Tue, 17 Jun 2014 20:36:35 -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 23BA11A0140 for ; Tue, 17 Jun 2014 20:36:35 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2EF4318013DA; Wed, 18 Jun 2014 05:36:31 +0200 (CEST) Message-ID: <53A10938.1010602@pi.nu> Date: Wed, 18 Jun 2014 05:36:24 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" , Adrian Farrel , "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KE95lEQ06srI2x4R8XuELDE62Ng Subject: [mpls] IPR poll on draft-ietf-mpls-mldp-node-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, 18 Jun 2014 03:36:37 -0000 Working Group, We have started the wglc draft-ietf-mpls-mldp-node-protection. When we did the wg adoption poll on this document (about a year ago) we did an IPR poll on the individual document. Before we progress the document after addressing wglc comment we want to do an IPR poll on the working group document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-mldp-node- protection? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are two IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jun 17 20:50:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930F01A021B for ; Tue, 17 Jun 2014 20:50:17 -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 7QWuKK8ghOu5 for ; Tue, 17 Jun 2014 20:50:15 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2A61A021A for ; Tue, 17 Jun 2014 20:50:15 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 10so195022ykt.36 for ; Tue, 17 Jun 2014 20:50:15 -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=ohuHRQS9t2Y8yEiiNsQvLY5BTQHvAu9pFbOLA8/utCo=; b=OFd7AQjqaRFCK3HhYV9WdxFxm1ArHtOkLVbHVsukgYxYOlRUVa2PTbA7wSs+wiMDkY YmNqd9ap+nOl4IT7bqZF1Ox2+nrOQ3RmvvAxnTvn19Bsxfc4cjoLYe1LNkP/RvFjjXtn sJyHVX0SCYx+ZlJpWppyVXFXJKXtTBzZksdNLXmjDtx56fuFFcTYA4Iphs1xPlbkIoM9 8gX4v+3tTBiRVY87vBaSFqaGhln99Re81y86nJP1U3gmrwyA9K67P45C6v200BrY5mSE ssFV6O5dKvaHk40fSFEyGJWrRAIbzYU5DkY4dsIB09Jc9f/rvDf1MXE1qf5TOKuMxM6X 2r/Q== MIME-Version: 1.0 X-Received: by 10.236.184.137 with SMTP id s9mr298543yhm.152.1403063415041; Tue, 17 Jun 2014 20:50:15 -0700 (PDT) Received: by 10.170.52.75 with HTTP; Tue, 17 Jun 2014 20:50:14 -0700 (PDT) In-Reply-To: <53A10938.1010602@pi.nu> References: <53A10938.1010602@pi.nu> Date: Tue, 17 Jun 2014 23:50:14 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf303f651673745004fc142895 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/k855W8jB8jdgo9cGFi1UoczLfF0 Cc: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-mldp-node-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, 18 Jun 2014 03:50:17 -0000 --20cf303f651673745004fc142895 Content-Type: text/plain; charset=UTF-8 I know of no relevant IPR that has not been disclosed. Alia On Tue, Jun 17, 2014 at 11:36 PM, Loa Andersson wrote: > Working Group, > > We have started the wglc draft-ietf-mpls-mldp-node-protection. When > we did the wg adoption poll on this document (about a year ago) we > did an IPR poll on the individual document. Before we progress the > document after addressing wglc comment we want to do an IPR poll on > the working group document. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-mldp-node- > protection? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > Currently there are two IPR disclosures that relates to this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Loa > (as MPLS WG co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf303f651673745004fc142895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I know of no relevant IPR that has not been disclosed.
Alia


On Tue, Jun 17, 2014 at 11:36 PM, Loa Andersson <loa@pi.nu&= gt; wrote:
Working Group,

We have started the wglc draft-ietf-mpls-mldp-node-protection. When<= br> we did the wg adoption poll on this document (about a year ago) we
did an IPR poll on the individual document. Before we progress the
document after addressing wglc comment we want to do an IPR poll on
the working group document.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-mldp-node-
protection?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

Currently there are two IPR disclosures that relates to this document.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The docum= ent will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks, Loa
(as MPLS WG co-chair)
--


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

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

--20cf303f651673745004fc142895-- From nobody Tue Jun 17 21:24:45 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4F1A0202 for ; Tue, 17 Jun 2014 21:24:43 -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_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 h2cpjoliKjmJ for ; Tue, 17 Jun 2014 21:24:41 -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 C1BC81A00D2 for ; Tue, 17 Jun 2014 21:24:41 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-1d-53a0c35a78b9 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 48.1F.27529.A53C0A35; Wed, 18 Jun 2014 00:38:18 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 00:24:31 -0400 From: Jeff Tantsura To: Loa Andersson Thread-Topic: IPR poll on draft-ietf-mpls-mldp-node-protection Thread-Index: AQHPiqaGfz4sGH8oDUis+F9yv2lnX5t2RRlN Date: Wed, 18 Jun 2014 04:24:31 +0000 Message-ID: <52B8E098-E4D6-4183-B3A1-C7CE31D68685@ericsson.com> References: <53A10938.1010602@pi.nu> In-Reply-To: <53A10938.1010602@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPt27U4QXBBquW6Vj86LnBbPHp2gwm i39z5zBb3Nn1hdXi+6UlLBa3lq5kdWDzaH22l9VjyZKfTB4rNq9k9Jg1vY3N48vlz2wBrFFc NimpOZllqUX6dglcGXfOPWEqmMpbcanlLXsDYw9XFyMnh4SAicSk6UsZIWwxiQv31rOB2EIC Rxklzhy37mLkArKXM0p0fTjCApJgEzCQ+P/tOJgtIiArcW3bTyaQImaBfUwSX1Y1gyWEBWwl 2jrWMkEU2Uk8PnWbGcI2kmhfvgosziKgKtF97hlYPa+AvcTsqbOB4hxA21Qk+mYFgoQ5gUo+ L7zCCmIzAh33/dQasFZmAXGJW0/mM0EcLSCxZM95ZghbVOLl43+sEDU6Egt2f2KDsLUlli18 zQyxSlDi5MwnLBMYRWchGTULScssJC2zkLQsYGRZxchRWpxalptuZLCJERhTxyTYdHcw7nlp eYhRgINRiYf3geeCYCHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYKxSkZtY7F3nuD1wRpj4qi/9NhY/HRztFrv/bFP/M0P5JJN+wY5vPSrJ5ZLXXZLut1XP d7LY4Df5uOWX+AhNpiUPWqQ2vpUxrWWX7Lr3MHSqdmyl2fbyzyW7DBZ8nP5OtFlSIDK71MBK +tgT9ikmFUsyFzxbtjRY6MCe5P6fekvv/uRl0Nd6rMRSnJFoqMVcVJwIAGhSAeGKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RJLbvKWoladx9w8qIu-njE5rgVc Cc: "mpls@ietf.org" , "draft-ietf-mpls-mldp-node-protection@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-mldp-node-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, 18 Jun 2014 04:24:43 -0000 Hi Loa, I am not aware of any IPR that has not been already disclosed. Regards, Jeff > On Jun 18, 2014, at 7:36 AM, "Loa Andersson" wrote: >=20 > Working Group, >=20 > We have started the wglc draft-ietf-mpls-mldp-node-protection. When > we did the wg adoption poll on this document (about a year ago) we > did an IPR poll on the individual document. Before we progress the > document after addressing wglc comment we want to do an IPR poll on > the working group document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-mldp-node- > protection? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are two IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The doc= ument will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jun 18 00:12:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9C21A0026 for ; Wed, 18 Jun 2014 00:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcmlQrzAAScn for ; Wed, 18 Jun 2014 00:12: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 2D8DA1A001A for ; Wed, 18 Jun 2014 00:12:22 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3C7A518013DA; Wed, 18 Jun 2014 09:12:18 +0200 (CEST) Message-ID: <53A13BCA.10107@pi.nu> Date: Wed, 18 Jun 2014 09:12:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org References: <53A00CBF.7010605@pi.nu> In-Reply-To: <53A00CBF.7010605@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/XFoul-_dSXhL69jBWH9Y7-jahR4 Subject: Re: [mpls] working group last call on draft-ietf-mpls-mldp-node-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, 18 Jun 2014 07:12:24 -0000 Authors, On 2014-06-17 11:39, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-mldp-node-protection-01. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are two IPR disclosures against this document. The authors and > the working group members have been asked in a separate mail to state > whether they are aware of other IPRs that relate to this document. > > This working group last call ends July 1, 2014. > > /Loa > for the MPLS wg chairs I've a question on the definition of "root node" for mp2mp networks. I think there are two models 1. the mp2mp network have ingress nodes and egress nodes, an ingress node send traffic to all egress nodes, thus acting as a root node on a for an p2mp network. 2. the mp2mp network have ingress nodes, egress node and one (active) root node. The ingress node send traffic to the root node, which send the traffic to all the egress nodes. Which model is assumed in draft-ietf-mpls-mldp-node-protection? /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 Wed Jun 18 02:59:15 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2F1A0149; Wed, 18 Jun 2014 02:59:13 -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 XKih81GXaWNr; Wed, 18 Jun 2014 02:59:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 136FD1A0011; Wed, 18 Jun 2014 02:59:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140618095912.27815.75622.idtracker@ietfa.amsl.com> Date: Wed, 18 Jun 2014 02:59:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PaCgh2nVYWBViIqNDg360P2gzEs Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-09.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, 18 Jun 2014 09:59:13 -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 : LDP Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-09.txt Pages : 15 Date : 2014-06-18 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-09 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 Jun 18 04:30:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E361A01FB for ; Wed, 18 Jun 2014 04:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnS-jIvAXQhG for ; Wed, 18 Jun 2014 04:30:09 -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 938531A01E0 for ; Wed, 18 Jun 2014 04:30:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO21828; Wed, 18 Jun 2014 11:30:06 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 12:30:06 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 19:30:03 +0800 From: Qin Wu To: "mpls@ietf.org" Thread-Topic: Working group last call on draft-ietf-mpls-seamless-mcast Thread-Index: AQHPhJaHcO3K9+kq/ECA76LAZYUjuZt2xAkQ Date: Wed, 18 Jun 2014 11:30:02 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sx_Q--ta3IbGi1_P_i3yfhWgNNw Subject: Re: [mpls] Working group last call on draft-ietf-mpls-seamless-mcast 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, 18 Jun 2014 11:30:11 -0000 Hi, authors: I have read this draft and believe it is well written and ready for going f= or publication. Here are a few editorial comments: 1. Section 3, the 10th paragraph said: " The backbone area segment has as its leaves ABRs that are connected to the egress area(s) or PEs in the backbone area, or ASBRs in the backbone area. " [Qin]: what does "has as its leaves ABRs" mean? Should it be "has its leave= s ABRs" 2. Section 3, the 11th paragraph said: " The egress area segment is rooted at an ABR in the egress area (egress ABR), and has as its leaves PEs and ASBR in that egress area (the latter covers the case where the P2MP service LSP spans multiple ASes). =20 " [Qin]: s/has as/has 3. Section 6.2.3, the 2nd paragraph said: " The upstream node's address is as determined in section 6.1 ("Determining the Upstream ABR/PE/ASBR (Upstream Node)"). " [Qin]: For consistency, would it be good to rephrase as " The upstream node's address is=20 determined as specified section 6.1 ("Determining the Upstream ABR/PE/ASBR (Upstream Node)"). " 4. Section 6.3.1.1 said: " Similarly whenever as a result of receiving MSDP messages a PE, that is not configured as a RP, discovers a new multicast source the PE SHOULD originate a BGP Source Active A-D route. " [Qin]: s/ messages a PE, that is not/ messages, a PE that is not 5. Section 6.3.1.2 said: " When as a result of receiving PIM or IGMP messages on one of its IP multicast interfaces an (egress) PE creates in its Tree Information " [Qin]: why "(egress) PE" not "egress PE"? does PE includes other type of PE= as well? 6. Section 12 said: " By default if the received S-PMSI A-D route carries the Inter-area P2MP Segmented Next-Hop Extended Community, then the originated S-PMSI A-D route SHOULD also carry this community. " [Qin]: Why SHOULD not MUST? What if the community is not carried in the originated S-PMSI A-D route? 7. Section 13.3 said: " An Ingress PE must perform application specific forwarding procedures to identify the outgoing inta-area segment of an incoming packet. " [Qin]: s/inta-area/intra-area 8. Section 14 said: " 14. Support for Inter-Area Transport LSPs=20 This section describes OPTIONAL procedures that allow to aggregate multiple (inter-area) P2MP service LSPs into a single inter-area P2MP transport LSP, and then apply the segmentation procedures, as specified in this document, to these inter-area P2MP transport LSPs (rather than applying these procedures directly to the inter-area P2MP service LSPs). " [Qin]: since the procedures proposed in section 14 is optional, why not mov= e these procedures to appendix of this document? -------- Original Message -------- Subject: Working group last call on draft-ietf-mpls-seamless-mcast Date: Mon, 09 Jun 2014 05:24:37 +0200 From: Loa Andersson To: mpls@ietf.org CC: draft-ietf-mpls-seamless-mcast@tools.ietf.org , mpls-chairs@tools.ietf.org , VIGOUREUX, MARTIN= (MARTIN) Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-s= eamless-mcast. There are one IPR disclosure against this document. The authors has stated = that he is unaware of any other IPRs that relate to this document. Please send your comments to the mpls wg mailing list (mpls@ietf.org). This working group last call ends June 23, 2014. /Loa for the MPLS wg chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jun 18 07:32:43 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD21A0294 for ; Wed, 18 Jun 2014 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ubit4f4SqJM7 for ; Wed, 18 Jun 2014 07:32:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92A01A0260 for ; Wed, 18 Jun 2014 07:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73; q=dns/txt; s=iport; t=1403101960; x=1404311560; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=2lNBLg+BnYHeDRvmD7IkrloGVb34kvnSvQurkfp1gfI=; b=V/0niZbQczrosAcB3+a9MdDvg7CW0C/1jhMW1I6BDsh4VUWZf5OSwyR0 FBh8Upe7GQ49Qgq4nWRVXCGj1NULcG3we2Tn02u/KtBs8XbV0Lzif33V5 7goO7i2ZKuPAC8EyyeOxPyTCHwOg2rwD66CfGveYs7X+Ctivu+tI4qOWj I=; X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="334020586" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jun 2014 14:32:39 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5IEWdJw032354; Wed, 18 Jun 2014 14:32:39 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id D6382769; Wed, 18 Jun 2014 10:32:38 -0400 (EDT) From: Eric Rosen To: Loa Andersson In-reply-to: Your message of Wed, 18 Jun 2014 05:36:24 +0200. <53A10938.1010602@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8631.1403101958.1@erosen-lnx> Date: Wed, 18 Jun 2014 10:32:38 -0400 Message-ID: <8632.1403101958@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/pP_ClfiE5s4Oq13L8OMEUPwwzBM Cc: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 14:32:41 -0000 I am unaware of any applicable IPR that has not already been disclosed. From nobody Wed Jun 18 07:54:42 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223021A0277 for ; Wed, 18 Jun 2014 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MBnrWcgjSwd for ; Wed, 18 Jun 2014 07:54:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F001A028A for ; Wed, 18 Jun 2014 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1882; q=dns/txt; s=iport; t=1403103271; x=1404312871; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=RS6ugQfjGeO7JfwTDv3GrvSjPSC43atPJvsHPdQkAZ8=; b=PVL2rwqPmgBys/niIVqXUt4NWRsuPQ2lt7S0tM/VLr4BkqfLsYYZMnoq yWFeTzvnK05Asf0mb1f5+EviVfb4b4jBNJa0ycrbOlVbNyBJJk8wLkt+i pL5/UPTuss+iKhAqhs2r9chw4I2oD1NDBKq5PxnUfJbII2T9YwjAfL7H9 0=; X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="333976641" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jun 2014 14:54:31 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5IEsUOP017858; Wed, 18 Jun 2014 14:54:30 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id 59C2B769; Wed, 18 Jun 2014 10:54:30 -0400 (EDT) From: Eric Rosen To: Loa Andersson In-reply-to: Your message of Wed, 18 Jun 2014 09:12:10 +0200. <53A13BCA.10107@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9143.1403103270.1@erosen-lnx> Date: Wed, 18 Jun 2014 10:54:30 -0400 Message-ID: <9144.1403103270@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/HxwIyDeLo4Dm8H6oEHFD0_e-5iQ Cc: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-mldp-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 14:54:35 -0000 Loa> I've a question on the definition of "root node" for mp2mp networks. RFC6388 defines "root node" for an MP2MP LSP. An MP2MP LSP is a tree, and as a tree it has a root node. However, the root node is not necessarily an ingress or egress node; any node can be an ingress, and any node can be an egress. Traffic from an ingress node travels both downstream from the ingress and upstream towards the root. When the traffic reaches the root, it travels downstream from the root on all branches other than the one from which the root received the traffic. Loa> I think there are two models No, RFC6388 doesn't have two models, and the model it does have is neither of the two below. Loa> 1. the mp2mp network have ingress nodes and egress nodes, an ingress Loa> node send traffic to all egress nodes, thus acting as a root node on Loa> a for an p2mp network. This description confuses the "root node" (the only node in the tree that is not a child of any other node) with an "ingress node" (a node that puts traffic onto the tree.) In a P2MP LSP, the only ingress point to the tree is the root node, but that's not true in MP2MP LSPs. Loa> 2. the mp2mp network have ingress nodes, egress node and one (active) Loa> root node. The ingress node send traffic to the root node, which Loa> send the traffic to all the egress nodes. If I understand correctly, this model requires the ingress to unicast to the root, and then requires the root to multicast down a P2MP tree. In general, this model does not work for MPLS. In this model, if a given node is both a sender and a receiver, it will receive its own traffic back, with no way to detect that it has already seen the traffic. This will result in traffic duplication. Loa> Which model is assumed in draft-ietf-mpls-mldp-node-protection? The RFC6388 MP2MP LSP model. From nobody Wed Jun 18 09:44:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA2F1A02CF for ; Wed, 18 Jun 2014 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-HDZOjPpvui for ; Wed, 18 Jun 2014 09:44: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 A2BB91A02CA for ; Wed, 18 Jun 2014 09:44:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO49885; Wed, 18 Jun 2014 16:44:28 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 17:44:27 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.232]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 09:44:23 -0700 From: Quintin zhao To: Loa Andersson Thread-Topic: IPR poll on draft-ietf-mpls-mldp-node-protection Thread-Index: AQHPitwcXxBanCdBCk6I/+1v43Jjr5t3EUXA Date: Wed, 18 Jun 2014 16:44:23 +0000 Message-ID: <11208E03C9803E4CB4C3D898F153D6C030798E42@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ORcjHOZ5npCh9WRy_n6C_nwVHMk Cc: "mpls@ietf.org" , "draft-ietf-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-mldp-node-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, 18 Jun 2014 16:44:39 -0000 Hi Loa, I am unaware of any applicable IPR that has not been already disclosed. Regards, Quintin > On Jun 18, 2014, at 7:36 AM, "Loa Andersson" wrote: >=20 > Working Group, >=20 > We have started the wglc draft-ietf-mpls-mldp-node-protection. When we=20 > did the wg adoption poll on this document (about a year ago) we did an=20 > IPR poll on the individual document. Before we progress the document=20 > after addressing wglc comment we want to do an IPR poll on the working=20 > group document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-mldp-node-=20 > protection? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are two IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond=20 > to this email regardless of whether or not you are aware of any=20 > relevant IPR. *The response needs to be sent to the MPLS wg mailing=20 > list.* The document will not advance to the next stage until a response h= as been received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author=20 > or contributor, then please explicitly respond only if you are aware=20 > of any IPR that has not yet been disclosed in conformance with IETF rules= . >=20 > Thanks, Loa > (as MPLS WG co-chair) > -- >=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 Jun 18 13:07:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475D21A025E for ; Wed, 18 Jun 2014 13:07:15 -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 C0DFMYK2s8M8 for ; Wed, 18 Jun 2014 13:07:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0691A015C for ; Wed, 18 Jun 2014 13:07:12 -0700 (PDT) Received: from hjohnson-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 18 Jun 2014 20:07:10 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jun 2014 16:06:38 -0400 References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> To: , Message-ID: <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR11CA0017.namprd11.prod.outlook.com (25.160.91.27) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02462830BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(377454003)(377424004)(189002)(199002)(51704005)(92726001)(92566001)(19580395003)(95666004)(62966002)(69596002)(19580405001)(81342001)(77982001)(83322001)(85852003)(83072002)(50226001)(4396001)(102836001)(31966008)(74662001)(74502001)(101416001)(97756001)(77156001)(15975445006)(46102001)(99396002)(23726002)(82746002)(21056001)(57306001)(76482001)(53416004)(36756003)(83716003)(50986999)(76176999)(105586002)(81542001)(77096002)(50466002)(86362001)(104166001)(33656002)(89996001)(46406003)(80022001)(79102001)(85306003)(93916002)(81156003)(20776003)(88136002)(64706001)(47776003)(87286001)(15202345003)(66066001)(42186005)(104396001)(42262001)(2101003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:hjohnson-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/4qN6IYhb9T5uxGoDZrtwlk8Ty7g Subject: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 20:07:15 -0000 Folks, I would like to request MPLS WG adoption of this draft. I'm hoping we = can progress it expeditiously. The only action it takes is to deprecate = the BGP Entropy Label Capabilty path attribute as defined in RFC 6790 S. = 5.2. Note that it's extremely short (3 pages including the usual boilerplate, = so about one page of content). Thanks, --John Begin forwarded message: > From: > Subject: New Version Notification for = draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > Date: June 18, 2014 at 2:11:36 PM EDT > To: John G.Scudder , Kireeti Kompella = , Kireeti Kompella , John = Scudder >=20 >=20 > A new version of I-D, = draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > has been successfully submitted by John G. Scudder and posted to the > IETF repository. >=20 > Name: draft-scudder-mpls-deprecate-bgp-entropy-label > Revision: 00 > Title: Deprecation of BGP Entropy Label Capability = Attribute > Document date: 2014-06-17 > Group: Individual Submission > Pages: 3 > URL: = http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-entro= py-label-00.txt > Status: = https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entropy-= label/ > Htmlized: = http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-label-= 00 >=20 >=20 > Abstract: > RFC 6790 defines the BGP Entropy Label Capability attribute. > Regrettably, it has a bug: although RFC 6790 mandates that Entropy > Label-incapable routers must remove the attribute, in practice this > requirement can't be guaranteed to be fulfilled. This specification > deprecates the attribute. A forthcoming document will propose a > replacement. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jun 18 13:28:18 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BFA1A0307 for ; Wed, 18 Jun 2014 13:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgAVaoBF8iHv for ; Wed, 18 Jun 2014 13:28:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1951A02F5 for ; Wed, 18 Jun 2014 13:28:13 -0700 (PDT) Received: from CO2PR05CA049.namprd05.prod.outlook.com (10.141.241.177) by BN1PR05MB107.namprd05.prod.outlook.com (10.255.199.20) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 18 Jun 2014 20:28:10 +0000 Received: from BL2FFO11FD042.protection.gbl (2a01:111:f400:7c09::165) by CO2PR05CA049.outlook.office365.com (2a01:111:e400:1429::49) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Wed, 18 Jun 2014 20:28:09 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD042.mail.protection.outlook.com (10.173.161.138) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Wed, 18 Jun 2014 20:28:08 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 18 Jun 2014 13:28:04 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s5IKS1n21555; Wed, 18 Jun 2014 13:28:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201406182028.s5IKS1n21555@magenta.juniper.net> To: , , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11181.1403123279.1@juniper.net> Date: Wed, 18 Jun 2014 13:27:59 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(189002)(199002)(1941001)(81342001)(31966008)(81542001)(21056001)(50986999)(2201001)(16796002)(4396001)(6806004)(54356999)(86362001)(46406003)(97736001)(50466002)(92726001)(92566001)(84676001)(558084003)(76482001)(99396002)(46102001)(87936001)(97756001)(77982001)(23726002)(83072002)(85852003)(74502001)(102836001)(74662001)(69596002)(64706001)(95666004)(81156003)(85306003)(83322001)(47776003)(68736004)(44976005)(80022001)(105596002)(79102001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB107; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02462830BE Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2OPKsZUHzmKmE1uDS0VziiF-HLw Cc: mpls@ietf.org Subject: [mpls] draft-ietf-mpls-pim-sm-over-mldp to WG LC 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, 18 Jun 2014 20:28:17 -0000 Dear WG chairs, Given that draft-ietf-mpls-pim-sm-over-mldp is fairly stable, could you please issue MPLS WG Last Call on it. Yakov. From nobody Wed Jun 18 13:44:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41131A0313 for ; Wed, 18 Jun 2014 13:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q59TisupO72P for ; Wed, 18 Jun 2014 13:44:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B061A0312 for ; Wed, 18 Jun 2014 13:44:32 -0700 (PDT) Received: from BN1PR05MB106.namprd05.prod.outlook.com (10.255.199.15) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 18 Jun 2014 20:44:30 +0000 Received: from BN1PR05CA003.namprd05.prod.outlook.com (10.255.197.23) by BN1PR05MB106.namprd05.prod.outlook.com (10.255.199.15) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 18 Jun 2014 20:44:25 +0000 Received: from BN1BFFO11FD009.protection.gbl (2a01:111:f400:7c10::1:190) by BN1PR05CA003.outlook.office365.com (2a01:111:e400:400::23) with Microsoft SMTP Server (TLS) id 15.0.959.24 via Frontend Transport; Wed, 18 Jun 2014 20:44:26 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD009.mail.protection.outlook.com (10.58.144.72) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Wed, 18 Jun 2014 20:44:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 18 Jun 2014 13:44:24 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s5IKiMn31609; Wed, 18 Jun 2014 13:44:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201406182044.s5IKiMn31609@magenta.juniper.net> To: Qin Wu In-Reply-To: References: X-MH-In-Reply-To: Qin Wu message dated "Wed, 18 Jun 2014 11:30:02 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11459.1403124262.1@juniper.net> Date: Wed, 18 Jun 2014 13:44:22 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(199002)(13464003)(189002)(51704005)(252514010)(66654002)(31966008)(83322001)(16796002)(95666004)(74662001)(19580395003)(92726001)(68736004)(19580405001)(6806004)(87936001)(46406003)(86362001)(83072002)(79102001)(44976005)(54356999)(69596002)(76482001)(85852003)(20776003)(50986999)(76176999)(81342001)(85306003)(99396002)(47776003)(4396001)(97736001)(97756001)(46102001)(23726002)(15975445006)(81542001)(50466002)(102836001)(74502001)(92566001)(77982001)(84676001)(80022001)(81156003)(64706001)(105596002)(21056001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB106; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02462830BE Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/V1qT3ew08mzyPrII7l2QGKF27Ug Cc: "mpls@ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-seamless-mcast 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, 18 Jun 2014 20:44:35 -0000 Qin, > Hi, authors: > I have read this draft and believe it is well written and ready for going for > publication. Many thanks for your review and comments. > Here are a few editorial comments: > 1. Section 3, the 10th paragraph said: > " > The backbone area segment has as its leaves ABRs that are > connected to the egress area(s) or PEs in the backbone area, or ASBRs > in the backbone area. > " > [Qin]: what does "has as its leaves ABRs" mean? Should it be "has its leaves > ABRs" Sure. > 2. Section 3, the 11th paragraph said: > " > The egress area segment is rooted at an ABR in the egress area > (egress ABR), and has as its leaves PEs and ASBR in that egress area > (the latter covers the case where the P2MP service LSP spans multiple > ASes). > " > [Qin]: s/has as/has Sure. > > 3. Section 6.2.3, the 2nd paragraph said: > " > The upstream node's address is as > determined in section 6.1 ("Determining the Upstream ABR/PE/ASBR > (Upstream Node)"). > " > [Qin]: For consistency, would it be good to rephrase as > " > The upstream node's address is > determined as specified section 6.1 ("Determining the Upstream ABR/PE/ASBR > (Upstream Node)"). > " Sure. > 4. Section 6.3.1.1 said: > " > Similarly > whenever as a result of receiving MSDP messages a PE, that is not > configured as a RP, discovers a new multicast source the PE SHOULD > originate a BGP Source Active A-D route. > " > [Qin]: s/ messages a PE, that is not/ messages, a PE that is not Sure. > 5. Section 6.3.1.2 said: > " > When as a result of receiving PIM or IGMP messages on one of its IP > multicast interfaces an (egress) PE creates in its Tree Information > " > [Qin]: why "(egress) PE" not "egress PE"? does PE includes other > type of PE as well? I'll delete the parenthesis. > 6. Section 12 said: > " > By default if the received S-PMSI A-D route carries the > Inter-area P2MP Segmented Next-Hop Extended Community, then the > originated S-PMSI A-D route SHOULD also carry this community. > " > [Qin]: Why SHOULD not MUST? > What if the community is not carried in the originated S-PMSI A-D route? Note that "SHOULD" applies to the *default* behavior. In fact, the previous sentence makes its clear that it should be possible to override the default behavior via config: the V-hub SHOULD be able to control via configuration whether the Inter-area P2MP Segmented Next-Hop Extended Community, if present in the received S-PMSI A-D route, be also carried in the originated S-PMSI A-D route. Thus it should be possible via config for the originated S-PMSI A-D routes *not* to carry the community. > > 7. Section 13.3 said: > " > An Ingress PE must perform application specific forwarding procedures > to identify the outgoing inta-area segment of an incoming packet. > " > [Qin]: s/inta-area/intra-area Sure. > > 8. Section 14 said: > " > 14. Support for Inter-Area Transport LSPs > > This section describes OPTIONAL procedures that allow to aggregate > multiple (inter-area) P2MP service LSPs into a single inter-area P2MP > transport LSP, and then apply the segmentation procedures, as > specified in this document, to these inter-area P2MP transport LSPs > (rather than applying these procedures directly to the inter-area > P2MP service LSPs). > " > [Qin]: since the procedures proposed in section 14 is optional, why not move > these procedures to appendix of this document? I don't think there are rules that say that optional procedures should be moved to the appendix. However, I don't have a strong opinion on this. Given all this, I'd like WG chairs advise on whether to keep the text in its present place, or move it to an appendix. Yakov. > > > -------- Original Message -------- > Subject: Working group last call on draft-ietf-mpls-seamless-mcast > Date: Mon, 09 Jun 2014 05:24:37 +0200 > From: Loa Andersson > To: mpls@ietf.org > CC: draft-ietf-mpls-seamless-mcast@tools.ietf.org > , > mpls-chairs@tools.ietf.org , VIGOUREUX, MARTIN ( MARTIN) > > Working Group, > > This is to initiate a two week working group last call on draft-ietf-mpls-sea mless-mcast. > > There are one IPR disclosure against this document. The authors has stated th at he is unaware of any other IPRs that relate to this document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends June 23, 2014. > > /Loa > for the MPLS wg chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jun 18 13:58:39 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D241A030E for ; Wed, 18 Jun 2014 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOEhJNKZmKuP for ; Wed, 18 Jun 2014 13:58:35 -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 F10AD1A030A for ; Wed, 18 Jun 2014 13:58:34 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-56-53a1ac4bf13c Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9C.F4.27529.B4CA1A35; Wed, 18 Jun 2014 17:12:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 16:58:33 -0400 From: Gregory Mirsky To: "John G. Scudder" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt Thread-Index: AQHPizDy0Aoj122gjk2cxL27MtvAyZt3V0uQ Date: Wed, 18 Jun 2014 20:58:33 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7DC871@eusaamb103.ericsson.se> References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> In-Reply-To: <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPlK73moXBBtefKVjMvPGV1eL7pSUs FreWrmR1YPZYsuQnk8f1pqvsHl8uf2YLYI7isklJzcksSy3St0vgyui7vpmp4JhoxaTlt1ga GJ8KdjFyckgImEhM/tjGBGGLSVy4t56ti5GLQ0jgKKPE2iuzWSCc5YwS/at6WECq2ASMJF5s 7GEHSYgItDJKrHraxdzFyMEhLJAg8eV3MUiNiECixPuOa2wgYRGg+ser6kHCLAKqEhM2PGIG sXkFfCVmnd/LCmILCZRJ9LVuAjuCU8Be4vTdL2A1jEAHfT+1BizOLCAucevJfKhDBSSW7DnP DGGLSrx8/I8VwlaS+Ph7PjtEvY7Egt2f2CBsbYllC19D7RWUODnzCcsERtFZSMbOQtIyC0nL LCQtCxhZVjFylBanluWmGxlsYgRGyDEJNt0djHteWh5iFOBgVOLhTZi9MFiINbGsuDL3EKM0 B4uSOO+s2nnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg9ZhpG9CXG7E6fsczkZmCOzDSO vYcq3u9JNxL4vst/ylzlcE3Obb7rGRiY54duCH5XkaV9wte071zN5bpi62aF1zKcEjMaY0pO 9n8Pfbxcb/fMUzkCFn/CIj8afw03k5ubd67w2g8OS0UXPonL325M7rliIjbtq/Alvpi1R5xc C+5ochtcfKLEUpyRaKjFXFScCAB+PYNacQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Qtls2OEidtjZ_5JN9J7YeGfrydg Subject: Re: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 20:58:37 -0000 Hi John, et. al, if the problem been identified, ELC may not be removed by EL-incapable rout= er, and the fix is on its way, why not to address the issue through errata = process? Or the plan is not to have BGP ELC attribute altogether? Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, June 18, 2014 1:07 PM To: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entro= py-label-00.txt Folks, I would like to request MPLS WG adoption of this draft. I'm hoping we can p= rogress it expeditiously. The only action it takes is to deprecate the BGP = Entropy Label Capabilty path attribute as defined in RFC 6790 S. 5.2. Note that it's extremely short (3 pages including the usual boilerplate, so= about one page of content). Thanks, --John Begin forwarded message: > From: > Subject: New Version Notification for=20 > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > Date: June 18, 2014 at 2:11:36 PM EDT > To: John G.Scudder , Kireeti Kompella=20 > , Kireeti Kompella , John=20 > Scudder >=20 >=20 > A new version of I-D,=20 > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > has been successfully submitted by John G. Scudder and posted to the=20 > IETF repository. >=20 > Name: draft-scudder-mpls-deprecate-bgp-entropy-label > Revision: 00 > Title: Deprecation of BGP Entropy Label Capability Attribute > Document date: 2014-06-17 > Group: Individual Submission > Pages: 3 > URL: http://www.ietf.org/internet-drafts/draft-scudder-mpls-de= precate-bgp-entropy-label-00.txt > Status: https://datatracker.ietf.org/doc/draft-scudder-mpls-depre= cate-bgp-entropy-label/ > Htmlized: http://tools.ietf.org/html/draft-scudder-mpls-deprecate-b= gp-entropy-label-00 >=20 >=20 > Abstract: > RFC 6790 defines the BGP Entropy Label Capability attribute. > Regrettably, it has a bug: although RFC 6790 mandates that Entropy > Label-incapable routers must remove the attribute, in practice this > requirement can't be guaranteed to be fulfilled. This specification > deprecates the attribute. A forthcoming document will propose a > replacement. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jun 18 14:12:31 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C661A0314 for ; Wed, 18 Jun 2014 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQlsYPYKfhgj for ; Wed, 18 Jun 2014 14:12:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4431A0195 for ; Wed, 18 Jun 2014 14:12:26 -0700 (PDT) Received: from hjohnson-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 18 Jun 2014 21:12:18 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7DC871@eusaamb103.ericsson.se> Date: Wed, 18 Jun 2014 17:12:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> <7347100B5761DC41A166AC17F22DF1121B7DC871@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR05CA003.namprd05.prod.outlook.com (10.141.96.23) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02462830BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(377424004)(377454003)(189002)(199002)(24454002)(13464003)(51704005)(19580395003)(92726001)(92566001)(81342001)(77982001)(83322001)(62966002)(21056001)(85852003)(19580405001)(83072002)(69596002)(102836001)(50226001)(4396001)(74502001)(31966008)(74662001)(95666004)(101416001)(77156001)(15975445006)(97756001)(46102001)(23726002)(82746002)(99396002)(57306001)(76482001)(53416004)(36756003)(83716003)(50986999)(76176999)(105586002)(81542001)(77096002)(50466002)(104166001)(33656002)(89996001)(46406003)(80022001)(86362001)(85306003)(93916002)(79102001)(20776003)(88136002)(64706001)(47776003)(87286001)(15202345003)(81156003)(42186005)(66066001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:hjohnson-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RR9wJPvmX58FmBPAzwrTscmCZvM Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 21:12:29 -0000 Hi Greg, The guidance I got from the ADs was that an erratum isn't suitable for = this kind of issue. It's to be used for stuff more like a typographical = error, or at worst an omission of the authors to properly express what = the WG consensus was.=20 The reason for having a "deprecate" draft to be followed by a fix draft, = instead of combining the two, is that it seems time is of the essence = for the "deprecate" step (to make sure implementors know there is an = issue) and it seems reasonable to hope for quick WG consensus and = advancement of that step, which would let IANA update the registry. It = will probably take somewhat longer -- though I hope not too long -- to = advance a replacement.=20 (In the past I have watched an AD try to "save work" by getting IANA to = update a registry without an enabling RFC. Suffice it to say the AD did = not save any work.) The plan is still to have a BGP ELC attribute, but one that doesn't have = the bug described in the deprecate draft. Thanks, --John On Jun 18, 2014, at 4:58 PM, Gregory Mirsky = wrote: > Hi John, et. al, > if the problem been identified, ELC may not be removed by EL-incapable = router, and the fix is on its way, why not to address the issue through = errata process? Or the plan is not to have BGP ELC attribute altogether? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Wednesday, June 18, 2014 1:07 PM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] adoption request for = draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >=20 > Folks, >=20 > I would like to request MPLS WG adoption of this draft. I'm hoping we = can progress it expeditiously. The only action it takes is to deprecate = the BGP Entropy Label Capabilty path attribute as defined in RFC 6790 S. = 5.2. >=20 > Note that it's extremely short (3 pages including the usual = boilerplate, so about one page of content). >=20 > Thanks, >=20 > --John >=20 > Begin forwarded message: >=20 >> From: >> Subject: New Version Notification for=20 >> draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >> Date: June 18, 2014 at 2:11:36 PM EDT >> To: John G.Scudder , Kireeti Kompella=20 >> , Kireeti Kompella , John=20= >> Scudder >>=20 >>=20 >> A new version of I-D,=20 >> draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >> has been successfully submitted by John G. Scudder and posted to the=20= >> IETF repository. >>=20 >> Name: draft-scudder-mpls-deprecate-bgp-entropy-label >> Revision: 00 >> Title: Deprecation of BGP Entropy Label Capability = Attribute >> Document date: 2014-06-17 >> Group: Individual Submission >> Pages: 3 >> URL: = http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-entro= py-label-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entropy-= label/ >> Htmlized: = http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-label-= 00 >>=20 >>=20 >> Abstract: >> RFC 6790 defines the BGP Entropy Label Capability attribute. >> Regrettably, it has a bug: although RFC 6790 mandates that Entropy >> Label-incapable routers must remove the attribute, in practice this >> requirement can't be guaranteed to be fulfilled. This specification >> deprecates the attribute. A forthcoming document will propose a >> replacement. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jun 18 18:30:33 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3EA1A025C for ; Wed, 18 Jun 2014 18:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImUdwgXwsvmA for ; Wed, 18 Jun 2014 18:30: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 E10481A0087 for ; Wed, 18 Jun 2014 18:30:29 -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 BIO82140; Thu, 19 Jun 2014 01:30:28 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 02:30:27 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 09:30:21 +0800 From: Qin Wu To: Yakov Rekhter Thread-Topic: [mpls] Working group last call on draft-ietf-mpls-seamless-mcast Thread-Index: AQHPizYk9pN5dD7KzU6WHc85AanJU5t3pL8w Date: Thu, 19 Jun 2014 01:30:20 +0000 Message-ID: References: <201406182044.s5IKiMn31609@magenta.juniper.net> In-Reply-To: <201406182044.s5IKiMn31609@magenta.juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/uJmPknUZXpjSdBZABojiVf6mBxc Cc: "mpls@ietf.org" Subject: Re: [mpls] Working group last call on draft-ietf-mpls-seamless-mcast 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, 19 Jun 2014 01:30:32 -0000 > 6. Section 12 said: > " > By default if the received S-PMSI A-D route carries the > Inter-area P2MP Segmented Next-Hop Extended Community, then the > originated S-PMSI A-D route SHOULD also carry this community. > " > [Qin]: Why SHOULD not MUST? > What if the community is not carried in the originated S-PMSI A-D route? Note that "SHOULD" applies to the *default* behavior. In fact, the previous= sentence makes its clear that it should be possible to override the defaul= t behavior via config: the V-hub SHOULD be able to control via configuration whether the Inter-area P2MP Segmented Next-Hop Extended Community, if present in the received S-PMSI A-D route, be also carried in the originated S-PMSI A-D route. Thus it should be possible via config for the originated S-PMSI A-D routes = *not* to carry the community. [Qin]: Make sense to me, thanks for your clarification. >=20 > 8. Section 14 said: > " > 14. Support for Inter-Area Transport LSPs >=20 > This section describes OPTIONAL procedures that allow to aggregate > multiple (inter-area) P2MP service LSPs into a single inter-area P2MP > transport LSP, and then apply the segmentation procedures, as > specified in this document, to these inter-area P2MP transport LSPs > (rather than applying these procedures directly to the inter-area > P2MP service LSPs). > " > [Qin]: since the procedures proposed in section 14 is optional, why=20 > not move these procedures to appendix of this document? I don't think there are rules that say that optional procedures should be m= oved to the appendix. However, I don't have a strong opinion on this. Given all this, I'd like WG chairs advise on whether to keep the text in it= s present place, or move it to an appendix. [Qin]: You are right, I have no objection to either of your proposals. Yakov. >=20 >=20 > -------- Original Message -------- > Subject: Working group last call on draft-ietf-mpls-seamless-mcast > Date: Mon, 09 Jun 2014 05:24:37 +0200 > From: Loa Andersson > To: mpls@ietf.org > CC: draft-ietf-mpls-seamless-mcast@tools.ietf.org > , > mpls-chairs@tools.ietf.org , VIGOUREUX,=20 > MARTIN ( MARTIN) >=20 > Working Group, >=20 > This is to initiate a two week working group last call on=20 > draft-ietf-mpls-sea mless-mcast. >=20 > There are one IPR disclosure against this document. The authors has=20 > stated th at he is unaware of any other IPRs that relate to this document. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > This working group last call ends June 23, 2014. >=20 > /Loa > for the MPLS wg chairs > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jun 18 20:31:09 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A151A01D5 for ; Wed, 18 Jun 2014 20:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8dncBOD45On for ; Wed, 18 Jun 2014 20:31:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEF71A0076 for ; Wed, 18 Jun 2014 20:30:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO79839; Thu, 19 Jun 2014 03:30:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 04:30:58 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 11:30:51 +0800 From: Xuxiaohu To: "John G. Scudder" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt Thread-Index: AQHPizDuFn0YlXitcUCs4+OYduBQD5t3wYpA Date: Thu, 19 Jun 2014 03:30:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828349E@NKGEML512-MBS.china.huawei.com> References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> In-Reply-To: <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/pGDmIAEyS0wYybfHAw9I9APBHgM Subject: Re: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 03:31:08 -0000 Hi John, If I understand it correctly, the BGP EL capability is only applicable to l= abeled BGP [RFC3701], it means the EL will be always inserted below the lab= el advertised by the labeled BGP, rather than the label of the LSP destined= for the intermediate BGP nexthop. In other words, the label advertised by = the labeled BGP would not be popped by the intermediate node modifying the = next hop of a labeled bgp route, as a result, it doesn't require that node = to process the EL. Hence, no matter the intermediate node modifying the nex= t hop of a labeled bgp route is capable of processing ELs or not, it's safe= for it to process the EL attribute as a normal optional, transitive attrib= utes. Did I miss something? Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Thursday, June 19, 2014 4:07 AM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] adoption request for > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >=20 > Folks, >=20 > I would like to request MPLS WG adoption of this draft. I'm hoping we can > progress it expeditiously. The only action it takes is to deprecate the B= GP Entropy > Label Capabilty path attribute as defined in RFC 6790 S. 5.2. >=20 > Note that it's extremely short (3 pages including the usual boilerplate, = so about > one page of content). >=20 > Thanks, >=20 > --John >=20 > Begin forwarded message: >=20 > > From: > > Subject: New Version Notification for > > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > > Date: June 18, 2014 at 2:11:36 PM EDT > > To: John G.Scudder , Kireeti Kompella > > , Kireeti Kompella , John > > Scudder > > > > > > A new version of I-D, > > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > > has been successfully submitted by John G. Scudder and posted to the > > IETF repository. > > > > Name: draft-scudder-mpls-deprecate-bgp-entropy-label > > Revision: 00 > > Title: Deprecation of BGP Entropy Label Capability Attribute > > Document date: 2014-06-17 > > Group: Individual Submission > > Pages: 3 > > URL: > http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-entr= opy > -label-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entropy= -lab > el/ > > Htmlized: > http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-label= -00 > > > > > > Abstract: > > RFC 6790 defines the BGP Entropy Label Capability attribute. > > Regrettably, it has a bug: although RFC 6790 mandates that Entropy > > Label-incapable routers must remove the attribute, in practice this > > requirement can't be guaranteed to be fulfilled. This specification > > deprecates the attribute. A forthcoming document will propose a > > replacement. > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jun 18 20:57:07 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B0F1A00F8 for ; Wed, 18 Jun 2014 20:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz_Mdin77GOL for ; Wed, 18 Jun 2014 20:57:00 -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 E53881A00FB for ; Wed, 18 Jun 2014 20:56:59 -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 BFO81197; Thu, 19 Jun 2014 03:56:58 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Jun 2014 04:56:57 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 19 Jun 2014 11:56:54 +0800 From: Xuxiaohu To: "John G. Scudder" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt Thread-Index: AQHPizDuFn0YlXitcUCs4+OYduBQD5t3ydFQ Date: Thu, 19 Jun 2014 03:56:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082834B7@NKGEML512-MBS.china.huawei.com> References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> In-Reply-To: <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Th45rpsR9vyCyGYuQt6yfKOufb4 Subject: Re: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 03:57:03 -0000 Hi John, "For correct operation, it is necessary that an intermediate node modifying the next hop of a route must remove the ELCA unless the node so doing is able to process entropy labels." The above argument quoted from your above draft seems not in accordance wit= h that of RFC6790 (see below): "However, if T changes the NEXT_HOP attribute for U and in the data plane pops the entire label stack to process the payload, T MAY include an ELC attribute for UPDATE U' if both of the following are true: C1: T sets the NEXT_HOP attribute of U' to itself AND C2: T can process entropy labels. Otherwise, T MUST remove the ELC attribute." BTW, I'm wondering in which REAL case an intermediate node modifying the ne= xt hop of a labeled BGP route needs to pop the entire label stack. Best regards, Xiaohu -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Thursday, June 19, 2014 4:07 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org Subject: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entro= py-label-00.txt Folks, I would like to request MPLS WG adoption of this draft. I'm hoping we can p= rogress it expeditiously. The only action it takes is to deprecate the BGP = Entropy Label Capabilty path attribute as defined in RFC 6790 S. 5.2. Note that it's extremely short (3 pages including the usual boilerplate, so= about one page of content). Thanks, --John Begin forwarded message: > From: > Subject: New Version Notification for=20 > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > Date: June 18, 2014 at 2:11:36 PM EDT > To: John G.Scudder , Kireeti Kompella=20 > , Kireeti Kompella , John=20 > Scudder >=20 >=20 > A new version of I-D,=20 > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > has been successfully submitted by John G. Scudder and posted to the=20 > IETF repository. >=20 > Name: draft-scudder-mpls-deprecate-bgp-entropy-label > Revision: 00 > Title: Deprecation of BGP Entropy Label Capability Attribute > Document date: 2014-06-17 > Group: Individual Submission > Pages: 3 > URL: http://www.ietf.org/internet-drafts/draft-scudder-mpls-de= precate-bgp-entropy-label-00.txt > Status: https://datatracker.ietf.org/doc/draft-scudder-mpls-depre= cate-bgp-entropy-label/ > Htmlized: http://tools.ietf.org/html/draft-scudder-mpls-deprecate-b= gp-entropy-label-00 >=20 >=20 > Abstract: > RFC 6790 defines the BGP Entropy Label Capability attribute. > Regrettably, it has a bug: although RFC 6790 mandates that Entropy > Label-incapable routers must remove the attribute, in practice this > requirement can't be guaranteed to be fulfilled. This specification > deprecates the attribute. A forthcoming document will propose a > replacement. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jun 18 23:33:23 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244A21A0324 for ; Wed, 18 Jun 2014 23:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-2XptTN3Pwf for ; Wed, 18 Jun 2014 23:33:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E251A031D for ; Wed, 18 Jun 2014 23:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1403159599; x=1404369199; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TOvx1aqvFr5IUwb02eq0/tYXWTnB0QCJfEJEcgtrpRc=; b=OTfBPw/WSOdKFGPcM3BWPzG73wGRQmiDo/2DTcrt2NvEfntJ+cz47fzU wL5xIOMeRaSv46t0txbSZpUpSlZaZaIdImlo1enEhnnciiNEeIWhXWBnQ jV5+3Ej1IFZq81DFYgF0HvaCqVEUp7FIckV7a055rm8eEDFtMd25/KPrk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAPeDolOtJssW/2dsb2JhbABark8BAgEBBQGZJwGBIXWEAwEBAQMBawMGBQUJAgtGGzwGE4g6CM4BFwSFXogyEAIBHDMHgy2BFgEDmkOTWINEOw X-IronPort-AV: E=Sophos;i="5.01,505,1400025600"; d="scan'208";a="86364353" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 19 Jun 2014 06:33:09 +0000 Received: from ams-iwijnand-8719.cisco.com (ams-iwijnand-8719.cisco.com [10.55.191.154]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5J6X8Zt016965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2014 06:33:08 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: IJsbrand Wijnands In-Reply-To: <53A10938.1010602@pi.nu> Date: Thu, 19 Jun 2014 08:33:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C7B92DB-EC56-462F-941E-AEA1C986C47F@cisco.com> References: <53A10938.1010602@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2naRQ2x4Tyc00mNzHUC8AfM40yc Cc: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-mldp-node-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, 19 Jun 2014 06:33:21 -0000 Hi Folks, I don=92t know of any IPR other then already disclosed. Thx, Ice. On 18 Jun 2014, at 05:36, Loa Andersson wrote: > Working Group, >=20 > We have started the wglc draft-ietf-mpls-mldp-node-protection. When > we did the wg adoption poll on this document (about a year ago) we > did an IPR poll on the individual document. Before we progress the > document after addressing wglc comment we want to do an IPR poll on > the working group document. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-mldp-node- > protection? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are two IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond = to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The = document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 19 01:12:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380291A035C for ; Thu, 19 Jun 2014 01:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIhrrwI9s068 for ; Thu, 19 Jun 2014 01:11:54 -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 ABE181A035A for ; Thu, 19 Jun 2014 01:11:53 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2289918013E2; Thu, 19 Jun 2014 10:11:50 +0200 (CEST) Message-ID: <53A29B3E.7030903@pi.nu> Date: Thu, 19 Jun 2014 10:11:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: erosen@cisco.com References: <9144.1403103270@erosen-lnx> In-Reply-To: <9144.1403103270@erosen-lnx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MOjpyYxZ28W28DqzkR3UZEpM7Ew Cc: "mpls@ietf.org" , draft-ietf-mpls-mldp-node-protection@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-mldp-node-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, 19 Jun 2014 08:12:02 -0000 Eric, tnx - I think I get this, the question I have now I try to capture in the figures below. Assume a mp2mp tree like this. A / \ / \ B C /| |\ / | | \ D E F G /| | | |\ / | | | | \ H I J K L M Assume the for a particular packet "G" is the ingress, G will replicate the packet and send it to L and M, and to C. C will send to it to F to be passed to K, C will also send to A. A will send it to B and eventually it will reach D, E, H, I and J. If node A fails, a bypass will be established between, and the tree will look like this: A B-----C /| |\ / | | \ D E F G /| | | |\ / | | | | \ H I J K L M One observation is that with respect to the packet using G as ingress, G is the root. The only change here is that C does not send the packet to A, but to B, i.e. with respect to traffic there are no unique functions performed by the root. I think this aligns with what you said about mp2mp root protection. However, if A has a third child. A----------------+ / \ | / \ | B C N /| |\ |\ / | | \ | \ D E F G O P /| | | |\ | |\ / | | | | \ | | \ H I J K L M Q R S Why isn't it enough that C (or B) establishes the bypass to N, like this: A B-----C-------------N /| |\ |\ / | | \ | \ D E F G O P /| | | |\ | |\ / | | | | \ | | \ H I J K L M Q R S You seem to say that we need this: A +-------------------+ | | B-----C-------------N /| |\ |\ / | | \ | \ D E F G O P /| | | |\ | |\ / | | | | \ | | \ H I J K L M Q R S Why is that? /Loa PS Sometimes I think there is an easy answer, but it keeps escaping me :( /Loa On 2014-06-18 16:54, Eric Rosen wrote: > Loa> I've a question on the definition of "root node" for mp2mp networks. > > RFC6388 defines "root node" for an MP2MP LSP. > > An MP2MP LSP is a tree, and as a tree it has a root node. However, the root > node is not necessarily an ingress or egress node; any node can be an > ingress, and any node can be an egress. Traffic from an ingress node > travels both downstream from the ingress and upstream towards the root. > When the traffic reaches the root, it travels downstream from the root on > all branches other than the one from which the root received the traffic. > > Loa> I think there are two models > > No, RFC6388 doesn't have two models, and the model it does have is neither > of the two below. > > Loa> 1. the mp2mp network have ingress nodes and egress nodes, an ingress > Loa> node send traffic to all egress nodes, thus acting as a root node on > Loa> a for an p2mp network. > > This description confuses the "root node" (the only node in the tree that is > not a child of any other node) with an "ingress node" (a node that puts > traffic onto the tree.) In a P2MP LSP, the only ingress point to the tree > is the root node, but that's not true in MP2MP LSPs. > > Loa> 2. the mp2mp network have ingress nodes, egress node and one (active) > Loa> root node. The ingress node send traffic to the root node, which > Loa> send the traffic to all the egress nodes. > > If I understand correctly, this model requires the ingress to unicast to the > root, and then requires the root to multicast down a P2MP tree. In general, > this model does not work for MPLS. In this model, if a given node is both a > sender and a receiver, it will receive its own traffic back, with no way to > detect that it has already seen the traffic. This will result in traffic > duplication. > > Loa> Which model is assumed in draft-ietf-mpls-mldp-node-protection? > > The RFC6388 MP2MP LSP model. > -- 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 Jun 19 03:12:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0441A0139 for ; Thu, 19 Jun 2014 03:12:05 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 acckRW6DqWWf for ; Thu, 19 Jun 2014 03:12:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B871A00F0 for ; Thu, 19 Jun 2014 03:11:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E6E8C324397; Thu, 19 Jun 2014 12:11:57 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C9A7023806E; Thu, 19 Jun 2014 12:11:57 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 12:11:57 +0200 From: To: Xuxiaohu Thread-Topic: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt Thread-Index: AQHPizDuFn0YlXitcUCs4+OYduBQD5t3wYpAgABOVhA= Date: Thu, 19 Jun 2014 10:11:56 +0000 Message-ID: <31786_1403172717_53A2B76D_31786_3376_1_53C29892C857584299CBF5D05346208A07164D4A@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828349E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828349E@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.93024 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/66pOqaIm_hjhCn9LyMBEia4kbig Cc: "mpls@ietf.org" Subject: Re: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 10:12:05 -0000 Hi Xiaohu, Please see some comments inline > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: T= hursday, June 19, 2014 5:31 AM >=20 > Hi John, >=20 > If I understand it correctly, the BGP EL capability is only applicable to= labeled > BGP [RFC3701], Which includes 6PE routes (as per RFC 4798) which could be used by AS1. Suc= h labeled routes may be transported unlabeled in the Internet across AS2. A= nd then labeled back in AS3 also using 6PE. As per RFC 6790, if AS2 and the egress ASBR in AS3 do not support BGP EL at= tribute, the BGP attribute will be tunneled up to the ingress ASBR in AS3. If the ingress supports EL, it will add the EL labels and the egress ASBR i= n AS3 will drop the traffic, even though all ASes did valid things. Possibly same issues with IP VPNs (customer/CE using 6PE routes, SP/PE usin= g VPN routes) Best regards, Bruno > it means the EL will be always inserted below the label > advertised by the labeled BGP, rather than the label of the LSP destined = for > the intermediate BGP nexthop. In other words, the label advertised by the > labeled BGP would not be popped by the intermediate node modifying the > next hop of a labeled bgp route, as a result, it doesn't require that nod= e to > process the EL. Hence, no matter the intermediate node modifying the next > hop of a labeled bgp route is capable of processing ELs or not, it's safe= for it to > process the EL attribute as a normal optional, transitive attributes. Did= I miss > something? >=20 > Best regards, > Xiaohu >=20 >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder > > Sent: Thursday, June 19, 2014 4:07 AM > > To: mpls@ietf.org; mpls-chairs@tools.ietf.org > > Subject: [mpls] adoption request for > > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > > > > Folks, > > > > I would like to request MPLS WG adoption of this draft. I'm hoping we > > can progress it expeditiously. The only action it takes is to > > deprecate the BGP Entropy Label Capabilty path attribute as defined in = RFC > 6790 S. 5.2. > > > > Note that it's extremely short (3 pages including the usual > > boilerplate, so about one page of content). > > > > Thanks, > > > > --John > > > > Begin forwarded message: > > > > > From: > > > Subject: New Version Notification for > > > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > > > Date: June 18, 2014 at 2:11:36 PM EDT > > > To: John G.Scudder , Kireeti Kompella > > > , Kireeti Kompella , John > > > Scudder > > > > > > > > > A new version of I-D, > > > draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt > > > has been successfully submitted by John G. Scudder and posted to the > > > IETF repository. > > > > > > Name: draft-scudder-mpls-deprecate-bgp-entropy-label > > > Revision: 00 > > > Title: Deprecation of BGP Entropy Label Capability Attribute > > > Document date: 2014-06-17 > > > Group: Individual Submission > > > Pages: 3 > > > URL: > > http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-e > > ntropy > > -label-00.txt > > > Status: > > https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entr > > opy-lab > > el/ > > > Htmlized: > > http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-la > > bel-00 > > > > > > > > > Abstract: > > > RFC 6790 defines the BGP Entropy Label Capability attribute. > > > Regrettably, it has a bug: although RFC 6790 mandates that Entropy > > > Label-incapable routers must remove the attribute, in practice this > > > requirement can't be guaranteed to be fulfilled. This specification > > > deprecates the attribute. A forthcoming document will propose a > > > replacement. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jun 19 12:31:28 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CF11A03E4 for ; Thu, 19 Jun 2014 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 D4KpG-APi9Pk for ; Thu, 19 Jun 2014 12:31:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B8C491A0145 for ; Thu, 19 Jun 2014 12:31:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D99B81801C0; Thu, 19 Jun 2014 12:30:04 -0700 (PDT) To: sboutros@cisco.com, msiva@cisco.com, raggarwa_1@yahoo.com, martin.vigoureux@alcatel-lucent.com, dai.xuehui@zte.com.cn, akatlas@gmail.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140619193004.D99B81801C0@rfc-editor.org> Date: Thu, 19 Jun 2014 12:30:04 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/eiRkIvmnwKDgVZ4fyF6WZ-_xgtg Cc: mpls@ietf.org, rfc-editor@rfc-editor.org, huubatwork@gmail.com Subject: [mpls] [Editorial Errata Reported] RFC6435 (4017) 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, 19 Jun 2014 19:31:26 -0000 The following errata report has been submitted for RFC6435, "MPLS Transport Profile Lock Instruct and Loopback Functions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=4017 -------------------------------------- Type: Editorial Reported by: Huub van Helvoort Section: 1 Original Text ------------- Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". This document discusses these functions in the context of MPLS networks. Corrected Text -------------- Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". This document discusses these functions in the context of MPLS networks. Further information about these abstract OAM functions in an MPLS Transport Profile context can be found in RFC 6371 [6] where the lock function is referred to as the "Lock Instruct function (LKI)" and the loopback function is called "data-plane loopback." Notes ----- RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document. RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2. This may confuse the reader of both documents. A similar confusion can occur for refering to the loopback function. Instructions: ------------- This errata 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. -------------------------------------- RFC6435 (draft-ietf-mpls-tp-li-lb-08) -------------------------------------- Title : MPLS Transport Profile Lock Instruct and Loopback Functions Publication Date : November 2011 Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Jun 19 12:36:14 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F301A03FF for ; Thu, 19 Jun 2014 12:36:11 -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 cHXMTQufKgWE for ; Thu, 19 Jun 2014 12:36:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484191A019A for ; Thu, 19 Jun 2014 12:36:08 -0700 (PDT) Received: from [172.29.37.252] (66.129.241.10) by BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) with Microsoft SMTP Server (TLS) id 15.0.969.15; Thu, 19 Jun 2014 19:36:05 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082834B7@NKGEML512-MBS.china.huawei.com> Date: Thu, 19 Jun 2014 15:35:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140618181136.21447.80774.idtracker@ietfa.amsl.com> <7A3CC6E4-7C94-4183-971C-89E07FC4EAED@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082834B7@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: DM2PR05CA004.namprd05.prod.outlook.com (10.141.96.24) To BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02475B2A01 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(164054003)(189002)(199002)(377424004)(13464003)(24454002)(51704005)(377454003)(42186005)(50466002)(76176999)(83322001)(19580405001)(19580395003)(50986999)(79102001)(31966008)(77156001)(97756001)(21056001)(50226001)(4396001)(15202345003)(87286001)(88136002)(85852003)(87976001)(83072002)(57306001)(89996001)(101416001)(83716003)(77982001)(62966002)(77096002)(95666004)(105586002)(76482001)(46406003)(85306003)(104166001)(46102001)(81342001)(92726001)(92566001)(99396002)(102836001)(74502001)(81542001)(33656002)(64706001)(47776003)(86362001)(20776003)(66066001)(80022001)(74662001)(82746002)(15975445006)(23726002)(36756003)(93916002)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB726; H:[172.29.37.252]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/QB1Pu_rgf02KzWf7ms0Gkvdaao0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] adoption request for draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 19:36:11 -0000 Hi Xiaohu, Bruno has already replied to your first comment regarding applicability. = I agree with his remarks. As regards the below "not in accordance", that's exactly the point -- = 6790 says "Otherwise, T MUST remove the ELC attribute."" But as Bruno = observes in his email, and as the Internet Draft points out, if T = doesn't support EL (and ELCA) then even though 6790 says "T MUST remove = the ELC attribute", in reality T will NOT remove it. Thus we have a = contradiction between the (per-spec) operation of the BGP protocol, and = the correctness assumptions of 6790 S. 5.2. In such a contradiction = between noble aspirations (6790) and deployed code (what BGP actually = does) the deployed code wins. :-/ Thanks, --John On Jun 18, 2014, at 11:56 PM, Xuxiaohu wrote: > Hi John, >=20 > "For correct operation, it > is necessary that an intermediate node modifying the next hop of a > route must remove the ELCA unless the node so doing is able to > process entropy labels." >=20 > The above argument quoted from your above draft seems not in = accordance with that of RFC6790 (see below): >=20 > "However, if T changes the NEXT_HOP attribute for U and in the data > plane pops the entire label stack to process the payload, T MAY > include an ELC attribute for UPDATE U' if both of the following are > true: >=20 > C1: T sets the NEXT_HOP attribute of U' to itself AND >=20 > C2: T can process entropy labels. >=20 > Otherwise, T MUST remove the ELC attribute." >=20 > BTW, I'm wondering in which REAL case an intermediate node modifying = the next hop of a labeled BGP route needs to pop the entire label stack. >=20 > Best regards, > Xiaohu >=20 >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Thursday, June 19, 2014 4:07 AM > To: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] adoption request for = draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >=20 > Folks, >=20 > I would like to request MPLS WG adoption of this draft. I'm hoping we = can progress it expeditiously. The only action it takes is to deprecate = the BGP Entropy Label Capabilty path attribute as defined in RFC 6790 S. = 5.2. >=20 > Note that it's extremely short (3 pages including the usual = boilerplate, so about one page of content). >=20 > Thanks, >=20 > --John >=20 > Begin forwarded message: >=20 >> From: >> Subject: New Version Notification for=20 >> draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >> Date: June 18, 2014 at 2:11:36 PM EDT >> To: John G.Scudder , Kireeti Kompella=20 >> , Kireeti Kompella , John=20= >> Scudder >>=20 >>=20 >> A new version of I-D,=20 >> draft-scudder-mpls-deprecate-bgp-entropy-label-00.txt >> has been successfully submitted by John G. Scudder and posted to the=20= >> IETF repository. >>=20 >> Name: draft-scudder-mpls-deprecate-bgp-entropy-label >> Revision: 00 >> Title: Deprecation of BGP Entropy Label Capability = Attribute >> Document date: 2014-06-17 >> Group: Individual Submission >> Pages: 3 >> URL: = http://www.ietf.org/internet-drafts/draft-scudder-mpls-deprecate-bgp-entro= py-label-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-scudder-mpls-deprecate-bgp-entropy-= label/ >> Htmlized: = http://tools.ietf.org/html/draft-scudder-mpls-deprecate-bgp-entropy-label-= 00 >>=20 >>=20 >> Abstract: >> RFC 6790 defines the BGP Entropy Label Capability attribute. >> Regrettably, it has a bug: although RFC 6790 mandates that Entropy >> Label-incapable routers must remove the attribute, in practice this >> requirement can't be guaranteed to be fulfilled. This specification >> deprecates the attribute. A forthcoming document will propose a >> replacement. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jun 19 14:12:25 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498601A00E8 for ; Thu, 19 Jun 2014 14:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Jd1SseW-5U for ; Thu, 19 Jun 2014 14:12:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487101A0083 for ; Thu, 19 Jun 2014 14:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6424; q=dns/txt; s=iport; t=1403212343; x=1404421943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Hyt30iG/zKnAgtXhWa65PrWTPqFyvc2iH3fmFAwRC/c=; b=Qwl26adrvBCEY9SGDCeftCNd8FwWSsOHQHReYAeI3z+NDIRi/Qod46Yf WnurEVw2HtyafdbHtHnDUIBk63IGM7nTyJWYBW04XOW8wLrprxND9bNwc IgttUYWTHf7o/B9XyAjIGvsixqqSLnCOrxBO9AWEEM8qXP5oNE6MQ/3xz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8JAOhRo1OtJV2d/2dsb2JhbABZgw1SWrwMgxmEJgGBDxZ1hAMBAQEEAQEBNzEDCw4CAgEIGB4QGwwLJQIEAQ0FiEINzHATBASOBwkRAVAHhEMEmkOTWINCgXc5 X-IronPort-AV: E=Sophos;i="5.01,509,1400025600"; d="scan'208";a="54524192" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 19 Jun 2014 21:12:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5JLCLAF030341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 21:12:21 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.82]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 16:12:20 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Loa Andersson , "Eric Rosen (erosen)" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-mldp-node-protection Thread-Index: AQHPiwU1d39qgeMrYEebgMsvsJGuJpt4afsAgACXCoA= Date: Thu, 19 Jun 2014 21:12:19 +0000 Message-ID: References: <9144.1403103270@erosen-lnx> <53A29B3E.7030903@pi.nu> In-Reply-To: <53A29B3E.7030903@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.68.49] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ihu47h7cERRNjV3cNmaL7hAZkwE Cc: "mpls@ietf.org" , "draft-ietf-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-mldp-node-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, 19 Jun 2014 21:12:24 -0000 Hi Loa, Per my understanding, it may result in disconnected tree incase of ROOT failure. Assume there is one more downstream leg from A as N1-N2-N3 So there are 4 MPTs now (B, C, N and N1) to protect ROOT A. If the intention is to choose any one as PLR and establish the backup LSP, due to any local matter it may result in below: 1. B chooses C as PLR. 2. C chooses B as PLR. 3. N chooses N1 as PLR. 4. N1 chooses N as PLR. Now, the tree will be disconnected during ROOT failure and any traffic flowing from H will not reach N or N1 and downstream and traffic from S will not reach B or C. Thanks, Nagendra On 6/19/14, 4:11 AM, "Loa Andersson" wrote: >Eric, > >tnx - I think I get this, the question I have now I try to capture in >the figures below. > >Assume a mp2mp tree like this. > > > A > / \ > / \ > B C > /| |\ > / | | \ > D E F G > /| | | |\ > / | | | | \ > H I J K L M > >Assume the for a particular packet "G" is the ingress, G will replicate >the packet and send it to L and M, and to C. > >C will send to it to F to be passed to K, C will also send to A. > >A will send it to B and eventually it will reach D, E, H, I and J. > >If node A fails, a bypass will be established between, and the tree >will look like this: > > A > > > B-----C > /| |\ > / | | \ > D E F G > /| | | |\ > / | | | | \ > H I J K L M > >One observation is that with respect to the packet using G as ingress, >G is the root. > >The only change here is that C does not send the packet to A, but to B, >i.e. with respect to traffic there are no unique functions performed by >the root. > >I think this aligns with what you said about mp2mp root protection. > >However, if A has a third child. > > A----------------+ > / \ | > / \ | > B C N > /| |\ |\ > / | | \ | \ > D E F G O P > /| | | |\ | |\ > / | | | | \ | | \ > H I J K L M Q R S > >Why isn't it enough that C (or B) establishes the bypass to N, >like this: > > > A > > > B-----C-------------N > /| |\ |\ > / | | \ | \ > D E F G O P > /| | | |\ | |\ > / | | | | \ | | \ > H I J K L M Q R S > >You seem to say that we need this: > > > A > +-------------------+ > | | > B-----C-------------N > /| |\ |\ > / | | \ | \ > D E F G O P > /| | | |\ | |\ > / | | | | \ | | \ > H I J K L M Q R S > >Why is that? > >/Loa > >PS > >Sometimes I think there is an easy answer, but it keeps escaping me :( > >/Loa > > >On 2014-06-18 16:54, Eric Rosen wrote: >> Loa> I've a question on the definition of "root node" for mp2mp >>networks. >> >> RFC6388 defines "root node" for an MP2MP LSP. >> >> An MP2MP LSP is a tree, and as a tree it has a root node. However, the >>root >> node is not necessarily an ingress or egress node; any node can be an >> ingress, and any node can be an egress. Traffic from an ingress node >> travels both downstream from the ingress and upstream towards the root. >> When the traffic reaches the root, it travels downstream from the root >>on >> all branches other than the one from which the root received the >>traffic. >> >> Loa> I think there are two models >> >> No, RFC6388 doesn't have two models, and the model it does have is >>neither >> of the two below. >> >> Loa> 1. the mp2mp network have ingress nodes and egress nodes, an >>ingress >> Loa> node send traffic to all egress nodes, thus acting as a root >>node on >> Loa> a for an p2mp network. >> >> This description confuses the "root node" (the only node in the tree >>that is >> not a child of any other node) with an "ingress node" (a node that puts >> traffic onto the tree.) In a P2MP LSP, the only ingress point to the >>tree >> is the root node, but that's not true in MP2MP LSPs. >> >> Loa> 2. the mp2mp network have ingress nodes, egress node and one >>(active) >> Loa> root node. The ingress node send traffic to the root node, which >> Loa> send the traffic to all the egress nodes. >> >> If I understand correctly, this model requires the ingress to unicast >>to the >> root, and then requires the root to multicast down a P2MP tree. In >>general, >> this model does not work for MPLS. In this model, if a given node is >>both a >> sender and a receiver, it will receive its own traffic back, with no >>way to >> detect that it has already seen the traffic. This will result in >>traffic >> duplication. >> >> Loa> Which model is assumed in draft-ietf-mpls-mldp-node-protection? >> >> The RFC6388 MP2MP LSP model. >> > >--=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 Thu Jun 19 14:34:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9521A03F4 for ; Thu, 19 Jun 2014 14:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 AjT7-pY_kmnN for ; Thu, 19 Jun 2014 14:33:54 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A461A028C for ; Thu, 19 Jun 2014 14:33:53 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5JLXC8Q029716; Thu, 19 Jun 2014 22:33:12 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5JLXBbT029710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jun 2014 22:33:11 +0100 From: "Adrian Farrel" To: References: <20140619193004.D99B81801C0@rfc-editor.org> In-Reply-To: <20140619193004.D99B81801C0@rfc-editor.org> Date: Thu, 19 Jun 2014 22:33:11 +0100 Message-ID: <085501cf8c06$12c0c770$38425650$@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: AQIzcBwPdfw62p8vttXMhQshOryS5ZqxKw4Q Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20768.002 X-TM-AS-Result: No--12.953-10.0-31-10 X-imss-scan-details: No--12.953-10.0-31-10 X-TMASE-MatchedRID: X4bcv0S75Kkk7QoVXCbROIzb2GR6Ttd3KfcYXeGU/XXSYAzZ6KmqWrBS akBbkYMgJnVY2sLQ1TzBy/tOisWDkAJRed7MoLu/QpxiLlDD9FUhotH7bEpEMs4GSdottRu3wua niM9QXy3tEQTZhWclu/ce7+KBY3mzmyvACBNOXxQ+N0lB+o/v7iwvdvzdTlpZtXl9IxEPXOr5FJ stWNYx/Gsn/Adx3VcWIe/W4/F4k9EEzPD+fJx5yMWUKBjERoYTgRykyfrH1xmhUoducQu06Sdzo HMfZDkVrm27gJgTa2+00HTgX5ZI95UxWI+YhDOFzYxWzZGfzlTUZrYvzuo9AqP4uIZFFmMi2pLu /7SrrfqT/slcnl7UEfrUoUEpWa5USSOWVJeuO1A5f9Xw/xqKXcidYBYDjITp+gD2vYtOFhgqtq5 d3cxkNbBw13yf7RsBNSNnNza0hV1IJXZVrgh+MZDTZ3FJOasRNq51HxaCQ2s= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/POTicI8P-VYvFwenhgDTbcl5izY Cc: dai.xuehui@zte.com.cn, msiva@cisco.com, sboutros@cisco.com, rcallon@juniper.net, raggarwa_1@yahoo.com, huubatwork@gmail.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (4017) 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, 19 Jun 2014 21:33:58 -0000 Working Group, Huub discussed this issue before raising it as an Errata Report. Apparently the difference in terminology between 6371 and 6435 has caused some doubt, and it seems best to make some clarification. The suggested additional paragraph was drafted by be. I believe it conveys the intent of the WG and authors when writing 6435 and does not make any change of substance to the document. Comments welcomed. Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 19 June 2014 20:30 > To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > akatlas@gmail.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > rcallon@juniper.net > Cc: huubatwork@gmail.com; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6435 (4017) > > The following errata report has been submitted for RFC6435, > "MPLS Transport Profile Lock Instruct and Loopback Functions". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=4017 > > -------------------------------------- > Type: Editorial > Reported by: Huub van Helvoort > > Section: 1 > > Original Text > ------------- > Two useful Operations, Administration, and Maintenance (OAM) > functions in a transport network are "lock" and "loopback". This > document discusses these functions in the context of MPLS networks. > > Corrected Text > -------------- > Two useful Operations, Administration, and Maintenance (OAM) > functions in a transport network are "lock" and "loopback". This > document discusses these functions in the context of MPLS networks. > > Further information about these abstract OAM functions in an MPLS > Transport Profile context can be found in RFC 6371 [6] where the > lock function is referred to as the "Lock Instruct function (LKI)" > and the loopback function is called "data-plane loopback." > > Notes > ----- > RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document. > RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2. > This may confuse the reader of both documents. > A similar confusion can occur for refering to the loopback function. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC6435 (draft-ietf-mpls-tp-li-lb-08) > -------------------------------------- > Title : MPLS Transport Profile Lock Instruct and Loopback Functions > Publication Date : November 2011 > Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, > Ed., X. Dai, Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Thu Jun 19 16:00:13 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F191A04BA for ; Thu, 19 Jun 2014 16:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cPm3-wDejUY for ; Thu, 19 Jun 2014 16:00:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8B71A0320 for ; Thu, 19 Jun 2014 16:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4067; q=dns/txt; s=iport; t=1403218808; x=1404428408; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CxYh5xoiLKquXaL/VptqPelH0LY1PWPl1SpvYnrou8w=; b=XZ8WKz/zLamzQCx2szCtShGrXjAjMDH6iYLerkh6NZMhbD8qGT4oJlQ9 kt6MzeUKRKHL/3d9dNfuaqAltBjL/hPV1ElbEmk0pQ7OG+fwzNeT3KH2Q Gji7FF7R1FQVrjwMmSC/2xtZvvtDW/hIZuRS73h8FkEOAiFiY93c/z00b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooFAIhqo1OtJA2D/2dsb2JhbAA/GoMNUqp0AQEBAQEHgQKBVY8Thz8BgQ8WdYQDAQEBAwEBAQE3NBAHBAIBCBEEAQEBHgkHIQYLEwEJCAIEARKILgMJCA02xhcNhkYXhWKDYIIUfYFwOgaDJ4EWBIRjBZNiBoFzjViGAINCbBI X-IronPort-AV: E=Sophos;i="5.01,509,1400025600"; d="scan'208";a="331302711" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jun 2014 23:00:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5JN07VG014184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 23:00:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 18:00:07 -0500 From: "Stewart Bryant (stbryant)" To: "" , "mpls@ietf.org" Thread-Topic: [mpls] [Editorial Errata Reported] RFC6435 (4017) Thread-Index: AQHPi/UXvmv+BsspX0CX0NJvw2dFbpt5SAqA///EePo= Date: Thu, 19 Jun 2014 23:00:06 +0000 Message-ID: <78C3640B-991D-45ED-90D3-64E17368C6F8@cisco.com> References: <20140619193004.D99B81801C0@rfc-editor.org>, <085501cf8c06$12c0c770$38425650$@olddog.co.uk> In-Reply-To: <085501cf8c06$12c0c770$38425650$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/EsGVV7bU4DX4-GtpB1Et0F_01zQ Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (4017) 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, 19 Jun 2014 23:00:10 -0000 This seems a useful to make this clarification. However it would be best start by deciding the preferred name, stating that= and putting the correction in the document that uses the unpreferred name. I have no preference, but it would be nice to make sure the error is not re= peated I some future text by making one authoritative which I don't think t= he proposed text does. -Stewart Sent from my iPad > On 19 Jun 2014, at 22:34, "Adrian Farrel" wrote: >=20 > Working Group, >=20 > Huub discussed this issue before raising it as an Errata Report. >=20 > Apparently the difference in terminology between 6371 and 6435 has caused= some > doubt, and it seems best to make some clarification. >=20 > The suggested additional paragraph was drafted by be. I believe it convey= s the > intent of the WG and authors when writing 6435 and does not make any chan= ge of > substance to the document. >=20 > Comments welcomed. >=20 > Adrian >=20 >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 19 June 2014 20:30 >> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >> akatlas@gmail.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >> rcallon@juniper.net >> Cc: huubatwork@gmail.com; mpls@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC6435 (4017) >>=20 >> The following errata report has been submitted for RFC6435, >> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6435&eid=3D4017 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Huub van Helvoort >>=20 >> Section: 1 >>=20 >> Original Text >> ------------- >> Two useful Operations, Administration, and Maintenance (OAM) >> functions in a transport network are "lock" and "loopback". This >> document discusses these functions in the context of MPLS networks. >>=20 >> Corrected Text >> -------------- >> Two useful Operations, Administration, and Maintenance (OAM) >> functions in a transport network are "lock" and "loopback". This >> document discusses these functions in the context of MPLS networks. >>=20 >> Further information about these abstract OAM functions in an MPLS >> Transport Profile context can be found in RFC 6371 [6] where the >> lock function is referred to as the "Lock Instruct function (LKI)" >> and the loopback function is called "data-plane loopback." >>=20 >> Notes >> ----- >> RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document= . >> RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2. >> This may confuse the reader of both documents. >> A similar confusion can occur for refering to the loopback function. >>=20 >> Instructions: >> ------------- >> This errata 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. >>=20 >> -------------------------------------- >> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >> -------------------------------------- >> Title : MPLS Transport Profile Lock Instruct and Loopback > Functions >> Publication Date : November 2011 >> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, E= d., M. > Vigoureux, >> Ed., X. Dai, Ed. >> 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 >=20 From nobody Thu Jun 19 19:33:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5651A0503; Thu, 19 Jun 2014 19:33: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 8x61i8L1EfZM; Thu, 19 Jun 2014 19:33:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3D1A016E; Thu, 19 Jun 2014 19:33:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620023323.13648.39593.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 19:33:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/okcVdy0kq8li-6hf7-ns6r4tz6o Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-10.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:33:24 -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 : LDP Hello Cryptographic Authentication Authors : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-10.txt Pages : 15 Date : 2014-06-19 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-hello-crypto-auth-10 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 Jun 19 20:13:32 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9444E1A025C for ; Thu, 19 Jun 2014 20:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgNgdxMVK2oS for ; Thu, 19 Jun 2014 20:13: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 F1F831A0515 for ; Thu, 19 Jun 2014 20:13:08 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8ACDC18015A1; Fri, 20 Jun 2014 05:13:02 +0200 (CEST) Message-ID: <53A3A6B9.9000806@pi.nu> Date: Fri, 20 Jun 2014 05:12:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nagendra Kumar Nainar (naikumar)" , "Eric Rosen (erosen)" References: <9144.1403103270@erosen-lnx> <53A29B3E.7030903@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PJWIAnlw4hQKGe1YLKrPV2DX0_Y Cc: "mpls@ietf.org" , "draft-ietf-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-mldp-node-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: Fri, 20 Jun 2014 03:13:22 -0000 Nagendra, Yes you are right! Took me some time to go over the cases. Further comments: 1. Figure 2 does not really explain your point. | (LSR1) . | . . | . . (N) . root . / \ . . / \. (LSR2)....(LSR3) | | Figure 2. N: The MP2MP root node being protected. ...: Backup LSPs between LSR1, LSR2 and LSR3. The tree will be fully connected by only two of the by-pass LSPs. Figure 2 would need to look like this: | | (LSR1)....(LSR4 . \ / . . \ / . . (N) . root . / \ . . / \. (LSR2)....(LSR3) | | And I would like to see some text around this also, one sentence under figure could e.g. be amended like this: In order to protect node N, and in order to avoid partitioning of the MP2MP tree, all the LSRs directly connected to N must participate in protecting node N by acting both as PLR and MPT LSRs. If, as in the case of non-root protection, each LSR just chose one PLR, and LSR 1 and LSR2 chose each other, while LSR3 and LSR4 chose each other the tree will be partioned. Modulo grammar changes by the authors. /Loa On 2014-06-19 23:12, Nagendra Kumar Nainar (naikumar) wrote: > Hi Loa, > > Per my understanding, it may result in disconnected tree incase of ROOT > failure. Assume there is one more downstream leg from A as N1-N2-N3 > > So there are 4 MPTs now (B, C, N and N1) to protect ROOT A. If the > intention is to choose any one as PLR and establish the backup LSP, due to > any local matter it may result in below: > > 1. B chooses C as PLR. > 2. C chooses B as PLR. > 3. N chooses N1 as PLR. > 4. N1 chooses N as PLR. > > Now, the tree will be disconnected during ROOT failure and any traffic > flowing from H will not reach N or N1 and downstream and traffic from S > will not reach B or C. > > Thanks, > Nagendra > > On 6/19/14, 4:11 AM, "Loa Andersson" wrote: > >> Eric, >> >> tnx - I think I get this, the question I have now I try to capture in >> the figures below. >> >> Assume a mp2mp tree like this. >> >> >> A >> / \ >> / \ >> B C >> /| |\ >> / | | \ >> D E F G >> /| | | |\ >> / | | | | \ >> H I J K L M >> >> Assume the for a particular packet "G" is the ingress, G will replicate >> the packet and send it to L and M, and to C. >> >> C will send to it to F to be passed to K, C will also send to A. >> >> A will send it to B and eventually it will reach D, E, H, I and J. >> >> If node A fails, a bypass will be established between, and the tree >> will look like this: >> >> A >> >> >> B-----C >> /| |\ >> / | | \ >> D E F G >> /| | | |\ >> / | | | | \ >> H I J K L M >> >> One observation is that with respect to the packet using G as ingress, >> G is the root. >> >> The only change here is that C does not send the packet to A, but to B, >> i.e. with respect to traffic there are no unique functions performed by >> the root. >> >> I think this aligns with what you said about mp2mp root protection. >> >> However, if A has a third child. >> >> A----------------+ >> / \ | >> / \ | >> B C N >> /| |\ |\ >> / | | \ | \ >> D E F G O P >> /| | | |\ | |\ >> / | | | | \ | | \ >> H I J K L M Q R S >> >> Why isn't it enough that C (or B) establishes the bypass to N, >> like this: >> >> >> A >> >> >> B-----C-------------N >> /| |\ |\ >> / | | \ | \ >> D E F G O P >> /| | | |\ | |\ >> / | | | | \ | | \ >> H I J K L M Q R S >> >> You seem to say that we need this: >> >> >> A >> +-------------------+ >> | | >> B-----C-------------N >> /| |\ |\ >> / | | \ | \ >> D E F G O P >> /| | | |\ | |\ >> / | | | | \ | | \ >> H I J K L M Q R S >> >> Why is that? >> >> /Loa >> >> PS >> >> Sometimes I think there is an easy answer, but it keeps escaping me :( >> >> /Loa >> >> >> On 2014-06-18 16:54, Eric Rosen wrote: >>> Loa> I've a question on the definition of "root node" for mp2mp >>> networks. >>> >>> RFC6388 defines "root node" for an MP2MP LSP. >>> >>> An MP2MP LSP is a tree, and as a tree it has a root node. However, the >>> root >>> node is not necessarily an ingress or egress node; any node can be an >>> ingress, and any node can be an egress. Traffic from an ingress node >>> travels both downstream from the ingress and upstream towards the root. >>> When the traffic reaches the root, it travels downstream from the root >>> on >>> all branches other than the one from which the root received the >>> traffic. >>> >>> Loa> I think there are two models >>> >>> No, RFC6388 doesn't have two models, and the model it does have is >>> neither >>> of the two below. >>> >>> Loa> 1. the mp2mp network have ingress nodes and egress nodes, an >>> ingress >>> Loa> node send traffic to all egress nodes, thus acting as a root >>> node on >>> Loa> a for an p2mp network. >>> >>> This description confuses the "root node" (the only node in the tree >>> that is >>> not a child of any other node) with an "ingress node" (a node that puts >>> traffic onto the tree.) In a P2MP LSP, the only ingress point to the >>> tree >>> is the root node, but that's not true in MP2MP LSPs. >>> >>> Loa> 2. the mp2mp network have ingress nodes, egress node and one >>> (active) >>> Loa> root node. The ingress node send traffic to the root node, which >>> Loa> send the traffic to all the egress nodes. >>> >>> If I understand correctly, this model requires the ingress to unicast >>> to the >>> root, and then requires the root to multicast down a P2MP tree. In >>> general, >>> this model does not work for MPLS. In this model, if a given node is >>> both a >>> sender and a receiver, it will receive its own traffic back, with no >>> way to >>> detect that it has already seen the traffic. This will result in >>> traffic >>> duplication. >>> >>> Loa> Which model is assumed in draft-ietf-mpls-mldp-node-protection? >>> >>> The RFC6388 MP2MP LSP model. >>> >> >> -- >> >> >> 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 >> > -- 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 Jun 20 02:31:27 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4401A035E for ; Fri, 20 Jun 2014 02:31:26 -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 rhQwMxC4pCh4 for ; Fri, 20 Jun 2014 02:31:24 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B011A00B6 for ; Fri, 20 Jun 2014 02:31:24 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so449228wib.17 for ; Fri, 20 Jun 2014 02:31:22 -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=W/DuJ2gmgK3riu8DqcWrfEi9FrkeYh6Ae5AILEDpP6w=; b=WmzIZJ/kozrxF+KQwXWiNyZkrLSCZCBJXxQPcbw3SJLDlshE6AFhX+6MdNTLV7UgRc A8lN5A1DP1ANrBrPdMScSatkbptSMO/6cmPT8r/s8O51v+0B9hHAwK7khYUv0yOMKl1m /1+Es38yPfr/qvdScxy2ny+UwitvQ/oHr3OiHj6BMk+/Y5DdBLInJUPngAKCXMtDkQ+d 3aMmiaLQNr1yza4OT1VJCdbvHtuBtWiFQDCWKB0cUho+aa0dV0PwM6XYIUnBtROuoTJp 8o62uT7VT1AlgNDuzpRcpgbfYai7eHip9Xh7c+3dfOHhgnsLKV1diCV/LYAy5hX/IbNW rsXQ== X-Received: by 10.180.189.44 with SMTP id gf12mr2777256wic.14.1403256682825; Fri, 20 Jun 2014 02:31:22 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id m1sm3033228wib.20.2014.06.20.02.31.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 02:31:22 -0700 (PDT) Message-ID: <53A3FF68.1030506@gmail.com> Date: Fri, 20 Jun 2014 11:31:20 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stewart Bryant (stbryant)" , "" , "mpls@ietf.org" References: <20140619193004.D99B81801C0@rfc-editor.org>, <085501cf8c06$12c0c770$38425650$@olddog.co.uk> <78C3640B-991D-45ED-90D3-64E17368C6F8@cisco.com> In-Reply-To: <78C3640B-991D-45ED-90D3-64E17368C6F8@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/r7r8xKvIceWV6GXcLoR1k0KhqbY Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (4017) 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: Fri, 20 Jun 2014 09:31:26 -0000 Hello Stewart, You reply: > This seems a useful to make this clarification. OK, thanks for the support. > However it would be best start by deciding the preferred name, stating that and putting the correction in the document that uses the unpreferred name. Good suggestion. > I have no preference, but it would be nice to make sure the error is not repeated I some future text by making one authoritative which I don't think the proposed text does. rfc6435 states in section 1.1. "Updates RFC 6371" So most logical is to use "LI", also because if "LKI" is preferred the IANA registry has to be updated. I doubt if that can be done with an erratum. If "LI" is preferred than it may indeed be better to report an erratum against rfc6371 stating that "LI" is preferred. Cheers, Huub. >> On 19 Jun 2014, at 22:34, "Adrian Farrel" wrote: >> >> Working Group, >> >> Huub discussed this issue before raising it as an Errata Report. >> >> Apparently the difference in terminology between 6371 and 6435 has caused some >> doubt, and it seems best to make some clarification. >> >> The suggested additional paragraph was drafted by be. I believe it conveys the >> intent of the WG and authors when writing 6435 and does not make any change of >> substance to the document. >> >> Comments welcomed. >> >> Adrian >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 19 June 2014 20:30 >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>> akatlas@gmail.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >>> rcallon@juniper.net >>> Cc: huubatwork@gmail.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Editorial Errata Reported] RFC6435 (4017) >>> >>> The following errata report has been submitted for RFC6435, >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=4017 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Huub van Helvoort >>> >>> Section: 1 >>> >>> Original Text >>> ------------- >>> Two useful Operations, Administration, and Maintenance (OAM) >>> functions in a transport network are "lock" and "loopback". This >>> document discusses these functions in the context of MPLS networks. >>> >>> Corrected Text >>> -------------- >>> Two useful Operations, Administration, and Maintenance (OAM) >>> functions in a transport network are "lock" and "loopback". This >>> document discusses these functions in the context of MPLS networks. >>> >>> Further information about these abstract OAM functions in an MPLS >>> Transport Profile context can be found in RFC 6371 [6] where the >>> lock function is referred to as the "Lock Instruct function (LKI)" >>> and the loopback function is called "data-plane loopback." >>> >>> Notes >>> ----- >>> RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document. >>> RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2. >>> This may confuse the reader of both documents. >>> A similar confusion can occur for refering to the loopback function. >>> >>> Instructions: >>> ------------- >>> This errata 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. >>> >>> -------------------------------------- >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>> -------------------------------------- >>> Title : MPLS Transport Profile Lock Instruct and Loopback >> Functions >>> Publication Date : November 2011 >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. >> Vigoureux, >>> Ed., X. Dai, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >> _______________________________________________ >> 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 Fri Jun 20 05:28:02 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB71B27AB for ; Fri, 20 Jun 2014 05:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gkuUvRk0MgR for ; Fri, 20 Jun 2014 05:27:56 -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 210341A0769 for ; Fri, 20 Jun 2014 05:27:54 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 65A261802B5C; Fri, 20 Jun 2014 14:27:51 +0200 (CEST) Message-ID: <53A428C4.3020408@pi.nu> Date: Fri, 20 Jun 2014 14:27:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yakov Rekhter , swallow@cisco.com, rcallon@juniper.net References: <201406182028.s5IKS1n21555@magenta.juniper.net> In-Reply-To: <201406182028.s5IKS1n21555@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RGmeyq17NCbDNwJ0aK2maWNxuK4 Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-pim-sm-over-mldp to WG LC 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, 20 Jun 2014 12:28:00 -0000 Yakov, et.al. we don't want to start more than one wglc per week, just now I have two wglc's going on alternate weeks. I have another one on queue for next week, but think I won't have that on ready. So there is a chance that I'll do draft-ietf-mpls-pim-sm- over-mldp, otherwise the week after. You can get on wglc comment from me now; or really a question. The draft says that all the security consideration that are applicable for mLDP are applicable here. What abaout, are there no security considerations derived from PIM? /Loa On 2014-06-18 22:27, Yakov Rekhter wrote: > Dear WG chairs, > > Given that draft-ietf-mpls-pim-sm-over-mldp is fairly stable, could > you please issue MPLS WG Last Call on it. > > Yakov. > -- 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 Jun 20 15:37:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827731A041F for ; Fri, 20 Jun 2014 15:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNkuFTpyZmHr for ; Fri, 20 Jun 2014 15:37:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A06F1A00E8 for ; Fri, 20 Jun 2014 15:37:15 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5KMbC9h025310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jun 2014 17:37:13 -0500 (CDT) 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 s5KMbC3l002463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 18:37:12 -0400 Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.109]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 20 Jun 2014 18:37:12 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-bryant-mpls-oam-udp-return Thread-Index: AQHPf+mIXbTUoLuth0OZOvkep32erZtg29GwgBk2SSCAAJ3y8A== Date: Fri, 20 Jun 2014 22:37:12 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340D946AB974@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2HuCXjlG2jWSDsqLH7d7nJ2GBf4 Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-oam-udp-return X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 22:37:19 -0000 Dear all, I was asked to review this draft. I understand the need to provide a more g= ranular out-of-band reply using a querier provided UDP port. Thus it is a u= seful draft to pursue. However, there are a couple of issues I found in this draft which if addres= sed would make in my view the document ready for WG status: 1. the first issue has to do with what I interpreted (correct me if I am wr= ong) as a change to the reply procedures in RFC 6374. This draft states in = Section 4: " If either the Return Address Object or Return UDP Port Object is not present in Query message and an MPLS-PLDM Response is requested out- of-band, the Query message MUST NOT be processed further. =20 " This modifies the behavior of RFC 6374 which does allow the reply to be sen= t over the address in the Source Address Object or over some configured out= -of-band response mechanism if none of the Source and Return Address object= s were included in the MPLS-PLDM query message.=20 2. The second issue has to do with the fact that the UDP Port Object is a s= eparate object from the address to be used with. I do not think this is a g= ood idea since the responder node can easily combine an address provided in= the Source Address Object with this UDP port and send it to the wrong node= in a cluster system. I propose that a new Return Address object be created which combines both t= he return address and return UDP port. Regards, Mustapha. From nobody Fri Jun 20 20:32:24 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6E61A04C8 for ; Fri, 20 Jun 2014 20:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK5wyxi8-bFD for ; Fri, 20 Jun 2014 20:32:19 -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 0E7521A04C2 for ; Fri, 20 Jun 2014 20:32:19 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D0A9218013DA; Sat, 21 Jun 2014 05:32:15 +0200 (CEST) Message-ID: <53A4FCBC.60203@pi.nu> Date: Sat, 21 Jun 2014 05:32:12 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-scudder-mpls-deprecate-bgp-entropy-label@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/UY4BwX0vFTmauw0VRf9KX1Vg3vo Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] NEW mpls wg document - draft-scudder-mpls-deprecate-bgp-entropy-label and IPR poll 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, 21 Jun 2014 03:32:21 -0000 Working Group, In the interest of time and given the short document, the mpls wg chairs have done the MPLS_RT review and also decided to accept the draft as an MPLS wg. Authors, Can you re-post the document as; draft-ietf-mpls-deprecate-bgp-entropy-label It would surprise me if we have and IPRs on this document, however: This mail starts that IPR poll. ------------------------------- Are you aware of any IPR that applies to draft-scudder-mpls-deprecate- bgp-entropy-label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are two IPR disclosures that relates to this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jun 21 09:00:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE1B1B27C8 for ; Sat, 21 Jun 2014 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 nNxp71EJFFYy for ; Sat, 21 Jun 2014 09:00:18 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 09C811A036B for ; Sat, 21 Jun 2014 09:00:11 -0700 (PDT) Received: (qmail 17156 invoked by uid 0); 21 Jun 2014 16:00:07 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 21 Jun 2014 16:00:07 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id H3zn1o00U2SSUrH013zq4S; Sat, 21 Jun 2014 10:00:07 -0600 X-Authority-Analysis: v=2.1 cv=F/jEKMRN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=N1Uyg9a6MDQA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=LWlq20R1y9OSUB77rgcA:9 a=aHtLYVD4bFwfbOyi:21 a=Xd3IE1II6HxChePy:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=HZkOTf57IcC0ZGJTCtHT1ODvFihK5BY+ONLkxLrtdzQ=; b=pOmOBqE1ljIaB86m+i5o++ilD/95eLkAMIy6CyjrAtB/UV1ibfkldISKeRkCAm6V3yJpnrEhjpA1k+dfrmWgJKv2PcrFP9UMoSjbGK1kQNnFlxZzYk9RuXhlx9vqlp0U; Received: from box313.bluehost.com ([69.89.31.113]:53125 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1WyNhj-0001IU-En; Sat, 21 Jun 2014 09:59:47 -0600 Message-ID: <53A5ABED.9080408@labn.net> Date: Sat, 21 Jun 2014 11:59:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/dMgFfUyLkkAQG08Y8QitIs44GeQ Cc: rtg-dir@ietf.org, draft-ietf-mpls-smp-requirements.all@tools.ietf.org, mpls@ietf.org Subject: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 16:00:25 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-smp-requirements-06.txt Reviewer: Lou Berger Review Date: June 21 2014 IETF LC End Date: 2014-06-23 Intended Status: Informational Summary: I have some minor concerns about this document that I think should (must, actually) be resolved before publication. Comments: I think the document is well written and, other than a couple of terminology related issues, easily understood. The document does have a number of terminology and technical issues which should be readily resolved prior to publication. Major Issues: Major issues are the type of concerns that will result in the document being blocked until they are resolved. The Routing ADs will become involved. Please include all of the major issues you have found. Give as much context information as possible (e.g., section numbers, paragraph counts). If you find no major issues, please write: "No major issues found." - No major issues found. In particular, I expect all issues can be resolved without AD intervention. Some of the minor issues, if not resolved will be escalated to the AD/major issue category. Minor Issues: Minor issues are concerns about clarity or technical accuracy that should be discussed and resolved before publication, but which would normally be resolved between the authors and the reviewers. Please include all of the minor issues you have found. Give as much context information as possible (e.g., section numbers, paragraph counts). If you find no minor issues, please write: "No minor issues found." - Document's usage of "committed" vs "allocated" resources: In section 1 the document introduces the notion that the distinction between protection and restoration is based on when resources are "committed". This difference from past definition. RFC4427 and 6372 make the distinction that protection and restoration differ based on when resources are *allocated* not *committed*. To quote RFC 4427: The distinction between protection and restoration is made based on the resource allocation done during the recovery LSP/span establishment. The distinction between different types of restoration is made based on the level of route computation, signaling, and resource allocation during the restoration LSP/span establishment. This difference also leads to come confused statements in the document as well as ambiguity in the text, i.e. confusion by the reader. The term "committed" is not tightly defined in this document (or earlier work) and is used differently than how "allocated" has been used. An example of this can be found in Section 3.1 which states: However, the commitment of the resources, at least for the shared segments, will only be finalized when the protection path is actually activated. Therefore, for the purists - regarding the terminology - SMP lies somewhere between protection and restoration. Both sentences are problematic. In the first, commitment seems to cover a "protection switch" would "connect" the protection path but not the earlier "allocation" of resources. (Quoted terms are used in earlier RFCs.) The second conclusion is based on the new distinction of protection vs. restoration and is unnecessary with the existing distinction. This issue exists in multiple places in the document where "committed" is used and I'd recommend that each should be replaced with terminology used in the referenced RFCs, i.e., "allocation", "connection", "cross-connect", "protection switch(over)", ... Note I'm *not* highlighting all cases where there are problems in the document related to this issue. There are a couple of places in the document where I think it's possible that once this terminology ambiguity is corrected that I'll have other substantive comments. - Section 2, 1st paragraph, last sentence. This sentence really defines the scope/purpose of the document, i.e., "clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document." As such, I'd repeat this in the abstract and move it to a more pronounced place in section 1 (or 3). - General comment: fate-sharing for co-routed bidirectional LSP protection: How is co-routing preserved for the reverse path in SMP? I'd assumed the protection switch coordination protocol would be required to trigger a switchover of the reverse LSP in the co-routed case, but don't see this in the document. - In section 4 and 5.2 you reference 5712 and 3209 as defining preemption terminology and behavior. I think 6372 is the right reference here as it defines both in the context of survivability and in dependent of control plane. - In section 4.2 you say "Therefore, it is suggested that this be carried out under the control of a dynamic control plane similar to GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, please make the correction. If not, I think the debate of which control protocol is used for MPLS-TP is way beyond the scope of this document. - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If referring to solutions conformant with this document, then these are informative statements, "and a non-control plane based SMP switchover mechanism is used, the control plane SHALL NOT ...". If referring to an operator's/user's choice of protection mechanism, I think the most you can say is MAY. - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP domain." As this is a requirement, what you mean by "tie-breaking rules" should be defined directly or by reference. - Section 5.3. RFC6372 takes an approach where preemption notification leverages the standard MPLS-TP OAM mechanisms, is there any reason to do more / not just follow 6372? - Section 5.7. There may be coordination required on soft-preemption as well (depending on the cross-connects established during LSP establishment) so coordinated switching should be supported independent of preemption mode. Nits: - Abstract: I don't recall the term "executive action" being used in any earlier related/referenced RFCs. Rather than introduce a new (and undefined) term, perhaps you can use an existing one, e.g., "protection switch"? - Section 1, paragraph 1. Do we really need another definition of MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP document(s) and dropping the first four sentences. The last sentence also makes a subjective statement. Whether it is critical or no is unnecessary. You can just say something like 6372 provides a survivability framework for MPLS-TP and is the foundation for this document. - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? Also drop the word linear, as it is an unnecessary qualifier and 4427/4428 don't use it. - Sections 3 (and to a lesser degree section 2) are really introductory text. I'm unsure as to why they aren't part of section 1. - Section 3.2 should have a reference for "existing control plane solutions for SMP within MPLS". - Section 3.2 again uses the "executive action" term. - Section 4.1. You say "two operations simultaneously". Do you really mean "simultaneously" or merely that they must both occur for protection to be provided? (Same comment in section 5.1. - Section 5.2. I suggest numbering the currently bulletted requirements list. - Section 5.2: First paragraph and forth bullet last sentence. These both basically cover the same topic (preemption) and actually say slightly different things. I suggest combine into a single requirement to ensure consistency and full coverage of the topic. - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't the topics related to timing be consolidated? - Section 5.2: requirement 6 seems to be a subset of 7, so it should be dropped. - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out just this one traffic treatment (sub) requirement? - Section 5.3. s/MAY/will - section 5.4: " When the working path detects.." detection is by the node not the path. - Section 5.4, last sentence. This is only the 2nd time you imply that the document covers requirements on a new protocol. I think this point is currently too subtle in the document. (This point was also made as a minor comment.) - section 5.6. RFC 6372 should be referenced From nobody Sun Jun 22 08:43:12 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB05D1A0395 for ; Sun, 22 Jun 2014 08:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.852 X-Spam-Level: X-Spam-Status: No, score=-111.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T18e5KJ8SrCd for ; Sun, 22 Jun 2014 08:43:07 -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 78CA01A037D for ; Sun, 22 Jun 2014 08:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12570; q=dns/txt; s=iport; t=1403451787; x=1404661387; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vO9/UTOAsvPbsjutm4qew8zTDFl0NaVefBlyxzZoUOQ=; b=m3eCIdQgLba5/qnI3Nbx0uo6JlAxcfMi4LHfFl55gFsEGEEZ9bqoOVVG EpoolbOVJtB2GyxrVYFflgz8e5LAgvt6f2NWlf0/vYP5bWJY7PKaGYQZJ 2nqc/mcRyb2sEfkXbTIsf8sNoUcQUX+t+3EfJfA4xc+tX5vFvF+gBp02d w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAGb4plOtJV2Y/2dsb2JhbABPCoJpJFJNDbwnh0ABgQEWdYQDAQEBAwEBAQE3NAkCDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIAYgxCAEMxWAXjiArMQcGgyeBFgScEZIeg0KBcCQc X-IronPort-AV: E=Sophos;i="5.01,524,1400025600"; d="scan'208";a="55068916" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 22 Jun 2014 15:43:06 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5MFh5Ta001378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 22 Jun 2014 15:43:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Sun, 22 Jun 2014 10:43:05 -0500 From: "Nobo Akiya (nobo)" To: "Nagendra Kumar Nainar (naikumar)" Thread-Topic: New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt Thread-Index: AQHPh0sKZ/vjNgoGA02gD6R1/DNUlZtviMsAgAAGuSCAAWXvgIAMTaug Date: Sun, 22 Jun 2014 15:43:05 +0000 Message-ID: References: <20140613210400.13388.18750.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/DJnb9oLKNRFDmAIszWczqJ59EnU Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-akiya-mpls-lsp-ping-lag-multipath-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 15:43:11 -0000 Hi Nagendra, > -----Original Message----- > From: Nagendra Kumar Nainar (naikumar) > Sent: Saturday, June 14, 2014 1:54 PM > To: Nobo Akiya (nobo) > Subject: Re: New Version Notification for draft-akiya-mpls-lsp-ping-lag- > multipath-00.txt >=20 > Hi Nobo, >=20 > As usual, interesting draft. Please see below for initial comments, Thank you for comments, and thank you for agreeing to allow me to include t= he MPLS WG in this response. I'm glad you found this document to be interesting. Although it became a bi= t more complicated that I was originally hoping. However, this extension ad= d a great value to a tool which can be part of the something larger to "fig= ht" the traffic black hole happening on MPLS networks :) =20 >=20 > From section 3, It appears that responder MUST set the LAG Info TLV. Is i= t the > case even if the downstream is not LAG?. Or did you meant that if the > responder have LAG based donwstream interface, then it MUST include the > TLV?. First bullet in the last portion of the Section 3 was exactly to explain wh= y this is a MUST, but clearly additional text will be helpful. How about we= update the bullet: [old] o Identify whether responder LSR understands this mechanism. [new] o Mandating the responder to always add the LAG Interface Info TLV in the MPLS echo reply allows the initiating LSR to identify whether responder LSR understands this mechanism. >=20 >=20 > In Section, I am trying to understand what does the below means, >=20 > "All fields and Sub-TLVs, except for Multipath Data Sub-TLV and > Interface Index Sub-TLV, are set/added to DDMAP to describe > this LAG interface, as per [RFC6424]. > " >=20 > The above statement followed by statement to add "Interface Index Sub- > TLV" > appears to be confusing. I see. Perhaps re-wording it can help clarify things. How about something l= ike this? [old] * All fields and Sub-TLVs, except for Multipath Data Sub-TLV and Interface Index Sub-TLV, are set/added to DDMAP to describe this LAG interface, as per [RFC6424]. [new] * In the DDMAP, Multipath Data Sub-TLV and Interface Index Sub- TLV are to describe each LAG member link. All other fields of the DDMAP are to describe the LAG interface. >=20 >=20 > In section 3, the below 2 statements appears to be redundant. Do we reall= y > need both?. >=20 > "* For each LAG member link of this LAG interface: >=20 > + MUST add Interface Index Sub-TLV (described in Section 7) > with LAG Member Link Indicator flag set in Interface Index > Flags, describing this LAG member link. >=20 > + MUST add Multipath Data Sub-TLV for this LAG member link, if > received DDMAP requested multipath information. >=20 > Each LAG member link is described with Interface Index Sub-TLV and > conditionally with Multipath Data Sub-TLV (if multipath information > is requested). " True. Let me re-word this one too. [old] Each LAG member link is described with Interface Index Sub-TLV and conditionally with Multipath Data Sub-TLV (if multipath information is requested). If both Sub-TLVs are placed in the DDMAP to describe a LAG member link, Interface Index Sub-TLV MUST be added first with Multipath Data Sub-TLV immediately following. [new] When both the Interface Index Sub-TLV and the Multipath Data Sub-TLV is placed in the DDMAP to describe a LAG member link, Interface Index Sub-TLV MUST be added first with Multipath Data Sub-TLV immediately following. >=20 >=20 > Section 4 says the inclusion of Detailed interface TLV is a MUST while > section 8 sys it is a MAY statement as below, >=20 > section 4: > " > Responder LSR MUST: >=20 > o Add LAG Interface Info TLV in the MPLS echo reply to provide > acknowledgement back to the initiator. Upstream LAG Info > Accommodation flag MUST be set in LAG Interface Info Flags. >=20 > o Add the Detailed Interface and Label Stack TLV (described in > Section 8) in the MPLS echo reply. > " >=20 > section 8: > "The Detailed Interface and Label Stack object is a TLV that MAY be > included in a MPLS echo reply message to report the interface on > which the MPLS echo request message was received and the label stack > that was on the packet when it was received. A responder LSR MUST > NOT insert more than one instance of this TLV. " >=20 Right, perhaps above snippet being preceded by the initiating LSR sending t= he MPLS echo request with DS Flags I bit set is not sufficient to elude tha= t responder is functioning with an assumption that it needs to include inte= rface/label-stack TLV. Let me change some texts: [old] o Add the Detailed Interface and Label Stack TLV (described in Section 8) in the MPLS echo reply. o Add the Incoming Interface Index Sub-TLV (described in Section 8.1.2) for LAG interfaces. The LAG Member Link Indicator flag MUST be set in Interface Index Flags, and the incoming Interface Index set to LAG member link which received the MPLS echo request. [new] o When the received DDMAP had DS Flags I set, add the Detailed Interface and Label Stack TLV (described in Section 8) in the MPLS echo reply. o When the received DDMAP had DS Flags I set, add the Incoming Interface Index Sub-TLV (described in Section 8.1.2) for LAG interfaces. The LAG Member Link Indicator flag MUST be set in Interface Index Flags, and the incoming Interface Index set to LAG member link which received the MPLS echo request. >=20 >=20 > Section 7 specifies as below, > "The Interface Index Sub-TLV describes the index assigned by the > upstream LSR to the interface." >=20 > Can you also point some reference to what type of index is it?. Is it > something assigned and advertised by LAG protocol like LACP or PAGP?. It's a locally allocated persistent index for local interfaces. It may or m= ay not be advertised, and that's not really important for this context. We = are just interested in getting a unique value (local to that node) that ide= ntifies a specific interface. I could add more texts, but the description o= n this sub-TLV was mostly ported from RFC4379. I think it's ok as is. >=20 > In association to above, Section 4 states the below, >=20 > "Note that defined procedures will provide a deterministic result for > LAG interfaces that are back-to-back connected between routers (i.e. > no L2 switch in between). If there is a L2 switch between LSR at > TTL=3Dn and LSR at TTL=3Dn+1, there is no guarantee that traversal of > every LAG member link at TTL=3Dn will result in reaching different > interface index at TTL=3Dn+1." >=20 > When there is L2 switch(es) in between, the LAG termination/negotiation > wil be between the LSR and L2 switch and so we may need some way to > exchange the Interface Index for each LAG member via L2 switch to be > exchanged between the LSRs. I am not aware of such exchange. If I am > missing something, I think it is worth referring the same for clarity :) That is exactly why L2-in-between is outside the scope of this document :) = Appendix A describes various flavors and why it is complicated to extend su= pport for those flavors. >=20 > Does the below sounds like a (direct) SHOULD statement? >=20 > "If the responder LSR is able to accommodate this request, > then the LAG Interface Info object MUST be included in the MPLS echo > reply message." >=20 > In the below topology, >=20 > +-------+ > | | > A-------B=3D=3D=3D=3D=3D=3D=3DC-------E > | | | > +-------D-------G >=20 > Assume A is validating all ECMP paths from A to G. Assume the metric from > B to D is 2 and rest all link are 1. So it will be >=20 > A-B-LAG-C-E-G > A-B-LAG-C-D-G > A-B-D-G >=20 > Assume the list of multipath data is (1-10) >=20 > Now B will reply as below, >=20 > (1,2,3) - {Link1, Downstream:C} > (4,5,6) - {Link2 Downstream:C} > (7,8,9,10) - {LinkBC, Downstream:D} >=20 > A will then send 2 request as below: >=20 > Echo1 (to C) - (multipath:1,2,3,4,5,6), > Echo2 (to D) - (multipath:7,8,9,10) >=20 > C will reply back with >=20 > (1,2,3) - {LinkCE, Downstream E} > (4,5,6) - {LinkCD, Downstream D} >=20 > So we dont have anything common between Link2 of LAG and downtream E. > Similarly we dont have anyhting common between Link1 of LAG and > downstream D (from C). I think we need the downstream node of LAG to > reply back with multipath info for each downstream from each LAG range. > Any thoughts?. The main problem with above example is that the range of multipath info is = too small, thus you ran out of intersect in the downstream. Additionally, i= f I was to implement this, then I would not carry over treating each LAG me= mber link separately in the LSP Tree Trace operations, once TTL=3Dn+1 is re= ached. Once LAG merges to a same downstream node, then I would aggregate th= e result and move forward in the downstream (i.e. treat the LAG as one logi= cal interface). Thanks! -Nobo >=20 > Thanks, > Nagendra >=20 >=20 >=20 >=20 > On 6/13/14, 5:33 PM, "Nobo Akiya (nobo)" wrote: >=20 > >FYI, new LSP Ping extension draft. > > > >> -----Original Message----- > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > >> (nobo) > >> Sent: Friday, June 13, 2014 5:15 PM > >> To: mpls@ietf.org > >> Subject: [mpls] FW: New Version Notification for > >>draft-akiya-mpls-lsp-ping- > >> lag-multipath-00.txt > >> > >> Dear MPLS WG, > >> > >> On MPLS data plane, one aspect which OAM is blind to traffic black > >>holing is when LSPs are traversing over LAG interfaces. We would like > >>to propose an extension to RFC4379 to provide the tool an ability to > >>discover and traverse LAG members. > >> > >> It will be very helpful if you could review this document, provide > >>comments and help us standardize this extension. > >> > >> Thanks! > >> > >> -Nobo, on behalf of authors > >> > >> > -----Original Message----- > >> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> > Sent: Friday, June 13, 2014 5:04 PM > >> > To: John E. Drake; Nobo Akiya (nobo); George Swallow (swallow); > >> > George Swallow (swallow); Bruno Decraene; Stephane Litkowski; Bruno > >> > Decraene; Nobo Akiya (nobo); John Drake; Stephane Litkowski > >> > Subject: New Version Notification for > >> > draft-akiya-mpls-lsp-ping-lag- multipath-00.txt > >> > > >> > > >> > A new version of I-D, > >> > draft-akiya-mpls-lsp-ping-lag-multipath-00.txt > >> > has been successfully submitted by Nobo Akiya and posted to the > >> > IETF repository. > >> > > >> > Name: draft-akiya-mpls-lsp-ping-lag-multipath > >> > Revision: 00 > >> > Title: Label Switched Path (LSP) Ping/Trace Multipath > Support for > >> > Link Aggregation Group (LAG) Interfaces > >> > Document date: 2014-06-13 > >> > Group: Individual Submission > >> > Pages: 18 > >> > URL: > >>http://www.ietf.org/internet-drafts/draft-akiya-mpls-lsp-ping- > >> > lag-multipath-00.txt > >> > Status: > >>https://datatracker.ietf.org/doc/draft-akiya-mpls-lsp-ping-lag- > >> > multipath/ > >> > Htmlized: > >>http://tools.ietf.org/html/draft-akiya-mpls-lsp-ping-lag- > >> > multipath-00 > >> > > >> > > >> > Abstract: > >> > This document defines an extension to the Multiprotocol Label > >> > Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute to > >> > describe Multipath Information for Link Aggregation (LAG) member > >> > links separately, thus allowing MPLS LSP Ping and Traceroute to > >> > discover and exercise specific paths of layer 2 Equal-Cost > >>Multipath > >> > (ECMP) over LAG interfaces. > >> > > >> > This document updates RFC4379 and RFC6424. > >> > > >> > > >> > > >> > > >> > > >> > Please note that it may take a couple of minutes from the time of > >> > submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > > >> > The IETF Secretariat > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jun 23 06:01:16 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856461B2AA3 for ; Mon, 23 Jun 2014 06:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.452 X-Spam-Level: X-Spam-Status: No, score=-7.452 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB6uX-dY9xGO for ; Mon, 23 Jun 2014 06:01:11 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013FB1B2AB2 for ; Mon, 23 Jun 2014 06:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9291; q=dns/txt; s=iport; t=1403528462; x=1404738062; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UiqeTxLyrH0q1c23Xqo5NG5yWNSoNiGNN994usoDQmA=; b=UR/mvfckv3AtEoMyBYUfoZBS52JjIhJ+jAt1ZHzEAWQClClqgl3lk2nk AoJ9RZSvK9c43MMgTtTyFZuR6aUUVOmRzZzZGqprTdpHmyFUapZ8wBlAS +7t4+7CYT4AWHzrjyIRj2h00xvjQmXI7uQZp0dEtglQjUS9c6YEiY/+Fh Y=; X-IronPort-AV: E=Sophos;i="5.01,530,1400025600"; d="scan'208";a="95711955" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 23 Jun 2014 13:01:00 +0000 Received: from ams-iwijnand-87111.cisco.com (ams-iwijnand-87111.cisco.com [10.55.191.156]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5ND0wfu003817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jun 2014 13:00:59 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: IJsbrand Wijnands In-Reply-To: <53A3A6B9.9000806@pi.nu> Date: Mon, 23 Jun 2014 15:00:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9144.1403103270@erosen-lnx> <53A29B3E.7030903@pi.nu> <53A3A6B9.9000806@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/lCFY8p9Pk5KvGMDG6OInMIDbHU8 Cc: "mpls@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , "draft-ietf-mpls-mldp-node-protection@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-mldp-node-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, 23 Jun 2014 13:01:15 -0000 Hi Loa, Thanks for the comments/suggestions to the draft. Besides Nagendra=92s point, to backup the Root node, we need a full mesh = of P2P LSPs between the nodes connected to the Root. For your figure 2, = it means there is a dotted line between LSR3 - LSR1 and LSR4 - LSR2. The = reason is to avoid looping. (Its like how a mesh-group works). Thx, Ice.=20 On 20 Jun 2014, at 05:12, Loa Andersson wrote: > Nagendra, >=20 > Yes you are right! Took me some time to go over the cases. >=20 > Further comments: >=20 > 1. Figure 2 does not really explain your point. >=20 >=20 > | > (LSR1) > . | . > . | . > . (N) . root > . / \ . > . / \. > (LSR2)....(LSR3) > | | > Figure 2. >=20 > N: The MP2MP root node being protected. > ...: Backup LSPs between LSR1, LSR2 and LSR3. >=20 > The tree will be fully connected by only two of the by-pass LSPs. >=20 > Figure 2 would need to look like this: >=20 > | | > (LSR1)....(LSR4 > . \ / . > . \ / . > . (N) . root > . / \ . > . / \. > (LSR2)....(LSR3) > | | >=20 >=20 > And I would like to see some text around this also, one sentence under > figure could e.g. be amended like this: >=20 > In order to protect node N, and in order to avoid partitioning of > the MP2MP tree, all the LSRs directly connected to N must > participate in protecting node N by acting both as PLR and MPT > LSRs. If, as in the case of non-root protection, each LSR just chose > one PLR, and LSR 1 and LSR2 chose each other, while LSR3 and LSR4 > chose each other the tree will be partioned. >=20 > Modulo grammar changes by the authors. >=20 > /Loa >=20 >=20 >=20 > On 2014-06-19 23:12, Nagendra Kumar Nainar (naikumar) wrote: >> Hi Loa, >>=20 >> Per my understanding, it may result in disconnected tree incase of = ROOT >> failure. Assume there is one more downstream leg from A as N1-N2-N3 >>=20 >> So there are 4 MPTs now (B, C, N and N1) to protect ROOT A. If the >> intention is to choose any one as PLR and establish the backup LSP, = due to >> any local matter it may result in below: >>=20 >> 1. B chooses C as PLR. >> 2. C chooses B as PLR. >> 3. N chooses N1 as PLR. >> 4. N1 chooses N as PLR. >>=20 >> Now, the tree will be disconnected during ROOT failure and any = traffic >> flowing from H will not reach N or N1 and downstream and traffic from = S >> will not reach B or C. >>=20 >> Thanks, >> Nagendra >>=20 >> On 6/19/14, 4:11 AM, "Loa Andersson" wrote: >>=20 >>> Eric, >>>=20 >>> tnx - I think I get this, the question I have now I try to capture = in >>> the figures below. >>>=20 >>> Assume a mp2mp tree like this. >>>=20 >>>=20 >>> A >>> / \ >>> / \ >>> B C >>> /| |\ >>> / | | \ >>> D E F G >>> /| | | |\ >>> / | | | | \ >>> H I J K L M >>>=20 >>> Assume the for a particular packet "G" is the ingress, G will = replicate >>> the packet and send it to L and M, and to C. >>>=20 >>> C will send to it to F to be passed to K, C will also send to A. >>>=20 >>> A will send it to B and eventually it will reach D, E, H, I and J. >>>=20 >>> If node A fails, a bypass will be established between, and the tree >>> will look like this: >>>=20 >>> A >>>=20 >>>=20 >>> B-----C >>> /| |\ >>> / | | \ >>> D E F G >>> /| | | |\ >>> / | | | | \ >>> H I J K L M >>>=20 >>> One observation is that with respect to the packet using G as = ingress, >>> G is the root. >>>=20 >>> The only change here is that C does not send the packet to A, but to = B, >>> i.e. with respect to traffic there are no unique functions performed = by >>> the root. >>>=20 >>> I think this aligns with what you said about mp2mp root protection. >>>=20 >>> However, if A has a third child. >>>=20 >>> A----------------+ >>> / \ | >>> / \ | >>> B C N >>> /| |\ |\ >>> / | | \ | \ >>> D E F G O P >>> /| | | |\ | |\ >>> / | | | | \ | | \ >>> H I J K L M Q R S >>>=20 >>> Why isn't it enough that C (or B) establishes the bypass to N, >>> like this: >>>=20 >>>=20 >>> A >>>=20 >>>=20 >>> B-----C-------------N >>> /| |\ |\ >>> / | | \ | \ >>> D E F G O P >>> /| | | |\ | |\ >>> / | | | | \ | | \ >>> H I J K L M Q R S >>>=20 >>> You seem to say that we need this: >>>=20 >>>=20 >>> A >>> +-------------------+ >>> | | >>> B-----C-------------N >>> /| |\ |\ >>> / | | \ | \ >>> D E F G O P >>> /| | | |\ | |\ >>> / | | | | \ | | \ >>> H I J K L M Q R S >>>=20 >>> Why is that? >>>=20 >>> /Loa >>>=20 >>> PS >>>=20 >>> Sometimes I think there is an easy answer, but it keeps escaping me = :( >>>=20 >>> /Loa >>>=20 >>>=20 >>> On 2014-06-18 16:54, Eric Rosen wrote: >>>> Loa> I've a question on the definition of "root node" for mp2mp >>>> networks. >>>>=20 >>>> RFC6388 defines "root node" for an MP2MP LSP. >>>>=20 >>>> An MP2MP LSP is a tree, and as a tree it has a root node. However, = the >>>> root >>>> node is not necessarily an ingress or egress node; any node can be = an >>>> ingress, and any node can be an egress. Traffic from an ingress = node >>>> travels both downstream from the ingress and upstream towards the = root. >>>> When the traffic reaches the root, it travels downstream from the = root >>>> on >>>> all branches other than the one from which the root received the >>>> traffic. >>>>=20 >>>> Loa> I think there are two models >>>>=20 >>>> No, RFC6388 doesn't have two models, and the model it does have is >>>> neither >>>> of the two below. >>>>=20 >>>> Loa> 1. the mp2mp network have ingress nodes and egress nodes, an >>>> ingress >>>> Loa> node send traffic to all egress nodes, thus acting as a = root >>>> node on >>>> Loa> a for an p2mp network. >>>>=20 >>>> This description confuses the "root node" (the only node in the = tree >>>> that is >>>> not a child of any other node) with an "ingress node" (a node that = puts >>>> traffic onto the tree.) In a P2MP LSP, the only ingress point to = the >>>> tree >>>> is the root node, but that's not true in MP2MP LSPs. >>>>=20 >>>> Loa> 2. the mp2mp network have ingress nodes, egress node and one >>>> (active) >>>> Loa> root node. The ingress node send traffic to the root node, = which >>>> Loa> send the traffic to all the egress nodes. >>>>=20 >>>> If I understand correctly, this model requires the ingress to = unicast >>>> to the >>>> root, and then requires the root to multicast down a P2MP tree. In >>>> general, >>>> this model does not work for MPLS. In this model, if a given node = is >>>> both a >>>> sender and a receiver, it will receive its own traffic back, with = no >>>> way to >>>> detect that it has already seen the traffic. This will result in >>>> traffic >>>> duplication. >>>>=20 >>>> Loa> Which model is assumed in = draft-ietf-mpls-mldp-node-protection? >>>>=20 >>>> The RFC6388 MP2MP LSP model. >>>>=20 >>>=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 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>=20 >=20 > --=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 Mon Jun 23 06:15:49 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100281B2952 for ; Mon, 23 Jun 2014 06:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 sAWPtOp-9xpr for ; Mon, 23 Jun 2014 06:15:41 -0700 (PDT) Received: from smtp05.msg.oleane.net (smtp05.msg.oleane.net [62.161.4.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3721A1B294E for ; Mon, 23 Jun 2014 06:15:39 -0700 (PDT) Received: from MGosseDellM6800 (LMontsouris-656-01-05-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp05.msg.oleane.net (MSA) with ESMTP id s5NDFHtN008595 for ; Mon, 23 Jun 2014 15:15:17 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Mon, 23 Jun 2014 15:15:36 +0200 Message-ID: <000a01cf8ee5$38beb130$aa3c1390$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CF8EF5.FC48B9B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+O5QWGCZymWSxsQkGCuddoMSgPdA== Content-Language: fr X-Backend: vm-smtp-sophos11v3 X-PMX-Spam: Probability=12% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.23.130318 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Svi1JLH24nFORBWKolMegwTHidU Subject: [mpls] Call for proposals MPLS SDN World Paris 2015 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, 23 Jun 2014 13:15:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01CF8EF5.FC48B9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MPLS SDN World Congress, together with the collocated NFV & SDN Summit, will take place in Paris next 17 to 20 March, 2015. The two events will share a common first day and will conclude with a panel discussion on standards versus open source. The MPLS SDN World agenda: Spring, SDN controler, resilience, SDN migration case studies. The call for proposals is open until July 15, 2014: http://www.uppersideconferences.com/mplssdnworld2015/mplssdn2015cfp.html ------=_NextPart_000_000B_01CF8EF5.FC48B9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS SDN World = Congress, together with the = collocated NFV & SDN Summit, will take place in Paris next 17 = to 20 March, 2015. 

The two events = will share a common first day and will conclude with a panel = discussion on standards versus open source.

The MPLS SDN World agenda: Spring, SDN controler, resilience, SDN migration case = studies.

The call for proposals is open until July 15, = 2014:

http://www.uppersideconferences.com/mplssdnworld2015/mplssdn2015= cfp.html

 

 

------=_NextPart_000_000B_01CF8EF5.FC48B9B0-- From nobody Mon Jun 23 07:01:05 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA11B2969; Mon, 23 Jun 2014 07:01:03 -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 XOgXZzV02Ts0; Mon, 23 Jun 2014 07:01:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B251B2B0F; Mon, 23 Jun 2014 07:00:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623140055.10358.16385.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 07:00:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/n6oTfImgSLUX2KcV1NmVimA8f1I Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'LDP Hello Cryptographic Authentication' to Proposed Standard (draft-ietf-mpls-ldp-hello-crypto-auth-10.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: Mon, 23 Jun 2014 14:01:04 -0000 The IESG has approved the following document: - 'LDP Hello Cryptographic Authentication' (draft-ietf-mpls-ldp-hello-crypto-auth-10.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ Technical Summary This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. Working Group Summary Taking a mostly security document through a working group like MPLS is a bit tricky. Most of the participants do not have there focus on security issues. While a large majority agree that the security work has a huge value, it is often not highest on the priority list for the average MPLS participant. Securing routing protocols, like LDP, started with a analysis done by the KARP working group. KARP pointed to the UDP based Hello messages as a potential risk. The current draft has been developed by the MPLS working group and reviewed by KARP during WGLC. The comments from people active in KARP have been very valuable. Document Quality Currently we do not know of existing implementations of this draft, The SecDir review from Yaron Sheffer took a while to resolve, but has improved the document. Personnel Adrian Farrel is the Responsible AD Loa Andersson is the Document Shepherd. From nobody Mon Jun 23 11:17:44 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF441B2BF4 for ; Mon, 23 Jun 2014 11:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG8Z3M7yOXOh for ; Mon, 23 Jun 2014 11:17:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372F21B2C01 for ; Mon, 23 Jun 2014 11:16:30 -0700 (PDT) Received: from ecowart-sslvpn-nc.jnpr.net (66.129.241.10) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.959.24; Mon, 23 Jun 2014 18:16:28 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <53A4FCBC.60203@pi.nu> Date: Mon, 23 Jun 2014 14:16:14 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1EA3C0FF-B1AD-44F6-9410-0FEA4C06DA14@juniper.net> References: <53A4FCBC.60203@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR03CA030.namprd03.prod.outlook.com (10.141.30.23) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 025100C802 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(252514010)(377454003)(189002)(24454002)(164054003)(199002)(92566001)(57306001)(31966008)(83322001)(77982001)(4396001)(77156001)(102836001)(74502001)(76482001)(76176999)(62966002)(104166001)(53416004)(50226001)(92726001)(33656002)(74662001)(69596002)(79102001)(50986999)(99396002)(81156004)(36756003)(93916002)(46102001)(42186005)(64706001)(77096002)(89996001)(20776003)(87286001)(95666004)(19580405001)(86362001)(85852003)(47776003)(105586002)(106356001)(80022001)(50466002)(87976001)(83072002)(81342001)(101416001)(19580395003)(66066001)(21056001)(81542001)(82746002)(83716003)(85306003)(23756003)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:ecowart-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/zkq-Ew6sEt6WDj5m1fWZM46R3C0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-scudder-mpls-deprecate-bgp-entropy-label@tools.ietf.org" Subject: Re: [mpls] NEW mpls wg document - draft-scudder-mpls-deprecate-bgp-entropy-label and IPR poll 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, 23 Jun 2014 18:17:39 -0000 Draft uploaded. I am not aware of any relevant IPR. (As you say, it would be quite = surprising if there were any.) Thanks, --John On Jun 20, 2014, at 11:32 PM, Loa Andersson wrote: > Working Group, >=20 > In the interest of time and given the short document, the mpls > wg chairs have done the MPLS_RT review and also decided to > accept the draft as an MPLS wg. >=20 > Authors, >=20 > Can you re-post the document as; > draft-ietf-mpls-deprecate-bgp-entropy-label >=20 > It would surprise me if we have and IPRs on this document, however: >=20 > This mail starts that IPR poll. > ------------------------------- >=20 > Are you aware of any IPR that applies to draft-scudder-mpls-deprecate- > bgp-entropy-label? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > Currently there are two IPR disclosures that relates to this document. >=20 > If you are listed as a document author or contributor please respond = to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The = document will not advance to the next stage until a response has been > received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa > (as MPLS WG co-chair) >=20 >=20 > --=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 Mon Jun 23 15:59:10 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981801A03A4; Mon, 23 Jun 2014 15:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 Psqr7fVDQ5OK; Mon, 23 Jun 2014 15:58:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A41A03B1; Mon, 23 Jun 2014 15:58:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CEA141801AE; Mon, 23 Jun 2014 15:57:24 -0700 (PDT) To: huubatwork@gmail.com, sboutros@cisco.com, msiva@cisco.com, raggarwa_1@yahoo.com, martin.vigoureux@alcatel-lucent.com, dai.xuehui@zte.com.cn X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140623225724.CEA141801AE@rfc-editor.org> Date: Mon, 23 Jun 2014 15:57:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/KgrixvkUYtmz7b8ZPMZy5ATF_oU Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, mpls@ietf.org Subject: [mpls] [Errata Verified] RFC6435 (4017) 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, 23 Jun 2014 22:58:59 -0000 The following errata report has been verified for RFC6435, "MPLS Transport Profile Lock Instruct and Loopback Functions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=4017 -------------------------------------- Status: Verified Type: Editorial Reported by: Huub van Helvoort Date Reported: 2014-06-19 Verified by: Adrian Farrel (IESG) Section: 1 Original Text ------------- Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". This document discusses these functions in the context of MPLS networks. Corrected Text -------------- Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". This document discusses these functions in the context of MPLS networks. Further information about these abstract OAM functions in an MPLS Transport Profile context can be found in RFC 6371 [6] where the lock function is referred to as the "Lock Instruct function (LKI)" and the loopback function is called "data-plane loopback." Notes ----- RFC6435 uses "LI" as acronym for "Lock Instruct" throughout the document. RFC6371 uses "LKI" for "Lock Instruct" in sections 7.1, 7.1.1 and 7.1.2. This may confuse the reader of both documents. A similar confusion can occur for refering to the loopback function. -------------------------------------- RFC6435 (draft-ietf-mpls-tp-li-lb-08) -------------------------------------- Title : MPLS Transport Profile Lock Instruct and Loopback Functions Publication Date : November 2011 Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jun 23 20:29:30 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68341B2823; Mon, 23 Jun 2014 20:29: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 e4ZN9xjX4FlH; Mon, 23 Jun 2014 20:29:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 385651B27C5; Mon, 23 Jun 2014 20:29:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624032924.23603.88508.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 20:29:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RWSORZlAJ5xalo5NvpN0koKe5oo Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-deprecate-bgp-entropy-label-00.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, 24 Jun 2014 03:29:26 -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 : Deprecation of BGP Entropy Label Capability Attribute Authors : John G. Scudder Kireeti Kompella Filename : draft-ietf-mpls-deprecate-bgp-entropy-label-00.txt Pages : 3 Date : 2014-06-23 Abstract: RFC 6790 defines the BGP Entropy Label Capability attribute. Regrettably, it has a bug: although RFC 6790 mandates that Entropy Label-incapable routers must remove the attribute, in practice this requirement can't be guaranteed to be fulfilled. This specification deprecates the attribute. A forthcoming document will propose a replacement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-deprecate-bgp-entropy-label-00 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 Jun 24 03:06:35 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149511B29B3 for ; Tue, 24 Jun 2014 03:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeRxfDLgQr00 for ; Tue, 24 Jun 2014 03:06:31 -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 AF3F81B28B7 for ; Tue, 24 Jun 2014 03:06:31 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.110.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C0CA31802B19; Tue, 24 Jun 2014 12:06:28 +0200 (CEST) Message-ID: <53A94D9A.2030409@pi.nu> Date: Tue, 24 Jun 2014 12:06:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <539528F5.1040906@pi.nu> In-Reply-To: <539528F5.1040906@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/l6APzR5doKP0V7ydzuUGuQn1Qik Cc: "" , "draft-ietf-mpls-seamless-mcast@tools.ietf.org" Subject: [mpls] Closed - Re: Working group last call on draft-ietf-mpls-seamless-mcast 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, 24 Jun 2014 10:06:33 -0000 Folks, This wglc ended yesterday. The authors should feel free to address the received comments and post a new version as necessary. However there are one development that was not anticipated when the wglc were started. There is a draft-ietf-l3vpn-pmsi-registry-02 creating an IANA registry that is applicable for e.g. draft-ietf-mpls- seamless-mcast. We do not intend to request publication of draft-ietf-mpls- seamless-mcast until this IANA registry have be created. draft-ietf-l3vpn-pmsi-registry is currently in late wglc in l3vpn, mpls and idr, we hope to make swift progress as soon as the wglc concludes. This will make it possible to have further comments on draft-ietf-mpls-seamless-mcast, the authors are requested to address additional comments if any as if they were part of the wglc comments. /Loa for the mpls co-chairs On 2014-06-09 05:24, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-seamless-mcast. > > There are one IPR disclosure against this document. The authors has > stated that he is unaware of any other IPRs that relate to this > document. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > This working group last call ends June 23, 2014. > > /Loa > for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Jun 24 15:29:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAFB1B2926 for ; Tue, 24 Jun 2014 15:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 pC7c3fGizn4F for ; Tue, 24 Jun 2014 15:29:30 -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 DEF6C1B2919 for ; Tue, 24 Jun 2014 15:29:29 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-e2-53a9a7dbd617 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8E.B1.11744.BD7A9A35; Tue, 24 Jun 2014 18:31:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 18:29:27 -0400 From: Gregory Mirsky To: "draft-ietf-mpls-forwarding@tools.ietf.org" Thread-Topic: Time Syncrhonization in draft-ietf-mpls-forwarding Thread-Index: Ac+P+tn4ThonEoK7RZiw4TIgHqSbIQ== Date: Tue, 24 Jun 2014 22:29:26 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E1C4A@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.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E1C4Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPoO7t5SuDDS5ctLHYcPcuu8WtpStZ HZg8liz5yeTx5fJntgCmKC6blNSczLLUIn27BK6MuRuuMhZclKn4+GMuawNjn2QXIyeHhICJ RN+qBlYIW0ziwr31bF2MXBxCAkcZJS4+bWGBcJYzShzqucIEUsUmYCTxYmMPO4gtIhArsXjW Y8YuRg4OZgFliVN3ZUDCwgI2Eu8nTmSCKHGU2PhjA1S5nsTFgz/BlrEIqEr833iYGcTmFfCV OLtmGguIzQh0xPdTa8B6mQXEJW49mc8EcZyAxJI955khbFGJl4//QR2tKLGvfzo7RH2+xMb7 V5kgZgpKnJz5hGUCo/AsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Lk KC1OLctNNzLcxAiMkmMSbI47GBd8sjzEKMDBqMTDq+CzMliINbGsuDL3EKM0B4uSOK9m9bxg IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYySPGsijYylNxs0/Sq+2mk3p3TZ9j16/DbzWFun Llr7rXCG1cutN135bM9vmitpNt1Cjs3beP28911PZ+lmx6RWJijL1zYtWShpq/yt6pMFv+22 P5crj/2SFeaawCxy+cdqlh7OAlNhntDEQ8IV73yEn/pt1lvj9D9Q+UAp+1bnxxHBuwVl3ymx FGckGmoxFxUnAgDeOwd7cwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/cxghqrJTZNp_y4VVGx9x4rfI8Yo Cc: "mpls@ietf.org" Subject: [mpls] Time Syncrhonization in draft-ietf-mpls-forwarding 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, 24 Jun 2014 22:29:32 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E1C4Aeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, I'd like to refer you to draft-mirsky-mpls-residence-time where we've proposed differe= nt method to support Transparent Clock and accumulate Correlation not in th= e correlationField but in Scratch Pad of Residence Time Measurement G-ACh. = I believe that our proposal would not require what is stated in the second = paragraph of the Section 2.1.3. We're preparing update and will publish -02= version of RTM draft before the deadline. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7E1C4Aeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et. al,

I’d like to refer you to draft-mirsky-mpls-residence-time where we’ve proposed different m= ethod to support Transparent Clock and accumulate Correlation not in the co= rrelationField but in Scratch Pad of Residence Time Measurement G-ACh. I be= lieve that our proposal would not require what is stated in the second paragraph of the Section 2.1.3. We’re p= reparing update and will publish -02 version of RTM draft before the deadli= ne.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B7E1C4Aeusaamb103erics_-- From nobody Fri Jun 27 06:43:46 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DAE1B31A2 for ; Fri, 27 Jun 2014 06:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqpSm9qRGITy for ; Fri, 27 Jun 2014 06:43:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542F11B2BD8 for ; Fri, 27 Jun 2014 06:43:43 -0700 (PDT) Received: from BLUPR05CA0056.namprd05.prod.outlook.com (10.141.20.26) by BLUPR05MB104.namprd05.prod.outlook.com (10.255.214.23) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 27 Jun 2014 13:43:41 +0000 Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::111) by BLUPR05CA0056.outlook.office365.com (2a01:111:e400:855::26) with Microsoft SMTP Server (TLS) id 15.0.974.11 via Frontend Transport; Fri, 27 Jun 2014 13:43:41 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft SMTP Server (TLS) id 15.0.969.12 via Frontend Transport; Fri, 27 Jun 2014 13:43:40 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Jun 2014 06:43:40 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s5RDhbn40382; Fri, 27 Jun 2014 06:43:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201406271343.s5RDhbn40382@magenta.juniper.net> To: Loa Andersson In-Reply-To: <53A428C4.3020408@pi.nu> References: <201406182028.s5IKS1n21555@magenta.juniper.net> <53A428C4.3020408@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Fri, 20 Jun 2014 14:27:48 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39111.1403876617.1@juniper.net> Date: Fri, 27 Jun 2014 06:43:37 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(189002)(199002)(252514010)(51704005)(24454002)(377424004)(85852003)(76482001)(77982001)(74662001)(74502001)(84676001)(31966008)(50466002)(68736004)(86362001)(4396001)(16796002)(85306003)(19580395003)(79102001)(69596002)(21056001)(76176999)(54356999)(50986999)(83322001)(44976005)(19580405001)(46102001)(6806004)(64706001)(105596002)(97736001)(46406003)(95666004)(97756001)(23726002)(102836001)(92726001)(80022001)(92566001)(99396002)(20776003)(87936001)(106466001)(81156004)(107046002)(81542001)(83072002)(47776003)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB104; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0255DF69B9 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/G9aUIznDVa9XD20oEEhSqBIaeXU Cc: rcallon@juniper.net, mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-pim-sm-over-mldp to WG LC 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, 27 Jun 2014 13:43:44 -0000 Loa, > Yakov, > > et.al. we don't want to start more than one wglc per week, just now > I have two wglc's going on alternate weeks. > > I have another one on queue for next week, but think I won't have that > on ready. So there is a chance that I'll do draft-ietf-mpls-pim-sm- > over-mldp, otherwise the week after. Ok. > You can get on wglc comment from me now; or really a question. The > draft says that all the security consideration that are applicable for > mLDP are applicable here. What about, are there no security > considerations derived from PIM? Since this draft just expands rfc6826 ("In-Band Signaling with mLDP") to cover PIM SM in ASM mode, and since the security consideration section of rfc6826, that covers PIM SM in SSM mode, does not say anything about security considerations derived from PIM, and I assume that there are no security considerations derived from PIM in this draft. Yakov. > > /Loa > > On 2014-06-18 22:27, Yakov Rekhter wrote: > > Dear WG chairs, > > > > Given that draft-ietf-mpls-pim-sm-over-mldp is fairly stable, could > > you please issue MPLS WG Last Call on it. > > > > Yakov. > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jun 28 15:10:50 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9AF1A00FF; Sat, 28 Jun 2014 15:10: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 7dASbrULcik6; Sat, 28 Jun 2014 15:10:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6D51A008F; Sat, 28 Jun 2014 15:10:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140628221045.23200.25492.idtracker@ietfa.amsl.com> Date: Sat, 28 Jun 2014 15:10:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/PFWTSs5mIJh3PkuyEhx86QR9XJA Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-07.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, 28 Jun 2014 22:10:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Seamless MPLS Architecture Authors : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-07.txt Pages : 42 Date : 2014-06-28 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mpls-07 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 Jun 29 06:50:17 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E678F1A04CD; Sun, 29 Jun 2014 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucXhwINWopwu; Sun, 29 Jun 2014 06:50:10 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA11F1A04C8; Sun, 29 Jun 2014 06:50:09 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5TDo4cg008316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jun 2014 08:50:06 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5TDo3Ed017821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jun 2014 15:50:04 +0200 Received: from [135.244.224.52] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 29 Jun 2014 15:50:02 +0200 Message-ID: <53B01988.6080502@alcatel-lucent.com> Date: Sun, 29 Jun 2014 15:50:00 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , , References: <5399AE30.3020703@alcatel-lucent.com> In-Reply-To: <5399AE30.3020703@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/6VxnTHie3fqF1yTFeR3a8E11L74 Cc: l3vpn-chairs@tools.ietf.org, mpls-chairs@tools.ietf.org, idr-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [mpls] WG Last Call on draft-ietf-l3vpn-pmsi-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 13:50:12 -0000 All, this WG LC is now closed. Thank you for your reviews and comments. There were few comments which I compiled and sent to the authors. We will proceed with requesting publication. -m Le 12/06/2014 15:42, Martin Vigoureux a crit : > Working Groups, > > This is to start a 2-week Working Group Last Call in three Working > Groups (idr, l3vpn and mpls) on draft-ietf-l3vpn-pmsi-registry-02. > > The draft has been made a WG Document by WG Chairs decision. > > In RFC 6514 (BGP Encodings and Procedures for Multicast in MPLS/BGP IP > VPNs), an optional transitive BGP attribute called the > "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" is > specified. This BGP attribute uses an octet field to specify the > PMSI tunnel type. RFC 6514 allocates the values 0-7. > > There now is need to make further code point allocations from this > name space. In particular, draft-ietf-mpls-seamless-mcast > needs to make such an allocation. That draft is currently in WG Last > Call in the MPLS Working Group. > > draft-ietf-l3vpn-pmsi-registry creates a new IANA registry called > "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" for > these code points. > The registry is created in the "Border Gateway Protocol (BGP) > Parameters" registry. > > Please send comments to the l3vpn mailing list (l3vpn@ietf.org). > > The WG LC will end on Friday the 27th of June. > > > Martin, on behalf of the WGs co-chairs > > From nobody Sun Jun 29 09:23:21 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D8F1A00D3 for ; Sun, 29 Jun 2014 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S71fvdHiwTUJ for ; Sun, 29 Jun 2014 09:23:15 -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 7566E1A00AA for ; Sun, 29 Jun 2014 09:23:14 -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 BGP53090; Sun, 29 Jun 2014 16:23:11 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 29 Jun 2014 17:23:11 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Sun, 29 Jun 2014 09:22:59 -0700 From: Huaimo Chen To: "Nobo Akiya (nobo)" , Gregory Mirsky , Yimin Shen , "mpls@ietf.org" Thread-Topic: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 Thread-Index: AQHPiAcqanZlS0+Fi06hpXsnzIjRVJtzMFiAgAClx5CAAjOngIASPbkg Date: Sun, 29 Jun 2014 16:22:58 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C817F9@SJCEML702-CHM.china.huawei.com> References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B773138@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7761F4@eusaamb103.ericsson.se> <75e6f9b9bfd44105a725a98d11e1f968@BY2PR05MB728.namprd05.prod.outlook.com>, <7347100B5761DC41A166AC17F22DF1121B776557@eusaamb103.ericsson.se> <104CBCDD-6440-453E-A224-3FAF4BE75F04@juniper.net> <7347100B5761DC41A166AC17F22DF1121B777091@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C4917F@SJCEML701-CHM.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B7775DE@eusaamb103.ericsson.se> <8E4F5326-58DC-4F16-95A2-F9D6C87DAFF7@juniper.net> <7347100B5761DC41A166AC17F22DF1121B77784D@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C66964@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C7496C@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C74B9A@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.237] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/-TbwpEKpPvXzfxScaN_ovJM5PGM Cc: Raveendra Torvi , mengnan 58534 , "Boris.Zhang@telus.com" , "Toy, Mehmet" , "ningso01@gmail.com" , lizhenbin 00147097 , Alia Atlas , Ross Callon , "'Xu, Fengman'" , Quintin zhao Subject: Re: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 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, 29 Jun 2014 16:23:19 -0000 Hi Nobo, Thanks much for your comments and suggestions! My answers/explanations are inline below. Best Regards, Huaimo -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Tuesday, June 17, 2014 1:33 PM To: Huaimo Chen; Gregory Mirsky; Yimin Shen; mpls@ietf.org Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu, Fengman'; To= y, Mehmet; LEI LIU; ningso01@gmail.com; lizhenbin 00147097; Quintin zhao; R= ichard Li; mengnan 58534; Boris.Zhang@telus.com Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 Hi Huaimo, My original intent was to highlight the limitations with detections propose= d, and I believe that has been accomplished. Thank you for putting up with = my effort to do so! [Huaimo] We will continue putting our effort on this if needed. > After the failure of the primary ingress happens and the backup > ingress determines the failure, the backup ingress sends/refreshes > PATH messages to the next hop node of the primary ingress of a P2P > LSP through the backup LSP as needed. The failure can be determined > reliably through checking the Link State Database (LSDB). Unfortunately, I don't think this additional text solves the problem. The b= ackup ingress needs to know the health of the link between the source and p= rimary ingress. That particular link could very well be outside the TE top= ology (i.e. link is CE to PE[primary ingress]) in which case you do not hav= e the trigger for the backup ingress to send the necessary PATH message. Wi= th LSDB trigger approach, you could be limiting the scope of the solution s= ignificantly. [Huaimo] The text will be revised. A method for reliably detecting the fail= ure of the primary ingress before the PATH message expires (at the next hop= nodes of the primary ingress) is needed. Thus, after the primary ingress f= ails, the backup ingress can use this method to detect the failure, and the= primary LSP will still be alive since the PATH message is refreshed before= the next hop nodes remove the states for the primary LSP.=20 It seems that the critical point is to make sure that the method to be used= can reliably detect the failure of the primary ingress within a given time= (seconds).=20 After the primary ingress fails, it will not be reachable after routing con= vergence. It looks like checking whether the primary ingress is reachable i= s a possible method.=20 Before the primary ingress fails, it has some links to other nodes such the= link to the backup ingress node and the links to the next hop nodes of the= primary ingress. These links are recorded in the Link State Database (LSDB= ). After the primary ingress fails, these links will disappear from the Lin= k State Database (LSDB) after IGP converges. Thus it seems that checking wh= ether there is not any link to the primary ingress in LSDB is another possi= ble method. Whether the link between the source and the primary ingress is = outside of the TE topology may not affect the method. After the primary ing= ress fails, all the links to it will disappear (i.e., there will be no link= to it).=20 LSP "association" approach (as roughly eluded in my earlier comment) still = rings a nicer sound, but I think, at this point, this document needs RSVP s= ignaling experts to provide comments and possibly alternative ideas. [Huaimo] We will keep this in our mind. Thanks! -Nobo > -----Original Message----- > From: Huaimo Chen [mailto:huaimo.chen@huawei.com] > Sent: Monday, June 16, 2014 12:37 PM > To: Nobo Akiya (nobo); Gregory Mirsky; Yimin Shen; mpls@ietf.org > Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu,=20 > Fengman'; Toy, Mehmet; LEI LIU; ningso01@gmail.com; lizhenbin=20 > 00147097; Quintin zhao; Richard Li; mengnan 58534;=20 > Boris.Zhang@telus.com > Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 >=20 > Hi Nobo, >=20 > Thanks much for your suggestions and comments! >=20 > It seems that 3.3 "Source Detects Failure" with some=20 > changes/enhancements works for protecting the primary ingress failure=20 > of a P2P LSP. >=20 > 3.3 "Source Detects Failure" may be updated as follows: >=20 > Source Detects Failure or Source-Detect means that the source is > responsible for detecting the failure of the primary ingress of an > LSP quickly. The backup ingress is ready to import the traffic from th= e > source into the backup LSP after the backup LSP is up. >=20 > In normal operations, the source sends the traffic to the primary > ingress. When the source detects the failure of the primary ingress, > it switches the traffic to the backup ingress, which delivers the > traffic to the next hops of the primary ingress through the backup > LSP, where the traffic is merged into the primary LSP. >=20 > After the failure of the primary ingress happens and the backup > ingress determines the failure, the backup ingress sends/refreshes > PATH messages to the next hop node of the primary ingress of a P2P > LSP through the backup LSP as needed. The failure can be determined > reliably through checking the Link State Database (LSDB). >=20 >=20 > Best Regards, > Huaimo > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Sunday, June 15, 2014 6:03 PM > To: Huaimo Chen; Gregory Mirsky; Yimin Shen > Cc: Alia Atlas; Ross Callon; Raveendra Torvi; Autumn Liu; 'Xu,=20 > Fengman'; Toy, Mehmet; LEI LIU; ningno@yahoo.com; Ning So; lizhenbin=20 > 00147097; Quintin zhao; Richard Li > Subject: RE: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 >=20 > Hi Huaimo, >=20 > > Thanks for your comments! >=20 > Thanks for responding! >=20 > Please see in-line. >=20 > > I believe 3.3 is the only one that works well. 3.1 can black hole=20 > > the traffic if the only failure is the link between source and=20 > > ingress (i.e. ingress node and link between ingress/backup being=20 > > alive will cause source to import the steam to backup, but backup=20 > > will not import > the stream to the P2MP tree). > > > > [Huaimo] It seems that 3.3 "Source Detects Failure" works well for=20 > > protecting the primary ingress failure of a P2MP LSP. For a P2P LSP, > > 3.3 seems not enough to provide protection for the primary ingress=20 > > failure of the LSP because we may need to send/refresh PATH messages=20 > > to the next hop node of the primary ingress of the P2P LSP through=20 > > the backup LSP when the primary ingress node fails. > > In the case that the link between the source and the primary ingress=20 > > fails, > > 3.1 " Backup and Source Detect Failure" may work well. The source=20 > > may locally distinguish between the failure of the primary ingress=20 > > and that of the link between the source and the primary ingress. =20 > > When the source detects the failure of the link (but not the failure=20 > > of the primary ingress), it may continue to send the traffic to the=20 > > primary ingress via another link between the source and the primary=20 > > ingress if > there is one. >=20 > IMHO, what I think we should avoid is creating a solution that relies=20 > on two unsynchronized brains making a same decision. If we pursue=20 > this, we create a complex problem of how do we ensure two brains make=20 > the same decision or how do we synchronize the decision by two brains.=20 > Additionally, we should avoid creating a solution that relies on an=20 > LSR being able to deterministically differentiate between a link=20 > failure and a node failure, this is also another complex problem. If=20 > we can come up with a solution that avoids both of these problems,=20 > then the resulting solution should be much more stable (i.e. able to prod= uce deterministic results). >=20 > Above, you said (3.1 " Backup and Source Detect Failure" may work well). > Sure it might be easier from signaling perspective, but it's not easy=20 > from failure detection perspective (i.e. has two brain problem). >=20 > > > 5. Remove the detection modes that do not work from the draft. > > > This is a challenging problem for us to have a perfect solution. > > > More discussions and comments may be needed. > > > > Theoretically, all 4 scenarios (3.1-3.4) are interesting. However,=20 > > first question that I have (and perhaps should first get discussed)=20 > > is do we _need to_ try to support all 4 scenarios and why. One=20 > > possible outcome is that folks are sufficiently happy with 3.3, and=20 > > there are no further problems to solve. If folks do indeed need=20 > > other > > solution(s) besides 3.3, then I agree that we should discuss some > possibilities. > > > > [Huaimo] 3.3 works for protecting the primary ingress failure of a=20 > > P2MP > LSP. > > We may just need to have a solution that works well for protecting=20 > > the primary ingress failure of a P2P LSP. >=20 > Perhaps an alternative way to approach this problem is to figure out=20 > how to do what you are doing with P2MP for P2P, and only use 3.3 as the d= etection. >=20 > Perhaps another way to approach this problem is to figure out how the=20 > LSP from primary ingress and corresponding LSP from backup ingress can=20 > get associated so that the two LSPs are always active (i.e. backup=20 > ingress can takeover anytime) but share bandwidth reservation (i.e. no=20 > bandwidth resources wasted). This approach also has a benefit of=20 > backup ingress being able to run continuity check on the LSP before=20 > the takeover, so that backup ingress knows that backup LSP is healthy=20 > when it takes over. It would be a pity for the backup ingress to take=20 > over but traffic black holes because forwarding state on the backup=20 > ingress or merge-point LSR or elsewhere is bad. >=20 > > > =A0Is it acceptable to have a detection mode that works well in=20 > > > most of cases and can recover in other corner cases in a short time? > > > > Is node failure more common than link failure? :) And how "short"=20 > > are we talking about? :) > > > > Perhaps better to check with operators/customers who are asking for thi= s? > > > > [Huaimo] "short" should mean in ms not in seconds. >=20 > Thanks for the information. >=20 > > > > I'd be happy to chip in to aid in tackling the problems, but=20 > > personally I'd like to know that we do indeed need to solve them. > > > > [Huaimo] Thanks much for your willing to help! >=20 > Based on names on this email thread, and list of authors/contributors=20 > in the document, clearly there's an interest to solve this problem. I=20 > am also supportive of solving this problem. However, I'm just not=20 > convinced that we have come up with the best way to solve this problem=20 > [yet]. But I'm just one person. >=20 > In my VERY humble opinion, it might be beneficial to articulate the=20 > limitations with proposals in this draft and ask for comments/feedback=20 > from the community with open mind to potentially fresh ideas. >=20 > Thanks! >=20 > -Nobo From nobody Sun Jun 29 12:18:34 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7F41A02F6 for ; Sun, 29 Jun 2014 12:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry4HTYIyZst2 for ; Sun, 29 Jun 2014 12:18:27 -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 D52E91A02DD for ; Sun, 29 Jun 2014 12:18:25 -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 BJJ76031; Sun, 29 Jun 2014 19:18:23 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.212.94.47) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 29 Jun 2014 20:18:22 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML701-CHM.china.huawei.com ([169.254.3.190]) with mapi id 14.03.0158.001; Sun, 29 Jun 2014 12:18:17 -0700 From: Huaimo Chen To: Autumn Liu , Yimin Shen , Ross Callon , "mpls@ietf.org" Thread-Topic: draft-ietf-mpls-rsvp-egress-protection-00 Thread-Index: AQHPaSV8o/K71U51ukWB9kHnTmwa65s34q2AgAkYsaCAF+H7gIASEs9QgANDEICAGo+tQA== Date: Sun, 29 Jun 2014 19:18:16 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445C84838@SJCEML702-CHM.china.huawei.com> References: <93426e96480c4945a5d35aea63d15a92@CO2PR05MB636.namprd05.prod.outlook.com> <233cc5ff63d84f4d904c5a7e4792f540@CO2PR05MB636.namprd05.prod.outlook.com> <649f1042acc6404aa37ba117348473c2@BY2PR05MB728.namprd05.prod.outlook.com> <9a39f3c347114e2197ce2bf8eb7c525d@BY2PR05MB728.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D445C66C94@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C68100@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C73DE9@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.237] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D445C84838SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/MdlwPz-blL0-wdIW_7VXsGdRktk Subject: Re: [mpls] draft-ietf-mpls-rsvp-egress-protection-00 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, 29 Jun 2014 19:18:31 -0000 --_000_5316A0AB3C851246A7CA5758973207D445C84838SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Autumn, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, June 12, 2014 10:11 AM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, Thanks for your reply. Please see my comment inline. Autumn From: Autumn Liu [mailto:autumn.liu@ericsson.com] Sent: Thursday, May 08, 2014 8:44 PM To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Huaimo, I have some questions. 1) How Inner label (vpn label) acquired on primary egress node is sent= to backup egress node? Via PATH message for backup LSP? which object is us= ed? How this label is processed? How this label is maintained? [Huaimo] An inner label (such as VPN label) allocated on the primary egress= node may be sent to the backup egress node in one of a few ways. One way i= s to use BGP to send the inner label to the backup egress node from the pri= mary egress node. Alternatively, the inner label may be sent from the prima= ry egress node to the upstream node of the primary egress node through an E= GRESS-BACKUP object in RESV message and then the upstream node sends the in= ner label to the backup egress node via an EGRESS-BACKUP object in the PAT= H message for the backup LSP. When the backup egress node receives the inne= r label as a UA label originally from the primary egress, it adds a forward= ing entry with the label into the LFIB for the primary egress node. When th= e backup egress node receives a packet from the backup LSP, it uses the top= label as a context label to find the LFIB for the primary egress node and = the inner label to deliver the packet to the same destination as the primar= y egress node according to the LFIB. Note that exactly how the inner label is sent from the primary egress node = to the backup egress node is out of scope for this document. I understand that this is out of scope of this document, but it is still no= t clear to me how inner label is going to be processed, maintained and prog= rammed. If bgp is used to send the inner label from primary egress node to = backup egress node, how bgp know there is backup egress node? Even this is = possible, the egress protection on the rsvp level should make this transpar= ent to bgp and any other applications using rsvp. If the alternative way yo= u described is used, it seems that rsvp will program a bgp entry in forward= ing plane, I don't think this is desired behavior either. [Huaimo 2] The inner label is processed by rsvp on the upstream node of the= primary egress in a way similar to the existing way for the intermediate n= ode protection. For protecting an intermediate node such as node X using f= acility backup, the upstream node of the node X will use the label allocate= d by the next hop node of X as the inner label . For protecting the primary= egress node, the upstream node of the primary egress will use the label al= located by the primary egress as the inner label . There is an object calle= d EGRESS_BACKUP object, which contains the primary egress IP address and th= e backup egress IP address. This object will be sent to the primary egress = by rsvp. At the primary egress, this information can be sent to any protoco= l, which is responsible for delivering the inner label as a upstream assign= ed label to the backup egress. The rsvp will not program any forwarding ent= ries on the backup egress for this inner label as a UA label. I don't think this is the similar case as the protection on intermediate no= de. Intermediate node would not look at the inner label at all while egress= node would because the outer label is popped on the egress node. If there = is no entry on the forwarding entries, how traffic is going forward from ba= ckup egress node? [Huaimo3] There may be some forwarding entries on the backup egress node. T= hese forwarding entries will be used to deliver the traffic from the backup= LSP. These forwarding entries are created/inserted by the component on the= backup egress that is responsible for handling the inner label as a UA lab= el from the primary egress even though the RSVP will not program any forwar= ding entries on the backup egress for this inner label as a UA label. 2) How PLR can acquire a path to backup egress node, its address is th= e same as primary egress node? [Huaimo] PLR gets the backup egress node first and then computes a path fro= m the PLR to the backup egress node. The backup egress node may be configur= ed by an operator on the ingress of the primary LSP. If it is configured, t= he ingress will include the backup egress node in the PATH message through = using EGRESS_BACKUP object. If the backup egress node is not given by the o= perator, the PLR tries to find the backup egress node, which is not the pri= mary egress node but has the same IP address as the destination IP address = of the LSP. Note that the primary egress node and the backup egress node S= HOULD have a same local address configured, and the cost to the local addre= ss on the backup egress node SHOULD be much bigger than the cost to the loc= al address on the primary egress node. The question is not about knowing the backup egress node, it is how to get = a route to backup egress node given the fact that the backup egress node ha= s the same address of the primary egress node. [Huaimo 2] The PLR computes a shortest constrained path to that address. Si= nce the cost to that address from the primary egress node is much bigger, t= he PLR will get the path to that address through the backup egress node. Why PLR does not choose the path to primary egress node, the cost is not lo= wer? [Huaimo3] When a PLR computes a backup path for protecting a node (e.g., th= e primary egress node) on the primary LSP, the PLR will exclude that node (= e.g., the primary egress node) to be protected. Thus the PLR will not selec= t the path to the primary egress node. 3) Does PLR sends the PATH message for primary LSP to backup egress no= de? [Huaimo] No. Then how the state of primary LSP on upstream node of the primary egress no= de is maintained after failure occurs? [Huaimo 2] The upstream node may continue to send the resv message to its u= pstream node along the primary LSP after the failure of the primary egress. Which upstream node continues send resv message when primary egress fails? [Huaimo3] The direct upstream node of the primary egress node continues to = send resv message to its upstream node along the primary LSP. Thus any upst= ream node (except for the ingress node) of the primary egress node will con= tinue to send the resv message to its upstream node. Thanks, Autumn From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, May 06, 2014 5:20 AM To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, It is not clear for me what you mean with "the egress protection of p2p= LSP needs to be addressed specifically with the draft." Can you please supply some text that addresses the issue(s) you mention= ed. Best Regards, Huaimo From: Huaimo Chen Sent: Monday, May 05, 2014 5:05 PM To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org Subject: draft-ietf-mpls-rsvp-egress-protection-00 Hi Autumn, Can you elaborate a little bit on "the egress protection of p2p LSP needs t= o be addressed specifically with the draft."? Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu Sent: Friday, March 14, 2014 9:03 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 I am ok with the name change, and agree with Yimin that the egress protecti= on of p2p LSP needs to be addressed specifically with the draft. -Autumn From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen Sent: Friday, March 14, 2014 4:14 PM To: Yimin Shen; Ross Callon; mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ch= en-mpls-p2mp-egress-protection@tools.ietf.org Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Adoption = draft-chen-mpls-p2mp-egress-protection-11 Hi chairs, authors, To help make this draft more generic to cover P2P LSPs, I'd like to suggest= the draft to differentiate the problems faced by P2MP LSPs and P2P LSPs, a= nd also to discuss specifically the set of problems of P2P LSPs, which are = imposed by inner labels (i.e. service labels). Of course, a complete solution for P2P LSP egress protection will require e= xtensions to Layer-2/3 VPN service label distribution protocols, which may = be out of the scope of RSVP and this draft. However, since these extensions= have already been addressed by some existing IETF work and drafts, this dr= aft could refer to them in the text. Thanks, /Yimin --_000_5316A0AB3C851246A7CA5758973207D445C84838SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Autumn,

 <= /p>

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,<= /span>

Huaimo<= /p>

From: Autumn L= iu [mailto:autumn.liu@ericsson.com]
Sent: Thursday, June 12, 2014 10:11 AM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 

Thanks for your reply. Plea= se see my comment inline.

Autumn

 

From: Autumn L= iu [mailto:autumn.liu@ericsson.c= om]
Sent: Thursday, May 08, 2014 8:44 PM
To: Huaimo Chen; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Huaimo,

 

I have some questions.

1= )   &= nbsp;  How Inner label (vpn label) acq= uired on primary egress node is sent to backup egress node? Via PATH messag= e for backup LSP? which object is used? How this label is processed? How this label is maintained?

[Huaimo] An inner label (= such as VPN label) allocated on the primary egress node may be sent to the = backup egress node in one of a few ways. One way is to use BGP to send the inner label to the backup egress node from the primary egr= ess node. Alternatively, the inner label may be sent from the primary egres= s node to the upstream node of the primary egress node through an EGRESS-BA= CKUP object in RESV message and then the upstream node sends the inner label to the backup egress node via=  an EGRESS-BACKUP object in the PATH message for the backup LSP. When= the backup egress node receives the inner label as a UA label originally f= rom the primary egress, it adds a forwarding entry with the label into the LFIB for the primary egress node. When the b= ackup egress node receives a packet from the backup LSP, it uses the top la= bel as a context label to find the LFIB for the primary egress node and the= inner label to deliver the packet to the same destination as the primary egress node according to the LFIB. =  

Note that exactly how the= inner label is sent from the primary egress node to the backup egress node= is out of scope for this document.

 <= /p>

I understand that this is o= ut of scope of this document, but it is still not clear to me how inner lab= el is going to be processed, maintained and programmed. If bgp is used to send the inner label from primary egress node to backup = egress node, how bgp know there is backup egress node? Even this is possibl= e, the egress protection on the rsvp level should make this transparent to = bgp and any other applications using rsvp. If the alternative way you described is used, it seems that rsvp wil= l program a bgp entry in forwarding plane, I don’t think this is desi= red behavior either.

 <= /p>

[Huaimo 2] The inner labe= l is processed by rsvp on the upstream node of the primary egress in a way = similar to the existing way for the intermediate node protection.  For protecting an intermediate node such as node X using facility ba= ckup, the upstream node of the node X will use the label allocated by the n= ext hop node of X as the inner label . For protecting the primary egress no= de, the upstream node of the primary egress will use the label allocated by the primary egress as the inner lab= el . There is an object called EGRESS_BACKUP object, which contains the pri= mary egress IP address and the backup egress IP address. This object will b= e sent to the primary egress by rsvp. At the primary egress, this information can be sent to any protocol,= which is responsible for delivering the inner label as a upstream assigned= label to the backup egress. The rsvp will not program any forwarding entri= es on the backup egress for this inner label as a UA label.

 <= /p>

I don’t think this is= the similar case as the protection on intermediate node. Intermediate node= would not look at the inner label at all while egress node would because the outer label is popped on the egress node. If there is no entry= on the forwarding entries, how traffic is going forward from backup egress= node?

 <= /p>

[Huaimo3] There may be so= me forwarding entries on the backup egress node. These forwarding entries w= ill be used to deliver the traffic from the backup LSP. These forwarding entries are created/inserted by the component on the back= up egress that is responsible for handling the inner label as a UA label fr= om the primary egress even though the RSVP will not program any forwarding = entries on the backup egress for this inner label as a UA label.

 

2) &= nbsp;    How PLR can acquire= a path to backup egress node, its address is the same as primary egress no= de?

[Huaimo] PLR gets the bac= kup egress node first and then computes a path from the PLR to the backup e= gress node. The backup egress node may be configured by an operator on the ingress of the primary LSP. If it is configured, the in= gress will include the backup egress node in the PATH message through using= EGRESS_BACKUP object. If the backup egress node is not given by the operat= or, the PLR tries to find the backup egress node, which is not the primary egress node but has the same IP addr= ess as the destination IP address of the LSP.  Note that the primary e= gress node and the backup egress node SHOULD have a same local address conf= igured, and the cost to the local address on the backup egress node SHOULD be much bigger than the cost to the local= address on the primary egress node.

 <= /p>

The question is not about k= nowing the backup egress node, it is how to get a route to backup egress no= de given the fact that the backup egress node has the same address of the primary egress node.

 <= /p>

[Huaimo 2] The PLR comput= es a shortest constrained path to that address. Since the cost to that addr= ess from the primary egress node is much bigger, the PLR will get the path to that address through the backup egress node.

 <= /p>

Why PLR does not choose the= path to primary egress node, the cost is not lower?

 <= /p>

[Huaimo3] When a PLR comp= utes a backup path for protecting a node (e.g., the primary egress node) on= the primary LSP, the PLR will exclude that node (e.g., the primary egress node) to be protected. Thus the PLR will not select the= path to the primary egress node.

 <= /p>

 <= /p>

3) &= nbsp;    Does PLR sends the = PATH message for primary LSP to backup egress node?

[Huaimo] No.

 <= /p>

Then how the state of primary LSP on up= stream node of the primary egress node is maintained after failure occurs?<= o:p>

[Huaimo 2] The upstream n= ode may continue to send the resv message to its upstream node along the pr= imary LSP after the failure of the primary egress.

 <= /p>

Which upstream node continu= es send resv message when primary egress fails?

 <= /p>

[Huaimo3] The direct upst= ream node of the primary egress node continues to send resv message to its = upstream node along the primary LSP. Thus any upstream node (except for the ingress node) of the primary egress node will continue to = send the resv message to its upstream node.

 <= /p>

Thanks,

Autumn

 <= /span>

 <= /p>

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Tuesday, May 06, 2014 5:20 AM
To: Autumn Liu; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: RE: draft-ietf-mpls-rsvp-egress-protection-00

 

Hi Autumn,

 

    It is not clear for me what yo= u mean with “the egress protection of p2p LSP needs to be addressed s= pecifically with the draft.”

    Can you please supply some tex= t that addresses the issue(s) you mentioned.

 

Best Regards,

Huaimo

From: Huaimo C= hen
Sent: Monday, May 05, 2014 5:05 PM
To: 'Autumn Liu'; Yimin Shen; Ross Callon; mpls@ietf.org
Subject: draft-ietf-mpls-rsvp-egress-protection-00=

 

Hi Autumn,

 <= /p>

Can you elaborate a little bit on “the egress protection of p2p LS= P needs to be addressed specifically with the draft.”?

 

Best Regards,<= /span>

Huaimo<= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Autumn Liu
Sent: Friday, March 14, 2014 9:03 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

 <= /p>

I am ok with the name cha= nge, and agree with Yimin that the egress protection of p2p LSP needs to be= addressed specifically with the draft.

-Autumn=

 <= /p>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
Sent: Friday, March 14, 2014 4:14 PM
To: Yimin Shen; Ross Callon; mpls@i= etf.org
Cc: mpls-chairs@tools.= ietf.org; dr= aft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Subject: Re: [mpls] change of name, RE: end of poll, RE: Poll for Ad= option draft-chen-mpls-p2mp-egress-protection-11

 

Hi chairs, authors,<= /o:p>

 <= /p>

To help make this draft m= ore generic to cover P2P LSPs, I’d like to suggest the draft to diffe= rentiate the problems faced by P2MP LSPs and P2P LSPs, and also to discuss specifically the set of problems of P2P LSPs, which are imposed= by inner labels (i.e. service labels).

 <= /p>

Of course, a complete sol= ution for P2P LSP egress protection will require extensions to Layer-2/3 VP= N service label distribution protocols, which may be out of the scope of RSVP and this draft. However, since these extensions have = already been addressed by some existing IETF work and drafts, this draft co= uld refer to them in the text.

 <= /p>

Thanks,=

 <= /p>

/Yimin<= /p>

 <= /p>

 

--_000_5316A0AB3C851246A7CA5758973207D445C84838SJCEML702CHMchi_-- From nobody Sun Jun 29 13:57:11 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2821A0023 for ; Sun, 29 Jun 2014 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROkIS2oAhl6E for ; Sun, 29 Jun 2014 13:57:08 -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 BA7A91A001E for ; Sun, 29 Jun 2014 13:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3752; q=dns/txt; s=iport; t=1404075428; x=1405285028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Nw0o3t6EBsXkm8L28t+fhzWkzAnMq7K3YfPgjyRXGoA=; b=GoHEOC8hSy6UKA33Fw1mDqY4sM1yz7A3QWkwaw5+HpbY7B+npKuyv/t0 BjNZk6Bxwmj4qSrVflIEBakPlUdIUeETF4hSeeJUqK301OphUpVzTisXQ zXlPwOO1nW/lUmizq1VtL9lTSrZclzyxXv/WCXksrtDB+CduuUewK4lLs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAEB8sFOtJA2J/2dsb2JhbABagmkkgSzFTQGBCBZ1hAMBAQEDAToxDhACAQgiFBAyJQIEAQ0NE4gfCAHGOheJTIRQOjEHgy2BFgEErluDQoIw X-IronPort-AV: E=Sophos;i="5.01,571,1400025600"; d="scan'208";a="336337465" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jun 2014 20:57:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5TKv7hx017455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jun 2014 20:57:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Sun, 29 Jun 2014 15:57:07 -0500 From: "Nobo Akiya (nobo)" To: Huaimo Chen , Gregory Mirsky , Yimin Shen , "mpls@ietf.org" Thread-Topic: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 Thread-Index: AQHPiAdDom4sP4did0mv4Q2gZ/v1RJtyoIOAgAGllQCAAUYOAIATJGQA///vaTA= Date: Sun, 29 Jun 2014 20:57:06 +0000 Message-ID: References: <591bf06e63ac4d978c708c598bb49d82@CO2PR05MB636.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B76EE6F@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C44C19@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B772EBB@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B77304D@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B773138@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7761F4@eusaamb103.ericsson.se> <75e6f9b9bfd44105a725a98d11e1f968@BY2PR05MB728.namprd05.prod.outlook.com>, <7347100B5761DC41A166AC17F22DF1121B776557@eusaamb103.ericsson.se> <104CBCDD-6440-453E-A224-3FAF4BE75F04@juniper.net> <7347100B5761DC41A166AC17F22DF1121B777091@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C4917F@SJCEML701-CHM.china.huawei.com>, <7347100B5761DC41A166AC17F22DF1121B7775DE@eusaamb103.ericsson.se> <8E4F5326-58DC-4F16-95A2-F9D6C87DAFF7@juniper.net> <7347100B5761DC41A166AC17F22DF1121B77784D@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D445C66964@SJCEML703-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C7496C@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C74B9A@SJCEML701-CHM.china.huawei.com> <5316A0AB3C851246A7CA5758973207D445C817F9@SJCEML702-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D445C817F9@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/nITf8VWQApokYAKrizwHAqIQQvI Cc: Raveendra Torvi , mengnan 58534 , "Boris.Zhang@telus.com" , "Toy, Mehmet" , "ningso01@gmail.com" , lizhenbin 00147097 , Alia Atlas , Ross Callon , "'Xu, Fengman'" , Quintin zhao Subject: Re: [mpls] draft-ietf-mpls-rsvp-ingress-protection-00 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, 29 Jun 2014 20:57:10 -0000 Hi Huaimo, Thank you for continued discussion! > > After the failure of the primary ingress happens and the backup > > ingress determines the failure, the backup ingress sends/refreshes > > PATH messages to the next hop node of the primary ingress of a P2P > > LSP through the backup LSP as needed. The failure can be determined > > reliably through checking the Link State Database (LSDB). >=20 > Unfortunately, I don't think this additional text solves the problem. The > backup ingress needs to know the health of the link between the source > and primary ingress. That particular link could very well be outside the= TE > topology (i.e. link is CE to PE[primary ingress]) in which case you do no= t > have the trigger for the backup ingress to send the necessary PATH messag= e. > With LSDB trigger approach, you could be limiting the scope of the soluti= on > significantly. >=20 > [Huaimo] The text will be revised. A method for reliably detecting the > failure of the primary ingress before the PATH message expires (at the ne= xt > hop nodes of the primary ingress) is needed. Thus, after the primary ingr= ess > fails, the backup ingress can use this method to detect the failure, and = the > primary LSP will still be alive since the PATH message is refreshed befor= e > the next hop nodes remove the states for the primary LSP. > It seems that the critical point is to make sure that the method to be us= ed > can reliably detect the failure of the primary ingress within a given tim= e > (seconds). > After the primary ingress fails, it will not be reachable after routing > convergence. It looks like checking whether the primary ingress is reacha= ble > is a possible method. > Before the primary ingress fails, it has some links to other nodes such t= he > link to the backup ingress node and the links to the next hop nodes of th= e > primary ingress. These links are recorded in the Link State Database (LSD= B). > After the primary ingress fails, these links will disappear from the Link= State > Database (LSDB) after IGP converges. Thus it seems that checking whether > there is not any link to the primary ingress in LSDB is another possible > method. Whether the link between the source and the primary ingress is > outside of the TE topology may not affect the method. After the primary > ingress fails, all the links to it will disappear (i.e., there will be no= link to it). >=20 > LSP "association" approach (as roughly eluded in my earlier comment) stil= l > rings a nicer sound, but I think, at this point, this document needs RSVP > signaling experts to provide comments and possibly alternative ideas. I'm not very keen on monitoring multiple links owned by the primary ingress= by the backup ingress, less the better & one is the best, ideally. Perhaps= this can be accomplished by monitoring just one IP address, as you eluded = in the first half in above. I.E. the disappearance of the primary ingress n= ode from the LSDB is the trigger for the backup ingress to send the PATH me= ssage to take over the LSP, for (3.1. Backup and Source Detect Failure) an= d (3.2. Backup Detects Failure). Question is, which IP address of the prim= ary ingress should be monitored by the backup ingress? Is it the TE router-= ID of the primary ingress or the IP address described in the Ingress IPv4/I= Pv6 Address Subobject? Assuming that the monitored IP address of the primar= y ingress by the backup ingress is a persistent address (i.e. loopback addr= ess and not address of a link), then I agree, it appears clearly described = IGP convergence based trigger procedures can produce sufficient determinism= . Thanks! -Nobo From nobody Mon Jun 30 08:55:00 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED1D1A038C for ; Mon, 30 Jun 2014 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV3BXIBg61mm for ; Mon, 30 Jun 2014 08:54:53 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A35F1A035C for ; Mon, 30 Jun 2014 08:54:53 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5UFsoTx011975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Jun 2014 10:54:51 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5UFsnjX027536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jun 2014 17:54:49 +0200 Received: from [172.27.205.228] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 30 Jun 2014 17:54:49 +0200 Message-ID: <53B18848.4070906@alcatel-lucent.com> Date: Mon, 30 Jun 2014 17:54:48 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Q6JQuIP5MDweD6_7-fXFqN9FKSg Subject: [mpls] Slots requests for MPLS WG sessions - IETF 90 - Toronto X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Martin Vigoureux , "mpls-chairs@tools.ietf.org" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:54:58 -0000 All, it is time we start building the MPLS WG agenda for Toronto. The current IETF agenda, still subject to change, is available at: https://datatracker.ietf.org/meeting/agenda/ The MPLS WG sessions are, for the moment, scheduled on: Tuesday, July 22, Morning Session I, 09:00-11:30 and Friday, July 25, Morning Session I, 09:00-11:30 Please send *me* (by replying to this e-mail and copying the co-chairs) your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + Q&As) *as well as* what the objective of the presentation is. Please send the requests before the 7th of July. Thank you Martin From nobody Mon Jun 30 10:45:36 2014 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31081A03F4; Mon, 30 Jun 2014 10:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpwBiVJ2gDft; Mon, 30 Jun 2014 10:45:25 -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 D18BD1A03C9; Mon, 30 Jun 2014 10:45:24 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-4a-53b14df0d175 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 72.46.25146.0FD41B35; Mon, 30 Jun 2014 13:45:53 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 13:45:05 -0400 From: Gregory Mirsky To: "mpls@ietf.org" , "tictoc@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-mpls-residence-time-02.txt Thread-Index: AQHPlIkqzO7VtuuSI0ezZVh8ZV3nI5uJ65kg Date: Mon, 30 Jun 2014 17:45:04 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7E41FB@eusaamb103.ericsson.se> References: <20140630173139.19513.13073.idtracker@ietfa.amsl.com> In-Reply-To: <20140630173139.19513.13073.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7E41FBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXSPn+5H343BBkuWM1rcWrqS1eJvcw+7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyXv/dwFowy6FixcvpTA2MW+y6GDk5JARMJA4svMAM YYtJXLi3nq2LkYtDSOAoo8TEt69ZIZzljBJrzraBVbEJGEm82NjD3sXIwSEi4CHRvzMNJCws ECyxZP8CRhBbRCBE4t7f06wQtpHE1QUPWUBsFgFViYdz54PFeQV8JVZeXQAWFxJwlPj48xNY nFPASWLtsx9MIDYj0EHfT60Bs5kFxCVuPZnPBHGogMSSPeehjhaVePn4HyuErSixr386O0R9 vsThRTeYIHYJSpyc+YRlAqPILCSjZiEpm4WkbBbQZ8wCmhLrd+lDlChKTOl+yA5ha0i0zpnL jiy+gJF9FSNHaXFqWW66keEmRmDEHJNgc9zBuOCT5SFGAQ5GJR5eBdONwUKsiWXFlbmHGKU5 WJTEeTWr5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYMyt40jyvKH7LvfEB4Yz+W8jCn+c az9RvexVpvy/gp0iOydqqXR93Gc4aevW6KRfXB25pQIMu7riha31PdKW8GzQWlbp/5A5TIfH U//S25UTdyQ2cyUkJdg37iy8l3ZT5fwG6yd2p8Irl6q57tmT+69HSJx9hqzBp7yl6Wf+Jv0J mnz/0JmE60osxRmJhlrMRcWJAGnAu7t5AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/vhhL8WgQYpwgkpSsAMRJS188CCQ Subject: [mpls] FW: New Version Notification for draft-mirsky-mpls-residence-time-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:45:29 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7E41FBeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQp1cGRhdGVkIHZlcnNpb24gYmVlbiBwb3N0ZWQgd2l0aDoNCuKAoiAgICAgICB1 cGRhdGVkIGZvcm1hdCBvZiBSVE0gbWVzc2FnZSAtIHRpbWUgc3luY2hyb25pemF0aW9uIHBhY2tl dCBjYXJyaWVkIHdpdGhpbiBUTFY7DQrigKIgICAgICAgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9u IG9mIFJUTSBpbiBSU1ZQLVRFIGVudmlyb25tZW50Ow0K4oCiICAgICAgIGhvbW9nZW5lb3VzIExE UCBlbnZpcm9ubWVudCBhcyBzcGVjaWFsIGNhc2UgZm9yIFJUTSB1c2UuDQoNCllvdXIgY29tbWVu dHMgYWx3YXlzIHdlbGNvbWUgYW5kIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQpXZSdyZSBwbGFubmlu ZyB0byBwcmVzZW50IGFuZCBkaXNjdXNzIHRoZXNlIHVwZGF0ZXMgaW4gVG9yb250byBhdCB0aGUg VElDVE9DIGFuZCBNUExTIFdHcyBtZWV0aW5ncy4NCg0KICAgICAgICBSZWdhcmRzLA0KICAgICAg ICAgICAgICAgIEdyZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNl bnQ6IE1vbmRheSwgSnVuZSAzMCwgMjAxNCAxMDozMiBBTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBT dGVmYW5vIFJ1ZmZpbmk7IEdyZWdvcnkgTWlyc2t5OyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgU3Rl ZmFubyBSdWZmaW5pOyBKb2huIERyYWtlOyBKb2huIERyYWtlOyBTYXNoYSBWYWluc2h0ZWluOyBT dGV3YXJ0IEJyeWFudDsgU3Rld2FydCBCcnlhbnQNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRpbWUtMDIudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lLTAy LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHcmVnIE1pcnNreSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1t aXJza3ktbXBscy1yZXNpZGVuY2UtdGltZQ0KUmV2aXNpb246ICAgICAgIDAyDQpUaXRsZTogICAg ICAgICAgUmVzaWRlbmNlIFRpbWUgTWVhc3VybWVudCBpbiBNUExTIG5ldHdvcmsNCkRvY3VtZW50 IGRhdGU6ICAyMDE0LTA2LTMwDQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczogICAgICAgICAgOQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lLTAyLnR4dA0K U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1p cnNreS1tcGxzLXJlc2lkZW5jZS10aW1lLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lLTAyDQpEaWZmOiAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWlyc2t5LW1w bHMtcmVzaWRlbmNlLXRpbWUtMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNp ZmllcyBHLUFDaCBiYXNlZCBSZXNpZGVuY2UgVGltZSBNZWFzdXJlbWVudCBhbmQNCiAgIGhvdyBp dCBjYW4gYmUgdXNlZCBieSB0aW1lIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbHMgYmVpbmcNCiAg IHRyYW5zcG9ydGVkIG92ZXIgTVBMUyBkb21haW4uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B7E41FBeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+RGVhciBBbGwsPC9kaXY+DQo8ZGl2PnVwZGF0ZWQg dmVyc2lvbiBiZWVuIHBvc3RlZCB3aXRoOjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW46MDtwYWRk aW5nLWxlZnQ6MzZwdDsiPg0KPGxpPnVwZGF0ZWQgZm9ybWF0IG9mIFJUTSBtZXNzYWdlIC0gdGlt ZSBzeW5jaHJvbml6YXRpb24gcGFja2V0IGNhcnJpZWQgd2l0aGluIFRMVjs8L2xpPjxsaT5tb3Jl IGRldGFpbGVkIGRpc2N1c3Npb24gb2YgUlRNIGluIFJTVlAtVEUgZW52aXJvbm1lbnQ7PC9saT48 bGk+aG9tb2dlbmVvdXMgTERQIGVudmlyb25tZW50IGFzIHNwZWNpYWwgY2FzZSBmb3IgUlRNIHVz ZS48L2xpPjwvdWw+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Zb3VyIGNvbW1lbnRzIGFsd2F5 cyB3ZWxjb21lIGFuZCBncmVhdGx5IGFwcHJlY2lhdGVkLjwvZGl2Pg0KPGRpdj5XZSdyZSBwbGFu bmluZyB0byBwcmVzZW50IGFuZCBkaXNjdXNzIHRoZXNlIHVwZGF0ZXMgaW4gVG9yb250byBhdCB0 aGUgVElDVE9DIGFuZCBNUExTIFdHcyBtZWV0aW5ncy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRz LDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbPGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5d DQo8YnI+DQoNClNlbnQ6IE1vbmRheSwgSnVuZSAzMCwgMjAxNCAxMDozMiBBTTxicj4NCg0KVG86 IEdyZWdvcnkgTWlyc2t5OyBTdGVmYW5vIFJ1ZmZpbmk7IEdyZWdvcnkgTWlyc2t5OyBBbGV4YW5k ZXIgVmFpbnNodGVpbjsgU3RlZmFubyBSdWZmaW5pOyBKb2huIERyYWtlOyBKb2huIERyYWtlOyBT YXNoYSBWYWluc2h0ZWluOyBTdGV3YXJ0IEJyeWFudDsgU3Rld2FydCBCcnlhbnQ8YnI+DQoNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1wbHMtcmVz aWRlbmNlLXRpbWUtMDIudHh0PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lk ZW5jZS10aW1lLTAyLnR4dDwvZGl2Pg0KPGRpdj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LW1pcnNreS1tcGxzLXJl c2lkZW5jZS10aW1lPC9kaXY+DQo8ZGl2PlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAwMjwvZGl2Pg0KPGRpdj5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzaWRlbmNlIFRpbWUgTWVhc3VybWVu dCBpbiBNUExTIG5ldHdvcms8L2Rpdj4NCjxkaXY+RG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNC0w Ni0zMDwvZGl2Pg0KPGRpdj5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPC9kaXY+DQo8ZGl2PlBh Z2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA5PC9kaXY+DQo8ZGl2PlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRpbWUtMDIudHh0 Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy1y ZXNpZGVuY2UtdGltZS0wMi50eHQ8L2E+PC9kaXY+DQo8ZGl2PlN0YXR1czombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRpbWUvIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXJza3ktbXBscy1yZXNpZGVu Y2UtdGltZS88L2E+PC9kaXY+DQo8ZGl2Pkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t aXJza3ktbXBscy1yZXNpZGVuY2UtdGltZS0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRpbWUtMDI8L2E+PC9kaXY+DQo8ZGl2PkRpZmY6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1pcnNr eS1tcGxzLXJlc2lkZW5jZS10aW1lLTAyIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1taXJza3ktbXBscy1yZXNpZGVuY2UtdGltZS0wMjwvYT48L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PkFic3RyYWN0OjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgVGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgRy1BQ2ggYmFzZWQgUmVzaWRlbmNlIFRpbWUgTWVhc3VyZW1lbnQg YW5kPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyBob3cgaXQgY2FuIGJlIHVzZWQgYnkgdGltZSBz eW5jaHJvbml6YXRpb24gcHJvdG9jb2xzIGJlaW5nPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyB0 cmFuc3BvcnRlZCBvdmVyIE1QTFMgZG9tYWluLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+VGhlIElFVEYgU2VjcmV0YXJpYXQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B7E41FBeusaamb103erics_--