From JuanCarlos.Zuniga@InterDigital.com Wed Mar 6 08:14:13 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9963B21F8A1D for ; Wed, 6 Mar 2013 08:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIWkzjA+wnMj for ; Wed, 6 Mar 2013 08:14:13 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id EBEAA21F8A05 for ; Wed, 6 Mar 2013 08:14:12 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Mar 2013 11:14:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 6 Mar 2013 11:14:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-seite-mif-cm-01.txt Thread-Index: Ac4RCh+hqF6+PwNXTc6OggH3YkxhPgJehvIw From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 06 Mar 2013 16:14:09.0617 (UTC) FILETIME=[A24BC410:01CE1A85] Subject: [mif] FW: New Version Notification for draft-seite-mif-cm-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:14:13 -0000 SGkgYWxsLA0KDQpBZnRlciBvdXIgcHJlc2VudGF0aW9uIG9uIHRoZSBDb25uZWN0aW9uIE1hbmFn ZW1lbnQgZHJhZnQgYXQgSUVURjg1IGluIEF0bGFudGEsIHdlIGdvdCBhbiBhY3Rpb24gaXRlbSB0 byB1cGRhdGUgb3VyIGRyYWZ0IHRvIGFsaWduIHRoZSBhcmNoaXRlY3R1cmUgd2l0aCB0aGUgTUlG IEFQSSBvbmUsIHRvIGhpZ2hsaWdodCB0aGUgY29ubmVjdGlvbiBtYW5hZ2VtZW50IHByb2JsZW1z LCBhbmQgdG8gc3VibWl0IHRoZSA4MDIuMjEgYW5uZXggYXMgYSBzZXBhcmF0ZSBkb2N1bWVudC4N Cg0KV2UgaGF2ZSB1cGRhdGVkIG91ciBkcmFmdCBhY2NvcmRpbmdseSBhbmQgaGF2ZSBhbHNvIHN1 Ym1pdHRlZCBhIG5ldyBpbmZvcm1hdGlvbmFsIGRyYWZ0IGFzIHJlcXVlc3RlZDoNCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VpdGUtbWlmLWNtLTAxIA0KDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16dW5pZ2EtbWlmLTgwMi0yMS1vdmVydmlldy0wMCANCg0K Q29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkp1YW4tQ2FybG9zICYgUGllcnJpY2sNCg0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDIyLCAyMDEzIDk6MzcgQU0NCj4gVG86IHBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20N Cj4gQ2M6IFp1bmlnYSwgSnVhbiBDYXJsb3MNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1zZWl0ZS1taWYtY20tMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXNlaXRlLW1pZi1jbS0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBQaWVycmljayBTZWl0ZSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJ RVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LXNlaXRlLW1pZi1jbQ0KPiBS ZXZpc2lvbjoJIDAxDQo+IFRpdGxlOgkJIE1JRiBBUEkgZm9yIENvbm5lY3Rpb24gTWFuYWdlbWVu dA0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0xOQ0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxNw0KPiBVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlaXRlLW1pZi1jbS0wMS50eHQN Cj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXNlaXRlLW1pZi1jbQ0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNlaXRlLW1pZi1jbS0wMQ0KPiBEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNlaXRlLW1pZi1jbS0wMQ0KPiANCj4gQWJzdHJh Y3Q6DQo+ICAgIFRoZXJlIGlzIGN1cnJlbnRseSBhIG5lZWQgdG8gcHJlc2VudCBhIGNvaGVyZW50 IGNvbm5lY3Rpb24NCj4gbWFuYWdlbWVudA0KPiAgICBiZWhhdmlvdXIgZm9yIGRpZmZlcmVudCB0 ZXJtaW5hbCBwbGF0Zm9ybXMgKGUuZy4gbW9iaWxlIHBob25lcywgUENzLA0KPiAgICB0YWJsZXRz LCBldGMuKS4gIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGhvdyBhIGNvbm5lY3Rpb24gbWFuYWdl cg0KPiBjYW4NCj4gICAgdXNlIHRoZSBNSUYgQVBJIHRvIHByb3ZpZGUgdGhpcyBjb2hlcmVudCBi ZWhhdmlvdXIgYW5kIGVuaGFuY2UgdGhlDQo+ICAgIGVuZCB1c2VyJ3MgZXhwZXJpZW5jZSB3aGVu IGEgdGVybWluYWwgaXMgYWJsZSB0byBjb25uZWN0IHRvIG11bHRpcGxlDQo+ICAgIGludGVyZmFj ZXMuICBUaGUgZ29hbCBvZiB0aGlzIGRvY3VtZW50IGlzIG5vdCB0byBkZWZpbmUgYSBjb25uZWN0 aW9uDQo+ICAgIG1hbmFnZXIgc3BlY2lmaWNhdGlvbiwgYnV0IHRvIGZvY3VzIG9uIHRoZSBpbnRl cmFjdGlvbiB3aXRoIHRoZSBNSUYNCj4gICAgQVBJIGFuZCBzdWdnZXN0IHJlbGV2YW50IGdlbmVy aWMgbWVzc2FnZXMgZm9yIHRoZSBpbnRlcmZhY2UuDQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IGlz IGZvciBkaXNjdXNzaW9uIGFuZCBpdHMgaW50ZW50aW9uIGlzIHRvIGhlbHANCj4gICAgY2xhcmlm eWluZyB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIE1JRiBBUEkgaW4gYSBjb25uZWN0aW9uIG1hbmFn ZW1lbnQNCj4gICAgY29udGV4dCBhbmQgcHJvcG9zZSBzb21lIHJlbGV2YW50IGNvbnNpZGVyYXRp b25zLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From denghui@chinamobile.com Sun Mar 10 06:55:21 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1721F85D6 for ; Sun, 10 Mar 2013 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60T92jrFukJR for ; Sun, 10 Mar 2013 06:55:21 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 8881C21F8425 for ; Sun, 10 Mar 2013 06:55:20 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2513c90ad97e-a297e; Sun, 10 Mar 2013 21:54:53 +0800 (CST) X-RM-TRANSID: 2ee2513c90ad97e-a297e Received: from cmccPC (unknown[172.16.20.82]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3513c90a8fe7-feebe; Sun, 10 Mar 2013 21:54:53 +0800 (CST) X-RM-TRANSID: 2ee3513c90a8fe7-feebe From: "Hui Deng" To: "'Michael Richardson'" , References: <0f2e01ce0556$6698cf60$33ca6e20$@cisco.com> <5113E9EF.5090400@network-heretics.com> <20067.1360331334@sandelman.ca> In-Reply-To: <20067.1360331334@sandelman.ca> Date: Sun, 10 Mar 2013 09:55:07 -0400 Message-ID: <000301ce1d96$e1fa72f0$a5ef58d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4GAyoFmQA8qOQEQLGI2eXh6WhFjgXkzMew Content-Language: zh-cn Cc: 'Keith Moore' Subject: Re: [mif] declaring interface 'up', with WiFi DNS/HTTP interception (login) proxies [was RE: DNS selection with HE-MIF] X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 13:55:21 -0000 =3D=3D> One clarification for below, are you talking about how to = migrate from HTTP portal to EAP authencation for wifi? =20 It would be nice if we also had a BCP on how to signal and upgrade From = HTTP login to some DHCP EAP, perhaps using a EAP-TLS resume From the = HTTP session state. This would permit captive portals to recognize = re-logins. =3D=3D> For today EAP wifi deployment, user (without connection manager) = will click and connect with EAP/SIM/AKA/TLS/TTLS/PEAP server = automatically,=20 And user (with connection manager) will automatically connect with = network once interface is up, this interface up doesn't need to do = detecting the network connection, if OS will do that whatever, it will = still say not success. -Hui From ek@google.com Fri Mar 15 07:06:34 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEE421F866F for ; Fri, 15 Mar 2013 07:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkkekJSW9QOQ for ; Fri, 15 Mar 2013 07:06:33 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2510F21F8667 for ; Fri, 15 Mar 2013 07:06:33 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l20so3417387oag.37 for ; Fri, 15 Mar 2013 07:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type; bh=Ugd/5i2E6rCwnACYTPdwSMHGrUs535J0EDs+Gbqm25A=; b=PQodp9m9dkIViKh8mV3aW8kOph0PWaN4kvh2c/f9DS5Rsz/dWF5vhqTV2g9LQ1eP4S 2IQtyXSIQqMbKDEEv5Zj7smUp+qyUiQFg4tN24Dvw8K3plTCzYcvPGw4UwtI4Kwx6r16 9P+aVkk0iimv42VMveBfeAY/779gK3hyaIDIQuvlIaakW5skMDth9iiQ2jveH9hbCKgq XD0lExjWr2sb+vxw88xGajrX0SJPtd7hoqvU+xcK9Nh+Dp0i0kZ5DfviDXJfJmgZcCeJ ideshoDjJ6WYziPhz0VwZ/cpU70+6tNW7se3SqYiKwo5dInKEUdkZ0Vg1tSofrMvCSy3 e0vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=Ugd/5i2E6rCwnACYTPdwSMHGrUs535J0EDs+Gbqm25A=; b=al0WHDt37kSrYrlH/0WffT6OIiVTWC7fsAEqpTEV4VgpO2NnvJ/vG7UdcXjr7H2/Hn 3IAjG2QJ4pxAzW0RVRA+KjtRhiWxzzXja54W6cGM0RDrln0ZWa+bnr0kAOmkTUUwpbXN m845yx691iKeNJOOIUfN9hxuzwVV7JUtp92hfS13qkrjpJkHtFl7cB7QsVCAGo10Unsa dv9+KdOb71bCr51Oo4Ax87PNdgo5OryoI9Y+lhcDEbTS++0lbk+XvwgH+KnEJFgf6wos qs682m8zd864buMtmsvYD42Ix/vpUfK2ZDJ3EX0tUe4LT3xz5mM4yfz9hCFPO/lvTnBG SywQ== X-Received: by 10.60.30.6 with SMTP id o6mr2989603oeh.128.1363356392708; Fri, 15 Mar 2013 07:06:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.50.227 with HTTP; Fri, 15 Mar 2013 07:06:12 -0700 (PDT) From: Erik Kline Date: Fri, 15 Mar 2013 10:06:12 -0400 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8fb2054a7d741804d7f72507 X-Gm-Message-State: ALoCoQmAvGZrAXSdHdHRe8PdqNEvQPi+AOp+iiK87ER7sIvy2QZ4oVP34rKRHZ6PCRERQ6k47tx2eerBSTZIuEuXK7VxU19GvCVo2VwS/bgWM6f7+Jl0l310OSYu6tEnuyWH9nTNQyx9pp2Lc7RnWStExVAk1XPozXNBNLG5Cqpp6uyXscu94UIJdaJ7KynSunyJyNG2N6E1 Cc: "mif@ietf.org" Subject: [mif] Network Access Identifier X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:06:34 -0000 --e89a8fb2054a7d741804d7f72507 Content-Type: text/plain; charset=UTF-8 Ted, Pursuant to our in-person conversation about APNs as one example of string identifiers used as a kind of provisioning profile identifier, I followed some 3gpp docs until I got to RFC 4282: http://www.3gpp.org/ftp/Specs/html-info/23003.htm http://www.etsi.org/deliver/etsi_ts/123000_123099/123003/11.04.00_60/ts_123003v110400p.pdf http://tools.ietf.org/html/rfc4282 I know it's *way* too early to discuss provisioning domain/profile string identifiers, and that the stated purpose ( http://tools.ietf.org/html/rfc4282#section-1.3) is not necessarily the same. Nevertheless, I hadn't run across this before and I found it interesting that something that /may/ be used as a model is out there (complete with international character set, DNS, and email address compatibility discussion). -ek --e89a8fb2054a7d741804d7f72507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

Pursuant to our in-person co= nversation about APNs as one example of string identifiers used as a kind o= f provisioning profile identifier, I followed some 3gpp docs until I got to= RFC 4282:


I know it's *way* too early to discuss provisioning domain/profile s= tring identifiers, and that the stated purpose (http://tools.ietf.org/html/rfc4282#section-= 1.3) is not necessarily the same.

Nevertheless, I hadn't run across this = before and I found it interesting that something that /may/ be used as a mo= del is out there (complete with international character set, DNS, and email= address compatibility discussion).

-ek
--e89a8fb2054a7d741804d7f72507-- From alexandru.petrescu@gmail.com Fri Mar 15 13:34:51 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FFB21F862B for ; Fri, 15 Mar 2013 13:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.097 X-Spam-Level: X-Spam-Status: No, score=-10.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbFHjRKCaNfs for ; Fri, 15 Mar 2013 13:34:50 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4964E21F85C0 for ; Fri, 15 Mar 2013 13:34:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2FKYm8U004781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Mar 2013 21:34:48 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2FKYmHa019758 for ; Fri, 15 Mar 2013 21:34:48 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2FKYRdU028981 for ; Fri, 15 Mar 2013 21:34:42 +0100 Message-ID: <514385AE.5050108@gmail.com> Date: Fri, 15 Mar 2013 21:33:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] clarifications about route-option activities X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 20:34:52 -0000 Yes, route-option expired and maybe not to discuss about it here, I agree. Independent of that. I just want to clarify a few things. I talked to opponents about this, and strong disagreement is still there. But, There was a request to write usecases and scenarios in the route-option draft. I said at the last meeting I would do. I did, but not in the route-option draft, but in my personal proposal draft-mouton; I dont know how to update the WG item, not being an author. It's not that I dont want to do it, I just dont know where to do it. A possible thing I could do further is to separate the idea of route option from default route option. What do you think? I believe most opposition is against default route option, not necessarily route option. What do you think? Also, I need to identify whether Vendor options, or INFORMATIONAL or EXPERIMENTAL status can be used effectively to advance this work. What do you think? Also, the metric comment from Ivo must be taken into account. Alex From Ted.Lemon@nominum.com Fri Mar 15 14:08:02 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA65021F8689 for ; Fri, 15 Mar 2013 14:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BTSurtks9bw for ; Fri, 15 Mar 2013 14:08:02 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 202D621F865D for ; Fri, 15 Mar 2013 14:08:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUUONsX83ImUyBztNRm/k166CQmbHIQvC@postini.com; Fri, 15 Mar 2013 14:08:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B4E761B8FF6 for ; Fri, 15 Mar 2013 14:08:01 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AAF70190043; Fri, 15 Mar 2013 14:08:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 14:07:55 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] clarifications about route-option activities Thread-Index: AQHOIbyNXPzEu3+lpEmXIc/jiA34OJintDeA Date: Fri, 15 Mar 2013 21:07:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474C749E@mbx-01.win.nominum.com> References: <514385AE.5050108@gmail.com> In-Reply-To: <514385AE.5050108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] clarifications about route-option activities X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 21:08:02 -0000 Alexandru, I'm going to reply to you off-list because I really don't want t= o see this discussion continue on MIF. If there is interest from others o= n the list in discussing this, I am going to propose that we set up a non-w= g list to discuss it; otherwise all the nice people who signed up to do MIF= architecture work will be driven off by the discussion about the route opt= ion. (If others are interested, I would like to mention that I am going to give = Alexandru some constructive feedback, not give him a hard time=97I fully un= derstand the frustration that dropping this work has created, and as AD I'm= not a bad person to talk to about that.) From denghui02@gmail.com Sat Mar 16 10:53:09 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827521F886B for ; Sat, 16 Mar 2013 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7nKhj+-Qlkj for ; Sat, 16 Mar 2013 10:53:08 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A337E21F8839 for ; Sat, 16 Mar 2013 10:53:08 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so2105462qca.31 for ; Sat, 16 Mar 2013 10:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=++0pIHKKg++4H7l95e24B5pBbIbnNQfuGUgTHwpZ5kI=; b=LmDrbOJB3AfGqxMu9OiuQcMUD4V926+eiEqngxF4/sWHMEdglcmwEmpbH9LYsSZdSU hwADZkpDSw74cENSC+udcpRFKRqpGh2q9boTGHtZvwDTgWIw6AXN9Dhmk2WUP65c1eR6 JDQxIPwrg2wl0O0dhuHtby/IrF9ezice27cpMicZ2oijCvEecgU7WrXT3JwGDTfH+n0i giaUy76DveCflbttHmlL/kwoL5JPncg/iiEtwth6Ut+C62ljqShzqezHHuKZaxeyvFjn ft789hyHTEFrA+TL380gg1f0Gh23xJ5BiLtL0CnxN0lNcod5USGg1dgT+LNR9V/YINDp FAGw== MIME-Version: 1.0 X-Received: by 10.49.24.45 with SMTP id r13mr13561075qef.3.1363456387823; Sat, 16 Mar 2013 10:53:07 -0700 (PDT) Received: by 10.49.95.133 with HTTP; Sat, 16 Mar 2013 10:53:07 -0700 (PDT) Date: Sat, 16 Mar 2013 10:53:07 -0700 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=047d7b33cb40a9cc5504d80e6d48 Subject: [mif] MIF minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 17:53:09 -0000 --047d7b33cb40a9cc5504d80e6d48 Content-Type: text/plain; charset=ISO-8859-1 Hello all. Thanks John Kaippallimalil and Ding Yi for taking minutes, Thanks Behcet Sarikaya in jabber. Feel free to let chair know if there is any reivision needed. http://www.ietf.org/proceedings/86/minutes/minutes-86-mif Best regards, -Hui --047d7b33cb40a9cc5504d80e6d48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all.
=A0
Thanks John Kaippallimalil and Ding= Yi for taking minutes,
Thanks Behcet Sarikaya in jabber.
=A0
Feel free to let chair know if there is any reivision need= ed.
=A0=
Best regards,
=A0
-Hui
--047d7b33cb40a9cc5504d80e6d48-- From denghui02@gmail.com Sat Mar 16 11:58:15 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F321F8689 for ; Sat, 16 Mar 2013 11:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2klLLd+aBvZu for ; Sat, 16 Mar 2013 11:58:14 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C275E21F8630 for ; Sat, 16 Mar 2013 11:58:14 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id v28so2074698qcm.25 for ; Sat, 16 Mar 2013 11:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=o+viKFG3jCbmTTwj9jt2K5RCDUg5scP49jNW+oFFJLY=; b=pH0PKwcg7CjRpd/5V0jIPStQLpb2dEsJsVTPALyojtgwNAo1F05S/Tvq4fJWagIcKF jgKZyUlDI36Nox2nCImVpmim52w8bHGTEJYLTE+NeDDJOhCl/ReZdV/dCjn0WoirJtJU +vZpfDZXGIff26U7tJC681LpmOi/X9i+PZpchS/TTKONIQQrDz95BsT1rsnWnO5vdAhj lggj5SHNjIoebKm14tZjAb0vcAy5uAag1M5DQPmg2yxXo6jmmhPbN/SA3LYfkKDZzG1T cMDOLpvZjBFZ2LTi+esHi68kGBc8TAPgTOuyj+UhZwZ8Xl9Rjytx4VdbYe3WzfxEkGLN rcjA== MIME-Version: 1.0 X-Received: by 10.224.168.144 with SMTP id u16mr12338400qay.18.1363460294296; Sat, 16 Mar 2013 11:58:14 -0700 (PDT) Received: by 10.49.95.133 with HTTP; Sat, 16 Mar 2013 11:58:14 -0700 (PDT) Date: Sat, 16 Mar 2013 11:58:14 -0700 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman , Ted Lemon Content-Type: multipart/alternative; boundary=20cf3074d86681cbeb04d80f564b Subject: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 18:58:15 -0000 --20cf3074d86681cbeb04d80f564b Content-Type: text/plain; charset=ISO-8859-1 Hello all Based on yesterday discussion, cochairs would like to call for volunteers who would like to work on architecture related design work, please kindly help to send emails to co-chairs. Thanks -Hui --20cf3074d86681cbeb04d80f564b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Based on yesterday discussion, cocha= irs would like to call for volunteers who would like to work on architectur= e related design work, please kindly help to send emails to co-chairs.
=A0
Thanks
=A0
-Hui
--20cf3074d86681cbeb04d80f564b-- From fred@cisco.com Sat Mar 16 14:10:08 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DFA21F8833 for ; Sat, 16 Mar 2013 14:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.316 X-Spam-Level: X-Spam-Status: No, score=-110.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nXgc-uv4BbJ for ; Sat, 16 Mar 2013 14:10:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFE621F8539 for ; Sat, 16 Mar 2013 14:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=857; q=dns/txt; s=iport; t=1363468206; x=1364677806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UhCiop3dhjvVfQTZbuT9290T8ZOwt/ILkXuYKQOuzDI=; b=HxHUrLuvKj57cj98/W8/PTR02EN3MkfPOQNqmdtmuWSE/AHM8e8nlZ/M jr6FTYhVH0z/Of19vBqVv7AkHz9QF6j6aH+WGa2RCThaSuAc1gDVqFVDw E+xq8tePAKEsAJImqaFx78Ie4M7w4gQFun18acRxXhZ/r4mO9N9B1/rq9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAGvfRFGtJV2a/2dsb2JhbABDh229R4FtFnSCKgEBAQMBHVwFCwIBCBIQJCERFw4CBA4FCId6AwkGuRYNiVuMTIIWAjEHgl9hA4g/jD+NSIUagwqCKA X-IronPort-AV: E=Sophos;i="4.84,857,1355097600"; d="scan'208";a="188031938" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 16 Mar 2013 21:09:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2GL9wA0029287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Mar 2013 21:09:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 16:09:58 -0500 From: "Fred Baker (fred)" To: Hui Deng Thread-Topic: [mif] Call for volunteers about architecture design Thread-Index: AQHOIng4sp27qzpVGE22Nyh5TTSqyZipJBkA Date: Sat, 16 Mar 2013 21:09:57 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <08C79444E1A72F4A8B4DDE6740D72BC0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 21:10:08 -0000 On Mar 16, 2013, at 12:58 PM, Hui Deng wrote: > Based on yesterday discussion, cochairs would like to call for volunteers= who would like to work on architecture related design work, please kindly = help to send emails to co-chairs. I'm willing to do that, but give fair warning that I think this is triviall= y solved in a manner that we have solved other problems such as PPP Multili= nk. IP should be able to view a set of interfaces as if they were one, and = the simplest way to do that is to insert a virtual interface between the se= t of interfaces and IP. If they are Ethernet interfaces and the device is a= switch or a router, it probably does 802.1 Ethernet Switching between them= . The discussion point will be how one treats that construct on a host, or = when they are of differing interface types. From Ted.Lemon@nominum.com Sat Mar 16 14:17:01 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35ADA21F87FB for ; Sat, 16 Mar 2013 14:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj34YYeiHNdD for ; Sat, 16 Mar 2013 14:16:59 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id C642221F86F4 for ; Sat, 16 Mar 2013 14:16:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUUThS9wmYzQiS/cIBnx72FcouNK8sBKw@postini.com; Sat, 16 Mar 2013 14:16:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 03A5A1B9037 for ; Sat, 16 Mar 2013 14:16:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EAFB1190043; Sat, 16 Mar 2013 14:16:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 16 Mar 2013 14:16:59 -0700 From: Ted Lemon To: "Fred Baker (fred)" Thread-Topic: [mif] Call for volunteers about architecture design Thread-Index: AQHOIng3nl1AuYp4zEafdnXCiS3KaJipRaGAgAAB9AA= Date: Sat, 16 Mar 2013 21:16:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 21:17:01 -0000 On Mar 16, 2013, at 5:09 PM, Fred Baker (fred) wrote: > I'm willing to do that, but give fair warning that I think this is trivia= lly solved in a manner that we have solved other problems such as PPP Multi= link. IP should be able to view a set of interfaces as if they were one, an= d the simplest way to do that is to insert a virtual interface between the = set of interfaces and IP. If they are Ethernet interfaces and the device is= a switch or a router, it probably does 802.1 Ethernet Switching between th= em. The discussion point will be how one treats that construct on a host, o= r when they are of differing interface types. This isn't at all the problem we are talking about. See my slides from th= e intarea presentation for details. From alexandru.petrescu@gmail.com Sat Mar 16 18:39:21 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5ED21F8576 for ; Sat, 16 Mar 2013 18:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.108 X-Spam-Level: X-Spam-Status: No, score=-10.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKJf1Q9SGCJv for ; Sat, 16 Mar 2013 18:39:20 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 63C0821F8574 for ; Sat, 16 Mar 2013 18:39:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2H1dI4g018084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 17 Mar 2013 02:39:18 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2H1dIp8000599 for ; Sun, 17 Mar 2013 02:39:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.1]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2H1d5gD021671 for ; Sun, 17 Mar 2013 02:39:18 +0100 Message-ID: <51451E98.1020007@gmail.com> Date: Sun, 17 Mar 2013 02:38:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mif@ietf.org References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 01:39:21 -0000 Le 16/03/2013 22:16, Ted Lemon a écrit : > On Mar 16, 2013, at 5:09 PM, Fred Baker (fred) > wrote: >> I'm willing to do that, but give fair warning that I think this is >> trivially solved in a manner that we have solved other problems >> such as PPP Multilink. IP should be able to view a set of >> interfaces as if they were one, and the simplest way to do that is >> to insert a virtual interface between the set of interfaces and >> IP. If they are Ethernet interfaces and the device is a switch or >> a router, it probably does 802.1 Ethernet Switching between them. >> The discussion point will be how one treats that construct on a >> host, or when they are of differing interface types. > > This isn't at all the problem we are talking about. See my slides > from the intarea presentation for details. This kind of problem - make one virtual interface to link all other interfaces together, with goals such as bandwidth augmentation, on a Mobile Router (not a Host) - is discussed in the ITS Intelligent Transportation Systems email list ietf.org/mailman/listinfo/its (this is one problem being considered there, but there are other ITS problems considered there. And there there is thought that MIF may consider this case - it seems not.) Alex > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From Ted.Lemon@nominum.com Sun Mar 17 04:51:14 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDB021F8771 for ; Sun, 17 Mar 2013 04:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrAnSCvhSXiS for ; Sun, 17 Mar 2013 04:51:13 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 197B621F855A for ; Sun, 17 Mar 2013 04:51:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUUWuMFV8Fcd+YrhTSra+mQ14AUDVKvwi@postini.com; Sun, 17 Mar 2013 04:51:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8986E1B8ECD for ; Sun, 17 Mar 2013 04:51:12 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7AC4F190043; Sun, 17 Mar 2013 04:51:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 17 Mar 2013 04:51:07 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Call for volunteers about architecture design Thread-Index: AQHOIng3nl1AuYp4zEafdnXCiS3KaJipRaGAgAAB9ACAAEkXAIAAqygA Date: Sun, 17 Mar 2013 11:51:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> In-Reply-To: <51451E98.1020007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0671827A806B084DA72AE11F95637845@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 11:51:14 -0000 On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu wrote: > This kind of problem - make one virtual interface to link all other > interfaces together, with goals such as bandwidth augmentation, on a > Mobile Router (not a Host) - is discussed in the ITS Intelligent > Transportation Systems email list ietf.org/mailman/listinfo/its >=20 > (this is one problem being considered there, but there are other ITS > problems considered there. And there there is thought that MIF may > consider this case - it seems not.) I think we should definitely consider this problem in the architecture disc= ussion. Whether it's in-scope or out of scope is another question. From swmike@swm.pp.se Mon Mar 18 07:03:36 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D030D21F8EE6 for ; Mon, 18 Mar 2013 07:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8cpMj4z39-4 for ; Mon, 18 Mar 2013 07:03:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 228AC21F8EE5 for ; Mon, 18 Mar 2013 07:03:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E416E9C; Mon, 18 Mar 2013 15:03:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DF0F49A for ; Mon, 18 Mar 2013 15:03:34 +0100 (CET) Date: Mon, 18 Mar 2013 15:03:34 +0100 (CET) From: Mikael Abrahamsson To: mif@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [mif] draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:03:36 -0000 Hello. I was going through IETF86 presentations and found the DHCPv6 route option draft. I have some thoughts about this subject: I would like to be able to provision routes based on source address of the packet being sent from the host. Use case: Two different routers announce two different on-link prefixes. I now want to be able to say that a certain route should only be applied towards one of the routers for a specific set of source addresses (most likely the addresses announced as being on-link by that router but not necessarily so). It feels like my case is close to use case 8 in the draft, but it's not clear to me from reading the draft if what I'm proposing is actually possible, especially since the format of the route information seems to be destination based only? 2001:db8:1::/64 /---- router a host ------------------- 2001:db8:2::/64 \---- router b so I want all packets sourced from 2001:db8:1::/64 to go to router a and all packets from 2001:db8:2::/64 to go to router b. Perhaps I also want to null route 2001:db8:3::/64 if sourced from 2001:db8:2::/64 plus add a 2001:db8:3::/64 via router a from 2001:db8:1::/64 (to make sure 2001:db8:2::/64 is never used to reach 2001:db8:3::/64). Or I just add a ::/0 source for 2001:db8:3::/64 via router a because this is a DMZ that is not reachable via router b at all, so both 2001:db8:1::/64 and 2001:db8:2::/64 sould use router a to reach 2001:db8:3::/64. Adding a source IP field to the route would give a lot of flexibility. Thougts? -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Mon Mar 18 07:58:45 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65C21F89D3 for ; Mon, 18 Mar 2013 07:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.11 X-Spam-Level: X-Spam-Status: No, score=-10.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5nnKGBZrBQb for ; Mon, 18 Mar 2013 07:58:44 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7484C21F889D for ; Mon, 18 Mar 2013 07:58:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2IEwgqp014495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 15:58:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2IEwgZW010577; Mon, 18 Mar 2013 15:58:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2IEwc4R020414; Mon, 18 Mar 2013 15:58:42 +0100 Message-ID: <51472B79.9030809@gmail.com> Date: Mon, 18 Mar 2013 15:58:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 14:58:45 -0000 Le 17/03/2013 12:51, Ted Lemon a écrit : > On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu > wrote: >> This kind of problem - make one virtual interface to link all >> other interfaces together, with goals such as bandwidth >> augmentation, on a Mobile Router (not a Host) - is discussed in the >> ITS Intelligent Transportation Systems email list >> ietf.org/mailman/listinfo/its >> >> (this is one problem being considered there, but there are other >> ITS problems considered there. And there there is thought that MIF >> may consider this case - it seems not.) > > I think we should definitely consider this problem in the > architecture discussion. Whether it's in-scope or out of scope is > another question. In addition to simultaneous use of multiple interfaces for bandwidth augmentation on a low-ratio egress-ingress bandwidth Mobile Router (its egress bandwith is much lower than ingress bandwidth), there is another aspect which deserves mentioning in a mif'ed Host: the use of Mobile IP and handovers. This would be such that a Host to offer highly available connections - when WiFi is available use WiFi, but if cellular is available then use cellular. This could be a sequential use of interfaces (only one interface is used exclusively), as opposed to simultaneous use of interfaces. The architecture aspect in this is the difference between simultaneous vs sequential use of interfaces. This could be illustrated with pictures of topology. This is something very complex to deal with. Alex > > > From Ted.Lemon@nominum.com Mon Mar 18 08:28:20 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E46E21F8FA3 for ; Mon, 18 Mar 2013 08:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdefCU7iQctU for ; Mon, 18 Mar 2013 08:28:19 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08E21F8D77 for ; Mon, 18 Mar 2013 08:28:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUUcykwUS9LluAYarawAgkLQVWZ71xtON@postini.com; Mon, 18 Mar 2013 08:28:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 146291B8E20 for ; Mon, 18 Mar 2013 08:28:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0AAAF190043; Mon, 18 Mar 2013 08:28:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 08:28:18 -0700 From: Ted Lemon To: Mikael Abrahamsson Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHOI+Fk9uoAyx8udEmZ71kNfAdwg5isCAOA Date: Mon, 18 Mar 2013 15:28:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751124E3@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:28:20 -0000 On Mar 18, 2013, at 10:03 AM, Mikael Abrahamsson wrote: > I was going through IETF86 presentations and found the DHCPv6 route optio= n draft. I have some thoughts about this subject: >=20 > I would like to be able to provision routes based on source address of th= e packet being sent from the host. You should not be expected to be aware of this, since it's quite recent new= s, but work on this option is going to be removed from the MIF charter, and= is officially out of scope for the working group, because it's such a cont= entious issue, and the working group needs to focus on its core charter. I think the question you've asked is an interesting one, but until we find = a home for this work and get IETF consensus on it, it's moot, since you can= 't have operational issues with a standard that hasn't been published (at l= east in theory). If you are interested in this work, there's been some talk of forming a non= -WG mailing list at the IETF for people who want to talk about it. I woul= d be happy to add you to the list of people who are interested in this topi= c if you want. And I do apologize for responding to a technical question with a process an= swer... :} From tomasz.mrugalski@gmail.com Mon Mar 18 10:18:42 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75D421F86C5 for ; Mon, 18 Mar 2013 10:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKMAvW5ZHRCV for ; Mon, 18 Mar 2013 10:18:34 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id F3B5121F8FDD for ; Mon, 18 Mar 2013 10:18:32 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id ez12so2871150wid.6 for ; Mon, 18 Mar 2013 10:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=kqyXtkeGXwLRB973G/G+XhyA+4zoQp+9P8jdJjPze+E=; b=jrn+9xN1C9pItrq3af9GBsIbBj+prMl+2Tnr+YNncozH5KppSPysrUhf/hmZq+sQx4 Ay/5Cnqx3D0zO2U6GDXAhuQmZiPhi1od3zKjGLMW0YRxTOCk3wX7j5ve0pNrJfFWDS7Z +dL8QspRPdqxcJLoXlZfMiE4o+23bzDp9/kVTL9Gi0O43YCulw2GntVQKlimQ+0Yu+8c 4ZbHPO36+8SReapsD29/gjSo7pQXCPfi2OCkfLHUHExPmads/vY5LCz3k62RBoejCUSL o3YUTYABMcalqS8Bh5k5xsLPwyx2dfbeXdpe5CBaxmtZM0i28AediXGVISvYqfTkEnRW DxWg== X-Received: by 10.194.92.65 with SMTP id ck1mr26754294wjb.54.1363627112031; Mon, 18 Mar 2013 10:18:32 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id fb8sm16238454wid.1.2013.03.18.10.18.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 10:18:31 -0700 (PDT) Message-ID: <51474C5D.7090701@gmail.com> Date: Mon, 18 Mar 2013 18:18:21 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: mif@ietf.org References: <8D23D4052ABE7A4490E77B1A012B6307751124E3@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751124E3@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130318181821089 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:18:42 -0000 On 18.03.2013 16:28, Ted Lemon wrote: > On Mar 18, 2013, at 10:03 AM, Mikael Abrahamsson > wrote: >> I was going through IETF86 presentations and found the DHCPv6 route >> option draft. I have some thoughts about this subject: >> >> I would like to be able to provision routes based on source address >> of the packet being sent from the host. A long time ago when mif-dhcpv6-route-option was forming as a rough merge between 3 drafts we made a decision to make source routing out of scope. Not because it was not important, but because it would make the whole concept even more contentious. dhcpv6-route-option is designed to be extensible. It is possible to define a new option that will convey information about source routing as well. > I think the question you've asked is an interesting one, but until we > find a home for this work and get IETF consensus on it, it's moot, > since you can't have operational issues with a standard that hasn't > been published (at least in theory). In my opinion there should be something published out of this work: either the route-option itself or a draft that explains why route-option like solution will not be published in IETF. This is fifth IIRC attempt to standardize routing configuration over DHCPv6. Even if we abandon this work, other attempts will be made in the future. It would be good to have something simple and clear to point to ("don't do this, because of the following reasons" style of a draft). > If you are interested in this work, there's been some talk of forming > a non-WG mailing list at the IETF for people who want to talk about > it. I would be happy to add you to the list of people who are > interested in this topic if you want. > > And I do apologize for responding to a technical question with a > process answer... :} We had technical answers coming all around and it didn't help, so we may want try a process one as well. ;) Tomek From Ted.Lemon@nominum.com Mon Mar 18 10:32:11 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADDC21F9047 for ; Mon, 18 Mar 2013 10:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yke-U5RFrL1 for ; Mon, 18 Mar 2013 10:32:03 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4E88B21F9028 for ; Mon, 18 Mar 2013 10:32:03 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUUdPksYZDQBRTbBwgO/7dVQKF50XVvbl@postini.com; Mon, 18 Mar 2013 10:32:03 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C51B61B8E1D for ; Mon, 18 Mar 2013 10:32:02 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B902B190043; Mon, 18 Mar 2013 10:32:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 10:31:56 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHOI+Fk9uoAyx8udEmZ71kNfAdwg5isCAOAgAAewICAAAPLgA== Date: Mon, 18 Mar 2013 17:31:55 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775112AD4@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307751124E3@mbx-01.win.nominum.com> <51474C5D.7090701@gmail.com> In-Reply-To: <51474C5D.7090701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <66FCDD9C8B49AC408178ACD355E12EAD@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:32:11 -0000 On Mar 18, 2013, at 1:18 PM, Tomek Mrugalski w= rote: > We had technical answers coming all around and it didn't help, so we may > want try a process one as well. ;) Indeed so. But let us keep this discussion off the MIF mailing list; if y= ou read this and want to be added to a discussion list, please reply to me = privately and not on the mif list. Thanks! From denghui02@gmail.com Mon Mar 18 17:11:15 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17521F855A for ; Mon, 18 Mar 2013 17:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGYsO15WDQ7j for ; Mon, 18 Mar 2013 17:11:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9F6121F8507 for ; Mon, 18 Mar 2013 17:11:07 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr12so5496131wgb.35 for ; Mon, 18 Mar 2013 17:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ojNSfNyJWk8DfNDKzIs9Yw5vnfjitJggMTxyhtXL8z4=; b=aKeVfWQrNz4PfznJ3glflYBC4Q3OGtKHA6ya/5fwtVAE/FA/0BKk4oZxgokEzSGKEh /H/qk1VmTEawKKeZWX7MU3mXRjpr65zjNA9xxLiMyrO/KfVG1M5tozbGy99C0MfdLlEn gK16XT/sTuYdBdEuEuYcVunxQUPZOoT0ltUrFtGd0kp+AcJ2k7QgpE2hFnmsNapNXIvw LJLLXU2jm3uQMNAV7lCK/Adj7bsj0L7PtWPZZRSyasflZRzEmINdBU2Wg4eOz4sxfabL 4AE5DGpK6gHNIKpP5HYIINGpCh6WI3ScoirtCOkMrtVj69++jTaEQ1uDvRXjKI4DCR9q 2+sw== MIME-Version: 1.0 X-Received: by 10.194.119.200 with SMTP id kw8mr28552943wjb.31.1363651866880; Mon, 18 Mar 2013 17:11:06 -0700 (PDT) Received: by 10.194.242.7 with HTTP; Mon, 18 Mar 2013 17:11:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 08:11:06 +0800 Message-ID: From: Hui Deng To: Erik Kline Content-Type: multipart/alternative; boundary=089e011779131f6fe704d83bf1b1 Cc: "mif@ietf.org" Subject: Re: [mif] Network Access Identifier X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:11:15 -0000 --089e011779131f6fe704d83bf1b1 Content-Type: text/plain; charset=ISO-8859-1 Erik Just a short comment on this, mobile network (3GPP) only use NAI when the mobile connects with operator's wifi, and NAI is not used in mobile connection side. It depends on how we design it, for today internet access, only MAC address is used as identifier, if we want to consider migrate into NAI, it may bring the security/trust issue for network access again. -Hui 2013/3/15 Erik Kline > Ted, > > Pursuant to our in-person conversation about APNs as one example of string > identifiers used as a kind of provisioning profile identifier, I followed > some 3gpp docs until I got to RFC 4282: > > http://www.3gpp.org/ftp/Specs/html-info/23003.htm > > http://www.etsi.org/deliver/etsi_ts/123000_123099/123003/11.04.00_60/ts_123003v110400p.pdf > http://tools.ietf.org/html/rfc4282 > > I know it's *way* too early to discuss provisioning domain/profile string > identifiers, and that the stated purpose ( > http://tools.ietf.org/html/rfc4282#section-1.3) is not necessarily the > same. > > Nevertheless, I hadn't run across this before and I found it interesting > that something that /may/ be used as a model is out there (complete with > international character set, DNS, and email address compatibility > discussion). > > -ek > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --089e011779131f6fe704d83bf1b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Erik
=A0
Just a short comment on this, mobile netw= ork (3GPP) only use NAI when the=A0mobile=A0connects with=A0operator's = wifi,
and NAI is not used in mobile connection side.
It depends on how we design it, for today internet access, only MAC addre= ss is used as identifier, if we want to consider migrate into NAI, it may b= ring the security/trust issue for network access again.
=A0
-Hui
2013/3/15 Erik = Kline <ek@google.com>
Ted,

Pursuant to our in-person conversa= tion about APNs as one example of string identifiers used as a kind of prov= isioning profile identifier, I followed some 3gpp docs until I got to RFC 4= 282:


I know= it's *way* too early to discuss provisioning domain/profile string ide= ntifiers, and that the stated purpose (http://tools.ietf.org/html/rfc4282= #section-1.3) is not necessarily the same.

Nevertheless, I hadn't run across this before and I= found it interesting that something that /may/ be used as a model is out t= here (complete with international character set, DNS, and email address com= patibility discussion).

-ek

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


--089e011779131f6fe704d83bf1b1-- From pierrick.seite@orange.com Tue Mar 19 02:13:56 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E83321F8596 for ; Tue, 19 Mar 2013 02:13:56 -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=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWCzEDyrP2rM for ; Tue, 19 Mar 2013 02:13:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3522621F854E for ; Tue, 19 Mar 2013 02:13:55 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id ECEFA22C6C0; Tue, 19 Mar 2013 10:13:53 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D09C523805C; Tue, 19 Mar 2013 10:13:53 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 19 Mar 2013 10:13:53 +0100 From: To: Alexandru Petrescu , Ted Lemon Thread-Topic: [mif] Call for volunteers about architecture design Thread-Index: AQHOIng4G+l5EKX7M0ONPce2bY9Bqpiov4WAgAAB9gCAAEkUAIAAqycAgAHGjoCAATxYAA== Date: Tue, 19 Mar 2013 09:13:53 +0000 Message-ID: <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> In-Reply-To: <51472B79.9030809@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.18.105419 Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 09:13:56 -0000 Hi Alex, Except the problem of access discovery and selection, I'm not sure there ar= e multiple provisioning domains issues with sequential use of interfaces. T= his is something we can do with current terminal... Maybe I'm wrong but, an= yway, I guess the architecture work will start with discussion on use-cases= to identify what is relevant or not. Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de > Alexandru Petrescu > Envoy=E9=A0: lundi 18 mars 2013 15:58 > =C0=A0: Ted Lemon > Cc=A0: > Objet=A0: Re: [mif] Call for volunteers about architecture design >=20 > Le 17/03/2013 12:51, Ted Lemon a =E9crit : > > On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu > > wrote: > >> This kind of problem - make one virtual interface to link all other > >> interfaces together, with goals such as bandwidth augmentation, on a > >> Mobile Router (not a Host) - is discussed in the ITS Intelligent > >> Transportation Systems email list ietf.org/mailman/listinfo/its > >> > >> (this is one problem being considered there, but there are other ITS > >> problems considered there. And there there is thought that MIF may > >> consider this case - it seems not.) > > > > I think we should definitely consider this problem in the > > architecture discussion. Whether it's in-scope or out of scope is > > another question. >=20 > In addition to simultaneous use of multiple interfaces for bandwidth > augmentation on a low-ratio egress-ingress bandwidth Mobile Router (its > egress bandwith is much lower than ingress bandwidth), >=20 > there is another aspect which deserves mentioning in a mif'ed Host: the > use of Mobile IP and handovers. This would be such that a Host to > offer highly available connections - when WiFi is available use WiFi, > but if cellular is available then use cellular. This could be a > sequential use of interfaces (only one interface is used exclusively), > as opposed to simultaneous use of interfaces. >=20 > The architecture aspect in this is the difference between simultaneous > vs sequential use of interfaces. This could be illustrated with > pictures of topology. >=20 > This is something very complex to deal with. >=20 > Alex >=20 > > > > > > >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ek@google.com Tue Mar 19 03:17:07 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0233321F88CF for ; Tue, 19 Mar 2013 03:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+PfYohgqKJ1 for ; Tue, 19 Mar 2013 03:17:06 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id D078B21F84BC for ; Tue, 19 Mar 2013 03:17:03 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n12so256549oag.13 for ; Tue, 19 Mar 2013 03:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FZJLXbAdHtNT84TyhDjB6kW8guVZHA1L2VBg4BPOl70=; b=AbAQajzBQ6HXYE7BRwbd/mqH/4H1FryUcgVB/PiihQx+GZRL3wuHYgjiEBHo/utf8b XNsPiIHpDefGdJdNkZnA58BCDyElimxNqXVbmEWhOE+JX5wIeYm5pxk9Dejk/CMhYitU UNNSrZt1YidSGKhyR5l/rwxuH+3juNZDOZmqRr5aX3W/rFaWuyz2HBHpDh2+C4unK+s/ nwENcZfVHU7tIXVW8YA0tQLCNhuWtS/5yQm3R1f2MuKWzRJmNKMyFU8IjS7od/VJB9Dm e7JmTndME7Jw8xQYMHgCg/+wXxnQXiOm3YFF/KMyAHE88bB6JzpWfsnu4IS/q9Kb9W3J LvwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=FZJLXbAdHtNT84TyhDjB6kW8guVZHA1L2VBg4BPOl70=; b=P6uYiy7Z14GnFIRwz1mHKaAzNljuyVLC405jZuQCXfr3Z15C9gzZfSMUBZsBWrWPWd TBty0OAlTYwIlz00HmrPnslXRLiRnMbjwM3Tm8tASj0+FCyDyun5hEPZYth+G/AH0SEU 7+DenXIvzrZOLbPQ9eDiRAWikG6CBeVveIY2GPiGsOc6zOJkj9VVxXhGH9MGYPKCe2bt KoPu0sUj/C/aaEfRjryHKYZ06x/SdnawU+4f8BXJ/88+e3ef6RMm1BkbplEsyyCoxOl7 rEPbGiTuQy/H7wQ3X8TX5YKvAVxeJaNm+R262FNIAI8sYwaoc0aVT2yHaoMhAjXMZq/4 XSVA== X-Received: by 10.182.194.35 with SMTP id ht3mr849987obc.39.1363688223404; Tue, 19 Mar 2013 03:17:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.50.227 with HTTP; Tue, 19 Mar 2013 03:16:43 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Tue, 19 Mar 2013 06:16:43 -0400 Message-ID: To: Hui Deng Content-Type: multipart/alternative; boundary=f46d0444e899240aa804d8446810 X-Gm-Message-State: ALoCoQknaK4LVHQ3+lpK9RIfhjkUjUYgp5wr2ojjzflw+bCXL9VdKGR2R1MvjyZ95T5Sif8A0w7xsCfcrkeWo+oAVlXts9xEgeX3mA0Ydn+BJap5xsYIYU3Ms3iHoCW2ppPtRooYr8ReWnkk/g3Oawa/aF19Vi/hD/W+sgjgLMV5TYVyhkE+zBj7qS9FKCqPjUSFVN0dqGwz Cc: "mif@ietf.org" Subject: Re: [mif] Network Access Identifier X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 10:17:07 -0000 --f46d0444e899240aa804d8446810 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hui, By "security/trust issue" I would guess that you mean the provider needs some way to verify that the provisioning profile requested by the user can and should actually be provided (they've paid for it, they're who they say they are, ...). If so, that sounds like a perfectly normal AAA type of concern. =E2=80=8BIf provisioning domains are like "static facts" about the network(= s) then AAA is likely less of a concern (or possibly not a concern at all). But if a client can request/select from among a set of available provisioning domains then AAA issues will likely follow. Interesting. Thanks. --f46d0444e899240aa804d8446810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hui,

By "security/trust issue"= ; I would guess that you mean the provider needs some way to verify that th= e provisioning profile requested by the user can and should actually be pro= vided (they've paid for it, they're who they say they are, ...). = =C2=A0If so, that sounds like a perfectly normal AAA type of concern.

=E2=80=8BIf provisioning domains are like "static facts= " about the network(s) then AAA is likely less of a concern (or possib= ly not a concern at all). =C2=A0But if a client can request/select from amo= ng a set of available provisioning domains then AAA issues will likely foll= ow. =C2=A0Interesting.

Thanks.
--f46d0444e899240aa804d8446810-- From alexandru.petrescu@gmail.com Tue Mar 19 07:34:37 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6537A21F85D4 for ; Tue, 19 Mar 2013 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.163 X-Spam-Level: X-Spam-Status: No, score=-10.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2Wg13bS9Nqz for ; Tue, 19 Mar 2013 07:34:36 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6F03B21F85C6 for ; Tue, 19 Mar 2013 07:34:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2JEYY0q027945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 15:34:34 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2JEYY2t025192; Tue, 19 Mar 2013 15:34:34 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2JEYNCr028098; Tue, 19 Mar 2013 15:34:34 +0100 Message-ID: <51487747.20506@gmail.com> Date: Tue, 19 Mar 2013 15:33:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:34:37 -0000 Le 19/03/2013 10:13, pierrick.seite@orange.com a écrit : > Hi Alex, > > Except the problem of access discovery and selection, I'm not sure > there are multiple provisioning domains issues with sequential use of > interfaces. I am not sure either. If continuous sessions are needed after a handover WiFi-3G (each is in a different provisioning domain), then Mobile IP should be used; if Mobile IP is used then there is a routing problem at the initial setup phase (the default route points to a tunnel interface but the HA should be reached with a host-specific route on the real interface). There could be advice from HA to mobile to tell it how to set up that route (use one the real interface for reaching HA and the tunnel interface for all other traffic). This advice is just another kind of advice that should be taken with precaution. Or there could be a visual interface on the terminal to set manually the default route and other specific routes. (was already said). Alex > This is something we can do with current terminal... Maybe I'm wrong > but, anyway, I guess the architecture work will start with discussion > on use-cases to identify what is relevant or not. > > Pierrick > >> -----Message d'origine----- De : mif-bounces@ietf.org >> [mailto:mif-bounces@ietf.org] De la part de Alexandru Petrescu >> Envoyé : lundi 18 mars 2013 15:58 À : Ted Lemon Cc : >> Objet : Re: [mif] Call for volunteers about >> architecture design >> >> Le 17/03/2013 12:51, Ted Lemon a écrit : >>> On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu >>> wrote: >>>> This kind of problem - make one virtual interface to link all >>>> other interfaces together, with goals such as bandwidth >>>> augmentation, on a Mobile Router (not a Host) - is discussed in >>>> the ITS Intelligent Transportation Systems email list >>>> ietf.org/mailman/listinfo/its >>>> >>>> (this is one problem being considered there, but there are >>>> other ITS problems considered there. And there there is >>>> thought that MIF may consider this case - it seems not.) >>> >>> I think we should definitely consider this problem in the >>> architecture discussion. Whether it's in-scope or out of scope >>> is another question. >> >> In addition to simultaneous use of multiple interfaces for >> bandwidth augmentation on a low-ratio egress-ingress bandwidth >> Mobile Router (its egress bandwith is much lower than ingress >> bandwidth), >> >> there is another aspect which deserves mentioning in a mif'ed Host: >> the use of Mobile IP and handovers. This would be such that a Host >> to offer highly available connections - when WiFi is available use >> WiFi, but if cellular is available then use cellular. This could be >> a sequential use of interfaces (only one interface is used >> exclusively), as opposed to simultaneous use of interfaces. >> >> The architecture aspect in this is the difference between >> simultaneous vs sequential use of interfaces. This could be >> illustrated with pictures of topology. >> >> This is something very complex to deal with. >> >> Alex >> >>> >>> >>> >> >> >> _______________________________________________ mif mailing list >> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > > _________________________________________________________________________________________________________________________ > > > > 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, France Telecom - 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, France > Telecom - Orange is not liable for messages that have been modified, > changed or falsified. Thank you. > > > From pierrick.seite@orange.com Tue Mar 19 08:03:33 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780F021F8CD4 for ; Tue, 19 Mar 2013 08:03:33 -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=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8BF-SLGWZ1W for ; Tue, 19 Mar 2013 08:03:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6961521F8A68 for ; Tue, 19 Mar 2013 08:03:32 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id EF2D622C860; Tue, 19 Mar 2013 16:03:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D20EF238067; Tue, 19 Mar 2013 16:03:30 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 19 Mar 2013 16:03:30 +0100 From: To: Alexandru Petrescu Thread-Topic: [mif] Call for volunteers about architecture design Thread-Index: AQHOJK7BG+l5EKX7M0ONPce2bY9BqpitGlNA Date: Tue, 19 Mar 2013 15:03:30 +0000 Message-ID: <17520_1363705410_51487E42_17520_10_1_81C77F07008CA24F9783A98CFD706F710B4676@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51487747.20506@gmail.com> In-Reply-To: <51487747.20506@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.18.105419 Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:03:33 -0000 Ok, so, being more generic than MIP, the problem is about simultaneous usag= e (not sequential) of physical and virtual interfaces, on a single physical= interface. This problem is identified in MIF problem statement.=20 Pierrick > -----Message d'origine----- > De=A0: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Envoy=E9=A0: mardi 19 mars 2013 15:34 > =C0=A0: SEITE Pierrick OLNC/OLN > Cc=A0: Ted Lemon; > Objet=A0: Re: [mif] Call for volunteers about architecture design >=20 > Le 19/03/2013 10:13, pierrick.seite@orange.com a =E9crit : > > Hi Alex, > > > > Except the problem of access discovery and selection, I'm not sure > > there are multiple provisioning domains issues with sequential use of > > interfaces. >=20 > I am not sure either. >=20 > If continuous sessions are needed after a handover WiFi-3G (each is in > a different provisioning domain), then Mobile IP should be used; if > Mobile IP is used then there is a routing problem at the initial setup > phase (the default route points to a tunnel interface but the HA should > be reached with a host-specific route on the real interface). >=20 > There could be advice from HA to mobile to tell it how to set up that > route (use one the real interface for reaching HA and the tunnel > interface for all other traffic). This advice is just another kind of > advice that should be taken with precaution. >=20 > Or there could be a visual interface on the terminal to set manually > the default route and other specific routes. (was already said). >=20 > Alex >=20 >=20 > > This is something we can do with current terminal... Maybe I'm wrong > > but, anyway, I guess the architecture work will start with discussion > > on use-cases to identify what is relevant or not. > > > > Pierrick > > > >> -----Message d'origine----- De : mif-bounces@ietf.org > >> [mailto:mif-bounces@ietf.org] De la part de Alexandru Petrescu > Envoy=E9 > >> : lundi 18 mars 2013 15:58 =C0 : Ted Lemon Cc : > >> Objet : Re: [mif] Call for volunteers about > >> architecture design > >> > >> Le 17/03/2013 12:51, Ted Lemon a =E9crit : > >>> On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu > >>> wrote: > >>>> This kind of problem - make one virtual interface to link all > other > >>>> interfaces together, with goals such as bandwidth augmentation, on > >>>> a Mobile Router (not a Host) - is discussed in the ITS Intelligent > >>>> Transportation Systems email list ietf.org/mailman/listinfo/its > >>>> > >>>> (this is one problem being considered there, but there are other > >>>> ITS problems considered there. And there there is thought that > MIF > >>>> may consider this case - it seems not.) > >>> > >>> I think we should definitely consider this problem in the > >>> architecture discussion. Whether it's in-scope or out of scope > >>> is another question. > >> > >> In addition to simultaneous use of multiple interfaces for bandwidth > >> augmentation on a low-ratio egress-ingress bandwidth Mobile Router > >> (its egress bandwith is much lower than ingress bandwidth), > >> > >> there is another aspect which deserves mentioning in a mif'ed Host: > >> the use of Mobile IP and handovers. This would be such that a Host > >> to offer highly available connections - when WiFi is available use > >> WiFi, but if cellular is available then use cellular. This could be > a > >> sequential use of interfaces (only one interface is used > >> exclusively), as opposed to simultaneous use of interfaces. > >> > >> The architecture aspect in this is the difference between > >> simultaneous vs sequential use of interfaces. This could be > >> illustrated with pictures of topology. > >> > >> This is something very complex to deal with. > >> > >> Alex > >> > >>> > >>> > >>> > >> > >> > >> _______________________________________________ mif mailing list > >> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > > > > > > 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, France Telecom - 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, France Telecom > > - Orange is not liable for messages that have been modified, changed > > or falsified. Thank you. > > > > > > >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Ted.Lemon@nominum.com Tue Mar 19 08:10:13 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3287D21F8D1F for ; Tue, 19 Mar 2013 08:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQQHjJc+N+6K for ; Tue, 19 Mar 2013 08:10:12 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6BE21F8D1E for ; Tue, 19 Mar 2013 08:10:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUUh/0oixgEav3Lao5hDsR4NgVtTon1YY@postini.com; Tue, 19 Mar 2013 08:10:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 628201B8802 for ; Tue, 19 Mar 2013 08:10:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 58331190043; Tue, 19 Mar 2013 08:10:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 08:10:10 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Call for volunteers about architecture design Thread-Index: AQHOIng3nl1AuYp4zEafdnXCiS3KaJipRaGAgAAB9ACAAEkXAIAAqygAgAHGjICAATIvgIAAWVyAgAAKLoA= Date: Tue, 19 Mar 2013 15:10:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775114E93@mbx-01.win.nominum.com> References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51487747.20506@gmail.com> In-Reply-To: <51487747.20506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3E2484DDFED52A40B8B5BE1070F3F4C2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:10:13 -0000 On Mar 19, 2013, at 10:33 AM, Alexandru Petrescu wrote: >> Except the problem of access discovery and selection, I'm not sure >> there are multiple provisioning domains issues with sequential use of >> interfaces. >=20 > I am not sure either. My take on this, for what it's worth, is that the work MIF is doing will be= useful, but not central, to what you are trying to do. MIF is focusing o= n what happens when all the interfaces are on at the same time, but we also= want to enable the provision sufficient functionality that you can set up = a connection manager that makes choices about which interfaces to keep aliv= e when. I am not _convinced_ that we need to do a lot of work in that space=97we ma= y be able to leverage work that IEEE has already done, for example, in whic= h case our job would be filling in the gaps that IEEE has not already addre= ssed, or getting IEEE to do it, whichever makes the most sense. But the point is that I think you should probably be interested in what MIF= is doing, but I suspect that the work MIF is doing is not crucial to the w= ork you are doing. From alexandru.petrescu@gmail.com Tue Mar 19 08:37:13 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA01F21F8CDD for ; Tue, 19 Mar 2013 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D2Ffr1DQBp0 for ; Tue, 19 Mar 2013 08:37:13 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 801E021F8CBD for ; Tue, 19 Mar 2013 08:37:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2JFbB5H023562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 16:37:11 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2JFbAJ3026886; Tue, 19 Mar 2013 16:37:11 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2JFb0xl009713; Tue, 19 Mar 2013 16:37:10 +0100 Message-ID: <514885F5.4030603@gmail.com> Date: Tue, 19 Mar 2013 16:36:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51487747.20506@gmail.com> <17520_1363705410_51487E42_17520_10_1_81C77F07008CA24F9783A98CFD706F710B4676@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17520_1363705410_51487E42_17520_10_1_81C77F07008CA24F9783A98CFD706F710B4676@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:37:14 -0000 Le 19/03/2013 16:03, pierrick.seite@orange.com a écrit : > Ok, so, being more generic than MIP, the problem is about > simultaneous usage (not sequential) of physical and virtual > interfaces, on a single physical interface. I agree in this sense. (to me 'simultaneous use' is when we say simultaneous use for bandwidth augmentation. Distinct HAroute and defroute - what we discuss above - is a method to do mobility registration at the same time as traffic, but does not offer bandwidth augmentation.) For the pure use of interfaces in a sequential manner, I dont see anything else than a Mobile IP problem, which is solved, as you say. > This problem is identified in MIF problem statement. Ok. Alex > > Pierrick >> -----Message d'origine----- De : Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Envoyé : mardi 19 mars 2013 >> 15:34 À : SEITE Pierrick OLNC/OLN Cc : Ted Lemon; >> Objet : Re: [mif] Call for volunteers about architecture design >> >> Le 19/03/2013 10:13, pierrick.seite@orange.com a écrit : >>> Hi Alex, >>> >>> Except the problem of access discovery and selection, I'm not >>> sure there are multiple provisioning domains issues with >>> sequential use of interfaces. >> >> I am not sure either. >> >> If continuous sessions are needed after a handover WiFi-3G (each >> is in a different provisioning domain), then Mobile IP should be >> used; if Mobile IP is used then there is a routing problem at the >> initial setup phase (the default route points to a tunnel interface >> but the HA should be reached with a host-specific route on the >> real interface). >> >> There could be advice from HA to mobile to tell it how to set up >> that route (use one the real interface for reaching HA and the >> tunnel interface for all other traffic). This advice is just >> another kind of advice that should be taken with precaution. >> >> Or there could be a visual interface on the terminal to set >> manually the default route and other specific routes. (was already >> said). >> >> Alex >> >> >>> This is something we can do with current terminal... Maybe I'm >>> wrong but, anyway, I guess the architecture work will start with >>> discussion on use-cases to identify what is relevant or not. >>> >>> Pierrick >>> >>>> -----Message d'origine----- De : mif-bounces@ietf.org >>>> [mailto:mif-bounces@ietf.org] De la part de Alexandru Petrescu >> Envoyé >>>> : lundi 18 mars 2013 15:58 À : Ted Lemon Cc : >>>> Objet : Re: [mif] Call for volunteers about architecture >>>> design >>>> >>>> Le 17/03/2013 12:51, Ted Lemon a écrit : >>>>> On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu >>>>> wrote: >>>>>> This kind of problem - make one virtual interface to link >>>>>> all >> other >>>>>> interfaces together, with goals such as bandwidth >>>>>> augmentation, on a Mobile Router (not a Host) - is >>>>>> discussed in the ITS Intelligent Transportation Systems >>>>>> email list ietf.org/mailman/listinfo/its >>>>>> >>>>>> (this is one problem being considered there, but there are >>>>>> other ITS problems considered there. And there there is >>>>>> thought that >> MIF >>>>>> may consider this case - it seems not.) >>>>> >>>>> I think we should definitely consider this problem in the >>>>> architecture discussion. Whether it's in-scope or out of >>>>> scope is another question. >>>> >>>> In addition to simultaneous use of multiple interfaces for >>>> bandwidth augmentation on a low-ratio egress-ingress bandwidth >>>> Mobile Router (its egress bandwith is much lower than ingress >>>> bandwidth), >>>> >>>> there is another aspect which deserves mentioning in a mif'ed >>>> Host: the use of Mobile IP and handovers. This would be such >>>> that a Host to offer highly available connections - when WiFi >>>> is available use WiFi, but if cellular is available then use >>>> cellular. This could be >> a >>>> sequential use of interfaces (only one interface is used >>>> exclusively), as opposed to simultaneous use of interfaces. >>>> >>>> The architecture aspect in this is the difference between >>>> simultaneous vs sequential use of interfaces. This could be >>>> illustrated with pictures of topology. >>>> >>>> This is something very complex to deal with. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ mif mailing >>>> list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif >>> >>> >> ______________________________________________________________________ >>> >> >> >> >> ___________________________________________________ >>> >>> >>> >>> >> 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, France Telecom - >>> 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, France >>> Telecom - Orange is not liable for messages that have been >>> modified, changed or falsified. Thank you. >>> >>> >>> >> > > > _________________________________________________________________________________________________________________________ > > > > > 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, France Telecom - 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, France > Telecom - Orange is not liable for messages that have been modified, > changed or falsified. Thank you. > > > From alexandru.petrescu@gmail.com Tue Mar 19 08:38:03 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3821F8DA2 for ; Tue, 19 Mar 2013 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NrSor3sUTDg for ; Tue, 19 Mar 2013 08:38:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 51B1821F8D60 for ; Tue, 19 Mar 2013 08:38:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r2JFc1L3021783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 16:38:01 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2JFc0XN027209; Tue, 19 Mar 2013 16:38:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2JFc0OR010267; Tue, 19 Mar 2013 16:38:00 +0100 Message-ID: <51488631.3000400@gmail.com> Date: Tue, 19 Mar 2013 16:37:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51487747.20506@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775114E93@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775114E93@mbx-01.win.nominum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:38:03 -0000 Le 19/03/2013 16:10, Ted Lemon a écrit : > On Mar 19, 2013, at 10:33 AM, Alexandru Petrescu > wrote: >>> Except the problem of access discovery and selection, I'm not >>> sure there are multiple provisioning domains issues with >>> sequential use of interfaces. >> >> I am not sure either. > > My take on this, for what it's worth, is that the work MIF is doing > will be useful, but not central, to what you are trying to do. MIF > is focusing on what happens when all the interfaces are on at the > same time, but we also want to enable the provision sufficient > functionality that you can set up a connection manager that makes > choices about which interfaces to keep alive when. > > I am not _convinced_ that we need to do a lot of work in that > space—we may be able to leverage work that IEEE has already done, for > example, in which case our job would be filling in the gaps that IEEE > has not already addressed, or getting IEEE to do it, whichever makes > the most sense. > > But the point is that I think you should probably be interested in > what MIF is doing, but I suspect that the work MIF is doing is not > crucial to the work you are doing. I agree. I am interested in what MIF is doing. Alex > > > From denghui@chinamobile.com Wed Mar 20 00:15:11 2013 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F121F89AE for ; Wed, 20 Mar 2013 00:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTvdG2IKp6LD for ; Wed, 20 Mar 2013 00:15:10 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 2385C21F8970 for ; Wed, 20 Mar 2013 00:15:09 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee1514961dd600-7b600; Wed, 20 Mar 2013 15:14:38 +0800 (CST) X-RM-TRANSID: 2ee1514961dd600-7b600 Received: from cmccPC (unknown[10.2.43.176]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3514961dbc68-71c1a; Wed, 20 Mar 2013 15:14:37 +0800 (CST) X-RM-TRANSID: 2ee3514961dbc68-71c1a From: "Hui Deng" To: "'Alexandru Petrescu'" , References: <8C48B86A895913448548E6D15DA7553B7D7894@xmb-rcd-x09.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077510F9D3@mbx-01.win.nominum.com> <51451E98.1020007@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775110D54@mbx-01.win.nominum.com> <51472B79.9030809@gmail.com> <22538_1363684433_51482C51_22538_54_1_81C77F07008CA24F9783A98CFD706F710B4285@PEXCVZYM12.corporate.adroot.infra.ftgroup> <51487747.20506@gmail.com> <17520_1363705410_51487E42_17520_10_1_81C77F07008CA24F9783A98CFD706F710B4676@PEXCVZYM12.corporate.adroot.infra.ftgroup> <514885F5.4030603@gmail.com> In-Reply-To: <514885F5.4030603@gmail.com> Date: Wed, 20 Mar 2013 15:14:58 +0800 Message-ID: <007d01ce253a$a1d8e480$e58aad80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4kt5bs3fvfxzg2Sqiz/0ZIWCHaIAAgjfAA Content-Language: zh-cn Cc: mif@ietf.org Subject: Re: [mif] Call for volunteers about architecture design X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 07:15:11 -0000 For sequential use of interfaces, I guess mobile IP is not the only = solution, today most internet application has figured out how to do = session continuity without mobile ip support. http://datatracker.ietf.org/doc/draft-deng-mif-api-session-continuity-gui= de/ -Hui -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of = Alexandru Petrescu Sent: Tuesday, March 19, 2013 11:36 PM To: pierrick.seite@orange.com Cc: Subject: Re: [mif] Call for volunteers about architecture design Le 19/03/2013 16:03, pierrick.seite@orange.com a =C3=A9crit : > Ok, so, being more generic than MIP, the problem is about simultaneous = > usage (not sequential) of physical and virtual interfaces, on a single = > physical interface. I agree in this sense. (to me 'simultaneous use' is when we say simultaneous use for bandwidth = augmentation. Distinct HAroute and defroute - what we discuss above - = is a method to do mobility registration at the same time as traffic, but = does not offer bandwidth augmentation.) For the pure use of interfaces in a sequential manner, I dont see = anything else than a Mobile IP problem, which is solved, as you say. > This problem is identified in MIF problem statement. Ok. Alex > > Pierrick >> -----Message d'origine----- De : Alexandru Petrescu=20 >> [mailto:alexandru.petrescu@gmail.com] Envoy=C3=A9 : mardi 19 mars = 2013 >> 15:34 =C3=80 : SEITE Pierrick OLNC/OLN Cc : Ted Lemon; = >> Objet : Re: [mif] Call for volunteers about architecture design >> >> Le 19/03/2013 10:13, pierrick.seite@orange.com a =C3=A9crit : >>> Hi Alex, >>> >>> Except the problem of access discovery and selection, I'm not sure=20 >>> there are multiple provisioning domains issues with sequential use=20 >>> of interfaces. >> >> I am not sure either. >> >> If continuous sessions are needed after a handover WiFi-3G (each is=20 >> in a different provisioning domain), then Mobile IP should be used;=20 >> if Mobile IP is used then there is a routing problem at the initial=20 >> setup phase (the default route points to a tunnel interface but the=20 >> HA should be reached with a host-specific route on the real=20 >> interface). >> >> There could be advice from HA to mobile to tell it how to set up that = >> route (use one the real interface for reaching HA and the tunnel=20 >> interface for all other traffic). This advice is just another kind=20 >> of advice that should be taken with precaution. >> >> Or there could be a visual interface on the terminal to set manually=20 >> the default route and other specific routes. (was already said). >> >> Alex >> >> >>> This is something we can do with current terminal... Maybe I'm wrong = >>> but, anyway, I guess the architecture work will start with=20 >>> discussion on use-cases to identify what is relevant or not. >>> >>> Pierrick >>> >>>> -----Message d'origine----- De : mif-bounces@ietf.org=20 >>>> [mailto:mif-bounces@ietf.org] De la part de Alexandru Petrescu >> Envoy=C3=A9 >>>> : lundi 18 mars 2013 15:58 =C3=80 : Ted Lemon Cc : = Objet=20 >>>> : Re: [mif] Call for volunteers about architecture design >>>> >>>> Le 17/03/2013 12:51, Ted Lemon a =C3=A9crit : >>>>> On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu=20 >>>>> wrote: >>>>>> This kind of problem - make one virtual interface to link all >> other >>>>>> interfaces together, with goals such as bandwidth augmentation,=20 >>>>>> on a Mobile Router (not a Host) - is discussed in the ITS=20 >>>>>> Intelligent Transportation Systems email list=20 >>>>>> ietf.org/mailman/listinfo/its >>>>>> >>>>>> (this is one problem being considered there, but there are other=20 >>>>>> ITS problems considered there. And there there is thought that >> MIF >>>>>> may consider this case - it seems not.) >>>>> >>>>> I think we should definitely consider this problem in the >>>>> architecture discussion. Whether it's in-scope or out of >>>>> scope is another question. >>>> >>>> In addition to simultaneous use of multiple interfaces for=20 >>>> bandwidth augmentation on a low-ratio egress-ingress bandwidth=20 >>>> Mobile Router (its egress bandwith is much lower than ingress=20 >>>> bandwidth), >>>> >>>> there is another aspect which deserves mentioning in a mif'ed >>>> Host: the use of Mobile IP and handovers. This would be such that=20 >>>> a Host to offer highly available connections - when WiFi is=20 >>>> available use WiFi, but if cellular is available then use cellular. = >>>> This could be >> a >>>> sequential use of interfaces (only one interface is used=20 >>>> exclusively), as opposed to simultaneous use of interfaces. >>>> >>>> The architecture aspect in this is the difference between=20 >>>> simultaneous vs sequential use of interfaces. This could be=20 >>>> illustrated with pictures of topology. >>>> >>>> This is something very complex to deal with. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ mif mailing list=20 >>>> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif >>> >>> >> _____________________________________________________________________ >> _ >>> >> >> >> >> ___________________________________________________ >>> >>> >>> >>> >> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>> etant susceptibles d'alteration, France Telecom - Orange decline=20 >>> toute responsabilite si ce message a ete altere, deforme ou=20 >>> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not = >>> be distributed, used or copied without authorisation. If you have=20 >>> received this email in error, please notify the sender and delete >> this >>> message and its attachments. As emails may be altered, France=20 >>> Telecom - Orange is not liable for messages that have been modified, = =20 >>> changed or falsified. Thank you. >>> >>> >>> >> > > > ______________________________________________________________________ > ___________________________________________________ > > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. > Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. If you have=20 > received this email in error, please notify the sender and delete this = > message and its attachments. As emails may be altered, France Telecom=20 > - Orange is not liable for messages that have been modified, changed=20 > or falsified. Thank you. > > > _______________________________________________ mif mailing list mif@ietf.org https://w