From thomas.morin@orange.com Mon Dec 2 01:44:01 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4B1AE0B6; Mon, 2 Dec 2013 01:44:01 -0800 (PST) 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 Glmz5tk98oT5; Mon, 2 Dec 2013 01:43:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 365541AE0A7; Mon, 2 Dec 2013 01:43:59 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 583743B4236; Mon, 2 Dec 2013 10:43:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2770D15805B; Mon, 2 Dec 2013 10:43:56 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 10:43:55 +0100 From: To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO70MEYTO6iOJ7iEi+neAeVWl4UA== Date: Mon, 2 Dec 2013 09:43:55 +0000 Message-ID: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-ID: <79643554AEEE1844A5F56107BD07E487@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.30.60616 Cc: "rtg-dir@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-on-lags.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:44:01 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiANClRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgDQpkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgDQpzb21l dGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRv IHByb3ZpZGUgDQphc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgDQpEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZWh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCg0KQWx0aG91Z2ggdGhl c2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMs IGl0IA0Kd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3 aXRoIGFueSBvdGhlciBJRVRGIA0KTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUs IGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggDQpkaXNjdXNzaW9uIG9yIGJ5IHVw ZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtYmZkLW9uLWxhZ3MtMDMN ClJldmlld2VyOiBUaG9tYXMgTW9yaW4NClJldmlldyBEYXRlOiBEZWNlbWJlciAxc3QsIDIwMTMN CklFVEYgTEMgRW5kIERhdGU6IERlY2VtYmVyIDJuZCwgMjAxMw0KSW50ZW5kZWQgU3RhdHVzOiBQ cm9wb3NlZCBTdGFuZGFyZA0KDQpTdW1tYXJ5Og0KDQogICBUaGUgZG9jdW1lbnQgaXMgY29uY2lz ZSwgd2VsbCB3cml0dGVuLCBhbmQgcmFpc2VzIG5vIG1ham9yIGlzc3VlLg0KICAgSG93ZXZlciwg YnJpbmdpbmcgY2xhcmlmaWNhdGlvbnMgdG8gYSBmZXcgYXJlYXMgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgDQpwcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KTWFqb3IgSXNzdWVzOg0KDQogICBOb25lLg0K DQoNCk1pbm9yIElzc3VlczoNCg0KLSBNaS4xKSBUaGUgZG9jdW1lbnQgbWVudGlvbnMgdGhlIHVz ZSBvZiBhIHNwZWNpZmljIFVEUCBwb3J0IGZvciB0aGUgDQptaWNyby1CRkQgc2Vzc2lvbnMgKDY3 ODQpLiBJdCBzaG91bGQgcHJvYmFibHkgZXhwbGFpbiB3aGF0IGlzIHRoZSANCmJlaGF2aW9yIGlm IEJGRCBtZXNzYWdlcyBmcm9tIGEgbWljcm8tQkZEIHNlc3Npb25zIGFyZSByZWNlaXZlZCBvbiB0 aGUgDQpub3JtYWwgQkZEIHBvcnQgKDM3ODQpLCBhbmQgdmljZS12ZXJzYSB3aGF0IGlzIHRoZSBi ZWhhdmlvciBmb3IgQkZEIA0KbWVzc2FnZXMgZnJvbSBhIG5vbi1CRkQgc2Vzc2lvbnMgaXMgcmVj ZWl2ZWQgb24gdGhlIG1pY3JvLUJGRCBVRFAgcG9ydC4NCg0KLSBNaS4yKSBUaGUgZG9jdW1lbnQg aW5kaWNhdGVzIGluIHNlY3Rpb24gMi4yIHRoYXQgIlRoZSBkZXRhaWxzIG9mIGhvdyANClt0aGUg ZGVzdGluYXRpb24gSVAgYWRkcmVzcyBvZiB0aGUgQkZEIHBlZXJdIGlzIGxlYXJuZWQgYXJlIG91 dHNpZGUgdGhlIA0Kc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iLiAgRmlyc3QsIGFuIGV4YW1wbGUg b2YgYSBjb21tb24gcHJhY3RpY2Ugd291bGQgDQpiZSBncmVhdCB0byBwcm92aWRlIGFuIGlsbHVz dHJhdGlvbi4gIFNlY29uZCwgSSB3b3VsZCBmaW5kIGl0IHdvcnRoIA0KZG9jdW1lbnRpbmcgaG93 IHRoaXMgY2FuIGJlIGRvbmUgaW4gcHJhY3RpY2Ugb24gYW4gdW5udW1iZXJlZCBsaW5rDQoNCi0g TWkuMykgVGhlIG5vdGlvbiBvZiAiTDMgY29udGludWl0eSIgaXMgdXNlZCBpbiB0aGUgaW50cm9k dWN0aW9uLCBidXQgDQppdCBpcyBub3QgZXhwbGFpbmVkIHdoYXQgdGhpcyBtZWFuczsgaXQgd291 bGQgZGVzZXJ2ZSBiZWluZyBleHBsYWluZWQgYXMgDQp0aGUgaWRlYSBvZiAiY29udGludWl0eSIg bWF5IG5vdCBiZSBvYnZpb3VzIHRvIGludGVycHJldCBpbiBhIGNvbnRlY3QgDQp3aGVyZSBhIHNp bmdsZSBMMyBob3AgaXMgYmVpbmcgdGVzdGVkLg0KDQotIE1pLjQpIFNlY3Rpb24gNCBtZW50aW9u cyAiTE1NIiBhbmQgInNvbWUgSW50ZXJmYWNlIG1hbmFnZW1lbnQgbW9kdWxlIiANCndpdGhvdXQg cHJvdmlkaW5nIGFueSBkZWZpbml0aW9uIG5vciBleHBsYWluaW5nIHRoZSByb2xlIG9mIHN1Y2gg bW9kdWxlcy4NCg0KLSBNaS41KSBUaGUgYmVoYXZpb3IgZGVzY3JpYmVkIGluIHRoZSBBcHBlbmRp eCBsb29rcyB2ZXJ5IGltcG9ydGFudCBmb3IgDQpzbW9vdGggYWN0aXZhdGlvbiBvZiB0aGUgZmVh dHVyZSBpbiBhIHJlYWwgbmV0d29yayBhbmQgaXMgYWN0dWFsbHkgDQpzcGVjaWZpY2F0aW9uIHRl eHQuIEknbSB0aHVzIHN1cnByaXNlZCB0byBmaW5kIGl0IGluIGFuIEFwcGVuZGl4IC0tIA0Kd2hl cmUgaXQgY291bGQgYmUgbWlzc2VkIGJ5IGltcGxlbWVudG9ycy4gIEkgd291bGQgc3VnZ2VzdCBj b25zaWRlcmluZyANCm1vdmluZyB0aGlzIHRleHQgYW1vbmcgdGhlIHJlc3Qgb2YgdGVjaG5pY2Fs IHNwZWNpZmljYXRpb25zIHNlY3Rpb25zLg0KDQoNCioqIEVkaXRvcmlhbCBjb21tZW50czoNCg0K LSBFZC4xKSBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIG1lbnRpb24gb2YgdGhlIHVzZSBv ZiBhIHNwZWNpZmljIA0KVURQIHBvcnQgZnJvbSB0aGUgQWJzdHJhY3QsIHdoaWNoIHdvdWxkIHRo ZW4gYmUgbW9yZSBjb25jaXNlIC0tIHRoZSANCm1vdGl2YXRpb24gZm9yIHVzaW5nIGEgc3BlY2lm aWMgVURQIHBvcnQgc28gY291bGQgYmUgcHJvdmlkZWQgaW4gc2VjdGlvbiANCjIuMi4NCg0KLSBF ZC4yKSBTZWN0aW9uIDIuMzogIkZvciB0aGUgZm9sbG93aW5nIEJGRCBwYWNrZXRzIHdpdGggVXAg c3RhdGUgdGhlIA0KTUFDIGFkZHJlc3MgZnJvbSB0aGUgcmVjZWl2ZWQgQkZEIHBhY2tldHMgZm9y IHRoZSBzZXNzaW9uIE1BWSBiZSB1c2VkIA0KaW5zdGVhZCBvZiB0aGUgZGVkaWNhdGVkIE1BQy4g Ig0KDQogICAgPT4gInRoZSBfc291cmNlXyBNQUMgYWRkcmVzcyBmcm9tIHRoZSByZWNlaXZlZCBC RkQgcGFja2V0cyIgPyANCihhZGRpbmcgInNvdXJjZSIgd291bGQgcmVtb3ZlIGFueSByaXNrIG9m IGFtYmlndW91cyBpbnRlcnByZXRhdGlvbikNCg0KLSBFZC4zKSBTZWN0aW9uIDU6ICJNQVkgcmVt b3ZlIHRoZSBtZW1iZXIgbGluayBmcm9tIHRoZSBsb2FkIGJhbGFuY2UgDQp0YWJsZSBvbmx5IHRo YXQgbWF0Y2hlcyB0aGUgYWRkcmVzcyBmYW1pbHkgb2YgdGhlIGZhaWxpbmcgQkZEIHNlc3Npb24i DQoNCiAgIEkgaGFkIGlzc3VlcyBwYXJzaW5nIHRoaXMgc2VudGVuY2U7IHdoYXQgYWJvdXQ6ICJN QVkgcmVtb3ZlIHRoZSANCm1lbWJlciBsaW5rIGZyb20gb25seSB0aGUgbG9hZCBiYWxhbmNlIHRh YmxlIHRoYXQgbWF0Y2hlcy4uLiINCg0KICAgRnVydGhlcm1vcmUsIGl0IHdvdWxkIGJlIG5pY2Ug dG8gYWRkIGEgY29sb24gYXQgdGhlIGVuZCBvZiB0aGUgDQpzZW50ZW5jZSB0byBpbmRpY2F0ZSB0 aGF0IHdoYXQgZm9sbG93cyBpcyBhbiBpbGx1c3RyYXRpb24gb2Ygd2hhdCBwcmVjZWRlcy4NCg0K ICAgTGFzdCwgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBpbmRpY2F0aW5nIGV4cGxpY2l0bHkg dGhhdCAiVGhlIA0KbWVtYmVyIGxpbmsgTUFZIGFsc28gYmUgcmVtb3ZlZCBmcm9tIGJvdGggdGhl IEw0IGFuZCBMNiBsb2FkIGJhbGFuY2luZyANCnRhYmxlIi4NCg0KLSBFZC40KSBJIGJlbGlldmUg eW91IG5lZWQgdG8gdXBkYXRlIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIE5pdGluIEJhaGFkdXIu DQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From martin.vigoureux@alcatel-lucent.com Thu Dec 5 08:09:33 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAA11AE0B6; Thu, 5 Dec 2013 08:09:33 -0800 (PST) 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 PYfpH9PciaLh; Thu, 5 Dec 2013 08:09:31 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51A1AE0AA; Thu, 5 Dec 2013 08:09:31 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rB5G9PAX027296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Dec 2013 10:09:26 -0600 (CST) 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 rB5G9MwE001093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 17:09:24 +0100 Received: from [172.27.205.188] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Dec 2013 17:09:23 +0100 Message-ID: <52A0A533.8050100@alcatel-lucent.com> Date: Thu, 5 Dec 2013 17:09:23 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 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.39] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, opsec@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:09:33 -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://www.ietf.org/iesg/directorate/routing.html 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-opsec-vpn-leakages-02 Reviewer: Martin Vigoureux Review Date: 2013-12-05 IETF LC End Date: 2013-12-16 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document is short, focussed, and well written. However it is unclear, beyond that fact that users do not know that traffic is leaking from (rather not mapped onto) their VPN, what the real issue is. Yes, a man in the middle, might intercept the leaked traffic but this traffic is a priori intended to resources only accessible through the VPN. So, knowing that the leaked traffic will not reach the targeted destination, it is not clear which critical information it may carry. I believe that it would be worth giving an example. Note that this relates to/extends a comment raised against draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html Minor Issues: Abstract: This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. I believe this sentence does not exactly reflect the content of the document. For the first part, I think it is not only because of enabling IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN client has poor capabilities in handling securely (i.e., mapping on the VPN) packets which use one of the two address families. By the way this is said in section 4: the resulting VPN traffic leakage is a side-effect of employing IPv6-unaware VPN software in a dual-stacked host/network. Thanks -m From warren@kumari.net Thu Dec 5 11:49:16 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18A11AE05B; Thu, 5 Dec 2013 11:49:16 -0800 (PST) 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, RP_MATCHES_RCVD=-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 xVfLfQEz-M82; Thu, 5 Dec 2013 11:49:14 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793161AE04F; Thu, 5 Dec 2013 11:49:14 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id 5AB561B4046D; Thu, 5 Dec 2013 14:49:10 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <52A0A533.8050100@alcatel-lucent.com> Date: Thu, 5 Dec 2013 14:49:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8426E7F4-A2D8-4200-8642-8E10A9B70619@kumari.net> References: <52A0A533.8050100@alcatel-lucent.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Thu, 05 Dec 2013 16:42:40 -0800 Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, Warren Kumari , opsec@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:49:17 -0000 On Dec 5, 2013, at 11:09 AM, Martin Vigoureux = wrote: > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. Just a quick note to say think you for the helpful review=85 W > 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://www.ietf.org/iesg/directorate/routing.html >=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-opsec-vpn-leakages-02 > Reviewer: Martin Vigoureux > Review Date: 2013-12-05 > IETF LC End Date: 2013-12-16 > Intended Status: Informational >=20 > Summary: > This document is basically ready for publication, but has nits that = should be considered prior to publication. >=20 > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that = traffic is leaking from (rather not mapped onto) their VPN, what the = real issue is. Yes, a man in the middle, might intercept the leaked = traffic but this traffic is a priori intended to resources only = accessible through the VPN. So, knowing that the leaked traffic will not = reach the targeted destination, it is not clear which critical = information it may carry. I believe that it would be worth giving an = example. > Note that this relates to/extends a comment raised against = draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. > http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html >=20 > Minor Issues: > Abstract: > This document discusses some scenarios in which such VPN leakages > may occur, either as a side effect of enabling IPv6 on a local > network, or as a result of a deliberate attack from a local > attacker. > I believe this sentence does not exactly reflect the content of the = document. For the first part, I think it is not only because of enabling = IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN = client has poor capabilities in handling securely (i.e., mapping on the = VPN) packets which use one of the two address families. > By the way this is said in section 4: > the resulting VPN traffic leakage is a side-effect of employing > IPv6-unaware VPN software in a dual-stacked host/network. >=20 > Thanks > -m >=20 --=20 "Does Emacs have the Buddha nature? Why not? It has bloody well = everything else..." From fgont@si6networks.com Fri Dec 6 09:02:29 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749D21AE0B3; Fri, 6 Dec 2013 09:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HQu4Lf7Yzf2; Fri, 6 Dec 2013 09:02:27 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B47011AE054; Fri, 6 Dec 2013 09:02:27 -0800 (PST) Received: from [2001:5c0:1000:a::25b9] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Voyn6-0001Um-LV; Fri, 06 Dec 2013 18:02:13 +0100 Message-ID: <52A20312.9080408@si6networks.com> Date: Fri, 06 Dec 2013 14:02:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Vigoureux , rtg-ads@tools.ietf.org References: <52A0A533.8050100@alcatel-lucent.com> In-Reply-To: <52A0A533.8050100@alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Dec 2013 09:23:39 -0800 Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, opsec@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:02:29 -0000 Hi, Martin! Thanks so much for your review! -- Please find my comments inline... On 12/05/2013 01:09 PM, Martin Vigoureux wrote: > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that > traffic is leaking from (rather not mapped onto) their VPN, what the > real issue is. Yes, a man in the middle, might intercept the leaked > traffic but this traffic is a priori intended to resources only > accessible through the VPN. The most basic scenario, as described in the I-D is this: You attend a conference and tunnel everything through the VPN (for security/privacy reasons). But then all your traffic goes in the clear... The implications are that the user can now be monitored wrt which istes he visits, etc., his location is leaked out, plaintext passwords come up in the clear, MITM attacks become possible, etc. > So, knowing that the leaked traffic will not > reach the targeted destination, it is not clear which critical > information it may carry. I believe that it would be worth giving an > example. This is what we currently have in the I-D, as an example, in the intro: ---- cut here ---- It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. The same is true for mobile nodes that establish VPN connections to secure their traffic while they roam from one network to another. In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear) acceptable, as the VPN provides security services (such as data integrity and/or confidentiality) for all communications made over the VPN. ---- cut here ---- Please let me know if you think this should be modified/augmented... and, if possible, provide advice regarding "how" that should be done. :-) > Minor Issues: > Abstract: > This document discusses some scenarios in which such VPN leakages > may occur, either as a side effect of enabling IPv6 on a local > network, or as a result of a deliberate attack from a local > attacker. > I believe this sentence does not exactly reflect the content of the > document. For the first part, I think it is not only because of enabling > IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN > client has poor capabilities in handling securely (i.e., mapping on the > VPN) packets which use one of the two address families. Would this modification address your comment?: ---- cut here ---- This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware software in networks that support IPv6 (either legitimately, or as a result of a deliberate attack from a local attacker). ---- cut here ---- Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From martin.vigoureux@alcatel-lucent.com Mon Dec 9 08:10:32 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DDD1ADF73; Mon, 9 Dec 2013 08:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7IS5y-uLiJh; Mon, 9 Dec 2013 08:10:30 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7A1ADFCE; Mon, 9 Dec 2013 08:10:29 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rB9GAKM6008758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 10:10:22 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rB9GAHK7023717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 17:10:18 +0100 Received: from [172.27.205.188] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 9 Dec 2013 17:10:17 +0100 Message-ID: <52A5EB68.4000409@alcatel-lucent.com> Date: Mon, 9 Dec 2013 17:10:16 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Fernando Gont References: <52A0A533.8050100@alcatel-lucent.com> <52A20312.9080408@si6networks.com> In-Reply-To: <52A20312.9080408@si6networks.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: rtg-dir@ietf.org, draft-ietf-opsec-vpn-leakages.all@tools.ietf.org, ler762@gmail.com, opsec@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-opsec-vpn-leakages-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:10:32 -0000 Fernando, thanks for following up. Your explanations clarify a lot, so I think these clarifications need to be brought to the draft. You are free not to take the suggested text as is, but I think you need to keep the objective. I would start by clarifying the Abstract: OLD: That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. NEW: That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be sent in the clear on the local network towards the final destination. OLD: This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. NEW: This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware VPN software. Then I believe you need to rework the first paragraph of the Introduction to clearly and rapidly state your problem space rather than loosing the reader in the VPN-to-corporate-resources sink. This echoes the comment you also received from Lee and the original one from KK. OLD: It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. The same is true for mobile nodes that establish VPN connections to secure their traffic while they roam from one network to another. In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear) acceptable, as the VPN provides security services (such as data integrity and/or confidentiality) for all communications made over the VPN. NEW: It is a very common practice for users of a VPN software to establish a VPN connection towards a targeted endpoint when their terminal, which hosts the VPN software, is itself connected to a local network (e.g., a conference network). This is typically done to gain access to some resources which are otherwise not accessible, but also to secure the terminal's traffic through the local network (e.g., against attackers that might be connected to the same local network). The latter case constitute the problem space of this document. Indeed, it is sometimes assumed that employing a VPN connection makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, as a VPN provides security services (such as data integrity and/or confidentiality) for all communications made over that VPN. However, this document illustrates that under certain circumstances, some traffic might not be mapped onto the VPN and thus be sent in the clear on the local network. -m Le 06/12/2013 18:02, Fernando Gont a écrit : > Hi, Martin! > > Thanks so much for your review! -- Please find my comments inline... > > On 12/05/2013 01:09 PM, Martin Vigoureux wrote: >> Comments: >> This document is short, focussed, and well written. >> However it is unclear, beyond that fact that users do not know that >> traffic is leaking from (rather not mapped onto) their VPN, what the >> real issue is. Yes, a man in the middle, might intercept the leaked >> traffic but this traffic is a priori intended to resources only >> accessible through the VPN. > > The most basic scenario, as described in the I-D is this: > You attend a conference and tunnel everything through the VPN (for > security/privacy reasons). But then all your traffic goes in the clear... > > The implications are that the user can now be monitored wrt which istes > he visits, etc., his location is leaked out, plaintext passwords come up > in the clear, MITM attacks become possible, etc. > > > >> So, knowing that the leaked traffic will not >> reach the targeted destination, it is not clear which critical >> information it may carry. I believe that it would be worth giving an >> example. > > This is what we currently have in the I-D, as an example, in the intro: > > ---- cut here ---- > It is a very common practice for employees working at remote > locations to establish a VPN connection with their office or home > office. This is typically done to gain access to some resources only > available within the company's network, but also to secure the host's > traffic against attackers that might be connected to the same remote > location. The same is true for mobile nodes that establish VPN > connections to secure their traffic while they roam from one network > to another. In some scenarios, it is even assumed that employing a > VPN connection makes the use of insecure protocols (e.g. that > transfer sensitive information in the clear) acceptable, as the VPN > provides security services (such as data integrity and/or > confidentiality) for all communications made over the VPN. > ---- cut here ---- > > Please let me know if you think this should be modified/augmented... > and, if possible, provide advice regarding "how" that should be done. :-) > > > >> Minor Issues: >> Abstract: >> This document discusses some scenarios in which such VPN leakages >> may occur, either as a side effect of enabling IPv6 on a local >> network, or as a result of a deliberate attack from a local >> attacker. >> I believe this sentence does not exactly reflect the content of the >> document. For the first part, I think it is not only because of enabling >> IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN >> client has poor capabilities in handling securely (i.e., mapping on the >> VPN) packets which use one of the two address families. > > Would this modification address your comment?: > > ---- cut here ---- > This document discusses some scenarios in which such VPN leakages > may occur as a result of employing IPv6-unaware software in networks > that support IPv6 (either legitimately, or as a result of a > deliberate attack from a local attacker). > ---- cut here ---- > > Thanks! > > Best regards, > From adrian@olddog.co.uk Tue Dec 10 14:31:39 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA991AE0C9 for ; Tue, 10 Dec 2013 14:31:39 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkPasW2mmgWl for ; Tue, 10 Dec 2013 14:31:36 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 520821AE071 for ; Tue, 10 Dec 2013 14:31:36 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBAMVI1Y008854; Tue, 10 Dec 2013 22:31:18 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBAMV7G2008751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 22:31:17 GMT From: "Adrian Farrel" To: Date: Tue, 10 Dec 2013 22:31:07 -0000 Message-ID: <06a101cef5f7$8b238090$a16a81b0$@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: Ac719szOjTarvNupQCqnZxdodTe9XQ== Content-Language: en-gb Cc: Dan Li , j.schoenwaelder@jacobs-university.de, db3546@att.com, stbryant@cisco.com Subject: [RTG-DIR] Final routing area review for draft-ietf-netmod-routing-cfg in WG last call X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:31:39 -0000 Hi Directorate, As observed by Juergen, this document has been around for review a number of times. Rather than finger one of you, I'll lay this open for all and any of you to revisit or review again and encourage any/all of you to jump to the aid of the Netmod working group. Thanks, Adrian > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 03 December 2013 16:20 > To: rtg-ads@tools.ietf.org > Cc: David Kessens; Benoit Claise > Subject: routing area reviews for draft-ietf-netmod-routing-cfg in WG last call > > Stewart and Adrian, > > the NETMOD working group has the routing configuration data model in > WG last call. It would surely be nice if you can find some routing > experts to take a look at it as well. Note that we did reach out for > routing area reviews before: > > - Early review had been requested in 2011. Eric Gray provided some > helpful feedback. > > - Further routing area reviews have been requested in 2012. Yi Yang > and Thomas Morin provided a review back than. > > - Further reviews were also requested by I2RS people in 2012. Bruno > Rijsman provided a review. > > In 2013, Ladislav Lhotka (our document editor) has been working with > some I2RS people to get things aligned with their work. > > Anyway, it would be nice to have a final check from routing experts > that this document is OK. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From thomas.morin@orange.com Wed Dec 11 09:01:16 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D4F1AD8EC for ; Wed, 11 Dec 2013 09:01:16 -0800 (PST) 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 le5ofe1X2Hxo for ; Wed, 11 Dec 2013 09:01:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8581AE019 for ; Wed, 11 Dec 2013 09:01:11 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id AFE913B4DDC; Wed, 11 Dec 2013 18:01:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 81B6318004B; Wed, 11 Dec 2013 18:01:04 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 18:01:04 +0100 From: To: Marc Binderberger Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO9TIuWnGCCoHNPUeHa/9P+WPrMJpPKf2A Date: Wed, 11 Dec 2013 17:01:03 +0000 Message-ID: <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> In-Reply-To: <20131209145824955173.389eae90@sniff.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 X-Mailman-Approved-At: Wed, 11 Dec 2013 09:07:46 -0800 Cc: Carlos Pignataro , "Bhatia, Manav \(Manav\)" , "rtg-dir@ietf.org" , Mach Chen , Sami Boutros , "jeff.tantsura@ericsson.com" , Nobo Akiya , "bfd-chairs@tools.ietf.org" , "Henderickx, Wim \(Wim\)" , Marc Binderberger , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:01:16 -0000 SGkgTWFyYywNCg0KMjAxMy0xMi0wOSwgTWFyYyBCaW5kZXJiZXJnZXI6DQo+DQo+IFRoZXJlIGlz IG9uZSBwb2ludCB3aGljaCBJIGV4cGxpY2l0bHkgZG8gbm90IHdhbnQgdG8gZm9sbG93OiB0aGUN Cj4gYXBwZW5kaXguIFdlIG1vdmVkIGl0J3MgY29udGVudCBhIHdoaWxlIGFnbyBmcm9tIHRoZSBt YWluIHRleHQgaW50byB0aGUNCj4gYXBwZW5kaXgsIHJlYWxpemluZyB0aGF0IGl0IGlzIG1vcmUg YWJvdXQgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBmcm9tDQo+IGV4aXN0aW5nIGltcGxlbWVudGF0 aW9ucyBhbmQgbm90IG5lY2Vzc2FyeSB0byBtYWtlIHRoZSBmZWF0dXJlIHJ1bm5pbmcuDQo+IEku ZS4gaXQgcmVwcmVzZW50cyBnb29kIHByYWN0aWNlIGZvcg0KPiBpbXBsZW1lbnRvcnMgd2FudGlu ZyB0byBtYWtlIHVzZSBvZiB0aGlzIGZlYXR1cmUgYnV0IHdlIGRvbid0IHdhbnQgdG8NCj4gY29u c3RyYWluIGEgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbiBmcm9tIGRvaW5nIHNvbWV0aGluZyBt b3JlIGNsZXZlci4NCj4gSXQncyBub3QgaW50ZW5kZWQgdG8gYmUgYSBub3JtYXRpdmUgdGV4dCwg bmVpdGhlciBmb3IgdGhlIHByb3RvY29sIG5vcg0KPiB0aGUgb3BlcmF0aW9ucy4NCj4NCj4gSG9w ZSB0aGlzIGlzIG9rYXkgd2l0aCB5b3UuDQoNCkkgdGhpbmsgdGhpcyBwb2ludCB3b3VsZCBkZXNl cnZlIGEgYml0IG9mIGRpc2N1c3Npb24uDQoNCkZpcnN0IG9mIGFsbCwgbGV0IG1lIHBvaW50IG91 dCB0aGF0IHRoZSBhcHBlbmRpeCBpcyB1c2luZyBSRkMyMTE5IA0KbGFuZ3VhZ2UgKGUuZy4gIlNI T1VMRCBOT1QiKS4gSWYgaW4gZmFjdCB0aGUgdGV4dCB0aGVyZSBpcyBub3QgbWVhbnQgdG8gDQpi ZSBjb25zdHJhaW5pbmcsIHRoZW4gaXQgcHJvYmFibHkgc2hvdWxkIG5vdCB1c2Ugc3VjaCBsYW5n dWFnZS4NCg0KSG93ZXZlciwgYXMgYSBjb250cmlidXRvciB3b3JraW5nIGZvciBhbiBvcGVyYXRv ciwgSSBhbSBwYXJ0aWN1bGFybHkgDQpjYXJlZnVsIGFib3V0IGRvY3VtZW50aW5nIHJlY29tbWVu ZGVkIGFwcHJvYWNoZXMgdG8gbWFrZSBhIGRlcGxveW1lbnQgDQpzbW9vdGguIFRoaXMgaXMgdmVy eSB1c2VmdWwgYW5kIHJlYWxseSBkZXNlcnZlcyBJTUhPIHRvIGFwcGVhciBpbiB0aGUgDQpkb2N1 bWVudCBpbiBhIHBvc2l0aW9uIHRoYXQgZ2l2ZXMgaXQgYSBmYWlyIGNoYW5jZSB0byBiZSByZWFk IGJ5IA0KaW1wbGVtZW50b3JzLg0KDQpJIHdvdWxkIGVuY291cmFnZSB5b3UgdG8gY29uc2lkZXIg bW92aW5nIHRoZSB0ZXh0IGluIHRoZSBtYWluIHNlY3Rpb24gb2YgDQp0aGUgZG9jdW1lbnQuIFBl cmhhcHMgbm90IGFzIHNwZWNpZmljYXRpb24gdGV4dCB1c2luZyBSRkMyMTE5IGxhbmd1YWdlLCAN CmJ1dCBwZXJoYXBzIHdvcmRlZCBpbiB0ZXJtcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUg bWF5IGJlIG90aGVyIA0Kd2F5cyB0byBvYnRhaW4gYSBzaW1pbGFyIGVmZmVjdCBidXQgdGhhdCBp bXBsZW1lbnRvcnMgc2hvdWxkIHRha2UgY2FyZSANCmFib3V0IHN1Y2ggaXNzdWVzLg0KDQoNCj4g Rm9yIHRoZSBMMyBjb250aW51aXR5IChNaS4zKSwgd2Uga2VwdCB0aGUgY2hhbmdlcyBzbWFsbCwg YWRkZWQgdG8gc2F5DQo+ICJpLmUuIHRoZSBhYmlsaXR5IGZvciBlYWNoIG1lbWJlciBsaW5rIHRv IGJlIGFibGUgdG8gZm9yd2FyZCBMMw0KPiBwYWNrZXRzLiIgV2hlbiBpbXBsZW1lbnRpbmcsIHRo aXMgYXNwZWN0IGlzIGxhcmdlbHkgaW1wbGljaXQgYXMgdGhlIEJGRA0KPiBwcm9jZXNzaW5nIHdp bGwgdXNlIGxheWVyLTMgY29kZS4gTWFraW5nIG1vcmUgZGV0YWlsZWQgc3RhdGVtZW50cyBvcg0K PiByZXF1aXJlbWVudHMgaXMgZGlmZmljdWx0IGFzIGl0IGlzIGltcGxlbWVudGF0aW9uIHNwZWNp ZmljLg0KDQpXaHkgbm90IHJlcGxhY2UgIiBhbmQgd291bGQgYmUgYWJsZSB0byAgdmVyaWZ5IEwz IENvbnRpbnVpdHkgcGVyIG1lbWJlciANCmxpbms7IGkuZS4gdGhlIGFiaWxpdHkgZm9yIGVhY2gg IG1lbWJlciBsaW5rIHRvIGJlIGFibGUgdG8gZm9yd2FyZCBMMyANCnBhY2tldHMuICIgYnkgImFu ZCB3b3VsZCBiZSBhYmxlIHRvIHZlcmlmeSB0aGUgYWJpbGl0eSBmb3IgZWFjaA0KICBtZW1iZXIg bGluayB0byBiZSBhYmxlIHRvIGZvcndhcmQgTDMgcGFja2V0cyIuDQoNClNhaWQgb3RoZXJ3aXNl LCB3aGF0IGRvZXMgdGhlIHRlcm0gIkwzIGNvbnRpbnVpdHkiIGJyaW5nID8NCihJIHNlZSB0aGUg ZHJhd2JhY2sgdGhhdCBpdCBtYXkgYnJpbmcsIGdpdmVuIHRoYXQgaXQncyB1bmNsZWFyIHRvIG1l IA0Kd2hhdCAiY29udGludWl0eSIgbWVhbnMgd2hlbiB3ZSBsb29rIGF0IGp1c3Qgb25lIElQIGZv cndhcmRpbmcgaG9wOiBCRkQgDQpMQUcgZG9lcyBub3QgdmVyaWZ5IHRoZSBhYmlsaXR5IG9mIHRo ZSBib3ggdG8gZm9yd2FyZCBvbmUgSVAgcGFja2V0IGZyb20gDQpvbmUgaW50ZXJmYWNlIHRvIGFu b3RoZXIsIHJpZ2h0ID8pDQoNCg0KPiBGb3IgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgKE1p LjIpIEkgb25seSBtZW50aW9uIHRoZSB0d28gZXh0cmVtZXMsDQo+IG1hbnVhbCBjb25maWd1cmF0 aW9uIGFuZCBzb21lIC0gdW5zcGVjaWZpZWQgLSBvdXQtb2YtYmFuZCBwcm90b2NvbCB0bw0KPiBs ZWFybiB0aGUgYWRkcmVzcy4gRm9yIHVubnVtYmVyZWQgbGlua3MgdGhlIGRlc3RpbmF0aW9uIElQ IGluIHRoZSBCRkQNCj4gcGFja2V0cyB3b3VsZCBiZSBsaWtlbHkgc29tZSAibG9vcGJhY2siIGFk ZHJlc3MuIFRoZSBkcmFmdCB3b3JkcyB0aGlzIGFzDQo+DQo+ICAgICBDb250cm9sIHBhY2tldHMg dXNlIGEgZGVzdGluYXRpb24gSVAgYWRkcmVzcyB0aGF0IGlzIGNvbmZpZ3VyZWQgb24NCj4gICAg IHRoZSBwZWVyIHN5c3RlbSBhbmQgY2FuIGJlIHJlYWNoZWQgdmlhIHRoZSBMQUcgaW50ZXJmYWNl Lg0KPg0KPiBGWUksIG1hbnVhbCBjb25maWd1cmF0aW9uIG9mIHRoZSBJUCBkZXN0aW5hdGlvbiBh ZGRyZXNzIGlzIHdoYXQgdGhlDQo+IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyB1c2UgdG9kYXku DQoNCk9rLiBUaGUgcmV2aXNlZCB0ZXh0IHNlZW1zIGdvb2QgZW5vdWdoLg0KDQoNCj4NCj4gRm9y IHRoZSBvdGhlciBjb21tZW50cyBJIGZvbGxvd2VkIHlvdXIgYWR2aWNlL3N1Z2dlc3Rpb25zLg0K DQpJIGRpZCBub3QgZmluZCB0ZXh0IGFkZHJlc3NpbmcgTWkuMSk6DQoNCiggSXQgc2hvdWxkIHBy b2JhYmx5IGV4cGxhaW4gd2hhdCBpcyB0aGUgYmVoYXZpb3IgaWYgQkZEIG1lc3NhZ2VzIGZyb20g YQ0KbWljcm8tQkZEIHNlc3Npb25zIGFyZSByZWNlaXZlZCBvbiB0aGUgbm9ybWFsIEJGRCBwb3J0 ICgzNzg0KSwgYW5kDQp2aWNlLXZlcnNhIHdoYXQgaXMgdGhlIGJlaGF2aW9yIGZvciBCRkQgbWVz c2FnZXMgZnJvbSBhIG5vbi1CRkQgc2Vzc2lvbnMNCmlzIHJlY2VpdmVkIG9uIHRoZSBtaWNyby1C RkQgVURQIHBvcnQuICkNCg0KVGhlIGFkZGVkIHRleHQgZG9lcyBub3Qgc2VlbSB0byBhZGRyZXNz IHRoZSBhYm92ZS4NCg0KQWRkaXRpb25hbGx5LCBJIGZpbmQgdGhlIGZvbGxvd2luZyBuZXcgc2Vu dGVuY2UgInNjYXJ5IiAoaWYgSSBtYXkgc2F5KToNCg0KICAgICBUaGUJZGVtdWx0aXBsZXhpbmcg cHJvY2VkdXJlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IHdpbGwNCiAgICAgcHJldmVudCBh bnkJQkZEIHNlc3Npb24gdG8gZ28gaW50byBVcCBzdGF0ZS4NCg0KVGhhdCBzb3VuZHMgbGlrZSBC RkQgd2lsbCBub3Qgd29yayBhdCBhbGwgYW55bW9yZS4uLiA7KQ0KDQpJdCBzb3VuZHMgbGlrZSB0 aGVyZSBhcmUgc29tZSB3b3JkcyBtaXNzaW5nLCBlLmcuIHNvbWV0aGluZyBsaWtlICJhbnkgDQpz dWNoIHVud2FudGVkIEJGRCBzZXNzaW9uIi4uLj8NCg0KVGhhbmtzLA0KDQotVGhvbWFzCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91LgoK From lberger@labn.net Wed Dec 11 10:57:56 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22E21ADBCD for ; Wed, 11 Dec 2013 10:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 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_BL_SPAMCOP_NET=1.347, 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 RN_yvldBqwkM for ; Wed, 11 Dec 2013 10:57:54 -0800 (PST) Received: from alt-proxy11.mail.unifiedlayer.com (alt-proxy11.mail.unifiedlayer.com [74.220.211.241]) by ietfa.amsl.com (Postfix) with SMTP id 0EB101ADFCA for ; Wed, 11 Dec 2013 10:57:54 -0800 (PST) Received: (qmail 16684 invoked by uid 0); 11 Dec 2013 18:57:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 11 Dec 2013 18:57:48 -0000 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=KtiiThZQIFG/HolH1D6RdGpKLloZAWWQGWj4armCVUE=; b=XxmvNnXjY3cNn3ewS1PqJoW+PUmtPgYyhXRdEQFmxGnqzp+6tgsVODcE+CBd2MHPgbljyoqkJS/46FTw/mOLtZ0GwUrOSxtC+eOy8gf1igP3tJJXzRdtoBGOBwtpXFQ3; Received: from box313.bluehost.com ([69.89.31.113]:43504 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vqoyi-0001OY-AH; Wed, 11 Dec 2013 11:57:48 -0700 Message-ID: <52A8B5AB.4040708@labn.net> Date: Wed, 11 Dec 2013 13:57:47 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rtg-dir@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 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} Cc: draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:57:57 -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. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html 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-rtgwg-cl-requirement-13.txt Reviewer: Lou Berger Review Date: 2013-12-11 IETF LC End Date: 2013-12-09 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: I think the document is greatly improved since the previous last call. I have some comments and reservations on the document that are described below. As discussed on the list, I remain concerned about the value of defining requirements in terms of nebulous "Performance Objectives", but as this is acceptable to the WG I will not elaborate on this concern further. Major Issues: No major issues found. Minor Issues: 1. Terminology & consistency: the document coins the term "Advanced Multipath": Advanced Multipath is a formalization of multipath techniques Do you see this term as a new noun, like LSP, or as an adjective? I expected the latter, i.e. that it be used like "multipath" is used in the above sentence, but it seems to be used as a new noun. I'm not sure coining a new noun really makes sense, but if this the intent then the last paragraph of section 2 needs to be revised as "Advanced Multipath" will now have a specific definition as opposed to a generic term. Also I suggest always capitalizing it (or even using the abbreviation "AM") will clarify this distinction. 2. Editorial: server and client layer vs upper and lower layer. The document uses server and client layer networks and LSPs and, sometimes interchangeably or redundantly, upper and lower layer networks and LSPs. I think this issue can be resolved by avoiding the term client/server when referring to network layers and just using the lower/upper terminology. The one exception to this is in the definition Client LSP which should simply be defined in the context of a multipath, i.e.: OLD A client LSP is an LSP which has been set up over a server layer. NEW A client LSP is an LSP which has been set up over Advanced Multipath. I think this also means that usage of the term "Client" is limited to "Client LSP". 3. Technical: The document should make it clear that LSPs can provide paths from an Advanced Multipath. I suggest adding something like the the following at the end of page 3 d. a lower layer LSP. and at the end of the Component Link definition: A component link may be provided via an LSP. 4. Editorial: Unless I'm mistaken, the requirements in this document apply to the Advanced Multipath solution. In most cases the document states requirements in the form of "The solution", but in a few cases it just says "advanced multipath". I think these cases should be changed to apply to an "Advanced Multipath solution". I think this comment applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. 5. Technical: use of "indicate" in FR10-13, FR14, FR15: In these cases it is unclear if the requirements apply to (a) a client's ability to indicate a desired service/LSP constraint or (b) a selected component link's attribute that will be used by a client LSP, (c) both, or (d) something completely different The requirements should be clear to which entity the requirement applies. 6. The last paragraph in section 3.3. strikes me as both odd and out of place. There are so many possible decisions that must be considered by network operators relative to disruption and optimization. Why mention just "power reduction"? Is there something special about the interactions of multipath and power reduction? What value / information does this paragraph add? 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? Nits: - References should be provided in all cases when referring to "existing ... techniques" Using line numbers from http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt Line 112 s/SHOULD/should Line 118 s/MAY/may Line 149, match intro: s/Advanced Multipath meets/Advanced Multipath is a formalization of multipath techniques that meet Lines 251-254, beginning with "The" through the end of the paragraph. This should be an FR. That's it, Lou From jhaas@slice.pfrc.org Wed Dec 11 10:38:32 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF151ADF8C for ; Wed, 11 Dec 2013 10:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, 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 gXXNRJbdZt80 for ; Wed, 11 Dec 2013 10:38:31 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB01ADBCD for ; Wed, 11 Dec 2013 10:38:31 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id AC5DBC126; Wed, 11 Dec 2013 13:38:25 -0500 (EST) Date: Wed, 11 Dec 2013 13:38:25 -0500 From: Jeffrey Haas To: thomas.morin@orange.com Message-ID: <20131211183825.GA4843@pfrc> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 11 Dec 2013 11:01:38 -0800 Cc: Carlos Pignataro , "Bhatia, Manav \(Manav\)" , "rtg-dir@ietf.org" , Marc Binderberger , Mach Chen , Sami Boutros , "jeff.tantsura@ericsson.com" , Nobo Akiya , "bfd-chairs@tools.ietf.org" , "Henderickx, Wim \(Wim\)" , Marc Binderberger , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:38:33 -0000 On Wed, Dec 11, 2013 at 05:01:03PM +0000, thomas.morin@orange.com wrote: > First of all, let me point out that the appendix is using RFC2119 > language (e.g. "SHOULD NOT"). If in fact the text there is not meant to > be constraining, then it probably should not use such language. Removing the 2119 capitalization is certainly easy to do. > However, as a contributor working for an operator, I am particularly > careful about documenting recommended approaches to make a deployment > smooth. This is very useful and really deserves IMHO to appear in the > document in a position that gives it a fair chance to be read by > implementors. Speaking as an implementor, if it's in the document, I read it as part of my work. > I would encourage you to consider moving the text in the main section of > the document. Perhaps not as specification text using RFC2119 language, > but perhaps worded in terms to make it clear that there may be other > ways to obtain a similar effect but that implementors should take care > about such issues. The difficulty here is that the primary purpose of the draft is to describe protocol operations. The purpose of the appendix is to offer advice to implementors of the feature for graceful integration of the feature. However, that advice is not normative to the operation of the protocol. Having worked as an implementor across a number of companies over the years, I am extremely paranoid about placing such operational advice in the context of a specification. Doing such things tends to get interop labs/testsuites pedantically testing the behavior and saying "you're not compliant", even if the reason for the variance in the operational behavior is internally justified. The other half of this is that if someone does some behavior that is *better* than that covered in the document they may become non-compliant, while the on-the-wire protocol is not impacted. I would rather delete the appendix than make it take on the air of something that is a normative portion of the protocol. We were trying to be nice by offering implementation wisdom rather than making the next implementor run into the same issues we did in our implementations. > > For the L3 continuity (Mi.3), we kept the changes small, added to say > > "i.e. the ability for each member link to be able to forward L3 > > packets." When implementing, this aspect is largely implicit as the BFD > > processing will use layer-3 code. Making more detailed statements or > > requirements is difficult as it is implementation specific. > > Why not replace " and would be able to verify L3 Continuity per member > link; i.e. the ability for each member link to be able to forward L3 > packets. " by "and would be able to verify the ability for each > member link to be able to forward L3 packets". > > Said otherwise, what does the term "L3 continuity" bring ? > (I see the drawback that it may bring, given that it's unclear to me > what "continuity" means when we look at just one IP forwarding hop: BFD > LAG does not verify the ability of the box to forward one IP packet from > one interface to another, right ?) I suspect this language was influenced by the VCCV feature and the language that was pushed upon BFD for that purpose. I don't have a strong feeling about keeping "L3 continuity" and would be fine accepting your text. Perhaps the other authors have some memory of why we went with that particular terminology. > > For the other comments I followed your advice/suggestions. > > I did not find text addressing Mi.1): > > ( It should probably explain what is the behavior if BFD messages from a > micro-BFD sessions are received on the normal BFD port (3784), and > vice-versa what is the behavior for BFD messages from a non-BFD sessions > is received on the micro-BFD UDP port. ) > > The added text does not seem to address the above. > > Additionally, I find the following new sentence "scary" (if I may say): > > The demultiplexing procedure described in this document will > prevent any BFD session to go into Up state. > > That sounds like BFD will not work at all anymore... ;) I tend to agree. I didn't have better text to offer, but the implication really is that the two instantiations of the BFD feature (BFD for IP/5881 and BFD over LAG) are really "ships in the night" features. If an implementation was somehow able to configure BFD port numbers such that the features were crossed... things would fail in rather peculiar ways. We do not have similar documentation covering other applications of BFD where specific bootstrapping scenarios are required (e.g. VCCV). I'm not sure it's applicable here either. In particular, a standard BFD session misconfigured to use BFD over LAG *might* be able to bootstrap a single link if it wasn't using the multicast discovery and the given implementation of IP on the line card was able to progress BFD packet processing with semi-resolved ARP addresses. But as you see, there's a significant number of "the following things would have to also be true". > It sounds like there are some words missing, e.g. something like "any > such unwanted BFD session"...? Honestly, I would prefer to drop this last sentence. The prior words seem strong enough: The new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. An example is configuring a LAG with micro BFD sessions on one side but using a [RFC5881] BFD session for the LAG (treated as a single interface) on the opposite side. What your comment was asking was "describe what happens if you misconfigure the port numbers". See my comments about about the number of additional variables that may be present in the implementation. -- Jeff From marc@sniff.de Wed Dec 11 14:25:30 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E08A1AE113 for ; Wed, 11 Dec 2013 14:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-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 RehsQWWXAmuL for ; Wed, 11 Dec 2013 14:25:28 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D612D1ADDD2 for ; Wed, 11 Dec 2013 14:25:27 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 90BA22AA0F; Wed, 11 Dec 2013 22:25:17 +0000 (GMT) Date: Wed, 11 Dec 2013 14:25:17 -0800 From: Marc Binderberger To: Jeffrey Haas , thomas.morin@orange.com Message-ID: <20131211142517154524.434ec0aa@sniff.de> In-Reply-To: <20131211183825.GA4843@pfrc> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 X-Mailman-Approved-At: Wed, 11 Dec 2013 15:23:02 -0800 Cc: Carlos Pignataro , "Bhatia, Manav \(Manav\)" , "rtg-dir@ietf.org" , Mach Chen , Sami Boutros , "jeff.tantsura@ericsson.com" , Nobo Akiya , "bfd-chairs@tools.ietf.org" , "Henderickx, Wim \(Wim\)" , Marc Binderberger , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:25:30 -0000 Hello Thomas and Jeff, I will remove the capitalization from the Appendix to avoid any impression this is normative. It's some practical experience we made, offered for free. Not a fit-for-all, it is influenced by some specific network operation procedures. Can live with replacing "L3 continuity" with what Thomas proposes. Mi.1 was addressed, at least from my view as an implementor. To some extend I dis-improved as the last sentence should have started with For this example [The demultiplexing procedure described in this document will prevent any BFD session to go into Up state.] But I'm also fine we avoid confusion and remove the sentence. The fact that the UDP port needs to be considered as part of the demultiplexing (for discriminator zero) is actually enough for a proper implementation. > If an > implementation was somehow able to configure BFD port numbers such that the > features were crossed... things would fail in rather peculiar ways. True but this would not follow the RFC5881 standard when the UDP port is e.g. configurable. Our text ensures the ships in the night behaviour within the RFC standards for BFD. I brought up this example as it is a true scenario (either by mistake or during reconfiguration) and a reason for introducing a new port. And it covered a "negative case" as proposed by Thomas :-) Will update the document in parallel while the emails come in ... . Regards, Marc On Wed, 11 Dec 2013 13:38:25 -0500, Jeffrey Haas wrote: > On Wed, Dec 11, 2013 at 05:01:03PM +0000, thomas.morin@orange.com wrote: >> First of all, let me point out that the appendix is using RFC2119 >> language (e.g. "SHOULD NOT"). If in fact the text there is not meant to >> be constraining, then it probably should not use such language. > > Removing the 2119 capitalization is certainly easy to do. > >> However, as a contributor working for an operator, I am particularly >> careful about documenting recommended approaches to make a deployment >> smooth. This is very useful and really deserves IMHO to appear in the >> document in a position that gives it a fair chance to be read by >> implementors. > > Speaking as an implementor, if it's in the document, I read it as part of my > work. > >> I would encourage you to consider moving the text in the main section of >> the document. Perhaps not as specification text using RFC2119 language, >> but perhaps worded in terms to make it clear that there may be other >> ways to obtain a similar effect but that implementors should take care >> about such issues. > > The difficulty here is that the primary purpose of the draft is to describe > protocol operations. The purpose of the appendix is to offer advice to > implementors of the feature for graceful integration of the feature. > However, that advice is not normative to the operation of the protocol. > > Having worked as an implementor across a number of companies over the years, > I am extremely paranoid about placing such operational advice in the context > of a specification. Doing such things tends to get interop labs/testsuites > pedantically testing the behavior and saying "you're not compliant", even if > the reason for the variance in the operational behavior is internally > justified. > > The other half of this is that if someone does some behavior that is > *better* than that covered in the document they may become non-compliant, > while the on-the-wire protocol is not impacted. > > I would rather delete the appendix than make it take on the air of something > that is a normative portion of the protocol. We were trying to be nice by > offering implementation wisdom rather than making the next implementor run > into the same issues we did in our implementations. > >>> For the L3 continuity (Mi.3), we kept the changes small, added to say >>> "i.e. the ability for each member link to be able to forward L3 >>> packets." When implementing, this aspect is largely implicit as the BFD >>> processing will use layer-3 code. Making more detailed statements or >>> requirements is difficult as it is implementation specific. >> >> Why not replace " and would be able to verify L3 Continuity per member >> link; i.e. the ability for each member link to be able to forward L3 >> packets. " by "and would be able to verify the ability for each >> member link to be able to forward L3 packets". >> >> Said otherwise, what does the term "L3 continuity" bring ? >> (I see the drawback that it may bring, given that it's unclear to me >> what "continuity" means when we look at just one IP forwarding hop: BFD >> LAG does not verify the ability of the box to forward one IP packet from >> one interface to another, right ?) > > I suspect this language was influenced by the VCCV feature and the language > that was pushed upon BFD for that purpose. > > I don't have a strong feeling about keeping "L3 continuity" and would be > fine accepting your text. > > Perhaps the other authors have some memory of why we went with that > particular terminology. > >>> For the other comments I followed your advice/suggestions. >> >> I did not find text addressing Mi.1): >> >> ( It should probably explain what is the behavior if BFD messages from a >> micro-BFD sessions are received on the normal BFD port (3784), and >> vice-versa what is the behavior for BFD messages from a non-BFD sessions >> is received on the micro-BFD UDP port. ) >> >> The added text does not seem to address the above. >> >> Additionally, I find the following new sentence "scary" (if I may say): >> >> The demultiplexing procedure described in this document will >> prevent any BFD session to go into Up state. >> >> That sounds like BFD will not work at all anymore... ;) > > I tend to agree. I didn't have better text to offer, but the implication > really is that the two instantiations of the BFD feature (BFD for IP/5881 > and BFD over LAG) are really "ships in the night" features. If an > implementation was somehow able to configure BFD port numbers such that the > features were crossed... things would fail in rather peculiar ways. > > We do not have similar documentation covering other applications of BFD > where specific bootstrapping scenarios are required (e.g. VCCV). I'm not > sure it's applicable here either. In particular, a standard BFD session > misconfigured to use BFD over LAG *might* be able to bootstrap a single > link if it wasn't using the multicast discovery and the given implementation > of IP on the line card was able to progress BFD packet processing with > semi-resolved ARP addresses. But as you see, there's a significant number > of "the following things would have to also be true". > >> It sounds like there are some words missing, e.g. something like "any >> such unwanted BFD session"...? > > Honestly, I would prefer to drop this last sentence. The prior words seem > strong enough: > The new UDP port removes the ambiguity of BFD over LAG packets from > BFD over single-hop IP. An example is configuring a LAG with micro > BFD sessions on one side but using a [RFC5881] BFD session for the > LAG (treated as a single interface) on the opposite side. > > What your comment was asking was "describe what happens if you misconfigure > the port numbers". See my comments about about the number of additional > variables that may be present in the implementation. > > -- Jeff > From thomas.morin@orange.com Thu Dec 12 00:55:30 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB41AE1F9 for ; Thu, 12 Dec 2013 00:55:30 -0800 (PST) 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 Xlfv_zfihiAb for ; Thu, 12 Dec 2013 00:55:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 303341AE0B7 for ; Thu, 12 Dec 2013 00:55:25 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 607AF3B4E85; Thu, 12 Dec 2013 09:55:19 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2AD5A4C060; Thu, 12 Dec 2013 09:55:19 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 09:55:18 +0100 From: To: Marc Binderberger , Jeffrey Haas Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO9TIuWnGCCoHNPUeHa/9P+WPrMJpPKf2AgAAbNYCAAD9igIAAsAWA Date: Thu, 12 Dec 2013 08:55:18 +0000 Message-ID: <13201_1386838519_52A979F7_13201_3636_1_52A979F5.203@orange.com> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> <20131211142517154524.434ec0aa@sniff.de> In-Reply-To: <20131211142517154524.434ec0aa@sniff.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="utf-8" Content-ID: <923A8B3CAEB8104AB549809915F3924A@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.12.81814 X-Mailman-Approved-At: Thu, 12 Dec 2013 01:23:19 -0800 Cc: Carlos Pignataro , "Bhatia, Manav \(Manav\)" , "rtg-dir@ietf.org" , Mach Chen , Sami Boutros , "jeff.tantsura@ericsson.com" , Nobo Akiya , "bfd-chairs@tools.ietf.org" , "Henderickx, Wim \(Wim\)" , Marc Binderberger , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 08:55:31 -0000 SGVsbG8gTWFyYywNCg0KMjAxMy0xMi0xMSwgTWFyYyBCaW5kZXJiZXJnZXI6DQo+DQo+IEkgd2ls bCByZW1vdmUgdGhlIGNhcGl0YWxpemF0aW9uIGZyb20gdGhlIEFwcGVuZGl4IHRvIGF2b2lkIGFu eQ0KPiBpbXByZXNzaW9uIHRoaXMgaXMgbm9ybWF0aXZlLiBJdCdzIHNvbWUgcHJhY3RpY2FsIGV4 cGVyaWVuY2Ugd2UgbWFkZSwNCj4gb2ZmZXJlZCBmb3IgZnJlZS4gTm90IGEgZml0LWZvci1hbGws IGl0IGlzIGluZmx1ZW5jZWQgYnkgc29tZSBzcGVjaWZpYw0KPiBuZXR3b3JrIG9wZXJhdGlvbiBw cm9jZWR1cmVzLg0KDQoNCkFncmVlZC4gSXQncyB0cnVlIHRoYXQgdGhpcyBwYXJ0IGRvZXMgbm90 IG5lZWQgdG8gYmUgbm9ybWF0aXZlLg0KDQpIb3dldmVyLCBvbyBnaXZlIHByb3BlciB2aXNpYmls aXR5IHRvIHRoaXMgc2VjdGlvbiwgSSB3b3VsZCBzdWdnZXN0IA0KbWVudGlvbmluZyBpdHMgZXhp c3RlbmNlIGluIHRoZSBpbnRyb2R1Y3Rpb24sIHdpdGggZm9yIGluc3RhbmNlIHRoZSANCmZvbGxv d2luZyB0ZXh0Og0KDQogICAgQXBwZW5kaXggQSBwcm92aWRlcyBhIGRlc2NyaXB0aW9uIG9mIGhv dyB0byBpbXBsZW1lbnQgdGhlc2Ugc3BlY3MgaW4NCiAgICBhIHdheSB0aGF0IGNhbiBoZWxwIGlu dHJvZHVjZSBCRkQgTEFHIGluIGEgcnVubmluZyBuZXR3b3JrIGFuZCwgaW4NCiAgICBwYXJ0aWN1 bGFyLCBlbnN1cmUgdGhhdCB0aGUgc2VxdWVuY2Ugb2YgZXZlbnRzIC0gZW5hYmxpbmcvZGlzYWJs aW5nDQogICAgdGhlIExBRyBhbmQgZW5hYmxpbmcvZGlzYWJsaW5nIEJGRCBvbiB0aGUgTEFHIC0g aGFzIG5vIGltcGFjdCBvbiB0aGUNCiAgICBmb3J3YXJkaW5nIHNlcnZpY2UuIEFsdGhvdWdoIHRo aXMgdGV4dCBpcyBub24gbm9ybWF0aXZlLCBpdCBpcw0KICAgIHJlY29tbWVuZGVkIHRoYXQgYW4g aW1wbGVtZW50YXRpb24gYWRkcmVzc2VzIHRoaXMgdHlwZSBvZiBpc3N1ZXMuDQoNCg0KPiBDYW4g bGl2ZSB3aXRoIHJlcGxhY2luZyAiTDMgY29udGludWl0eSIgd2l0aCB3aGF0IFRob21hcyBwcm9w b3Nlcy4NCg0KT2suDQoNCg0KPiBNaS4xIHdhcyBhZGRyZXNzZWQsIGF0IGxlYXN0IGZyb20gbXkg dmlldyBhcyBhbiBpbXBsZW1lbnRvci4gVG8gc29tZQ0KPiBleHRlbmQgSSBkaXMtaW1wcm92ZWQg YXMgdGhlIGxhc3Qgc2VudGVuY2Ugc2hvdWxkIGhhdmUgc3RhcnRlZCB3aXRoDQo+DQo+ICAgICBG b3IgdGhpcyBleGFtcGxlIFtUaGUNCj4gICAgIGRlbXVsdGlwbGV4aW5nIHByb2NlZHVyZSBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCB3aWxsIHByZXZlbnQgYW55DQo+ICAgICBCRkQgc2Vzc2lv biB0byBnbyBpbnRvIFVwIHN0YXRlLl0NCg0KVGhpcyBuZXcgdGV4dCBpcyBnb29kLg0KDQooTW9y ZSBpbiBhIHJlcGx5IHRvIEplZmYncyBlbWFpbC4pDQoNClRoYW5rcywNCg0KLVRob21hcw0KDQoN Cg0KPiBPbiBXZWQsIDExIERlYyAyMDEzIDEzOjM4OjI1IC0wNTAwLCBKZWZmcmV5IEhhYXMgd3Jv dGU6DQo+PiBPbiBXZWQsIERlYyAxMSwgMjAxMyBhdCAwNTowMTowM1BNICswMDAwLCB0aG9tYXMu bW9yaW5Ab3JhbmdlLmNvbSB3cm90ZToNCj4+PiBGaXJzdCBvZiBhbGwsIGxldCBtZSBwb2ludCBv dXQgdGhhdCB0aGUgYXBwZW5kaXggaXMgdXNpbmcgUkZDMjExOQ0KPj4+IGxhbmd1YWdlIChlLmcu ICJTSE9VTEQgTk9UIikuIElmIGluIGZhY3QgdGhlIHRleHQgdGhlcmUgaXMgbm90IG1lYW50IHRv DQo+Pj4gYmUgY29uc3RyYWluaW5nLCB0aGVuIGl0IHByb2JhYmx5IHNob3VsZCBub3QgdXNlIHN1 Y2ggbGFuZ3VhZ2UuDQo+Pg0KPj4gUmVtb3ZpbmcgdGhlIDIxMTkgY2FwaXRhbGl6YXRpb24gaXMg Y2VydGFpbmx5IGVhc3kgdG8gZG8uDQo+Pg0KPj4+IEhvd2V2ZXIsIGFzIGEgY29udHJpYnV0b3Ig d29ya2luZyBmb3IgYW4gb3BlcmF0b3IsIEkgYW0gcGFydGljdWxhcmx5DQo+Pj4gY2FyZWZ1bCBh Ym91dCBkb2N1bWVudGluZyByZWNvbW1lbmRlZCBhcHByb2FjaGVzIHRvIG1ha2UgYSBkZXBsb3lt ZW50DQo+Pj4gc21vb3RoLiBUaGlzIGlzIHZlcnkgdXNlZnVsIGFuZCByZWFsbHkgZGVzZXJ2ZXMg SU1ITyB0byBhcHBlYXIgaW4gdGhlDQo+Pj4gZG9jdW1lbnQgaW4gYSBwb3NpdGlvbiB0aGF0IGdp dmVzIGl0IGEgZmFpciBjaGFuY2UgdG8gYmUgcmVhZCBieQ0KPj4+IGltcGxlbWVudG9ycy4NCj4+ DQo+PiBTcGVha2luZyBhcyBhbiBpbXBsZW1lbnRvciwgaWYgaXQncyBpbiB0aGUgZG9jdW1lbnQs IEkgcmVhZCBpdCBhcyBwYXJ0IG9mIG15DQo+PiB3b3JrLg0KPj4NCj4+PiBJIHdvdWxkIGVuY291 cmFnZSB5b3UgdG8gY29uc2lkZXIgbW92aW5nIHRoZSB0ZXh0IGluIHRoZSBtYWluIHNlY3Rpb24g b2YNCj4+PiB0aGUgZG9jdW1lbnQuIFBlcmhhcHMgbm90IGFzIHNwZWNpZmljYXRpb24gdGV4dCB1 c2luZyBSRkMyMTE5IGxhbmd1YWdlLA0KPj4+IGJ1dCBwZXJoYXBzIHdvcmRlZCBpbiB0ZXJtcyB0 byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgbWF5IGJlIG90aGVyDQo+Pj4gd2F5cyB0byBvYnRh aW4gYSBzaW1pbGFyIGVmZmVjdCBidXQgdGhhdCBpbXBsZW1lbnRvcnMgc2hvdWxkIHRha2UgY2Fy ZQ0KPj4+IGFib3V0IHN1Y2ggaXNzdWVzLg0KPj4NCj4+IFRoZSBkaWZmaWN1bHR5IGhlcmUgaXMg dGhhdCB0aGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoZSBkcmFmdCBpcyB0byBkZXNjcmliZQ0KPj4g cHJvdG9jb2wgb3BlcmF0aW9ucy4gIFRoZSBwdXJwb3NlIG9mIHRoZSBhcHBlbmRpeCBpcyB0byBv ZmZlciBhZHZpY2UgdG8NCj4+IGltcGxlbWVudG9ycyBvZiB0aGUgZmVhdHVyZSBmb3IgZ3JhY2Vm dWwgaW50ZWdyYXRpb24gb2YgdGhlIGZlYXR1cmUuDQo+PiBIb3dldmVyLCB0aGF0IGFkdmljZSBp cyBub3Qgbm9ybWF0aXZlIHRvIHRoZSBvcGVyYXRpb24gb2YgdGhlIHByb3RvY29sLg0KPj4NCj4+ IEhhdmluZyB3b3JrZWQgYXMgYW4gaW1wbGVtZW50b3IgYWNyb3NzIGEgbnVtYmVyIG9mIGNvbXBh bmllcyBvdmVyIHRoZSB5ZWFycywNCj4+IEkgYW0gZXh0cmVtZWx5IHBhcmFub2lkIGFib3V0IHBs YWNpbmcgc3VjaCBvcGVyYXRpb25hbCBhZHZpY2UgaW4gdGhlIGNvbnRleHQNCj4+IG9mIGEgc3Bl Y2lmaWNhdGlvbi4gIERvaW5nIHN1Y2ggdGhpbmdzIHRlbmRzIHRvIGdldCBpbnRlcm9wIGxhYnMv dGVzdHN1aXRlcw0KPj4gcGVkYW50aWNhbGx5IHRlc3RpbmcgdGhlIGJlaGF2aW9yIGFuZCBzYXlp bmcgInlvdSdyZSBub3QgY29tcGxpYW50IiwgZXZlbiBpZg0KPj4gdGhlIHJlYXNvbiBmb3IgdGhl IHZhcmlhbmNlIGluIHRoZSBvcGVyYXRpb25hbCBiZWhhdmlvciBpcyBpbnRlcm5hbGx5DQo+PiBq dXN0aWZpZWQuDQo+Pg0KPj4gVGhlIG90aGVyIGhhbGYgb2YgdGhpcyBpcyB0aGF0IGlmIHNvbWVv bmUgZG9lcyBzb21lIGJlaGF2aW9yIHRoYXQgaXMNCj4+ICpiZXR0ZXIqIHRoYW4gdGhhdCBjb3Zl cmVkIGluIHRoZSBkb2N1bWVudCB0aGV5IG1heSBiZWNvbWUgbm9uLWNvbXBsaWFudCwNCj4+IHdo aWxlIHRoZSBvbi10aGUtd2lyZSBwcm90b2NvbCBpcyBub3QgaW1wYWN0ZWQuDQo+Pg0KPj4gSSB3 b3VsZCByYXRoZXIgZGVsZXRlIHRoZSBhcHBlbmRpeCB0aGFuIG1ha2UgaXQgdGFrZSBvbiB0aGUg YWlyIG9mIHNvbWV0aGluZw0KPj4gdGhhdCBpcyBhIG5vcm1hdGl2ZSBwb3J0aW9uIG9mIHRoZSBw cm90b2NvbC4gIFdlIHdlcmUgdHJ5aW5nIHRvIGJlIG5pY2UgYnkNCj4+IG9mZmVyaW5nIGltcGxl bWVudGF0aW9uIHdpc2RvbSByYXRoZXIgdGhhbiBtYWtpbmcgdGhlIG5leHQgaW1wbGVtZW50b3Ig cnVuDQo+PiBpbnRvIHRoZSBzYW1lIGlzc3VlcyB3ZSBkaWQgaW4gb3VyIGltcGxlbWVudGF0aW9u cy4NCj4+DQo+Pj4+IEZvciB0aGUgTDMgY29udGludWl0eSAoTWkuMyksIHdlIGtlcHQgdGhlIGNo YW5nZXMgc21hbGwsIGFkZGVkIHRvIHNheQ0KPj4+PiAiaS5lLiB0aGUgYWJpbGl0eSBmb3IgZWFj aCBtZW1iZXIgbGluayB0byBiZSBhYmxlIHRvIGZvcndhcmQgTDMNCj4+Pj4gcGFja2V0cy4iIFdo ZW4gaW1wbGVtZW50aW5nLCB0aGlzIGFzcGVjdCBpcyBsYXJnZWx5IGltcGxpY2l0IGFzIHRoZSBC RkQNCj4+Pj4gcHJvY2Vzc2luZyB3aWxsIHVzZSBsYXllci0zIGNvZGUuIE1ha2luZyBtb3JlIGRl dGFpbGVkIHN0YXRlbWVudHMgb3INCj4+Pj4gcmVxdWlyZW1lbnRzIGlzIGRpZmZpY3VsdCBhcyBp dCBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCj4+Pg0KPj4+IFdoeSBub3QgcmVwbGFjZSAi IGFuZCB3b3VsZCBiZSBhYmxlIHRvICB2ZXJpZnkgTDMgQ29udGludWl0eSBwZXIgbWVtYmVyDQo+ Pj4gbGluazsgaS5lLiB0aGUgYWJpbGl0eSBmb3IgZWFjaCAgbWVtYmVyIGxpbmsgdG8gYmUgYWJs ZSB0byBmb3J3YXJkIEwzDQo+Pj4gcGFja2V0cy4gIiBieSAiYW5kIHdvdWxkIGJlIGFibGUgdG8g dmVyaWZ5IHRoZSBhYmlsaXR5IGZvciBlYWNoDQo+Pj4gICAgbWVtYmVyIGxpbmsgdG8gYmUgYWJs ZSB0byBmb3J3YXJkIEwzIHBhY2tldHMiLg0KPj4+DQo+Pj4gU2FpZCBvdGhlcndpc2UsIHdoYXQg ZG9lcyB0aGUgdGVybSAiTDMgY29udGludWl0eSIgYnJpbmcgPw0KPj4+IChJIHNlZSB0aGUgZHJh d2JhY2sgdGhhdCBpdCBtYXkgYnJpbmcsIGdpdmVuIHRoYXQgaXQncyB1bmNsZWFyIHRvIG1lDQo+ Pj4gd2hhdCAiY29udGludWl0eSIgbWVhbnMgd2hlbiB3ZSBsb29rIGF0IGp1c3Qgb25lIElQIGZv cndhcmRpbmcgaG9wOiBCRkQNCj4+PiBMQUcgZG9lcyBub3QgdmVyaWZ5IHRoZSBhYmlsaXR5IG9m IHRoZSBib3ggdG8gZm9yd2FyZCBvbmUgSVAgcGFja2V0IGZyb20NCj4+PiBvbmUgaW50ZXJmYWNl IHRvIGFub3RoZXIsIHJpZ2h0ID8pDQo+Pg0KPj4gSSBzdXNwZWN0IHRoaXMgbGFuZ3VhZ2Ugd2Fz IGluZmx1ZW5jZWQgYnkgdGhlIFZDQ1YgZmVhdHVyZSBhbmQgdGhlIGxhbmd1YWdlDQo+PiB0aGF0 IHdhcyBwdXNoZWQgdXBvbiBCRkQgZm9yIHRoYXQgcHVycG9zZS4NCj4+DQo+PiBJIGRvbid0IGhh dmUgYSBzdHJvbmcgZmVlbGluZyBhYm91dCBrZWVwaW5nICJMMyBjb250aW51aXR5IiBhbmQgd291 bGQgYmUNCj4+IGZpbmUgYWNjZXB0aW5nIHlvdXIgdGV4dC4NCj4+DQo+PiBQZXJoYXBzIHRoZSBv dGhlciBhdXRob3JzIGhhdmUgc29tZSBtZW1vcnkgb2Ygd2h5IHdlIHdlbnQgd2l0aCB0aGF0DQo+ PiBwYXJ0aWN1bGFyIHRlcm1pbm9sb2d5Lg0KPj4NCj4+Pj4gRm9yIHRoZSBvdGhlciBjb21tZW50 cyBJIGZvbGxvd2VkIHlvdXIgYWR2aWNlL3N1Z2dlc3Rpb25zLg0KPj4+DQo+Pj4gSSBkaWQgbm90 IGZpbmQgdGV4dCBhZGRyZXNzaW5nIE1pLjEpOg0KPj4+DQo+Pj4gKCBJdCBzaG91bGQgcHJvYmFi bHkgZXhwbGFpbiB3aGF0IGlzIHRoZSBiZWhhdmlvciBpZiBCRkQgbWVzc2FnZXMgZnJvbSBhDQo+ Pj4gbWljcm8tQkZEIHNlc3Npb25zIGFyZSByZWNlaXZlZCBvbiB0aGUgbm9ybWFsIEJGRCBwb3J0 ICgzNzg0KSwgYW5kDQo+Pj4gdmljZS12ZXJzYSB3aGF0IGlzIHRoZSBiZWhhdmlvciBmb3IgQkZE IG1lc3NhZ2VzIGZyb20gYSBub24tQkZEIHNlc3Npb25zDQo+Pj4gaXMgcmVjZWl2ZWQgb24gdGhl IG1pY3JvLUJGRCBVRFAgcG9ydC4gKQ0KPj4+DQo+Pj4gVGhlIGFkZGVkIHRleHQgZG9lcyBub3Qg c2VlbSB0byBhZGRyZXNzIHRoZSBhYm92ZS4NCj4+Pg0KPj4+IEFkZGl0aW9uYWxseSwgSSBmaW5k IHRoZSBmb2xsb3dpbmcgbmV3IHNlbnRlbmNlICJzY2FyeSIgKGlmIEkgbWF5IHNheSk6DQo+Pj4N Cj4+PiAgICAgICBUaGUJZGVtdWx0aXBsZXhpbmcgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiB0aGlz IGRvY3VtZW50IHdpbGwNCj4+PiAgICAgICBwcmV2ZW50IGFueQlCRkQgc2Vzc2lvbiB0byBnbyBp bnRvIFVwIHN0YXRlLg0KPj4+DQo+Pj4gVGhhdCBzb3VuZHMgbGlrZSBCRkQgd2lsbCBub3Qgd29y ayBhdCBhbGwgYW55bW9yZS4uLiA7KQ0KPj4NCj4+IEkgdGVuZCB0byBhZ3JlZS4gIEkgZGlkbid0 IGhhdmUgYmV0dGVyIHRleHQgdG8gb2ZmZXIsIGJ1dCB0aGUgaW1wbGljYXRpb24NCj4+IHJlYWxs eSBpcyB0aGF0IHRoZSB0d28gaW5zdGFudGlhdGlvbnMgb2YgdGhlIEJGRCBmZWF0dXJlIChCRkQg Zm9yIElQLzU4ODENCj4+IGFuZCBCRkQgb3ZlciBMQUcpIGFyZSByZWFsbHkgInNoaXBzIGluIHRo ZSBuaWdodCIgZmVhdHVyZXMuICBJZiBhbg0KPj4gaW1wbGVtZW50YXRpb24gd2FzIHNvbWVob3cg YWJsZSB0byBjb25maWd1cmUgQkZEIHBvcnQgbnVtYmVycyBzdWNoIHRoYXQgdGhlDQo+PiBmZWF0 dXJlcyB3ZXJlIGNyb3NzZWQuLi4gdGhpbmdzIHdvdWxkIGZhaWwgaW4gcmF0aGVyIHBlY3VsaWFy IHdheXMuDQo+Pg0KPj4gV2UgZG8gbm90IGhhdmUgc2ltaWxhciBkb2N1bWVudGF0aW9uIGNvdmVy aW5nIG90aGVyIGFwcGxpY2F0aW9ucyBvZiBCRkQNCj4+IHdoZXJlIHNwZWNpZmljIGJvb3RzdHJh cHBpbmcgc2NlbmFyaW9zIGFyZSByZXF1aXJlZCAoZS5nLiBWQ0NWKS4gIEknbSBub3QNCj4+IHN1 cmUgaXQncyBhcHBsaWNhYmxlIGhlcmUgZWl0aGVyLiAgSW4gcGFydGljdWxhciwgYSBzdGFuZGFy ZCBCRkQgc2Vzc2lvbg0KPj4gbWlzY29uZmlndXJlZCB0byB1c2UgQkZEIG92ZXIgTEFHICptaWdo dCogYmUgYWJsZSB0byBib290c3RyYXAgYSBzaW5nbGUNCj4+IGxpbmsgaWYgaXQgd2Fzbid0IHVz aW5nIHRoZSBtdWx0aWNhc3QgZGlzY292ZXJ5IGFuZCB0aGUgZ2l2ZW4gaW1wbGVtZW50YXRpb24N Cj4+IG9mIElQIG9uIHRoZSBsaW5lIGNhcmQgd2FzIGFibGUgdG8gcHJvZ3Jlc3MgQkZEIHBhY2tl dCBwcm9jZXNzaW5nIHdpdGgNCj4+IHNlbWktcmVzb2x2ZWQgQVJQIGFkZHJlc3Nlcy4gIEJ1dCBh cyB5b3Ugc2VlLCB0aGVyZSdzIGEgc2lnbmlmaWNhbnQgbnVtYmVyDQo+PiBvZiAidGhlIGZvbGxv d2luZyB0aGluZ3Mgd291bGQgaGF2ZSB0byBhbHNvIGJlIHRydWUiLg0KPj4NCj4+PiBJdCBzb3Vu ZHMgbGlrZSB0aGVyZSBhcmUgc29tZSB3b3JkcyBtaXNzaW5nLCBlLmcuIHNvbWV0aGluZyBsaWtl ICJhbnkNCj4+PiBzdWNoIHVud2FudGVkIEJGRCBzZXNzaW9uIi4uLj8NCj4+DQo+PiBIb25lc3Rs eSwgSSB3b3VsZCBwcmVmZXIgdG8gZHJvcCB0aGlzIGxhc3Qgc2VudGVuY2UuICBUaGUgcHJpb3Ig d29yZHMgc2VlbQ0KPj4gc3Ryb25nIGVub3VnaDoNCj4+ICAgICBUaGUgbmV3IFVEUCBwb3J0IHJl bW92ZXMgdGhlIGFtYmlndWl0eSBvZiBCRkQgb3ZlciBMQUcgcGFja2V0cyBmcm9tDQo+PiAgICAg QkZEIG92ZXIgc2luZ2xlLWhvcCBJUC4gIEFuIGV4YW1wbGUgaXMgY29uZmlndXJpbmcgYSBMQUcg d2l0aCBtaWNybw0KPj4gICAgIEJGRCBzZXNzaW9ucyBvbiBvbmUgc2lkZSBidXQgdXNpbmcgYSBb UkZDNTg4MV0gQkZEIHNlc3Npb24gZm9yIHRoZQ0KPj4gICAgIExBRyAodHJlYXRlZCBhcyBhIHNp bmdsZSBpbnRlcmZhY2UpIG9uIHRoZSBvcHBvc2l0ZSBzaWRlLg0KPj4NCj4+IFdoYXQgeW91ciBj b21tZW50IHdhcyBhc2tpbmcgd2FzICJkZXNjcmliZSB3aGF0IGhhcHBlbnMgaWYgeW91IG1pc2Nv bmZpZ3VyZQ0KPj4gdGhlIHBvcnQgbnVtYmVycyIuICBTZWUgbXkgY29tbWVudHMgYWJvdXQgYWJv dXQgdGhlIG51bWJlciBvZiBhZGRpdGlvbmFsDQo+PiB2YXJpYWJsZXMgdGhhdCBtYXkgYmUgcHJl c2VudCBpbiB0aGUgaW1wbGVtZW50YXRpb24uDQo+Pg0KPj4gLS0gSmVmZg0KPj4NCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu ClRoYW5rIHlvdS4KCg== From thomas.morin@orange.com Thu Dec 12 01:07:19 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3101AE201 for ; Thu, 12 Dec 2013 01:07:18 -0800 (PST) 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 r2wMb8Vzk5c1 for ; Thu, 12 Dec 2013 01:07:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id C07E71ADF63 for ; Thu, 12 Dec 2013 01:07:15 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 1AF251B82C3; Thu, 12 Dec 2013 10:07:09 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id DFCC4C805F; Thu, 12 Dec 2013 10:07:08 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 10:07:08 +0100 From: To: Jeffrey Haas Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO9TIuWnGCCoHNPUeHa/9P+WPrMJpPKf2AgAAbNYCAAPK2gA== Date: Thu, 12 Dec 2013 09:07:08 +0000 Message-ID: <7118_1386839229_52A97CBC_7118_7473_1_52A97CBB.5090207@orange.com> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> In-Reply-To: <20131211183825.GA4843@pfrc> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-ID: <56C9F0374660B24B99110FE6D8B9D3AD@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.12.52114 X-Mailman-Approved-At: Thu, 12 Dec 2013 01:23:20 -0800 Cc: Carlos Pignataro , "Bhatia, Manav \(Manav\)" , "rtg-dir@ietf.org" , Marc Binderberger , Mach Chen , Sami Boutros , "jeff.tantsura@ericsson.com" , Nobo Akiya , "bfd-chairs@tools.ietf.org" , "Henderickx, Wim \(Wim\)" , Marc Binderberger , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 09:07:19 -0000 SGkgSmVmZiwNCg0KMjAxMy0xMi0xMSwgSmVmZnJleSBIYWFzOg0KPj4gSG93ZXZlciwgYXMgYSBj b250cmlidXRvciB3b3JraW5nIGZvciBhbiBvcGVyYXRvciwgSSBhbSBwYXJ0aWN1bGFybHkNCj4+ IGNhcmVmdWwgYWJvdXQgZG9jdW1lbnRpbmcgcmVjb21tZW5kZWQgYXBwcm9hY2hlcyB0byBtYWtl IGEgZGVwbG95bWVudA0KPj4gc21vb3RoLiBUaGlzIGlzIHZlcnkgdXNlZnVsIGFuZCByZWFsbHkg ZGVzZXJ2ZXMgSU1ITyB0byBhcHBlYXIgaW4gdGhlDQo+PiBkb2N1bWVudCBpbiBhIHBvc2l0aW9u IHRoYXQgZ2l2ZXMgaXQgYSBmYWlyIGNoYW5jZSB0byBiZSByZWFkIGJ5DQo+PiBpbXBsZW1lbnRv cnMuDQo+DQo+IFNwZWFraW5nIGFzIGFuIGltcGxlbWVudG9yLCBpZiBpdCdzIGluIHRoZSBkb2N1 bWVudCwgSSByZWFkIGl0IGFzIHBhcnQgb2YgbXkNCj4gd29yay4NCg0KWW91ciBhcmUgY2VydGFp bmx5IGFuIGV4YW1wbGUgdGhhdCBpbXBsZW1lbnRvciBzaG91bGQgZm9sbG93Lg0KU3BlYWtpbmcg YXMgYW4gb3BlcmF0b3IsIEkgZmluZCB2ZXJ5IG9mdGVuIHRoYXQgdGV4dCBnZXRzIGlnbm9yZWQg ZXZlbiANCmlmIGluIHRoZSBtYWluIG5vcm1hdGl2ZSBwYXJ0IG9mIHRoZSBkb2N1bWVudC4gIEFu ZCBJIGNhbiBlYXNpbHkgZ3Vlc3MgDQp0aGF0IG1hbnkgcGVvcGxlIGp1c3QgZG9uJ3QgcmVhZCBi ZXlvbmQgdGhlIEFja25vd2xlZGdlbWVudHMgc2VjdGlvbi4NCg0KDQo+PiBJIHdvdWxkIGVuY291 cmFnZSB5b3UgdG8gY29uc2lkZXIgbW92aW5nIHRoZSB0ZXh0IGluIHRoZSBtYWluIHNlY3Rpb24g b2YNCj4+IHRoZSBkb2N1bWVudC4gUGVyaGFwcyBub3QgYXMgc3BlY2lmaWNhdGlvbiB0ZXh0IHVz aW5nIFJGQzIxMTkgbGFuZ3VhZ2UsDQo+PiBidXQgcGVyaGFwcyB3b3JkZWQgaW4gdGVybXMgdG8g bWFrZSBpdCBjbGVhciB0aGF0IHRoZXJlIG1heSBiZSBvdGhlcg0KPj4gd2F5cyB0byBvYnRhaW4g YSBzaW1pbGFyIGVmZmVjdCBidXQgdGhhdCBpbXBsZW1lbnRvcnMgc2hvdWxkIHRha2UgY2FyZQ0K Pj4gYWJvdXQgc3VjaCBpc3N1ZXMuDQo+DQo+IFRoZSBkaWZmaWN1bHR5IGhlcmUgaXMgdGhhdCB0 aGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoZSBkcmFmdCBpcyB0byBkZXNjcmliZQ0KPiBwcm90b2Nv bCBvcGVyYXRpb25zLiAgVGhlIHB1cnBvc2Ugb2YgdGhlIGFwcGVuZGl4IGlzIHRvIG9mZmVyIGFk dmljZSB0bw0KPiBpbXBsZW1lbnRvcnMgb2YgdGhlIGZlYXR1cmUgZm9yIGdyYWNlZnVsIGludGVn cmF0aW9uIG9mIHRoZSBmZWF0dXJlLg0KPiBIb3dldmVyLCB0aGF0IGFkdmljZSBpcyBub3Qgbm9y bWF0aXZlIHRvIHRoZSBvcGVyYXRpb24gb2YgdGhlIHByb3RvY29sLg0KPg0KPiBIYXZpbmcgd29y a2VkIGFzIGFuIGltcGxlbWVudG9yIGFjcm9zcyBhIG51bWJlciBvZiBjb21wYW5pZXMgb3ZlciB0 aGUgeWVhcnMsDQo+IEkgYW0gZXh0cmVtZWx5IHBhcmFub2lkIGFib3V0IHBsYWNpbmcgc3VjaCBv cGVyYXRpb25hbCBhZHZpY2UgaW4gdGhlIGNvbnRleHQNCj4gb2YgYSBzcGVjaWZpY2F0aW9uLiAg RG9pbmcgc3VjaCB0aGluZ3MgdGVuZHMgdG8gZ2V0IGludGVyb3AgbGFicy90ZXN0c3VpdGVzDQo+ IHBlZGFudGljYWxseSB0ZXN0aW5nIHRoZSBiZWhhdmlvciBhbmQgc2F5aW5nICJ5b3UncmUgbm90 IGNvbXBsaWFudCIsIGV2ZW4gaWYNCj4gdGhlIHJlYXNvbiBmb3IgdGhlIHZhcmlhbmNlIGluIHRo ZSBvcGVyYXRpb25hbCBiZWhhdmlvciBpcyBpbnRlcm5hbGx5DQo+IGp1c3RpZmllZC4NCj4NCj4g VGhlIG90aGVyIGhhbGYgb2YgdGhpcyBpcyB0aGF0IGlmIHNvbWVvbmUgZG9lcyBzb21lIGJlaGF2 aW9yIHRoYXQgaXMNCj4gKmJldHRlciogdGhhbiB0aGF0IGNvdmVyZWQgaW4gdGhlIGRvY3VtZW50 IHRoZXkgbWF5IGJlY29tZSBub24tY29tcGxpYW50LA0KPiB3aGlsZSB0aGUgb24tdGhlLXdpcmUg cHJvdG9jb2wgaXMgbm90IGltcGFjdGVkLg0KPg0KPiBJIHdvdWxkIHJhdGhlciBkZWxldGUgdGhl IGFwcGVuZGl4IHRoYW4gbWFrZSBpdCB0YWtlIG9uIHRoZSBhaXIgb2Ygc29tZXRoaW5nDQo+IHRo YXQgaXMgYSBub3JtYXRpdmUgcG9ydGlvbiBvZiB0aGUgcHJvdG9jb2wuICBXZSB3ZXJlIHRyeWlu ZyB0byBiZSBuaWNlIGJ5DQo+IG9mZmVyaW5nIGltcGxlbWVudGF0aW9uIHdpc2RvbSByYXRoZXIg dGhhbiBtYWtpbmcgdGhlIG5leHQgaW1wbGVtZW50b3IgcnVuDQo+IGludG8gdGhlIHNhbWUgaXNz dWVzIHdlIGRpZCBpbiBvdXIgaW1wbGVtZW50YXRpb25zLg0KDQpVbmRlcnN0b29kLCBhbmQgYWdy ZWVkLg0KDQo+Pj4gRm9yIHRoZSBMMyBjb250aW51aXR5IChNaS4zKSwgd2Uga2VwdCB0aGUgY2hh bmdlcyBzbWFsbCwgYWRkZWQgdG8gc2F5DQo+Pj4gImkuZS4gdGhlIGFiaWxpdHkgZm9yIGVhY2gg bWVtYmVyIGxpbmsgdG8gYmUgYWJsZSB0byBmb3J3YXJkIEwzDQo+Pj4gcGFja2V0cy4iIFdoZW4g aW1wbGVtZW50aW5nLCB0aGlzIGFzcGVjdCBpcyBsYXJnZWx5IGltcGxpY2l0IGFzIHRoZSBCRkQN Cj4+PiBwcm9jZXNzaW5nIHdpbGwgdXNlIGxheWVyLTMgY29kZS4gTWFraW5nIG1vcmUgZGV0YWls ZWQgc3RhdGVtZW50cyBvcg0KPj4+IHJlcXVpcmVtZW50cyBpcyBkaWZmaWN1bHQgYXMgaXQgaXMg aW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQo+Pg0KPj4gV2h5IG5vdCByZXBsYWNlICIgYW5kIHdv dWxkIGJlIGFibGUgdG8gIHZlcmlmeSBMMyBDb250aW51aXR5IHBlciBtZW1iZXINCj4+IGxpbms7 IGkuZS4gdGhlIGFiaWxpdHkgZm9yIGVhY2ggIG1lbWJlciBsaW5rIHRvIGJlIGFibGUgdG8gZm9y d2FyZCBMMw0KPj4gcGFja2V0cy4gIiBieSAiYW5kIHdvdWxkIGJlIGFibGUgdG8gdmVyaWZ5IHRo ZSBhYmlsaXR5IGZvciBlYWNoDQo+PiAgICBtZW1iZXIgbGluayB0byBiZSBhYmxlIHRvIGZvcndh cmQgTDMgcGFja2V0cyIuDQo+Pg0KPj4gU2FpZCBvdGhlcndpc2UsIHdoYXQgZG9lcyB0aGUgdGVy bSAiTDMgY29udGludWl0eSIgYnJpbmcgPw0KPj4gKEkgc2VlIHRoZSBkcmF3YmFjayB0aGF0IGl0 IG1heSBicmluZywgZ2l2ZW4gdGhhdCBpdCdzIHVuY2xlYXIgdG8gbWUNCj4+IHdoYXQgImNvbnRp bnVpdHkiIG1lYW5zIHdoZW4gd2UgbG9vayBhdCBqdXN0IG9uZSBJUCBmb3J3YXJkaW5nIGhvcDog QkZEDQo+PiBMQUcgZG9lcyBub3QgdmVyaWZ5IHRoZSBhYmlsaXR5IG9mIHRoZSBib3ggdG8gZm9y d2FyZCBvbmUgSVAgcGFja2V0IGZyb20NCj4+IG9uZSBpbnRlcmZhY2UgdG8gYW5vdGhlciwgcmln aHQgPykNCj4NCj4gSSBzdXNwZWN0IHRoaXMgbGFuZ3VhZ2Ugd2FzIGluZmx1ZW5jZWQgYnkgdGhl IFZDQ1YgZmVhdHVyZSBhbmQgdGhlIGxhbmd1YWdlDQo+IHRoYXQgd2FzIHB1c2hlZCB1cG9uIEJG RCBmb3IgdGhhdCBwdXJwb3NlLg0KPg0KPiBJIGRvbid0IGhhdmUgYSBzdHJvbmcgZmVlbGluZyBh Ym91dCBrZWVwaW5nICJMMyBjb250aW51aXR5IiBhbmQgd291bGQgYmUNCj4gZmluZSBhY2NlcHRp bmcgeW91ciB0ZXh0Lg0KPg0KPiBQZXJoYXBzIHRoZSBvdGhlciBhdXRob3JzIGhhdmUgc29tZSBt ZW1vcnkgb2Ygd2h5IHdlIHdlbnQgd2l0aCB0aGF0DQo+IHBhcnRpY3VsYXIgdGVybWlub2xvZ3ku DQo+DQo+Pj4gRm9yIHRoZSBvdGhlciBjb21tZW50cyBJIGZvbGxvd2VkIHlvdXIgYWR2aWNlL3N1 Z2dlc3Rpb25zLg0KPj4NCj4+IEkgZGlkIG5vdCBmaW5kIHRleHQgYWRkcmVzc2luZyBNaS4xKToN Cj4+DQo+PiAoIEl0IHNob3VsZCBwcm9iYWJseSBleHBsYWluIHdoYXQgaXMgdGhlIGJlaGF2aW9y IGlmIEJGRCBtZXNzYWdlcyBmcm9tIGENCj4+IG1pY3JvLUJGRCBzZXNzaW9ucyBhcmUgcmVjZWl2 ZWQgb24gdGhlIG5vcm1hbCBCRkQgcG9ydCAoMzc4NCksIGFuZA0KPj4gdmljZS12ZXJzYSB3aGF0 IGlzIHRoZSBiZWhhdmlvciBmb3IgQkZEIG1lc3NhZ2VzIGZyb20gYSBub24tQkZEIHNlc3Npb25z DQo+PiBpcyByZWNlaXZlZCBvbiB0aGUgbWljcm8tQkZEIFVEUCBwb3J0LiApDQo+Pg0KPj4gVGhl IGFkZGVkIHRleHQgZG9lcyBub3Qgc2VlbSB0byBhZGRyZXNzIHRoZSBhYm92ZS4NCj4+DQo+PiBB ZGRpdGlvbmFsbHksIEkgZmluZCB0aGUgZm9sbG93aW5nIG5ldyBzZW50ZW5jZSAic2NhcnkiIChp ZiBJIG1heSBzYXkpOg0KPj4NCj4+ICAgICAgIFRoZQlkZW11bHRpcGxleGluZyBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgd2lsbA0KPj4gICAgICAgcHJldmVudCBhbnkJQkZE IHNlc3Npb24gdG8gZ28gaW50byBVcCBzdGF0ZS4NCj4+DQo+PiBUaGF0IHNvdW5kcyBsaWtlIEJG RCB3aWxsIG5vdCB3b3JrIGF0IGFsbCBhbnltb3JlLi4uIDspDQo+DQo+IEkgdGVuZCB0byBhZ3Jl ZS4gIEkgZGlkbid0IGhhdmUgYmV0dGVyIHRleHQgdG8gb2ZmZXIsIGJ1dCB0aGUgaW1wbGljYXRp b24NCj4gcmVhbGx5IGlzIHRoYXQgdGhlIHR3byBpbnN0YW50aWF0aW9ucyBvZiB0aGUgQkZEIGZl YXR1cmUgKEJGRCBmb3IgSVAvNTg4MQ0KPiBhbmQgQkZEIG92ZXIgTEFHKSBhcmUgcmVhbGx5ICJz aGlwcyBpbiB0aGUgbmlnaHQiIGZlYXR1cmVzLiAgSWYgYW4NCj4gaW1wbGVtZW50YXRpb24gd2Fz IHNvbWVob3cgYWJsZSB0byBjb25maWd1cmUgQkZEIHBvcnQgbnVtYmVycyBzdWNoIHRoYXQgdGhl DQo+IGZlYXR1cmVzIHdlcmUgY3Jvc3NlZC4uLiB0aGluZ3Mgd291bGQgZmFpbCBpbiByYXRoZXIg cGVjdWxpYXIgd2F5cy4NCj4NCj4gV2UgZG8gbm90IGhhdmUgc2ltaWxhciBkb2N1bWVudGF0aW9u IGNvdmVyaW5nIG90aGVyIGFwcGxpY2F0aW9ucyBvZiBCRkQNCj4gd2hlcmUgc3BlY2lmaWMgYm9v dHN0cmFwcGluZyBzY2VuYXJpb3MgYXJlIHJlcXVpcmVkIChlLmcuIFZDQ1YpLiAgSSdtIG5vdA0K PiBzdXJlIGl0J3MgYXBwbGljYWJsZSBoZXJlIGVpdGhlci4gIEluIHBhcnRpY3VsYXIsIGEgc3Rh bmRhcmQgQkZEIHNlc3Npb24NCj4gbWlzY29uZmlndXJlZCB0byB1c2UgQkZEIG92ZXIgTEFHICpt aWdodCogYmUgYWJsZSB0byBib290c3RyYXAgYSBzaW5nbGUNCj4gbGluayBpZiBpdCB3YXNuJ3Qg dXNpbmcgdGhlIG11bHRpY2FzdCBkaXNjb3ZlcnkgYW5kIHRoZSBnaXZlbiBpbXBsZW1lbnRhdGlv bg0KPiBvZiBJUCBvbiB0aGUgbGluZSBjYXJkIHdhcyBhYmxlIHRvIHByb2dyZXNzIEJGRCBwYWNr ZXQgcHJvY2Vzc2luZyB3aXRoDQo+IHNlbWktcmVzb2x2ZWQgQVJQIGFkZHJlc3Nlcy4gIEJ1dCBh cyB5b3Ugc2VlLCB0aGVyZSdzIGEgc2lnbmlmaWNhbnQgbnVtYmVyDQo+IG9mICJ0aGUgZm9sbG93 aW5nIHRoaW5ncyB3b3VsZCBoYXZlIHRvIGFsc28gYmUgdHJ1ZSIuDQo+DQo+PiBJdCBzb3VuZHMg bGlrZSB0aGVyZSBhcmUgc29tZSB3b3JkcyBtaXNzaW5nLCBlLmcuIHNvbWV0aGluZyBsaWtlICJh bnkNCj4+IHN1Y2ggdW53YW50ZWQgQkZEIHNlc3Npb24iLi4uPw0KPg0KPiBIb25lc3RseSwgSSB3 b3VsZCBwcmVmZXIgdG8gZHJvcCB0aGlzIGxhc3Qgc2VudGVuY2UuICBUaGUgcHJpb3Igd29yZHMg c2VlbQ0KPiBzdHJvbmcgZW5vdWdoOg0KPiAgICAgVGhlIG5ldyBVRFAgcG9ydCByZW1vdmVzIHRo ZSBhbWJpZ3VpdHkgb2YgQkZEIG92ZXIgTEFHIHBhY2tldHMgZnJvbQ0KPiAgICAgQkZEIG92ZXIg c2luZ2xlLWhvcCBJUC4gIEFuIGV4YW1wbGUgaXMgY29uZmlndXJpbmcgYSBMQUcgd2l0aCBtaWNy bw0KPiAgICAgQkZEIHNlc3Npb25zIG9uIG9uZSBzaWRlIGJ1dCB1c2luZyBhIFtSRkM1ODgxXSBC RkQgc2Vzc2lvbiBmb3IgdGhlDQo+ICAgICBMQUcgKHRyZWF0ZWQgYXMgYSBzaW5nbGUgaW50ZXJm YWNlKSBvbiB0aGUgb3Bwb3NpdGUgc2lkZS4NCj4NCj4gV2hhdCB5b3VyIGNvbW1lbnQgd2FzIGFz a2luZyB3YXMgImRlc2NyaWJlIHdoYXQgaGFwcGVucyBpZiB5b3UgbWlzY29uZmlndXJlDQo+IHRo ZSBwb3J0IG51bWJlcnMiLg0KDQooSSB3YXNuJ3QgYXNraW5nIHRoaXMgaW4gZmFjdCAtLSBJIHdh c24ndCBjbGVhciBpbiB3aGF0IEkgYXNrZWQpDQoNCg0KPiBTZWUgbXkgY29tbWVudHMgYWJvdXQg YWJvdXQgdGhlIG51bWJlciBvZiBhZGRpdGlvbmFsDQo+IHZhcmlhYmxlcyB0aGF0IG1heSBiZSBw cmVzZW50IGluIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KSSB1bmRlcnN0YW5kIHlvdXIgYW5zd2Vy IGFuZCBNYXJjJ3MuDQoNCkxldCBtZSBleHBsYWluIHdoeSBpbiBteSB2aWV3cyBtYXkgY29tbWVu dCB3YXMgbm90IHlldCBhZGRyZXNzZWQuIEkgDQptZWFudCAiZXhwbGFpbiB3aGF0IGhhcHBlbnMi IGFzICJleHBsYWluIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gc2hvdWxkIA0KYmUgc28gdGhhdCB5 b3UgY2Fubm90IGhhdmUgJ3N0cmVhbXMgY3Jvc3NpbmcnIGJldHdlZW4gcGxhaW4gQkZEIGFuZCBh IA0KbWljcm8gQkZEIHNlc3Npb24iLCBpZS4gcWhhdCBJIGhhZCBpbiBtaW5kIHdhcyB0aGF0IHRo ZSB0ZXh0IA0KY291bGQvc2hvdWxkIG1ha2UgaXQgZXhwbGljaXQgdGhhdCB0aGUgcHJvY2VkdXJl cyBmb3IgcGxhaW4tQkZEIG11c3Qgbm90IA0KYmUgYXBwbGllZCBmb3Igc2Vzc2lvbiBvbiB0aGUg bWljcm8gQkZEIHBvcnQsIGFuZCB2aWNlLXZlcnNhLg0KDQpZb3UgYXJlIGNvcnJlY3QgdGhhdCB0 aGUgYWJvdmUgdGV4dCwgd2l0aCB0aGUgVURQIHBvcnQgYXMgdGhlIA0KZGlzY3JpbWluYXRvciwg YWNoaWV2ZXMgdGhlIHNhbWUgcHVycG9zZSBpbXBsaWNpdGx5LCBidXQgaWYgbmVnYXRpdmUgDQpz aWRlIGVmZmVjdHMgYXJlIGZlYXJlZCwgdGhlbiBtYWtpbmcgaXQgZnVsbHkgZXhwbGljaXQgd2l0 aCAiTVVTVCBOT1QicyANCndvdWxkIGJlIGEgZ29vZCB3YXkgdG8gaW5zaXN0IG9uIGl0Lg0KDQpU aGFua3MsDQoNCi1UaG9tYXMKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From cpignata@cisco.com Fri Dec 13 07:30:57 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC261AE300 for ; Fri, 13 Dec 2013 07:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 hQo4nXYVHAZ1 for ; Fri, 13 Dec 2013 07:30:54 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id BD75B1AE2DB for ; Fri, 13 Dec 2013 07:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8493; q=dns/txt; s=iport; t=1386948648; x=1388158248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cQ1XdLdTUP+HljC2TQxN49Iy9CEeo9ruXN9yFO6v9sk=; b=NQX7Jf25WFXN3mlG+wYgBdwXvfaZvTZ4UyudhLPwwEMdDa6+Oq851RMV HUO56EvA8i+jCKNh1SwEeaxDS73IL1Yt9Grr5Uih41FEEpj2/BpwhhKea Br1F/ssMqghRcmQ0ZmQLeVHDUlGtsRZbC9K+hl++jdMn9NG919iMqjDMg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHcnq1KtJV2b/2dsb2JhbABZgwqBDbhdgSMWdIImAQEEeRACAQhGMiUCBA4FiATLKheOMgERAR0zB4Q2AQOYFpIUgyqBcTk X-IronPort-AV: E=Sophos;i="4.95,479,1384300800"; d="scan'208";a="6593317" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 13 Dec 2013 15:30:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBDFUlB1027155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 15:30:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 09:30:47 -0600 From: "Carlos Pignataro (cpignata)" To: "thomas.morin@orange.com" Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO9TIwEubhr50IbEK5ruD9pSW3fppPn1aAgAAbNICAAPK4AIABqa4A Date: Fri, 13 Dec 2013 15:30:47 +0000 Message-ID: References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> <7118_1386839229_52A97CBC_7118_7473_1_52A97CBB.5090207@orange.com> In-Reply-To: <7118_1386839229_52A97CBC_7118_7473_1_52A97CBB.5090207@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.250.104] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Dec 2013 13:52:52 -0800 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , Marc Binderberger , Mach Chen , "Sami Boutros \(sboutros\)" , "jeff.tantsura@ericsson.com" , "Nobo Akiya \(nobo\)" , "bfd-chairs@tools.ietf.org" , Jeffrey Haas , "Henderickx, Wim \(Wim\)" , "Marc Binderberger \(mbinderb\)" , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:30:57 -0000 Thomas, Stepping back for a second =8B and hence top-posting =8B one question: if t= he micro BFD session uses a different UDP port (6784) from the =B3regular=B2 (3784) BFD session, what is exactly the fear with =8Cstreams crossing=B9? Is the same concern of BFD single-hop and BFD multi hop (4784) =8Cstreams crossing=B9? Thanks, =8B Carlos. On 12/12/13, 4:07 AM, "thomas.morin@orange.com" wrote: >Hi Jeff, > >2013-12-11, Jeffrey Haas: >>> However, as a contributor working for an operator, I am particularly >>> careful about documenting recommended approaches to make a deployment >>> smooth. This is very useful and really deserves IMHO to appear in the >>> document in a position that gives it a fair chance to be read by >>> implementors. >> >> Speaking as an implementor, if it's in the document, I read it as part >>of my >> work. > >Your are certainly an example that implementor should follow. >Speaking as an operator, I find very often that text gets ignored even >if in the main normative part of the document. And I can easily guess >that many people just don't read beyond the Acknowledgements section. > > >>> I would encourage you to consider moving the text in the main section >>>of >>> the document. Perhaps not as specification text using RFC2119 language, >>> but perhaps worded in terms to make it clear that there may be other >>> ways to obtain a similar effect but that implementors should take care >>> about such issues. >> >> The difficulty here is that the primary purpose of the draft is to >>describe >> protocol operations. The purpose of the appendix is to offer advice to >> implementors of the feature for graceful integration of the feature. >> However, that advice is not normative to the operation of the protocol. >> >> Having worked as an implementor across a number of companies over the >>years, >> I am extremely paranoid about placing such operational advice in the >>context >> of a specification. Doing such things tends to get interop >>labs/testsuites >> pedantically testing the behavior and saying "you're not compliant", >>even if >> the reason for the variance in the operational behavior is internally >> justified. >> >> The other half of this is that if someone does some behavior that is >> *better* than that covered in the document they may become >>non-compliant, >> while the on-the-wire protocol is not impacted. >> >> I would rather delete the appendix than make it take on the air of >>something >> that is a normative portion of the protocol. We were trying to be nice >>by >> offering implementation wisdom rather than making the next implementor >>run >> into the same issues we did in our implementations. > >Understood, and agreed. > >>>> For the L3 continuity (Mi.3), we kept the changes small, added to say >>>> "i.e. the ability for each member link to be able to forward L3 >>>> packets." When implementing, this aspect is largely implicit as the >>>>BFD >>>> processing will use layer-3 code. Making more detailed statements or >>>> requirements is difficult as it is implementation specific. >>> >>> Why not replace " and would be able to verify L3 Continuity per member >>> link; i.e. the ability for each member link to be able to forward L3 >>> packets. " by "and would be able to verify the ability for each >>> member link to be able to forward L3 packets". >>> >>> Said otherwise, what does the term "L3 continuity" bring ? >>> (I see the drawback that it may bring, given that it's unclear to me >>> what "continuity" means when we look at just one IP forwarding hop: BFD >>> LAG does not verify the ability of the box to forward one IP packet >>>from >>> one interface to another, right ?) >> >> I suspect this language was influenced by the VCCV feature and the >>language >> that was pushed upon BFD for that purpose. >> >> I don't have a strong feeling about keeping "L3 continuity" and would be >> fine accepting your text. >> >> Perhaps the other authors have some memory of why we went with that >> particular terminology. >> >>>> For the other comments I followed your advice/suggestions. >>> >>> I did not find text addressing Mi.1): >>> >>> ( It should probably explain what is the behavior if BFD messages from >>>a >>> micro-BFD sessions are received on the normal BFD port (3784), and >>> vice-versa what is the behavior for BFD messages from a non-BFD >>>sessions >>> is received on the micro-BFD UDP port. ) >>> >>> The added text does not seem to address the above. >>> >>> Additionally, I find the following new sentence "scary" (if I may say): >>> >>> The demultiplexing procedure described in this document will >>> prevent any BFD session to go into Up state. >>> >>> That sounds like BFD will not work at all anymore... ;) >> >> I tend to agree. I didn't have better text to offer, but the >>implication >> really is that the two instantiations of the BFD feature (BFD for >>IP/5881 >> and BFD over LAG) are really "ships in the night" features. If an >> implementation was somehow able to configure BFD port numbers such that >>the >> features were crossed... things would fail in rather peculiar ways. >> >> We do not have similar documentation covering other applications of BFD >> where specific bootstrapping scenarios are required (e.g. VCCV). I'm >>not >> sure it's applicable here either. In particular, a standard BFD session >> misconfigured to use BFD over LAG *might* be able to bootstrap a single >> link if it wasn't using the multicast discovery and the given >>implementation >> of IP on the line card was able to progress BFD packet processing with >> semi-resolved ARP addresses. But as you see, there's a significant >>number >> of "the following things would have to also be true". >> >>> It sounds like there are some words missing, e.g. something like "any >>> such unwanted BFD session"...? >> >> Honestly, I would prefer to drop this last sentence. The prior words >>seem >> strong enough: >> The new UDP port removes the ambiguity of BFD over LAG packets from >> BFD over single-hop IP. An example is configuring a LAG with micro >> BFD sessions on one side but using a [RFC5881] BFD session for the >> LAG (treated as a single interface) on the opposite side. >> >> What your comment was asking was "describe what happens if you >>misconfigure >> the port numbers". > >(I wasn't asking this in fact -- I wasn't clear in what I asked) > > >> See my comments about about the number of additional >> variables that may be present in the implementation. > >I understand your answer and Marc's. > >Let me explain why in my views may comment was not yet addressed. I >meant "explain what happens" as "explain that an implementation should >be so that you cannot have 'streams crossing' between plain BFD and a >micro BFD session", ie. qhat I had in mind was that the text >could/should make it explicit that the procedures for plain-BFD must not >be applied for session on the micro BFD port, and vice-versa. > >You are correct that the above text, with the UDP port as the >discriminator, achieves the same purpose implicitly, but if negative >side effects are feared, then making it fully explicit with "MUST NOT"s >would be a good way to insist on it. > >Thanks, > >-Thomas >__________________________________________________________________________ >_______________________________________________ > >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 que les pieces jointes. Les messages >electroniques 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 >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 >been modified, changed or falsified. >Thank you. > From thomas.morin@orange.com Fri Dec 13 08:43:40 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35AA1ADFC6 for ; Fri, 13 Dec 2013 08:43:40 -0800 (PST) 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 F-SnPaut1xl7 for ; Fri, 13 Dec 2013 08:43:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9321ADEB7 for ; Fri, 13 Dec 2013 08:43:38 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 2273337573B; Fri, 13 Dec 2013 17:43:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id D4E2415804E; Fri, 13 Dec 2013 17:43:30 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 17:43:30 +0100 From: To: "Carlos Pignataro (cpignata)" , Marc Binderberger Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO9TIuWnGCCoHNPUeHa/9P+WPrMJpPn1aAgAAbNICAAPK4AIABqa4A///yz4A= Date: Fri, 13 Dec 2013 16:43:30 +0000 Message-ID: <24148_1386953010_52AB3932_24148_203_1_52AB3931.8040300@orange.com> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> <7118_1386839229_52A97CBC_7118_7473_1_52A97CBB.5090207@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="utf-8" Content-ID: <1CB591980F205D489D94A1BA1C30F6C3@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 X-Mailman-Approved-At: Fri, 13 Dec 2013 13:52:53 -0800 Cc: "rtg-dir@ietf.org" , "Bhatia, Manav \(Manav\)" , Mach Chen , "Sami Boutros \(sboutros\)" , "jeff.tantsura@ericsson.com" , "Nobo Akiya \(nobo\)" , "bfd-chairs@tools.ietf.org" , Jeffrey Haas , "Henderickx, Wim \(Wim\)" , "Marc Binderberger \(mbinderb\)" , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:43:41 -0000 SGkgQ2FybG9zLA0KDQpHaXZlbiB0aGUgcHJlY2lzaW9uIGFkZGVkIGluIHBhcmFncmFwaCAzIG9m IHNlY3Rpb24gMi4yIGluIC0wNC1iZXRhLCBJIA0KZG9uJ3Qgc2VlIHJpc2tzIGlmIHBlb3BsZSBh Y3R1YWxseSBmb2xsb3cgdGhlIHNwZWNzLiBIb3dldmVyIHRoZXJlIG1heSANCmJlIGEgcmlzayBp ZiBpbXBsZW1lbnRvcnMgbWlzcyBvdXQgdGhpcyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IHBhcnQs IA0KaGVuY2UgbXkgc3VnZ2VzdGlvbiB0aGF0IGluc2lzdGluZyBvbiBpdCB3aWxsIGJlIGFuIGlt cHJvdmVtZW50IHRvIHRoZSB0ZXh0Lg0KDQpTbyBsZXQgbWUgcmVkdWNlIG15IGNvbW1lbnQgdG8g YSBzaW1wbGUgc3VnZ2VzdGlvbiBvZiB0ZXh0IHRvIGFkZCAoZWcuIA0KYWZ0ZXIgdGhlIHRleHQg ZXhwbGFpbmluZyB0aGUgdXNlIG9mIGEgZGlzdGluY3QgVURQIHBvcnQpOg0KDQogICBUaGUgcHJv Y2VkdXJlcyBpbiB0aGlzIGRvY3VtZW50IE1VU1QgYmUgdXNlZCBmb3IgQkZEIG1lc3NhZ2VzDQog ICBhZGRyZXNzZWQgdG8gcG9ydCA2Nzg0IGFuZCBNVVNUIE5PVCBiZSB1c2VkIGZvciBvdGhlcnMg cG9ydHMNCiAgIGFzc2lnbmVkIGluIFJGQ3MgZGVzY3JpYmVkIG90aGVyIEJGRCBtb2Rlcy4NCg0K VGhhbmsgeW91LA0KDQotVGhvbWFzDQoNCg0KDQoyMDEzLTEyLTEzLCBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSk6DQo+IFRob21hcywNCj4NCj4gU3RlcHBpbmcgYmFjayBmb3IgYSBzZWNvbmQg 4oC5IGFuZCBoZW5jZSB0b3AtcG9zdGluZyDigLkgb25lIHF1ZXN0aW9uOiBpZiB0aGUNCj4gbWlj cm8gQkZEIHNlc3Npb24gdXNlcyBhIGRpZmZlcmVudCBVRFAgcG9ydCAoNjc4NCkgZnJvbSB0aGUg wrNyZWd1bGFywrINCj4gKDM3ODQpIEJGRCBzZXNzaW9uLCB3aGF0IGlzIGV4YWN0bHkgdGhlIGZl YXIgd2l0aCDFknN0cmVhbXMgY3Jvc3NpbmfCuT8NCj4NCj4gSXMgdGhlIHNhbWUgY29uY2VybiBv ZiBCRkQgc2luZ2xlLWhvcCBhbmQgQkZEIG11bHRpIGhvcCAoNDc4NCkgxZJzdHJlYW1zDQo+IGNy b3NzaW5nwrk/DQo+DQo+IFRoYW5rcywNCj4NCj4g4oC5IENhcmxvcy4NCj4NCj4NCj4gT24gMTIv MTIvMTMsIDQ6MDcgQU0sICJ0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSIgPHRob21hcy5tb3JpbkBv cmFuZ2UuY29tPg0KPj4+Pg0KPj4+PiBJIGRpZCBub3QgZmluZCB0ZXh0IGFkZHJlc3NpbmcgTWku MSk6DQo+Pj4+DQo+Pj4+ICggSXQgc2hvdWxkIHByb2JhYmx5IGV4cGxhaW4gd2hhdCBpcyB0aGUg YmVoYXZpb3IgaWYgQkZEIG1lc3NhZ2VzIGZyb20NCj4+Pj4gYQ0KPj4+PiBtaWNyby1CRkQgc2Vz c2lvbnMgYXJlIHJlY2VpdmVkIG9uIHRoZSBub3JtYWwgQkZEIHBvcnQgKDM3ODQpLCBhbmQNCj4+ Pj4gdmljZS12ZXJzYSB3aGF0IGlzIHRoZSBiZWhhdmlvciBmb3IgQkZEIG1lc3NhZ2VzIGZyb20g YSBub24tQkZEDQo+Pj4+IHNlc3Npb25zDQo+Pj4+IGlzIHJlY2VpdmVkIG9uIHRoZSBtaWNyby1C RkQgVURQIHBvcnQuICkNCj4+Pj4NCj4+Pj4gVGhlIGFkZGVkIHRleHQgZG9lcyBub3Qgc2VlbSB0 byBhZGRyZXNzIHRoZSBhYm92ZS4NCj4+Pj4NCj4+Pj4gQWRkaXRpb25hbGx5LCBJIGZpbmQgdGhl IGZvbGxvd2luZyBuZXcgc2VudGVuY2UgInNjYXJ5IiAoaWYgSSBtYXkgc2F5KToNCj4+Pj4NCj4+ Pj4gICAgICAgIFRoZQlkZW11bHRpcGxleGluZyBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIHRoaXMg ZG9jdW1lbnQgd2lsbA0KPj4+PiAgICAgICAgcHJldmVudCBhbnkJQkZEIHNlc3Npb24gdG8gZ28g aW50byBVcCBzdGF0ZS4NCj4+Pj4NCj4+Pj4gVGhhdCBzb3VuZHMgbGlrZSBCRkQgd2lsbCBub3Qg d29yayBhdCBhbGwgYW55bW9yZS4uLiA7KQ0KPj4+DQo+Pj4gSSB0ZW5kIHRvIGFncmVlLiAgSSBk aWRuJ3QgaGF2ZSBiZXR0ZXIgdGV4dCB0byBvZmZlciwgYnV0IHRoZQ0KPj4+IGltcGxpY2F0aW9u DQo+Pj4gcmVhbGx5IGlzIHRoYXQgdGhlIHR3byBpbnN0YW50aWF0aW9ucyBvZiB0aGUgQkZEIGZl YXR1cmUgKEJGRCBmb3INCj4+PiBJUC81ODgxDQo+Pj4gYW5kIEJGRCBvdmVyIExBRykgYXJlIHJl YWxseSAic2hpcHMgaW4gdGhlIG5pZ2h0IiBmZWF0dXJlcy4gIElmIGFuDQo+Pj4gaW1wbGVtZW50 YXRpb24gd2FzIHNvbWVob3cgYWJsZSB0byBjb25maWd1cmUgQkZEIHBvcnQgbnVtYmVycyBzdWNo IHRoYXQNCj4+PiB0aGUNCj4+PiBmZWF0dXJlcyB3ZXJlIGNyb3NzZWQuLi4gdGhpbmdzIHdvdWxk IGZhaWwgaW4gcmF0aGVyIHBlY3VsaWFyIHdheXMuDQo+Pj4NCj4+PiBXZSBkbyBub3QgaGF2ZSBz aW1pbGFyIGRvY3VtZW50YXRpb24gY292ZXJpbmcgb3RoZXIgYXBwbGljYXRpb25zIG9mIEJGRA0K Pj4+IHdoZXJlIHNwZWNpZmljIGJvb3RzdHJhcHBpbmcgc2NlbmFyaW9zIGFyZSByZXF1aXJlZCAo ZS5nLiBWQ0NWKS4gIEknbQ0KPj4+IG5vdA0KPj4+IHN1cmUgaXQncyBhcHBsaWNhYmxlIGhlcmUg ZWl0aGVyLiAgSW4gcGFydGljdWxhciwgYSBzdGFuZGFyZCBCRkQgc2Vzc2lvbg0KPj4+IG1pc2Nv bmZpZ3VyZWQgdG8gdXNlIEJGRCBvdmVyIExBRyAqbWlnaHQqIGJlIGFibGUgdG8gYm9vdHN0cmFw IGEgc2luZ2xlDQo+Pj4gbGluayBpZiBpdCB3YXNuJ3QgdXNpbmcgdGhlIG11bHRpY2FzdCBkaXNj b3ZlcnkgYW5kIHRoZSBnaXZlbg0KPj4+IGltcGxlbWVudGF0aW9uDQo+Pj4gb2YgSVAgb24gdGhl IGxpbmUgY2FyZCB3YXMgYWJsZSB0byBwcm9ncmVzcyBCRkQgcGFja2V0IHByb2Nlc3Npbmcgd2l0 aA0KPj4+IHNlbWktcmVzb2x2ZWQgQVJQIGFkZHJlc3Nlcy4gIEJ1dCBhcyB5b3Ugc2VlLCB0aGVy ZSdzIGEgc2lnbmlmaWNhbnQNCj4+PiBudW1iZXINCj4+PiBvZiAidGhlIGZvbGxvd2luZyB0aGlu Z3Mgd291bGQgaGF2ZSB0byBhbHNvIGJlIHRydWUiLg0KPj4+DQo+Pj4+IEl0IHNvdW5kcyBsaWtl IHRoZXJlIGFyZSBzb21lIHdvcmRzIG1pc3NpbmcsIGUuZy4gc29tZXRoaW5nIGxpa2UgImFueQ0K Pj4+PiBzdWNoIHVud2FudGVkIEJGRCBzZXNzaW9uIi4uLj8NCj4+Pg0KPj4+IEhvbmVzdGx5LCBJ IHdvdWxkIHByZWZlciB0byBkcm9wIHRoaXMgbGFzdCBzZW50ZW5jZS4gIFRoZSBwcmlvciB3b3Jk cw0KPj4+IHNlZW0NCj4+PiBzdHJvbmcgZW5vdWdoOg0KPj4+ICAgICAgVGhlIG5ldyBVRFAgcG9y dCByZW1vdmVzIHRoZSBhbWJpZ3VpdHkgb2YgQkZEIG92ZXIgTEFHIHBhY2tldHMgZnJvbQ0KPj4+ ICAgICAgQkZEIG92ZXIgc2luZ2xlLWhvcCBJUC4gIEFuIGV4YW1wbGUgaXMgY29uZmlndXJpbmcg YSBMQUcgd2l0aCBtaWNybw0KPj4+ICAgICAgQkZEIHNlc3Npb25zIG9uIG9uZSBzaWRlIGJ1dCB1 c2luZyBhIFtSRkM1ODgxXSBCRkQgc2Vzc2lvbiBmb3IgdGhlDQo+Pj4gICAgICBMQUcgKHRyZWF0 ZWQgYXMgYSBzaW5nbGUgaW50ZXJmYWNlKSBvbiB0aGUgb3Bwb3NpdGUgc2lkZS4NCj4+Pg0KPj4+ IFdoYXQgeW91ciBjb21tZW50IHdhcyBhc2tpbmcgd2FzICJkZXNjcmliZSB3aGF0IGhhcHBlbnMg aWYgeW91DQo+Pj4gbWlzY29uZmlndXJlDQo+Pj4gdGhlIHBvcnQgbnVtYmVycyIuDQo+Pg0KPj4g KEkgd2Fzbid0IGFza2luZyB0aGlzIGluIGZhY3QgLS0gSSB3YXNuJ3QgY2xlYXIgaW4gd2hhdCBJ IGFza2VkKQ0KPj4NCj4+DQo+Pj4gU2VlIG15IGNvbW1lbnRzIGFib3V0IGFib3V0IHRoZSBudW1i ZXIgb2YgYWRkaXRpb25hbA0KPj4+IHZhcmlhYmxlcyB0aGF0IG1heSBiZSBwcmVzZW50IGluIHRo ZSBpbXBsZW1lbnRhdGlvbi4NCj4+DQo+PiBJIHVuZGVyc3RhbmQgeW91ciBhbnN3ZXIgYW5kIE1h cmMncy4NCj4+DQo+PiBMZXQgbWUgZXhwbGFpbiB3aHkgaW4gbXkgdmlld3MgbWF5IGNvbW1lbnQg d2FzIG5vdCB5ZXQgYWRkcmVzc2VkLiBJDQo+PiBtZWFudCAiZXhwbGFpbiB3aGF0IGhhcHBlbnMi IGFzICJleHBsYWluIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gc2hvdWxkDQo+PiBiZSBzbyB0aGF0 IHlvdSBjYW5ub3QgaGF2ZSAnc3RyZWFtcyBjcm9zc2luZycgYmV0d2VlbiBwbGFpbiBCRkQgYW5k IGENCj4+IG1pY3JvIEJGRCBzZXNzaW9uIiwgaWUuIHFoYXQgSSBoYWQgaW4gbWluZCB3YXMgdGhh dCB0aGUgdGV4dA0KPj4gY291bGQvc2hvdWxkIG1ha2UgaXQgZXhwbGljaXQgdGhhdCB0aGUgcHJv Y2VkdXJlcyBmb3IgcGxhaW4tQkZEIG11c3Qgbm90DQo+PiBiZSBhcHBsaWVkIGZvciBzZXNzaW9u IG9uIHRoZSBtaWNybyBCRkQgcG9ydCwgYW5kIHZpY2UtdmVyc2EuDQo+Pg0KPj4gWW91IGFyZSBj b3JyZWN0IHRoYXQgdGhlIGFib3ZlIHRleHQsIHdpdGggdGhlIFVEUCBwb3J0IGFzIHRoZQ0KPj4g ZGlzY3JpbWluYXRvciwgYWNoaWV2ZXMgdGhlIHNhbWUgcHVycG9zZSBpbXBsaWNpdGx5LCBidXQg aWYgbmVnYXRpdmUNCj4+IHNpZGUgZWZmZWN0cyBhcmUgZmVhcmVkLCB0aGVuIG1ha2luZyBpdCBm dWxseSBleHBsaWNpdCB3aXRoICJNVVNUIE5PVCJzDQo+PiB3b3VsZCBiZSBhIGdvb2Qgd2F5IHRv IGluc2lzdCBvbiBpdC4NCj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4gLVRob21hcwpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From jhaas@slice.pfrc.org Fri Dec 13 08:45:49 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043241ADF9B for ; Fri, 13 Dec 2013 08:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, 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 muUbgB6sbrOe for ; Fri, 13 Dec 2013 08:45:48 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAEC1ADEB7 for ; Fri, 13 Dec 2013 08:45:48 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id A16D0C266; Fri, 13 Dec 2013 11:45:41 -0500 (EST) Date: Fri, 13 Dec 2013 11:45:41 -0500 From: Jeffrey Haas To: thomas.morin@orange.com Message-ID: <20131213164541.GE19433@pfrc> References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> <7118_1386839229_52A97CBC_7118_7473_1_52A97CBB.5090207@orange.com> <24148_1386953010_52AB3932_24148_203_1_52AB3931.8040300@orange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24148_1386953010_52AB3932_24148_203_1_52AB3931.8040300@orange.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 13 Dec 2013 13:52:51 -0800 Cc: "Carlos Pignataro \(cpignata\)" , "Bhatia, Manav \(Manav\)" , "rtg-dir@ietf.org" , Marc Binderberger , Mach Chen , "Sami Boutros \(sboutros\)" , "jeff.tantsura@ericsson.com" , "Nobo Akiya \(nobo\)" , "bfd-chairs@tools.ietf.org" , Jeffrey Haas , "Henderickx, Wim \(Wim\)" , "Marc Binderberger \(mbinderb\)" , "paul.hitchen@bt.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:45:49 -0000 Thomas, On Fri, Dec 13, 2013 at 04:43:30PM +0000, thomas.morin@orange.com wrote: > The procedures in this document MUST be used for BFD messages > addressed to port 6784 and MUST NOT be used for others ports > assigned in RFCs described other BFD modes. Which precludes the procedures from being used at some point in the future by a spec based on this one. Perhaps BFD for LAGs over switched ports. :-) -- Jeff From adrian@olddog.co.uk Fri Dec 13 14:40:25 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB41AE441 for ; Fri, 13 Dec 2013 14:40:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izXnRlmeHrQE for ; Fri, 13 Dec 2013 14:40:23 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 672D91AE43E for ; Fri, 13 Dec 2013 14:40:23 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBDMe25Z004116; Fri, 13 Dec 2013 22:40:02 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBDMdxB4004088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Dec 2013 22:40:00 GMT From: "Adrian Farrel" To: "'Jeffrey Haas'" , References: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> <20131209145824955173.389eae90@sniff.de> <19746_1386781264_52A89A50_19746_863_1_52A89A4F.4080605@orange.com> <20131211183825.GA4843@pfrc> <7118_1386839229_52A97CBC_7118_7473_1_52A97CBB.5090207@orange.com> <24148_1386953010_52AB3932_24148_203_1_52AB3931.8040300@orange.com> <20131213164541.GE19433@pfrc> In-Reply-To: <20131213164541.GE19433@pfrc> Date: Fri, 13 Dec 2013 22:39:58 -0000 Message-ID: <066201cef854$4220a4e0$c661eea0$@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: AQND8Ojs7wfilmh6qtx/FmHlXYerxAH6bD/ZAv65m2UBrscPiQDqBy22AkJLcZoBUey03AI6o3NZlv2+8fA= Content-Language: en-gb X-Mailman-Approved-At: Fri, 13 Dec 2013 14:40:42 -0800 Cc: "'Carlos Pignataro \(cpignata\)'" , "'Bhatia, Manav \(Manav\)'" , rtg-dir@ietf.org, 'Marc Binderberger' , 'Mach Chen' , "'Sami Boutros \(sboutros\)'" , jeff.tantsura@ericsson.com, "'Nobo Akiya \(nobo\)'" , bfd-chairs@tools.ietf.org, "'Henderickx, Wim \(Wim\)'" , "'Marc Binderberger \(mbinderb\)'" , paul.hitchen@bt.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:40:25 -0000 Jeff, (What a lot of recipients! Welcome to our spamfest.) Saying "MUST NOT" in this document does not preclude future documents describing new applications. It precludes new applications without documentation. That is, a new document can update this one to change the "MUST NOT" under specific conditions. What *this* document does is describe the behavior of implementations of *this* document. I think that put the answer somewhere between you and Thomas. This document cannot influence what implementations of something else do (although it can give advice and dire warnings). What it can do is be very clear about what implementations of this document do. A > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: 13 December 2013 16:46 > To: thomas.morin@orange.com > Cc: Carlos Pignataro (cpignata); Bhatia, Manav (Manav); rtg-dir@ietf.org; Marc > Binderberger; Mach Chen; Sami Boutros (sboutros); jeff.tantsura@ericsson.com; > Nobo Akiya (nobo); bfd-chairs@tools.ietf.org; Jeffrey Haas; Henderickx, Wim > (Wim); Marc Binderberger (mbinderb); paul.hitchen@bt.com > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-on-lags-03 > > Thomas, > > On Fri, Dec 13, 2013 at 04:43:30PM +0000, thomas.morin@orange.com wrote: > > The procedures in this document MUST be used for BFD messages > > addressed to port 6784 and MUST NOT be used for others ports > > assigned in RFCs described other BFD modes. > > Which precludes the procedures from being used at some point in the future > by a spec based on this one. Perhaps BFD for LAGs over switched ports. :-) > > -- Jeff From curtis@ipv6.occnc.com Tue Dec 17 19:36:36 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1451AE04F; Tue, 17 Dec 2013 19:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBGZ-3I2Vkuc; Tue, 17 Dec 2013 19:36:32 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5F1AE038; Tue, 17 Dec 2013 19:36:31 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id rBI3aTOu079410; Tue, 17 Dec 2013 22:36:29 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201312180336.rBI3aTOu079410@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Wed, 11 Dec 2013 13:57:47 -0500." <52A8B5AB.4040708@labn.net> Date: Tue, 17 Dec 2013 22:36:29 -0500 X-Mailman-Approved-At: Wed, 18 Dec 2013 08:14:23 -0800 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 03:36:36 -0000 In message <52A8B5AB.4040708@labn.net> Lou Berger writes: > 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. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > 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-rtgwg-cl-requirement-13.txt > Reviewer: Lou Berger > Review Date: 2013-12-11 > IETF LC End Date: 2013-12-09 > Intended Status: Informational > > Summary: > > I have some minor concerns about this document that I think > should be resolved before publication. > > Comments: > > I think the document is greatly improved since the previous last > call. I have some comments and reservations on the document that are > described below. As discussed on the list, I remain concerned about the > value of defining requirements in terms of nebulous "Performance > Objectives", but as this is acceptable to the WG I will not elaborate on > this concern further. > > Major Issues: > > No major issues found. > > Minor Issues: > > 1. Terminology & consistency: the document coins the term "Advanced > Multipath": > Advanced Multipath is a formalization of multipath techniques > > Do you see this term as a new noun, like LSP, or as an adjective? I > expected the latter, i.e. that it be used like "multipath" is used in > the above sentence, but it seems to be used as a new noun. I'm not sure > coining a new noun really makes sense, but if this the intent then the > last paragraph of section 2 needs to be revised as "Advanced Multipath" > will now have a specific definition as opposed to a generic term. Also I > suggest always capitalizing it (or even using the abbreviation "AM") > will clarify this distinction. I see multipath as a noun and therefore advanced multipath as a noun. Advanced is an adjective, multipath as a noun. Advanced Multipath is the set of techniques that form a solution. An advanced multipath is a collection of componet links. The former is capitalized, the latter is not. I'll check to see if I got that right in all occurances. If you would like I can also add this to the definition making it: OLD Advanced Multipath Advanced Multipath meets the requirements defined in this document. A key capability of advanced multipath is the support of non-homogeneous component links. NEW Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. An "advanced multipath" is a collection of component links. In this document the former is capitalized and the latter is not. If we agree on this I'll just search for "advanced" and make capitalization consistent with the above statements. I don't think the phrase "advanced multipath technique" makes it an adjective any more than a statement such as make-before-break is an MPLS technique" makes MPLS an adjective in normal use. The phrase "an X technique" is simply a shorthand for indicating a "technique applicable to X". Even if that makes it an adjective the phrase "MPLS technique" is common and so that should not be a problem. The paragraph in question might be the following. It seems benign to me. The term Advanced Multipath is intended to be used within the context of this document and the related documents, [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and any other related document. Other advanced multipath techniques may in the future arise. If the capabilities defined in this document become commonplace, they would no longer be considered "advanced". Use of the term "advanced multipath" outside this document, if referring to the term as defined here, should indicate Advanced Multipath as defined by this document, citing the current document name. If using another definition of "advanced multipath", documents may optionally clarify that they are not using the term "advanced multipath" as defined by this document if clarification is deemed helpful. I see no problem with this. Please be more specific if you think there are places where advanced multipath is used as an adjective or where its use is confusing. > 2. Editorial: server and client layer vs upper and lower layer. > > The document uses server and client layer networks and LSPs and, > sometimes interchangeably or redundantly, upper and lower layer networks > and LSPs. I think this issue can be resolved by avoiding the term > client/server when referring to network layers and just using the > lower/upper terminology. The one exception to this is in the definition > Client LSP which should simply be defined in the context of a multipath, > i.e.: > OLD > A client LSP is an LSP which has been set up over a server layer. > NEW > A client LSP is an LSP which has been set up over Advanced Multipath. A client LSP can be set up over a server layer MPLS-TP LSP or any server layer MPLS LSP or over a link layer or over a pseudowire ... or over an advanced multipath. > I think this also means that usage of the term "Client" is limited to > "Client LSP". I searched for all occurances of the word client. All occurances are "client LSP" excexpt the phrase "client of a client LSP" and that is used only in the following paragraph. The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. THe point is that "A midpoint LSR does not participate in the signaling of any clients of the client LSP" and that non-participation in client (or higher layer) signaling applies to any "client of a client LSP", not just other LSP running over it. I then searched for all occurances of the words upper and lower and higher. There are no occurances of "upper". There were a few occurances of "lower latency" and "higher latency". Other than that, all occurances of lower and higher except one are in the follwoing text: 3.2. Component Links Provided by Lower Layer Networks A component link may be supported by a lower layer network. For example, the lower layer may be a circuit switched network or another MPLS network (e.g., MPLS-TP)). The lower layer network may change the latency (and/or other performance parameters) seen by the client layer. Currently, there is no protocol for the lower layer network to inform the higher layer network of a change in a performance parameter. Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable. FR#8 The solution SHALL specify a protocol means to allow a lower layer server network to communicate latency to the higher layer client network. The exception is this sentence: FR#22 The solution SHOULD support the use case where an advanced multipath itself is a component link for a higher order advanced multipath. For example, an advanced multipath comprised of MPLS- TP bi-directional tunnels viewed as logical links could then be used as a component link in yet another advanced multipath that connects MPLS routers. The terms lower layer and higher layer go all the way back to the ISO seven layer model of ancient times (1970s?, 1980s?) and maybe further back but that is before even my time. I don't think this is unclear but I could add the following in definitions: Higher Layers A client layer is the one immediately above a server layer. The client layer and all layers above that layer are higher layers. Lower Layers A server layer is the later immediately below a client laer. The server layer and all layers below are lower layers. Do I really need to put this in the definitions section? If yoy think it is necessary, I will add it. > 3. Technical: The document should make it clear that LSPs can provide > paths from an Advanced Multipath. I suggest adding something like the > the following at the end of page 3 > d. a lower layer LSP. Case "b." is intended to include LSP but is not specifically limited to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, Ethernet Link Aggregation, and all sorts of things that don't involve MPLS at all. For example, a path in Ethernet Link Aggregation Group (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though this would be unknown to the LAG, or in the simplest case each path in the set of LAG members could be supported by a plain Ethernet cable. > and at the end of the Component Link definition: > A component link may be provided via an LSP. I think this is covered in "3.2. Component Links Provided by Lower Layer Networks". 3.2. Component Links Provided by Lower Layer Networks A component link may be supported by a lower layer network. For example, the lower layer may be a circuit switched network or another MPLS network (e.g., MPLS-TP)). This sort of statement could be made earlier. For example in the discussion following the definitions (on page 5) the document covers one case (where a component link is not an LSP) but it is not until later that the other case is mentioned. I could add a paragraph in the discussion following the definitions that mentions that a component link can also be another LSP. OLD: A Component Link may be a point-to-point physical link (where a "physical link" includes one or more link layer plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's Performance Objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub- layers, including those providing physical layer emulation. NEW: A Component Link may be a point-to-point physical link (where a "physical link" includes one or more link layer plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's Performance Objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub- layers, including those providing physical layer emulation, or over MPLS server layer LSP. These are identical except the phrase ", or over MPLS server layer LSP" added to the end of the last sentence. > 4. Editorial: Unless I'm mistaken, the requirements in this document > apply to the Advanced Multipath solution. In most cases the document > states requirements in the form of "The solution", but in a few cases it > just says "advanced multipath". I think these cases should be changed > to apply to an "Advanced Multipath solution". I think this comment > applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. That is not correct. For example: FR#1 An advanced multipath MAY be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency. The advanced multipath SHALL behave as a single IGP adjacency. In this requirement the "advanced multipath" is a specific collection of component links that is announced by way of an MPLS Forwarding Adjaccency (FA) in the IGP. The same is true for the other requirements cited. In all of these cases an advanced multipath is a specific collection of component links. There is a typo in MR#1. OLD MR#1 Management Plane MUST support polling of the status and configuration of an advanced multipath and its individual advanced multipath and support notification of status change. NEW MR#1 Management Plane MUST support polling of the status and configuration of an advanced multipath and its individual component links and support notification of status change. In the last line s/advanced multipath/component links/ > 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > In these cases it is unclear if the requirements apply to > (a) a client's ability to indicate a desired service/LSP constraint or > (b) a selected component link's attribute that will be used by a client > LSP, > (c) both, or > (d) something completely different > The requirements should be clear to which entity the requirement applies. This "indication" can be through signaling or the management plane and both must be supported in later framework and protocol definitions and we can argue then whether both must be supported or if one or the other is a "should" in RFC 2119 speak. There was concern that the word "signal" would exclude providing the same informantion through the management plane and therefore the word "indicate" is used. Rather than spell this out many times we hoped this would be clear. I could add clarifying text up front if you think this is necessary. For example, I could add the following before FR#1. FR#0 In requirements that follow in this document the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents providing framework and protocol definitions both signaling and management plane mechanisms MUST be defined. It would be trivial to make this FR#1 and renumber the rest. Should I add it and renumber? > 6. The last paragraph in section 3.3. strikes me as both odd and out of > place. There are so many possible decisions that must be considered by > network operators relative to disruption and optimization. Why mention > just "power reduction"? Is there something special about the > interactions of multipath and power reduction? What value / information > does this paragraph add? The last paragraph in section 3.3 is: Allowing multipath to contain component links with different characteristics can improve the overall load balance and can be accomplished while still accommodating the more strict requirements of a subset of client LSP. I'm not sure if this is the "odd and out of place" paragraph you refer to. It summarizes the purpose of the requirements in this section. I think you mean section 3.5 and not 3.3. The remainder of your paragraph above discusses power reducetion and this is only mentioned in section 3.5 so I think you mean this paragraph. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weigh the benefit of power reduction against the disadvantage of a minimal disruption. The paragraphs following a set of requirements provide discussion related to that set of requirements. I don't see this as out of place. The prior two paragraphs discuss delay discontinuity. This paragraph is a reminder that "As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive." I don't see this as out of place. For example, to compensate for a less than perfect load balance a subset of LSPs may need to be moved and that subset can be chosen from those which will be least affected (and there are plenty of requirements that compell the fussy LSP to tell the network abour their specifial needs). To power down a component link, *all* LSP on that component link need to be moved, even the very fussy ones. Therefore I think mentioning that disruption should be considered is not out of place in the discussion following these requirements. We like to keep the discussion brief so this level of detail was not included. > 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? At the very least it means something similar to same administrative domain. An AS can be subdivided within an organization. Do you have a better way to define intra-domain and inter-domain without going down the rat hole of defining the term "domain"? No on in the WG had an issue with this so far but I'm open for a suggestion for better wording. > Nits: > > - References should be provided in all cases when referring to > "existing ... techniques" References are not allowed in the abstract. In section 3.3 is the sentence: Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of existing techniques and a set of references. Much of that document is dedicated to describing existing techniques and it contains quite a few references. I can move this sentence. Where in the document would you like to see it moved to? > Using line numbers from > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt Using line number is a text editor counts the page headers. What tool are you using? I didn't see anything on tools.ietf.org. So I'll guess. Looks like add 10 lines per page. > Line 112 > s/SHOULD/should s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ Also remove stray comma. > Line 118 > s/MAY/may s/deployment MAY choose to/deployment may choose to/ OK. Could go either way but s/MAY chose to/MAY/ would work too. > Line 149, match intro: > s/Advanced Multipath meets/Advanced Multipath is a formalization of > multipath techniques that meet OK. > Lines 251-254, beginning with "The" through the end of the paragraph. > This should be an FR. Looks like you mean this: The transient period between some service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by Performance Objective values. OK. I'll add this as FR#6++. > That's it, > Lou There are a few suggestions for changes to the text based on your comments and a few questions for you. Based on your response to this email I will edit the document. Thanks for the thorough review. Curtis