From nobody Tue Aug 1 02:40:06 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB90132C47; Tue, 1 Aug 2017 02:39:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150158039749.9669.10725894647522064724.idtracker@ietfa.amsl.com> Date: Tue, 01 Aug 2017 02:39:57 -0700 Archived-At: Subject: [DMM] Alexey Melnikov's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:39:57 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nit: IANA-3 value is referenced in the IANA Considerations, but is not used. I think you meant IANA-4 in the place where IANA-3 is currently referenced. From nobody Tue Aug 1 13:13:34 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA9012778D; Tue, 1 Aug 2017 13:13:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150161840636.12123.2784912255737760138.idtracker@ietfa.amsl.com> Date: Tue, 01 Aug 2017 13:13:26 -0700 Archived-At: Subject: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:13:26 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. I had the same concern as the SecDir reviewer in reading the draft, the concern about leaking traffic as a result of multiple tunnels is not addressed in the security considerations section. Hilary's writeup is quite helpful https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html From nobody Wed Aug 2 02:46:25 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49387131D6D; Wed, 2 Aug 2017 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8vZkxrJDWDga; Wed, 2 Aug 2017 02:46:22 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF64127978; Wed, 2 Aug 2017 02:46:18 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 630DDC0754; Wed, 2 Aug 2017 11:46:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4224AC0063; Wed, 2 Aug 2017 11:46:17 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0352.000; Wed, 2 Aug 2017 11:46:17 +0200 From: To: "ietf@kuehlewind.net" , "iesg@ietf.org" CC: "dmm-chairs@ietf.org" , "draft-ietf-dmm-mag-multihoming@ietf.org" , "dmm@ietf.org" Thread-Topic: =?utf-8?B?W0RNTV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0?= =?utf-8?B?Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHTCkbXHFgoZp7dwEGHF2S2oFwAPKJwy2RA Date: Wed, 2 Aug 2017 09:46:15 +0000 Message-ID: <1514_1501667177_59819F69_1514_119_1_81C77F07008CA24F9783A98CFD706F713AA907E5@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> In-Reply-To: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-mag-multihoming-04=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 09:46:24 -0000 SGVsbG8gTWlyamEsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBXZSB3aWxsIHVwZGF0ZSB0 aGUgZG9jdW1lbnQgYWNjb3JkaW5nbHk7IHBsZWFzZSBzZWUgaW5saW5lIGZvciByZXNvbHV0aW9u Lg0KDQpSZWdhcmRzLA0KUGllcnJpY2sNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGUgOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBN aXJqYSBLw7xobGV3aW5kDQo+IEVudm95w6kgOiBsdW5kaSAzMSBqdWlsbGV0IDIwMTcgMjM6NDkN Cj4gw4AgOiBUaGUgSUVTRw0KPiBDYyA6IGRtbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt ZG1tLW1hZy1tdWx0aWhvbWluZ0BpZXRmLm9yZzsNCj4gZG1tQGlldGYub3JnDQo+IE9iamV0IDog W0RNTV0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kbW0tbWFnLW11 bHRpaG9taW5nLTA0Og0KPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPg0KPiBNaXJqYSBL w7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K PiBkcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmctMDQ6IERpc2N1c3MNCj4NCj4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPg0KPg0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbW0tbWFn LW11bHRpaG9taW5nLw0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4NCj4gMSkgVGhpcyBkb2N1bWVudCBzaG91bGQgbm90IHJlY29tbWVuZCB0 aGUgdXNlIG9mIE1QVENQIGZvciB0dW5uZWxpbmcsIGFzIFRDUC0NCj4gaW4tVENQIHR1bm5lbHMg YXJlIGdlbmVyYWxseSBub3QgcmVjb21tZW5kIGlmIHRoYXQgY2FuIGJlIGF2b2lkZWQuDQoNClRo ZSBkb2N1bWVudCBkb2VzIG5vdCByZWNvbW1lbmQgc3VjaCBhIHRoaW5nLi4uIHRoZSBkb2N1bWVu dCBsZXZlcmFnZXMgUE1JUCAoUkZDNTIxMykgdHVubmVsaW5nIG1lY2hhbmlzbXMsIGkuZS4gSVAt aW4tSVAsIEdSRSwgLi4uDQoNClBsZWFzZSByZW1vdmUNCj4gdGhlIGZvbGxvd2luZyBwYXJ0IGZy b20gc2VjdGlvbiAzLjIgYW5kIGxlYXZlIElQLWxldmVsIHR1bm5lbGluZyBhcyB0aGUgb25seSBv cHRpb246DQo+IOKAnlBhY2tldCBkaXN0cmlidXRpb24gY2FuIGJlIGRvbmUgZWl0aGVyIGF0IHRo ZSB0cmFuc3BvcnQgbGV2ZWwsIGUuZy4gdXNpbmcgTVBUQ1Ag4oCm4oCcDQo+DQoNCk9rLCB3ZSB3 aWxsIHJlbW92ZSB0aGUgc2VudGVuY2UuIEJ1dCBqdXN0IHRvIGNsYXJpZnk6IHRoaXMgc2VudGVu Y2UgcmVmZXJzIHRvIE1QVENQIGFzIHBhY2tldCBkaXN0cmlidXRpb24gc2NoZW1lLCBub3QgdHVu bmVsaW5nLCBpLmUuIHJ1biBNUFRQIG92ZXIgUE1JUCAgdHVubmVscyAoSVAgdHVubmVscykuIFRo aXMgZG9jdW1lbnQgZm9sbG93cyB0aGUgaWRlYSB0aGF0IGJ1aWxkaW5nIHRoZSBkYXRhcGF0aCwg d2l0aCB0aGUgbXVsdGlwbGUgYmluZGluZyBvcHRpb24sIGlzIG9uZSB0aGluZyBhbmQgaG93IHRv IHVzZSB0aGUgdHVubmVscyBpcyBhbm90aGVyIHRoaW5nLi4uLiBNUFRDUCBjYW4gdGh1cyBiZSBv bmUgb2YgdGhlIHdheSB0byBkaXN0cmlidXRlIHRoZSB0cmFmZmljIGFjcm9zcyB0aGVzZSB0dW5u ZWxzOyB3ZSBhY3R1YWxseSBiZWxpZXZlIHRoYXQgdXNlIGV4aXN0aW5nIElFVEYgcHJvdG9jb2xz IGluc3RlYWQgb2YgIHJlaW52ZW50aW5nIGhhemFyZG91cyBtZWNoYW5pc21zLi4uDQoNCj4gMikg RnVydGhlciB0aGUgZm9sbG93aW5nIHNlbnRlbmNlcyBhbHNvIGluIHNlY3Rpb24gMy4yIHNob3Vs ZCBiZSByZXZpc2VkOg0KPiDigJ5Gb3IgZXhhbXBsZSwgaGlnaCB0aHJvdWdocHV0IHNlcnZpY2Vz IChlLmcuDQo+ICAgIHZpZGVvIHN0cmVhbWluZykgbWF5IGJlbmVmaXQgZnJvbSBwZXItcGFja2V0 IGRpc3RyaWJ1dGlvbiBzY2hlbWUsDQo+ICAgIHdoaWxlIGxhdGVuY3kgc2Vuc2l0aXZlIGFwcGxp Y2F0aW9ucyAoZS5nLiAgVm9JUCkgYXJlIG5vdCBiZSBzcHJlYWQNCj4gICAgb3ZlciBkaWZmZXJl bnQgV0FOIHBhdGhzLuKAnA0KPiBIaWdoIHRocm91Z2hwdXQgc2VydmljZXMgb25seSBiZW5lZml0 IGZyb20gcGVyLXBhY2tldCBzY2hlZHVsaW5nIGlmIHRoZSBzZXJ2aWNlDQo+IHJlcXVpcmVzIGhp Z2hlciB0aHJvdWdocHV0IHRoYW4gb25lIG9mIHRoZSBsaW5rcyBjYW4gcHJvdmlkZS4gQWxzbyB2 aWRlbyBzdHJlYW1pbmcNCj4gbWF5IG5vdCBiZSBhIGdvb2QgZXhhbXBsZSBoZXJlIGJlY2F1c2Ug aGlnaCBsYXRlbmN5IHZhcmlhdGlvbnMgY2FuIGxlYWQgdG8NCj4gc3RhbGxzLiBUaGVyZWZvcmUg aW4gZ2VuZXJhbCBwZXItZmxvdyBzY2hlZHVsaW5nIHNob3VsZCBiZSByZWNvbW1lbmQgZm9yIGFs bA0KPiB0cmFmZmljLiBJdCBjb3VsZCBzdGlsbCBiZSBiZW5lZmljaWFsIHRvIHNjaGVkdWxlIGZs b3dzIHRoYXQgcmVxdWlyZSBsb3cgbGF0ZW5jeSBvdmVyIHRoZQ0KPiBsaW5rIHdpdGggdGhlIGxv d2VyIGJhc2UgbGF0ZW5jeSwgb3IgbWF5YmUgbW9yZSBpbXBvcnRhbnQgbG93ZXIgaml0dGVyLCBo b3dldmVyLA0KPiBvZnRlbiBpdCBpcyBub3Qga25vd24gdG8gdGhlIG5ldHdvcmsgd2hhdCB0aGUg cmVxdWlyZW1lbnRzIG9uIGxhdGVuY3kgYXJlIGZvciBhDQo+IGdpdmVuIGZsb3cuIFRoZXJlZm9y ZSBpcyBzaG91bGQgcHJvYmFibHkgYmUgcmVjb21tZW5kZWQgdG8gc2NoZWR1bGUgYWxsIHRyYWZm aWMNCj4gb24gdGhlICJiZXR0ZXIiIGxpbmsgKHdoZXJlIGJldHRlciBjYW4gYmUgcHJlLWNvbmZp Z3VyZWQga25vd2xlZGdlIG9yIG1lYXN1cmVkKSBhcw0KPiBsb25nIGFzIHRoZSBiYW5kd2lkdGgg b2YgdGhlIGluY29taW5nIHRyYWZmaWMgaXMgc21hbGxlciB0aGFuIHRoZSBiYW5kd2lkdGggb2Yg dGhlDQo+IHRoYXQgbGluaywgYW5kIG9ubHkgdXNlIGEgc2Vjb25kIGxpbmsgKHdpdGggcGVyLWZs b3cgc2NoZWR1bGluZykgaWYgdGhlIGNhcGFjaXR5IGlzDQo+IHJlcXVpcmVkLg0KPg0KDQpJIGFn cmVlLiBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGFpbSB0byByZWNvbW1lbmQgd2F5 cyB0byBzdGVlciB0cmFmZmljIG92ZXIgbXVsdGlwbGUgcGF0aHMuIEV4YW1wbGVzIGZvY3VzZXMg b24gdXNlLWNhc2VzIGZyb20gUkZDNDkwOCB0byB3aGljaCB0aGUgZG9jdW1lbnQgaW5lcml0cy4g QWN0dWFsbHksIGFzIHBlciBSRkM3ODY0IChmbG93IG1vYmlsaXR5IGV4dGVuc2lvbiBmb3IgUE1J UHY2KSwgbGVhdmVzIHBvc3NpYmlsaXR5IHRvIHVzZSBlaXRoZXIgcGVyLWZsb3cgYW5kIHBlci1w YWNrZXQgZGlzdHJpYnV0aW9uLi4gdXNlIG9uZSBvZiB0aGlzIHNjaGVtZSwgb3IgYm90aCBpdCBp cyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UgdGhhdCAgaXMgb3V0IHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0KDQoNCj4gMykgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCByZWFsbHkgbm9ybWF0 aXZlIHNwZWNpZnkgdGhlIHVzZSBvZiB0aGUgbmV3bHkgZGVmaW5lZA0KPiBvcHRpb25zLiBJdCBv bmx5IGdpdmVzIGFuIGV4YW1wbGVzIGJ1dCBpdCBkb2VzIG5vdCBzcGVjaWZ5IG5vcm1hdGl2ZWx5 IGFueSBhY3Rpb25zDQo+IHRoYXQgbmVlZCB0byBwZXJmb3JtZWQgb24gcmVjZWlwdCBvZiB0aGVz ZSBvcHRpb25zLiBIb3cgZG9lcyB0aGUgTUFHIGtub3cgaWYNCj4gdGhlIExNQSBkb2VzIG5vdCBz dXBwb3J0IE11bHRpcGF0aCBiaW5kaW5nPyBBbiBMTUEgdGhhdCBkb2VzIG5vdCBpbXBsZW1lbnQg dGhpcw0KPiBzcGVjIHdpbGwgbm90IHNlbmQgYmFjayBhbiBlcnJvciBtZXNzYWdlLg0KDQpHb29k IHBvaW50Li4uDQoNClNlY3Rpb24gNC4zIHN0YXRlcyB0aGUgTE1BIHRoYXQgZG9lcyBub3Qgc3Vw cG9ydCBtdWx0aXBhdGggYmluZGluZy5TSE9VTEQgcmVwbGllcyB3aXRoIHRoZSBlcnJvciBtZXNz YWdlOiAgIENBTk5PVF9TVVBQT1JUX01VTFRJUEFUSF9CSU5ESU5HDQoNCkhvd2V2ZXIsIGlmIHRo ZSBMTUEgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIHNwZWMgYW5kLCB0aHVzLCBkb2VzIG5vdCBzdXBw b3J0IHRoaXMgZXJyb3IgbWVzc2FnZSwgdGhlIE1BRyBzaGFsbCBub3QgcmVjZWl2ZSB0aGUgTUFH IGlkZW50aWZpZXIgaW4gdGhlIFBCVSBhY2suIFNvLCB0aGF0IE1BRyBzaGFsbCB0aHVzIGZhbGwt YmFjayB0byB0aGUgbGVnYWN5IFJGQzUyMTMgY29tcGxpYW50IE1BRyBiZWhhdmlvci4NCg0KV2Ug d2lsbCBjbGFyaWZpeSB0aGF0Lg0KDQpXaHkgYXJlIHRoZXJlIHR3byBkaWZmZXJlbnQgb3B0aW9u cz8NCj4gV2hhdCBoYXBwZW5zIGlmIG9uZSBvZiB0aGUgb3B0aW9ucyBpcyBwcmVzZW50IGluIHRo ZSBQcm94eSBCaW5kaW5nIFVwZGF0ZSBidXQgbm90DQo+IHRoZSBvdGhlcj8NCj4NCg0KVGhlIHBy b3h5IGJpbmRpbmcgdXBkYXRlIGNvbnRhaW5zIHRoZSBNQUcgaWRlbnRpZmllciBhbmQgIHRoZSBt dWx0aWhvbWluZyAuIFRoZSBMTUEgcmVwbGllcyB3aXRoIG9ubHkgdGhlIE1BRyBpZGVudGlmaWVy IG9wdGlvbi4gVGhpcyBpcyBpbiBzZWN0aW9uIDMuMSAod2hpY2ggc2hvdWxkIGJlIHJlbmFtZWQg YXMgInByb3RvY29sIG92ZXJ2aWV3IiksIGJ1dCBJIGNvbmZlc3MgdGhhdCBpdCBzaG91bGQgYmUg YmV0dGVyIGhpZ2hsaWdodGVkLi4uLkFsc28sIGlmIG9uZSBvcHRpb24gaXMgbWlzc2luZyBpbiB0 aGUgUEJVLCB0aGUgYmVoYXZpb3Igc2hvdWxkIGJlIHNpbWlsYXIgdG8gd2hhdCBpdCBpcyBzcGVj aWZpZWQgaW4gUE1JUHY2IFJGQzUyMTM6ICJNSVNTSU5HX1hYWF9PUFRJT04iIGVycm9yIHNob3Vs ZCBiZSBzZW50IGJ5IHRoZSBMTUEgaW4gdGhlIFBCQS4uLiB3ZSB3aWxsIGFkZCB0aGlzLg0KDQoN Cj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IFBs ZWFzZSBhbHNvIGNsYXJpZnkgdGhlIGRlZmluaXRpb25zIG9mIEludGVyZmFjZSBMYWJlbCBhbmQg QmluZGluZyBJZGVudGlmaWVyIGFzDQo+IHJlcXVlc3RlZCBieSB0aGUgZ2VuLWFydCByZXZpZXcg KFRoYW5rcyBSb2JlcnQhKQ0KPg0KPg0KDQpZZXMsIG9mIGNvdXJzZS4NCg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkbW0gbWFpbGluZyBsaXN0 DQo+IGRtbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RtbQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Aug 2 08:25:35 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE713214B; Wed, 2 Aug 2017 08:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ0ut0G7hW_6; Wed, 2 Aug 2017 08:25:21 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70335132149; Wed, 2 Aug 2017 08:25:01 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id 33so20077811wrz.4; Wed, 02 Aug 2017 08:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BAEpk2jxKotXria1H3Qq0+DrKO6RF/VYDQySPsljwVY=; b=mX4a1LEG84dMahhwDVBlhMkKw6bg+t0Dq0Q2kArSeC1nj6Nc4zBBwFbj8aADBOvi43 nmjorFOJ9UwQ/Pc0SGiDuQVSi3LttINaR31+ZhJIKVPin6wWe2ncvwwexW0l2BdJkEY0 Rv/Spi7Pk5zi6uO1B6Hhdnu99LKwJY68/QY6fpyw8//GIjyRHdJpDvz3ZBmF5WjOYTY+ EzpR08wjEHiNTTveM2bYF0zlCIHlCXuDJF+27N8wbIXLOzNrpRlAki+/4Qh8+HC1IrWj U1PE7vMUXKEebxQ98M+3lzRuyOTpxwu4HR2hPLttooEoysr54xUXKWv3U0TgsxePdpwz KvFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=BAEpk2jxKotXria1H3Qq0+DrKO6RF/VYDQySPsljwVY=; b=bcZpXlCPwDl2IRSaWRNVv7u2io7kO+KD91ZIENVW2LwmVuATuWT/yIlauCAnFxJq2a /1ACDh/F+4N945Lyw+TJzn3cuxHLTn3zoD4FL9DKUyEUdf5Jtop46il0GI/i2ev0WnzX 4rx4R5BQPYCzPvg04p5xMriZ1bbaauiCFjFE83iu0voJUIYfhF0rmLY5DfLQzT00L/mv 679EaERmyspil9x3WrBO/uw86O/3RuUKgOrQNyBQ2CxSdiU3feGRPzjCBfU2TSQiZHZO AWPvmEeZeTd+VaXJASGW+dt1XJ3B71MyM8iNb9YLPpDBh1bHgczTN7F8TMlv1RJ8pWrL 5B6Q== X-Gm-Message-State: AIVw111+UpqHwEqu6F4olFIsIHRwtG8vXyOck5XESkslPCwz6eZgSbEr N++2HarmolL9gFT97hvaJ34Z1Aenqw== X-Received: by 10.223.160.229 with SMTP id n34mr20473557wrn.117.1501687499924; Wed, 02 Aug 2017 08:24:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.212 with HTTP; Wed, 2 Aug 2017 08:24:59 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <1514_1501667177_59819F69_1514_119_1_81C77F07008CA24F9783A98CFD706F713AA907E5@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> <1514_1501667177_59819F69_1514_119_1_81C77F07008CA24F9783A98CFD706F713AA907E5@OPEXCLILM22.corporate.adroot.infra.ftgroup> From: Behcet Sarikaya Date: Wed, 2 Aug 2017 10:24:59 -0500 Message-ID: To: Pierrick Seite Cc: "ietf@kuehlewind.net" , "iesg@ietf.org" , "draft-ietf-dmm-mag-multihoming@ietf.org" , "dmm-chairs@ietf.org" , "dmm@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c18478cff2b530555c6dd4e" Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-mag-multihoming-04=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:25:29 -0000 --94eb2c18478cff2b530555c6dd4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 2, 2017 at 4:46 AM, wrote: > Hello Mirja, > > Thanks for the comments. We will update the document accordingly; please > see inline for resolution. > > Regards, > Pierrick > > > -----Message d'origine----- > > De : dmm [mailto:dmm-bounces@ietf.org] De la part de Mirja K=C3=BChlewi= nd > > Envoy=C3=A9 : lundi 31 juillet 2017 23:49 > > =C3=80 : The IESG > > Cc : dmm-chairs@ietf.org; draft-ietf-dmm-mag-multihoming@ietf.org; > > dmm@ietf.org > > Objet : [DMM] Mirja K=C3=BChlewind's Discuss on draft-ietf-dmm-mag- > multihoming-04: > > (with DISCUSS and COMMENT) > > > > Mirja K=C3=BChlewind has entered the following ballot position for > > draft-ietf-dmm-mag-multihoming-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > 1) This document should not recommend the use of MPTCP for tunneling, a= s > TCP- > > in-TCP tunnels are generally not recommend if that can be avoided. > > The document does not recommend such a thing... the document leverages > PMIP (RFC5213) tunneling mechanisms, i.e. IP-in-IP, GRE, ... > > Please remove > > the following part from section 3.2 and leave IP-level tunneling as the > only option: > > =E2=80=9EPacket distribution can be done either at the transport level,= e.g. > using MPTCP =E2=80=A6=E2=80=9C > > > > Ok, we will remove the sentence. But just to clarify: this sentence refer= s > to MPTCP as packet distribution scheme, not tunneling, i.e. run MPTP over > PMIP tunnels (IP tunnels). This document follows the idea that building > the datapath, with the multiple binding option, is one thing and how to u= se > the tunnels is another thing.... MPTCP can thus be one of the way to > distribute the traffic across these tunnels; we actually believe that use > existing IETF protocols instead of reinventing hazardous mechanisms... > > I think you are talking about the hybrid access solution that was discussed long time back in BBF. Such a discussion belongs to BANANA group not dmm. This draft is supposed to be a maintenance draft coming from Netext which is now closed. dmm is not the place to add new functionality such as hybrid access capability to PMIP. Such a capability would require PMIP support at the home gateways which was not agreed upon in BBF. I support Mirja's comment and suggest removing the whole discussion from the draft. Regards, Behcet > > 2) Further the following sentences also in section 3.2 should be revise= d: > > =E2=80=9EFor example, high throughput services (e.g. > > video streaming) may benefit from per-packet distribution scheme, > > while latency sensitive applications (e.g. VoIP) are not be spread > > over different WAN paths.=E2=80=9C > > High throughput services only benefit from per-packet scheduling if the > service > > requires higher throughput than one of the links can provide. Also vide= o > streaming > > may not be a good example here because high latency variations can lead > to > > stalls. Therefore in general per-flow scheduling should be recommend fo= r > all > > traffic. It could still be beneficial to schedule flows that require lo= w > latency over the > > link with the lower base latency, or maybe more important lower jitter, > however, > > often it is not known to the network what the requirements on latency > are for a > > given flow. Therefore is should probably be recommended to schedule all > traffic > > on the "better" link (where better can be pre-configured knowledge or > measured) as > > long as the bandwidth of the incoming traffic is smaller than the > bandwidth of the > > that link, and only use a second link (with per-flow scheduling) if the > capacity is > > required. > > > > I agree. However, this document does not aim to recommend ways to steer > traffic over multiple paths. Examples focuses on use-cases from RFC4908 t= o > which the document inerits. Actually, as per RFC7864 (flow mobility > extension for PMIPv6), leaves possibility to use either per-flow and > per-packet distribution.. use one of this scheme, or both it is an > implementation choice that is out the scope of this document. > > > > 3) This document does not really normative specify the use of the newly > defined > > options. It only gives an examples but it does not specify normatively > any actions > > that need to performed on receipt of these options. How does the MAG > know if > > the LMA does not support Multipath binding? An LMA that does not > implement this > > spec will not send back an error message. > > Good point... > > Section 4.3 states the LMA that does not support multipath binding.SHOULD > replies with the error message: CANNOT_SUPPORT_MULTIPATH_BINDING > > However, if the LMA does not support this spec and, thus, does not suppor= t > this error message, the MAG shall not receive the MAG identifier in the P= BU > ack. So, that MAG shall thus fall-back to the legacy RFC5213 compliant MA= G > behavior. > > We will clarifiy that. > > Why are there two different options? > > What happens if one of the options is present in the Proxy Binding > Update but not > > the other? > > > > The proxy binding update contains the MAG identifier and the multihoming > . The LMA replies with only the MAG identifier option. This is in section > 3.1 (which should be renamed as "protocol overview"), but I confess that = it > should be better highlighted....Also, if one option is missing in the PBU= , > the behavior should be similar to what it is specified in PMIPv6 RFC5213: > "MISSING_XXX_OPTION" error should be sent by the LMA in the PBA... we wil= l > add this. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please also clarify the definitions of Interface Label and Binding > Identifier as > > requested by the gen-art review (Thanks Robert!) > > > > > > Yes, of course. > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > ____________________________________________________________ > _____________________________________________________________ > > 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 o= u > 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 bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --94eb2c18478cff2b530555c6dd4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 4:46 AM, <pierrick.seite@orange.com> wrote:
Hello Mirja,

Thanks for the comments. We will update the document accordingly; please se= e inline for resolution.

Regards,
Pierrick

> -----Message d'origine-----
> De : dmm [mailto:dmm-bounces@i= etf.org] De la part de Mirja K=C3=BChlewind
> Envoy=C3=A9 : lundi 31 juillet 2017 23:49
> =C3=80 : The IESG
> Cc : dmm-chairs@ietf.org; <= a href=3D"mailto:draft-ietf-dmm-mag-multihoming@ietf.org">draft-ietf-dmm-ma= g-multihoming@ietf.org;
> dmm@ietf.org
> Objet : [DMM] Mirja K=C3=BChlewind's Discuss on draft-ietf-dmm-mag= -multihoming-04:
> (with DISCUSS and COMMENT)
>
> Mirja K=C3=BChlewind has entered the following ballot position for
> draft-ietf-dmm-mag-multihoming-04: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> 1) This document should not recommend the use of MPTCP for tunneling, = as TCP-
> in-TCP tunnels are generally not recommend if that can be avoided.

The document does not recommend such a thing... the document leverag= es PMIP (RFC5213) tunneling mechanisms, i.e. IP-in-IP, GRE, ...

Please remove
> the following part from section 3.2 and leave IP-level tunneling as th= e only option:
> =E2=80=9EPacket distribution can be done either at the transport level= , e.g. using MPTCP =E2=80=A6=E2=80=9C
>

Ok, we will remove the sentence. But just to clarify: this sentence = refers to MPTCP as packet distribution scheme, not tunneling, i.e. run MPTP= over PMIP=C2=A0 tunnels (IP tunnels). This document follows the idea that = building the datapath, with the multiple binding option, is one thing and h= ow to use the tunnels is another thing.... MPTCP can thus be one of the way= to distribute the traffic across these tunnels; we actually believe that u= se existing IETF protocols instead of=C2=A0 reinventing hazardous mechanism= s...


I think you ar= e talking about the hybrid access solution that was discussed long time bac= k in BBF.
Such a discussion belongs to BANANA group not dmm.<= br>
This draft is supposed to be a maintenance draft coming f= rom Netext which is now closed.
dmm is not the place to add n= ew functionality such as hybrid access capability to PMIP.
= =C2=A0Such a capability would require PMIP support at the home gateways whi= ch was not agreed upon in BBF.
I support Mirja's comment = and suggest removing the whole discussion from the draft.

Regards,

Behcet
= > 2) Further the following sentences also in section 3.2 should be revis= ed:
> =E2=80=9EFor example, high throughput services (e.g.
>=C2=A0 =C2=A0 video streaming) may benefit from per-packet distribution= scheme,
>=C2=A0 =C2=A0 while latency sensitive applications (e.g.=C2=A0 VoIP) ar= e not be spread
>=C2=A0 =C2=A0 over different WAN paths.=E2=80=9C
> High throughput services only benefit from per-packet scheduling if th= e service
> requires higher throughput than one of the links can provide. Also vid= eo streaming
> may not be a good example here because high latency variations can lea= d to
> stalls. Therefore in general per-flow scheduling should be recommend f= or all
> traffic. It could still be beneficial to schedule flows that require l= ow latency over the
> link with the lower base latency, or maybe more important lower jitter= , however,
> often it is not known to the network what the requirements on latency = are for a
> given flow. Therefore is should probably be recommended to schedule al= l traffic
> on the "better" link (where better can be pre-configured kno= wledge or measured) as
> long as the bandwidth of the incoming traffic is smaller than the band= width of the
> that link, and only use a second link (with per-flow scheduling) if th= e capacity is
> required.
>

I agree. However, this document does not aim to recommend ways to st= eer traffic over multiple paths. Examples focuses on use-cases from RFC4908= to which the document inerits. Actually, as per RFC7864 (flow mobility ext= ension for PMIPv6), leaves possibility to use either per-flow and per-packe= t distribution.. use one of this scheme, or both it is an implementation ch= oice that=C2=A0 is out the scope of this document.


> 3) This document does not really normative specify the use of the newl= y defined
> options. It only gives an examples but it does not specify normatively= any actions
> that need to performed on receipt of these options. How does the MAG k= now if
> the LMA does not support Multipath binding? An LMA that does not imple= ment this
> spec will not send back an error message.

Good point...

Section 4.3 states the LMA that does not support multipath binding.SHOULD r= eplies with the error message:=C2=A0 =C2=A0CANNOT_SUPPORT_MULTIPATH_BI= NDING

However, if the LMA does not support this spec and, thus, does not support = this error message, the MAG shall not receive the MAG identifier in the PBU= ack. So, that MAG shall thus fall-back to the legacy RFC5213 compliant MAG= behavior.

We will clarifiy that.

Why are there two different options?
> What happens if one of the options is present in the Proxy Binding Upd= ate but not
> the other?
>

The proxy binding update contains the MAG identifier and=C2=A0 the m= ultihoming . The LMA replies with only the MAG identifier option. This is i= n section 3.1 (which should be renamed as "protocol overview"), b= ut I confess that it should be better highlighted....Also, if one option is= missing in the PBU, the behavior should be similar to what it is specified= in PMIPv6 RFC5213: "MISSING_XXX_OPTION" error should be sent by = the LMA in the PBA... we will add this.


>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Please also clarify the definitions of Interface Label and Binding Ide= ntifier as
> requested by the gen-art review (Thanks Robert!)
>
>

Yes, of course.

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

_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s 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 inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

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

--94eb2c18478cff2b530555c6dd4e-- From nobody Wed Aug 2 08:51:06 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA37F129ABE; Wed, 2 Aug 2017 08:51:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150168906468.5751.13580574259195982629.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 08:51:04 -0700 Archived-At: Subject: [DMM] Alia Atlas' No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:51:05 -0000 Alia Atlas has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sec 3.2: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. " is clearly not a properly written sentence. I also share Mirja's concerns about TCP inside TCP. 2) Sec 4.1: "This flag MUST NOT be set to a value of (1), if the value of the Registration Overwrite Flag (O) is set to a value of (1). Binding Overwrite (O)" Please make the draft consistent as to the name of the flag (O) From nobody Wed Aug 2 10:35:13 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BEC131F3C; Wed, 2 Aug 2017 10:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 oBamCJ5HBXD8; Wed, 2 Aug 2017 10:35:01 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7BC131EC1; Wed, 2 Aug 2017 10:35:00 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4E76C1C061A; Wed, 2 Aug 2017 19:34:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 052D4180081; Wed, 2 Aug 2017 19:34:56 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0352.000; Wed, 2 Aug 2017 19:34:55 +0200 From: To: Alia Atlas , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: RE : Alia Atlas' No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) Thread-Index: AdMLtadN3GZQmyGTSJu8xuaE08cSxA== Date: Wed, 2 Aug 2017 17:34:54 +0000 Message-ID: <12067_1501695299_59820D43_12067_500_1_w8u6t9tm8p2kcb2blckr0dcl.1501695292134@email.android.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_w8u6t9tm8p2kcb2blckr0dcl1501695292134emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Alia Atlas' No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:35:02 -0000 --_000_w8u6t9tm8p2kcb2blckr0dcl1501695292134emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIZWxsbywNCg0KVGhhbmtzIGZvciBjb21tZW50LCBwbGVhc2Ugc2VlIGRldGFpbHMgaW5saW5l Lg0KDQpSZWdhcmRzDQpQaWVycmljaw0KDQoNClNlbnQgZnJvbSBteSBjZWxsIHBob25lLCBtaW5k IHRoZSB0eXBvcy4NCg0KLS0tLS0tLS0gTWVzc2FnZSBkJ29yaWdpbmUgLS0tLS0tLS0NCkRlIDog QWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb20+DQpEYXRlIDogMDIvMDgvMjAxNyAxNzo1MSAo R01UKzAxOjAwKQ0Kw4AgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjIDogZHJhZnQtaWV0 Zi1kbW0tbWFnLW11bHRpaG9taW5nQGlldGYub3JnLCBKb3VuaSBLb3Job25lbiA8am91bmkubm9z cGFtQGdtYWlsLmNvbT4sIGRtbS1jaGFpcnNAaWV0Zi5vcmcsIGpvdW5pLm5vc3BhbUBnbWFpbC5j b20sIGRtbUBpZXRmLm9yZw0KT2JqZXQgOiBBbGlhIEF0bGFzJyBObyBPYmplY3Rpb24gb24gZHJh ZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiAod2l0aCBDT01NRU5UKQ0KDQpBbGlhIEF0 bGFzIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQt aWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxs DQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0K UGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1 c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmcvDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoxKSBTZWMgMy4yOiAiUGFj a2V0IGRpc3RyaWJ1dGlvbiBjYW4gYmUgZG9uZQ0KICAgICAgZWl0aGVyIGF0IHRoZSB0cmFuc3Bv cnQgbGV2ZWwsIGUuZy4gdXNpbmcgTVBUQ1Agb3IgYXQgV2hlbg0KICAgICAgb3BlcmF0aW5nIGF0 IHRoZSBJUCBwYWNrZXQgbGV2ZWwsIGRpZmZlcmVudCBwYWNrZXRzIGRpc3RyaWJ1dGlvbg0KICAg ICAgYWxnb3JpdGhtcyBhcmUgcG9zc2libGUuICIgIGlzIGNsZWFybHkgbm90IGEgcHJvcGVybHkg d3JpdHRlbiBzZW50ZW5jZS4NCiAgICAgIEkgYWxzbyBzaGFyZSBNaXJqYSdzIGNvbmNlcm5zIGFi b3V0IFRDUCBpbnNpZGUgVENQLg0KDQpQUzogVGhlIGRyYWZ0IGRvZXMgbm90IHVzZSBUQ1Agb3Zl ciBUQ1AgdHVubmVsaW5nLiBPbmx5IFBNSVAgdHVubmVsaW5nICwgaS5lIElQLWluLUlQLCBHUkUu IC4gKE1vcmUgZGV0YWlscyBpbiBteSByZXBseSB0byBNaXJqYSkuIFLDqWbDqXJlbmNlIHRvIE1Q VENQIHdpbGwgYmUgcmVtb3ZlZCB0byBhdm9pZCBzdWNoIGNvbmZ1c2lvbi4NCg0KMikgU2VjIDQu MTogIlRoaXMgZmxhZyBNVVNUIE5PVCBiZSBzZXQgdG8gYQ0KICAgICAgdmFsdWUgb2YgKDEpLCBp ZiB0aGUgdmFsdWUgb2YgdGhlIFJlZ2lzdHJhdGlvbiBPdmVyd3JpdGUgRmxhZyAoTykNCiAgICAg IGlzIHNldCB0byBhIHZhbHVlIG9mICgxKS4NCg0KICAgQmluZGluZyBPdmVyd3JpdGUgKE8pIg0K ICAgUGxlYXNlIG1ha2UgdGhlIGRyYWZ0IGNvbnNpc3RlbnQgYXMgdG8gdGhlIG5hbWUgb2YgdGhl IGZsYWcgKE8pDQoNClBTIDogZm9yIHN1cmUuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_w8u6t9tm8p2kcb2blckr0dcl1501695292134emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+SGVsbG8sPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3Mg Zm9yIGNvbW1lbnQsIHBsZWFzZSBzZWUgZGV0YWlscyBpbmxpbmUuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5SZWdhcmRzJm5ic3A7PC9kaXY+DQo8ZGl2PlBpZXJyaWNrJm5ic3A7PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImNvbXBv c2VyX3NpZ25hdHVyZSI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTci PlNlbnQgZnJvbSBteSBjZWxsIHBob25lLCBtaW5kIHRoZSB0eXBvcy4mbmJzcDs8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9y OiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPg0KPGRpdj4tLS0tLS0tLSBNZXNzYWdl IGQnb3JpZ2luZSAtLS0tLS0tLTwvZGl2Pg0KPGRpdj5EZSA6IEFsaWEgQXRsYXMgJmx0O2FrYXRs YXNAZ21haWwuY29tJmd0OyA8L2Rpdj4NCjxkaXY+RGF0ZSA6IDAyLzA4LzIwMTcgMTc6NTEgKEdN VCYjNDM7MDE6MDApIDwvZGl2Pg0KPGRpdj7DgCA6IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3Jn Jmd0OyA8L2Rpdj4NCjxkaXY+Q2MgOiBkcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmdAaWV0 Zi5vcmcsIEpvdW5pIEtvcmhvbmVuICZsdDtqb3VuaS5ub3NwYW1AZ21haWwuY29tJmd0OywgZG1t LWNoYWlyc0BpZXRmLm9yZywgam91bmkubm9zcGFtQGdtYWlsLmNvbSwgZG1tQGlldGYub3JnDQo8 L2Rpdj4NCjxkaXY+T2JqZXQgOiBBbGlhIEF0bGFzJyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiAod2l0aCBDT01NRU5UKQ0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+QWxpYSBBdGxhcyBoYXMgZW50ZXJlZCB0 aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLWRtbS1tYWct bXVsdGlob21pbmctMDQ6IE5vIE9iamVjdGlvbjxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4N CmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJy Pg0KPGJyPg0KPGJyPg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfQkxBTksi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sPC9hPjxicj4NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1tLW1hZy1t dWx0aWhvbWluZy8iIHRhcmdldD0iX0JMQU5LIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmcvPC9hPjxicj4NCjxicj4NCjxicj4N Cjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQo8YnI+DQoxKSBTZWMgMy4yOiAmcXVvdDtQYWNrZXQgZGlzdHJpYnV0aW9uIGNhbiBiZSBkb25l PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVpdGhlciBhdCB0aGUgdHJhbnNw b3J0IGxldmVsLCBlLmcuIHVzaW5nIE1QVENQIG9yIGF0IFdoZW48YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb3BlcmF0aW5nIGF0IHRoZSBJUCBwYWNrZXQgbGV2ZWwsIGRpZmZl cmVudCBwYWNrZXRzIGRpc3RyaWJ1dGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBhbGdvcml0aG1zIGFyZSBwb3NzaWJsZS4gJnF1b3Q7Jm5ic3A7IGlzIGNsZWFybHkgbm90 IGEgcHJvcGVybHkgd3JpdHRlbiBzZW50ZW5jZS48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSSBhbHNvIHNoYXJlIE1pcmphJ3MgY29uY2VybnMgYWJvdXQgVENQIGluc2lkZSBU Q1AuPC9kaXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iUGxhaW5UZXh0Ij5QUzogVGhlIGRyYWZ0IGRvZXMgbm90IHVzZSBUQ1Agb3ZlciBUQ1AgdHVu bmVsaW5nLiBPbmx5IFBNSVAgdHVubmVsaW5nICwgaS5lIElQLWluLUlQLCBHUkUuIC4gKE1vcmUg ZGV0YWlscyBpbiBteSByZXBseSB0byBNaXJqYSkuIFLDqWbDqXJlbmNlIHRvIE1QVENQIHdpbGwg YmUgcmVtb3ZlZCB0byBhdm9pZCBzdWNoIGNvbmZ1c2lvbi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9IlBsYWluVGV4dCI+PGJyPg0KMikgU2VjIDQuMTogJnF1b3Q7VGhpcyBmbGFnIE1VU1QgTk9U IGJlIHNldCB0byBhPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlIG9m ICgxKSwgaWYgdGhlIHZhbHVlIG9mIHRoZSBSZWdpc3RyYXRpb24gT3ZlcndyaXRlIEZsYWcgKE8p PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHNldCB0byBhIHZhbHVlIG9m ICgxKS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgQmluZGluZyBPdmVyd3JpdGUgKE8pJnF1b3Q7 PGJyPg0KJm5ic3A7Jm5ic3A7IFBsZWFzZSBtYWtlIHRoZSBkcmFmdCBjb25zaXN0ZW50IGFzIHRv IHRoZSBuYW1lIG9mIHRoZSBmbGFnIChPKTxicj4NCjxicj4NClBTIDogZm9yIHN1cmUuJm5ic3A7 PGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPFBSRT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_w8u6t9tm8p2kcb2blckr0dcl1501695292134emailandroidcom_-- From nobody Wed Aug 2 10:54:08 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC36129A92; Wed, 2 Aug 2017 10:54:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150169644117.5772.16801460686092306963.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 10:54:01 -0700 Archived-At: Subject: [DMM] Spencer Dawkins' No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:54:01 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for making the change to address Mirja's Discuss, which I agreed with. I also agree with your proposed resolution. From nobody Wed Aug 2 11:05:05 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FFA129417; Wed, 2 Aug 2017 11:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 rOm68rGTRFEY; Wed, 2 Aug 2017 11:05:02 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C89126E3A; Wed, 2 Aug 2017 11:05:02 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 0D93A1207D0; Wed, 2 Aug 2017 20:05:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id CA946180062; Wed, 2 Aug 2017 20:05:00 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0352.000; Wed, 2 Aug 2017 20:05:00 +0200 From: To: Kathleen Moriarty , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: RE : Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AdMLudtsH1AzHo+ZRZu5Ecm1SAmf9g== Date: Wed, 2 Aug 2017 18:05:00 +0000 Message-ID: <22002_1501697100_5982144C_22002_294_1_011tltohcmw3npknpg1m4xea.1501697097442@email.android.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_011tltohcmw3npknpg1m4xea1501697097442emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:05:04 -0000 --_000_011tltohcmw3npknpg1m4xea1501697097442emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gS2F0aGxlZW4sDQoNCllvdSdyZSByaWdodC4gLi4gc29ycnkgZm9yIGxhdGUgcmVwbHkg dG8gSGlsYXJ5J3MgY29uY2Vybi4gUGxlYXNlIHNlZSBvdXIgcmVwbHkgYmVsb3cuDQoNClJlZ2Fy ZHMNClBpZXJyaWNrICYgU3JpDQoNCnRoZXJlIGlzIG9uZSBzZWN1cml0eSBpc3N1ZSB0aGF0IGlz IG1lbnRpb25lZCBpbiBSRkM1MjEzIHRoYXQNCmlzIGV4YWNlcmJhdGVkIGJ5IHRoZSBjdXJyZW50 IGRyYWZ0LiAgSS5lLiwNCg0KVG8gYWRkcmVzcyB0aGUgdGhyZWF0IHJlbGF0ZWQgdG8gYSBjb21w cm9taXNlZCBtb2JpbGUgYWNjZXNzIGdhdGV3YXksDQogICB0aGUgbG9jYWwgbW9iaWxpdHkgYW5j aG9yLCBiZWZvcmUgYWNjZXB0aW5nIGEgUHJveHkgQmluZGluZyBVcGRhdGUNCiAgIG1lc3NhZ2Ug Zm9yIGEgZ2l2ZW4gbW9iaWxlIG5vZGUsIG1heSBlbnN1cmUgdGhhdCB0aGUgbW9iaWxlIG5vZGUg aXMNCiAgIGF0dGFjaGVkIHRvIHRoZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgdGhhdCBzZW50IHRo ZSBQcm94eSBCaW5kaW5nDQogICBVcGRhdGUgbWVzc2FnZS4NCg0KVGhlIFJGQyBoYXMgbm8gcmVj b21tZW5kYXRpb24gZm9yIGEgc29sdXRpb24sIGJ1dCBiZWNhdXNlIHRoZXJlIGFyZQ0Kbm93IG11 bHRpcGxlIHR1bm5lbHMsIHRoaXMgYXNzdXJhbmNlIG1heSBiZSBtb3JlIGRpZmZpY3VsdCB0byBv YnRhaW4uDQoNCg0KDQogID4+PiBUaGUgdXNlIG9mIG11bHRpcGxlIENvQeKAmXMgb24gdGhlIE1B RyBoYXMgbm8gcmVsYXRpb24gdG8gdGhlIE1BRyBjb21wcm9taXNlIHRocmVhdDogdGhlcmUgYXJl IG11bHRpcGxlIHR1bm5lbHMgYmV0d2VlbiBhIE1BRyBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgTE1B LCBidXQgYSBzaW5nbGUgbGluayBmcm9tIHRoZSBtb2JpbGUgbm9kZSBhbmQgdGhlIE1BRy4gU28s IGZyb20gdGhlIG1vYmlsZSBub2RlIHBlcnNwZWN0aXZlLCB0aGVyZSBpcyBubyBkaWZmZXJlbmNl ICBpbiBjb21wYXJpc29uIHRvIHRoZSBSRkM1MjEzLiBXZSB0aHVzIGhhdmUgdGhlIHNhbWUgY29t cGxleGl0eSB0byBnZXQgYXNzdXJhbmNlIHRoYXQgYSBtb2JpbGUgbm9kZSBpcyBhdHRhY2hlZCB0 byB0aGUg4oCccmlnaHTigJ0gTUFHIGlzIGV4YWN0bHkgdGhlIHNhbWUuDQoNCg0KSXMgdGhlcmUg YW55IHJlYXNvbiB0byB3b3JyeSBhYm91dCByZXVzZSBvZiBDb0FzPyAgQ291bGQgcGFja2V0cyBm cm9tDQpvbmUgdHVubmVsIGdldCBhIENvQSB0aGF0IHdhcyByZWNlbnRseSB1c2VkIGJ5IGFub3Ro ZXIgdHVubmVsLCBhbmQNCmNvdWxkIGRlbGF5ZWQgcGFja2V0cyBnZXQgcm91dGVkIHRocm91Z2gg dGhlIHdyb25nIHR1bm5lbD8gIEp1c3QgYXNraW5nLg0KDQoNCj4+ID4+IHdlbGwsIExNQSBjcmVh dGVzIGEgdHVubmVsIHRvIGEgZ2l2ZW4gQ29BIGFuZCBhZGRzIGEgSG9BIHJvdXRlIG9ubHkgYWZ0 ZXIgYSBQQlUvUEJBIGV4Y2hhbmdlLiBJbiB0aGUgcmFyZSBzY2VuYXJpbyBvZiBhIENvQSBnZXR0 aW5nIG1vdmVkIGJldHdlZW4gTUFH4oCZcywgYW55IHBhY2tldHMgaW4gdHJhbnNpdCB3b3VsZCBo YXZlIGNsZWFyZWQgYXMgdGhlcmUgaXMgYSBQQlUvUEJBIGV4Y2hhbmdlIG5lZWRzIHRvIGhhcHBl biBhbmQgdGhhdCBoYXMgc3VmZmljaWVudCB0aW1lIHRvIGVsaW1pbmF0ZSB0aGUgcG9zc2liaWxp dGllcyByZWxhdGVkIHRvIHJlb3JkZXJpbmcuIFNvLCBub3QgcmVhbGx5IGEgIHdvcnJ5Lg0KDQoN Cg0KU2VudCBmcm9tIG15IGNlbGwgcGhvbmUsIG1pbmQgdGhlIHR5cG9zLg0KDQotLS0tLS0tLSBN ZXNzYWdlIGQnb3JpZ2luZSAtLS0tLS0tLQ0KRGUgOiBLYXRobGVlbiBNb3JpYXJ0eSA8S2F0aGxl ZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQpEYXRlIDogMDEvMDgvMjAxNyAyMjoxMyAoR01U KzAxOjAwKQ0Kw4AgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjIDogZHJhZnQtaWV0Zi1k bW0tbWFnLW11bHRpaG9taW5nQGlldGYub3JnLCBKb3VuaSBLb3Job25lbiA8am91bmkubm9zcGFt QGdtYWlsLmNvbT4sIGRtbS1jaGFpcnNAaWV0Zi5vcmcsIGpvdW5pLm5vc3BhbUBnbWFpbC5jb20s IGRtbUBpZXRmLm9yZw0KT2JqZXQgOiBLYXRobGVlbiBNb3JpYXJ0eSdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiAod2l0aCBESVNDVVNTKQ0KDQpLYXRobGVl biBNb3JpYXJ0eSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN CmRyYWZ0LWlldGYtZG1tLW1hZy1tdWx0aWhvbWluZy0wNDogRGlzY3Vzcw0KDQpXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVl bCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0K DQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBv dGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1tLW1hZy1tdWx0aWhvbWluZy8NCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoYW5rcyBmb3IgeW91 ciB3b3JrIG9uIHRoaXMgZHJhZnQuICBJIGhhZCB0aGUgc2FtZSBjb25jZXJuIGFzIHRoZSBTZWNE aXINCnJldmlld2VyIGluIHJlYWRpbmcgdGhlIGRyYWZ0LCB0aGUgY29uY2VybiBhYm91dCBsZWFr aW5nIHRyYWZmaWMgYXMgYSByZXN1bHQgb2YNCm11bHRpcGxlIHR1bm5lbHMgaXMgbm90IGFkZHJl c3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCkhpbGFyeSdzIHdy aXRldXAgaXMgcXVpdGUgaGVscGZ1bA0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA3NDQ2Lmh0bWwNCg0KDQoNCg0KCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhh bmsgeW91LgoK --_000_011tltohcmw3npknpg1m4xea1501697097442emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <95A6FA7790F75747B66380A2390628A5@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5IZWxsbyBL YXRobGVlbiw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdSdyZSByaWdodC4gLi4g c29ycnkgZm9yIGxhdGUgcmVwbHkgdG8gSGlsYXJ5J3MgY29uY2Vybi4gUGxlYXNlIHNlZSBvdXIg cmVwbHkgYmVsb3cuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzJm5ic3A7 PC9kaXY+DQo8ZGl2PlBpZXJyaWNrICZhbXA7IFNyaSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBkaXI9ImF1dG8iPg0K PGRpdj4NCjxkaXYgbGFuZz0iRlIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDsgZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnRoZXJlIGlzIG9uZSBzZWN1 cml0eSBpc3N1ZSB0aGF0IGlzIG1lbnRpb25lZCBpbiBSRkM1MjEzIHRoYXQ8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aXMgZXhhY2VyYmF0 ZWQgYnkgdGhlIGN1cnJlbnQgZHJhZnQuJm5ic3A7IEkuZS4sPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UbyBhZGRyZXNzIHRo ZSB0aHJlYXQgcmVsYXRlZCB0byBhIGNvbXByb21pc2VkIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSw8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHRoZSBsb2NhbCBtb2JpbGl0eSBhbmNob3IsIGJlZm9yZSBhY2NlcHRpbmcg YSBQcm94eSBCaW5kaW5nIFVwZGF0ZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbWVzc2FnZSBmb3IgYSBnaXZlbiBt b2JpbGUgbm9kZSwgbWF5IGVuc3VyZSB0aGF0IHRoZSBtb2JpbGUgbm9kZSBpczwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgYXR0YWNoZWQgdG8gdGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSB0aGF0IHNlbnQgdGhlIFBy b3h5IEJpbmRpbmc8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFVwZGF0ZSBtZXNzYWdlLjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIFJGQyBo YXMgbm8gcmVjb21tZW5kYXRpb24gZm9yIGEgc29sdXRpb24sIGJ1dCBiZWNhdXNlIHRoZXJlIGFy ZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5ub3cgbXVsdGlwbGUgdHVubmVscywgdGhpcyBhc3N1cmFuY2UgbWF5IGJlIG1vcmUgZGlmZmlj dWx0IHRvIG9idGFpbi48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBXaW5nZGluZ3M7Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA3cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Ij4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij4mbmJzcDsmZ3Q7Jmd0OyZndDsN CiBUaGUgdXNlIG9mIG11bHRpcGxlIENvQeKAmXMgb24gdGhlIE1BRyBoYXMgbm8gcmVsYXRpb24g dG8gdGhlIE1BRyBjb21wcm9taXNlIHRocmVhdDogdGhlcmUgYXJlIG11bHRpcGxlIHR1bm5lbHMg YmV0d2VlbiBhIE1BRyBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgTE1BLCBidXQgYSBzaW5nbGUgbGlu ayBmcm9tIHRoZSBtb2JpbGUgbm9kZSBhbmQgdGhlIE1BRy4gU28sIGZyb20gdGhlIG1vYmlsZSBu b2RlIHBlcnNwZWN0aXZlLCB0aGVyZSBpcyBubyBkaWZmZXJlbmNlDQogJm5ic3A7aW4gY29tcGFy aXNvbiB0byB0aGUgUkZDNTIxMy4gV2UgdGh1cyBoYXZlIHRoZSBzYW1lIGNvbXBsZXhpdHkgdG8g Z2V0IGFzc3VyYW5jZSB0aGF0IGEgbW9iaWxlIG5vZGUgaXMgYXR0YWNoZWQgdG8gdGhlIOKAnHJp Z2h04oCdIE1BRyBpcyBleGFjdGx5IHRoZSBzYW1lLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIGRpcj0i YXV0byI+DQo8ZGl2Pg0KPGRpdiBsYW5nPSJGUiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPiZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JcyB0aGVy ZSBhbnkgcmVhc29uIHRvIHdvcnJ5IGFib3V0IHJldXNlIG9mIENvQXM/Jm5ic3A7IENvdWxkIHBh Y2tldHMgZnJvbTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5vbmUgdHVubmVsIGdldCBhIENvQSB0aGF0IHdhcyByZWNlbnRseSB1c2VkIGJ5 IGFub3RoZXIgdHVubmVsLCBhbmQ8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Y291bGQgZGVsYXllZCBwYWNrZXRzIGdldCByb3V0ZWQgdGhy b3VnaCB0aGUgd3JvbmcgdHVubmVsPyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SnVzdCBhc2tp bmcuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij4m bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0Ij48Zm9udCBmYWNlPSJXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEzLjMzMzNweDsiPiZndDsmZ3Q7ICZndDsmZ3Q7IHdlbGwsJm5ic3A7PC9zcGFuPjwv Zm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTFwdDsiPkxNQSBjcmVhdGVzIGEgdHVubmVsIHRvIGEgZ2l2ZW4gQ29BIGFuZCBhZGRz IGEgSG9BDQogcm91dGUgb25seSBhZnRlciBhIFBCVS9QQkEgZXhjaGFuZ2UuIEluIHRoZSByYXJl IHNjZW5hcmlvIG9mIGEgQ29BIGdldHRpbmcgbW92ZWQgYmV0d2VlbiBNQUfigJlzLCBhbnkgcGFj a2V0cyBpbiB0cmFuc2l0IHdvdWxkIGhhdmUgY2xlYXJlZCBhcyB0aGVyZSBpcyBhIFBCVS9QQkEg ZXhjaGFuZ2UgbmVlZHMgdG8gaGFwcGVuIGFuZCB0aGF0IGhhcyBzdWZmaWNpZW50IHRpbWUgdG8g ZWxpbWluYXRlIHRoZSBwb3NzaWJpbGl0aWVzIHJlbGF0ZWQgdG8NCiByZW9yZGVyaW5nLiBTbywg bm90IHJlYWxseSBhICZuYnNwO3dvcnJ5LiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2IGRpcj0iYXV0byI+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYg aWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9y OiM1NzU3NTciPlNlbnQgZnJvbSBteSBjZWxsIHBob25lLCBtaW5kIHRoZSB0eXBvcy4mbmJzcDs8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTox MDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPg0KPGRpdj4tLS0tLS0t LSBNZXNzYWdlIGQnb3JpZ2luZSAtLS0tLS0tLTwvZGl2Pg0KPGRpdj5EZSA6IEthdGhsZWVuIE1v cmlhcnR5ICZsdDtLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSZndDsgPC9kaXY+DQo8 ZGl2PkRhdGUgOiAwMS8wOC8yMDE3IDIyOjEzIChHTVQmIzQzOzAxOjAwKSA8L2Rpdj4NCjxkaXY+ w4AgOiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDsgPC9kaXY+DQo8ZGl2PkNjIDogZHJh ZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nQGlldGYub3JnLCBKb3VuaSBLb3Job25lbiAmbHQ7 am91bmkubm9zcGFtQGdtYWlsLmNvbSZndDssIGRtbS1jaGFpcnNAaWV0Zi5vcmcsIGpvdW5pLm5v c3BhbUBnbWFpbC5jb20sIGRtbUBpZXRmLm9yZw0KPC9kaXY+DQo8ZGl2Pk9iamV0IDogS2F0aGxl ZW4gTW9yaWFydHkncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZG1tLW1hZy1tdWx0aWhvbWluZy0w NDogKHdpdGggRElTQ1VTUykNCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPkthdGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWlldGYtZG1tLW1hZy1tdWx0aWhvbWluZy0wNDog RGlzY3Vzczxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3NlcyBpbmNs dWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0K aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNl IHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfQkxBTksiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJy Pg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1tLW1hZy1tdWx0aWhvbWluZy8iIHRhcmdldD0i X0JMQU5LIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtbS1t YWctbXVsdGlob21pbmcvPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQpESVNDVVNTOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaGFua3MgZm9yIHlv dXIgd29yayBvbiB0aGlzIGRyYWZ0LiZuYnNwOyBJIGhhZCB0aGUgc2FtZSBjb25jZXJuIGFzIHRo ZSBTZWNEaXI8YnI+DQpyZXZpZXdlciBpbiByZWFkaW5nIHRoZSBkcmFmdCwgdGhlIGNvbmNlcm4g YWJvdXQgbGVha2luZyB0cmFmZmljIGFzIGEgcmVzdWx0IG9mPGJyPg0KbXVsdGlwbGUgdHVubmVs cyBpcyBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u LiA8YnI+DQpIaWxhcnkncyB3cml0ZXVwIGlzIHF1aXRlIGhlbHBmdWw8YnI+DQo8YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50 L21zZzA3NDQ2Lmh0bWwiIHRhcmdldD0iX0JMQU5LIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA3NDQ2Lmh0bWw8L2E+PGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPFBSRT5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_011tltohcmw3npknpg1m4xea1501697097442emailandroidcom_-- From nobody Wed Aug 2 13:23:10 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E41CD131C84; Wed, 2 Aug 2017 13:23:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150170538887.5691.5091031605308391116.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 13:23:08 -0700 Archived-At: Subject: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 20:23:09 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3.2. Traffic distribution schemes "Per-packet management: the LMA and the MAG distribute packets, belonging to a same IP flow, over more than one bindings (i.e. more than one WAN interface)." This immediately made my out-of-order-packets antenna pop up, so I read the section looking for mitigations. The very next sentence reads: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. " -- the fact that this sentence is a: malformed and b: hand-wavy did nothing to allay my concerns, so I read further: "The distribution algorithm is left to implementer but whatever the algorithm is, packets distribution likely introduces packet latency and out-of-order delivery. LMA and MAG shall thus be able to make reordering before packets delivery." - I agree with the first sentence (although it is poorly worded), but the second sentence doesn't follow from the first; "shall thus be able to" implies that the prior text somehow provides a solution, not points out a problem (the sentence is also malformed)-- I think you mean something like "The LMA and MAG thus need to be able reorder packets to their original order before delivery." This then continues with "Sequence number can be can be used for that purpose, for example using GRE with sequence number option [RFC5845]." - I think that the actual reference should be RFC2890, but regardless of this, I don't think that what you are proposing works - "The Sequence Number field is used to maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, emphasis added). This means that sequence numbers are local to the tunnel, and (as I understand it) your solution involves diverse tunnels. Further, Section 2.2. Sequence Number says: "The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number." - if you are proposing using a single sequence number space for multiple tunnels, you will end up with sequence number space gabs, and lots of buffering, etc. The section ends with: "However, more detailed considerations on reordering and IP packet distribution scheme (e.g. definition of packets distribution algorithm) are out the scope of this document." - I think that, unless the prior paragraph is significantly reworked, it should not try and suggest any mitigations. The whole idea of striping packets of a flow across (notably) different transports seems like a really bad idea to me -- is it actually needed? From nobody Wed Aug 2 14:19:11 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E983A13217F; Wed, 2 Aug 2017 14:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3PZjwiBCnzNz; Wed, 2 Aug 2017 14:19:00 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E451E132177; Wed, 2 Aug 2017 14:18:59 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 1D64AC0370; Wed, 2 Aug 2017 23:18:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id C86021A0071; Wed, 2 Aug 2017 23:18:57 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Wed, 2 Aug 2017 23:18:57 +0200 From: To: Warren Kumari , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: RE : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AdML1PMuL0ekOU6ARNSRJXiwSpuVlw== Date: Wed, 2 Aug 2017 21:18:56 +0000 Message-ID: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_p123omkxf24p6fskvw4pi68k1501708734898emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 21:19:02 -0000 --_000_p123omkxf24p6fskvw4pi68k1501708734898emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8NCg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KUGllcnJpY2sNCg0KDQoNClNlbnQgZnJvbSBt eSBjZWxsIHBob25lLCBtaW5kIHRoZSB0eXBvcy4NCg0KLS0tLS0tLS0gTWVzc2FnZSBkJ29yaWdp bmUgLS0tLS0tLS0NCkRlIDogV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+DQpEYXRl IDogMDIvMDgvMjAxNyAyMjoyMyAoR01UKzAxOjAwKQ0Kw4AgOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4NCkNjIDogZHJhZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nQGlldGYub3JnLCBKb3Vu aSBLb3Job25lbiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT4sIGRtbS1jaGFpcnNAaWV0Zi5vcmcs IGpvdW5pLm5vc3BhbUBnbWFpbC5jb20sIGRtbUBpZXRmLm9yZw0KT2JqZXQgOiBXYXJyZW4gS3Vt YXJpJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmctMDQ6ICh3aXRo IERJU0NVU1MpDQoNCldhcnJlbiBLdW1hcmkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmctMDQ6IERpc2N1 c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFu ZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtbS1tYWctbXVs dGlob21pbmcvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpTZWN0aW9uIDMuMi4gIFRyYWZmaWMgZGlzdHJpYnV0aW9uIHNjaGVtZXMNCiJQZXItcGFja2V0 IG1hbmFnZW1lbnQ6IHRoZSBMTUEgYW5kIHRoZSBNQUcgZGlzdHJpYnV0ZSBwYWNrZXRzLCBiZWxv bmdpbmcgdG8gYQ0Kc2FtZSBJUCBmbG93LCBvdmVyIG1vcmUgdGhhbiBvbmUgYmluZGluZ3MgKGku ZS4gbW9yZSB0aGFuIG9uZSBXQU4gaW50ZXJmYWNlKS4iDQpUaGlzIGltbWVkaWF0ZWx5IG1hZGUg bXkgb3V0LW9mLW9yZGVyLXBhY2tldHMgYW50ZW5uYSBwb3AgdXAsIHNvIEkgcmVhZCB0aGUNCnNl Y3Rpb24gbG9va2luZyBmb3IgbWl0aWdhdGlvbnMuIFRoZSB2ZXJ5IG5leHQgc2VudGVuY2UgcmVh ZHM6ICJQYWNrZXQNCmRpc3RyaWJ1dGlvbiBjYW4gYmUgZG9uZSBlaXRoZXIgYXQgdGhlIHRyYW5z cG9ydCBsZXZlbCwgZS5nLiB1c2luZyBNUFRDUCBvciBhdA0KV2hlbiBvcGVyYXRpbmcgYXQgdGhl IElQIHBhY2tldCBsZXZlbCwgZGlmZmVyZW50IHBhY2tldHMgZGlzdHJpYnV0aW9uDQphbGdvcml0 aG1zIGFyZSBwb3NzaWJsZS4gIiAtLSB0aGUgZmFjdCB0aGF0IHRoaXMgc2VudGVuY2UgaXMgYTog bWFsZm9ybWVkIGFuZA0KYjogaGFuZC13YXZ5IGRpZCBub3RoaW5nIHRvIGFsbGF5IG15IGNvbmNl cm5zLCBzbyBJIHJlYWQgZnVydGhlcjogIlRoZQ0KZGlzdHJpYnV0aW9uIGFsZ29yaXRobSBpcyBs ZWZ0IHRvIGltcGxlbWVudGVyIGJ1dCB3aGF0ZXZlciB0aGUgYWxnb3JpdGhtIGlzLA0KcGFja2V0 cyBkaXN0cmlidXRpb24gbGlrZWx5IGludHJvZHVjZXMgcGFja2V0IGxhdGVuY3kgYW5kIG91dC1v Zi1vcmRlcg0KZGVsaXZlcnkuICBMTUEgYW5kIE1BRyBzaGFsbCB0aHVzIGJlIGFibGUgdG8gbWFr ZSByZW9yZGVyaW5nIGJlZm9yZSBwYWNrZXRzDQpkZWxpdmVyeS4iIC0gSSBhZ3JlZSB3aXRoIHRo ZSBmaXJzdCBzZW50ZW5jZSAoYWx0aG91Z2ggaXQgaXMgcG9vcmx5IHdvcmRlZCksDQpidXQgdGhl IHNlY29uZCBzZW50ZW5jZSBkb2Vzbid0IGZvbGxvdyBmcm9tIHRoZSBmaXJzdDsgInNoYWxsIHRo dXMgYmUgYWJsZSB0byINCmltcGxpZXMgdGhhdCB0aGUgcHJpb3IgdGV4dCBzb21laG93IHByb3Zp ZGVzIGEgc29sdXRpb24sIG5vdCBwb2ludHMgb3V0IGENCnByb2JsZW0gKHRoZSBzZW50ZW5jZSBp cyBhbHNvIG1hbGZvcm1lZCktLSBJIHRoaW5rIHlvdSBtZWFuIHNvbWV0aGluZyBsaWtlICJUaGUN CkxNQSBhbmQgTUFHIHRodXMgbmVlZCB0byBiZSBhYmxlIHJlb3JkZXIgcGFja2V0cyB0byB0aGVp ciBvcmlnaW5hbCBvcmRlciBiZWZvcmUNCmRlbGl2ZXJ5LiINCg0KVGhpcyB0aGVuIGNvbnRpbnVl cyB3aXRoICJTZXF1ZW5jZSBudW1iZXIgY2FuIGJlIGNhbiBiZSB1c2VkIGZvciB0aGF0IHB1cnBv c2UsDQpmb3IgZXhhbXBsZSB1c2luZyBHUkUgd2l0aCBzZXF1ZW5jZSBudW1iZXIgb3B0aW9uIFtS RkM1ODQ1XS4iIC0gSSB0aGluayB0aGF0DQp0aGUgYWN0dWFsIHJlZmVyZW5jZSBzaG91bGQgYmUg UkZDMjg5MCwgYnV0IHJlZ2FyZGxlc3Mgb2YgdGhpcywgSSBkb24ndCB0aGluaw0KdGhhdCB3aGF0 IHlvdSBhcmUgcHJvcG9zaW5nIHdvcmtzIC0gIlRoZSBTZXF1ZW5jZSBOdW1iZXIgZmllbGQgaXMg dXNlZCB0bw0KbWFpbnRhaW4gc2VxdWVuY2Ugb2YgcGFja2V0cyAqKndpdGhpbioqIHRoZSBHUkUg VHVubmVsLiIgKGZyb20gUkZDMjg5MCwNCmVtcGhhc2lzIGFkZGVkKS4gVGhpcyBtZWFucyB0aGF0 IHNlcXVlbmNlIG51bWJlcnMgYXJlIGxvY2FsIHRvIHRoZSB0dW5uZWwsIGFuZA0KKGFzIEkgdW5k ZXJzdGFuZCBpdCkgeW91ciBzb2x1dGlvbiBpbnZvbHZlcyBkaXZlcnNlIHR1bm5lbHMuIEZ1cnRo ZXIsIFNlY3Rpb24NCjIuMi4gU2VxdWVuY2UgTnVtYmVyIHNheXM6ICJUaGUgcmVjZWl2ZXIgbWF5 IHBlcmZvcm0gYSBzbWFsbCBhbW91bnQgb2YNCmJ1ZmZlcmluZyBpbiBhbiBhdHRlbXB0IHRvIHJl Y292ZXIgdGhlIG9yaWdpbmFsIHNlcXVlbmNlIG9mIHRyYW5zbWl0dGVkDQpwYWNrZXRzLiBJbiB0 aGlzIGNhc2UsIHRoZSBwYWNrZXQgbWF5IGJlIHBsYWNlZCBpbiBhIGJ1ZmZlciBzb3J0ZWQgYnkg c2VxdWVuY2UNCm51bWJlci4iIC0gaWYgeW91IGFyZSBwcm9wb3NpbmcgdXNpbmcgYSBzaW5nbGUg c2VxdWVuY2UgbnVtYmVyIHNwYWNlIGZvcg0KbXVsdGlwbGUgdHVubmVscywgeW91IHdpbGwgZW5k IHVwIHdpdGggc2VxdWVuY2UgbnVtYmVyIHNwYWNlIGdhYnMsIGFuZCBsb3RzIG9mDQpidWZmZXJp bmcsIGV0Yy4gVGhlIHNlY3Rpb24gZW5kcyB3aXRoOiAiSG93ZXZlciwgbW9yZSBkZXRhaWxlZCBj b25zaWRlcmF0aW9ucw0Kb24gcmVvcmRlcmluZyAgYW5kIElQIHBhY2tldCBkaXN0cmlidXRpb24g c2NoZW1lIChlLmcuIGRlZmluaXRpb24gb2YgcGFja2V0cw0KZGlzdHJpYnV0aW9uIGFsZ29yaXRo bSkgYXJlIG91dCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iIC0gSSB0aGluayB0aGF0LA0K dW5sZXNzIHRoZSBwcmlvciBwYXJhZ3JhcGggaXMgc2lnbmlmaWNhbnRseSByZXdvcmtlZCwgaXQg c2hvdWxkIG5vdCB0cnkgYW5kDQpzdWdnZXN0IGFueSBtaXRpZ2F0aW9ucy4NCg0KPj4gb2sNCg0K VGhlIHdob2xlIGlkZWEgb2Ygc3RyaXBpbmcgcGFja2V0cyBvZiBhIGZsb3cgYWNyb3NzIChub3Rh Ymx5KSBkaWZmZXJlbnQNCnRyYW5zcG9ydHMgc2VlbXMgbGlrZSBhIHJlYWxseSBiYWQgaWRlYSB0 byBtZSAtLSBpcyBpdCBhY3R1YWxseSBuZWVkZWQ/DQoNCj4+IHNvbWUgdXNlLWNhc2VzIGltcGxl bWVudCBwZXItcGFja2V0IGRpc3RyaWJ1dGlvbi4gSG93ZXZlciB0aGlzIGRvY3VtZW50IGRvZXMg bm90IGFpbSB0byBtYWtlIHJlY29tbWVuZGF0aW9uIG9uIHRoZSB3YXkgdG8gZGlzdHJpYnV0ZSBw YWNrZXRzDQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_p123omkxf24p6fskvw4pi68k1501708734898emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <028B50449E638E42A27C8C59DEE0C321@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5IZWxsbyZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGxlYXNlIHNlZSBpbmxpbmU8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBpZXJyaWNrJm5ic3A7PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGlk PSJjb21wb3Nlcl9zaWduYXR1cmUiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjoj NTc1NzU3Ij5TZW50IGZyb20gbXkgY2VsbCBwaG9uZSwgbWluZCB0aGUgdHlwb3MuJm5ic3A7PC9k aXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6MTAw JTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT4NCjxkaXY+LS0tLS0tLS0g TWVzc2FnZSBkJ29yaWdpbmUgLS0tLS0tLS08L2Rpdj4NCjxkaXY+RGUgOiBXYXJyZW4gS3VtYXJp ICZsdDt3YXJyZW5Aa3VtYXJpLm5ldCZndDsgPC9kaXY+DQo8ZGl2PkRhdGUgOiAwMi8wOC8yMDE3 IDIyOjIzIChHTVQmIzQzOzAxOjAwKSA8L2Rpdj4NCjxkaXY+w4AgOiBUaGUgSUVTRyAmbHQ7aWVz Z0BpZXRmLm9yZyZndDsgPC9kaXY+DQo8ZGl2PkNjIDogZHJhZnQtaWV0Zi1kbW0tbWFnLW11bHRp aG9taW5nQGlldGYub3JnLCBKb3VuaSBLb3Job25lbiAmbHQ7am91bmkubm9zcGFtQGdtYWlsLmNv bSZndDssIGRtbS1jaGFpcnNAaWV0Zi5vcmcsIGpvdW5pLm5vc3BhbUBnbWFpbC5jb20sIGRtbUBp ZXRmLm9yZw0KPC9kaXY+DQo8ZGl2Pk9iamV0IDogV2FycmVuIEt1bWFyaSdzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiAod2l0aCBESVNDVVNTKQ0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+V2FycmVuIEt1bWFyaSBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1p ZXRmLWRtbS1tYWctbXVsdGlob21pbmctMDQ6IERpc2N1c3M8YnI+DQo8YnI+DQpXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGw8YnI+DQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4g KEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj4NCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKTxicj4NCjxicj4NCjxicj4NClBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHRhcmdldD0i X0JMQU5LIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp dGVyaWEuaHRtbDwvYT48YnI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxicj4NCjxicj4NCjxicj4NClRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRt bS1tYWctbXVsdGlob21pbmcvIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nLzwvYT48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRElTQ1VTUzo8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KPGJyPg0KU2VjdGlvbiAzLjIuJm5ic3A7IFRyYWZmaWMgZGlzdHJpYnV0aW9uIHNj aGVtZXM8YnI+DQomcXVvdDtQZXItcGFja2V0IG1hbmFnZW1lbnQ6IHRoZSBMTUEgYW5kIHRoZSBN QUcgZGlzdHJpYnV0ZSBwYWNrZXRzLCBiZWxvbmdpbmcgdG8gYTxicj4NCnNhbWUgSVAgZmxvdywg b3ZlciBtb3JlIHRoYW4gb25lIGJpbmRpbmdzIChpLmUuIG1vcmUgdGhhbiBvbmUgV0FOIGludGVy ZmFjZSkuJnF1b3Q7PGJyPg0KVGhpcyBpbW1lZGlhdGVseSBtYWRlIG15IG91dC1vZi1vcmRlci1w YWNrZXRzIGFudGVubmEgcG9wIHVwLCBzbyBJIHJlYWQgdGhlPGJyPg0Kc2VjdGlvbiBsb29raW5n IGZvciBtaXRpZ2F0aW9ucy4gVGhlIHZlcnkgbmV4dCBzZW50ZW5jZSByZWFkczogJnF1b3Q7UGFj a2V0PGJyPg0KZGlzdHJpYnV0aW9uIGNhbiBiZSBkb25lIGVpdGhlciBhdCB0aGUgdHJhbnNwb3J0 IGxldmVsLCBlLmcuIHVzaW5nIE1QVENQIG9yIGF0PGJyPg0KV2hlbiBvcGVyYXRpbmcgYXQgdGhl IElQIHBhY2tldCBsZXZlbCwgZGlmZmVyZW50IHBhY2tldHMgZGlzdHJpYnV0aW9uPGJyPg0KYWxn b3JpdGhtcyBhcmUgcG9zc2libGUuICZxdW90OyAtLSB0aGUgZmFjdCB0aGF0IHRoaXMgc2VudGVu Y2UgaXMgYTogbWFsZm9ybWVkIGFuZDxicj4NCmI6IGhhbmQtd2F2eSBkaWQgbm90aGluZyB0byBh bGxheSBteSBjb25jZXJucywgc28gSSByZWFkIGZ1cnRoZXI6ICZxdW90O1RoZTxicj4NCmRpc3Ry aWJ1dGlvbiBhbGdvcml0aG0gaXMgbGVmdCB0byBpbXBsZW1lbnRlciBidXQgd2hhdGV2ZXIgdGhl IGFsZ29yaXRobSBpcyw8YnI+DQpwYWNrZXRzIGRpc3RyaWJ1dGlvbiBsaWtlbHkgaW50cm9kdWNl cyBwYWNrZXQgbGF0ZW5jeSBhbmQgb3V0LW9mLW9yZGVyPGJyPg0KZGVsaXZlcnkuJm5ic3A7IExN QSBhbmQgTUFHIHNoYWxsIHRodXMgYmUgYWJsZSB0byBtYWtlIHJlb3JkZXJpbmcgYmVmb3JlIHBh Y2tldHM8YnI+DQpkZWxpdmVyeS4mcXVvdDsgLSBJIGFncmVlIHdpdGggdGhlIGZpcnN0IHNlbnRl bmNlIChhbHRob3VnaCBpdCBpcyBwb29ybHkgd29yZGVkKSw8YnI+DQpidXQgdGhlIHNlY29uZCBz ZW50ZW5jZSBkb2Vzbid0IGZvbGxvdyBmcm9tIHRoZSBmaXJzdDsgJnF1b3Q7c2hhbGwgdGh1cyBi ZSBhYmxlIHRvJnF1b3Q7PGJyPg0KaW1wbGllcyB0aGF0IHRoZSBwcmlvciB0ZXh0IHNvbWVob3cg cHJvdmlkZXMgYSBzb2x1dGlvbiwgbm90IHBvaW50cyBvdXQgYTxicj4NCnByb2JsZW0gKHRoZSBz ZW50ZW5jZSBpcyBhbHNvIG1hbGZvcm1lZCktLSBJIHRoaW5rIHlvdSBtZWFuIHNvbWV0aGluZyBs aWtlICZxdW90O1RoZTxicj4NCkxNQSBhbmQgTUFHIHRodXMgbmVlZCB0byBiZSBhYmxlIHJlb3Jk ZXIgcGFja2V0cyB0byB0aGVpciBvcmlnaW5hbCBvcmRlciBiZWZvcmU8YnI+DQpkZWxpdmVyeS4m cXVvdDs8YnI+DQo8YnI+DQpUaGlzIHRoZW4gY29udGludWVzIHdpdGggJnF1b3Q7U2VxdWVuY2Ug bnVtYmVyIGNhbiBiZSBjYW4gYmUgdXNlZCBmb3IgdGhhdCBwdXJwb3NlLDxicj4NCmZvciBleGFt cGxlIHVzaW5nIEdSRSB3aXRoIHNlcXVlbmNlIG51bWJlciBvcHRpb24gW1JGQzU4NDVdLiZxdW90 OyAtIEkgdGhpbmsgdGhhdDxicj4NCnRoZSBhY3R1YWwgcmVmZXJlbmNlIHNob3VsZCBiZSBSRkMy ODkwLCBidXQgcmVnYXJkbGVzcyBvZiB0aGlzLCBJIGRvbid0IHRoaW5rPGJyPg0KdGhhdCB3aGF0 IHlvdSBhcmUgcHJvcG9zaW5nIHdvcmtzIC0gJnF1b3Q7VGhlIFNlcXVlbmNlIE51bWJlciBmaWVs ZCBpcyB1c2VkIHRvPGJyPg0KbWFpbnRhaW4gc2VxdWVuY2Ugb2YgcGFja2V0cyAqKndpdGhpbioq IHRoZSBHUkUgVHVubmVsLiZxdW90OyAoZnJvbSBSRkMyODkwLDxicj4NCmVtcGhhc2lzIGFkZGVk KS4gVGhpcyBtZWFucyB0aGF0IHNlcXVlbmNlIG51bWJlcnMgYXJlIGxvY2FsIHRvIHRoZSB0dW5u ZWwsIGFuZDxicj4NCihhcyBJIHVuZGVyc3RhbmQgaXQpIHlvdXIgc29sdXRpb24gaW52b2x2ZXMg ZGl2ZXJzZSB0dW5uZWxzLiBGdXJ0aGVyLCBTZWN0aW9uPGJyPg0KMi4yLiBTZXF1ZW5jZSBOdW1i ZXIgc2F5czogJnF1b3Q7VGhlIHJlY2VpdmVyIG1heSBwZXJmb3JtIGEgc21hbGwgYW1vdW50IG9m PGJyPg0KYnVmZmVyaW5nIGluIGFuIGF0dGVtcHQgdG8gcmVjb3ZlciB0aGUgb3JpZ2luYWwgc2Vx dWVuY2Ugb2YgdHJhbnNtaXR0ZWQ8YnI+DQpwYWNrZXRzLiBJbiB0aGlzIGNhc2UsIHRoZSBwYWNr ZXQgbWF5IGJlIHBsYWNlZCBpbiBhIGJ1ZmZlciBzb3J0ZWQgYnkgc2VxdWVuY2U8YnI+DQpudW1i ZXIuJnF1b3Q7IC0gaWYgeW91IGFyZSBwcm9wb3NpbmcgdXNpbmcgYSBzaW5nbGUgc2VxdWVuY2Ug bnVtYmVyIHNwYWNlIGZvcjxicj4NCm11bHRpcGxlIHR1bm5lbHMsIHlvdSB3aWxsIGVuZCB1cCB3 aXRoIHNlcXVlbmNlIG51bWJlciBzcGFjZSBnYWJzLCBhbmQgbG90cyBvZjxicj4NCmJ1ZmZlcmlu ZywgZXRjLiBUaGUgc2VjdGlvbiBlbmRzIHdpdGg6ICZxdW90O0hvd2V2ZXIsIG1vcmUgZGV0YWls ZWQgY29uc2lkZXJhdGlvbnM8YnI+DQpvbiByZW9yZGVyaW5nJm5ic3A7IGFuZCBJUCBwYWNrZXQg ZGlzdHJpYnV0aW9uIHNjaGVtZSAoZS5nLiBkZWZpbml0aW9uIG9mIHBhY2tldHM8YnI+DQpkaXN0 cmlidXRpb24gYWxnb3JpdGhtKSBhcmUgb3V0IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiZx dW90OyAtIEkgdGhpbmsgdGhhdCw8YnI+DQp1bmxlc3MgdGhlIHByaW9yIHBhcmFncmFwaCBpcyBz aWduaWZpY2FudGx5IHJld29ya2VkLCBpdCBzaG91bGQgbm90IHRyeSBhbmQ8YnI+DQpzdWdnZXN0 IGFueSBtaXRpZ2F0aW9ucy48L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPiZndDsmZ3Q7IG9rPGJyPg0KPGJyPg0KVGhlIHdo b2xlIGlkZWEgb2Ygc3RyaXBpbmcgcGFja2V0cyBvZiBhIGZsb3cgYWNyb3NzIChub3RhYmx5KSBk aWZmZXJlbnQ8YnI+DQp0cmFuc3BvcnRzIHNlZW1zIGxpa2UgYSByZWFsbHkgYmFkIGlkZWEgdG8g bWUgLS0gaXMgaXQgYWN0dWFsbHkgbmVlZGVkPzxicj4NCjxicj4NCiZndDsmZ3Q7IHNvbWUgdXNl LWNhc2VzIGltcGxlbWVudCBwZXItcGFja2V0IGRpc3RyaWJ1dGlvbi4gSG93ZXZlciB0aGlzIGRv Y3VtZW50IGRvZXMgbm90IGFpbSB0byBtYWtlIHJlY29tbWVuZGF0aW9uIG9uIHRoZSB3YXkgdG8g ZGlzdHJpYnV0ZSBwYWNrZXRzJm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+ PC9mb250Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_p123omkxf24p6fskvw4pi68k1501708734898emailandroidcom_-- From nobody Wed Aug 2 15:14:17 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B5D131C9D; Wed, 2 Aug 2017 15:14:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150171204983.5743.7998947846703116776.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 15:14:09 -0700 Archived-At: Subject: [DMM] Ben Campbell's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 22:14:10 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few editorial comments/nits: - There are several acronyms that should be expanded on first mention. (including at least a couple that are expanded on _second_ mention (MAG and LMA). - 3.2, "Per-packet management" bullet: The second sentence does not make sense. - 3.2, last paragraph: Are we really talking about the latency introduced by per-packet management, or jitter (i.e. variation in latency)? - 4.1, definition of "Interface Label": This doesn't really define the term "interface label". It talks about how it is used, but not what it represents. From nobody Wed Aug 2 16:38:12 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFF4131CD5 for ; Wed, 2 Aug 2017 16:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAquLkO2zOol for ; Wed, 2 Aug 2017 16:38:07 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B16D12EAF0 for ; Wed, 2 Aug 2017 16:38:07 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id g189so23671125vke.5 for ; Wed, 02 Aug 2017 16:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l0s18xwK0GGZNlfBZvYJYDNhh6TwFCHIHkquNke2/SA=; b=pubPmRl/JlEn1R3USD/ILzydImip+4eSlcb+TwiDwPtKrO/Dge70/vgaXX0hkVJPN5 /o5eEDB5AZkFWwj9w4oC9E1A1QvKQ9GvfNLOHLUUkScQBUqhKk7vknlYOYZGxG5OAhFp mhhvqk+4E9fVs12L5WEF9t/tqKZ00e3gQu+wCNa5kY+cuhAzOY3F/4VlJr6Dho+o3SmY 3Us43HmoFga6O+X0HgBeQ3HuQIFiMapaKpOc3PNceaWj4U3nByvTkKmDcIBv5nV2ntEp dpTwM1P1EPGOXsGDFk1dktnDRtakn2A3vEXp8TKh9HMSG3XOko7DImT0Q61x6A4KJ3o7 Rviw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l0s18xwK0GGZNlfBZvYJYDNhh6TwFCHIHkquNke2/SA=; b=rS6JbEadoOOqhXxmztZTZcLcMjscrm84YLFnP+b75pqXDEIVy7QgVssLFstm0w5Eej AAyweZulGmNrlDPiy7d3t0jVo+qgmOYNp31lD0WoQnUuD4qqMkd86ZXIqH2ANP9eZmBU zkml77ouL3kafY9S/irlVHywRfu0YcvXgMf0UIuUZaoKXJSCIZIBHhN5zHb6TDX6PwGu 5a8DVQz2DHofVnsZZPkwCMCyn/gleG4BOB+9Ea9AcR8HAlWjAfHnfw8rB9aeUtKu7+Sr h3rmhk1UMuMcX35eRROVVgqYh1rRMq0PCVS9HFNgRrknIlKomxKAzeWnGtb0jraxanMS LOnQ== X-Gm-Message-State: AIVw1114p9cNsM/XmsEo+B8mcxu3+ZI3RMiF0P0w5sCksN3WgRqeZodT sNH3tKraSxPZDBbJWusTU3VAda9bt4In X-Received: by 10.31.157.199 with SMTP id g190mr12281573vke.156.1501717086071; Wed, 02 Aug 2017 16:38:06 -0700 (PDT) MIME-Version: 1.0 References: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> In-Reply-To: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> From: Warren Kumari Date: Wed, 02 Aug 2017 23:37:55 +0000 Message-ID: To: The IESG , pierrick.seite@orange.com Cc: Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" , "draft-ietf-dmm-mag-multihoming@ietf.org" Content-Type: multipart/alternative; boundary="001a11425c147805570555cdc112" Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:38:11 -0000 --001a11425c147805570555cdc112 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 2, 2017 at 5:18 PM wrote: > Hello > > Please see inline > > Pierrick > > > > Sent from my cell phone, mind the typos. > > -------- Message d'origine -------- > De : Warren Kumari > Date : 02/08/2017 22:23 (GMT+01:00) > =C3=80 : The IESG > Cc : draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen < > jouni.nospam@gmail.com>, dmm-chairs@ietf.org, jouni.nospam@gmail.com, > dmm@ietf.org > Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: > (with DISCUSS) > > Warren Kumari has entered the following ballot position for > draft-ietf-dmm-mag-multihoming-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 3.2. Traffic distribution schemes > "Per-packet management: the LMA and the MAG distribute packets, belonging > to a > same IP flow, over more than one bindings (i.e. more than one WAN > interface)." > This immediately made my out-of-order-packets antenna pop up, so I read t= he > section looking for mitigations. The very next sentence reads: "Packet > distribution can be done either at the transport level, e.g. using MPTCP > or at > When operating at the IP packet level, different packets distribution > algorithms are possible. " -- the fact that this sentence is a: malformed > and > b: hand-wavy did nothing to allay my concerns, so I read further: "The > distribution algorithm is left to implementer but whatever the algorithm > is, > packets distribution likely introduces packet latency and out-of-order > delivery. LMA and MAG shall thus be able to make reordering before packe= ts > delivery." - I agree with the first sentence (although it is poorly > worded), > but the second sentence doesn't follow from the first; "shall thus be abl= e > to" > implies that the prior text somehow provides a solution, not points out a > problem (the sentence is also malformed)-- I think you mean something lik= e > "The > LMA and MAG thus need to be able reorder packets to their original order > before > delivery." > > This then continues with "Sequence number can be can be used for that > purpose, > for example using GRE with sequence number option [RFC5845]." - I think > that > the actual reference should be RFC2890, but regardless of this, I don't > think > that what you are proposing works - "The Sequence Number field is used to > maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, > emphasis added). This means that sequence numbers are local to the tunnel= , > and > (as I understand it) your solution involves diverse tunnels. Further, > Section > 2.2. Sequence Number says: "The receiver may perform a small amount of > buffering in an attempt to recover the original sequence of transmitted > packets. In this case, the packet may be placed in a buffer sorted by > sequence > number." - if you are proposing using a single sequence number space for > multiple tunnels, you will end up with sequence number space gabs, and > lots of > buffering, etc. The section ends with: "However, more detailed > considerations > on reordering and IP packet distribution scheme (e.g. definition of > packets > distribution algorithm) are out the scope of this document." - I think > that, > unless the prior paragraph is significantly reworked, it should not try a= nd > suggest any mitigations. > > >> ok > > > The whole idea of striping packets of a flow across (notably) different > transports seems like a really bad idea to me -- is it actually needed? > > >> some use-cases implement per-packet distribution. However this documen= t > does not aim to make recommendation on the way to distribute packets > > So, how do they deal with out of order packets? W > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11425c147805570555cdc112 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Aug 2, 2017 a= t 5:18 PM <pierrick.seite@o= range.com> wrote:
Hello=C2=A0

Please see inline

Pierrick=C2=A0



Sent from my cell phone, mind th= e typos.=C2=A0

-------- Message d'origine --------
De : Warren Kumari <warren@kumari.net>
Date : 02/08/2017 22:23 (GMT+01:00)
=C3=80 : The IESG <iesg@ietf.org>
Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-= 04: (with DISCUSS)

Warren Kumari has entered th= e following ballot position for
draft-ietf-dmm-mag-multihoming-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-mul= tihoming/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 3.2.=C2=A0 Traffic distribution schemes
"Per-packet management: the LMA and the MAG distribute packets, belong= ing to a
same IP flow, over more than one bindings (i.e. more than one WAN interface= )."
This immediately made my out-of-order-packets antenna pop up, so I read the=
section looking for mitigations. The very next sentence reads: "Packet=
distribution can be done either at the transport level, e.g. using MPTCP or= at
When operating at the IP packet level, different packets distribution
algorithms are possible. " -- the fact that this sentence is a: malfor= med and
b: hand-wavy did nothing to allay my concerns, so I read further: "The=
distribution algorithm is left to implementer but whatever the algorithm is= ,
packets distribution likely introduces packet latency and out-of-order
delivery.=C2=A0 LMA and MAG shall thus be able to make reordering before pa= ckets
delivery." - I agree with the first sentence (although it is poorly wo= rded),
but the second sentence doesn't follow from the first; "shall thus= be able to"
implies that the prior text somehow provides a solution, not points out a problem (the sentence is also malformed)-- I think you mean something like = "The
LMA and MAG thus need to be able reorder packets to their original order be= fore
delivery."

This then continues with "Sequence number can be can be used for that = purpose,
for example using GRE with sequence number option [RFC5845]." - I thin= k that
the actual reference should be RFC2890, but regardless of this, I don't= think
that what you are proposing works - "The Sequence Number field is used= to
maintain sequence of packets **within** the GRE Tunnel." (from RFC2890= ,
emphasis added). This means that sequence numbers are local to the tunnel, = and
(as I understand it) your solution involves diverse tunnels. Further, Secti= on
2.2. Sequence Number says: "The receiver may perform a small amount of=
buffering in an attempt to recover the original sequence of transmitted
packets. In this case, the packet may be placed in a buffer sorted by seque= nce
number." - if you are proposing using a single sequence number space f= or
multiple tunnels, you will end up with sequence number space gabs, and lots= of
buffering, etc. The section ends with: "However, more detailed conside= rations
on reordering=C2=A0 and IP packet distribution scheme (e.g. definition of p= ackets
distribution algorithm) are out the scope of this document." - I think= that,
unless the prior paragraph is significantly reworked, it should not try and=
suggest any mitigations.

>> ok


The whole idea of striping packets of a flow across (notably) different
transports seems like a really bad idea to me -- is it actually needed?

>> some use-cases implement per-packet distribution. However this doc= ument does not aim to make recommendation on the way to distribute packets= =C2=A0


So, how do they deal with out of order packets?
W


 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s 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 inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--
I don't think the executi= on is relevant when it was obviously a bad idea in the first place.
This= is like putting rabid weasels in your pants, and later expressing regret a= t having chosen those particular rabid weasels and that pair of pants.
= =C2=A0 =C2=A0---maf
--001a11425c147805570555cdc112-- From nobody Thu Aug 3 01:00:48 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F138131C31; Thu, 3 Aug 2017 01:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 ek6RPOIIJBgc; Thu, 3 Aug 2017 01:00:39 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0091124234; Thu, 3 Aug 2017 01:00:38 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 3E5341808A3; Thu, 3 Aug 2017 10:00:36 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id EE5921A0073; Thu, 3 Aug 2017 10:00:35 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0352.000; Thu, 3 Aug 2017 10:00:34 +0200 From: To: Warren Kumari , The IESG CC: Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" , "draft-ietf-dmm-mag-multihoming@ietf.org" Thread-Topic: RE : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AdML1PMuL0ekOU6ARNSRJXiwSpuVlwAAqaeAABUXxjA= Date: Thu, 3 Aug 2017 08:00:34 +0000 Message-ID: <81C77F07008CA24F9783A98CFD706F713AA91258@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01D30C3F.552C0EA0" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:00:41 -0000 ------=_NextPart_000_000D_01D30C3F.552C0EA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01D30C3F.552C0EA0" ------=_NextPart_001_000E_01D30C3F.552C0EA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 De : Warren Kumari [mailto:warren@kumari.net]=20 Envoy=C3=A9 : jeudi 3 ao=C3=BBt 2017 01:38 =C3=80 : The IESG; SEITE Pierrick IMT/OLN Cc : Jouni Korhonen; dmm-chairs@ietf.org; dmm@ietf.org; = draft-ietf-dmm-mag-multihoming@ietf.org Objet : Re: RE : Warren Kumari's Discuss on = draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) =20 =20 On Wed, Aug 2, 2017 at 5:18 PM wrote: Hello=20 =20 Please see inline =20 Pierrick=20 =20 =20 =20 Sent from my cell phone, mind the typos.=20 =20 -------- Message d'origine -------- De : Warren Kumari =20 Date : 02/08/2017 22:23 (GMT+01:00)=20 =C3=80 : The IESG =20 Cc : draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen = , dmm-chairs@ietf.org, jouni.nospam@gmail.com, = dmm@ietf.org=20 Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: = (with DISCUSS)=20 =20 Warren Kumari has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3.2. Traffic distribution schemes "Per-packet management: the LMA and the MAG distribute packets, = belonging to a same IP flow, over more than one bindings (i.e. more than one WAN = interface)." This immediately made my out-of-order-packets antenna pop up, so I read = the section looking for mitigations. The very next sentence reads: "Packet distribution can be done either at the transport level, e.g. using MPTCP = or at When operating at the IP packet level, different packets distribution algorithms are possible. " -- the fact that this sentence is a: = malformed and b: hand-wavy did nothing to allay my concerns, so I read further: "The distribution algorithm is left to implementer but whatever the algorithm = is, packets distribution likely introduces packet latency and out-of-order delivery. LMA and MAG shall thus be able to make reordering before = packets delivery." - I agree with the first sentence (although it is poorly = worded), but the second sentence doesn't follow from the first; "shall thus be = able to" implies that the prior text somehow provides a solution, not points out = a problem (the sentence is also malformed)-- I think you mean something = like "The LMA and MAG thus need to be able reorder packets to their original order = before delivery." This then continues with "Sequence number can be can be used for that = purpose, for example using GRE with sequence number option [RFC5845]." - I think = that the actual reference should be RFC2890, but regardless of this, I don't = think that what you are proposing works - "The Sequence Number field is used = to maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, emphasis added). This means that sequence numbers are local to the = tunnel, and (as I understand it) your solution involves diverse tunnels. Further, = Section 2.2. Sequence Number says: "The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by = sequence number." - if you are proposing using a single sequence number space for multiple tunnels, you will end up with sequence number space gabs, and = lots of buffering, etc. The section ends with: "However, more detailed = considerations on reordering and IP packet distribution scheme (e.g. definition of = packets distribution algorithm) are out the scope of this document." - I think = that, unless the prior paragraph is significantly reworked, it should not try = and suggest any mitigations. =20 >> ok The whole idea of striping packets of a flow across (notably) different transports seems like a really bad idea to me -- is it actually needed? >> some use-cases implement per-packet distribution. However this = document does not aim to make recommendation on the way to distribute = packets=20 =20 So, how do they deal with out of order packets? =20 >> AFAIK, it is implementation specific and depends on the use-case: = some implementation relies on MPTCP, some others have proprietary = mechanisms adding sequence numbers to the tunneled packet. Sometimes, if = only some specific application are supposed to take benefit of the = aggregation, reordering is only managed at the application layer.=20 =20 W =20 =20 _________________________________________________________________________= ________________________________________________ =20 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. =20 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. --=20 I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. ---maf ------=_NextPart_001_000E_01D30C3F.552C0EA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

<= o:p> 

<= o:p> 

De : Warren = Kumari [mailto:warren@kumari.net]
Envoy=C3=A9 : jeudi 3 = ao=C3=BBt 2017 01:38
=C3=80 : The IESG; SEITE Pierrick = IMT/OLN
Cc : Jouni Korhonen; dmm-chairs@ietf.org; = dmm@ietf.org; = draft-ietf-dmm-mag-multihoming@ietf.org
Objet : Re: RE : = Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with = DISCUSS)

 

 

On = Wed, Aug 2, 2017 at 5:18 PM <pierrick.seite@orange.com&g= t; wrote:

Hello 

 

Please see inline

 

Pierrick 

 

 

 

Sent = from my cell phone, mind the = typos. 

 

-------- Message d'origine = --------

De : Warren Kumari <warren@kumari.net> =

Date : 02/08/2017 22:23 (GMT+01:00) =

=C3=80 : The IESG <iesg@ietf.org> =

Objet : Warren Kumari's Discuss on = draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) =

 

=

Warren Kumari = has entered the following ballot position = for
draft-ietf-dmm-mag-multihoming-04: Discuss

When = responding, please keep the subject line intact and reply to = all
email addresses included in the To and CC lines. (Feel free to = cut this
introductory paragraph, however.)


Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
for more information about IESG DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-mul= tihoming/



--------------------------------------------= --------------------------
DISCUSS:
-------------------------------= ---------------------------------------

Section 3.2.  = Traffic distribution schemes
"Per-packet management: the LMA and = the MAG distribute packets, belonging to a
same IP flow, over more = than one bindings (i.e. more than one WAN interface)."
This = immediately made my out-of-order-packets antenna pop up, so I read = the
section looking for mitigations. The very next sentence reads: = "Packet
distribution can be done either at the transport level, = e.g. using MPTCP or at
When operating at the IP packet level, = different packets distribution
algorithms are possible. " -- the = fact that this sentence is a: malformed and
b: hand-wavy did nothing = to allay my concerns, so I read further: "The
distribution = algorithm is left to implementer but whatever the algorithm = is,
packets distribution likely introduces packet latency and = out-of-order
delivery.  LMA and MAG shall thus be able to make = reordering before packets
delivery." - I agree with the first = sentence (although it is poorly worded),
but the second sentence = doesn't follow from the first; "shall thus be able = to"
implies that the prior text somehow provides a solution, not = points out a
problem (the sentence is also malformed)-- I think you = mean something like "The
LMA and MAG thus need to be able = reorder packets to their original order = before
delivery."

This then continues with "Sequence = number can be can be used for that purpose,
for example using GRE = with sequence number option [RFC5845]." - I think that
the = actual reference should be RFC2890, but regardless of this, I don't = think
that what you are proposing works - "The Sequence Number = field is used to
maintain sequence of packets **within** the GRE = Tunnel." (from RFC2890,
emphasis added). This means that = sequence numbers are local to the tunnel, and
(as I understand it) = your solution involves diverse tunnels. Further, Section
2.2. = Sequence Number says: "The receiver may perform a small amount = of
buffering in an attempt to recover the original sequence of = transmitted
packets. In this case, the packet may be placed in a = buffer sorted by sequence
number." - if you are proposing using = a single sequence number space for
multiple tunnels, you will end up = with sequence number space gabs, and lots of
buffering, etc. The = section ends with: "However, more detailed considerations
on = reordering  and IP packet distribution scheme (e.g. definition of = packets
distribution algorithm) are out the scope of this = document." - I think that,
unless the prior paragraph is = significantly reworked, it should not try and
suggest any = mitigations.

 

<= div>

>> = ok



The whole idea of striping packets of = a flow across (notably) different
transports seems like a really bad = idea to me -- is it actually = needed?

>> = some use-cases implement per-packet distribution. However this document = does not aim to make recommendation on the way to distribute = packets 

 

So, how do they deal with out of order = packets?

<= o:p> 

&= gt;> AFAIK, it is implementation specific and depends on the = use-case: some implementation relies on MPTCP, some others have = proprietary mechanisms adding sequence numbers to the tunneled packet. = Sometimes, if only some specific application are supposed to take = benefit of the aggregation, reordering is only managed =C2=A0at the = application layer.

<= o:p> 

W

 

 

_______=
_________________________________________________________________________=
_________________________________________
 =
;
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.

--

I = don't think the execution is relevant when it was obviously a bad idea = in the first place.
This is like putting rabid weasels in your pants, = and later expressing regret at having chosen those particular rabid = weasels and that pair of pants.
  =  ---maf

------=_NextPart_001_000E_01D30C3F.552C0EA0-- ------=_NextPart_000_000D_01D30C3F.552C0EA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPmDCCA8cw ggKvoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwajELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5j ZSBUZWxlY29tIFNBMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEmMCQGA1UEAwwdR3JvdXBlIEZy YW5jZSBUZWxlY29tIFJvb3QgQ0EwHhcNMDUxMTE0MTIzNDA2WhcNMzUxMTE0MTIzNDA2WjBqMQsw CQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExFzAVBgNVBAsMDjAwMDIgMzgw MTI5ODY2MSYwJAYDVQQDDB1Hcm91cGUgRnJhbmNlIFRlbGVjb20gUm9vdCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALQPGHWb9eHSLKjwqhQqzRVp6jtyzl3L7igdDM8Kqksd7swc vjhKgx3j4bONtboJhUB/0XwJ8pQsRn3WCFZYCWLumRIf/mnzpzYdRJ1lTF3Gj5Q+4B1uyI97nEAf PfnTP+iass5sAYvorqOWjBqRYq9ztCR1mi7KsAbClk9vBtzf6tvVoNRHeABRpmMXDCnxa2ds+iRd 5OO4iuPUYmKgXqpQKMa3e1CBpZLnMvtnwA9aGDwZgtKEjCHxWEYWq5zBbQlqVCauf8D3o9z3Jq8P 470RSrI2pOHuklmLV3975UECIfj01Ke7DadLrPsD3+vrh7ZT2FykZRd+Y8QUzSsL/7kCAwEAAaN4 MHYwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBqSU8jPMxu28qVg feKvJBJBsJpgMB8GA1UdIwQYMBaAFBqSU8jPMxu28qVgfeKvJBJBsJpgMBMGA1UdIAQMMAowCAYG KoF6ARAMMA0GCSqGSIb3DQEBBQUAA4IBAQCDEc4ZDIFeaQATFc8DOiunh+89khLzcWCrV/77E3zG pNLIh+gns5rSfWl8plGdny3mVvMn75AH5/9DLg+527FVt8RkuOcPv0lsJaTwwr9c07RW197WHwFM kEoJO5O9MtF80kCqm96DciEnAt8LRlC6M2TXG5heqtOxps8KqyHpDjtv2SF2DQSMtVfXEurPZFbE tEaey364tpxK3m2FgA2SRZY8524Is8FonSmg6lSw8wY/P0LVwrO0rpJCTyi8BJuZ5Cdxf5iUyszU cDPJaBDTnw/p7VHOlS7XWlNBmiFWwBhlbZu1Aa+jphRJrcJ/f8wUD7dX88dyzsRsVas7cH3cMIIF AjCCA+qgAwIBAgIBATANBgkqhkiG9w0BAQUFADBqMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJh bmNlIFRlbGVjb20gU0ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5ODY2MSYwJAYDVQQDDB1Hcm91cGUg RnJhbmNlIFRlbGVjb20gUm9vdCBDQTAeFw0xMTA2MDgxMDAzMTJaFw0yNTExMTcxMDAzMTJaMIGW MQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rl cm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMM I0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsPMrb/9/950vF5H63795Vqp8uBndVfHlTk+wdFsXyTKn1j27tGqHOFknEYai IQB+tRpn2un9wFavqNz6bYyeOfZDKfwAmnkafAxc1u4jRZv0H3ZPNVfXVS1x7G2MFlN+94/5LMdU pppN77KuH1mqXgDi33bO9CjuEVj/2FUpjqwBVTIqleJfX+mvhvC69rTmZFml/t729xxOpgxt5Wt2 OlQ6VaYqEq8+tSj2/KS8joO07oYSMTikzTXnxHA8BSsfc31SWsfjx4+sxmxc3RhDFnscBkot0l5I AFevwiTbQhx1xNjqa1nN9CYgmNfBpLz60YDtVwUqsdMQyGpvlqRIfwIDAQABo4IBhDCCAYAwDwYD VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDYcM2fTE1z6W5/qi7pEZnRG 8Xd4MHQGA1UdIwRtMGuAFBqSU8jPMxu28qVgfeKvJBJBsJpgoVCBTkNOPUdyb3VwZSBGcmFuY2Ug VGVsZWNvbSBSb290IENBLCBPVT0wMDAyIDM4MDEyOTg2NiwgTz1GcmFuY2UgVGVsZWNvbSBTQSwg Qz1GUoIBADB8BgNVHR8EdTBzMDOgMaAvhi1odHRwOi8vcGtpLWNybC5pdG4uZnRncm91cC9jcmwv aWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNhLmZyYW5jZXRlbGVjb20uY29t L2NybC9pZ2NnZnRfcmNhLmNybDBKBgNVHSAEQzBBMD8GByqBegEQDAIwNDAyBggrBgEFBQcCARYm aHR0cDovL2lnY2dmdC1yY2EuZnJhbmNldGVsZWNvbS5jb20vcGMwDQYJKoZIhvcNAQEFBQADggEB AAYnlAZbNOHSm110Res4plYBlKidMGviiMNUD6x/Ffgx5wAHq2ze+fxSJ9OFB5VoppVYxr+rH3ys eTSpIEGyj6rrlBc5wA9mrH8mOyBJvYrUprWyjmxi8c7FA9vHv5Np1/ARHl/Pwlyp3bBY/Sol6ltH lclR1lVtOSsjrRrch2C+THDcg+axS5Uu+RLofzxio9W159rjLnRku2UgTyZr7bkeI5BnTw35MmfI cJ3yvDZ91rduKPCLwm0UZHaoIm8FM8R5sxl6Bs0oheoKcY7T/RZ8HLVdPXGntKu9PPFm5sOEAV/f R3OsIQcUsEFUtYwqqkYpoxWXKF2ggfM2boaBWE0wggbDMIIFq6ADAgECAhIRIdsSSQ2RowRsC5q9 SdyGFvUwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVs ZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4w MDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwHhcNMTYxMTEwMTUyOTQ3WhcNMjAxMTEwMTUyOTQ3WjBsMQswCQYDVQQGEwJGUjEaMBgGA1UE ChMRRnJhbmNlIFRlbGVjb20gU0ExFzAVBgNVBAMMDlNlaXRlIFBpZXJyaWNrMSgwJgYJKoZIhvcN AQkBDBlwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAx+8AqQCVr92UckX7U15KZ0vDtil2hHlap9fccx9ieTVGSIHXclF7U9XQeLOcNpno7Wh1 P1pqZdj9hf41fnpT2aisvqvCs7mL3Ee4tofq3btoOu9suHfCnAjN06uaNuJj3oburKLbczq3EHK5 yqfOi1NUvhRbuXnD0q+FLm/qX4mw5GlTCT3qJc3Z0XWpSAtaE9YHcMHas8AbX5+e1sP2+uEXA4Qw iHmkK3EaDunpNHM1ea4dkkbve9STrgX/DO/TxlOkHt1hO2xMUtr/p1qCbuuHqVutCv94YRmkDn+6 tbp8v/01hAX1i37PGEbJc+GmY2c5NfkP9cn8gTsL7Y9Y3QIDAQABo4IDMjCCAy4wDgYDVR0PAQH/ BAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGXBpZXJyaWNrLnNlaXRlQG9y YW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB6KCB5aCB4oaB32xkYXA6Ly8vY249R3JvdXBlJTIw RnJhbmNlJTIwVGVsZWNvbSUyMEludGVybmFsJTIwQ0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 YWQsREM9ZnJhbmNldGVsZWNvbSxEQz1mcj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0 aS1jYTEtbGRhcC5zaS5mcmFuY2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNS TERQLG91PUFDX09OLG91PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5p dG4uZnRncm91cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEt aHR0cC5zaS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcwNTAz BggqgXoBEAwCAzAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3BzMDwGCCsG AQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdyb3VwL29jc3Aw HQYDVR0OBBYEFB2F2zucBQaZgAUdw0GxO8ZDKexEMB8GA1UdIwQYMBaAFDYcM2fTE1z6W5/qi7pE ZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQCC8AJaaR7ZePR0x/OG20bV0aByMZeM/tQUwLSxw/SY U2wwrFJCTSxiZmN4BD2aWo7BDMftDJ8RSK8mutxaoQy6oScRalUtkdimEj6D/Rc4VdMkNmxOkdUM jZgjUkGhEdq6GSqF1kCkmybxaJ4xev4HwaxM9avkDMYm2b4Xv9ccK5cugjJ2ABh0qrvEJIbKcngN ZxcC00cVvW7W/qko/fXWmbMOFV8yZZCru8Q5raE+DliR8E71IT00zLTpmCdxaXvub7RSz7J5SViW hmLKY6+14TG4qc+Ko+wL3rIRFFps2jisEYCxs3cNlVrIDRCLsJQ1MP0Fd3P8rgI1OBU60BMLMYIC TjCCAkoCAQEwga0wgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEk MCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEy OTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDECEhEh2xJJ DZGjBGwLmr1J3IYW9TAJBgUrDgMCGgUAoHcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAYBgkq hkiG9w0BCQ8xCzAJMAcGBSsOAwIaMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDMwODAwMjdaMCMGCSqG SIb3DQEJBDEWBBSzbR+VX+npFKjzlqI76q4Oo9cdGTANBgkqhkiG9w0BAQEFAASCAQA+hD07lHxl 2TeivFIWOF2lvlTEBmNAnWQeMznM1rtsQTArglFQtdpJ0qLkU7biVDmN264ofqbnTZ5KZjee1yen Ly1cy/75v5VVH3/dw6WIkTRv0G0FqLAeT0BO7+2Er8DxeBK06KwnB408Fc0RjL93YUsl0KRVw66W LV+53+1GBCmsmLk/k/tJCOZEwzH2EvP8u72Fud3w3rE83ykF5lnydo1p7tRhMLzgZFnjNV4XXx0n O3KI8ZjvEWiKUEr19KQB36vIBsjGqtR83Rv2gcMmJmTNJSyJwyedFLhb7O6VWHmfBlHNMaqAoRCH r/zz6QMazA6DVApPDbfzL2vvA/4EAAAAAAAA ------=_NextPart_000_000D_01D30C3F.552C0EA0-- From nobody Thu Aug 3 01:31:08 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C05132324; Thu, 3 Aug 2017 01:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 PR0aW0lkek5W; Thu, 3 Aug 2017 01:30:58 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7DF131D25; Thu, 3 Aug 2017 01:30:57 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4DF7F1203DD; Thu, 3 Aug 2017 10:30:56 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 29D3B160088; Thu, 3 Aug 2017 10:30:56 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0352.000; Thu, 3 Aug 2017 10:30:54 +0200 From: To: Ben Campbell , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "jouni.nospam@gmail.com" , "dmm@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) Thread-Index: AQHTC9ytcOq9fw96OEyswCAb38l3DaJyS6NQ Date: Thu, 3 Aug 2017 08:30:54 +0000 Message-ID: <81C77F07008CA24F9783A98CFD706F713AA912BB@OPEXCLILM22.corporate.adroot.infra.ftgroup> References: <150171204983.5743.7998947846703116776.idtracker@ietfa.amsl.com> In-Reply-To: <150171204983.5743.7998947846703116776.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01D30C43.953C8570" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Ben Campbell's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:30:59 -0000 ------=_NextPart_000_001A_01D30C43.953C8570 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] > Envoy=C3=A9 : jeudi 3 ao=C3=BBt 2017 00:14 > =C3=80 : The IESG > Cc : draft-ietf-dmm-mag-multihoming@ietf.org; Jouni Korhonen; dmm- > chairs@ietf.org; jouni.nospam@gmail.com; dmm@ietf.org > Objet : Ben Campbell's No Objection on = draft-ietf-dmm-mag-multihoming-04: (with > COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-dmm-mag-multihoming-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I have a few editorial comments/nits: >=20 > - There are several acronyms that should be expanded on first mention. > (including at least a couple that are expanded on _second_ mention = (MAG and > LMA). >=20 > - 3.2, "Per-packet management" bullet: The second sentence does not = make > sense. >=20 This sentence will be removed > - 3.2, last paragraph: Are we really talking about the latency = introduced by per- > packet management, or jitter (i.e. variation in latency)? >=20 We are talking about jitter. It will be clarified in next release. > - 4.1, definition of "Interface Label": This doesn't really define the = term "interface > label". It talks about how it is used, but not what it represents. >=20 You're right... We will add definition of interface label in the = terminology section. ------=_NextPart_000_001A_01D30C43.953C8570 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPmDCCA8cw ggKvoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwajELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5j ZSBUZWxlY29tIFNBMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEmMCQGA1UEAwwdR3JvdXBlIEZy YW5jZSBUZWxlY29tIFJvb3QgQ0EwHhcNMDUxMTE0MTIzNDA2WhcNMzUxMTE0MTIzNDA2WjBqMQsw CQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExFzAVBgNVBAsMDjAwMDIgMzgw MTI5ODY2MSYwJAYDVQQDDB1Hcm91cGUgRnJhbmNlIFRlbGVjb20gUm9vdCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALQPGHWb9eHSLKjwqhQqzRVp6jtyzl3L7igdDM8Kqksd7swc vjhKgx3j4bONtboJhUB/0XwJ8pQsRn3WCFZYCWLumRIf/mnzpzYdRJ1lTF3Gj5Q+4B1uyI97nEAf PfnTP+iass5sAYvorqOWjBqRYq9ztCR1mi7KsAbClk9vBtzf6tvVoNRHeABRpmMXDCnxa2ds+iRd 5OO4iuPUYmKgXqpQKMa3e1CBpZLnMvtnwA9aGDwZgtKEjCHxWEYWq5zBbQlqVCauf8D3o9z3Jq8P 470RSrI2pOHuklmLV3975UECIfj01Ke7DadLrPsD3+vrh7ZT2FykZRd+Y8QUzSsL/7kCAwEAAaN4 MHYwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBqSU8jPMxu28qVg feKvJBJBsJpgMB8GA1UdIwQYMBaAFBqSU8jPMxu28qVgfeKvJBJBsJpgMBMGA1UdIAQMMAowCAYG KoF6ARAMMA0GCSqGSIb3DQEBBQUAA4IBAQCDEc4ZDIFeaQATFc8DOiunh+89khLzcWCrV/77E3zG pNLIh+gns5rSfWl8plGdny3mVvMn75AH5/9DLg+527FVt8RkuOcPv0lsJaTwwr9c07RW197WHwFM kEoJO5O9MtF80kCqm96DciEnAt8LRlC6M2TXG5heqtOxps8KqyHpDjtv2SF2DQSMtVfXEurPZFbE tEaey364tpxK3m2FgA2SRZY8524Is8FonSmg6lSw8wY/P0LVwrO0rpJCTyi8BJuZ5Cdxf5iUyszU cDPJaBDTnw/p7VHOlS7XWlNBmiFWwBhlbZu1Aa+jphRJrcJ/f8wUD7dX88dyzsRsVas7cH3cMIIF AjCCA+qgAwIBAgIBATANBgkqhkiG9w0BAQUFADBqMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJh bmNlIFRlbGVjb20gU0ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5ODY2MSYwJAYDVQQDDB1Hcm91cGUg RnJhbmNlIFRlbGVjb20gUm9vdCBDQTAeFw0xMTA2MDgxMDAzMTJaFw0yNTExMTcxMDAzMTJaMIGW MQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rl cm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMM I0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsPMrb/9/950vF5H63795Vqp8uBndVfHlTk+wdFsXyTKn1j27tGqHOFknEYai IQB+tRpn2un9wFavqNz6bYyeOfZDKfwAmnkafAxc1u4jRZv0H3ZPNVfXVS1x7G2MFlN+94/5LMdU pppN77KuH1mqXgDi33bO9CjuEVj/2FUpjqwBVTIqleJfX+mvhvC69rTmZFml/t729xxOpgxt5Wt2 OlQ6VaYqEq8+tSj2/KS8joO07oYSMTikzTXnxHA8BSsfc31SWsfjx4+sxmxc3RhDFnscBkot0l5I AFevwiTbQhx1xNjqa1nN9CYgmNfBpLz60YDtVwUqsdMQyGpvlqRIfwIDAQABo4IBhDCCAYAwDwYD VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDYcM2fTE1z6W5/qi7pEZnRG 8Xd4MHQGA1UdIwRtMGuAFBqSU8jPMxu28qVgfeKvJBJBsJpgoVCBTkNOPUdyb3VwZSBGcmFuY2Ug VGVsZWNvbSBSb290IENBLCBPVT0wMDAyIDM4MDEyOTg2NiwgTz1GcmFuY2UgVGVsZWNvbSBTQSwg Qz1GUoIBADB8BgNVHR8EdTBzMDOgMaAvhi1odHRwOi8vcGtpLWNybC5pdG4uZnRncm91cC9jcmwv aWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNhLmZyYW5jZXRlbGVjb20uY29t L2NybC9pZ2NnZnRfcmNhLmNybDBKBgNVHSAEQzBBMD8GByqBegEQDAIwNDAyBggrBgEFBQcCARYm aHR0cDovL2lnY2dmdC1yY2EuZnJhbmNldGVsZWNvbS5jb20vcGMwDQYJKoZIhvcNAQEFBQADggEB AAYnlAZbNOHSm110Res4plYBlKidMGviiMNUD6x/Ffgx5wAHq2ze+fxSJ9OFB5VoppVYxr+rH3ys eTSpIEGyj6rrlBc5wA9mrH8mOyBJvYrUprWyjmxi8c7FA9vHv5Np1/ARHl/Pwlyp3bBY/Sol6ltH lclR1lVtOSsjrRrch2C+THDcg+axS5Uu+RLofzxio9W159rjLnRku2UgTyZr7bkeI5BnTw35MmfI cJ3yvDZ91rduKPCLwm0UZHaoIm8FM8R5sxl6Bs0oheoKcY7T/RZ8HLVdPXGntKu9PPFm5sOEAV/f R3OsIQcUsEFUtYwqqkYpoxWXKF2ggfM2boaBWE0wggbDMIIFq6ADAgECAhIRIdsSSQ2RowRsC5q9 SdyGFvUwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVs ZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4w MDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwHhcNMTYxMTEwMTUyOTQ3WhcNMjAxMTEwMTUyOTQ3WjBsMQswCQYDVQQGEwJGUjEaMBgGA1UE ChMRRnJhbmNlIFRlbGVjb20gU0ExFzAVBgNVBAMMDlNlaXRlIFBpZXJyaWNrMSgwJgYJKoZIhvcN AQkBDBlwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAx+8AqQCVr92UckX7U15KZ0vDtil2hHlap9fccx9ieTVGSIHXclF7U9XQeLOcNpno7Wh1 P1pqZdj9hf41fnpT2aisvqvCs7mL3Ee4tofq3btoOu9suHfCnAjN06uaNuJj3oburKLbczq3EHK5 yqfOi1NUvhRbuXnD0q+FLm/qX4mw5GlTCT3qJc3Z0XWpSAtaE9YHcMHas8AbX5+e1sP2+uEXA4Qw iHmkK3EaDunpNHM1ea4dkkbve9STrgX/DO/TxlOkHt1hO2xMUtr/p1qCbuuHqVutCv94YRmkDn+6 tbp8v/01hAX1i37PGEbJc+GmY2c5NfkP9cn8gTsL7Y9Y3QIDAQABo4IDMjCCAy4wDgYDVR0PAQH/ BAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGXBpZXJyaWNrLnNlaXRlQG9y YW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB6KCB5aCB4oaB32xkYXA6Ly8vY249R3JvdXBlJTIw RnJhbmNlJTIwVGVsZWNvbSUyMEludGVybmFsJTIwQ0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 YWQsREM9ZnJhbmNldGVsZWNvbSxEQz1mcj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0 aS1jYTEtbGRhcC5zaS5mcmFuY2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNS TERQLG91PUFDX09OLG91PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5p dG4uZnRncm91cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEt aHR0cC5zaS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcwNTAz BggqgXoBEAwCAzAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3BzMDwGCCsG AQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdyb3VwL29jc3Aw HQYDVR0OBBYEFB2F2zucBQaZgAUdw0GxO8ZDKexEMB8GA1UdIwQYMBaAFDYcM2fTE1z6W5/qi7pE ZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQCC8AJaaR7ZePR0x/OG20bV0aByMZeM/tQUwLSxw/SY U2wwrFJCTSxiZmN4BD2aWo7BDMftDJ8RSK8mutxaoQy6oScRalUtkdimEj6D/Rc4VdMkNmxOkdUM jZgjUkGhEdq6GSqF1kCkmybxaJ4xev4HwaxM9avkDMYm2b4Xv9ccK5cugjJ2ABh0qrvEJIbKcngN ZxcC00cVvW7W/qko/fXWmbMOFV8yZZCru8Q5raE+DliR8E71IT00zLTpmCdxaXvub7RSz7J5SViW hmLKY6+14TG4qc+Ko+wL3rIRFFps2jisEYCxs3cNlVrIDRCLsJQ1MP0Fd3P8rgI1OBU60BMLMYIC TjCCAkoCAQEwga0wgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEk MCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEy OTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDECEhEh2xJJ DZGjBGwLmr1J3IYW9TAJBgUrDgMCGgUAoHcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAYBgkq hkiG9w0BCQ8xCzAJMAcGBSsOAwIaMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDMwODMwNTJaMCMGCSqG SIb3DQEJBDEWBBQ4BkpZZcLjt8v1qwx62a6UqZDXfjANBgkqhkiG9w0BAQEFAASCAQCrhGnG9VM9 9OMgXcKF12EMV9SQ4uxPl3VI1Z/hjQKir/Kc5Nrdre4xu/tdmNHfTusHp7V9EtJfWluzi92rtavs nIZNNSqmWy7qRRj4HHh94pdH6684KDjCAhrCzbNTZIIM7KcdzYv8OYRfXq6EvbUtQnCbj2iiffIW G8UDUpb3dfEtLpIN3cO5vMMvfqWRtBhSYVMD0SOiWDF3fmuqW8xI2jClJHbrJKyIn/o6aVV5KvP4 2EhKapDKGU1Y2cMR8DamoVrhRscM8T7CDkT1xdbfcV62/dIJzUF/cgtygrodW6m9DOZfciGx8Axn 715K786uSMT8qPq8nsbE/mXzGgAUAAAAAAAA ------=_NextPart_000_001A_01D30C43.953C8570-- From nobody Thu Aug 3 08:38:45 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B042132481; Thu, 3 Aug 2017 08:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 qivjzBi2_TEL; Thu, 3 Aug 2017 08:38:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F148A132488; Thu, 3 Aug 2017 08:38:35 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v73FcWJs089974 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Aug 2017 10:38:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <81C77F07008CA24F9783A98CFD706F713AA912BB@OPEXCLILM22.corporate.adroot.infra.ftgroup> Date: Thu, 3 Aug 2017 10:38:32 -0500 Cc: The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150171204983.5743.7998947846703116776.idtracker@ietfa.amsl.com> <81C77F07008CA24F9783A98CFD706F713AA912BB@OPEXCLILM22.corporate.adroot.infra.ftgroup> To: pierrick.seite@orange.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DMM] Ben Campbell's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 15:38:38 -0000 Thanks, your response resolves all my comments. Ben. > On Aug 3, 2017, at 3:30 AM, pierrick.seite@orange.com wrote: >=20 >=20 >=20 >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com] >> Envoy=C3=A9 : jeudi 3 ao=C3=BBt 2017 00:14 >> =C3=80 : The IESG >> Cc : draft-ietf-dmm-mag-multihoming@ietf.org; Jouni Korhonen; dmm- >> chairs@ietf.org; jouni.nospam@gmail.com; dmm@ietf.org >> Objet : Ben Campbell's No Objection on = draft-ietf-dmm-mag-multihoming-04: (with >> COMMENT) >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-dmm-mag-multihoming-04: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I have a few editorial comments/nits: >>=20 >> - There are several acronyms that should be expanded on first = mention. >> (including at least a couple that are expanded on _second_ mention = (MAG and >> LMA). >>=20 >> - 3.2, "Per-packet management" bullet: The second sentence does not = make >> sense. >>=20 >=20 > This sentence will be removed >=20 >> - 3.2, last paragraph: Are we really talking about the latency = introduced by per- >> packet management, or jitter (i.e. variation in latency)? >>=20 >=20 > We are talking about jitter. It will be clarified in next release. >=20 >> - 4.1, definition of "Interface Label": This doesn't really define = the term "interface >> label". It talks about how it is used, but not what it represents. >>=20 >=20 > You're right... We will add definition of interface label in the = terminology section. From nobody Thu Aug 3 21:40:31 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE30120727; Thu, 3 Aug 2017 21:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 WKINVQ7JCrgS; Thu, 3 Aug 2017 21:40:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E5D128AA1; Thu, 3 Aug 2017 21:40:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F2AB9B8103D; Thu, 3 Aug 2017 21:40:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dmm@ietf.org Message-Id: <20170804044021.F2AB9B8103D@rfc-editor.org> Date: Thu, 3 Aug 2017 21:40:21 -0700 (PDT) Archived-At: Subject: [DMM] RFC 8191 on Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 04:40:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8191 Title: Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) Author: Z. Yan, J. Lee, X. Lee Status: Standards Track Stream: IETF Date: August 2017 Mailbox: yan@cnnic.cn, jonghyouk@smu.ac.kr, xl@cnnic.cn Pages: 10 Characters: 20719 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dmm-hnprenum-07.txt URL: https://www.rfc-editor.org/info/rfc8191 DOI: 10.17487/RFC8191 In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification. This document is a product of the Distributed Mobility Management Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 10 12:59:49 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0751B132420 for ; Thu, 10 Aug 2017 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aQe-QCb144So for ; Thu, 10 Aug 2017 12:59:44 -0700 (PDT) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF1C1321EC for ; Thu, 10 Aug 2017 12:59:44 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 10 Aug 2017 12:59:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,354,1498546800"; d="scan'208,217";a="298614795" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga004.fm.intel.com with ESMTP; 10 Aug 2017 12:59:43 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 Aug 2017 12:59:43 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.164]) by HASMSX110.ger.corp.intel.com ([169.254.6.39]) with mapi id 14.03.0319.002; Thu, 10 Aug 2017 22:59:40 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: New draft of draft-moses-dmm-dhcp-ondemand-mobility after dhc WG review Thread-Index: AdMSEkkwZhu7y7mmTGuSFUMPcqEqeQ== Date: Thu, 10 Aug 2017 19:59:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.255.195.163] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134F35CA4HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] New draft of draft-moses-dmm-dhcp-ondemand-mobility after dhc WG review X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 19:59:47 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134F35CA4HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable AT IETF98 (Chicago) I was request by the WG to present the draft-moses-dmm-= dhcp-ondemand-mobility draft to the dhc group and have them review the DHCP= v6 aspects of this draft. At IETF99 (Prague), I presented the draft and receive very useful comments= and correction. The new draft includes all the changes as a result of that review. I am including in this email, the list of comments that were raised and the= actions taken to improve the draft. I hope that after this important milestone was achieved, the draft will be = adopted by the dmm WG. The following comments/questions were raised regarding the DHCP OnDemand dr= aft (draft-moses-dmm-dhcp-ondemand-mobility): 1. Replace the status code name from NoAddrsAvail to NoPrefixAvail 2. The description of the server's behavior in response to an unrecogn= ized encapsulated option in section 3 is wrong - fix it. 3. Clarify the correlation of the service types and the lifetime attri= bute (especially for Fixed address types). 4. Correct the fields of the Anchor Preference option 5. Remove the definition of the Anchor Preference option. It is not ne= eded. 6. Check capital letters for keywords (MUST, SHOULD, MAY) 7. Fix section 2 - RFC8174 (wording was updated). See RFC8156 - for ex= ample. 8. Draft does not mention the Confirm and Rebind messages which are re= levant for mobility support. Actions: 1. Replace the status code from NoAddrsAvail to NoPrefixAvail: Done. 2. Correct description of server's behavior when receiving an unrecogn= ized option: Replaced the original text: "A server that does not support this option will discard it as well as the = IA_PD Prefix option that had this option encapsulated in one of its IAprefi= x-options field. If a client does not receive the requested prefix, it must resend the reque= st without the desired IPv6 Continuity Service option since it is not suppo= rted by the server. In this case, the requesting device (host or router) cannot assume any IP continuity service behavior for that = prefix." With: "A server that does not support this option will ignore it and respond with= out taking into account the desired session continuity service. The respons= e will not include the Continuity Service option encapsulated in the IApref= ix-options field of the IA_PD prefix option. The missing Continuity Service option in the response serves as an indicati= on to the client that this feature is not supported by the server. It MAY u= se the allocated prefix (knowing it does not necessarily support the desire= d Continuity service), or perform any other action." 3. Clarify the correlation of the service types and the lifetime attri= bute: Adding section 3.1 to clarify the correlation between Session continuity se= rvices and 'lifetime': 3.1 Correlation between Session Continuity Service and lifetime values The values to be used in the Preferred-lifetime and Valid-lifetime fields i= n the IA Prefix Option are out of the scope of this specification and left = to implementation. It is recommended to provide longer lifetime values for = Fixed and Session-lasting prefixes compared to the lifetime values of Non-p= ersistent and Graceful-replacement prefixes because the network has guarant= eed their validity regardless of the link to which the host is attached. For clients using Graceful-replacement services, the network MAY obsolete a= Prefix and allocate a new one from time to time especially in a mobility-r= elated event. On such occasions, the network SHOULD provide a graceful peri= od (lifetime) in which the obsoleted prefix can still be used and a new (lo= nger) lifetime with the new prefix. It is not recommended to use 0xFFFFFFFFFF (infinity) values for the lifetim= e of Fixed prefixes. Even though they are fixed, it is still safer to Rebin= d periodically. The lifetime value can be relatively long to reduce message= exchange overhead. Section 18.2 of 3633bis - Client Behavior: "A client uses the Solicit message to discover DHCP servers configured to a= ssign leases or return other configuration parameters on the link to which = the client is attached. A client uses Request, Renew, Rebind, Release and Decline messages during t= he normal life cycle of addresses and delegated prefixes. When a client det= ects it may have moved to a new link, it uses Confirm if it only has addres= ses and Rebind if it has delegated prefixed (and addresses)..." Section 3.1 also has some clarifications regarding the client's operation a= fter moving to a new link: "Section 18.2 - Client Behavior of ietf-dhc-rfc3315bis specifies that when = a client detects it may have moved to a new link, it uses Rebind if it has = delegated prefixes. It is worth clarifying that a client does not HAVE to R= ebind the prefixes if they are Fixed or Session-lasting prefixes." 4. Correct the fields of the Anchor Preference option: Since the Anchor Preference option is not needed (see next comment) it has = been removed from the draft. 5. Remove the definition of the Anchor Preference option. It is not ne= eded: Done. 6. Check capital letters for keywords (MUST, SHOULD, MAY): Done. Hope I did not miss any... 7. Fix section 2 - RFC8174 (wording was updated). See RFC8156 - for ex= ample: Done. Added reference to RFC8174 and updated the wording. 8. Draft does not mention the Confirm and Rebind messages which are re= levant for mobility support: That is correct. The draft is about a new option and it does not affect any= existing messages. However as described in this email, Rebind will be ment= ion is the description of the need to rebind after a mobility event. Thanks, Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134F35CA4HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

AT IETF98 (Chicago) I was request by the WG to prese= nt the draft-moses-dmm-dhcp-ondemand-mobility draft to the dhc group and ha= ve them review the DHCPv6 aspects of this draft.

 

At IETF99 (Prague), I presented the draft  and = receive very useful comments and correction.

The new draft includes all the changes as a result o= f that review.

 

I am including in this email, the list of comments t= hat were raised and the actions taken to improve the draft.

I hope that after this important milestone was achie= ved, the draft will be adopted by the dmm WG.

 

 

 

The following comments/questions were raised regardi= ng the DHCP OnDemand draft (draft-moses-dmm-dhcp-ondemand-mobility):

 

1.      Replace the status code na= me from NoAddrsAvail to NoPrefixAvail

2.      The description of the ser= ver’s behavior in response to an unrecognized encapsulated option in = section 3 is wrong – fix it.

3.      Clarify the correlation of= the service types and the lifetime attribute (especially for Fixed address= types).

4.      Correct the fields of the = Anchor Preference option

5.      Remove the definition of t= he Anchor Preference option. It is not needed.

6.      Check capital letters for = keywords (MUST, SHOULD, MAY)

7.      Fix section 2 – RFC8= 174 (wording was updated). See RFC8156 – for example.

8.      Draft does not mention the= Confirm and Rebind messages which are relevant for mobility support.<= /o:p>

 

 

Actions:

1.      Replace the status code fr= om NoAddrsAvail to NoPrefixAvail:

Done.

 

2.      Correct description of ser= ver’s behavior when receiving an unrecognized option:

Replaced the original text:

“A server that does not support this option wi= ll discard it as well as the IA_PD Prefix option that had this option encap= sulated in one of its IAprefix-options field.

If a client does not receive the requested prefix, i= t must resend the request without the desired IPv6 Continuity Service optio= n since it is not supported by the server. In this case, the requesting dev= ice
(host or router) cannot assume any IP continuity service behavior for that = prefix.”

 

With:

“A server that does not support this option wi= ll ignore it and respond without taking into account the desired session co= ntinuity service. The response will not include the Continuity Service opti= on encapsulated in the IAprefix-options field of the IA_PD prefix option.

 

The missing Continuity Service option in the respons= e serves as an indication to the client that this feature is not supported = by the server. It MAY use the allocated prefix (knowing it does not necessa= rily support the desired Continuity service), or perform any other action.”

3.      Clarify the correlation of= the service types and the lifetime attribute:

 

 

Adding section 3.1 to clarify the correlation betwee= n Session continuity services and ‘lifetime’:

3.1 Correlation between Session Continuity Service a= nd lifetime values

The values to be used in the Preferred-lifetime and = Valid-lifetime fields in the IA Prefix Option are out of the scope of this = specification and left to implementation. It is recommended to provide long= er lifetime values for Fixed and Session-lasting prefixes compared to the lifetime values of Non-persistent and Graceful-re= placement prefixes because the network has guaranteed their validity regard= less of the link to which the host is attached.

 

For clients using Graceful-replacement services, the= network MAY obsolete a Prefix and allocate a new one from time to time esp= ecially in a mobility-related event. On such occasions, the network SHOULD = provide a graceful period (lifetime) in which the obsoleted prefix can still be used and a new (longer) lifetim= e with the new prefix.

It is not recommended to use 0xFFFFFFFFFF (infinity)= values for the lifetime of Fixed prefixes. Even though they are fixed, it = is still safer to Rebind periodically. The lifetime value can be relatively= long to reduce message exchange overhead.

 

Section 18.2 of 3633bis – Client Behavior:

“A client uses the Solicit message to discover= DHCP servers configured to assign leases or return other configuration par= ameters on the link to which the client is attached.

 

A client uses Request, Renew, Rebind, Release and De= cline messages during the normal life cycle of addresses and delegated pref= ixes. When a client detects it may have moved to a new link, it uses Confir= m if it only has addresses and Rebind if it has delegated prefixed (and addresses)…”

 

Section 3.1 also has some clarifications regarding t= he client’s operation after moving to a new link:

“Section 18.2 - Client Behavior of ietf-dhc-rf= c3315bis specifies that when a client detects it may have moved to a new li= nk, it uses Rebind if it has delegated prefixes. It is worth clarifying tha= t a client does not HAVE to Rebind the prefixes if they are Fixed or Session-lasting prefixes.”

 

4.      Correct the fields of the = Anchor Preference option:

Since the Anchor Preference option is not needed (se= e next comment) it has been removed from the draft.

 

5.      Remove the definition of t= he Anchor Preference option. It is not needed:

Done.

 

6.      Check capital letters for = keywords (MUST, SHOULD, MAY):

Done. Hope I did not miss any…

 

7.      Fix section 2 – RFC8= 174 (wording was updated). See RFC8156 – for example:

Done. Added reference to RFC8174 and updated the wor= ding.

 

 

8.      Draft does not mention the= Confirm and Rebind messages which are relevant for mobility support:<= /o:p>

That is correct. The draft is about a new option and= it does not affect any existing messages. However as described in this ema= il, Rebind will be mention is the description of the need to rebind after a= mobility event.

 

Thanks,

 

Danny

 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134F35CA4HASMSX106gercor_-- From nobody Sun Aug 13 04:59:29 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5F4132630 for ; Sun, 13 Aug 2017 04:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 76RpgKpolnwI for ; Sun, 13 Aug 2017 04:59:25 -0700 (PDT) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F832132530 for ; Sun, 13 Aug 2017 04:59:25 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 13 Aug 2017 04:59:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,368,1498546800"; d="scan'208,217";a="299555199" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga004.fm.intel.com with ESMTP; 13 Aug 2017 04:59:25 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 13 Aug 2017 04:59:24 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 13 Aug 2017 04:59:24 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.164]) by HASMSX110.ger.corp.intel.com ([169.254.6.39]) with mapi id 14.03.0319.002; Sun, 13 Aug 2017 14:59:21 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: Any comments on the new version of the OnDemand draft (draft-ietf-dmm-ondemand-mobility-12 )? Thread-Index: AdMUKvGbcto5TIkiRniI5Q1+Dkg9TA== Date: Sun, 13 Aug 2017 11:59:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.124.184.49] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134F361F9HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] Any comments on the new version of the OnDemand draft (draft-ietf-dmm-ondemand-mobility-12 )? X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 11:59:27 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134F361F9HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi everyone, Two weeks ago I posted a new version of draft-ietf-dmm-ondemand-mobility-12= includ= ing modifications addressing comments in the last DMM session. I also poste= d on this list text that describe the different session continuity services= and use-cases for each one. Are there any comments? Is the draft ready for another round of WGLC? If not, what else should we a= ddress? Thanks, Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134F361F9HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

Two weeks ago I posted a new version of draft-iet= f-dmm-ondemand-mobility-12 including modifications addressing= comments in the last DMM session. I also posted on this list text that describe the different session continuity se= rvices and use-cases for each one.

 

Are there any comments?

Is the draft ready for another round of WGLC? If not= , what else should we address?

 

Thanks,

Danny

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134F361F9HASMSX106gercor_-- From nobody Tue Aug 15 10:47:49 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A6B132143 for ; Tue, 15 Aug 2017 10:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU9hKBIG-Dpt for ; Tue, 15 Aug 2017 10:47:42 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3A4124207 for ; Tue, 15 Aug 2017 10:47:40 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id m57so5300386wrm.5 for ; Tue, 15 Aug 2017 10:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cSvHWGGampz74P13B+yOO2o5uvzoWVUNSFnKfbJzKDo=; b=GLJ2McCDjZia2CCT08CMW4KySn2Kf1w0OL61uibiDpjVOEZffOSzuT7vn8UKHwPQRJ 6oIvB8AO3fEiwaySoIhsx2m0xStyq9UUViXpdUf9DkjEEpYizhdLUy7d46MdSI+NhJHa SQy4xFjfwvHJn3AqySNKUfGTNVCq7zQLfJd+Gh0UdSdQfcdGP28bSpAj7KGKE2CuyutF ueBwo6Xm/AjZkjT78MoVfYekxJ7M0MCC0eAfA9dSlZsdmcR2tnmsgXNA1H8FahJAlzs+ 2JRMSThqmKYUs207CM5W+1tOTutzYyUS+8R7200wGvaPV4/0IoEOR087214hLhmYpPIr A9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cSvHWGGampz74P13B+yOO2o5uvzoWVUNSFnKfbJzKDo=; b=ZW4OORoqbJd/rbm0yPuUTe+fjFpTGTCRmUk276iGggC/bxpTvAqPkkOhgsP/INbv78 Y3K6o89trKttNxxSKOPPKWPDi7e7HEwtdfkl3uSRbL8MT/jYO1Zg9AhexTARup4kkOuC Xw+0DQnRsjfqrS/+Rvw/NGmoMkW9xZCMSH7wedXmzSnuOxMeRQtniBme6wokkQqH0Bpx HySFIpToweXChGn9vER5KJBEfUvm10NZmZVCa9tRZmGFqcvupjwPzyr0kpo8KfzjEYgd mzlRUOxJvT3vgSIc6eF8dmICJmaUGK5JBt6dTDMB5cOSqYRCEA/Ik0ulYmF2yOuwtmYJ 1Dsw== X-Gm-Message-State: AHYfb5hfqq1Ur6wnTOHZQnQLSwWqygpHqdjr08igLUcUaOO8DHDudqeP YZhKw7P3OMiL9+Ijck6i9JkJOsqWuNe+ X-Received: by 10.223.176.5 with SMTP id f5mr3306249wra.194.1502819258715; Tue, 15 Aug 2017 10:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 15 Aug 2017 10:46:57 -0700 (PDT) In-Reply-To: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> References: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> From: Warren Kumari Date: Tue, 15 Aug 2017 13:46:57 -0400 Message-ID: To: pierrick.seite@orange.com Cc: The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:47:44 -0000 This document is on Thursday's telechat - I have not seen proposed text to address my concerns, and so I'm continuing to hold my DISCUSS position. W On Wed, Aug 2, 2017 at 5:18 PM, wrote: > Hello > > Please see inline > > Pierrick > > > > Sent from my cell phone, mind the typos. > > -------- Message d'origine -------- > De : Warren Kumari > Date : 02/08/2017 22:23 (GMT+01:00) > =C3=80 : The IESG > Cc : draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen > , dmm-chairs@ietf.org, jouni.nospam@gmail.com, > dmm@ietf.org > Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (wi= th > DISCUSS) > > Warren Kumari has entered the following ballot position for > draft-ietf-dmm-mag-multihoming-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 3.2. Traffic distribution schemes > "Per-packet management: the LMA and the MAG distribute packets, belonging= to > a > same IP flow, over more than one bindings (i.e. more than one WAN > interface)." > This immediately made my out-of-order-packets antenna pop up, so I read t= he > section looking for mitigations. The very next sentence reads: "Packet > distribution can be done either at the transport level, e.g. using MPTCP = or > at > When operating at the IP packet level, different packets distribution > algorithms are possible. " -- the fact that this sentence is a: malformed > and > b: hand-wavy did nothing to allay my concerns, so I read further: "The > distribution algorithm is left to implementer but whatever the algorithm = is, > packets distribution likely introduces packet latency and out-of-order > delivery. LMA and MAG shall thus be able to make reordering before packe= ts > delivery." - I agree with the first sentence (although it is poorly worde= d), > but the second sentence doesn't follow from the first; "shall thus be abl= e > to" > implies that the prior text somehow provides a solution, not points out a > problem (the sentence is also malformed)-- I think you mean something lik= e > "The > LMA and MAG thus need to be able reorder packets to their original order > before > delivery." > > This then continues with "Sequence number can be can be used for that > purpose, > for example using GRE with sequence number option [RFC5845]." - I think t= hat > the actual reference should be RFC2890, but regardless of this, I don't > think > that what you are proposing works - "The Sequence Number field is used to > maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, > emphasis added). This means that sequence numbers are local to the tunnel= , > and > (as I understand it) your solution involves diverse tunnels. Further, > Section > 2.2. Sequence Number says: "The receiver may perform a small amount of > buffering in an attempt to recover the original sequence of transmitted > packets. In this case, the packet may be placed in a buffer sorted by > sequence > number." - if you are proposing using a single sequence number space for > multiple tunnels, you will end up with sequence number space gabs, and lo= ts > of > buffering, etc. The section ends with: "However, more detailed > considerations > on reordering and IP packet distribution scheme (e.g. definition of pack= ets > distribution algorithm) are out the scope of this document." - I think th= at, > unless the prior paragraph is significantly reworked, it should not try a= nd > suggest any mitigations. > >>> ok > > The whole idea of striping packets of a flow across (notably) different > transports seems like a really bad idea to me -- is it actually needed? > >>> some use-cases implement per-packet distribution. However this document >>> does not aim to make recommendation on the way to distribute packets > > > _________________________________________________________________________= ________________________________________________ > > 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 re= cu > 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 o= u > 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 bee= n > modified, changed or falsified. > Thank you. --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 15 17:03:43 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E298C1323B9; Tue, 15 Aug 2017 17:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fg4JZTU4bE5; Tue, 15 Aug 2017 17:03:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98761323AC; Tue, 15 Aug 2017 17:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6156; q=dns/txt; s=iport; t=1502841817; x=1504051417; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s2jov7AIh5FkOlgXoaJGDyI2kRmDG8e4kh/41bEgxD0=; b=lcFyX4EYCtqdOGHWtJBDfE0+h2qcjlfRxfpJDTbXQ3RgvszZ1Z7s4ZQ9 D4TyVCdEiufhcHbpk2On2bJTe2NzzZQ9yOtKtOGLYD1jPITLiVW6UR4uF oD0YU5sSvCBiBfyXStP2BYKQAigwW926yPC9XFgET3mpN3IythF7si5sH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACUi5NZ/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjguQEYFuiDeNYQ6CBCyFGwKENj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEFeRACAQgYLiERJQIEAQ0FG4l8AxUQrnWHRA2EGQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFgyiCAoFMgWODJ4JXgWkBEgFLBoVCBYl7h2COJjwCh1GDVIQjhHa?= =?us-ascii?q?CD4Vfg3uGcIw1iWIBHzh/C3cVhWAcGYFOdgGHT4EjgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,380,1498521600"; d="scan'208";a="65170046" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Aug 2017 00:03:36 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v7G03a3U014802 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Aug 2017 00:03:36 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Aug 2017 19:03:35 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 15 Aug 2017 19:03:35 -0500 From: "Sri Gundavelli (sgundave)" To: Warren Kumari , "pierrick.seite@orange.com" CC: The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: RE : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AQHTFiMa5HaWVPV3GUm7h+7dw60DEQ== Date: Wed, 16 Aug 2017 00:03:35 +0000 Message-ID: References: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9AC535457189A043BC34314E81A27D27@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 00:03:41 -0000 Hi Warren, We will post the text by tomorrow. Regards Sri On 8/15/17, 10:46 AM, "Warren Kumari" wrote: >This document is on Thursday's telechat - I have not seen proposed >text to address my concerns, and so I'm continuing to hold my DISCUSS >position. > >W > >On Wed, Aug 2, 2017 at 5:18 PM, wrote: >> Hello >> >> Please see inline >> >> Pierrick >> >> >> >> Sent from my cell phone, mind the typos. >> >> -------- Message d'origine -------- >> De : Warren Kumari >> Date : 02/08/2017 22:23 (GMT+01:00) >> =C0 : The IESG >> Cc : draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen >> , dmm-chairs@ietf.org, jouni.nospam@gmail.com, >> dmm@ietf.org >> Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: >>(with >> DISCUSS) >> >> Warren Kumari has entered the following ballot position for >> draft-ietf-dmm-mag-multihoming-04: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to=20 >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 3.2. Traffic distribution schemes >> "Per-packet management: the LMA and the MAG distribute packets, >>belonging to >> a >> same IP flow, over more than one bindings (i.e. more than one WAN >> interface)." >> This immediately made my out-of-order-packets antenna pop up, so I read >>the >> section looking for mitigations. The very next sentence reads: "Packet >> distribution can be done either at the transport level, e.g. using >>MPTCP or >> at >> When operating at the IP packet level, different packets distribution >> algorithms are possible. " -- the fact that this sentence is a: >>malformed >> and >> b: hand-wavy did nothing to allay my concerns, so I read further: "The >> distribution algorithm is left to implementer but whatever the >>algorithm is, >> packets distribution likely introduces packet latency and out-of-order >> delivery. LMA and MAG shall thus be able to make reordering before >>packets >> delivery." - I agree with the first sentence (although it is poorly >>worded), >> but the second sentence doesn't follow from the first; "shall thus be >>able >> to" >> implies that the prior text somehow provides a solution, not points out >>a >> problem (the sentence is also malformed)-- I think you mean something >>like >> "The >> LMA and MAG thus need to be able reorder packets to their original order >> before >> delivery." >> >> This then continues with "Sequence number can be can be used for that >> purpose, >> for example using GRE with sequence number option [RFC5845]." - I think >>that >> the actual reference should be RFC2890, but regardless of this, I don't >> think >> that what you are proposing works - "The Sequence Number field is used >>to >> maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, >> emphasis added). This means that sequence numbers are local to the >>tunnel, >> and >> (as I understand it) your solution involves diverse tunnels. Further, >> Section >> 2.2. Sequence Number says: "The receiver may perform a small amount of >> buffering in an attempt to recover the original sequence of transmitted >> packets. In this case, the packet may be placed in a buffer sorted by >> sequence >> number." - if you are proposing using a single sequence number space for >> multiple tunnels, you will end up with sequence number space gabs, and >>lots >> of >> buffering, etc. The section ends with: "However, more detailed >> considerations >> on reordering and IP packet distribution scheme (e.g. definition of >>packets >> distribution algorithm) are out the scope of this document." - I think >>that, >> unless the prior paragraph is significantly reworked, it should not try >>and >> suggest any mitigations. >> >>>> ok >> >> The whole idea of striping packets of a flow across (notably) different >> transports seems like a really bad idea to me -- is it actually needed? >> >>>> some use-cases implement per-packet distribution. However this >>>>document >>>> does not aim to make recommendation on the way to distribute packets >> >> >>=20 >>_________________________________________________________________________ >>________________________________________________ >> >> 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. > > > >--=20 >I don't think the execution is relevant when it was obviously a bad >idea in the first place. >This is like putting rabid weasels in your pants, and later expressing >regret at having chosen those particular rabid weasels and that pair >of pants. > ---maf From nobody Tue Aug 15 18:40:53 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67B4120713; Tue, 15 Aug 2017 18:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw4OQNOQQupb; Tue, 15 Aug 2017 18:40:46 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2979713239F; Tue, 15 Aug 2017 18:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27167; q=dns/txt; s=iport; t=1502847646; x=1504057246; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sIChSgVBIuinM11I76lmzvOVHSGNCCSXmtNTvsp3fTM=; b=PvIAtgIjzL+uc+X/Hj9+Mw4XFvPEHPCje3D5nrOBQGsM1MKjI3G8au49 lbkK1F1cFOjldIot4/1xaRDZ2qyBH4gR16OWhHv/Fs+msW/uusVBBAl8W ilZ9x5FMgQ2hZ6WdVFNDLwBMW+Hz42JUuZjtC/5q2AIRHDPcNWZCj6HwX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAAByoZNZ/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZDlcB4RTiTiQEYFuiDeNYQ6CBCyFGwKENj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQYaXxACAQYCPwchERQRAgQBDQUbiTBMAxUQjl+gCodEDYQZAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDKIICgUyBY4MngleBaQESAQdECoU+BYl7B44Th2w?= =?us-ascii?q?8AodRg1SEI4R2gg+Ba4N0g3uGcIw1iWIBHzh/C3cVhWAcGYFOdgGHT4EjgQ8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.41,380,1498521600"; d="scan'208,217";a="472026155" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2017 01:40:44 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v7G1eieM002349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Aug 2017 01:40:44 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Aug 2017 20:40:44 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Tue, 15 Aug 2017 20:40:44 -0500 From: "Sri Gundavelli (sgundave)" To: Warren Kumari , "pierrick.seite@orange.com" CC: The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: RE : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AQHTFjCs5HaWVPV3GUm7h+7dw60DEQ== Date: Wed, 16 Aug 2017 01:40:43 +0000 Message-ID: References: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: multipart/alternative; boundary="_000_D5B8F046287689sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 01:40:50 -0000 --_000_D5B8F046287689sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Warren, Slight rewrite of this paragraph without changing the original intent. Rem= oved unnecessary text; identified the key issues. Please let me know if this addresses your concerns. Regards Sri =97=97=97=97=97=97=97=97=97=97=97=97- NEW: 3.2. Traffic distribution schemes When the MAG has registered multipath binding with the LMA, there will be m= ultiple established overlay tunnels between them. The MAG and the LMA can u= se any one, or more of the available tunnels paths for routing the mobile n= ode=92s IP traffic. This specification does not recommend, or define any s= pecific traffic distribution scheme, however it identifies two well-known a= pproaches that implementations can potentially use. These approaches are, P= er-flow and Per-packet Traffic distribution schemes. Per-Flow Traffic Distribution: In this approach the MAG and the LMA associate each of the IP flows (upstre= am and downstream) to a specific tunnel path. The packets in a given IP flo= w are always routed on the same overlay tunnel path; they are never split a= nd routed concurrently on more than one tunnel path. It is possible a give= n flow may be moved from one tunnel path to another, but the flow is never = split. The decision to bind a given IP flow to a specific tunnel path is ba= sed on traffic distribution policy. This traffic distribution policy is eit= her statically configured on both the MAG and the LMA, or dynamically negot= iated over Proxy Mobile IPv6 signaling. The Flow Binding extension [6089= ] defines the mechanism and the semantics for exchanging the traffic policy= between two tunnel peers and the same mechanism and the mobility options a= re used here. Per-Packet Traffic Distribution: In this approach, packets belonging a given IP flow will be split and route= d across more than one tunnel paths. The exact approach for traffic distrib= ution, or the distribution weights is outside the scope of this specificati= on. In a very simplistic approach, assuming the established tunnel paths ha= ve symmetric characteristics, the packets can be equally distributed on all= the available tunnel paths. In a different scenario when the links have di= fferent speeds, the chosen approach can be based on weighted distribution (= Ex: n:m ratio). However, in any of these chosen approaches, implementations= have to be sensitive to issues related to asymmetric link characteristics = and the resulting issues such as re-ordering, buffering and the impact to t= he application performance. Care must be taken to ensure there is no negati= ve impact to the application performance due to the use of this approach. =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97- OD: 3.2. Traffic distribution schemes When receiving packets from the MN, the MAG distributes packets over tunnels that have been established. Traffic distribution can be managed either on a per-flow or on a per-packet basis: o Per-flow traffic management: each IP flow (both upstream and downstream) is mapped to a given tunnel, corresponding to a given WAN interface. Flow binding extension [RFC6089] is used to exchange, and synchronize, IP flow management policies (i.e. rules associating traffic selectors [RFC6088] to a tunnel). o Per-packet management: the LMA and the MAG distribute packets, belonging to a same IP flow, over more than one bindings (i.e. more than one WAN interface). Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. For example, the algorithm may give precedence to one given access: the MAG overflows traffic from the primary access, e.g. WLAN, to the second one, only when load on primary access reaches a given threshold. The distribution algorithm is left to implementer but whatever the algorithm is, packets distribution likely introduces packet latency and out-of- order delivery. LMA and MAG shall thus be able to make reordering before packets delivery. Sequence number can be can be used for that purpose, for example using GRE with sequence number option [RFC5845]. However, more detailed considerations on reordering and IP packet distribution scheme (e.g. definition of packets distribution algorithm) are out the scope of this document. Because latency introduced by per-packet can cause injury to some application, per-flow and per-packet distribution schemes could be used in conjunction. For example, high throughput services (e.g. video streaming) may benefit from per-packet distribution scheme, while latency sensitive applications (e.g. VoIP) are not be spread over different WAN paths. IP flow mobility extensions, [RFC6089] and [RFC6088], can be used to provision the MAG with such flow policies. On 8/15/17, 10:46 AM, "Warren Kumari" > wrote: This document is on Thursday's telechat - I have not seen proposed text to address my concerns, and so I'm continuing to hold my DISCUSS position. W On Wed, Aug 2, 2017 at 5:18 PM, > wrote: Hello Please see inline Pierrick Sent from my cell phone, mind the typos. -------- Message d'origine -------- De : Warren Kumari > Date : 02/08/2017 22:23 (GMT+01:00) =C0 : The IESG > Cc : draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen >, dmm-chairs@ietf.or= g, jouni.nospam@gmail.com, dmm@ietf.org Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Warren Kumari has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3.2. Traffic distribution schemes "Per-packet management: the LMA and the MAG distribute packets, belonging t= o a same IP flow, over more than one bindings (i.e. more than one WAN interface)." This immediately made my out-of-order-packets antenna pop up, so I read the section looking for mitigations. The very next sentence reads: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. " -- the fact that this sentence is a: malformed and b: hand-wavy did nothing to allay my concerns, so I read further: "The distribution algorithm is left to implementer but whatever the algorithm is= , packets distribution likely introduces packet latency and out-of-order delivery. LMA and MAG shall thus be able to make reordering before packets delivery." - I agree with the first sentence (although it is poorly worded)= , but the second sentence doesn't follow from the first; "shall thus be able to" implies that the prior text somehow provides a solution, not points out a problem (the sentence is also malformed)-- I think you mean something like "The LMA and MAG thus need to be able reorder packets to their original order before delivery." This then continues with "Sequence number can be can be used for that purpose, for example using GRE with sequence number option [RFC5845]." - I think tha= t the actual reference should be RFC2890, but regardless of this, I don't think that what you are proposing works - "The Sequence Number field is used to maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, emphasis added). This means that sequence numbers are local to the tunnel, and (as I understand it) your solution involves diverse tunnels. Further, Section 2.2. Sequence Number says: "The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number." - if you are proposing using a single sequence number space for multiple tunnels, you will end up with sequence number space gabs, and lots of buffering, etc. The section ends with: "However, more detailed considerations on reordering and IP packet distribution scheme (e.g. definition of packet= s distribution algorithm) are out the scope of this document." - I think that= , unless the prior paragraph is significantly reworked, it should not try and suggest any mitigations. ok The whole idea of striping packets of a flow across (notably) different transports seems like a really bad idea to me -- is it actually needed? some use-cases implement per-packet distribution. However this document does not aim to make recommendation on the way to distribute packets ___________________________________________________________________________= ______________________________________________ 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. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --_000_D5B8F046287689sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Warren,

Slight rewrite of this paragraph without changing the original intent.=  Removed unnecessary text; identified the key issues.

Please let me know if this addresses your concerns.

Regards
Sri


=97=97=97=97=97=97=97=97=97=97=97=97-
NEW:
3.2.  Traffic distribut=
ion schemes
When the MAG has registered multipath bindin= g with the LMA, there will be multiple established overlay tunnels between = them. The MAG and the LMA can use any one, or more of the available tunnels= paths for routing the mobile node=92s IP traffic.  This specification does not recommend, or define any spe= cific traffic distribution scheme, however it identifies two well-known app= roaches that implementations can potentially use. These approaches are, Per= -flow and Per-packet Traffic distribution schemes. 

Per-Flow Traffic Distribution:

In this approach the MAG and the LMA associa= te each of the IP flows (upstream and downstream) to a specific tunnel path= . The packets in a given IP flow are always routed on the same overlay tunn= el path; they are never split and routed concurrently on more than one tunnel path.  It is possible a g= iven flow may be moved from one tunnel path to another, but the flow is nev= er split. The decision t= o bind a given IP flow to a specific tunnel path is based on traffic distribution policy. This traffic distribution po= licy is either statically configured on both the MAG and the LMA, or dynami= cally negotiated  over Proxy Mobile IPv6 signaling.   The Flow Bi= nding extension [6089] defines the mechanism and the semantics for exchanging the traffic policy between two tunnel pee= rs and the same mechanism and the mobility options are used here.

Per-Packet Traffic Distribution:<= /div> 
In this approach, packets belonging a given =
IP flow will be split and routed across more than one tunnel paths. The exa=
ct approach for traffic distribution, or the distribution weights is outsid=
e the scope of this specification. In a very simplistic approach, assuming =
the established tunnel paths have symmetric characteristics, the packets ca=
n be equally distributed on all the available tunnel paths. In a different =
scenario when the links have different speeds, the chosen approach can be based on weighted distribution =
(Ex: n:m ratio). However, in any of these chosen approaches, implementation=
s have to be sensitive to issues related to asymmetric link characteristics=
 and the resulting issues such as re-ordering, buffering and the impact to =
the application performance. Care must be taken to ensure there is no negat=
ive impact to the application performance due to the use of this approach.<=
/span>
=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=
=97=97=97=97=97=97-
OD:
3.2.  Traffic distribut=
ion schemes
   When receiving packe=
ts from the MN, the MAG distributes packets over
   tunnels that have been established.  Traffic distribution can be
   managed either on a per-flow or on a per-packet basis:

   o  Per-flow traffic =
management: each IP flow (both upstream and
      downstream) is mapped to a given tunnel, corresponding to a given
      WAN interface.  Flow binding extension [RFC6089] is used to
      exchange, and synchronize, IP flow management policies (i.e. rules
      associating traffic selectors [RFC6088] to a tunnel).

   o  Per-packet management: the LMA and the MAG distribute packets,
      belonging to a same IP flow, over more than one bindings (i.e.
      more than one WAN interface).  Packet distribution can be done
      either at the transport level, e.g. using MPTCP or at When
      operating at the IP packet level, different packets distribution
      algorithms are possible.  For example, the algorithm may give
      precedence to one given access: the MAG overflows traffic from the
      primary access, e.g.  WLAN, to the second one, only when load on
      primary access reaches a given threshold.  The distribution
      algorithm is left to implementer but whatever the algorithm is,
      packets distribution likely introduces packet latency and out-of-
      order delivery.  LMA and MAG shall thus be able to make reordering
      before packets delivery.  Sequence number can be can be used for
      that purpose, for example using GRE with sequence number option
      [RFC5845].  However, more detailed considerations on reordering
      and IP packet distribution scheme (e.g. definition of packets
      distribution algorithm) are out the scope of this document.

   Because latency introduced by per-packet can cause injury to some
   application, per-flow and per-packet distribution schemes could be
   used in conjunction.  For example, high throughput services (e.g.
   video streaming) may benefit from per-packet distribution scheme,
   while latency sensitive applications (e.g.  VoIP) are not be spread
   over different WAN paths.  IP flow mobility extensions, [RFC6089] and
   [RFC6088], can be used to provision the MAG with such flow policies.=




On 8/15/17, 10:46 AM, "Warren Kumari" <warren@kumari.net> wrote:

This document is on Thursday's telechat - I have not seen proposed
text to address my concerns, and so I'm continuing to hold my DISCUSS<= /div>
position.

W

On Wed, Aug 2, 2017 at 5:18 PM,  <pierrick.seite@orange.com> wrote:
Hello

Please see inline

Pierrick



Sent from my cell phone, mind the typos.

-------- Message d'origine --------
De : Warren Kumari <warren@kum= ari.net>
Date : 02/08/2017 22:23 (GMT+01:00)
=C0 : The IESG <iesg@ietf.org&= gt;
Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: = (with
DISCUSS)

Warren Kumari has entered the following ballot position for
draft-ietf-dmm-mag-multihoming-04: Discuss

When responding, please keep the subject line intact and reply to all<= /div>
email addresses included in the To and CC lines. (Feel free to cut thi= s
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------=
DISCUSS:
----------------------------------------------------------------------=

Section 3.2.  Traffic distribution schemes
"Per-packet management: the LMA and the MAG distribute packets, b= elonging to
a
same IP flow, over more than one bindings (i.e. more than one WAN
interface)."
This immediately made my out-of-order-packets antenna pop up, so I rea= d the
section looking for mitigations. The very next sentence reads: "P= acket
distribution can be done either at the transport level, e.g. using MPT= CP or
at
When operating at the IP packet level, different packets distribution<= /div>
algorithms are possible. " -- the fact that this sentence is a: m= alformed
and
b: hand-wavy did nothing to allay my concerns, so I read further: &quo= t;The
distribution algorithm is left to implementer but whatever the algorit= hm is,
packets distribution likely introduces packet latency and out-of-order=
delivery.  LMA and MAG shall thus be able to make reordering= before packets
delivery." - I agree with the first sentence (although it is poor= ly worded),
but the second sentence doesn't follow from the first; "shall thu= s be able
to"
implies that the prior text somehow provides a solution, not points ou= t a
problem (the sentence is also malformed)-- I think you mean something = like
"The
LMA and MAG thus need to be able reorder packets to their original ord= er
before
delivery."

This then continues with "Sequence number can be can be used for = that
purpose,
for example using GRE with sequence number option [RFC5845]." - I= think that
the actual reference should be RFC2890, but regardless of this, I don'= t
think
that what you are proposing works - "The Sequence Number field is= used to
maintain sequence of packets **within** the GRE Tunnel." (from RF= C2890,
emphasis added). This means that sequence numbers are local to the tun= nel,
and
(as I understand it) your solution involves diverse tunnels. Further,<= /div>
Section
2.2. Sequence Number says: "The receiver may perform a small amou= nt of
buffering in an attempt to recover the original sequence of transmitte= d
packets. In this case, the packet may be placed in a buffer sorted by<= /div>
sequence
number." - if you are proposing using a single sequence number sp= ace for
multiple tunnels, you will end up with sequence number space gabs, and= lots
of
buffering, etc. The section ends with: "However, more detailed
considerations
on reordering  and IP packet distribution scheme (e.g. defin= ition of packets
distribution algorithm) are out the scope of this document." - I = think that,
unless the prior paragraph is significantly reworked, it should not tr= y and
suggest any mitigations.

ok

The whole idea of striping packets of a flow across (notably) differen= t
transports seems like a really bad idea to me -- is it actually needed= ?

some use-cases implement per-packet distribution. However this documen= t
does not aim to make recommendation on the way to distribute packets


______________________________________________________________________= ___________________________________________________

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 messag= es
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform= e ou
falsifie. Merci.

This message and its attachments may contain confidential or privilege= d
information that may be protected by law;
they should not be distributed, used or copied without authorisation.<= /div>
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.



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing=
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

--_000_D5B8F046287689sgundaveciscocom_-- From nobody Tue Aug 15 23:33:17 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EF0126B71; Tue, 15 Aug 2017 23:33:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150286519610.12480.4832297974578384362.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 23:33:16 -0700 Archived-At: Subject: [DMM] Adam Roach's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 06:33:16 -0000 Adam Roach has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Figure 1 labels the bottom-left most construct "Flow0-4" -- I suspect this should be "Flow-4." I see the requests to remove MPTCP from the document, and the rationale seems sound. If, by some chance, any mention of MPTCP remains in the final version, please make sure it gets expanded (as an acronym) and cited. The final paragraph in section 3.2 starts with "Because latency introduced by..." -- this isn't the reason damage can arise. The problem is the *variation* in latency. Suggest something like: "Because the variation in packet latency, also known as jitter, introduced by per-packet scheduling between access networks can cause..." Section 4.1, definition of If-ATT -- suggest citing the specific section: "[RFC5213] section 8.5." Section 4.1, definition of If-Label -- the value of 0 appears to be reserved? Ideally, this would prescribe specific behavior for an LMA if they receive an If-Label of 0. Section 4.1, definition of BID -- same comment; ideally, this would specify recipient behavior if set to 0 or 255. Section 4.3 defines a new response code for LMAs that don't implement this spec. Existing, already deployed LMAs will necessarily have a different reaction to receiving these unknown options than sending this response code. This section should provide guidance for MAGs letting them know what observable behavior they should expect when sending these options to LMAs unaware of this extension at all. Additionally, _if_ such observable behavior is sufficient for the MAG to understand what is happening, I would assert that the new response code is unnecessary and should be removed. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - MAG - Mobile Access Gateway (in the title) - GRE - Generic Routing Encapsulation - LMA - Local Mobility Anchor - LTE - Long-Term Evolution - MN - Mobile Node - BCE - Bonding Channel Entity From nobody Wed Aug 16 18:50:00 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CA7132407 for ; Wed, 16 Aug 2017 18:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAuSoRBWpPgt for ; Wed, 16 Aug 2017 18:49:52 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBBA132441 for ; Wed, 16 Aug 2017 18:49:46 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 5so4627665wrz.5 for ; Wed, 16 Aug 2017 18:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HBlj1gE7Fk5hdjL2BPypPpC73eXHEU6hWdD40XhA8SI=; b=erOAR76Vh9zryvs8Ca4/jFvoZg+VkDBK6Wexdjblcp4dCQE/acMhs5lgW1jSQlnbRj WKs0EgnDjsoH/sxC/xK2ta1CezBh6yOX3ravKaeIShoj80g8/C1EmpiZCZGjSP88KxtM wmJvvo7DW4g8Tj4g3BFPNi/QIBO1wdyqz9iGK16au57M6QQR00IBgs7PfNbsuZgkr6tq GROMqEFmd9vRIe2llkVo5dqOqFpCFFNFvgvPuPK2+boZ7hOZnb9E71VP7yagjTZlQE23 68UzMfOgRC1M2xcdxnB+LQOH6bj+UqXeGB/qjtBCj22zG8cMGyEjKvCc4LY4r4wWx3P4 R8Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HBlj1gE7Fk5hdjL2BPypPpC73eXHEU6hWdD40XhA8SI=; b=rxBgDWI1ZBRXZUxiHTYW2xGqy7Zj4Odb8wSSljW/4ewyBlNiK5g03agzziAWY0JPoA JBi8+dP3BbaDz2xz2+dRHN4s7++eTjkWQjD5FlDkDAzmPnsVsX7nI8J3gSrNb/Fl8vAu Z8tNl+/cThDFrBgVnjGUPttx7ZQz7FvDAO6RlGQD4nryT1vfCwcnRwdxR8WrrQ577OfR Ma9FeQU+hM6qcpSP6i8JnjvzsiiHaXkRBe45ryKT54Tlc5nRW/qQmwfBE87yWWqGftXo G+jagRRb7i8tAYewbsQpHPVrcRoc1O3AhdGhg/XYx9tz78nsZuOZpbRGGQHGF6vgygsT LiQw== X-Gm-Message-State: AHYfb5geNFZCGEjsSIP5ZqIP0Q46in/M65wOtWLVCxXawJ/TEZ9TXXsM 3erIP1zBUiUVr8QVU8R6NPx0X6tMsupO X-Received: by 10.28.100.132 with SMTP id y126mr157094wmb.18.1502934584839; Wed, 16 Aug 2017 18:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Wed, 16 Aug 2017 18:49:04 -0700 (PDT) In-Reply-To: References: <12323_1501708737_598241C1_12323_28_1_p123omkxf24p6fskvw4pi68k.1501708734898@email.android.com> From: Warren Kumari Date: Wed, 16 Aug 2017 21:49:04 -0400 Message-ID: To: "Sri Gundavelli (sgundave)" Cc: "pierrick.seite@orange.com" , The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:49:54 -0000 Thank you. This addresses my concerns. W On Tue, Aug 15, 2017 at 9:40 PM, Sri Gundavelli (sgundave) wrote: > Hi Warren, > > Slight rewrite of this paragraph without changing the original intent. > Removed unnecessary text; identified the key issues. > > Please let me know if this addresses your concerns. > > Regards > Sri > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94- > > NEW: > > 3.2. Traffic distribution schemes > > When the MAG has registered multipath binding with the LMA, there will be > multiple established overlay tunnels between them. The MAG and the LMA ca= n > use any one, or more of the available tunnels paths for routing the mobil= e > node=E2=80=99s IP traffic. This specification does not recommend, or def= ine any > specific traffic distribution scheme, however it identifies two well-know= n > approaches that implementations can potentially use. These approaches are= , > Per-flow and Per-packet Traffic distribution schemes. > > Per-Flow Traffic Distribution: > > In this approach the MAG and the LMA associate each of the IP flows > (upstream and downstream) to a specific tunnel path. The packets in a giv= en > IP flow are always routed on the same overlay tunnel path; they are never > split and routed concurrently on more than one tunnel path. It is possib= le > a given flow may be moved from one tunnel path to another, but the flow i= s > never split. The decision to bind a given IP flow to a specific tunnel pa= th > is based on traffic distribution policy. This traffic distribution policy= is > either statically configured on both the MAG and the LMA, or dynamically > negotiated over Proxy Mobile IPv6 signaling. The Flow Binding extensio= n > [6089] defines the mechanism and the semantics for exchanging the traffic > policy between two tunnel peers and the same mechanism and the mobility > options are used here. > > Per-Packet Traffic Distribution: > > In this approach, packets belonging a given IP flow will be split and rou= ted > across more than one tunnel paths. The exact approach for traffic > distribution, or the distribution weights is outside the scope of this > specification. In a very simplistic approach, assuming the established > tunnel paths have symmetric characteristics, the packets can be equally > distributed on all the available tunnel paths. In a different scenario wh= en > the links have different speeds, the chosen approach can be based on > weighted distribution (Ex: n:m ratio). However, in any of these chosen > approaches, implementations have to be sensitive to issues related to > asymmetric link characteristics and the resulting issues such as > re-ordering, buffering and the impact to the application performance. Car= e > must be taken to ensure there is no negative impact to the application > performance due to the use of this approach. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94- > > OD: > > 3.2. Traffic distribution schemes > > When receiving packets from the MN, the MAG distributes packets over > tunnels that have been established. Traffic distribution can be > managed either on a per-flow or on a per-packet basis: > > o Per-flow traffic management: each IP flow (both upstream and > downstream) is mapped to a given tunnel, corresponding to a given > WAN interface. Flow binding extension [RFC6089] is used to > exchange, and synchronize, IP flow management policies (i.e. rules > associating traffic selectors [RFC6088] to a tunnel). > > o Per-packet management: the LMA and the MAG distribute packets, > belonging to a same IP flow, over more than one bindings (i.e. > more than one WAN interface). Packet distribution can be done > either at the transport level, e.g. using MPTCP or at When > operating at the IP packet level, different packets distribution > algorithms are possible. For example, the algorithm may give > precedence to one given access: the MAG overflows traffic from the > primary access, e.g. WLAN, to the second one, only when load on > primary access reaches a given threshold. The distribution > algorithm is left to implementer but whatever the algorithm is, > packets distribution likely introduces packet latency and out-of- > order delivery. LMA and MAG shall thus be able to make reordering > before packets delivery. Sequence number can be can be used for > that purpose, for example using GRE with sequence number option > [RFC5845]. However, more detailed considerations on reordering > and IP packet distribution scheme (e.g. definition of packets > distribution algorithm) are out the scope of this document. > > Because latency introduced by per-packet can cause injury to some > application, per-flow and per-packet distribution schemes could be > used in conjunction. For example, high throughput services (e.g. > video streaming) may benefit from per-packet distribution scheme, > while latency sensitive applications (e.g. VoIP) are not be spread > over different WAN paths. IP flow mobility extensions, [RFC6089] and > [RFC6088], can be used to provision the MAG with such flow policies. > > > > > > On 8/15/17, 10:46 AM, "Warren Kumari" wrote: > > This document is on Thursday's telechat - I have not seen proposed > text to address my concerns, and so I'm continuing to hold my DISCUSS > position. > > W > > On Wed, Aug 2, 2017 at 5:18 PM, wrote: > > Hello > > Please see inline > > Pierrick > > > > Sent from my cell phone, mind the typos. > > -------- Message d'origine -------- > De : Warren Kumari > Date : 02/08/2017 22:23 (GMT+01:00) > =C3=80 : The IESG > Cc : draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen > , dmm-chairs@ietf.org, jouni.nospam@gmail.com, > dmm@ietf.org > Objet : Warren Kumari's Discuss on draft-ietf-dmm-mag-multihoming-04: (wi= th > DISCUSS) > > Warren Kumari has entered the following ballot position for > draft-ietf-dmm-mag-multihoming-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 3.2. Traffic distribution schemes > "Per-packet management: the LMA and the MAG distribute packets, belonging= to > a > same IP flow, over more than one bindings (i.e. more than one WAN > interface)." > This immediately made my out-of-order-packets antenna pop up, so I read t= he > section looking for mitigations. The very next sentence reads: "Packet > distribution can be done either at the transport level, e.g. using MPTCP = or > at > When operating at the IP packet level, different packets distribution > algorithms are possible. " -- the fact that this sentence is a: malformed > and > b: hand-wavy did nothing to allay my concerns, so I read further: "The > distribution algorithm is left to implementer but whatever the algorithm = is, > packets distribution likely introduces packet latency and out-of-order > delivery. LMA and MAG shall thus be able to make reordering before packe= ts > delivery." - I agree with the first sentence (although it is poorly worde= d), > but the second sentence doesn't follow from the first; "shall thus be abl= e > to" > implies that the prior text somehow provides a solution, not points out a > problem (the sentence is also malformed)-- I think you mean something lik= e > "The > LMA and MAG thus need to be able reorder packets to their original order > before > delivery." > > This then continues with "Sequence number can be can be used for that > purpose, > for example using GRE with sequence number option [RFC5845]." - I think t= hat > the actual reference should be RFC2890, but regardless of this, I don't > think > that what you are proposing works - "The Sequence Number field is used to > maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, > emphasis added). This means that sequence numbers are local to the tunnel= , > and > (as I understand it) your solution involves diverse tunnels. Further, > Section > 2.2. Sequence Number says: "The receiver may perform a small amount of > buffering in an attempt to recover the original sequence of transmitted > packets. In this case, the packet may be placed in a buffer sorted by > sequence > number." - if you are proposing using a single sequence number space for > multiple tunnels, you will end up with sequence number space gabs, and lo= ts > of > buffering, etc. The section ends with: "However, more detailed > considerations > on reordering and IP packet distribution scheme (e.g. definition of pack= ets > distribution algorithm) are out the scope of this document." - I think th= at, > unless the prior paragraph is significantly reworked, it should not try a= nd > suggest any mitigations. > > ok > > > The whole idea of striping packets of a flow across (notably) different > transports seems like a really bad idea to me -- is it actually needed? > > some use-cases implement per-packet distribution. However this document > does not aim to make recommendation on the way to distribute packets > > > > _________________________________________________________________________= ________________________________________________ > > 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 re= cu > 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 o= u > 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 bee= n > modified, changed or falsified. > Thank you. > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Aug 16 18:52:45 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C8A13240C; Wed, 16 Aug 2017 18:52:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150293476142.12406.17685050843215071001.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 18:52:41 -0700 Archived-At: Subject: [DMM] Warren Kumari's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:52:41 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sri Gundavelli's proposal text in https://mailarchive.ietf.org/arch/msg/dmm/hh4xrA5vOkC3NuH3l-e3zH9-aM8 addresses my concern. Thanks Sri, W -------------- Old discuss position for posterity: "Section 3.2. Traffic distribution schemes "Per-packet management: the LMA and the MAG distribute packets, belonging to a same IP flow, over more than one bindings (i.e. more than one WAN interface)." This immediately made my out-of-order-packets antenna pop up, so I read the section looking for mitigations. The very next sentence reads: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. " -- the fact that this sentence is a: malformed and b: hand-wavy did nothing to allay my concerns, so I read further: "The distribution algorithm is left to implementer but whatever the algorithm is, packets distribution likely introduces packet latency and out-of-order delivery. LMA and MAG shall thus be able to make reordering before packets delivery." - I agree with the first sentence (although it is poorly worded), but the second sentence doesn't follow from the first; "shall thus be able to" implies that the prior text somehow provides a solution, not points out a problem (the sentence is also malformed)-- I think you mean something like "The LMA and MAG thus need to be able reorder packets to their original order before delivery." This then continues with "Sequence number can be can be used for that purpose, for example using GRE with sequence number option [RFC5845]." - I think that the actual reference should be RFC2890, but regardless of this, I don't think that what you are proposing works - "The Sequence Number field is used to maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, emphasis added). This means that sequence numbers are local to the tunnel, and (as I understand it) your solution involves diverse tunnels. Further, Section 2.2. Sequence Number says: "The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number." - if you are proposing using a single sequence number space for multiple tunnels, you will end up with sequence number space gabs, and lots of buffering, etc. The section ends with: "However, more detailed considerations on reordering and IP packet distribution scheme (e.g. definition of packets distribution algorithm) are out the scope of this document." - I think that, unless the prior paragraph is significantly reworked, it should not try and suggest any mitigations. The whole idea of striping packets of a flow across (notably) different transports seems like a really bad idea to me -- is it actually needed?" From nobody Wed Aug 16 19:13:25 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E256F132428 for ; Wed, 16 Aug 2017 19:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUsTaSmUC5mR for ; Wed, 16 Aug 2017 19:13:20 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCB013241A for ; Wed, 16 Aug 2017 19:13:19 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id y129so32665643pgy.4 for ; Wed, 16 Aug 2017 19:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=1leOCRQqPDk8gfh0OMQ69c6spowo2qZH4YIhc1BaeBU=; b=grij1FevdtAhCWpmjYOerhx1WiAjurA7sDMTjG29pG6Ja0gUj0jGaC4xlAAkAWMYaC JbS5iEXlGBQM2V0gPsyqKP9lVhBB5SNRFsr9FeTNuz51ScR0emIUIZNnqTwp1nWZjGw9 0on26lmc3xpYJ5aujzxl8Y5c5lqCwNV8HZ/eKGDS38nZc0f/yVu/8mXml1Uj4gy8GTqL INbDuX6ZPBONr+QfJn8RM7q+ApdYXqKlmwBYK6o97dT5j5WGy6cEu0ANwXpbbkBDBtTj G4Ya9P9KnrrGxos7MY4OhNWz53OY1Pm2w9lCqQIJOAJjuSlaitpEsjgiRdRQnHbPBR7K 60QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=1leOCRQqPDk8gfh0OMQ69c6spowo2qZH4YIhc1BaeBU=; b=LKRjRVTOOU8hz/Kkg2MJhIfH3LWNGhuDEK8lcTeUqY1Fx8Gm6gU6hNIUiAsnNxXS43 WPO8uc7AXBcs30QcCStPG2rb+Xf4+XnJgjpYFjULG1MNIlQ+UEgsti7MqRyl8m6pcYge WHu7Oys/PxpUSVGKTeVl4u+nIz9RnjwuXCHkk2ayLiVFTW/mtkWJrZktmOEQTWzjyT7w CV8PXYEBiAKU/uDqJUCSV+rncatxbZn9jAGjLqo5Z48nI4L+UxAPCqMaqjA6QRrlqC+/ /mL4OfdFf8RYhRLgXhEn9x8k69DQLfLiA8/RP/4rweKgx8c+nPQsXCA2rYJSclxg1RM3 22oA== X-Gm-Message-State: AHYfb5j+z/xEGv/BT8PKKUGUS6HISMN4kdl/YZ8XJMgKJVqo1RK80Egt BGprWO9Gj9V/XKD9 X-Received: by 10.98.33.148 with SMTP id o20mr3547512pfj.89.1502935999245; Wed, 16 Aug 2017 19:13:19 -0700 (PDT) Received: from LAPTOPFOEU10F0 ([211.50.153.252]) by smtp.gmail.com with ESMTPSA id u69sm3971469pfa.70.2017.08.16.19.13.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 19:13:18 -0700 (PDT) From: "Seil Jeon" To: "'dmm'" References: <148774673290.16706.4569151626444979623.idtracker@ietfa.amsl.com> In-Reply-To: <148774673290.16706.4569151626444979623.idtracker@ietfa.amsl.com> Date: Thu, 17 Aug 2017 11:13:15 +0900 Message-ID: <006801d316fe$6402b680$2c082380$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHLT2iJYIX1jVIBbfj3XU2nBMODVaKXXQgA Content-Language: en-us Archived-At: Subject: [DMM] FW: I-D Action: draft-ietf-dmm-deployment-models-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:13:22 -0000 Hi All, As we were requested in the Prague meeting by chair, we ask your review and feedback on the current version. Then, we'll try to go for last call after addressing it. Regards, Seil Jeon -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, February 22, 2017 3:59 PM To: i-d-announce@ietf.org Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-deployment-models-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : DMM Deployment Models and Architectural Considerations Authors : Sri Gundavelli Seil Jeon Filename : draft-ietf-dmm-deployment-models-01.txt Pages : 15 Date : 2017-02-21 Abstract: This document identifies the deployment models for Distributed Mobility Management architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-deployment-models/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-deployment-models-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-deployment-models-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Aug 16 20:04:09 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B104132659; Wed, 16 Aug 2017 20:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DesHhrg-BE7; Wed, 16 Aug 2017 20:04:04 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8817132626; Wed, 16 Aug 2017 20:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18584; q=dns/txt; s=iport; t=1502939042; x=1504148642; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qdKlP+XoG3DcmU1JeFHHfc3YO3Ms4KqDa6id+4Ftv34=; b=gUifzfhPxRhu3WTANAMl994LdRmKLKIvqdns2sg43JruQR4GeT7v7e9g IFXtMnfzBOc/Y8MjUNpjcZK3hE35KoWIHwHO4iAGaq7yXncDRcVBqDSXp fbC/Y0dEpZdTVHO4U+jGYOmYPp2w2takhWhF8v51Fq8q1Sq91D5pa3jxC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAABOB5VZ/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEVB4RTiTiQEoFuiDiILIU2DoIELIRMTwKERj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGQEEAXIHBQsCAQYCPwchERQRAgQBDQUbiTFMAw0IEIw2oAqHPA2EF?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiCAoFMgWODJ4JXgWkBCwYCARsKLwK?= =?us-ascii?q?FPAWJfocXhwaHcTwCh1KHeIR2ghCFYIN7hnGJaIJOiWQBHzh/C3cVSYVMgU52A?= =?us-ascii?q?YcoAiQHgQWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,385,1498521600"; d="scan'208,217";a="472628853" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2017 03:04:01 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v7H341vL001866 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2017 03:04:01 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Aug 2017 22:04:00 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 16 Aug 2017 22:04:01 -0500 From: "Sri Gundavelli (sgundave)" To: Kathleen Moriarty , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AQHTFwV5phU5hY4eRk6/IO/vBdSuEQ== Date: Thu, 17 Aug 2017 03:04:01 +0000 Message-ID: References: <150161840636.12123.2784912255737760138.idtracker@ietfa.amsl.com> In-Reply-To: <150161840636.12123.2784912255737760138.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: multipart/alternative; boundary="_000_D5BA4FC7287B1Fsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 03:04:08 -0000 --_000_D5BA4FC7287B1Fsgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kathleen and Hilarie, Thank you for reviewing the documents and the feedback. Please see inline. > For security considerations, the authors predictably defer to RFC5213, = =93Proxy Mobile IPv6=94, and assert "no impact on the protocol security". H= owever, there is one security issue that is mentioned in RFC5213 that is ex= acerbated by the current draft. I.e., > To address the threat related to a compromised mobile access gateway, th= e local mobility anchor, before accepting a Proxy Binding Update message fo= r a given mobile node, may ensure that the mobile node is attached to the m= obile access gateway that sent the Proxy Binding Update message. A MAG is required to prove the presence of a mobile node=92s presence on it= s (ingress) access link. That assertion needs to be validated by the LMA. B= ut, MAG using a single tunnel or multiple tunnels has no relation to this i= ssue. The LMA identifies the MAG using the MAG-NAI and not using Care-of Ad= dress; a new option, MAG Identifier option is defined in section 4.2 for th= is purpose. > Is there any reason to worry about reuse of CoAs? Could packets from one = tunnel get a CoA that was recently used by another tunnel, and could delaye= d packets get routed through the wrong tunnel? Just asking. The tunnels between LMA and MAG are dynamically established after protocol = signaling. The idea of CoA re-use between MAG=92s and delayed packets getti= ng delivered to a different MAG is impossible to realize even in lab condit= ions. It is possible there are two MAG=92s in a given access network and on= e looses the CoA and the other MAG gets the name address. But, the tunnels = comes up after PBU/PBA exchange which introduces some delay, and so the pos= sibility of packets from previous MAG-era getting showing up at the new MAG= is nearly impossible and is not worth mentioning it, IMO. > Nits. On page 3 there is a paragraph beginning =93In the continuation of = c, a Proxy Mobile IPv6 ..." There is no explanation of =93c". Is this a rem= nant of a list of items "a, b, c"? Fixed in -04 version > On page 4 there is Figure 1 showing four flows and two tunnels. The We just wanted to hint that the Flow-4 is based on per-packet load balancin= g using both the paths, whereas the other flows are routed based on Per-flo= w load balancing. But, I think the comment is still valid. We should show t= he use of a single forwarding mode and not mix both the modes. Minor nit, w= ill fix it. Thank you for your review. Regards Sri =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97 Security review of MAG Multipath Binding Option draft-ietf-dmm-mag-multihoming-03.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. If you've been frustrated by being limited to only one IP tunnel between a mobile access gateway and a local mobility anchor, then you'll be glad to know that this draft fixes the problem and enables multiple care-of addresses and IP tunnels. Now mobile devices can be assigned to any applicable tunnel between the MAG and the LMA. For security considerations, the authors predictably defer to RFC5213, "Proxy Mobile IPv6", and assert "no impact on the protocol security". However, there is one security issue that is mentioned in RFC5213 that is exacerbated by the current draft. I.e., To address the threat related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may ensure that the mobile node is attached to the mobile access gateway that sent the Proxy Binding Update message. The RFC has no recommendation for a solution, but because there are now multiple tunnels, this assurance may be more difficult to obtain. For example, if the LMA expects to contact some kind of trusted entity that is keeping track of the mobile devices that the MAG is sending on a tunnel, then the MAG and LMA may now have to keep track of multiple trusted entities, one for each tunnel. Whether or not this is a realistic scenario is not something that I can judge because RFC5213 punts on what seems to be an important security issue. Is there any reason to worry about reuse of CoAs? Could packets from one tunnel get a CoA that was recently used by another tunnel, and could delayed packets get routed through the wrong tunnel? Just asking. Nits. On page 3 there is a paragraph beginning "In the continuation of c, a Proxy Mobile IPv6 ..." There is no explanation of "c". Is this a remnant of a list of items "a, b, c"? On page 4 there is Figure 1 showing four flows and two tunnels. The text immediately preceding that says that "Flow-1,2 and 3 are distributed either on Tunnel-1 (over LTE) or Tunnel-2 (over WLAN)", but the diagram shows Flow-1 on Tunnel-1 and Flow-2,3 on Tunnel-2. I think the text should indicate that the first three flows are each assigned to a single tunnel. The authors probably meant that either Tunnel-1 or Tunnel-2 could have been assigned, but the choice was to put Flow-1 on Tunnel-1 and the other flows on Tunnel-2. I had to read over the text several times before I was sure of the intent. Hilarie On 8/1/17, 1:13 PM, "Kathleen Moriarty" > wrote: Kathleen Moriarty has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. I had the same concern as the SecDir reviewer in reading the draft, the concern about leaking traffic as a resul= t of multiple tunnels is not addressed in the security considerations section. Hilary's writeup is quite helpful https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html --_000_D5BA4FC7287B1Fsgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <896E500E8BFD234C9311A3D250586504@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kathleen and Hilarie,

Thank you for reviewing the documents a= nd the feedback. Please see inline.



> For security considerations, the authors predictably defer to RFC= 5213, =93Proxy Mobile IPv6=94, and assert "no impact on the protocol s= ecurity". However, there is one security issue that is mentioned in RF= C5213 that is exacerbated by the current draft. I.e.,

>  To address the threat related to a compromised mobile acces= s gateway, the local mobility anchor, before accepting a Proxy Binding Upda= te message for a given mobile node, may ensure that the mobile node is atta= ched to the mobile access gateway that sent the Proxy Binding Update message.


A MAG is required to prove the presence of a mobile node=92s presen= ce on its (ingress) access link. That assertion needs to be validated by th= e LMA. But, MAG using a single tunnel or multiple tunnels has no relation t= o this issue. The LMA identifies the MAG using the MAG-NAI and not using Care-of Address; a new option, MAG Ide= ntifier option is defined in section 4.2 for this purpose.





> Is there any reason to worry about reuse of CoAs? Could packets f= rom one tunnel get a CoA that was recently used by another tunnel, and coul= d delayed packets get routed through the wrong tunnel? Just asking.

The tunnels between LMA and MAG are = dynamically established after protocol signaling. The idea of CoA re-use be= tween MAG=92s and delayed packets getting delivered to a different MAG is i= mpossible to realize even in lab conditions. It is possible there are two MAG=92s in a given access network and one loo= ses the CoA and the other MAG gets the name address. But, the tunnels comes= up after PBU/PBA exchange which introduces some delay, and so the possibil= ity of packets from previous MAG-era getting showing up at the new MAG is nearly impossible and is not worth me= ntioning it, IMO.





> Nits. On page 3 there is a paragra= ph beginning =93In the continuation of c, a Proxy Mobile IPv6 ..." The= re is no explanation of =93c". Is this a remnant of a list of items &q= uot;a, b, c"?

Fixed in -04 version





> On page 4 there is Figure 1 showin= g four flows and two tunnels. The

We just wanted to hint that the Flow-4 is based on per-packet load = balancing using both the paths, whereas the other flows are routed based on= Per-flow load balancing. But, I think the comment is still valid. We shoul= d show the use of a single forwarding mode and not mix both the modes. Minor nit, will fix it.


Thank you for your review.


Regards
Sri







=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97
Security review of
MAG Multipath Binding Option
draft-ietf-dmm-mag-multihoming-03.txt

Do not be alarmed. I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written primarily
for the benefit of the security area directors. Document editors and
WG chairs should treat these comments just like any other last call
comments.

If you've been frustrated by being limited to only one IP tunnel
between a mobile access gateway and a local mobility anchor, then
you'll be glad to know that this draft fixes the problem and enables
multiple care-of addresses and IP tunnels. Now mobile devices can be
assigned to any applicable tunnel between the MAG and the LMA.

For security considerations, the authors predictably defer to RFC5213,=
"Proxy Mobile IPv6", and assert "no impact on the proto= col security".
However, there is one security issue that is mentioned in RFC5213 that=
is exacerbated by the current draft. I.e.,

To address the threat related to a compromised mobile access gateway,<= /div>
the local mobility anchor, before accepting a Proxy Binding Update
message for a given mobile node, may ensure that the mobile node is
attached to the mobile access gateway that sent the Proxy Binding
Update message.

The RFC has no recommendation for a solution, but because there are
now multiple tunnels, this assurance may be more difficult to obtain.<= /div>
For example, if the LMA expects to contact some kind of trusted entity=
that is keeping track of the mobile devices that the MAG is sending on=
a tunnel, then the MAG and LMA may now have to keep track of multiple<= /div>
trusted entities, one for each tunnel. Whether or not this is a
realistic scenario is not something that I can judge because RFC5213
punts on what seems to be an important security issue.

Is there any reason to worry about reuse of CoAs? Could packets from
one tunnel get a CoA that was recently used by another tunnel, and
could delayed packets get routed through the wrong tunnel? Just asking= .

Nits. On page 3 there is a paragraph beginning "In the continuati= on
of c, a Proxy Mobile IPv6 ..." There is no explanation of "c= ". Is
this a remnant of a list of items "a, b, c"?

On page 4 there is Figure 1 showing four flows and two tunnels. The
text immediately preceding that says that "Flow-1,2 and 3 are
distributed either on Tunnel-1 (over LTE) or Tunnel-2 (over WLAN)"= ;,
but the diagram shows Flow-1 on Tunnel-1 and Flow-2,3 on Tunnel-2.
I think the text should indicate that the first three flows are
each assigned to a single tunnel. The authors probably meant that
either Tunnel-1 or Tunnel-2 could have been assigned, but the choice
was to put Flow-1 on Tunnel-1 and the other flows on Tunnel-2.
I had to read over the text several times before I was sure of the
intent.

Hilarie

On 8/1/17, 1:13 PM, "Kathleen Mori= arty" <Kathleen= .Moriarty.ietf@gmail.com> wrote:

Kathleen Moriarty has entered the following ballot position for
draft-ietf-dmm-mag-multihoming-04: Discuss

When responding, please keep the subject line intact and reply to all<= /div>
email addresses included in the To and CC lines. (Feel free to cut thi= s
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------=
DISCUSS:
----------------------------------------------------------------------=

Thanks for your work on this draft.  I had the same concern = as the SecDir
reviewer in reading the draft, the concern about leaking traffic as a = result of
multiple tunnels is not addressed in the security considerations secti= on.
Hilary's writeup is quite helpful






--_000_D5BA4FC7287B1Fsgundaveciscocom_-- From nobody Wed Aug 16 20:17:55 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A185132626; Wed, 16 Aug 2017 20:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhvVdjMycjIO; Wed, 16 Aug 2017 20:17:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62AC13208E; Wed, 16 Aug 2017 20:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5140; q=dns/txt; s=iport; t=1502939872; x=1504149472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O8iZnLiZWXGlhX/IpwAf37Cj52L2z55J786NK+y3ExU=; b=UDd7AYjYYgy1Gf53AtFOARbaRVA+jZ/M2tI3TgsySlZrEPhP+MT8QNJI fhucIdgvtxSO4z90t1yGre0BJBMvB/YVpIEz6AnrpeYeZzRAegKHDqnjC 0Oz1/8updLm5OJ6UJy7HL1rRfgsE0S5x5PDj7ZYiW0BEPw2DzPLeRDRwo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAACjCZVZ/5tdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEVB44LkBKTI4RlghKFRwIahCw/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?GIxFFEAIBBgIaAiYCAgIwFQULAgQBDQWKMIxFnWSCJotfAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYELgh2CAoFMhQqESCuDE4JhAQSJfhOIa4UfiC0ClECCEIVgimy?= =?us-ascii?q?JaIwyAR84gQp3FYYVgU52hykHgSuBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,385,1498521600"; d="scan'208";a="287328318" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2017 03:17:51 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7H3HpjW007135 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2017 03:17:51 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Aug 2017 22:17:51 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 16 Aug 2017 22:17:50 -0500 From: "Sri Gundavelli (sgundave)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kbW0t?= =?utf-8?Q?mag-multihoming-04:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHTCkbWqTqOB87KxkGk4BHR1eN2MaKH2QUA Date: Thu, 17 Aug 2017 03:17:50 +0000 Message-ID: References: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> In-Reply-To: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="utf-8" Content-ID: <6EEB6FCA077CDF4E8B5F0B34C26E2AA7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-mag-multihoming-04=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 03:17:54 -0000 SGkgTWlyamEuDQoNClBsZWFzZSBzZWUgYmVsb3cgYW5kIGFsc28gbGV0IHVzIGtub3cgaWYgdGhl IHRleHQgdGhhdCB3ZSBkaXNjdXNzZWQgd2l0aA0KV2FycmVuIGFkZHJlc3NlcyB5b3VyIG1haW4g Y29uY2VybnMuDQoNCg0KUmVnYXJkcw0KU3JpDQoNCg0KT24gNy8zMS8xNywgMjo0OSBQTSwgIk1p cmphIEvDvGhsZXdpbmQiIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiB3cm90ZToNCg0KPk1pcmphIEvD vGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ ZHJhZnQtaWV0Zi1kbW0tbWFnLW11bHRpaG9taW5nLTA0OiBEaXNjdXNzDQo+DQo+DQo+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPkRJU0NVU1M6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPjEpIFRoaXMgZG9jdW1lbnQg c2hvdWxkIG5vdCByZWNvbW1lbmQgdGhlIHVzZSBvZiBNUFRDUCBmb3IgdHVubmVsaW5nLCBhcw0K PlRDUC1pbi1UQ1AgdHVubmVscyBhcmUgZ2VuZXJhbGx5IG5vdCByZWNvbW1lbmQgaWYgdGhhdCBj YW4gYmUgYXZvaWRlZC4NCj5QbGVhc2UNCj5yZW1vdmUgdGhlIGZvbGxvd2luZyBwYXJ0IGZyb20g c2VjdGlvbiAzLjIgYW5kIGxlYXZlIElQLWxldmVsIHR1bm5lbGluZw0KPmFzIHRoZQ0KPm9ubHkg b3B0aW9uOiDigKjigJ5QYWNrZXQgZGlzdHJpYnV0aW9uIGNhbiBiZSBkb25lIGVpdGhlciBhdCB0 aGUgdHJhbnNwb3J0DQo+bGV2ZWwsDQo+ZS5nLiB1c2luZyBNUFRDUCDigKbigJwNCg0KDQpBY2su IFBsZWFzZSBzZWUgdGhlIG5ldyB0ZXh0Lg0KDQoNCj4NCj4yKSBGdXJ0aGVyIHRoZSBmb2xsb3dp bmcgc2VudGVuY2VzIGFsc28gaW4gc2VjdGlvbiAzLjIgc2hvdWxkIGJlIHJldmlzZWQ6DQo+4oCe Rm9yIGV4YW1wbGUsIGhpZ2ggdGhyb3VnaHB1dCBzZXJ2aWNlcyAoZS5nLg0KPiAgIHZpZGVvIHN0 cmVhbWluZykgbWF5IGJlbmVmaXQgZnJvbSBwZXItcGFja2V0IGRpc3RyaWJ1dGlvbiBzY2hlbWUs DQo+ICAgd2hpbGUgbGF0ZW5jeSBzZW5zaXRpdmUgYXBwbGljYXRpb25zIChlLmcuICBWb0lQKSBh cmUgbm90IGJlIHNwcmVhZA0KPiAgIG92ZXIgZGlmZmVyZW50IFdBTiBwYXRocy7igJwNCj5IaWdo IHRocm91Z2hwdXQgc2VydmljZXMgb25seSBiZW5lZml0IGZyb20gcGVyLXBhY2tldCBzY2hlZHVs aW5nIGlmIHRoZQ0KPnNlcnZpY2UNCj5yZXF1aXJlcyBoaWdoZXIgdGhyb3VnaHB1dCB0aGFuIG9u ZSBvZiB0aGUgbGlua3MgY2FuIHByb3ZpZGUuIEFsc28gdmlkZW8NCj5zdHJlYW1pbmcgbWF5IG5v dCBiZSBhIGdvb2QgZXhhbXBsZSBoZXJlIGJlY2F1c2UgaGlnaCBsYXRlbmN5IHZhcmlhdGlvbnMN Cj5jYW4NCj5sZWFkIHRvIHN0YWxscy4gVGhlcmVmb3JlIGluIGdlbmVyYWwgcGVyLWZsb3cgc2No ZWR1bGluZyBzaG91bGQgYmUNCj5yZWNvbW1lbmQNCj5mb3IgYWxsIHRyYWZmaWMuIEl0IGNvdWxk IHN0aWxsIGJlIGJlbmVmaWNpYWwgdG8gc2NoZWR1bGUgZmxvd3MgdGhhdA0KPnJlcXVpcmUNCj5s b3cgbGF0ZW5jeSBvdmVyIHRoZSBsaW5rIHdpdGggdGhlIGxvd2VyIGJhc2UgbGF0ZW5jeSwgb3Ig bWF5YmUgbW9yZQ0KPmltcG9ydGFudA0KPmxvd2VyIGppdHRlciwgaG93ZXZlciwgb2Z0ZW4gaXQg aXMgbm90IGtub3duIHRvIHRoZSBuZXR3b3JrIHdoYXQgdGhlDQo+cmVxdWlyZW1lbnRzIG9uIGxh dGVuY3kgYXJlIGZvciBhIGdpdmVuIGZsb3cuIFRoZXJlZm9yZSBpcyBzaG91bGQNCj5wcm9iYWJs eSBiZQ0KPnJlY29tbWVuZGVkIHRvIHNjaGVkdWxlIGFsbCB0cmFmZmljIG9uIHRoZSAiYmV0dGVy IiBsaW5rICh3aGVyZSBiZXR0ZXINCj5jYW4gYmUNCj5wcmUtY29uZmlndXJlZCBrbm93bGVkZ2Ug b3IgbWVhc3VyZWQpIGFzIGxvbmcgYXMgdGhlIGJhbmR3aWR0aCBvZiB0aGUNCj5pbmNvbWluZw0K PnRyYWZmaWMgaXMgc21hbGxlciB0aGFuIHRoZSBiYW5kd2lkdGggb2YgdGhlIHRoYXQgbGluaywg YW5kIG9ubHkgdXNlIGENCj5zZWNvbmQNCj5saW5rICh3aXRoIHBlci1mbG93IHNjaGVkdWxpbmcp IGlmIHRoZSBjYXBhY2l0eSBpcyByZXF1aXJlZC4NCg0KDQpXZSByZS13cm90ZSB0aGlzIHBhcmFn cmFwaCBhbmQgaG9wZWZ1bGx5IHRoYXQgYWRkcmVzc2VzIHRoaXMgaXNzdWUuDQoNCg0KDQo+DQo+ MykgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCByZWFsbHkgbm9ybWF0aXZlIHNwZWNpZnkgdGhlIHVz ZSBvZiB0aGUgbmV3bHkNCj5kZWZpbmVkDQo+b3B0aW9ucy4gSXQgb25seSBnaXZlcyBhbiBleGFt cGxlcyBidXQgaXQgZG9lcyBub3Qgc3BlY2lmeSBub3JtYXRpdmVseSBhbnkNCj5hY3Rpb25zIHRo YXQgbmVlZCB0byBwZXJmb3JtZWQgb24gcmVjZWlwdCBvZiB0aGVzZSBvcHRpb25zLiBIb3cgZG9l cyB0aGUNCj5NQUcNCj5rbm93IGlmIHRoZSBMTUEgZG9lcyBub3Qgc3VwcG9ydCBNdWx0aXBhdGgg YmluZGluZz8gQW4gTE1BIHRoYXQgZG9lcyBub3QNCj5pbXBsZW1lbnQgdGhpcyBzcGVjIHdpbGwg bm90IHNlbmQgYmFjayBhbiBlcnJvciBtZXNzYWdlLiBXaHkgYXJlIHRoZXJlIHR3bw0KPmRpZmZl cmVudCBvcHRpb25zPyBXaGF0IGhhcHBlbnMgaWYgb25lIG9mIHRoZSBvcHRpb25zIGlzIHByZXNl bnQgaW4gdGhlDQo+UHJveHkNCj5CaW5kaW5nIFVwZGF0ZSBidXQgbm90IHRoZSBvdGhlcj8NCj4N Cg0KDQpUaGlzIGlzIGEgZ29vZCBwb2ludC4gVGhlcmUgaXMgYW4gaW1wbGljaXQgYXNzdW1wdGlv biB0aGF0IHRoZSBMTUENCmJlaGF2aW9yIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgYmVoYXZpb3Ig d2hlbiBkZWFsaW5nIHdpdGggYW55IHVua25vd24NCm9wdGlvbnMuIA0KV2UgY2FuIHB1dCBhIG5v dGUgdGhhdCB0aGUgUEJVIHdpbGwgcmVqZWN0ZWQgd2l0aCBlcnJvciBjb2RlIDEyOC4NCg0KDQoN Cg0KDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPlBs ZWFzZSBhbHNvIGNsYXJpZnkgdGhlIGRlZmluaXRpb25zIG9mIEludGVyZmFjZSBMYWJlbCBhbmQg QmluZGluZw0KPklkZW50aWZpZXINCj5hcyByZXF1ZXN0ZWQgYnkgdGhlIGdlbi1hcnQgcmV2aWV3 IChUaGFua3MgUm9iZXJ0ISkNCj4NCg0KSW50ZXJmYWNlIGxhYmVsIGlzIGEgc3RhdGljIGZpZWxk LCBFeDog4oCcTFRFLUludGVyZmFjZeKAnSwg4oCcbXkgYmx1ZQ0KaW50ZXJmYWNl4oCdLiBUcmFm ZmljIHBvbGljeSBpcyB0aWVkIHRvIHRoaXMgc3RhdGljIGxhYmVsLA0KDQpIVFRQIEZsb3c6IFVz ZSBMVEUtSW50ZXJmYWNlLCBpZiBub3QgYXZhaWxhYmxlLCB1c2Ug4oCcV2lGSS1JbnRlcmZhY2Xi gJ0uDQpMYWJlbCBpcyB0aWVkIHRvIGEgcG9saWN5OyB3aGljaCB0aGUgTUFHIGFuZCBMTUEgd2ls bCB0cmFuc2xhdGUgaXQgYmluZA0KdGhlIGZsb3cgdG8gYSBkeW5hbWljYWxseSBjcmVhdGVkIHR1 bm5lbCB1c2luZyB0aGUgQ29BIGZyb20gdGhhdCBpbnRlcmZhY2UuDQoNCkJpbmRpbmcgaWRlbnRp ZmllciBpcyB3aGF0IGlzIGR5bmFtaWNhbGx5IGdlbmVyYXRlZCBhbmQgdXNpbmcgdG8gaWRlbnRp ZnkNCmEgc3BlY2lmaWMgYmluZGluZyBvbiB0aGUgTE1BLg0KDQoNCg0KDQo+DQoNCg== From nobody Wed Aug 16 21:01:08 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC611323B3; Wed, 16 Aug 2017 21:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnsIaPYoPTB2; Wed, 16 Aug 2017 21:01:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A931241F5; Wed, 16 Aug 2017 21:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3331; q=dns/txt; s=iport; t=1502942464; x=1504152064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/8x1Ipr05cuqXMVsRoOeyIWHxNsfIccEsvYO2/Fqyhk=; b=KULCDlhJf35fOfgiOJyTXTdJpl3qnLmxPjeJF6PyflfODADG2/gOaS06 0WsfkjBuFp8hUPDb3X6JZyuPtGp7acYf8q0mnJ+W4FWE1sHRc7JDAsVDD e0F+LIuzbHEiEdyrgXwC6hyusOU/WgLpraKmdlgVFasQ92ncbeYpEjgV0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAABDFJVZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjguQEpgIDoIELIUbAoRGPxgBAgEBAQEBAQFrKIUZBjo?= =?us-ascii?q?/EAIBCDYQMiUCBAENBYowEKwii18BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMog?= =?us-ascii?q?gKBTIUKhEABEgEHSoVCBYl+jh2ILQKHUoxughCFYIpslhoBHzh/C3cVH4VBHBm?= =?us-ascii?q?BTnYBAYc2gSOBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,386,1498521600"; d="scan'208";a="281875958" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2017 04:01:02 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7H412tA031088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2017 04:01:02 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Aug 2017 23:01:01 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 16 Aug 2017 23:01:01 -0500 From: "Sri Gundavelli (sgundave)" To: Adam Roach , The IESG CC: "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) Thread-Index: AQHTFw1wVsi9OHgllU6gn+b/pO6+ZA== Date: Thu, 17 Aug 2017 04:01:01 +0000 Message-ID: References: <150286519610.12480.4832297974578384362.idtracker@ietfa.amsl.com> In-Reply-To: <150286519610.12480.4832297974578384362.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="us-ascii" Content-ID: <8398FE5122CC874F94F5831B9A153E9D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Adam Roach's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 04:01:07 -0000 Hi Adam, Thank you for the review. Please see inline. Sri On 8/15/17, 11:33 PM, "Adam Roach" wrote: >Adam Roach has entered the following ballot position for >draft-ietf-dmm-mag-multihoming-04: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Figure 1 labels the bottom-left most construct "Flow0-4" -- I suspect this >should be "Flow-4." Ack. > >I see the requests to remove MPTCP from the document, and the rationale >seems >sound. If, by some chance, any mention of MPTCP remains in the final >version, >please make sure it gets expanded (as an acronym) and cited. Please see new text that we discussed with Warren > >The final paragraph in section 3.2 starts with "Because latency introduced >by..." -- this isn't the reason damage can arise. The problem is the >*variation* in latency. Suggest something like: "Because the variation in >packet latency, also known as jitter, introduced by per-packet scheduling >between access networks can cause..." Please see the new text that we discussed with Warren > >Section 4.1, definition of If-ATT -- suggest citing the specific section: >"[RFC5213] section 8.5." Ack > >Section 4.1, definition of If-Label -- the value of 0 appears to be >reserved? >Ideally, this would prescribe specific behavior for an LMA if they >receive an >If-Label of 0. No real reason as with most fields we just eliminated zero value field. > >Section 4.1, definition of BID -- same comment; ideally, this would >specify >recipient behavior if set to 0 or 255. Same response. > >Section 4.3 defines a new response code for LMAs that don't implement this >spec. Existing, already deployed LMAs will necessarily have a different >reaction to receiving these unknown options than sending this response >code. >This section should provide guidance for MAGs letting them know what >observable >behavior they should expect when sending these options to LMAs unaware of >this >extension at all. Additionally, _if_ such observable behavior is >sufficient for >the MAG to understand what is happening, I would assert that the new >response >code is unnecessary and should be removed. Ack. We will add a sentence on the default LMA behavior with respect to dealing with unknown options. > >Please expand the following acronyms upon first use and in the title; >see https://www.rfc-editor.org/materials/abbrev.expansion.txt for >guidance. > > - MAG - Mobile Access Gateway (in the title) > - GRE - Generic Routing Encapsulation > - LMA - Local Mobility Anchor > - LTE - Long-Term Evolution > - MN - Mobile Node > - BCE - Bonding Channel Entity Ack > > From nobody Thu Aug 17 06:13:08 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CCF1323AC for ; Thu, 17 Aug 2017 06:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnQOUDXI1Wy4 for ; Thu, 17 Aug 2017 06:13:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990A2132400 for ; Thu, 17 Aug 2017 06:12:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=nq1RflX2MIlldCnD9c4pZPfTKfvn0s6WCJfewAWMe5xfN0rpKE3HioAtmhUrVaziPcI2vx4LMDL+fzyG1aPTPrN2Qy6w7R9dxjqRH4XUCyXfK2gZK75wEgQu3y3/hKTK3UrQLVYXy7NbC/x1snElZz86aI0F7jGHj0ba1u6k52g=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 9433 invoked from network); 17 Aug 2017 15:12:57 +0200 Received: from pd9e11b0f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.27.15) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Aug 2017 15:12:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 17 Aug 2017 15:12:55 +0200 Cc: The IESG , "dmm-chairs@ietf.org" , Jouni Korhonen , "draft-ietf-dmm-mag-multihoming@ietf.org" , "dmm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <89C42C3C-4A49-4CB1-B853-D834900281D8@kuehlewind.net> References: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> To: "Sri Gundavelli (sgundave)" X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170817131257.9424.29756@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-mag-multihoming-04=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:13:03 -0000 Hi Sri, see below. > Am 17.08.2017 um 05:17 schrieb Sri Gundavelli (sgundave) = : >=20 > Hi Mirja. >=20 > Please see below and also let us know if the text that we discussed = with > Warren addresses your main concerns. >=20 >=20 > Regards > Sri >=20 >=20 > On 7/31/17, 2:49 PM, "Mirja K=C3=BChlewind" = wrote: >=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-dmm-mag-multihoming-04: Discuss >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> 1) This document should not recommend the use of MPTCP for tunneling, = as >> TCP-in-TCP tunnels are generally not recommend if that can be = avoided. >> Please >> remove the following part from section 3.2 and leave IP-level = tunneling >> as the >> only option:=20 > =E2=80=9EPacket distribution can be done either at the transport >> level, >> e.g. using MPTCP =E2=80=A6=E2=80=9C >=20 >=20 > Ack. Please see the new text. Yes, the new text is fine. Instead of not recommending anything you = could actually even recommend per-flow scheduling as the default=E2=80=A6 = but text is fine this way as well. >=20 >=20 >>=20 >> 2) Further the following sentences also in section 3.2 should be = revised: >> =E2=80=9EFor example, high throughput services (e.g. >> video streaming) may benefit from per-packet distribution scheme, >> while latency sensitive applications (e.g. VoIP) are not be spread >> over different WAN paths.=E2=80=9C >> High throughput services only benefit from per-packet scheduling if = the >> service >> requires higher throughput than one of the links can provide. Also = video >> streaming may not be a good example here because high latency = variations >> can >> lead to stalls. Therefore in general per-flow scheduling should be >> recommend >> for all traffic. It could still be beneficial to schedule flows that >> require >> low latency over the link with the lower base latency, or maybe more >> important >> lower jitter, however, often it is not known to the network what the >> requirements on latency are for a given flow. Therefore is should >> probably be >> recommended to schedule all traffic on the "better" link (where = better >> can be >> pre-configured knowledge or measured) as long as the bandwidth of the >> incoming >> traffic is smaller than the bandwidth of the that link, and only use = a >> second >> link (with per-flow scheduling) if the capacity is required. >=20 >=20 > We re-wrote this paragraph and hopefully that addresses this issue. Yes, just removing this part was the best option here. >=20 >=20 >=20 >>=20 >> 3) This document does not really normative specify the use of the = newly >> defined >> options. It only gives an examples but it does not specify = normatively any >> actions that need to performed on receipt of these options. How does = the >> MAG >> know if the LMA does not support Multipath binding? An LMA that does = not >> implement this spec will not send back an error message. Why are = there two >> different options? What happens if one of the options is present in = the >> Proxy >> Binding Update but not the other? >>=20 >=20 >=20 > This is a good point. There is an implicit assumption that the LMA > behavior is consistent with the behavior when dealing with any unknown > options.=20 > We can put a note that the PBU will rejected with error code 128. That's good. Are you supposed to resend without the new options if you = received 128? And again what happens if only one option is present? >=20 >=20 >=20 >=20 >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Please also clarify the definitions of Interface Label and Binding >> Identifier >> as requested by the gen-art review (Thanks Robert!) >>=20 >=20 > Interface label is a static field, Ex: =E2=80=9CLTE-Interface=E2=80=9D, = =E2=80=9Cmy blue > interface=E2=80=9D. Traffic policy is tied to this static label, >=20 > HTTP Flow: Use LTE-Interface, if not available, use = =E2=80=9CWiFI-Interface=E2=80=9D. > Label is tied to a policy; which the MAG and LMA will translate it = bind > the flow to a dynamically created tunnel using the CoA from that = interface. >=20 > Binding identifier is what is dynamically generated and using to = identify > a specific binding on the LMA. I think this comment was on the way it is described in the draft. Maybe = the wording can be further clarified there. Here is the original text = from the genart review of Robert Sparks: "* I still find the definitions of Interface Label and Binding = Identifier confusing. I suspect they _both_ need to be carefully rewritten to make sure = they are definitions of the terms, and not descriptions of the interactions of = the two fields. Why is the Interface Label definition talking so much about = binding? As currently written, that last sentence of the Binding Identifier definition says the document says the mobile access gateway assigns a single unique binding identifier for each of its interfaces. =E2=80=9E= =20 Thanks! Mirja >=20 >=20 >=20 >=20 >>=20 >=20 From nobody Thu Aug 17 07:05:37 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AA013242C; Thu, 17 Aug 2017 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFAt_UhedXbu; Thu, 17 Aug 2017 07:05:34 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F71132063; Thu, 17 Aug 2017 07:05:33 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id i12so43711930pgr.3; Thu, 17 Aug 2017 07:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=83XzUYB2JPOgQUQGZ9/XOOhyILlpySepW2H0RCdx2w0=; b=CcdIOKhvQgBnYFVcFAgYhVRpwECL9YOahBflH0nyZ8OaDfujWIGRz4tLE+Y6gm8Z9y BTJmCPnExbVfPZTVjNwMlyiPti1kAV1KgsghqmLJS96tnUV7P6tb6K0syR4+0A88ot89 gSQ4+yHhAappkbKXfEWHvXmKu9qtbUr5XbnDScwlGuHPx/RLWVwnAy/+85SBGhHip/yf OvRQxvbRRKYCWr6FchEs/jb/cI/0CB+RxWc1cYbEqEeSL2J3AKH8KeMBCcTOaIC/gm6g N4OO4ayCQ0TNIUasCfttUtpwdKMT0fYR+/rpTHrVlNZ/uphV6Tce4DO0ubTld71DBVc0 ybjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=83XzUYB2JPOgQUQGZ9/XOOhyILlpySepW2H0RCdx2w0=; b=BHKEHsYVomVsJ2Z3Kq4Zl0FvzKoXu4XDukIT6xt+Tp9sNN+hrDDu20wjxwCYeQBaio 7hkTohg8XkZBK3pkZw7XppeygR4KD4NtQ0QLyrwujOCWB0MaYLA8hQFDzX3C0nfEwjuR s8WhXo9iIMtt/N8A+1vtVnjdS6aiKlCUCnY4QQRTrxvFvSJn9xr4u7WpuYzwy7Yoib+c zltNe9QJioTToESBmqmDBaFPOLUG7Q9o+tEeq4URPFcOfqZy7I9GuXa+PDCQmMrvoS1w ZsEAmpDEBNnlyhz4xdp5+qu5bQh2JTXZphZ92MDTOFv1fCzw+EzfgTIbTxaT/DBe47GZ EmSw== X-Gm-Message-State: AHYfb5hJ2eMDNU3C7uxgP3ESbhCKidbL1FgbexiwRJWAVIvhTsSmOfxw f8Bkmp1h0SzTiDV3f53n5e6V43mnoQ== X-Received: by 10.84.229.13 with SMTP id b13mr5945531plk.352.1502978733293; Thu, 17 Aug 2017 07:05:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Thu, 17 Aug 2017 07:04:52 -0700 (PDT) In-Reply-To: References: <150161840636.12123.2784912255737760138.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 17 Aug 2017 10:04:52 -0400 Message-ID: To: "Sri Gundavelli (sgundave)" Cc: The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:05:36 -0000 Good morning, On Wed, Aug 16, 2017 at 11:04 PM, Sri Gundavelli (sgundave) wrote: > Hi Kathleen and Hilarie, > > Thank you for reviewing the documents and the feedback. Please see inline= . > > > >> For security considerations, the authors predictably defer to RFC5213, >> =E2=80=9CProxy Mobile IPv6=E2=80=9D, and assert "no impact on the protoc= ol security". >> However, there is one security issue that is mentioned in RFC5213 that i= s >> exacerbated by the current draft. I.e., > >> To address the threat related to a compromised mobile access gateway, t= he >> local mobility anchor, before accepting a Proxy Binding Update message f= or a >> given mobile node, may ensure that the mobile node is attached to the mo= bile >> access gateway that sent the Proxy Binding Update message. > > > A MAG is required to prove the presence of a mobile node=E2=80=99s presen= ce on its > (ingress) access link. That assertion needs to be validated by the LMA. B= ut, > MAG using a single tunnel or multiple tunnels has no relation to this iss= ue. > The LMA identifies the MAG using the MAG-NAI and not using Care-of Addres= s; > a new option, MAG Identifier option is defined in section 4.2 for this > purpose. > Could you add some text to the security considerations to explain why there is no concern then related to split tunneling/data leakage to the incorrect tunnel? > > > > >> Is there any reason to worry about reuse of CoAs? Could packets from one >> tunnel get a CoA that was recently used by another tunnel, and could del= ayed >> packets get routed through the wrong tunnel? Just asking. > > The tunnels between LMA and MAG are dynamically established after protoco= l > signaling. The idea of CoA re-use between MAG=E2=80=99s and delayed packe= ts getting > delivered to a different MAG is impossible to realize even in lab > conditions. It is possible there are two MAG=E2=80=99s in a given access = network and > one looses the CoA and the other MAG gets the name address. But, the tunn= els > comes up after PBU/PBA exchange which introduces some delay, and so the > possibility of packets from previous MAG-era getting showing up at the ne= w > MAG is nearly impossible and is not worth mentioning it, IMO. > > > > > >> Nits. On page 3 there is a paragraph beginning =E2=80=9CIn the continuat= ion of c, >> a Proxy Mobile IPv6 ..." There is no explanation of =E2=80=9Cc". Is this= a remnant >> of a list of items "a, b, c"? > > Fixed in -04 version > > > > > >> On page 4 there is Figure 1 showing four flows and two tunnels. The > > We just wanted to hint that the Flow-4 is based on per-packet load balanc= ing > using both the paths, whereas the other flows are routed based on Per-flo= w > load balancing. But, I think the comment is still valid. We should show t= he > use of a single forwarding mode and not mix both the modes. Minor nit, wi= ll > fix it. Thank you for fixing this. Kathleen > > > Thank you for your review. > > > Regards > Sri > > > > > > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 > Security review of > MAG Multipath Binding Option > draft-ietf-dmm-mag-multihoming-03.txt > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > If you've been frustrated by being limited to only one IP tunnel > between a mobile access gateway and a local mobility anchor, then > you'll be glad to know that this draft fixes the problem and enables > multiple care-of addresses and IP tunnels. Now mobile devices can be > assigned to any applicable tunnel between the MAG and the LMA. > > For security considerations, the authors predictably defer to RFC5213, > "Proxy Mobile IPv6", and assert "no impact on the protocol security". > However, there is one security issue that is mentioned in RFC5213 that > is exacerbated by the current draft. I.e., > > To address the threat related to a compromised mobile access gateway, > the local mobility anchor, before accepting a Proxy Binding Update > message for a given mobile node, may ensure that the mobile node is > attached to the mobile access gateway that sent the Proxy Binding > Update message. > > The RFC has no recommendation for a solution, but because there are > now multiple tunnels, this assurance may be more difficult to obtain. > For example, if the LMA expects to contact some kind of trusted entity > that is keeping track of the mobile devices that the MAG is sending on > a tunnel, then the MAG and LMA may now have to keep track of multiple > trusted entities, one for each tunnel. Whether or not this is a > realistic scenario is not something that I can judge because RFC5213 > punts on what seems to be an important security issue. > > Is there any reason to worry about reuse of CoAs? Could packets from > one tunnel get a CoA that was recently used by another tunnel, and > could delayed packets get routed through the wrong tunnel? Just asking. > > Nits. On page 3 there is a paragraph beginning "In the continuation > of c, a Proxy Mobile IPv6 ..." There is no explanation of "c". Is > this a remnant of a list of items "a, b, c"? > > On page 4 there is Figure 1 showing four flows and two tunnels. The > text immediately preceding that says that "Flow-1,2 and 3 are > distributed either on Tunnel-1 (over LTE) or Tunnel-2 (over WLAN)", > but the diagram shows Flow-1 on Tunnel-1 and Flow-2,3 on Tunnel-2. > I think the text should indicate that the first three flows are > each assigned to a single tunnel. The authors probably meant that > either Tunnel-1 or Tunnel-2 could have been assigned, but the choice > was to put Flow-1 on Tunnel-1 and the other flows on Tunnel-2. > I had to read over the text several times before I was sure of the > intent. > > Hilarie > > On 8/1/17, 1:13 PM, "Kathleen Moriarty" > wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-dmm-mag-multihoming-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. I had the same concern as the SecDir > reviewer in reading the draft, the concern about leaking traffic as a res= ult > of > multiple tunnels is not addressed in the security considerations section. > Hilary's writeup is quite helpful > > https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html > > > > > --=20 Best regards, Kathleen From nobody Thu Aug 17 07:07:14 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FE3132063; Thu, 17 Aug 2017 07:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYAgijY-_C-e; Thu, 17 Aug 2017 07:07:11 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB9913264C; Thu, 17 Aug 2017 07:07:07 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id h70so4043698ioi.2; Thu, 17 Aug 2017 07:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=TfjtMS3BbZR8silV9cxJaT8IW9eLgyIlg0Lvb+WHtn8=; b=LZ20v1qwzUjz8AbjGna7y2LyWKw4XOIqIh3jf3FhFpB8GQxLNp5zY3AV0NA7BbbZpO AJ8TInVh+gRlTk0SxwG9mmRwb7sV8b97p5PNnTLwvMrUY72mHBwBK6O+f7B5Y9vioJid BsSo7owgloAfO4KIy/hRrzCwXnC3v3mIUIRnGxN2voUJyZ/RMA80VdirQ/gPa+ejoGHf zW/BtGFww8Vtsc+gUXRor6mvIJQFcpaYbnAW4IH4GlkpWZ80YIWDcgEafw7u+DIoDxmH PF0vW4ykSbHRmreUgCA9lDggGJQsNcoHhGBydOAxQsUQ1+ZHaGdUIN9g9KBTU4qzuCqt fKsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=TfjtMS3BbZR8silV9cxJaT8IW9eLgyIlg0Lvb+WHtn8=; b=Mm9Sc/eiCLAbTmw477bFG5IleuYO+OqNQtoI9qyEtJgnE+Jn0YOeC+zcL0FYWt5reP 4VXNnEofChvdh6OTl7/RvjlvwM7BBkCn//qMoPM1h2614l8QSqwM2RNUyL5nXd80HEeF LsC153OdJ4ruMM+5qHwylwTAaljzQNHeeNWcE2ZAKryt0Sr7k++ZDsuL2PZE7VfDu+Xi Q9/7Qu5BL4ZNHTF64mUCYiI7ownb/Fnw6oPXwsnUVp0nxJcuLLW4UINgdLmOVRHRCZjp 75tEPo0eJfZcWnXsXYdYaqHWXkNA9yP3K6QgFjuOYrm5prcvpPDPiSKqqqbesm7x6nFZ HIMg== X-Gm-Message-State: AHYfb5hbUnHZJkhpMUJTU4VmtLsz/lm8JsHHEUVePhzN3oeZZLm05SV/ QVLlvvdpizf47Ir+ajcWtA== X-Received: by 10.107.53.156 with SMTP id k28mr4678202ioo.290.1502978827063; Thu, 17 Aug 2017 07:07:07 -0700 (PDT) Received: from sureshs-mbp.dyn.mtl.kaloom.io ([67.22.228.35]) by smtp.gmail.com with ESMTPSA id d184sm1669108itd.6.2017.08.17.07.07.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 07:07:06 -0700 (PDT) From: Suresh Krishnan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <6BFFC7B7-8AD6-4183-A4FA-7C19BB309DF8@gmail.com> Date: Thu, 17 Aug 2017 10:07:05 -0400 To: dmm@ietf.org, dmm-chairs X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [DMM] Upcoming IPR disclosure on draft-ietf-dmm-mag-multihoming-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:07:13 -0000 Hi all, When this draft went through IESG evaluation one of the ADs realized = that they had some IPR that could be applicable to this draft. An IPR = disclosure has been submitted and should be posted within the next few = days. I just wanted to give the WG a heads up on this situation. Please = talk to me or the chairs if you have any concerns. Thanks Suresh From nobody Thu Aug 17 18:08:44 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E64132707; Thu, 17 Aug 2017 18:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC5okEaQZiKA; Thu, 17 Aug 2017 18:08:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05C81243F6; Thu, 17 Aug 2017 18:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4378; q=dns/txt; s=iport; t=1503018520; x=1504228120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ut5AuSuQURgm/PN2Oy6hhsNevN+BoqoRSqFVAZBnS0A=; b=OeWiP+nbPJ3jJgVsw/TZaD8fAOBPJ2SpBsbFwQbKSLsOFGbAaiO5yKEw p0AOIR/qUmsFwnbPzmznGVa7xJXaE6LOpmiSG+tYg5XYs3J0tb4vaSqnU CM+WSmD622ak8yfV8YUXzbUisSNy3IPMUnCu8MG5j6yrLYP6fQ0sg69nK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAADIPZZZ/5FdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEVB44LkBKTI4RmghKFRwIahD4/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?GIxFFEAIBCBoCJgICAjAVBQsCBA4FijCqC4Imi2YBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdgQuCHYICgUyFCoRIgz6CYQWJfhOIa41NApRAghCFYIpsiWiMNAEfOIE?= =?us-ascii?q?KdxWGFYFOdohMgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,390,1498521600"; d="scan'208";a="284163497" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2017 01:08:33 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v7I18X77019253 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Aug 2017 01:08:33 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Aug 2017 20:08:33 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 17 Aug 2017 20:08:33 -0500 From: "Sri Gundavelli (sgundave)" To: "Mirja Kuehlewind (IETF)" CC: The IESG , "dmm-chairs@ietf.org" , Jouni Korhonen , "draft-ietf-dmm-mag-multihoming@ietf.org" , "dmm@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kbW0t?= =?utf-8?Q?mag-multihoming-04:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHTCkbWqTqOB87KxkGk4BHR1eN2MQ== Date: Fri, 18 Aug 2017 01:08:33 +0000 Message-ID: References: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> <89C42C3C-4A49-4CB1-B853-D834900281D8@kuehlewind.net> In-Reply-To: <89C42C3C-4A49-4CB1-B853-D834900281D8@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: text/plain; charset="utf-8" Content-ID: <1B7F884D2C11ED498255A7A6C41BA3D5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-mag-multihoming-04=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 01:08:43 -0000 SGkgTWlyamEsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBxdWljayBmZWVkYmFjay4gUGxlYXNlIHNl ZSBpbmxpbmUg4oCmDQoNCg0KDQpPbiA4LzE3LzE3LCA2OjEyIEFNLCAiTWlyamEgS3VlaGxld2lu ZCAoSUVURikiIDxpZXRmQGt1ZWhsZXdpbmQubmV0PiB3cm90ZToNCg0KPHNuaXA+IC4uIGtlZXBp bmcgb25seSB0aGUgb3BlbiBpc3N1ZXMuDQoNCj4NCj4+IA0KPj4gDQo+PiANCj4+PiANCj4+PiAz KSBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHJlYWxseSBub3JtYXRpdmUgc3BlY2lmeSB0aGUgdXNl IG9mIHRoZSBuZXdseQ0KPj4+IGRlZmluZWQNCj4+PiBvcHRpb25zLiBJdCBvbmx5IGdpdmVzIGFu IGV4YW1wbGVzIGJ1dCBpdCBkb2VzIG5vdCBzcGVjaWZ5IG5vcm1hdGl2ZWx5DQo+Pj5hbnkNCj4+ PiBhY3Rpb25zIHRoYXQgbmVlZCB0byBwZXJmb3JtZWQgb24gcmVjZWlwdCBvZiB0aGVzZSBvcHRp b25zLiBIb3cgZG9lcw0KPj4+dGhlDQo+Pj4gTUFHDQo+Pj4ga25vdyBpZiB0aGUgTE1BIGRvZXMg bm90IHN1cHBvcnQgTXVsdGlwYXRoIGJpbmRpbmc/IEFuIExNQSB0aGF0IGRvZXMNCj4+Pm5vdA0K Pj4+IGltcGxlbWVudCB0aGlzIHNwZWMgd2lsbCBub3Qgc2VuZCBiYWNrIGFuIGVycm9yIG1lc3Nh Z2UuIFdoeSBhcmUgdGhlcmUNCj4+PnR3bw0KPj4+IGRpZmZlcmVudCBvcHRpb25zPyBXaGF0IGhh cHBlbnMgaWYgb25lIG9mIHRoZSBvcHRpb25zIGlzIHByZXNlbnQgaW4gdGhlDQo+Pj4gUHJveHkN Cj4+PiBCaW5kaW5nIFVwZGF0ZSBidXQgbm90IHRoZSBvdGhlcj8NCj4+PiANCj4+IA0KPj4gDQo+ PiBUaGlzIGlzIGEgZ29vZCBwb2ludC4gVGhlcmUgaXMgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiB0 aGF0IHRoZSBMTUENCj4+IGJlaGF2aW9yIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgYmVoYXZpb3Ig d2hlbiBkZWFsaW5nIHdpdGggYW55IHVua25vd24NCj4+IG9wdGlvbnMuIA0KPj4gV2UgY2FuIHB1 dCBhIG5vdGUgdGhhdCB0aGUgUEJVIHdpbGwgcmVqZWN0ZWQgd2l0aCBlcnJvciBjb2RlIDEyOC4N Cj4NCj5UaGF0J3MgZ29vZC4gQXJlIHlvdSBzdXBwb3NlZCB0byByZXNlbmQgd2l0aG91dCB0aGUg bmV3IG9wdGlvbnMgaWYgeW91DQo+cmVjZWl2ZWQgMTI4PyBBbmQgYWdhaW4gd2hhdCBoYXBwZW5z IGlmIG9ubHkgb25lIG9wdGlvbiBpcyBwcmVzZW50Pw0KDQpJIHdpbGwgdGFrZSBjYXJlIG9mIHRo aXMuIFdpbGwgYWRkIGNvbnNpZGVyYXRpb25zIG9uIGJvdGggTE1BL01BRyBiZWhhdmlvcg0Kd2hl biB0aGVyZSBpcyB2ZXJzaW9uIGluY29tcGF0aWJpbGl0eS4gV2lsbCBwb3N0IGEgbmV3IHJldiB3 aXRoIHRoZXNlDQpjb25zaWRlcmF0aW9ucy4gQnV0LCB0aGFuayB5b3U7IHdlIGRlZmluaXRlbHkg b3Zlcmxvb2tlZCB0aGlzIHBhcnQuDQoNCg0KDQoNCj4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g DQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IENPTU1FTlQ6DQo+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+IA0KPj4+IFBsZWFzZSBhbHNvIGNsYXJpZnkgdGhlIGRlZmluaXRpb25zIG9mIEludGVy ZmFjZSBMYWJlbCBhbmQgQmluZGluZw0KPj4+IElkZW50aWZpZXINCj4+PiBhcyByZXF1ZXN0ZWQg YnkgdGhlIGdlbi1hcnQgcmV2aWV3IChUaGFua3MgUm9iZXJ0ISkNCj4+PiANCj4+IA0KPj4gSW50 ZXJmYWNlIGxhYmVsIGlzIGEgc3RhdGljIGZpZWxkLCBFeDog4oCcTFRFLUludGVyZmFjZeKAnSwg 4oCcbXkgYmx1ZQ0KPj4gaW50ZXJmYWNl4oCdLiBUcmFmZmljIHBvbGljeSBpcyB0aWVkIHRvIHRo aXMgc3RhdGljIGxhYmVsLA0KPj4gDQo+PiBIVFRQIEZsb3c6IFVzZSBMVEUtSW50ZXJmYWNlLCBp ZiBub3QgYXZhaWxhYmxlLCB1c2Ug4oCcV2lGSS1JbnRlcmZhY2XigJ0uDQo+PiBMYWJlbCBpcyB0 aWVkIHRvIGEgcG9saWN5OyB3aGljaCB0aGUgTUFHIGFuZCBMTUEgd2lsbCB0cmFuc2xhdGUgaXQg YmluZA0KPj4gdGhlIGZsb3cgdG8gYSBkeW5hbWljYWxseSBjcmVhdGVkIHR1bm5lbCB1c2luZyB0 aGUgQ29BIGZyb20gdGhhdA0KPj5pbnRlcmZhY2UuDQo+PiANCj4+IEJpbmRpbmcgaWRlbnRpZmll ciBpcyB3aGF0IGlzIGR5bmFtaWNhbGx5IGdlbmVyYXRlZCBhbmQgdXNpbmcgdG8NCj4+aWRlbnRp ZnkNCj4+IGEgc3BlY2lmaWMgYmluZGluZyBvbiB0aGUgTE1BLg0KPg0KPkkgdGhpbmsgdGhpcyBj b21tZW50IHdhcyBvbiB0aGUgd2F5IGl0IGlzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuIE1heWJl DQo+dGhlIHdvcmRpbmcgY2FuIGJlIGZ1cnRoZXIgY2xhcmlmaWVkIHRoZXJlLiBIZXJlIGlzIHRo ZSBvcmlnaW5hbCB0ZXh0DQo+ZnJvbSB0aGUgZ2VuYXJ0IHJldmlldyBvZiBSb2JlcnQgU3Bhcmtz Og0KDQoNCkkgaGF2ZSBsb29rZWQgYXQgYm90aCB0aGUgZGVmaW5pdGlvbnMgYW5kIEkgYWdyZWUg aXQgbmVlZHMgdG8gc29tZQ0KY2xhcmlmaWNhdGlvbi4gSSB3aWxsIGZpeCB0aGlzLg0KDQoNCg0K DQo+DQo+IiogSSBzdGlsbCBmaW5kIHRoZSBkZWZpbml0aW9ucyBvZiBJbnRlcmZhY2UgTGFiZWwg YW5kIEJpbmRpbmcgSWRlbnRpZmllcg0KPmNvbmZ1c2luZy4NCj4gICBJIHN1c3BlY3QgdGhleSBf Ym90aF8gbmVlZCB0byBiZSBjYXJlZnVsbHkgcmV3cml0dGVuIHRvIG1ha2Ugc3VyZSB0aGV5DQo+ YXJlDQo+ICAgZGVmaW5pdGlvbnMgb2YgdGhlIHRlcm1zLCBhbmQgbm90IGRlc2NyaXB0aW9ucyBv ZiB0aGUgaW50ZXJhY3Rpb25zIG9mDQo+dGhlIHR3bw0KPiAgIGZpZWxkcy4gV2h5IGlzIHRoZSBJ bnRlcmZhY2UgTGFiZWwgZGVmaW5pdGlvbiB0YWxraW5nIHNvIG11Y2ggYWJvdXQNCj5iaW5kaW5n Pw0KPiAgIEFzIGN1cnJlbnRseSB3cml0dGVuLCB0aGF0IGxhc3Qgc2VudGVuY2Ugb2YgdGhlIEJp bmRpbmcgSWRlbnRpZmllcg0KPiAgIGRlZmluaXRpb24gc2F5cyAgdGhlIGRvY3VtZW50IHNheXMg dGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSBhc3NpZ25zDQo+ICAgYSBzaW5nbGUgdW5pcXVlIGJp bmRpbmcgaWRlbnRpZmllciBmb3IgZWFjaCBvZiBpdHMgaW50ZXJmYWNlcy4g4oCeDQo+IA0KPg0K PlRoYW5rcyENCj5NaXJqYQ0KPg0KPg0KPg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+Pj4gDQo+PiAN Cj4NCg0K From nobody Thu Aug 17 18:15:34 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062001326D8; Thu, 17 Aug 2017 18:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGpM84jOSw-i; Thu, 17 Aug 2017 18:15:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7165132677; Thu, 17 Aug 2017 18:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31998; q=dns/txt; s=iport; t=1503018922; x=1504228522; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bHhCW/U406hN0ztxxxemqtfQ7JJFrOQly94RGCS1d68=; b=gBsouhr/5xvTA7K3EPojKyMBudFRWjYuXjx5q3lSldvqDV/ujGz0++fG 6d9/I77nb3+CxDEol//hgjtjPulTY/ljc+vFYcMleh5z8RLQzMn/UsnG2 M4I2gWMtBilrrMorc7vdk95+ypA0jE/S9+rtXbPscJiWyTjl3kBRRMLML Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAAC7PpZZ/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEVB4RTiTiQEoomjWMOggQshExPAhqEPj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQYjTwcQAgEGAj8DAgICHxEUEQIEDgUbiTFMAxUQjA+dZIImhzoNhCABA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMogRtngUyBY4MngleBaQELBgIBGwovAoJ?= =?us-ascii?q?bgmEFiX6HF4cGh3I8AodSg1WEI4R2ghCFYIN7hnGJaIJOiWYBHzh/C3cVSYVMg?= =?us-ascii?q?U52AYcZAiQHgQWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,390,1498521600"; d="scan'208,217";a="444861376" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2017 01:15:21 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7I1FLgw001584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Aug 2017 01:15:21 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Aug 2017 20:15:20 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 17 Aug 2017 20:15:20 -0500 From: "Sri Gundavelli (sgundave)" To: Kathleen Moriarty CC: The IESG , "draft-ietf-dmm-mag-multihoming@ietf.org" , Jouni Korhonen , "dmm-chairs@ietf.org" , "dmm@ietf.org" Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) Thread-Index: AQHTF7911UlvoXUvDEOO27BVPk/g+A== Date: Fri, 18 Aug 2017 01:15:20 +0000 Message-ID: References: <150161840636.12123.2784912255737760138.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.62] Content-Type: multipart/alternative; boundary="_000_D5BB8C89287E2Csgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 01:15:26 -0000 --_000_D5BB8C89287E2Csgundaveciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2F0aGxlZW4sDQoNClRoYW5rIHlvdSBzbyBtdWNoLiBQbGVhc2Ugc2VlIGlubGluZS4NCg0K DQoNCg0KR29vZCBtb3JuaW5nLA0KDQpPbiBXZWQsIEF1ZyAxNiwgMjAxNyBhdCAxMTowNCBQTSwg U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKQ0KPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1 bmRhdmVAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBLYXRobGVlbiBhbmQgSGlsYXJpZSwNCg0KVGhh bmsgeW91IGZvciByZXZpZXdpbmcgdGhlIGRvY3VtZW50cyBhbmQgdGhlIGZlZWRiYWNrLiBQbGVh c2Ugc2VlDQppbmxpbmUuDQoNCg0KDQpGb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHRoZSBh dXRob3JzIHByZWRpY3RhYmx5IGRlZmVyIHRvIFJGQzUyMTMsDQrCs1Byb3h5IE1vYmlsZSBJUHY2 wrIsIGFuZCBhc3NlcnQgIm5vIGltcGFjdCBvbiB0aGUgcHJvdG9jb2wgc2VjdXJpdHkiLg0KSG93 ZXZlciwgdGhlcmUgaXMgb25lIHNlY3VyaXR5IGlzc3VlIHRoYXQgaXMgbWVudGlvbmVkIGluIFJG QzUyMTMgdGhhdA0KaXMNCmV4YWNlcmJhdGVkIGJ5IHRoZSBjdXJyZW50IGRyYWZ0LiBJLmUuLA0K DQogIFRvIGFkZHJlc3MgdGhlIHRocmVhdCByZWxhdGVkIHRvIGEgY29tcHJvbWlzZWQgbW9iaWxl IGFjY2VzcyBnYXRld2F5LA0KdGhlDQpsb2NhbCBtb2JpbGl0eSBhbmNob3IsIGJlZm9yZSBhY2Nl cHRpbmcgYSBQcm94eSBCaW5kaW5nIFVwZGF0ZSBtZXNzYWdlDQpmb3IgYQ0KZ2l2ZW4gbW9iaWxl IG5vZGUsIG1heSBlbnN1cmUgdGhhdCB0aGUgbW9iaWxlIG5vZGUgaXMgYXR0YWNoZWQgdG8gdGhl DQptb2JpbGUNCmFjY2VzcyBnYXRld2F5IHRoYXQgc2VudCB0aGUgUHJveHkgQmluZGluZyBVcGRh dGUgbWVzc2FnZS4NCg0KDQpBIE1BRyBpcyByZXF1aXJlZCB0byBwcm92ZSB0aGUgcHJlc2VuY2Ug b2YgYSBtb2JpbGUgbm9kZcK5cyBwcmVzZW5jZSBvbg0KaXRzDQooaW5ncmVzcykgYWNjZXNzIGxp bmsuIFRoYXQgYXNzZXJ0aW9uIG5lZWRzIHRvIGJlIHZhbGlkYXRlZCBieSB0aGUgTE1BLg0KQnV0 LA0KTUFHIHVzaW5nIGEgc2luZ2xlIHR1bm5lbCBvciBtdWx0aXBsZSB0dW5uZWxzIGhhcyBubyBy ZWxhdGlvbiB0byB0aGlzDQppc3N1ZS4NClRoZSBMTUEgaWRlbnRpZmllcyB0aGUgTUFHIHVzaW5n IHRoZSBNQUctTkFJIGFuZCBub3QgdXNpbmcgQ2FyZS1vZg0KQWRkcmVzczsNCmEgbmV3IG9wdGlv biwgTUFHIElkZW50aWZpZXIgb3B0aW9uIGlzIGRlZmluZWQgaW4gc2VjdGlvbiA0LjIgZm9yIHRo aXMNCnB1cnBvc2UuDQoNCg0KQ291bGQgeW91IGFkZCBzb21lIHRleHQgdG8gdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHRvIGV4cGxhaW4gd2h5DQp0aGVyZSBpcyBubyBjb25jZXJuIHRoZW4g cmVsYXRlZCB0byBzcGxpdCB0dW5uZWxpbmcvZGF0YSBsZWFrYWdlIHRvDQp0aGUgaW5jb3JyZWN0 IHR1bm5lbD8NCg0KSSBhc3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIGJlbG93IGRpc2N1 c3Npb24gcG9pbnQuICBXZSBjYW4gYWRkIHNvbWUgdGV4dCwgYnV0IHRoaXMgSU1ITyBpcyBhYnNv bHV0ZWx5IGEgbm9uLWV4aXN0ZW50IHNjZW5hcmlvOyBub3QgdHJ5aW5nIHRvIGlnbm9yZSBhIHZh bGlkIGlzc3VlLiBPdXQgb2Ygb3JkZXIgZGVsaXZlcnkgd2l0aCBzdWNoIGRlbGF5cywgd2hlcmUg b25lIE1BRyByZWxlYXNpbmcgdGhlIGFkZHJlc3MgYW5kIGFub3RoZXIgTUFHIG9idGFpbmluZyB0 aGUgc2FtZSBJUCBhZGRyZXNzIHdpdGggdGhlIGFzc29jaWF0ZWQgYWRkcmVzcyBjb25maWd1cmF0 aW9uIGRlbGF5cywgTU4gYXR0YWNobWVudCB0cmlnZ2VyaW5nIGEgUEJVIGF0IHRoYXQganVuY3R1 cmUsIGFuZCBhIFBCVS9QQkEgZXhjaGFuZ2UsICBhIHR1bm5lbCBlc3RhYmxpc2htZW50IGFuZCBh IHBhY2tldCBmcm9tIHRoZSBwcmV2aW91cyBNQUcgc2hvd2luZyB1cCBhdCB0aGUgbmV3IE1BRyBp cyBub3QgYSB0ZWNobmljYWwgcG9zc2liaWxpdHksIElNTy4gSSBhbSBub3QgZXZlbiBzdXJlIGhv dyB0byBmcmFtZSB0aGlzLg0KDQpCdXQsIEkgYW0gaGFwcHkgdG8gaW5jbHVkZSBhbnkgdGV4dCwg YnV0IElNSE8gaXQgd2lsbCBiZSBhIHRleHQgZm9yIG5vbi1leGlzdGVudCBzY2VuYXJpby4gTGV0 IG1lIGtub3cuDQoNCg0KDQpSZWdhcmRzDQpTcmkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpJcyB0 aGVyZSBhbnkgcmVhc29uIHRvIHdvcnJ5IGFib3V0IHJldXNlIG9mIENvQXM/IENvdWxkIHBhY2tl dHMgZnJvbQ0Kb25lDQp0dW5uZWwgZ2V0IGEgQ29BIHRoYXQgd2FzIHJlY2VudGx5IHVzZWQgYnkg YW5vdGhlciB0dW5uZWwsIGFuZCBjb3VsZA0KZGVsYXllZA0KcGFja2V0cyBnZXQgcm91dGVkIHRo cm91Z2ggdGhlIHdyb25nIHR1bm5lbD8gSnVzdCBhc2tpbmcuDQoNClRoZSB0dW5uZWxzIGJldHdl ZW4gTE1BIGFuZCBNQUcgYXJlIGR5bmFtaWNhbGx5IGVzdGFibGlzaGVkIGFmdGVyDQpwcm90b2Nv bA0Kc2lnbmFsaW5nLiBUaGUgaWRlYSBvZiBDb0EgcmUtdXNlIGJldHdlZW4gTUFHwrlzIGFuZCBk ZWxheWVkIHBhY2tldHMNCmdldHRpbmcNCmRlbGl2ZXJlZCB0byBhIGRpZmZlcmVudCBNQUcgaXMg aW1wb3NzaWJsZSB0byByZWFsaXplIGV2ZW4gaW4gbGFiDQpjb25kaXRpb25zLiBJdCBpcyBwb3Nz aWJsZSB0aGVyZSBhcmUgdHdvIE1BR8K5cyBpbiBhIGdpdmVuIGFjY2Vzcw0KbmV0d29yayBhbmQN Cm9uZSBsb29zZXMgdGhlIENvQSBhbmQgdGhlIG90aGVyIE1BRyBnZXRzIHRoZSBuYW1lIGFkZHJl c3MuIEJ1dCwgdGhlDQp0dW5uZWxzDQpjb21lcyB1cCBhZnRlciBQQlUvUEJBIGV4Y2hhbmdlIHdo aWNoIGludHJvZHVjZXMgc29tZSBkZWxheSwgYW5kIHNvIHRoZQ0KcG9zc2liaWxpdHkgb2YgcGFj a2V0cyBmcm9tIHByZXZpb3VzIE1BRy1lcmEgZ2V0dGluZyBzaG93aW5nIHVwIGF0IHRoZQ0KbmV3 DQpNQUcgaXMgbmVhcmx5IGltcG9zc2libGUgYW5kIGlzIG5vdCB3b3J0aCBtZW50aW9uaW5nIGl0 LCBJTU8uDQoNCg0KDQoNCg0KTml0cy4gT24gcGFnZSAzIHRoZXJlIGlzIGEgcGFyYWdyYXBoIGJl Z2lubmluZyDCs0luIHRoZSBjb250aW51YXRpb24gb2YNCmMsDQphIFByb3h5IE1vYmlsZSBJUHY2 IC4uLiIgVGhlcmUgaXMgbm8gZXhwbGFuYXRpb24gb2YgwrNjIi4gSXMgdGhpcyBhDQpyZW1uYW50 DQpvZiBhIGxpc3Qgb2YgaXRlbXMgImEsIGIsIGMiPw0KDQpGaXhlZCBpbiAtMDQgdmVyc2lvbg0K DQoNCg0KDQoNCk9uIHBhZ2UgNCB0aGVyZSBpcyBGaWd1cmUgMSBzaG93aW5nIGZvdXIgZmxvd3Mg YW5kIHR3byB0dW5uZWxzLiBUaGUNCg0KV2UganVzdCB3YW50ZWQgdG8gaGludCB0aGF0IHRoZSBG bG93LTQgaXMgYmFzZWQgb24gcGVyLXBhY2tldCBsb2FkDQpiYWxhbmNpbmcNCnVzaW5nIGJvdGgg dGhlIHBhdGhzLCB3aGVyZWFzIHRoZSBvdGhlciBmbG93cyBhcmUgcm91dGVkIGJhc2VkIG9uDQpQ ZXItZmxvdw0KbG9hZCBiYWxhbmNpbmcuIEJ1dCwgSSB0aGluayB0aGUgY29tbWVudCBpcyBzdGls bCB2YWxpZC4gV2Ugc2hvdWxkIHNob3cNCnRoZQ0KdXNlIG9mIGEgc2luZ2xlIGZvcndhcmRpbmcg bW9kZSBhbmQgbm90IG1peCBib3RoIHRoZSBtb2Rlcy4gTWlub3Igbml0LA0Kd2lsbA0KZml4IGl0 Lg0KDQpUaGFuayB5b3UgZm9yIGZpeGluZyB0aGlzLg0KS2F0aGxlZW4NCg0KDQoNClRoYW5rIHlv dSBmb3IgeW91ciByZXZpZXcuDQoNCg0KUmVnYXJkcw0KU3JpDQoNCg0KDQoNCg0KDQoNCuKAueKA ueKAueKAueKAueKAueKAueKAueKAueKAueKAueKAueKAueKAueKAueKAueKAuQ0KU2VjdXJpdHkg cmV2aWV3IG9mDQpNQUcgTXVsdGlwYXRoIEJpbmRpbmcgT3B0aW9uDQpkcmFmdC1pZXRmLWRtbS1t YWctbXVsdGlob21pbmctMDMudHh0DQoNCkRvIG5vdCBiZSBhbGFybWVkLiBJIGhhdmUgcmV2aWV3 ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZQ0Kc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzDQpiZWluZyBwcm9jZXNz ZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkNCmZv ciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVk aXRvcnMgYW5kDQpXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsDQpjb21tZW50cy4NCg0KSWYgeW91J3ZlIGJlZW4gZnJ1c3Ry YXRlZCBieSBiZWluZyBsaW1pdGVkIHRvIG9ubHkgb25lIElQIHR1bm5lbA0KYmV0d2VlbiBhIG1v YmlsZSBhY2Nlc3MgZ2F0ZXdheSBhbmQgYSBsb2NhbCBtb2JpbGl0eSBhbmNob3IsIHRoZW4NCnlv dSdsbCBiZSBnbGFkIHRvIGtub3cgdGhhdCB0aGlzIGRyYWZ0IGZpeGVzIHRoZSBwcm9ibGVtIGFu ZCBlbmFibGVzDQptdWx0aXBsZSBjYXJlLW9mIGFkZHJlc3NlcyBhbmQgSVAgdHVubmVscy4gTm93 IG1vYmlsZSBkZXZpY2VzIGNhbiBiZQ0KYXNzaWduZWQgdG8gYW55IGFwcGxpY2FibGUgdHVubmVs IGJldHdlZW4gdGhlIE1BRyBhbmQgdGhlIExNQS4NCg0KRm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLCB0aGUgYXV0aG9ycyBwcmVkaWN0YWJseSBkZWZlciB0byBSRkM1MjEzLA0KIlByb3h5IE1v YmlsZSBJUHY2IiwgYW5kIGFzc2VydCAibm8gaW1wYWN0IG9uIHRoZSBwcm90b2NvbCBzZWN1cml0 eSIuDQpIb3dldmVyLCB0aGVyZSBpcyBvbmUgc2VjdXJpdHkgaXNzdWUgdGhhdCBpcyBtZW50aW9u ZWQgaW4gUkZDNTIxMyB0aGF0DQppcyBleGFjZXJiYXRlZCBieSB0aGUgY3VycmVudCBkcmFmdC4g SS5lLiwNCg0KVG8gYWRkcmVzcyB0aGUgdGhyZWF0IHJlbGF0ZWQgdG8gYSBjb21wcm9taXNlZCBt b2JpbGUgYWNjZXNzIGdhdGV3YXksDQp0aGUgbG9jYWwgbW9iaWxpdHkgYW5jaG9yLCBiZWZvcmUg YWNjZXB0aW5nIGEgUHJveHkgQmluZGluZyBVcGRhdGUNCm1lc3NhZ2UgZm9yIGEgZ2l2ZW4gbW9i aWxlIG5vZGUsIG1heSBlbnN1cmUgdGhhdCB0aGUgbW9iaWxlIG5vZGUgaXMNCmF0dGFjaGVkIHRv IHRoZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgdGhhdCBzZW50IHRoZSBQcm94eSBCaW5kaW5nDQpV cGRhdGUgbWVzc2FnZS4NCg0KVGhlIFJGQyBoYXMgbm8gcmVjb21tZW5kYXRpb24gZm9yIGEgc29s dXRpb24sIGJ1dCBiZWNhdXNlIHRoZXJlIGFyZQ0Kbm93IG11bHRpcGxlIHR1bm5lbHMsIHRoaXMg YXNzdXJhbmNlIG1heSBiZSBtb3JlIGRpZmZpY3VsdCB0byBvYnRhaW4uDQpGb3IgZXhhbXBsZSwg aWYgdGhlIExNQSBleHBlY3RzIHRvIGNvbnRhY3Qgc29tZSBraW5kIG9mIHRydXN0ZWQgZW50aXR5 DQp0aGF0IGlzIGtlZXBpbmcgdHJhY2sgb2YgdGhlIG1vYmlsZSBkZXZpY2VzIHRoYXQgdGhlIE1B RyBpcyBzZW5kaW5nIG9uDQphIHR1bm5lbCwgdGhlbiB0aGUgTUFHIGFuZCBMTUEgbWF5IG5vdyBo YXZlIHRvIGtlZXAgdHJhY2sgb2YgbXVsdGlwbGUNCnRydXN0ZWQgZW50aXRpZXMsIG9uZSBmb3Ig ZWFjaCB0dW5uZWwuIFdoZXRoZXIgb3Igbm90IHRoaXMgaXMgYQ0KcmVhbGlzdGljIHNjZW5hcmlv IGlzIG5vdCBzb21ldGhpbmcgdGhhdCBJIGNhbiBqdWRnZSBiZWNhdXNlIFJGQzUyMTMNCnB1bnRz IG9uIHdoYXQgc2VlbXMgdG8gYmUgYW4gaW1wb3J0YW50IHNlY3VyaXR5IGlzc3VlLg0KDQpJcyB0 aGVyZSBhbnkgcmVhc29uIHRvIHdvcnJ5IGFib3V0IHJldXNlIG9mIENvQXM/IENvdWxkIHBhY2tl dHMgZnJvbQ0Kb25lIHR1bm5lbCBnZXQgYSBDb0EgdGhhdCB3YXMgcmVjZW50bHkgdXNlZCBieSBh bm90aGVyIHR1bm5lbCwgYW5kDQpjb3VsZCBkZWxheWVkIHBhY2tldHMgZ2V0IHJvdXRlZCB0aHJv dWdoIHRoZSB3cm9uZyB0dW5uZWw/IEp1c3QgYXNraW5nLg0KDQpOaXRzLiBPbiBwYWdlIDMgdGhl cmUgaXMgYSBwYXJhZ3JhcGggYmVnaW5uaW5nICJJbiB0aGUgY29udGludWF0aW9uDQpvZiBjLCBh IFByb3h5IE1vYmlsZSBJUHY2IC4uLiIgVGhlcmUgaXMgbm8gZXhwbGFuYXRpb24gb2YgImMiLiBJ cw0KdGhpcyBhIHJlbW5hbnQgb2YgYSBsaXN0IG9mIGl0ZW1zICJhLCBiLCBjIj8NCg0KT24gcGFn ZSA0IHRoZXJlIGlzIEZpZ3VyZSAxIHNob3dpbmcgZm91ciBmbG93cyBhbmQgdHdvIHR1bm5lbHMu IFRoZQ0KdGV4dCBpbW1lZGlhdGVseSBwcmVjZWRpbmcgdGhhdCBzYXlzIHRoYXQgIkZsb3ctMSwy IGFuZCAzIGFyZQ0KZGlzdHJpYnV0ZWQgZWl0aGVyIG9uIFR1bm5lbC0xIChvdmVyIExURSkgb3Ig VHVubmVsLTIgKG92ZXIgV0xBTikiLA0KYnV0IHRoZSBkaWFncmFtIHNob3dzIEZsb3ctMSBvbiBU dW5uZWwtMSBhbmQgRmxvdy0yLDMgb24gVHVubmVsLTIuDQpJIHRoaW5rIHRoZSB0ZXh0IHNob3Vs ZCBpbmRpY2F0ZSB0aGF0IHRoZSBmaXJzdCB0aHJlZSBmbG93cyBhcmUNCmVhY2ggYXNzaWduZWQg dG8gYSBzaW5nbGUgdHVubmVsLiBUaGUgYXV0aG9ycyBwcm9iYWJseSBtZWFudCB0aGF0DQplaXRo ZXIgVHVubmVsLTEgb3IgVHVubmVsLTIgY291bGQgaGF2ZSBiZWVuIGFzc2lnbmVkLCBidXQgdGhl IGNob2ljZQ0Kd2FzIHRvIHB1dCBGbG93LTEgb24gVHVubmVsLTEgYW5kIHRoZSBvdGhlciBmbG93 cyBvbiBUdW5uZWwtMi4NCkkgaGFkIHRvIHJlYWQgb3ZlciB0aGUgdGV4dCBzZXZlcmFsIHRpbWVz IGJlZm9yZSBJIHdhcyBzdXJlIG9mIHRoZQ0KaW50ZW50Lg0KDQpIaWxhcmllDQoNCk9uIDgvMS8x NywgMToxMyBQTSwgIkthdGhsZWVuIE1vcmlhcnR5Ig0KPEthdGhsZWVuLk1vcmlhcnR5LmlldGZA Z21haWwuY29tPG1haWx0bzpLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+DQp3cm90 ZToNCg0KS2F0aGxlZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmctMDQ6IERpc2N1c3MN Cg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbW0tbWFnLW11bHRp aG9taW5nLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K VGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcyBkcmFmdC4gIEkgaGFkIHRoZSBzYW1lIGNvbmNl cm4gYXMgdGhlDQpTZWNEaXINCnJldmlld2VyIGluIHJlYWRpbmcgdGhlIGRyYWZ0LCB0aGUgY29u Y2VybiBhYm91dCBsZWFraW5nIHRyYWZmaWMgYXMgYQ0KcmVzdWx0DQpvZg0KbXVsdGlwbGUgdHVu bmVscyBpcyBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0Kc2Vj dGlvbi4NCkhpbGFyeSdzIHdyaXRldXAgaXMgcXVpdGUgaGVscGZ1bA0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA3NDQ2Lmh0bWwNCg0K DQoNCg0KDQoNCg0K --_000_D5BB8C89287E2Csgundaveciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <062A78F83F39694D81570E961272502F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5IaSBLYXRobGVlbiw8L2Rpdj4NCjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+ PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogLXdlYmtpdC1zdGFuZGFyZDsiPlRoYW5rIHlvdSBzbyBtdWNoLiBQbGVhc2Ugc2VlIGlubGlu ZS48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAt d2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsgYm9yZGVy LWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsg Ym9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdp bjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+R29vZCBtb3JuaW5nLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24g V2VkLCBBdWcgMTYsIDIwMTcgYXQgMTE6MDQgUE0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk8 L2Rpdj4NCjxkaXY+Jmx0OzxhIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iPnNndW5k YXZlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJib3JkZXItbGVmdC1jb2xvcjog cmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1z dHlsZTogc29saWQ7IHBhZGRpbmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBw eCA1cHg7Ij4NCjxkaXY+SGkgS2F0aGxlZW4gYW5kIEhpbGFyaWUsPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHJldmlld2luZyB0aGUgZG9jdW1lbnRzIGFuZCB0 aGUgZmVlZGJhY2suIFBsZWFzZSBzZWU8L2Rpdj4NCjxkaXY+aW5saW5lLjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJib3Jk ZXItbGVmdC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItbGVmdC13aWR0aDogNXB4 OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmc6IDBweCAwcHggMHB4IDVweDsgbWFy Z2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXY+Rm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z LCB0aGUgYXV0aG9ycyBwcmVkaWN0YWJseSBkZWZlciB0byBSRkM1MjEzLDwvZGl2Pg0KPGRpdj7C s1Byb3h5IE1vYmlsZSBJUHY2wrIsIGFuZCBhc3NlcnQgJnF1b3Q7bm8gaW1wYWN0IG9uIHRoZSBw cm90b2NvbCBzZWN1cml0eSZxdW90Oy48L2Rpdj4NCjxkaXY+SG93ZXZlciwgdGhlcmUgaXMgb25l IHNlY3VyaXR5IGlzc3VlIHRoYXQgaXMgbWVudGlvbmVkIGluIFJGQzUyMTMgdGhhdDwvZGl2Pg0K PGRpdj5pczwvZGl2Pg0KPGRpdj5leGFjZXJiYXRlZCBieSB0aGUgY3VycmVudCBkcmFmdC4gSS5l Liw8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBp ZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImJvcmRlci1sZWZ0 LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1sZWZ0LXdpZHRoOiA1cHg7IGJvcmRl ci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBweCAwcHggNXB4OyBtYXJnaW46IDBw eCAwcHggMHB4IDVweDsiPg0KPGRpdj4mbmJzcDsmbmJzcDtUbyBhZGRyZXNzIHRoZSB0aHJlYXQg cmVsYXRlZCB0byBhIGNvbXByb21pc2VkIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSw8L2Rpdj4NCjxk aXY+dGhlPC9kaXY+DQo8ZGl2PmxvY2FsIG1vYmlsaXR5IGFuY2hvciwgYmVmb3JlIGFjY2VwdGlu ZyBhIFByb3h5IEJpbmRpbmcgVXBkYXRlIG1lc3NhZ2U8L2Rpdj4NCjxkaXY+Zm9yIGE8L2Rpdj4N CjxkaXY+Z2l2ZW4gbW9iaWxlIG5vZGUsIG1heSBlbnN1cmUgdGhhdCB0aGUgbW9iaWxlIG5vZGUg aXMgYXR0YWNoZWQgdG8gdGhlPC9kaXY+DQo8ZGl2Pm1vYmlsZTwvZGl2Pg0KPGRpdj5hY2Nlc3Mg Z2F0ZXdheSB0aGF0IHNlbnQgdGhlIFByb3h5IEJpbmRpbmcgVXBkYXRlIG1lc3NhZ2UuPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+QSBNQUcgaXMgcmVxdWlyZWQgdG8gcHJvdmUgdGhlIHByZXNlbmNlIG9mIGEgbW9iaWxlIG5v ZGXCuXMgcHJlc2VuY2Ugb248L2Rpdj4NCjxkaXY+aXRzPC9kaXY+DQo8ZGl2PihpbmdyZXNzKSBh Y2Nlc3MgbGluay4gVGhhdCBhc3NlcnRpb24gbmVlZHMgdG8gYmUgdmFsaWRhdGVkIGJ5IHRoZSBM TUEuPC9kaXY+DQo8ZGl2PkJ1dCw8L2Rpdj4NCjxkaXY+TUFHIHVzaW5nIGEgc2luZ2xlIHR1bm5l bCBvciBtdWx0aXBsZSB0dW5uZWxzIGhhcyBubyByZWxhdGlvbiB0byB0aGlzPC9kaXY+DQo8ZGl2 Pmlzc3VlLjwvZGl2Pg0KPGRpdj5UaGUgTE1BIGlkZW50aWZpZXMgdGhlIE1BRyB1c2luZyB0aGUg TUFHLU5BSSBhbmQgbm90IHVzaW5nIENhcmUtb2Y8L2Rpdj4NCjxkaXY+QWRkcmVzczs8L2Rpdj4N CjxkaXY+YSBuZXcgb3B0aW9uLCBNQUcgSWRlbnRpZmllciBvcHRpb24gaXMgZGVmaW5lZCBpbiBz ZWN0aW9uIDQuMiBmb3IgdGhpczwvZGl2Pg0KPGRpdj5wdXJwb3NlLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNvdWxkIHlv dSBhZGQgc29tZSB0ZXh0IHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0byBleHBsYWlu IHdoeTwvZGl2Pg0KPGRpdj50aGVyZSBpcyBubyBjb25jZXJuIHRoZW4gcmVsYXRlZCB0byBzcGxp dCB0dW5uZWxpbmcvZGF0YSBsZWFrYWdlIHRvPC9kaXY+DQo8ZGl2PnRoZSBpbmNvcnJlY3QgdHVu bmVsPzwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGZvbnQgY29sb3I9IiMwMDAwZmYi PjxiPkkgYXNzdW1lIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBiZWxvdyBkaXNjdXNzaW9uIHBv aW50LiZuYnNwOyZuYnNwO1dlIGNhbiBhZGQgc29tZSB0ZXh0LCBidXQgdGhpcyBJTUhPIGlzIGFi c29sdXRlbHkgYSBub24tZXhpc3RlbnQgc2NlbmFyaW87IG5vdCB0cnlpbmcgdG8gaWdub3JlIGEg dmFsaWQgaXNzdWUuIE91dCBvZiBvcmRlciBkZWxpdmVyeQ0KIHdpdGggc3VjaCBkZWxheXMsIHdo ZXJlIG9uZSBNQUcgcmVsZWFzaW5nIHRoZSBhZGRyZXNzIGFuZCBhbm90aGVyIE1BRyBvYnRhaW5p bmcgdGhlIHNhbWUgSVAgYWRkcmVzcyB3aXRoIHRoZSBhc3NvY2lhdGVkIGFkZHJlc3MgY29uZmln dXJhdGlvbiBkZWxheXMsIE1OIGF0dGFjaG1lbnQgdHJpZ2dlcmluZyBhIFBCVSBhdCB0aGF0IGp1 bmN0dXJlLCBhbmQgYSBQQlUvUEJBIGV4Y2hhbmdlLCZuYnNwOyZuYnNwO2EgdHVubmVsIGVzdGFi bGlzaG1lbnQgYW5kIGEgcGFja2V0DQogZnJvbSB0aGUgcHJldmlvdXMgTUFHIHNob3dpbmcgdXAg YXQgdGhlIG5ldyBNQUcgaXMgbm90IGEgdGVjaG5pY2FsIHBvc3NpYmlsaXR5LCBJTU8uIEkgYW0g bm90IGV2ZW4gc3VyZSBob3cgdG8gZnJhbWUgdGhpcy4mbmJzcDs8L2I+PC9mb250PjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Zm9udCBjb2xvcj0i IzAwMDBmZiI+PGI+PGJyPg0KPC9iPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxiPkJ1dCwgSSBh bSBoYXBweSB0byBpbmNsdWRlIGFueSB0ZXh0LCBidXQgSU1ITyBpdCB3aWxsIGJlIGEgdGV4dCBm b3Igbm9uLWV4aXN0ZW50IHNjZW5hcmlvLiBMZXQgbWUga25vdy48L2I+PC9mb250PjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Zm9udCBjb2xvcj0i IzAwMDBmZiI+PGI+PGJyPg0KPC9iPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxiPjxicj4NCjwv Yj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZDsiPjxmb250IGNvbG9yPSIjMDAwMGZmIj48Yj48YnI+DQo8L2I+PC9mb250PjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48Zm9udCBjb2xvcj0iIzAw MDBmZiI+PGI+UmVnYXJkczwvYj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogLXdlYmtpdC1zdGFuZGFyZDsiPjxmb250IGNvbG9yPSIjMDAwMGZmIj48Yj5Tcmk8L2I+PC9m b250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdlYmtpdC1zdGFu ZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5 NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlk OyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiIHN0eWxlPSJib3JkZXItbGVmdC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMp OyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRp bmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRl ci1sZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4 IDBweCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj5JcyB0aGVyZSBh bnkgcmVhc29uIHRvIHdvcnJ5IGFib3V0IHJldXNlIG9mIENvQXM/IENvdWxkIHBhY2tldHMgZnJv bTwvZGl2Pg0KPGRpdj5vbmU8L2Rpdj4NCjxkaXY+dHVubmVsIGdldCBhIENvQSB0aGF0IHdhcyBy ZWNlbnRseSB1c2VkIGJ5IGFub3RoZXIgdHVubmVsLCBhbmQgY291bGQ8L2Rpdj4NCjxkaXY+ZGVs YXllZDwvZGl2Pg0KPGRpdj5wYWNrZXRzIGdldCByb3V0ZWQgdGhyb3VnaCB0aGUgd3JvbmcgdHVu bmVsPyBKdXN0IGFza2luZy48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoZSB0dW5uZWxzIGJldHdlZW4gTE1BIGFuZCBNQUcgYXJlIGR5bmFtaWNhbGx5IGVz dGFibGlzaGVkIGFmdGVyPC9kaXY+DQo8ZGl2PnByb3RvY29sPC9kaXY+DQo8ZGl2PnNpZ25hbGlu Zy4gVGhlIGlkZWEgb2YgQ29BIHJlLXVzZSBiZXR3ZWVuIE1BR8K5cyBhbmQgZGVsYXllZCBwYWNr ZXRzPC9kaXY+DQo8ZGl2PmdldHRpbmc8L2Rpdj4NCjxkaXY+ZGVsaXZlcmVkIHRvIGEgZGlmZmVy ZW50IE1BRyBpcyBpbXBvc3NpYmxlIHRvIHJlYWxpemUgZXZlbiBpbiBsYWI8L2Rpdj4NCjxkaXY+ Y29uZGl0aW9ucy4gSXQgaXMgcG9zc2libGUgdGhlcmUgYXJlIHR3byBNQUfCuXMgaW4gYSBnaXZl biBhY2Nlc3M8L2Rpdj4NCjxkaXY+bmV0d29yayBhbmQ8L2Rpdj4NCjxkaXY+b25lIGxvb3NlcyB0 aGUgQ29BIGFuZCB0aGUgb3RoZXIgTUFHIGdldHMgdGhlIG5hbWUgYWRkcmVzcy4gQnV0LCB0aGU8 L2Rpdj4NCjxkaXY+dHVubmVsczwvZGl2Pg0KPGRpdj5jb21lcyB1cCBhZnRlciBQQlUvUEJBIGV4 Y2hhbmdlIHdoaWNoIGludHJvZHVjZXMgc29tZSBkZWxheSwgYW5kIHNvIHRoZTwvZGl2Pg0KPGRp dj5wb3NzaWJpbGl0eSBvZiBwYWNrZXRzIGZyb20gcHJldmlvdXMgTUFHLWVyYSBnZXR0aW5nIHNo b3dpbmcgdXAgYXQgdGhlPC9kaXY+DQo8ZGl2Pm5ldzwvZGl2Pg0KPGRpdj5NQUcgaXMgbmVhcmx5 IGltcG9zc2libGUgYW5kIGlzIG5vdCB3b3J0aCBtZW50aW9uaW5nIGl0LCBJTU8uPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNf T1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6 IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQt c3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAw cHggNXB4OyI+DQo8ZGl2Pk5pdHMuIE9uIHBhZ2UgMyB0aGVyZSBpcyBhIHBhcmFncmFwaCBiZWdp bm5pbmcgwrNJbiB0aGUgY29udGludWF0aW9uIG9mPC9kaXY+DQo8ZGl2PmMsPC9kaXY+DQo8ZGl2 PmEgUHJveHkgTW9iaWxlIElQdjYgLi4uJnF1b3Q7IFRoZXJlIGlzIG5vIGV4cGxhbmF0aW9uIG9m IMKzYyZxdW90Oy4gSXMgdGhpcyBhPC9kaXY+DQo8ZGl2PnJlbW5hbnQ8L2Rpdj4NCjxkaXY+b2Yg YSBsaXN0IG9mIGl0ZW1zICZxdW90O2EsIGIsIGMmcXVvdDs/PC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GaXhlZCBpbiAtMDQgdmVyc2lvbjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiBy Z2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1sZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0 eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBweCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4 IDVweDsiPg0KT24gcGFnZSA0IHRoZXJlIGlzIEZpZ3VyZSAxIHNob3dpbmcgZm91ciBmbG93cyBh bmQgdHdvIHR1bm5lbHMuIFRoZTwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PldlIGp1c3Qgd2FudGVkIHRvIGhpbnQgdGhhdCB0aGUgRmxvdy00IGlzIGJhc2VkIG9uIHBlci1w YWNrZXQgbG9hZDwvZGl2Pg0KPGRpdj5iYWxhbmNpbmc8L2Rpdj4NCjxkaXY+dXNpbmcgYm90aCB0 aGUgcGF0aHMsIHdoZXJlYXMgdGhlIG90aGVyIGZsb3dzIGFyZSByb3V0ZWQgYmFzZWQgb248L2Rp dj4NCjxkaXY+UGVyLWZsb3c8L2Rpdj4NCjxkaXY+bG9hZCBiYWxhbmNpbmcuIEJ1dCwgSSB0aGlu ayB0aGUgY29tbWVudCBpcyBzdGlsbCB2YWxpZC4gV2Ugc2hvdWxkIHNob3c8L2Rpdj4NCjxkaXY+ dGhlPC9kaXY+DQo8ZGl2PnVzZSBvZiBhIHNpbmdsZSBmb3J3YXJkaW5nIG1vZGUgYW5kIG5vdCBt aXggYm90aCB0aGUgbW9kZXMuIE1pbm9yIG5pdCw8L2Rpdj4NCjxkaXY+d2lsbDwvZGl2Pg0KPGRp dj5maXggaXQuPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGFuayB5b3UgZm9yIGZpeGluZyB0aGlzLjwvZGl2Pg0KPGRpdj5LYXRobGVlbjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsg Ym9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5n OiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmsgeW91IGZvciB5b3VyIHJldmll dy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdh cmRzPC9kaXY+DQo8ZGl2PlNyaTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+4oC54oC5 4oC54oC54oC54oC54oC54oC54oC54oC54oC54oC54oC54oC54oC54oC54oC5PC9kaXY+DQo8ZGl2 PlNlY3VyaXR5IHJldmlldyBvZjwvZGl2Pg0KPGRpdj5NQUcgTXVsdGlwYXRoIEJpbmRpbmcgT3B0 aW9uPC9kaXY+DQo8ZGl2PmRyYWZ0LWlldGYtZG1tLW1hZy1tdWx0aWhvbWluZy0wMy50eHQ8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvIG5vdCBiZSBhbGFybWVkLiBJIGhhdmUgcmV2 aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZTwvZGl2Pg0KPGRpdj5zZWN1cml0eSBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHM8 L2Rpdj4NCjxkaXY+YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3 ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5PC9kaXY+DQo8ZGl2PmZvciB0aGUgYmVuZWZpdCBvZiB0aGUg c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kPC9kaXY+DQo8ZGl2 PldHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGw8L2Rpdj4NCjxkaXY+Y29tbWVudHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JZiB5b3UndmUgYmVlbiBmcnVzdHJhdGVkIGJ5IGJlaW5nIGxpbWl0ZWQgdG8gb25s eSBvbmUgSVAgdHVubmVsPC9kaXY+DQo8ZGl2PmJldHdlZW4gYSBtb2JpbGUgYWNjZXNzIGdhdGV3 YXkgYW5kIGEgbG9jYWwgbW9iaWxpdHkgYW5jaG9yLCB0aGVuPC9kaXY+DQo8ZGl2PnlvdSdsbCBi ZSBnbGFkIHRvIGtub3cgdGhhdCB0aGlzIGRyYWZ0IGZpeGVzIHRoZSBwcm9ibGVtIGFuZCBlbmFi bGVzPC9kaXY+DQo8ZGl2Pm11bHRpcGxlIGNhcmUtb2YgYWRkcmVzc2VzIGFuZCBJUCB0dW5uZWxz LiBOb3cgbW9iaWxlIGRldmljZXMgY2FuIGJlPC9kaXY+DQo8ZGl2PmFzc2lnbmVkIHRvIGFueSBh cHBsaWNhYmxlIHR1bm5lbCBiZXR3ZWVuIHRoZSBNQUcgYW5kIHRoZSBMTUEuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHRoZSBhdXRo b3JzIHByZWRpY3RhYmx5IGRlZmVyIHRvIFJGQzUyMTMsPC9kaXY+DQo8ZGl2PiZxdW90O1Byb3h5 IE1vYmlsZSBJUHY2JnF1b3Q7LCBhbmQgYXNzZXJ0ICZxdW90O25vIGltcGFjdCBvbiB0aGUgcHJv dG9jb2wgc2VjdXJpdHkmcXVvdDsuPC9kaXY+DQo8ZGl2Pkhvd2V2ZXIsIHRoZXJlIGlzIG9uZSBz ZWN1cml0eSBpc3N1ZSB0aGF0IGlzIG1lbnRpb25lZCBpbiBSRkM1MjEzIHRoYXQ8L2Rpdj4NCjxk aXY+aXMgZXhhY2VyYmF0ZWQgYnkgdGhlIGN1cnJlbnQgZHJhZnQuIEkuZS4sPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UbyBhZGRyZXNzIHRoZSB0aHJlYXQgcmVsYXRlZCB0byBhIGNv bXByb21pc2VkIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSw8L2Rpdj4NCjxkaXY+dGhlIGxvY2FsIG1v YmlsaXR5IGFuY2hvciwgYmVmb3JlIGFjY2VwdGluZyBhIFByb3h5IEJpbmRpbmcgVXBkYXRlPC9k aXY+DQo8ZGl2Pm1lc3NhZ2UgZm9yIGEgZ2l2ZW4gbW9iaWxlIG5vZGUsIG1heSBlbnN1cmUgdGhh dCB0aGUgbW9iaWxlIG5vZGUgaXM8L2Rpdj4NCjxkaXY+YXR0YWNoZWQgdG8gdGhlIG1vYmlsZSBh Y2Nlc3MgZ2F0ZXdheSB0aGF0IHNlbnQgdGhlIFByb3h5IEJpbmRpbmc8L2Rpdj4NCjxkaXY+VXBk YXRlIG1lc3NhZ2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgUkZDIGhhcyBu byByZWNvbW1lbmRhdGlvbiBmb3IgYSBzb2x1dGlvbiwgYnV0IGJlY2F1c2UgdGhlcmUgYXJlPC9k aXY+DQo8ZGl2Pm5vdyBtdWx0aXBsZSB0dW5uZWxzLCB0aGlzIGFzc3VyYW5jZSBtYXkgYmUgbW9y ZSBkaWZmaWN1bHQgdG8gb2J0YWluLjwvZGl2Pg0KPGRpdj5Gb3IgZXhhbXBsZSwgaWYgdGhlIExN QSBleHBlY3RzIHRvIGNvbnRhY3Qgc29tZSBraW5kIG9mIHRydXN0ZWQgZW50aXR5PC9kaXY+DQo8 ZGl2PnRoYXQgaXMga2VlcGluZyB0cmFjayBvZiB0aGUgbW9iaWxlIGRldmljZXMgdGhhdCB0aGUg TUFHIGlzIHNlbmRpbmcgb248L2Rpdj4NCjxkaXY+YSB0dW5uZWwsIHRoZW4gdGhlIE1BRyBhbmQg TE1BIG1heSBub3cgaGF2ZSB0byBrZWVwIHRyYWNrIG9mIG11bHRpcGxlPC9kaXY+DQo8ZGl2PnRy dXN0ZWQgZW50aXRpZXMsIG9uZSBmb3IgZWFjaCB0dW5uZWwuIFdoZXRoZXIgb3Igbm90IHRoaXMg aXMgYTwvZGl2Pg0KPGRpdj5yZWFsaXN0aWMgc2NlbmFyaW8gaXMgbm90IHNvbWV0aGluZyB0aGF0 IEkgY2FuIGp1ZGdlIGJlY2F1c2UgUkZDNTIxMzwvZGl2Pg0KPGRpdj5wdW50cyBvbiB3aGF0IHNl ZW1zIHRvIGJlIGFuIGltcG9ydGFudCBzZWN1cml0eSBpc3N1ZS48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PklzIHRoZXJlIGFueSByZWFzb24gdG8gd29ycnkgYWJvdXQgcmV1c2Ugb2Yg Q29Bcz8gQ291bGQgcGFja2V0cyBmcm9tPC9kaXY+DQo8ZGl2Pm9uZSB0dW5uZWwgZ2V0IGEgQ29B IHRoYXQgd2FzIHJlY2VudGx5IHVzZWQgYnkgYW5vdGhlciB0dW5uZWwsIGFuZDwvZGl2Pg0KPGRp dj5jb3VsZCBkZWxheWVkIHBhY2tldHMgZ2V0IHJvdXRlZCB0aHJvdWdoIHRoZSB3cm9uZyB0dW5u ZWw/IEp1c3QgYXNraW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tml0cy4gT24g cGFnZSAzIHRoZXJlIGlzIGEgcGFyYWdyYXBoIGJlZ2lubmluZyAmcXVvdDtJbiB0aGUgY29udGlu dWF0aW9uPC9kaXY+DQo8ZGl2Pm9mIGMsIGEgUHJveHkgTW9iaWxlIElQdjYgLi4uJnF1b3Q7IFRo ZXJlIGlzIG5vIGV4cGxhbmF0aW9uIG9mICZxdW90O2MmcXVvdDsuIElzPC9kaXY+DQo8ZGl2PnRo aXMgYSByZW1uYW50IG9mIGEgbGlzdCBvZiBpdGVtcyAmcXVvdDthLCBiLCBjJnF1b3Q7PzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gcGFnZSA0IHRoZXJlIGlzIEZpZ3VyZSAxIHNo b3dpbmcgZm91ciBmbG93cyBhbmQgdHdvIHR1bm5lbHMuIFRoZTwvZGl2Pg0KPGRpdj50ZXh0IGlt bWVkaWF0ZWx5IHByZWNlZGluZyB0aGF0IHNheXMgdGhhdCAmcXVvdDtGbG93LTEsMiBhbmQgMyBh cmU8L2Rpdj4NCjxkaXY+ZGlzdHJpYnV0ZWQgZWl0aGVyIG9uIFR1bm5lbC0xIChvdmVyIExURSkg b3IgVHVubmVsLTIgKG92ZXIgV0xBTikmcXVvdDssPC9kaXY+DQo8ZGl2PmJ1dCB0aGUgZGlhZ3Jh bSBzaG93cyBGbG93LTEgb24gVHVubmVsLTEgYW5kIEZsb3ctMiwzIG9uIFR1bm5lbC0yLjwvZGl2 Pg0KPGRpdj5JIHRoaW5rIHRoZSB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBmaXJzdCB0 aHJlZSBmbG93cyBhcmU8L2Rpdj4NCjxkaXY+ZWFjaCBhc3NpZ25lZCB0byBhIHNpbmdsZSB0dW5u ZWwuIFRoZSBhdXRob3JzIHByb2JhYmx5IG1lYW50IHRoYXQ8L2Rpdj4NCjxkaXY+ZWl0aGVyIFR1 bm5lbC0xIG9yIFR1bm5lbC0yIGNvdWxkIGhhdmUgYmVlbiBhc3NpZ25lZCwgYnV0IHRoZSBjaG9p Y2U8L2Rpdj4NCjxkaXY+d2FzIHRvIHB1dCBGbG93LTEgb24gVHVubmVsLTEgYW5kIHRoZSBvdGhl ciBmbG93cyBvbiBUdW5uZWwtMi48L2Rpdj4NCjxkaXY+SSBoYWQgdG8gcmVhZCBvdmVyIHRoZSB0 ZXh0IHNldmVyYWwgdGltZXMgYmVmb3JlIEkgd2FzIHN1cmUgb2YgdGhlPC9kaXY+DQo8ZGl2Pmlu dGVudC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkhpbGFyaWU8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uIDgvMS8xNywgMToxMyBQTSwgJnF1b3Q7S2F0aGxlZW4gTW9y aWFydHkmcXVvdDs8L2Rpdj4NCjxkaXY+Jmx0OzxhIGhyZWY9Im1haWx0bzpLYXRobGVlbi5Nb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbSI+S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+ Jmd0OzwvZGl2Pg0KPGRpdj53cm90ZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkth dGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcjwvZGl2Pg0KPGRpdj5kcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmctMDQ6IERpc2N1 c3M8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDwvZGl2Pg0KPGRp dj5lbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpczwvZGl2Pg0KPGRpdj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLik8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Q bGVhc2UgcmVmZXIgdG8mbmJzcDs8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIj5odHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PC9kaXY+DQo8 ZGl2PmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBw b3NpdGlvbnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmcvIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtbS1tYWctbXVsdGlob21pbmcvPC9hPjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2PkRJU0NVU1M6PC9kaXY+DQo8ZGl2 Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3Ig eW91ciB3b3JrIG9uIHRoaXMgZHJhZnQuJm5ic3A7Jm5ic3A7SSBoYWQgdGhlIHNhbWUgY29uY2Vy biBhcyB0aGU8L2Rpdj4NCjxkaXY+U2VjRGlyPC9kaXY+DQo8ZGl2PnJldmlld2VyIGluIHJlYWRp bmcgdGhlIGRyYWZ0LCB0aGUgY29uY2VybiBhYm91dCBsZWFraW5nIHRyYWZmaWMgYXMgYTwvZGl2 Pg0KPGRpdj5yZXN1bHQ8L2Rpdj4NCjxkaXY+b2Y8L2Rpdj4NCjxkaXY+bXVsdGlwbGUgdHVubmVs cyBpcyBub3QgYWRkcmVzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uczwvZGl2Pg0K PGRpdj5zZWN0aW9uLjwvZGl2Pg0KPGRpdj5IaWxhcnkncyB3cml0ZXVwIGlzIHF1aXRlIGhlbHBm dWw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDc0NDYuaHRtbCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZWNkaXIvY3VycmVudC9tc2cwNzQ0 Ni5odG1sPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D5BB8C89287E2Csgundaveciscocom_-- From nobody Fri Aug 18 01:31:15 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF51326DF for ; Fri, 18 Aug 2017 01:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNjFwWnLyGKC for ; Fri, 18 Aug 2017 01:31:13 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A843C132335 for ; Fri, 18 Aug 2017 01:31:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=FEcCvyRiEYqgVB1rvD8z8qaMKTmADcGXHG8B8FW3EtfNVXvqRnH27pMgYekJEkrAk0l2yXvnV2UGXaSNfJtNT3oL3mVbMJEN8O0H+GIZned5UmS70fwCmPU6YopvHydpyxqs0M3LY77KOGmZxpEhz5Ei+6Kxl5dzeHcVnWUHaxU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1353 invoked from network); 18 Aug 2017 10:24:30 +0200 Received: from p5dec23ce.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.35.206) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2017 10:24:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 18 Aug 2017 10:24:27 +0200 Cc: The IESG , "dmm-chairs@ietf.org" , Jouni Korhonen , "draft-ietf-dmm-mag-multihoming@ietf.org" , "dmm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150153774387.6368.10402951105593501459.idtracker@ietfa.amsl.com> <89C42C3C-4A49-4CB1-B853-D834900281D8@kuehlewind.net> To: "Sri Gundavelli (sgundave)" X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170818082430.1344.38121@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-mag-multihoming-04=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 08:31:14 -0000 Thanks! Will wait for the next version! > Am 18.08.2017 um 03:08 schrieb Sri Gundavelli (sgundave) = : >=20 > Hi Mirja, >=20 > Thank you for your quick feedback. Please see inline =E2=80=A6 >=20 >=20 >=20 > On 8/17/17, 6:12 AM, "Mirja Kuehlewind (IETF)" = wrote: >=20 > .. keeping only the open issues. >=20 >>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> 3) This document does not really normative specify the use of the = newly >>>> defined >>>> options. It only gives an examples but it does not specify = normatively >>>> any >>>> actions that need to performed on receipt of these options. How = does >>>> the >>>> MAG >>>> know if the LMA does not support Multipath binding? An LMA that = does >>>> not >>>> implement this spec will not send back an error message. Why are = there >>>> two >>>> different options? What happens if one of the options is present in = the >>>> Proxy >>>> Binding Update but not the other? >>>>=20 >>>=20 >>>=20 >>> This is a good point. There is an implicit assumption that the LMA >>> behavior is consistent with the behavior when dealing with any = unknown >>> options.=20 >>> We can put a note that the PBU will rejected with error code 128. >>=20 >> That's good. Are you supposed to resend without the new options if = you >> received 128? And again what happens if only one option is present? >=20 > I will take care of this. Will add considerations on both LMA/MAG = behavior > when there is version incompatibility. Will post a new rev with these > considerations. But, thank you; we definitely overlooked this part. >=20 >=20 >=20 >=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Please also clarify the definitions of Interface Label and Binding >>>> Identifier >>>> as requested by the gen-art review (Thanks Robert!) >>>>=20 >>>=20 >>> Interface label is a static field, Ex: =E2=80=9CLTE-Interface=E2=80=9D= , =E2=80=9Cmy blue >>> interface=E2=80=9D. Traffic policy is tied to this static label, >>>=20 >>> HTTP Flow: Use LTE-Interface, if not available, use = =E2=80=9CWiFI-Interface=E2=80=9D. >>> Label is tied to a policy; which the MAG and LMA will translate it = bind >>> the flow to a dynamically created tunnel using the CoA from that >>> interface. >>>=20 >>> Binding identifier is what is dynamically generated and using to >>> identify >>> a specific binding on the LMA. >>=20 >> I think this comment was on the way it is described in the draft. = Maybe >> the wording can be further clarified there. Here is the original text >> from the genart review of Robert Sparks: >=20 >=20 > I have looked at both the definitions and I agree it needs to some > clarification. I will fix this. >=20 >=20 >=20 >=20 >>=20 >> "* I still find the definitions of Interface Label and Binding = Identifier >> confusing. >> I suspect they _both_ need to be carefully rewritten to make sure = they >> are >> definitions of the terms, and not descriptions of the interactions = of >> the two >> fields. Why is the Interface Label definition talking so much about >> binding? >> As currently written, that last sentence of the Binding Identifier >> definition says the document says the mobile access gateway assigns >> a single unique binding identifier for each of its interfaces. =E2=80=9E= >>=20 >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Sun Aug 20 19:55:12 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD71200F3; Sun, 20 Aug 2017 19:55:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: suresh.krishnan@gmail.com, dmm-chairs@ietf.org, dmm@ietf.org, sgundave@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150328411076.6629.4893157714389013426.idtracker@ietfa.amsl.com> Date: Sun, 20 Aug 2017 19:55:10 -0700 Archived-At: Subject: [DMM] dmm - New Meeting Session Request for IETF 100 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 02:55:11 -0000 A new meeting session request has just been submitted by Sri Gundavelli, a Chair of the dmm working group. --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Sri Gundavelli Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: intarea, lpwan, ipwave Second Priority: 6man People who must be present: Sri Gundavelli Suresh Krishnan Dapeng Liu Resources Requested: Special Requests: Preferred: Monday --------------------------------------------------------- From nobody Tue Aug 22 14:55:19 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B55132A7E; Tue, 22 Aug 2017 14:55:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150343891797.6009.18151413294505237191@ietfa.amsl.com> Date: Tue, 22 Aug 2017 14:55:17 -0700 Archived-At: Subject: [DMM] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-dmm-mag-multihoming belonging to Chemtron Research LLC X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 21:55:18 -0000 Dear Pierrick Seite, Alper E. Yegin, Sri Gundavelli: An IPR disclosure that pertains to your Internet-Draft entitled "MAG Multipath Binding Option" (draft-ietf-dmm-mag-multihoming) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3052/). The title of the IPR disclosure is "Eric Rescorla's Statement about IPR related to draft-ietf-dmm-mag-multihoming belonging to Chemtron Research LLC" Thank you IETF Secretariat From nobody Mon Aug 28 07:52:50 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9A3132A05; Mon, 28 Aug 2017 07:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQEeU3LJDJKx; Mon, 28 Aug 2017 07:52:48 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4302E1328DB; Mon, 28 Aug 2017 07:52:48 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 83so2086185pgb.4; Mon, 28 Aug 2017 07:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:reply-to:user-agent:mime-version :content-transfer-encoding; bh=BsJjef1mq8dgnO7GnQykG/WlPLsoWLsy0RYnIj+5WcE=; b=e92b4Lp7m3Df9SvpMcmLXqAKqL3pYPRZuXssv4LV/+GS7NCU/P6C3EGPUwFiRt5pqs zhcbH7sYBNR0ShtYx8HAAx5ray8rJHFnPqjTYaDx5WXvNkLoQJUJ37HlGqHKk1S2tAg1 U44uMMpU02rkTe4BhJFbvtEmxLJEcJ/V6++UgIKi2k9hgr1AaOgE2ZlFDLLn3ZYRTg5m RGHCdFm6ZoRFFi46s8tgFSMcmdhcD5UukYqQuRzz6JIeOIiUvFUpnM9UeCvkCoGzDFlU Ps2oIVyAW7MWK8XZPPHzXAWsiYyBP2X0n+ukOmAc46cLGPb+5Ew5nj7/CblBSuC/UKsu hKPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:reply-to :user-agent:mime-version:content-transfer-encoding; bh=BsJjef1mq8dgnO7GnQykG/WlPLsoWLsy0RYnIj+5WcE=; b=fG5GxNI5SyedEbIcBzEC5YnuPjYWYGAmnmHm+xYlTJvYbe6pOZEF6ELGYaivglcX9u fu2xp3JkPu29Sq/JQwYBjWoyBX6YMlnZ25argjODlf29+BFTo6Crn99c2f963OW+LBi8 HxSQwEJhgwKIzbrHtuA3upUjAhthdPYuiYCDM6sEGBRcz59PQUrP/1BM2/puXE0BMlsd 4G41tP2Hajq5myE/R62dQXiD2KPMSaNU04ldl50DNzBxVulfQuC8HQXug7idpsExKRKH raYZgorlGxrWEjqWbzRbO4QyDlWbuO0D+UKzuI6UBZWy27dwnn0+mDtafBygNJzmZBgM 8BmQ== X-Gm-Message-State: AHYfb5g3n8Gz7QxAElaFaVP+pd+HhhP03Len/u/nGV5dT6nB9/Xm7EjY ze42xVDFV0GdKIQKWMw= X-Received: by 10.98.10.202 with SMTP id 71mr864068pfk.176.1503931967549; Mon, 28 Aug 2017 07:52:47 -0700 (PDT) Received: from [192.168.10.7] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id 74sm1098351pfo.74.2017.08.28.07.52.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 07:52:46 -0700 (PDT) From: "Kentaro Ebisawa" To: dmm@ietf.org, spring@ietf.org Cc: "Matsushima Satoru" Date: Mon, 28 Aug 2017 14:52:44 +0000 Message-Id: Reply-To: "Kentaro Ebisawa" User-Agent: eM_Client/7.1.30646.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 14:52:50 -0000 Hi, I have a few questions about how Encoded SID should be placed in Segment=20 List and IPv6 Dst Address in Mobile User-Plane use case. # Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01. # I tried to check Slides from IETF 99 but link seems to be missing. #=20 https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobile-user-plane/ Q1) Up Link packet (existing network to SRv6) > outer IPv4 and tunnel header. And then the endpoint does T.Insert > process with the SID which consists of the allocated domain-wise SID > prefix, source and destination addresses, and tunnel identifier as > described in Figure 3. Then the endpoint send out the packet to the > SRv6 network along with its routing policy. How would IPv6 src/dst addr and Segment List look like for this Up Link=20 packet? (existing network to SRv6) My understanding is usually source address of the T.Insert node is not=20 included in Segment List. But from above description, it looks like you intend to require Encoded=20 SID (Fig 3) to be included in the Segment List of UL packet. For example, is below packet structure what you intended in case you=20 have n segments to traverse in SRv6 nework? IPv6 Src: Encoded SID or T.Insert node ?? IPv6 Dst: SL[n] Segment Left =3D n SL[0] =3D Segment 0 SL[n] =3D Segment n SL[n+1] =3D Encoded SID Q2) Down Link packet (SRv6 to existing network) > When the endpoint receives packet and the active segment of the > packet indicates the SID, the endpoint pop the SRH of the SID, and On the other hand, are there any reason that description in page 7 does=20 not mandate m to be zero while requiring to pop the SRH? My understanding of DL packet (SRv6 to existing network) is as below. IPv6 Src: Origin Host IPv6 Dst: SL[n] Segment Left =3D n SL[m] =3D Encoded SID SL[m+1] =3D Segment m+1 SL[n] =3D Segment n Regards, -- Ponto Networks, Inc. Kentaro Ebisawa From nobody Mon Aug 28 08:44:14 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6A51321B6; Mon, 28 Aug 2017 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW31n8GsQp_G; Mon, 28 Aug 2017 08:44:10 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F039E126C7A; Mon, 28 Aug 2017 08:44:09 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id r133so2509075pgr.3; Mon, 28 Aug 2017 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=DzPt2i7klPth5n/zwfYD4/OXSjm4NaDrbGGaFuVC+L8=; b=gFBkw7xnnQ9ibtaa+JuPkrKevyzYG8ISE/V9i9HAwPoMH09hUm4ZVW0BrtayE0hSms NhV/QnFEpOgrBWR81zI4daE/kMseWRbXTqIBHUhjP6tQEyPobC99JihALjbDUnqumTlE Hv30FQ/K6FhUnAP8+Gbrh6xOTBw/KRMHNQIf6N1aBThBXUuTLL0Y4anD2b2jz1b7eRAl GGAtoD7IFEweO8gqxvKgwkWcH+Uj7lt2Gz6yUF1U7yxN52kp0yu1f/WMaCE+KIAVlOAM JoUtnM+ImupCe7kTAf3DCqSVJRV8LaCNIgGrNzlRuf7DL9bKkH6c/MxMhoRfpJmOo5dO mQ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=DzPt2i7klPth5n/zwfYD4/OXSjm4NaDrbGGaFuVC+L8=; b=OIymXKX6n+UzRCDlGb4y1Mc1u/A4EveRWqy1SCswBQIoKmBYHRCqMu7v0EzYFc7Atb 3+jNH8vQw+6FYCa8PZ8T9SqWiPWcSKNw69KwksJ1G4XM2L5EyuM0a67BduKKT7zfcR/4 GDbYFxUYvxzv1zcyzglRzLEkdDJHCWRRPdej7rLoWBWEYpDlbPa3/vqivWKyoM++yf5o t877kRbd8HulSLGqF+TIcyCrEsMKutUmm8wdHAKiGU7n2pIdQMVL6bGPWPEKsfxy5Icn Tjs+9f27jCZwl8JRMqHTEJapK2SzpZPObp8auvbfTxmpIEe5TXrygt1ZO0TLZg/eCua1 yPbQ== X-Gm-Message-State: AHYfb5jCGhiziQ9wka92SBme9BbXgJUlDu21cGjvDwV7rx+JizrKj/hL xMWVsEt6B9ffOOGUZtU= X-Received: by 10.84.231.15 with SMTP id f15mr1302084plk.334.1503935048871; Mon, 28 Aug 2017 08:44:08 -0700 (PDT) Received: from [192.168.10.7] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id t10sm1306552pgr.54.2017.08.28.08.44.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 08:44:07 -0700 (PDT) From: "Kentaro Ebisawa" To: dmm@ietf.org, spring@ietf.org Cc: "Matsushima Satoru" Date: Mon, 28 Aug 2017 15:44:05 +0000 Message-Id: In-Reply-To: References: Reply-To: "Kentaro Ebisawa" User-Agent: eM_Client/7.1.30646.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 15:44:12 -0000 Hi, > Q2) Down Link packet (SRv6 to existing network) > > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, and > ... > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left =3D n > SL[m] =3D Encoded SID > SL[m+1] =3D Segment m+1 > SL[n] =3D Segment n Actually I think this differs for T.Insert case, where MN user packet is=20 IPv6. # Unless I missed description that Stateless Interworking will always=20 use encapsulation mode even if user packet is IPv6. IPv6 Src: Origin Host IPv6 Dst: SL[n] Segment Left =3D n SL[0] =3D MN address SL[1] =3D Encoded SID SL[n] =3D Segment n And interworking segment should behave like below. When the endpoint receives packet and the active segment of the packet indicates the SID, the endpoint pop the SRH of the SID, >> Set IPv6 destination address as SL[0] (MN's address), and then the endpoint encaps the payload with the encoded information in the SID which are tunnel identifier of tunnel header, source and destination IPv4 address of IPv4 header described in Figure 3. Maybe having example packet headers described for each cases=20 (encap/insert, User Packet =3D IPv4/IPv6) will help this makes more easier= =20 to understand. Thanks, -- Ponto Networks, Inc. Kentaro Ebisawa ------ Original Message ------ From: "Kentaro Ebisawa" To: dmm@ietf.org; spring@ietf.org Cc: "Matsushima Satoru" Sent: 2017/08/28 23:52:44 Subject: How Encoded SID should be placed in SL (SRv6-mobile-uplane) >Hi, > >I have a few questions about how Encoded SID should be placed in=20 >Segment List and IPv6 Dst Address in Mobile User-Plane use case. > ># Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01. ># I tried to check Slides from IETF 99 but link seems to be missing. >#=20 >https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobile-user-plane/ > > >Q1) Up Link packet (existing network to SRv6) > > > outer IPv4 and tunnel header. And then the endpoint does T.Insert > > process with the SID which consists of the allocated domain-wise SID > > prefix, source and destination addresses, and tunnel identifier as > > described in Figure 3. Then the endpoint send out the packet to the > > SRv6 network along with its routing policy. > >How would IPv6 src/dst addr and Segment List look like for this Up Link=20 >packet? (existing network to SRv6) >My understanding is usually source address of the T.Insert node is not=20 >included in Segment List. >But from above description, it looks like you intend to require Encoded=20 >SID (Fig 3) to be included in the Segment List of UL packet. > >For example, is below packet structure what you intended in case you=20 >have n segments to traverse in SRv6 nework? > >IPv6 Src: Encoded SID or T.Insert node ?? >IPv6 Dst: SL[n] >Segment Left =3D n >SL[0] =3D Segment 0 >SL[n] =3D Segment n >SL[n+1] =3D Encoded SID > > >Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, and > >On the other hand, are there any reason that description in page 7 does=20 >not mandate m to be zero while requiring to pop the SRH? >My understanding of DL packet (SRv6 to existing network) is as below. > >IPv6 Src: Origin Host >IPv6 Dst: SL[n] >Segment Left =3D n >SL[m] =3D Encoded SID >SL[m+1] =3D Segment m+1 >SL[n] =3D Segment n > > >Regards, >-- >Ponto Networks, Inc. >Kentaro Ebisawa From nobody Mon Aug 28 18:25:04 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AB11321A4; Mon, 28 Aug 2017 18:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMgxXlqgjzLz; Mon, 28 Aug 2017 18:24:54 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95765126BF3; Mon, 28 Aug 2017 18:24:54 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id l132so5910400vke.5; Mon, 28 Aug 2017 18:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n65bbUHylp9kNvCJm0Jp5hnScyCFHtfvemxSKmZblzs=; b=uW733BZcfBVi9yBPfR/goFrRLuIk+Y2Alg9RU4ojnodp0FT9H9l8hTgOnD8SMAtcC4 JRgAYuZOgNCnMOax9Ofny+IAiEdsSm1WHPyf9yKCrHhm8Am+mWl8SMmHYZY831C9q8DG zTS1fv0V0s6z3c3TyeziJuZiVdFZUF90V22CRCcQnnyDGTGWbZeSyCIXhufjp4hbVi8t 5qAELfRdgXrC/YVY6CG/oxCYDNO7nyhzbLefEuyckV8JqPOh4J/yunlxTDhqtqFoZpHc v5+yQrwVC1njagqj9uLYrPQt7MQ9lF0dzBqVVdpOjlpEVAN3tMTU/fNW9Dp2hA1iF41s dXyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n65bbUHylp9kNvCJm0Jp5hnScyCFHtfvemxSKmZblzs=; b=ZOgajTZMxv1R+U1F40lV0IiqqcCQYWExpt9DAhNBU1jf982d1x85YiY0oALlNxjdPI /9VfRm4VhXcy6amPtkgMF/6JM0RtKsG6X31wClIwprxW3txIJcvsPj5FKucyOD6ShGgz zEGJIX0rrF1RbzQtpc4V2g/UwkHB8Qjt+mmUk1CZP3znZorWsby9HBW/Q1rhDmTZP5SV gWrpG5xdq2Wu1xHdDTkD4AnOFUE0aWs/qJ/ximcYekQhBRtxfHlmOfjFVaHTB11Bk8P1 pegB5CUDiyo6NYGmww6sCGRNbigH+/j4u1D3+nvRl4zZ/AawZN1VjiFSqJz2GJYHmOG2 FGVg== X-Gm-Message-State: AHYfb5ixkA0c1l3qn/+tIuevn7qjhgpWe3xk0vkYp8qsBRmSY3U2Zan2 cXGzA1c2CjhzeFTN8lsDW+AUthD50f6U X-Received: by 10.31.62.8 with SMTP id l8mr1646279vka.185.1503969893617; Mon, 28 Aug 2017 18:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.25 with HTTP; Mon, 28 Aug 2017 18:24:53 -0700 (PDT) In-Reply-To: References: From: Satoru Matsushima Date: Tue, 29 Aug 2017 10:24:53 +0900 Message-ID: To: Kentaro Ebisawa Cc: dmm , spring@ietf.org, Matsushima Satoru Content-Type: multipart/alternative; boundary="001a1144776e4316c70557da47ee" Archived-At: Subject: Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 01:24:58 -0000 --001a1144776e4316c70557da47ee Content-Type: text/plain; charset="UTF-8" Hi Kentaro, On Mon, Aug 28, 2017 at 11:52 PM, Kentaro Ebisawa wrote: > Hi, > > I have a few questions about how Encoded SID should be placed in Segment > List and IPv6 Dst Address in Mobile User-Plane use case. > > # Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01. > # I tried to check Slides from IETF 99 but link seems to be missing. > # https://datatracker.ietf.org/doc/slides-99-dmm-srv6-for-mobi > le-user-plane/ That looks weird. It's not only for that document. All ietf99 meeting materials are mis-linked from " https://datatracker.ietf.org/meeting/99/agenda" page. > > Q1) Up Link packet (existing network to SRv6) > > > outer IPv4 and tunnel header. And then the endpoint does T.Insert > > process with the SID which consists of the allocated domain-wise SID > > prefix, source and destination addresses, and tunnel identifier as > > described in Figure 3. Then the endpoint send out the packet to the > > SRv6 network along with its routing policy. > In above text, we assumed that the payload encapsulated in the IPv4 tunnel is an IPv6 packet. So the source address of the packet should be an MN's address. > How would IPv6 src/dst addr and Segment List look like for this Up Link > packet? (existing network to SRv6) > My understanding is usually source address of the T.Insert node is not > included in Segment List. > But from above description, it looks like you intend to require Encoded > SID (Fig 3) to be included in the Segment List of UL packet. > > For example, is below packet structure what you intended in case you have > n segments to traverse in SRv6 nework? > > IPv6 Src: Encoded SID or T.Insert node ?? > IPv6 Dst: SL[n] > Segment Left = n > SL[0] = Segment 0 > SL[n] = Segment n > SL[n+1] = Encoded SID > > SL[0] must be original destination address of the IPv6 packet which the MN sends out. The SID which consists of the existing network tunnel info would be placed at SL[1]. In case of that it means that the endpoint which the SID indicates is egress of the SRv6 domain. If any other endpoints exist in the segment list, that SID would be placed at SL[n] where n >=2. > Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, and > > On the other hand, are there any reason that description in page 7 does > not mandate m to be zero while requiring to pop the SRH? > As similar with UL, SL[0] must be original destination address. In DL direction the interworking node must be egress of the SRv6 domain so that the tunnel info encoded SID should be placed in SL[1]. Best regards, --satoru > My understanding of DL packet (SRv6 to existing network) is as below. > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left = n > SL[m] = Encoded SID > SL[m+1] = Segment m+1 > SL[n] = Segment n > > > Regards, > -- > Ponto Networks, Inc. > Kentaro Ebisawa > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --001a1144776e4316c70557da47ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kentaro,


On Mon, Aug 28, 2017 at 11:52 PM, Kent= aro Ebisawa <ebiken.g@gmail.com> wrote:
Hi,

I have a few questions about how Encoded SID should be placed in Segment Li= st and IPv6 Dst Address in Mobile User-Plane use case.

# Refering to draft-matsushima-spring-dmm-srv6-mobile-uplane-01.
# I tried to check Slides from IETF 99 but link seems to be missing.
# https://datatracker.ietf= .org/doc/slides-99-dmm-srv6-for-mobile-user-plane/

That looks weird. It's not only for that document= .=C2=A0
All ietf99 meeting materials are mis-linked from "https://datatracke= r.ietf.org/meeting/99/agenda" page.

=C2= =A0

Q1) Up Link packet (existing network to SRv6)

> outer IPv4 and tunnel header. And then the endpoint does T.Insert
> process with the SID which consists of the allocated domain-wise SID > prefix, source and destination addresses, and tunnel identifier as
> described in Figure 3. Then the endpoint send out the packet to the > SRv6 network along with its routing policy.

<= /div>

In above text, we assumed that the payload encapsu= lated in the IPv4 tunnel is an IPv6 packet.
So the source address= of the packet should be an MN's address.


How would IPv6 src/dst addr and Segment List look like for this Up Link pac= ket? (existing network to SRv6)
My understanding is usually source address of the T.Insert node is not incl= uded in Segment List.
But from above description, it looks like you intend to require Encoded SID= (Fig 3) to be included in the Segment List of UL packet.

For example, is below packet structure what you intended in case you have n= segments to traverse in SRv6 nework?

IPv6 Src: Encoded SID or T.Insert node ??
IPv6 Dst: SL[n]
Segment Left =3D n
SL[0] =3D Segment 0
SL[n] =3D Segment n
SL[n+1] =3D Encoded SID


SL[0] must be original destination add= ress of the IPv6 packet which the MN sends out.
The SID which con= sists of the existing network tunnel info would be placed at SL[1]. In case= of that it means that the endpoint which the SID indicates is egress of th= e SRv6 domain. If any other endpoints exist in the segment list, that SID w= ould be placed at SL[n] where n >=3D2.



Q2) Down Link packet (SRv6 to existing network)

> When the endpoint receives packet and the active segment of the
> packet indicates the SID, the endpoint pop the SRH of the SID, and

On the other hand, are there any reason that description in page 7 does not= mandate m to be zero while requiring to pop the SRH?
=
As similar with UL, SL[0] must be original destination addre= ss. In DL direction the interworking node must be egress of the SRv6 domain= so that the tunnel info encoded SID should be placed in SL[1].
<= br>
Best regards,
--satoru

=C2= =A0
My understanding of DL packet (SRv6 to existing network) is as below.

IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left =3D n
SL[m] =3D Encoded SID
SL[m+1] =3D Segment m+1
SL[n] =3D Segment n


Regards,
--
Ponto Networks, Inc.
Kentaro Ebisawa <ebiken.g@gmail.com>

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

--001a1144776e4316c70557da47ee-- From nobody Mon Aug 28 18:44:28 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5BD1321AC; Mon, 28 Aug 2017 18:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6_fzWVIv0Vr; Mon, 28 Aug 2017 18:44:18 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E927126BF3; Mon, 28 Aug 2017 18:44:18 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id j7so6053243vke.0; Mon, 28 Aug 2017 18:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QPvl7t2PKxZC8sNgCCR9laPcvOZATm/OXUWAv35NRZU=; b=uCgk7lhh1FFj9GTulKDOzT4C7AY3UwEp7bdZzsHm+PbNDgUaqP0ayPwuzACT9YSltx PWLt04yI9FOJy89ZiHtq0NlNs3HaIwx+XQHM0rflwfcrU1NwhYICoVjgIhx+t/CDupk8 XJXl1M9aMDkaGzqgsR1Jf8IUZdEbRqI7lJHRFrEZuJiGK+uEflnJh/Qn13cr0uCUm6id C/+HRra3OwLaRxXSCxGMuiWZFMeY4Sh/6htxogd+RF9VBkmY9ho8lMEX4zBhckfnPbFm RtOSJEr98LwEIH1yp2QgaidGCL79r1Wjaf1i2bazSLTjUWtdQa2YZZ+3YgM4d7yW4jmx gGqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QPvl7t2PKxZC8sNgCCR9laPcvOZATm/OXUWAv35NRZU=; b=rhJyk1zcCFzM6xiYi+B+8TQkznNuTuB5HQ+InoF7+NnIohXMG4z89fRMDmtpUx/qm9 JDPhDCC6O6+ac1A8Qq9pus3U2ZD2YRi3ZmeedCp2hvUzF4iw+VqyFT7o0HA1gS5Y1IYJ Zl3c4EoBU2CnTbBYr+Gb+JHWG15mKb56eOvCfqFzdGoGW+yMd5UUyZ7KA2dopnJ0cfjL 8SrN1I2hBjqAZwQkDiM+j4eaGv3IdVIAdxJ6CQiaQ6kG2zjopn7iAuzdT5D7YlX+STHf Hg7W1VGdYjFCjV8tDGK/4FXoD+Bmvc5F9IpkLTGCAzmJUQ9WtvAltKHLvbP6bOy2FwwQ drcw== X-Gm-Message-State: AHYfb5h8dAECQGM07ZPR/REo5ZDz42QAVs8xVzSGDhZqWGH7/CeRaPJ0 6gD54oTy3hpxmWCBMWKTqeDK852K1Q== X-Received: by 10.31.108.215 with SMTP id j84mr1547083vki.7.1503971057549; Mon, 28 Aug 2017 18:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.25 with HTTP; Mon, 28 Aug 2017 18:44:16 -0700 (PDT) In-Reply-To: References: From: Satoru Matsushima Date: Tue, 29 Aug 2017 10:44:16 +0900 Message-ID: To: Kentaro Ebisawa Cc: dmm , spring@ietf.org, Matsushima Satoru Content-Type: multipart/alternative; boundary="001a1147a148a347c40557da8ce8" Archived-At: Subject: Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 01:44:20 -0000 --001a1147a148a347c40557da8ce8 Content-Type: text/plain; charset="UTF-8" Hi Kentaro, I've replied to your previous mail that I hope it would answer to your questions. On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa wrote: > Hi, > > > Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > > packet indicates the SID, the endpoint pop the SRH of the SID, and > > ... > > > > IPv6 Src: Origin Host > > IPv6 Dst: SL[n] > > Segment Left = n > > SL[m] = Encoded SID > > SL[m+1] = Segment m+1 > > SL[n] = Segment n > > Actually I think this differs for T.Insert case, where MN user packet is > IPv6. > # Unless I missed description that Stateless Interworking will always use > encapsulation mode even if user packet is IPv6. In DL, Stateless Interworking uses encapsulation for original IPv6 packet with IPv4 and tunnel header. > > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left = n > SL[0] = MN address > SL[1] = Encoded SID > SL[n] = Segment n > > As I mentioned in the previous mail, SL indicates SL[1] at the interworking node. > And interworking segment should behave like below. > > When the endpoint receives packet and the active segment of the > packet indicates the SID, the endpoint pop the SRH of the SID, > >> Set IPv6 destination address as SL[0] (MN's address), and > then the endpoint encaps the payload with the encoded information in > the SID which are tunnel identifier of tunnel header, source and > destination IPv4 address of IPv4 header described in Figure 3. > Right, it looks more precise description to it. Thanks! > > Maybe having example packet headers described for each cases > (encap/insert, User Packet = IPv4/IPv6) will help this makes more easier to > understand. > > Absolutely yes, it's helpful to understand. I'll update the I-D with that example in next revision. Thanks, --satoru --001a1147a148a347c40557da8ce8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kentaro,

I've replied to your pr= evious mail that I hope it would answer to your questions.

On Tue, Aug 29, 2017 at 12:= 44 AM, Kentaro Ebisawa <ebiken.g@gmail.com> wrote:
Hi,

> Q2) Down Link packet (SRv6 to existing network)
> > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, an= d
 > ...
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left =3D n
> SL[m] =3D Encoded SID
> SL[m+1] =3D Segment m+1
> SL[n] =3D Segment n

 Actually I think this differs for T.Insert case, where MN user packet is IP= v6.
# Unless I missed description that Stateless Interworking will always use e= ncapsulation mode even if user packet is IPv6.

<= div>In DL, Stateless Interworking uses encapsulation for original IPv6 pack= et with IPv4 and tunnel header.

=C2=A0


IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left =3D n
 SL[0] =3D MN address
SL[1] =3D Encoded SID
SL[n] =3D Segment n


As I mentioned in the previous = mail, SL indicates SL[1] at the interworking node.

=C2=A0
And interworking segment should behave like below.

When the endpoint receives packet and the active segment of the
packet indicates the SID, the endpoint pop the SRH of the SID,
 >> Set IPv6 destination address as SL[0] (MN's address), and
then the endpoint encaps the payload with the encoded information in
the SID which are tunnel identifier of tunnel header, source and
destination IPv4 address of IPv4 header described in Figure 3.


Right, it looks more precise descrip= tion to it. Thanks!

=C2=A0

Maybe having example packet headers described for each cases (encap/insert,= User Packet =3D IPv4/IPv6) will help this makes more easier to understand.=


Absolutely yes, it's helpful to un= derstand. I'll update the I-D with that example in next revision.
=

Thanks,
--satoru

--001a1147a148a347c40557da8ce8-- From nobody Tue Aug 29 06:00:12 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36091200F3; Tue, 29 Aug 2017 06:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9sSOEYurQrO; Tue, 29 Aug 2017 06:00:02 -0700 (PDT) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6595132055; Tue, 29 Aug 2017 06:00:02 -0700 (PDT) Received: by mail-yw0-x241.google.com with SMTP id h127so1994317ywf.1; Tue, 29 Aug 2017 06:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wRDPULtrscDbx9fQ+p3/B91VVrZOiWCUICRfQoeSJoY=; b=lGaZjMkWkADFql0R0/6qf93chL32ysyrTh85VIw8NsZqTObkhLeGWHK0b4NZbvh0zj HFBIzP44xmSnjK6GkmEtSTkNH4SNAPh52PuZ2asPkhU0ItRaJt0JcZcoLHRchHt5xaeb EbBiXEaGHYTEptqhayoO/AigGRUqDvYIhf+rZzUErwFJQvugWzGfdOWtxnekQ/+sMvv6 0/5WS+gUEUipUtC6lQHxzMaGnhi/471yhH0ME0e6pKm5entxcWkB/riwM2OGfD7C/Ukw wj+23zmFUaMOsTL5ptrSh9tg+FEfUF+PxyL8OL4Kx/gACEZrITERjTk559tb4CydD0kO PGUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wRDPULtrscDbx9fQ+p3/B91VVrZOiWCUICRfQoeSJoY=; b=sEVs8ZghwL8eUImqKWTSF6aWpcHB2voqBdcxgygjxX8iA2gN/qOxb8KFqUED5IJfdQ JCyeiriiBIOI5I6MA87I6Fxz7JCbrB9go2yx+aMqsZnuA7mgcsCxXtL4lIMqzOmOaQyG s62miTqMW/oBDQ22GolFB7REz2mOXqLqLIZaGWINGpmanIfL/tRR0/t83bbYLsFNsZLS cn5eFz6pnZ3veuVPf/PJu/KUnJTZtKWCwY6ISj1cCaU4bRvSuXwKmlcYhRUS5QH0XCZF 9OBeeW4xcMyUfa+T1bkFH3nJokyq+3gLGeB5uWjRwJtZMP3BrGnEJQ0qhNcpqJjsx3l2 37tA== X-Gm-Message-State: AHYfb5hXz9167DTpvDKP3gVY4N7mkiGR6kHAAuJQiANDxJ/Ob0jmW7YU oErn2vbkjV/dchTkHDq3oQ== X-Received: by 10.37.203.199 with SMTP id b190mr237711ybg.244.1504011601489; Tue, 29 Aug 2017 06:00:01 -0700 (PDT) Received: from [10.0.0.5] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id x5sm1072608ywl.51.2017.08.29.06.00.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 06:00:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <150343891797.6009.18151413294505237191@ietfa.amsl.com> Date: Tue, 29 Aug 2017 09:00:09 -0400 Cc: draft-ietf-dmm-mag-multihoming@ietf.org, dmm-chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <150343891797.6009.18151413294505237191@ietfa.amsl.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DMM] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-dmm-mag-multihoming belonging to Chemtron Research LLC X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:00:10 -0000 Hi all, I will wait another week (until end of day Sep 5 2017) to see if there = are any comments in the WG mailing list about this IPR declaration. If = there are no comments/issues raised, I will proceed with the document = processing once the two remaining DISCUSSes are addressed. =20 Thanks Suresh > On Aug 22, 2017, at 5:55 PM, IETF Secretariat = wrote: >=20 > Dear Pierrick Seite, Alper E. Yegin, Sri Gundavelli: >=20 >=20 > An IPR disclosure that pertains to your Internet-Draft entitled "MAG > Multipath Binding Option" (draft-ietf-dmm-mag-multihoming) was = submitted > to the IETF Secretariat on and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/3052/). The title of the IPR = disclosure is > "Eric Rescorla's Statement about IPR related to > draft-ietf-dmm-mag-multihoming belonging to Chemtron Research LLC" >=20 >=20 > Thank you >=20 > IETF Secretariat >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Aug 29 09:50:04 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D178132D6F; Tue, 29 Aug 2017 09:50:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-dmm-mag-multihoming@ietf.org, Jouni Korhonen , dmm-chairs@ietf.org, jouni.nospam@gmail.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150402540207.13183.12916271645603088686.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 09:50:02 -0700 Archived-At: Subject: [DMM] Kathleen Moriarty's No Objection on draft-ietf-dmm-mag-multihoming-04: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 16:50:02 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dmm-mag-multihoming-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. I have the same concern as the SecDir reviewer in reading the draft, the concern about leaking traffic as a result of multiple tunnels is not addressed in the security considerations section. Hilary's writeup is quite helpful https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html Although the editor says this is not an issue, but I don't think it's clear in the draft. From nobody Tue Aug 29 18:34:50 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F77126BF3; Tue, 29 Aug 2017 18:34:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150405688808.21503.12614853722503051226@ietfa.amsl.com> Date: Tue, 29 Aug 2017 18:34:48 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-deployment-models-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 01:34:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : DMM Deployment Models and Architectural Considerations Authors : Sri Gundavelli Seil Jeon Filename : draft-ietf-dmm-deployment-models-02.txt Pages : 15 Date : 2017-08-29 Abstract: This document identifies the deployment models for Distributed Mobility Management architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-deployment-models/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-deployment-models-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-deployment-models-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-deployment-models-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 30 05:35:37 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D423133159; Wed, 30 Aug 2017 05:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4klR9KP_z3L4; Wed, 30 Aug 2017 05:35:33 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49323133173; Wed, 30 Aug 2017 05:35:33 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id l87so9116981pfj.1; Wed, 30 Aug 2017 05:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:cc:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version; bh=ZgpdpUJXVI6vWu/MlYK4rj6y9Sjuth0dDtMG3MO+apY=; b=O1Cxny4W0yvDTkC3TB354oS5AbO3IB9WXTZukcUbHdUM9khyjlHaGvh5yQK3J933wo IaDT439KHWs31NneKUF9tTs94DG7MGej5Vg0UE/9sbPpSipUnT8Q1hLUCmqY59tneghR cJXECAu32bAfcn7TCAl75pWFYi2+HHTktOEPUBUQ3v+lYEVTal7FmGljRAiIlhfYVcql /EpoPlgDO2/ib8SiWIHoiHK8sGka6CUoOPEeEOMRemIyag8VvUnuqfaNZOIuJkzzAVC0 Z+8o86j91dJ+ekOvCd5VLbgXGxaiRTdi4J2IP6Q7zatHHciq85HWHakWM9dFnGIP/haV +3og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version; bh=ZgpdpUJXVI6vWu/MlYK4rj6y9Sjuth0dDtMG3MO+apY=; b=dUfYcFLZ6Wrgpkbof1YLp5xzb4wX+zY4UKmfLb8UCARNuH9WanxR73jmMO681hadF6 /ji/RNz7NmphX+zEKJ7wLrIwP7qlu/4hU10u2qtnU5yzwOgog6Xgcg48H0B2lFowOZTx rJpvl9F2gb/cwANLGqw690Lh/Hp+35VL3Tnp+qDJk6n0SvRA4PUEf7LqTZxx4v7eZAgi ujVEvo4bEoeLTWXuHE/7JZDqeny3OJoJLCGJzeFihbIRVrQy91a3PO0eneXdZqnKsAlp rt0fBq/suDfUQMY6vFu09Mv6E4ODUrs2kZbxyj8EurrIJPIiE96ToGQRfJzCaFtecAtN jKJQ== X-Gm-Message-State: AHYfb5jmk9QmRqJwg+sqhhdFaKNkzThv6V+DnExDc5QbgV8U+MX+gcbr P3Pra7Lzu9o4Nw== X-Received: by 10.101.85.193 with SMTP id k1mr1419718pgs.88.1504096532606; Wed, 30 Aug 2017 05:35:32 -0700 (PDT) Received: from [192.168.10.7] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id q13sm9740815pfk.6.2017.08.30.05.35.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 05:35:31 -0700 (PDT) From: "Kentaro Ebisawa" To: "Satoru Matsushima" Cc: dmm , spring@ietf.org Date: Wed, 30 Aug 2017 12:35:30 +0000 Message-Id: In-Reply-To: References: Reply-To: "Kentaro Ebisawa" User-Agent: eM_Client/7.1.30646.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329" Archived-At: Subject: Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile-uplane) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 12:35:35 -0000 --------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Satoru, Thank you for the email replies and taking time for offline discussion. Your explanation in the emails clarified my questions, and leaving a few=20 notes below to share clarification made during the offline chat for=20 others on the list. * In the draft, SRv6-mobile-uplane, IPv4 client packets will use Encap=20 and IPv6 packets will use Insert while traversing SRv6 network. * For UL, Encoded SID will be SL[1] * Exist side of SRv6 and not on the interworking node in DL. * SL[0] is an end host on external network who MN is communicating=20 with. * "Locater of interwork" differes for UL and DL. (as mentioned in the=20 draft) Regards, -- Kentaro Ebisawa ------ Original Message ------ From: "Satoru Matsushima" To: "Kentaro Ebisawa" Cc: "dmm" ; spring@ietf.org; "Matsushima Satoru"=20 Sent: 2017/08/29 10:44:16 Subject: Re: [DMM] How Encoded SID should be placed in SL=20 (SRv6-mobile-uplane) >Hi Kentaro, > >I've replied to your previous mail that I hope it would answer to your=20 >questions. > >On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa =20 >wrote: >>Hi, >> >> > Q2) Down Link packet (SRv6 to existing network) >> > > When the endpoint receives packet and the active segment of the >> > > packet indicates the SID, the endpoint pop the SRH of the SID, and >> > ... >> > >> > IPv6 Src: Origin Host >> > IPv6 Dst: SL[n] >> > Segment Left =3D n >> > SL[m] =3D Encoded SID >> > SL[m+1] =3D Segment m+1 >> > SL[n] =3D Segment n >> >>Actually I think this differs for T.Insert case, where MN user packet=20 >>is IPv6. >># Unless I missed description that Stateless Interworking will always=20 >>use encapsulation mode even if user packet is IPv6. > >In DL, Stateless Interworking uses encapsulation for original IPv6=20 >packet with IPv4 and tunnel header. > > >> >> >>IPv6 Src: Origin Host >>IPv6 Dst: SL[n] >>Segment Left =3D n >>SL[0] =3D MN address >>SL[1] =3D Encoded SID >>SL[n] =3D Segment n >> > >As I mentioned in the previous mail, SL indicates SL[1] at the=20 >interworking node. > > >>And interworking segment should behave like below. >> >>When the endpoint receives packet and the active segment of the >>packet indicates the SID, the endpoint pop the SRH of the SID, >> >> Set IPv6 destination address as SL[0] (MN's address), and >>then the endpoint encaps the payload with the encoded information in >>the SID which are tunnel identifier of tunnel header, source and >>destination IPv4 address of IPv4 header described in Figure 3. > > >Right, it looks more precise description to it. Thanks! > > >> >>Maybe having example packet headers described for each cases=20 >>(encap/insert, User Packet =3D IPv4/IPv6) will help this makes more=20 >>easier to understand. >> > >Absolutely yes, it's helpful to understand. I'll update the I-D with=20 >that example in next revision. > >Thanks, >--satoru > --------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Satoru,

Thank = you for the email replies and taking time for offline discussion.

Your explanation in the emails clarified my questions, a= nd leaving a few notes below to share clarification made during the offline = chat for others on the list.

* In the draft, SRv6-mobile-uplane, IPv4 client packets will use En= cap and IPv6 packets will use Insert while traversing SRv6 network.
* For UL, Encoded SID will be SL[1]
=C2=A0 =C2=A0 * Exist side of SRv6 and not on=C2= =A0the interworking node in DL.
=C2=A0 = =C2=A0 * SL[0] is an end host on external network who MN is communicating= with.
* "Locater of interwork" differes = for UL and DL. (as mentioned in the draft)

Regards,
--=C2=A0<= /div>
Kentaro Eb= isawa <ebiken.g@gmail.com><= /div>

------ Original Message ------
From: "Satoru Matsushima" <satoru.matsushima@gmail.com>
To: "Kentaro Ebisawa" <ebiken= .g@gmail.com>
Cc: "dmm" <dmm@ietf.org>; spring@ietf.org; "Matsushima Satoru" &= lt;satoru.matsushima@= g.softbank.co.jp>
Sent: 2017/08/29 10:44:16
Subject: Re: [DMM] How Encoded SID should be placed in SL (SRv6-mobile= -uplane)

Hi Kentaro,

I've replied to your prev= ious mail that I hope it would answer to your questions.

On Tue, Aug 29, 2017 at 12:4= 4 AM, Kentaro Ebisawa <ebiken.g@gmail.com> wrote:
Hi,

> Q2) Down Link packet (SRv6 to existing network)
> > When the endpoint receives packet and the active segment of the > > packet indicates the SID, the endpoint pop the SRH of the SID, an= d
 > ...
>
> IPv6 Src: Origin Host
> IPv6 Dst: SL[n]
> Segment Left =3D n
> SL[m] =3D Encoded SID
> SL[m+1] =3D Segment m+1
> SL[n] =3D Segment n

 Actually I think this differs for T.Insert case, where MN user packet is IP= v6.
# Unless I missed description that Stateless Interworking will always use e= ncapsulation mode even if user packet is IPv6.

In DL, Stateless Interworking uses encapsulation for original IPv6 pa= cket with IPv4 and tunnel header.

=C2=A0


IPv6 Src: Origin Host
IPv6 Dst: SL[n]
Segment Left =3D n
 SL[0] =3D MN address
SL[1] =3D Encoded SID
SL[n] =3D Segment n


As I mentioned in the previ= ous mail, SL indicates SL[1] at the interworking node.

=C2=A0
And interworking segment should behave like below.

When the endpoint receives packet and the active segment of the
packet indicates the SID, the endpoint pop the SRH of the SID,
 >> Set IPv6 destination address as SL[0] (MN's address), and
then the endpoint encaps the payload with the encoded information in
the SID which are tunnel identifier of tunnel header, source and
destination IPv4 address of IPv4 header described in Figure 3.


Right, it looks more precise d= escription to it. Thanks!

=C2=A0

Maybe having example packet headers described for each cases (encap/insert, = User Packet =3D IPv4/IPv6) will help this makes more easier to understand.=


Absolutely yes, it's helpful to un= derstand. I'll update the I-D with that example in next revision.

Thanks,
--satoru

--------=_MBA09855CA-4991-44C4-826A-9BFF6C70E329-- From nobody Wed Aug 30 12:55:40 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF86126B7E; Wed, 30 Aug 2017 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 Ijnzpa_uHtEO; Wed, 30 Aug 2017 12:55:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB47132027; Wed, 30 Aug 2017 12:55:30 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7UJtNTf068987 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Aug 2017 14:55:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <148721684794.31572.814060328381329269.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 14:55:22 -0500 Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9790D9AB-A943-420B-923D-5EF87F4A4D4C@nostrum.com> References: <148721684794.31572.814060328381329269.idtracker@ietfa.amsl.com> To: The IESG , Suresh Krishnan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DMM] Ben Campbell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:55:33 -0000 I apologize for taking a while to circle back on this=E2=80=94I missed = the fact that there was an update. Version 5 changes the assertion that =E2=80=9Csome of these = identifiers=E2=80=9D may be considered private information to simply = saying mobile identifiers are private information, and changes the = lower-case =E2=80=9Cshould" encrypt to a MUST. That resolves my DISCUSS = point. I will clear. Thanks! Ben. > On Feb 15, 2017, at 9:47 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-dmm-4283mnids-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > The security considerations says some of these identifiers can carry > sensitive information, and when they do you should encrypt. This = leaves > it to the reader to decide which might be sensitive. The draft should > tell the reader which ones the working group thinks are sensitive, > keeping in mind that if an identifier is sometimes sensitive, it = usually > needs to be treated as if always sensitive. (It's hard for deployed = code > to figure out when it is or isn't sensitive.) >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I agree with Stephen's, Alissa's, and Mirja's discusses. I especially > agree that we should not standardize new identifiers without = justifying > each one. >=20 > Section 5 says this document does not impact existing security > mechanisms. But it does add new data elements, and acknowledges some = of > them may be sensitive. Thus I think the "does not impact" assertion = needs > some supporting discussion. Are the existing mechanisms still = adequate? > Why? >=20 > There are a bunch of acronyms that would benefit from expansion on = first > mention. >=20 >=20 From nobody Wed Aug 30 12:58:16 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A3132955; Wed, 30 Aug 2017 12:58:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dmm-4283mnids@ietf.org, Dapeng Liu , dmm-chairs@ietf.org, max.ldp@alibaba-inc.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412309441.21603.8655211765003021771.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 12:58:14 -0700 Archived-At: Subject: [DMM] Ben Campbell's No Objection on draft-ietf-dmm-4283mnids-05: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:58:14 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmm-4283mnids-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for resolving my DISCUSS point. From nobody Wed Aug 30 13:17:33 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0851321C7; Wed, 30 Aug 2017 13:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LtOeu-M9q1uQ; Wed, 30 Aug 2017 13:17:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35F41329E3; Wed, 30 Aug 2017 13:17:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A6C4AB80FFA; Wed, 30 Aug 2017 13:16:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dmm@ietf.org Message-Id: <20170830201650.A6C4AB80FFA@rfc-editor.org> Date: Wed, 30 Aug 2017 13:16:50 -0700 (PDT) Archived-At: Subject: [DMM] RFC 8127 on Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:17:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8127 Title: Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor Author: D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz Status: Standards Track Stream: IETF Date: August 2017 Mailbox: dhpatki@cisco.com, sgundave@cisco.com, jonghyouk@smu.ac.kr, fuqiao1@outlook.com, lyle.t.bertz@sprint.com Pages: 14 Characters: 25152 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dmm-lma-controlled-mag-params-05.txt URL: https://www.rfc-editor.org/info/rfc8127 DOI: 10.17487/RFC8127 This specification defines a new extension, LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters. This document is a product of the Distributed Mobility Management Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Aug 30 13:58:02 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02927132A80; Wed, 30 Aug 2017 13:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pulRBojtTjD8; Wed, 30 Aug 2017 13:57:53 -0700 (PDT) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45962132A89; Wed, 30 Aug 2017 13:57:52 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id s187so4833695ywf.2; Wed, 30 Aug 2017 13:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h72BIGPEjZAdBpKTktBLYOXOF8Dzznh4ePlvWRNkNOM=; b=Ll7aOp/dsVrsMoeSSUiuERqzQPQMR/GNm7Ax/WFYB4UOaKirte6mwE25JPyW7vSF+Y Q4cizAsBGNd3Qvw53Atjbd6fZEdWXk1+Tqc6cXDTJ7cK7RdyNyQUunUkVHtWltxckHiq 0SLWgavLZLIazBOR+y4UlOBw8JgR/vLef1YSkbXzT2tHXh2qTETllQ5fR844RqqVIIcg QBRXkPLOgZIK76GRsegcDy9EWYUphZSRWS1GMb8YO/8Gy6XkwEF/ZVkcsMIl3cQhJuyR 0TMAOyz4vOEU5gG+rsmuUeM3E+QeWZL9H07Ej5AAE+smKSEljxWq9jcQ+WhAt3FvHjPz /HfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h72BIGPEjZAdBpKTktBLYOXOF8Dzznh4ePlvWRNkNOM=; b=b7Kd/toe9iy3jABYWcenVbexy2p8aYZZ+VPq8pDp6JeYJBPIkrVyvMysE2kPLEpDbr XXcd+z/G1wjNqyx8LN6dDbVVvUw6SjdFc3xY2VPlaZTiPB/qYwUGq3Jy88m5bLK7qNRy engEBUea6V9XkuSwSoNNfJNvRB3tjrJZW0UNfVJzJYXxOzK++RktOOAx5HQIp+NmfxzB nlmidJcM+C9E0JG21Pzjz6NPV539KJmrQzhFB/UpN8bIQ0xg8ICb0trsicUL2Fvva2GN l8C843QSK0PiSxmvS5C8sPtF6ORgZI16DzJqsDNAex4+GKM+JFtBR/+N5wsxVlJC3063 iSQQ== X-Gm-Message-State: AHYfb5ikXVBNbhhyVqw9A37UIOJX0o8gG1Og58BOIZ3obLPirf5/vLL4 6ODgfH7cg9Yx/z92ynYS1Q== X-Received: by 10.37.178.155 with SMTP id k27mr2321013ybj.218.1504126671440; Wed, 30 Aug 2017 13:57:51 -0700 (PDT) Received: from [10.0.0.5] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id o17sm2347764ywd.37.2017.08.30.13.57.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 13:57:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <9790D9AB-A943-420B-923D-5EF87F4A4D4C@nostrum.com> Date: Wed, 30 Aug 2017 16:57:49 -0400 Cc: The IESG , "max.ldp" , draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <148721684794.31572.814060328381329269.idtracker@ietfa.amsl.com> <9790D9AB-A943-420B-923D-5EF87F4A4D4C@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DMM] Ben Campbell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:57:55 -0000 > On Aug 30, 2017, at 3:55 PM, Ben Campbell wrote: >=20 > I apologize for taking a while to circle back on this=E2=80=94I missed = the fact that there was an update. >=20 > Version 5 changes the assertion that =E2=80=9Csome of these = identifiers=E2=80=9D may be considered private information to simply = saying mobile identifiers are private information, and changes the = lower-case =E2=80=9Cshould" encrypt to a MUST. That resolves my DISCUSS = point. I will clear. Thanks a lot Ben for checking and clearing. Regards Suresh