From marcelo@it.uc3m.es Wed Jul 1 05:45:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F8328C64A; Wed, 1 Jul 2009 05:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huDAh3zCYV-m; Wed, 1 Jul 2009 05:45:13 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 81D3E28C5C9; Wed, 1 Jul 2009 05:31:04 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id EBBD7C0E0; Wed, 1 Jul 2009 14:31:10 +0200 (CEST) Message-ID: <4A4B570E.5090301@it.uc3m.es> Date: Wed, 01 Jul 2009 14:31:10 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4A4A3BD3.1040703@it.uc3m.es> <4D35478224365146822AE9E3AD4A266609E3BF87$0001@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609E3BF87$0001@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.007 Cc: netext@ietf.org, netlmm@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 12:45:14 -0000 Koodli, Rajeev escribió: > >>> >>> >> right, what are the required functions that are provided by a >> network based mobility that are lacking in a host based >> mobility approach? >> > > As a starting point, the host is not involved in mobility management > (aka, managing persistence and reachability). > right, this is what i was asking So, i think this can be defined in terms of what is in control of the network, correct? So, would it make sense to define this as a requirement that it must be network that decides through wich interface the node sends traffic In particular, it is the network side that decides: - when the node performs a handoff to the other interface - how the traffic is distributed among interfaces - which flow flows through each interface Is that what you have in mind? Regards, marcelo > What we are looking at here is not to change the mobility management > model (i.e., host does not know anything about mobility at L3), but to > consider MN - Network (MAG) interactions which *may* need L3 extensions. > > Regards, > > -Rajeev > > > >> Regards, marcelo >> >> >> >>> -Raj >>> >>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > > > This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. > > From kevin.noll@twcable.com Wed Jul 1 06:53:22 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE9D3A6F37; Wed, 1 Jul 2009 06:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.447 X-Spam-Level: X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_PRODUCT=0.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y01CBnN6f5X; Wed, 1 Jul 2009 06:53:21 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id 2CAFC3A683E; Wed, 1 Jul 2009 06:53:21 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,323,1243828800"; d="scan'208";a="429152974" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 01 Jul 2009 09:52:10 -0400 Received: from PRVPVSMAIL07.corp.twcable.com ([10.157.247.203]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 09:52:09 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Jul 2009 09:52:08 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description thread-index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYqABMlAnA= References: From: "Noll, Kevin" To: , X-OriginalArrivalTime: 01 Jul 2009 13:52:09.0757 (UTC) FILETIME=[20E04CD0:01C9FA53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 13:53:22 -0000 SSd2ZSBiZWVuIGx1cmtpbmcgaGVyZSBmb3IgYSB3aGlsZSB3YXRjaGluZyB0aGUgY29udmVyc2F0 aW9uLiBQbGVhc2UKYWNjZXB0IG15IGFwb2xvZ2llcyBmb3IgZHJvcHBpbmcgaW4gdW5leHBlY3Rl ZGx5LCBidXQgSSB0aG91Z2h0IEkgbWlnaHQKZ2l2ZSBhdCBsZWFzdCBvbmUgb3BlcmF0b3IncyB2 aWV3cG9pbnQuCgpZb3UgYXJlIGNvcnJlY3QgdGhhdCBtb3N0IGRhdGEgY2FyZHMgYmVpbmcgc29s ZCB0b2RheSByZXF1aXJlIHlvdSB0bwppbnN0YWxsIHRoZSBjYXJyaWVyJ3Mgc29mdHdhcmUuIFRo aXMgc29mdHdhcmUgdHlwaWNhbGx5IGNvbnRhaW5zIGEKY29ubmVjdGlvbiBtYW5hZ2VyIGFuZCB0 aGUgT1MgZHJpdmVycyByZXF1aXJlZCB0byBvcGVyYXRlIHRoZSBkYXRhIGNhcmQuClRlY2huaWNh bGx5IHNwZWFraW5nLCB0aGUgZGF0YSBjYXJkcyB0aGF0IEkgaGF2ZSB3b3JrZWQgd2l0aCBkbyBu b3QgYWxsCipyZXF1aXJlKiB0aGUgY29ubmVjdGlvbiBtYW5hZ2VyIHRvIG9wZXJhdGUsIHRob3Vn aCBpdCB2YXJpZXMgZnJvbSBjYXJkCnRvIGNhcmQuIE9idmlvdXNseSwgdGhvdWdoLCB0aGV5ICpk byogbmVlZCB0aGUgZHJpdmVycy4KCldoYXQgd2Ugc2F3IHdpdGggV2lGaSB3YXMgYSB0ZWNobm9s b2d5IHRoYXQgYmVnYW4gYXMgYW4gYWRkLW9uIHRvIG91cgpjb21wdXRpbmcgZGV2aWNlcyAobGFw dG9wcywgZXRjLikuIFdpRmkgZ3JldywgbWF0dXJlZCwgYW5kIGJlY2FtZSBzbwp3aWRlbHkgYWNj ZXB0ZWQgdGhhdCBvcGVyYXRpbmcgc3lzdGVtcyBiZWdhbiB0byBzaGlwIHdpdGggbmF0aXZlCmRy aXZlcnMsIHRoZSBhZGQtb24gZGV2aWNlIGJlY2FtZSBpbnRlZ3JhdGVkIGludG8gdGhlIGNvbXB1 dGluZyBkZXZpY2VzCmFuZCB3ZSBubyBsb25nZXIgbmVlZGVkIHRvIGluc3RhbGwgM3JkLXBhcnR5 IGRyaXZlcnMgb3IgY29ubmVjdGlvbgpzb2Z0d2FyZS4KCkFzIGEgbmV0d29yayBwcm92aWRlci9v cGVyYXRvciwgd2UgbGlrZSB0aGlzIG1vZGVsIGJlY2F1c2UgaXQgaXMgdmVyeQpleHBlbnNpdmUg dG8gd3JpdGUgYW5kIG1haW50YWluIHRoZSBjb25uZWN0aW9uIHNvZnR3YXJlIGFuZCBkcml2ZXJz IGFuZAprZWVwIHRoZSB1c2VyJ3MgZGV2aWNlIHVwIHRvIGRhdGUuIEFkZGluZyBhIG1vYmlsaXR5 IHN0YWNrIHRvIHRoZQpzb2Z0d2FyZSBiZWluZyBpbnN0YWxsZWQgYWRkcyBzaWduaWZpY2FudGx5 IHRvIHRoaXMgY29zdC4gV2UgYXJlIHNlZWluZwp0aGUgY29zdCBjb21lIGRvd24sIGJ1dCB0aGVy ZSdzIHN0aWxsIHRoZSBpc3N1ZSBvZiBjb25maWd1cmF0aW9uIGFuZAp3aGF0LW5vdC4KCldlIGV4 cGVjdCB0byBzZWUgb3BlbiBuZXR3b3JrcyBhbmQgdGVjaG5vbG9naWVzIGxpa2UgV2lNQVggKGFu ZCBwb3NzaWJseQpMVEUpIGNoYW5nZSB0aGUgdHJhZGl0aW9uYWwgY2VsbHVsYXIgZGF0YS1jYXJk IG1vZGVsIHRvIG9uZSB0aGF0IGlzIG1vcmUKc2ltaWxhciB0byBXaUZpLCBob3BlZnVsbHkgZHJp dmluZyBkb3duIHRoZSBjb3N0IG9mIHRoZSBzb2Z0d2FyZSBhbmQKbW92aW5nIHRoZSBzb2Z0d2Fy ZSBkZXZlbG9wbWVudCB0YXNrcyBvdXQgb2YgdGhlIG9wZXJhdG9yIGFuZCBpbnRvIHRoZQpPUyB2 ZW5kb3IgY29tbXVuaXR5LgoKVGhpcyBzYWlkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgbWlzdGFr ZSB0byBtYWtlIGFueSBhc3N1bXB0aW9ucyBvbgplaXRoZXIgb2YgdGhlIHR3byBwb2ludHMgbWVu dGlvbmVkIGJlbG93LiAKCjEuIEluIHRoZSBmdXR1cmUgdGhlIGNhcnJpZXIgbWF5IG5vdCBkZWxp dmVyIHNvZnR3YXJlIHdpdGggdGhlIGRhdGEKY2FyZCwgc28gaXQncyBwcm9iYWJseSBhIGJhZCBh c3N1bXB0aW9uIHRvIHNheSB0aGF0IHRoZSBjYXJyaWVyIHdvdWxkCnNpbXBseSBkZWxpdmVyIGEg bW9iaWxpdHkgc3RhY2sgd2l0aCB0aGUgZGV2aWNlLgoKMi4gSXQncyBwcm9iYWJseSBhIGdvb2Qg YXNzdW1wdGlvbiB0byBzYXkgdGhhdCBkZXZpY2VzIHdpbGwgZXZlbnR1YWxseQpoYXZlIG5hdGl2 ZSBtb2JpbGl0eSBzdGFja3MuIFdlIGFyZSBhbHJlYWR5IHNlZWluZyB0aGlzIGRldmVsb3BtZW50 IGluCm1haW5zdHJlYW0gb3BlcmF0aW5nIHN5c3RlbXMuIFRoaXMgaXMgc2ltaWxhciB0byB0aGUg ZXZvbHV0aW9uIG9mIFdpRmkuCgozLiBJdCdzIHByb2JhYmx5IG5vdCBhIGdvb2QgYXNzdW1wdGlv biB0byBzYXkgdGhhdCAqYWxsKiBkZXZpY2VzIHdpbGwKaGF2ZSB0aGUgcGVyZmVjdCBjb21iaW5h dGlvbiBvZiBuYXRpdmUgc3VwcG9ydCBvciBjYXJyaWVyIHN1cHBvcnQuCgo0LiBBdCBsZWFzdCBz b21lIGNhcnJpZXJzIHByZWZlciB0byBtYW5hZ2UgbW9iaWxpdHkgaW5zaWRlIHRoZSBuZXR3b3Jr CnJhdGhlciB0aGFuIG9uIHRoZSBjdXN0b21lciBkZXZpY2UuIFRoaXMgaXMgc29tZXRoaW5nIHRo YXQgd2UgYXJlCmNvbnN0YW50bHkgZGlzY3Vzc2luZyBpbnRlcm5hbCB0byBvdXIgb3JnYW5pemF0 aW9uLCB3aXRoIHZlbmRvcnMsIGFuZAp3aXRoIG90aGVyIG9wZXJhdG9ycy4KCkJhc2VkIG9uIHRo aXMsIHRoZSBjYXNlIGZvciBleHRlbmRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgUE1JUDYgaXMK cHJldHR5IHN0cm9uZywgYXQgbGVhc3QgaW4gbXkgb3Bpbmlvbi4gCgpPbiB0aGUgb3RoZXIgaGFu ZCwgd2Ugd2lsbCBhbHNvIGNvbnRpbnVlIGZvbGxvd2luZyB0aGUgZGV2ZWxvcG1lbnQgb2YKbmF0 aXZlIHN0YWNrcyBhbmQgZXZhbHVhdGUgd2hlbiBhbmQgaG93IGJlc3QgdG8gdXNlIHRoZW0gaW4g b3VyIHByb2R1Y3QKb2ZmZXJpbmdzLiBTaW1pbGFybHksIHdlIHdpbGwgY29udGludWUgdG8gZXZh bHVhdGUgd2hldGhlciBvciBub3Qgd2UKbmVlZCB0byBkZWxpdmVyIGEgbW9iaWxpdHkgc3RhY2sg d2l0aCBvdXIgZGF0YSBjYXJkIHNvZnR3YXJlLgoKVGhhbmtzIQoKLS1rYW4tLQotLQpLZXZpbiBB LiBOb2xsCgoKClAgR28gR3JlZW4hIFByaW50IHRoaXMgZW1haWwgb25seSB3aGVuIG5lY2Vzc2Fy eS4gVGhhbmsgeW91IGZvciBoZWxwaW5nIFRpbWUgV2FybmVyIENhYmxlIGJlIGVudmlyb25tZW50 YWxseSByZXNwb25zaWJsZS4KIAogCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IG5l dGxtbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0bG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZgpPZiBIZXNoYW0gU29saW1hbgpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDA5IDEx OjU5IFBNClRvOiBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tOyBtYXJjZWxvQGl0LnVjM20uZXMK Q2M6IG5ldGV4dEBpZXRmLm9yZzsgbmV0bG1tQGlldGYub3JnClN1YmplY3Q6IFJlOiBbbmV0bG1t XSBbTUVYVF0gW25ldGV4dF0gTkVYVEVYVDI6IGZpcnN0IGRyYWZ0IG9mIHRoZSBib2YKZGVzY3Jp cHRpb24KCgpIaSBSYWosIAoKSSBoYWQgYSBicmllZiBvZmZsaW5lIGNoYXQgd2l0aCBKdWxpZW4g YW5kIHRob3VnaHQgdGhhdCBJIGNvdWxkIHJlZmluZQpteQpzdWdnZXN0aW9uIGEgYml0IG1vcmUg dG8gbWFrZSB0aGUgcG9pbnQgY2xlYXJlci4gTXkgcG9pbnQgaXMgdGhhdCB0aGVyZQphcmUKY3Vy cmVudGx5IHR3byBzbGlnaHRseSBkaWZmZXJlbnQgcG9pbnRzIGJlaW5nIG1hZGUgYWJvdXQgdGhl IHJlcXVpcmVtZW50Cm9uCmhvc3QgaW52b2x2ZW1lbnQgMSkgbm8gU1cgb24gdGhlIGhvc3QgYW5k IHRoZSBtb3JlIG51YW5jZWQgMikgbm8KcHJvdG9jb2wKc3VwcG9ydCBvbiB0aGUgaG9zdC4gSSB3 b24ndCBldmVuIGdldCBpbnRvIHRoZSByZWFzb25zIGZvciBwb2ludCAyKQphYm92ZQphbmQgSSds bCBsZXQgdGhlIHBlb3BsZSB3aG8gcmFpc2UgaXQgcHJvdmlkZSB0aG9zZSByZWFzb25zLCBJIGNh bid0CmZpZ3VyZQpvdXQgYW55IHRlY2huaWNhbCByZWFzb25zIHRoZXJlLgoKQW55d2F5LCBteSBw b2ludCBpcyB0aGF0IDEpIGFib3ZlIGlzIG5vdCBhbiBpc3N1ZSB0b2RheSBiZWNhdXNlIGl0CmFs cmVhZHkKaGFwcGVucyBvbiBhIHZlcnkgbGFyZ2Ugc2NhbGUsIHNvIHJlcXVpcmluZyBpdCBmb3Ig YSBzcGVjaWZpYyBmZWF0dXJlCmxpa2UKbXVsdGlob21pbmcgaXMgaGFyZGx5IGEgbGVhcC4gSSBj YW4gaW1hZ2luZSBhZHMgZm9yICJkb3dubG9hZCB5b3VyCndpcmVsZXNzCm9wdGltaXNlciBmcm9t IHd3d3cub3BlcmF0b3IuY29tIGFuZCBzYXZlIG1vbmV5IiAob2sgbm90IHZlcnkgY3JlYXRpdmUp LgpUaGUgc3VidGxlIGRpZmZlcmVuY2UgYmV0d2VlbiAxKSBhbmQgMikgaXMgSU1PIGEgbW9vdCBw b2ludCBhbnl3YXkKYmVjYXVzZQoyKSBzaW1wbHkgc2F5cyB0aGF0IG9wZXJhdG9ycyBkb24ndCB3 YW50IHByb3RvY29sIHN1cHBvcnQgaW4gdGhlCm5ldHdvcmssCmJ1dCB0aGF0IHN1cHBvcnQgYWxy ZWFkeSBleGlzdHMgaW4gdGhlIGZvcm0gb2YgUE1JUCBhbmQgaWYgeW91IGhhdmUgUE1JUAp5b3UK aGF2ZSBNSVAuIFNvLCBib3RoIG1vdGl2YXRpb25zIHNlZW0gdG8gYmUgb24gc2hha3kgZ3JvdW5k LgpBbmQgeWVzLCB5b3UgY2FuIG9mIGNvdXJzZSBpbnRlZ3JhdGUgM0cgbW9kZW1zIGluIGNvbXB1 dGVycywgYnV0IHlvdSBjYW4KYWxzbyBpbnRlZ3JhdGUgbW9iaWxpdHkgY29kZSBpbiB0aGUgc2Ft ZSBjb21wdXRlcnMgd2l0aCB0aGUgM0cgc3VwcG9ydC4KVGhlClNXIHRoYXQgaXMgcHJvdmlkZWQg d2l0aCB0aGUgbW9kZW1zIGlzIG5vdCBvbmx5IGNvbm5lY3Rpb24gU1cgaXQKYWN0dWFsbHkKcHJv dmlkZXMgYSBudW1iZXIgb2YgZmVhdHVyZXMgKGUuZy4gUmVjZWl2aW5nIFNNUywgYWNjb3VudCBp bmZvcm1hdGlvbiwKZW1haWwgLi4uLmV0Yykgc28gaXQncyBhIGNsZWFyIG1vdmUgYnkgb3BlcmF0 b3JzIHRvIGJlIHByZXNlbnQgb24gdGhvc2UKbWFjaGluZXMuIEkgZG9uJ3QgdGhpbmsgaXQncyBh bnl0aGluZyBsaWtlIFdMQU4gY29ubmN0aW9ucyBTVy4KCk9mIGNvdXJzZSBpdCdzIHdvcnRoIG1l bnRpb25pbmcgdGhhdCB0aGUgZWxlcGhhbnQgaW4gdGhlIHJvb20gaXMgdGhlCmJpbmFyeQpyZXF1 aXJlbWVudCBvbiBob3N0IHN1cHBvcnQgb2YgcHJvdG9jb2xzLiBXZSBuZWVkIHRvIGhhdmUgYSB5 ZXMvbm8KYW5zd2VyIGFzCnRvIHdoZXRoZXIgdGhlcmUgaXMgYSByZXF1aXJlbWVudCB0byBOT1Qg aGF2ZSBwcm90b2NvbCBzdXBwb3J0IGluIHRoZQpob3N0LgpBdCB0aGUgbW9tZW50IHRoaXMgaXMg YmVpbmcga2VwdCB2ZXJ5IHZhZ3VlLgoKSGVzaGFtCgo+PiA9PiBObyBvbmUgSSBrbm93IGNhbiBn ZXQgYSAzRyBkYXRhIGNhcmQgdG8gYWNjZXNzIHRoZSBJbnRlcm5ldCBmcm9tCnRoZWlyIFBDCj4+ IHdpdGhvdXQgaGF2aW5nIHRvIGluc3RhbGwgYSBwaWVjZSBvZiBzb2Z0d2FyZSAgb24gdGhlaXIg UEMgdG8gbWFrZSBpdAp3b3JrLgo+PiBTbyBJIHRoaW5rIHlvdXIgYXNzdW1wdGlvbiB0aGF0IHRo ZSBvcGVyYXRvciBjYW5ub3QgbWFuZGF0ZSBzb2Z0d2FyZQpvbiB0aGUKPj4gaG9zdCBpcyBxdWVz dGlvbmFibGUsIGJlY2F1c2UgdGhleSBhbHJlYWR5IGRvICh1bmZvcnR1bmF0ZWx5KS4KPiAKPiBU aGUgc2l0dWF0aW9uIHRoYXQgeW91IGRlc2NyaWJlIGFib3ZlIHdhcyB0aGUgc2FtZSB3aGVuIDgw Mi4xMSBmaXJzdApyb2xsZWQKPiBhcm91bmQgYXMgd2VsbC4KPiBZb3UgaGFkIHRvIGluc3RhbGwg YSBwaWVjZSBvZiBzb2Z0d2FyZSB0aGF0IGNhbWUgd2l0aCB0aGUgUEMgY2FyZC4gQnV0CnRoYXQK PiBoYXMgY2hhbmdlZCB3aXRoIAo+IHdpZmkgbm93IGJlaW5nIGFuIGludGVncmFsIHBhcnQgb2Yg dGhlIG5vdGVib29rIGNvbXB1dGVycy4KPiBBbmQgSSB0aGluayB5b3UgY291bGQgZXhwZWN0IDNH IGNoaXBzZXRzIGFuZCBhY2Nlc3MgYnVpbHQtaW4gYXMgd2VsbAppbiBkdWUKPiBjb3Vyc2Ugb2Yg dGltZS4gQXQgbGVhc3QgSSBrbm93IG9mIGEgZmV3Cj4gb3BlcmF0b3JzIGluIHRoZSBVUyAoYXMg d2VsbCBhcyBub3RlYm9vayBtYW51ZmFjdHVyZXJzKSB3aG8gb2ZmZXIgc3VjaAo+IG5ldC9ub3Rl Ym9vayBjb21wdXRlcnMsCj4gaS5lIHdpdGggaW50ZWdyYXRlZCAzRyBhY2Nlc3MuIEkgZG8gbm90 IGtub3cgd2hhdCBhZGRpdGlvbmFsIHN3IGlzCmxvYWRlZCBvbgo+IHRoZXNlIGJ1dCBhdCBsZWFz dCB0aGUgZW5kIHVzZXIKPiBpcyBub3QgaW5zdGFsbGluZyBhbnl0aGluZyBlbHNlLgo+IERvZXMg aXQgaW1wbHkgdGhhdCBzdWNoIGhvc3RzIHdpbGwgaW5jbHVkZSB0aGUgc29mdHdhcmUgdGhhdCB3 b3VsZAplbmFibGUgaG9zdAo+IG1vYmlsaXR5PyBJdHMgYW4gb3BlbiBxdWVzdGlvbiAoaS5lIHVu a25vd24pCj4gYW5kIHdpbGwgZGVwZW5kIGxhcmdlbHkgb24gb3BlcmF0b3IgY2hvaWNlcyBhbmQg dmVuZG9ycy4KPiAKPiAtUmFqCj4gCj4+IEhlc2hhbQo+IAo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bG1tIG1haWxpbmcgbGlzdAo+IG5ldGxt bUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bG1t CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bG1t IG1haWxpbmcgbGlzdApuZXRsbW1AaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRsbW0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIKQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwKb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbAppcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0 IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzCkUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwKZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8g dGhlIGNvbnRlbnRzCm9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUKdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5CnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueQpjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuCg== From marcelo@it.uc3m.es Wed Jul 1 07:31:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6756A28C569; Wed, 1 Jul 2009 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJDfK5qAHBbG; Wed, 1 Jul 2009 07:31:50 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 974D328C583; Wed, 1 Jul 2009 07:31:20 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 88CC7BA5086; Wed, 1 Jul 2009 14:32:11 +0200 (CEST) Message-ID: <4A4B574B.6020902@it.uc3m.es> Date: Wed, 01 Jul 2009 14:32:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sri Gundavelli References: <4A4A3BD3.1040703@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16736.007 Cc: netext@ietf.org, netlmm@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:32:23 -0000 Sri Gundavelli escribió: > Hi Marcelo, > > > On Tue, 30 Jun 2009, marcelo bagnulo braun wrote: > >>> >> so what is the assumption requiremnent here? >> Is the requriemnent that the solution must work wihtout requiring any >> host support? Or is there some level of host support that is >> acceptble? If so, why? (i mena, why some level of host support is >> accpetbale and other is not) >> >> > > The requirement is to have that intelligence on the network for > supporting > these features, while allowing the mobile node to only express > preferences > on network attachment/multihoming or flow mobility. Right, i think this can be expresserd as a requirement. please see the email i have just sent to Rajeev regards, marcelo > he participation of > the client will be to minimal proportions. The goal is to have a simple > client, with a minimal software component such as for managing these > aspects and not require an extensive set of protocol stacks. > > > >>> 2. An operator may choose to deploy a network with only network based >>> mobility protocol support >>> >>> >> right, what are the required functions that are provided by a network >> based mobility that are lacking in a host based mobility approach? >> > > I'm not sure, if we want to compare the missing features and say they > will be available in host mobility protocols and so we go that route. > We could have said that even before we standardized network-based > mobility approaches. But, there is interest to support network-based > mobility protocols and so we need to ensure we do that job completly. > > Industry has accepted network-based mobility approaches in the form of > GTP/PMIPv6. We have to add the missing features and support that > accepted model completly. This is about completing the work. > > Regards > Sri > > > > >> Regards, marcelo >> >> >>> -Raj >>> >>> >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > From marcelo@it.uc3m.es Wed Jul 1 08:12:32 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83863A6F2D for ; Wed, 1 Jul 2009 08:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOlyTDsiUO5R for ; Wed, 1 Jul 2009 08:12:32 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1B3AD3A694D for ; Wed, 1 Jul 2009 08:12:31 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id DE8F765584A for ; Wed, 1 Jul 2009 17:12:45 +0200 (CEST) Message-ID: <4A4B7CED.5090909@it.uc3m.es> Date: Wed, 01 Jul 2009 17:12:45 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.000 Subject: [netext] Questions for defining the NETEXT2 problem space X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:12:33 -0000 Hi, After the discussion so far, i have identified the following question for which i think it would be important to provide answer to define the requirements of the problems we are trying to tackle. As stated earlier, the goal of this questions is to try to define the "what are we trying to achieve?" question. Once we have a set of answers, we will need to do the "Why?" part. So, this is work in progress, but i woudl appreciate input in terms of modificatiosn to the questions, answers to the questions and more questions. Questions: 1)- What L2 technologies are supported? All the L2 technologies? A subset of L2 technologies? 2)- What changes are acceptable in the MN? Options include: No host changes. Only configuration required in the host. New code is acceptable, but no protocol changes (the motivation for this could include to interop with other devices already using the existent protocol) Protocol extensions are acceptable. 3)- What capabilities need to be controlled by the network? When the MN performs a handover from one interface to another one? How the node distributes the load among interfaces? in which direction? Which flow is routed through which interface? in which direction? Hope this helps... regards, marcelo From tsirtsis@googlemail.com Wed Jul 1 08:31:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C434C3A69FB; Wed, 1 Jul 2009 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vu02L1tXJsf; Wed, 1 Jul 2009 08:31:43 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 19E753A67AF; Wed, 1 Jul 2009 08:31:42 -0700 (PDT) Received: by bwz25 with SMTP id 25so598767bwz.37 for ; Wed, 01 Jul 2009 08:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ba3aHgU9LJ6DonOyjtuBllZLLAjvV4oA1UMH132LT1k=; b=hQ2dXoBuHd9X0G4fA1DcetbX47/eqlleyY3U5P6yz7Z+Y/+yU7pRV1B9XsyhVPvhXh cXua/ilOz4NCVPPKjxr0y8/xSzVbpw8Il/qdAq/Y1sF2uZdLyEbEQWwZAk1eIwjGu81D PpplDEYiSM9Z+kY/qo7yc6nW2jzkCJmMHPuKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V95GL6XbmaAcMBH0sprnMR9DxHiH+oJPIkoRJeazHOsFL/52jdY9fxOd/cDcedn9yN wqIpTqgPjSXNteU5xubGg/gT5MXCFOhGGrAJK4RXcokfQoinzC2MO55Nfi7fm1NAUres XEHvzCGX2pbrqFUQ1rOKJFONC9LEAslu7RYew= MIME-Version: 1.0 Received: by 10.223.114.135 with SMTP id e7mr6243817faq.89.1246462289290; Wed, 01 Jul 2009 08:31:29 -0700 (PDT) In-Reply-To: References: <4A4A3BD3.1040703@it.uc3m.es> Date: Wed, 1 Jul 2009 16:31:28 +0100 Message-ID: From: George Tsirtsis To: Sri Gundavelli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, netlmm@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:31:44 -0000 Sri, just one question below... On Tue, Jun 30, 2009 at 6:33 PM, Sri Gundavelli wrote: > Hi George, > > > On Tue, 30 Jun 2009, George Tsirtsis wrote: > >> Hey Sri, >> >> So let me see if I understand. >> You think that the MN will only have to signal during network >> attachment, so, essentially out-of-band from PMIP perspective; is that >> correct? > > They can be =C2=A0out-of-band from PMIP perspective, but act as triggers = to > PMIP signaling. > > >> I assume by network attachment you mean on a per technology basis? >> i.e., when WiFi IF attached to a given network, and when a 3G IF >> attaches it signals again? >> > > Yes. When the mobile attaches to the network over a given interface, > it can identify the type of attachment (Handoff from Int-X, New > Attachment). It can be on a per-interface basis, on every attach event. > > Lets take this example of host with 3G and WiFI interafaces. Possible > scenarios: > > Host initially attaches over WiFI a.) Later brings up 3G interface for > multihoming > b.) or, performs an handoff to 3G > > Host attaches through 3G and Wifi interfaces and performs > an handoff from multihoming to single attach. > a.) WiFI b.) 3G > > In all these cases, I need the host to be able to suggest the > following: > > Event-1: NEW ATTACHMENT, Interface Type: WiFI, IfId: 1 > Event-2: HANDOFF, FROM: 3G, IfIf:2 =C2=A0 TO: WiFI, IfId: 1 > > Do I need more extensive attach preferences ? > > >> If yes, then what kind of network attachment signalling do you intend >> to define in the IETF? =C2=A0Could you elaborate a bit, keeping in mind >> that network attachment is typically an L2 process (except PANA I >> guess?)? >> > > Its too early to discuss the semantics of the signaling. Its at a L2 > layer or L3-layer ... that leads to the solution discussion. I'm sure, > we can have detailed discussions on the semantics. > GT> Sri, the protocol details (e.g., message format, semantics etc) is indeed solution space. Whether this an L2 vs L3 protocol, however, must be relevant to whether this work happens in the IETF or somewhere else, don't you think so? Don't you think that this decision needs to be taken before such work goes ahead in the IETF? >> Also, if you only signal during attachment; does it mean that >> multi-homing feature in PMIP will ONLY apply to different technologies >> (i.e., you exclude multihoming on the same technology)? >> > > I dont follow completly. > > Between multihoming and inter-tech handoff, we need the host to be > able to specify if a given attachment is as a result of bringup of > a new interface (simultaneous attach) or a result of a handoff. The > host and the network has the complete view of the hosts attachment > over all its interfaces. So, not sure why the multihoming features > will appear only across technologies. > GT> OK, so if two IFs of the same technology connect to the network, they will both have to go through the attach procedures you are talking about. > Regards > Sri > > > >> Thanks >> >> On Tue, Jun 30, 2009 at 5:36 PM, Sri Gundavelli wrot= e: >>> >>> Hi Marcelo, >>> >>> >>> On Tue, 30 Jun 2009, marcelo bagnulo braun wrote: >>> >>>>> >>>> so what is the assumption requiremnent here? >>>> Is the requriemnent that the solution must work wihtout requiring any >>>> host >>>> support? Or is there some level of host support that is acceptble? If >>>> so, >>>> why? (i mena, why some level of host support is accpetbale and other i= s >>>> not) >>>> >>>> >>> >>> The requirement is to have that intelligence on the network for >>> supporting >>> these features, while allowing the mobile node to only express >>> preferences >>> on network attachment/multihoming or flow mobility. The participation o= f >>> the client will be to minimal proportions. The goal is to have a simple >>> client, with a minimal software component such as for managing these >>> aspects and not require an extensive set of protocol stacks. >>> >>> >>> >>>>> =C2=A02. An operator may choose to deploy a network with only network= based >>>>> =C2=A0mobility protocol support >>>>> >>>>> >>>> right, what are the required functions that are provided by a network >>>> based mobility that are lacking in a host based mobility approach? >>>> >>> >>> I'm not sure, if we want to compare the missing features and say they >>> will be available in host mobility protocols and so we go that route. >>> We could have said that even before we standardized network-based >>> mobility approaches. But, there is interest to support network-based >>> mobility protocols and so we need to ensure we do that job completly. >>> >>> Industry has accepted network-based mobility approaches in the form of >>> GTP/PMIPv6. We have to add the missing features and support that >>> accepted model completly. This is about completing the work. >>> >>> Regards >>> Sri >>> >>> >>> >>> >>>> Regards, marcelo >>>> >>>> >>>>> =C2=A0-Raj >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> > From kevin.noll@twcable.com Wed Jul 1 08:46:42 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9793C3A6F43 for ; Wed, 1 Jul 2009 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIEqk68mm-Ht for ; Wed, 1 Jul 2009 08:46:41 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 52AFE3A67AF for ; Wed, 1 Jul 2009 08:46:41 -0700 (PDT) X-SENDER-IP: 10.157.247.211 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,324,1243828800"; d="scan'208";a="428292855" Received: from unknown (HELO prvpmailconn1.corp.twcable.com) ([10.157.247.211]) by pblpas02.twcable.com with ESMTP; 01 Jul 2009 11:40:00 -0400 Received: from PRVPVSMAIL07.corp.twcable.com ([10.157.247.203]) by prvpmailconn1.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 11:39:59 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Jul 2009 11:39:59 -0400 Message-ID: In-Reply-To: <925933.41309.qm@web111401.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description thread-index: Acn6Xo2xh19BdUUXQU+6fTh8MhtA8AAAXOyg References: <925933.41309.qm@web111401.mail.gq1.yahoo.com> From: "Noll, Kevin" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 01 Jul 2009 15:39:59.0778 (UTC) FILETIME=[314F2820:01C9FA62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:46:42 -0000 ClBlcmhhcHMgSSBkaWRuJ3QgY2F0Y2ggdGhlIHdob2xlIGludGVudCBvZiB0aGUgZGlzY3Vzc2lv biwgYnV0IEkgYW0gYXNzdW1pbmcgdGhhdCB0aGVyZSBpcyAqbm8qIGNsaWVudCBzb2Z0d2FyZSBv ciBzdGFjayByZXF1aXJlbWVudCB0byBzdXBwb3J0IFBNSVA2IG9yIGFueSBvZiBpdHMgZXh0ZW5z aW9ucy4KCklmIHRoZXJlIHdlcmUgZXh0ZW5zaW9ucyB0byBQTUlQNiB0aGF0IHJlcXVpcmVkIGNs aWVudCBzb2Z0d2FyZSBjaGFuZ2VzLCB0aGVuIHdlIG1pZ2h0IGFzIHdlbGwgaW5zdGFsbCBhIGNv bXBsZXRlIE1JUDYgc3RhY2suIE9uIHRoZSBvdGhlciBoYW5kLCBJIGNhbiBzZWUgc2NlbmFyaW9z IHdoZXJlIHdlIG1pZ2h0IHdhbnQgc29tZSBmdW5jdGlvbmFsaXR5IG9uIHRoZSBjbGllbnQgdG8g aGVscCBtYWtlIEhPIGRlY2lzaW9ucyBvciBpbXByb3ZlIHRoZSBlZmZpY2llbmN5IG9mIGEgSE8s IGJ1dCBub3Qgd2FudCBhIGNvbXBsZXRlIElQIG1vYmlsaXR5IHN0YWNrLiBUaGlzIHNlY29uZCBz Y2VuYXJpbyBzZWVtcyB0byBzdWdnZXN0IHVzaW5nIGV4dGVuc2lvbnMgYmFzZWQgb24gc29tZXRo aW5nIGxpa2UgTUlILgoKQmFzZWQgb24gdGhpcyAob25seSBzb21lIGJyaWVmIHRob3VnaHQgZ2l2 ZW4gdG8gaXQpLCBwZXJoYXBzIGFuIGFwcHJvYWNoIHdvdWxkIGJlIHRvIHNwZWNpZnkgdGhlIGFi aWxpdHkgZm9yIGEgUE1JUDYgY2xpZW50IChub3QgdGhlIE1OLCBidXQgdGhlIG5ldHdvcmsgZWxl bWVudCkgdG8gY29udmVyc2Ugd2l0aCBhbiBNSUggY2xpZW50IGFuZC9vciBzZXJ2ZXIuIFRoaXMg Y291bGQgYXZvaWQgdGhlIG5lZWQgdG8gKnJlcXVpcmUqIHNvbWV0aGluZyBvbiB0aGUgTU4sIGJ1 dCB0YWtlIGFkdmFudGFnZSBvZiBpdCB3aGVuIGl0IGlzIGF2YWlsYWJsZS4KCi0ta2FuLS0KLS0K S2V2aW4gQS4gTm9sbAoKCgpQIEdvIEdyZWVuISBQcmludCB0aGlzIGVtYWlsIG9ubHkgd2hlbiBu ZWNlc3NhcnkuIFRoYW5rIHlvdSBmb3IgaGVscGluZyBUaW1lIFdhcm5lciBDYWJsZSBiZSBlbnZp cm9ubWVudGFsbHkgcmVzcG9uc2libGUuCiAKIAotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpG cm9tOiBCZWhjZXQgU2FyaWtheWEgW21haWx0bzpiZWhjZXRzYXJpa2F5YUB5YWhvby5jb21dIApT ZW50OiBXZWRuZXNkYXksIEp1bHkgMDEsIDIwMDkgMTE6MTQgQU0KVG86IE5vbGwsIEtldmluOyBu ZXRleHRAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtuZXRsbW1dIFtNRVhUXSBbbmV0ZXh0XSBORVhU RVhUMjogZmlyc3QgZHJhZnQgb2YgdGhlIGJvZiBkZXNjcmlwdGlvbgoKCkhpIEtldmluLAogIE5p Y2UgdG8gaGVhciBmcm9tIHlvdSEKCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tCj4gRnJv bTogIk5vbGwsIEtldmluIiA8a2V2aW4ubm9sbEB0d2NhYmxlLmNvbT4KPiBUbzogbmV0ZXh0QGll dGYub3JnOyBuZXRsbW1AaWV0Zi5vcmcKPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMSwgMjAwOSA4 OjUyOjA4IEFNCj4gU3ViamVjdDogUmU6IFtuZXRsbW1dIFtNRVhUXSBbbmV0ZXh0XSBORVhURVhU MjogZmlyc3QgZHJhZnQgb2YgdGhlIGJvZiBkZXNjcmlwdGlvbgo+IAo+IEkndmUgYmVlbiBsdXJr aW5nIGhlcmUgZm9yIGEgd2hpbGUgd2F0Y2hpbmcgdGhlIGNvbnZlcnNhdGlvbi4gUGxlYXNlCj4g YWNjZXB0IG15IGFwb2xvZ2llcyBmb3IgZHJvcHBpbmcgaW4gdW5leHBlY3RlZGx5LCBidXQgSSB0 aG91Z2h0IEkgbWlnaHQKPiBnaXZlIGF0IGxlYXN0IG9uZSBvcGVyYXRvcidzIHZpZXdwb2ludC4K PiAKPiBZb3UgYXJlIGNvcnJlY3QgdGhhdCBtb3N0IGRhdGEgY2FyZHMgYmVpbmcgc29sZCB0b2Rh eSByZXF1aXJlIHlvdSB0bwo+IGluc3RhbGwgdGhlIGNhcnJpZXIncyBzb2Z0d2FyZS4gVGhpcyBz b2Z0d2FyZSB0eXBpY2FsbHkgY29udGFpbnMgYQo+IGNvbm5lY3Rpb24gbWFuYWdlciBhbmQgdGhl IE9TIGRyaXZlcnMgcmVxdWlyZWQgdG8gb3BlcmF0ZSB0aGUgZGF0YSBjYXJkLgo+IFRlY2huaWNh bGx5IHNwZWFraW5nLCB0aGUgZGF0YSBjYXJkcyB0aGF0IEkgaGF2ZSB3b3JrZWQgd2l0aCBkbyBu b3QgYWxsCj4gKnJlcXVpcmUqIHRoZSBjb25uZWN0aW9uIG1hbmFnZXIgdG8gb3BlcmF0ZSwgdGhv dWdoIGl0IHZhcmllcyBmcm9tIGNhcmQKPiB0byBjYXJkLiBPYnZpb3VzbHksIHRob3VnaCwgdGhl eSAqZG8qIG5lZWQgdGhlIGRyaXZlcnMuCj4gCj4gV2hhdCB3ZSBzYXcgd2l0aCBXaUZpIHdhcyBh IHRlY2hub2xvZ3kgdGhhdCBiZWdhbiBhcyBhbiBhZGQtb24gdG8gb3VyCj4gY29tcHV0aW5nIGRl dmljZXMgKGxhcHRvcHMsIGV0Yy4pLiBXaUZpIGdyZXcsIG1hdHVyZWQsIGFuZCBiZWNhbWUgc28K PiB3aWRlbHkgYWNjZXB0ZWQgdGhhdCBvcGVyYXRpbmcgc3lzdGVtcyBiZWdhbiB0byBzaGlwIHdp dGggbmF0aXZlCj4gZHJpdmVycywgdGhlIGFkZC1vbiBkZXZpY2UgYmVjYW1lIGludGVncmF0ZWQg aW50byB0aGUgY29tcHV0aW5nIGRldmljZXMKPiBhbmQgd2Ugbm8gbG9uZ2VyIG5lZWRlZCB0byBp bnN0YWxsIDNyZC1wYXJ0eSBkcml2ZXJzIG9yIGNvbm5lY3Rpb24KPiBzb2Z0d2FyZS4KPiAKPiBB cyBhIG5ldHdvcmsgcHJvdmlkZXIvb3BlcmF0b3IsIHdlIGxpa2UgdGhpcyBtb2RlbCBiZWNhdXNl IGl0IGlzIHZlcnkKPiBleHBlbnNpdmUgdG8gd3JpdGUgYW5kIG1haW50YWluIHRoZSBjb25uZWN0 aW9uIHNvZnR3YXJlIGFuZCBkcml2ZXJzIGFuZAo+IGtlZXAgdGhlIHVzZXIncyBkZXZpY2UgdXAg dG8gZGF0ZS4gQWRkaW5nIGEgbW9iaWxpdHkgc3RhY2sgdG8gdGhlCj4gc29mdHdhcmUgYmVpbmcg aW5zdGFsbGVkIGFkZHMgc2lnbmlmaWNhbnRseSB0byB0aGlzIGNvc3QuIFdlIGFyZSBzZWVpbmcK PiB0aGUgY29zdCBjb21lIGRvd24sIGJ1dCB0aGVyZSdzIHN0aWxsIHRoZSBpc3N1ZSBvZiBjb25m aWd1cmF0aW9uIGFuZAo+IHdoYXQtbm90Lgo+IAo+IFdlIGV4cGVjdCB0byBzZWUgb3BlbiBuZXR3 b3JrcyBhbmQgdGVjaG5vbG9naWVzIGxpa2UgV2lNQVggKGFuZCBwb3NzaWJseQo+IExURSkgY2hh bmdlIHRoZSB0cmFkaXRpb25hbCBjZWxsdWxhciBkYXRhLWNhcmQgbW9kZWwgdG8gb25lIHRoYXQg aXMgbW9yZQo+IHNpbWlsYXIgdG8gV2lGaSwgaG9wZWZ1bGx5IGRyaXZpbmcgZG93biB0aGUgY29z dCBvZiB0aGUgc29mdHdhcmUgYW5kCj4gbW92aW5nIHRoZSBzb2Z0d2FyZSBkZXZlbG9wbWVudCB0 YXNrcyBvdXQgb2YgdGhlIG9wZXJhdG9yIGFuZCBpbnRvIHRoZQo+IE9TIHZlbmRvciBjb21tdW5p dHkuCj4gCj4gVGhpcyBzYWlkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgbWlzdGFrZSB0byBtYWtl IGFueSBhc3N1bXB0aW9ucyBvbgo+IGVpdGhlciBvZiB0aGUgdHdvIHBvaW50cyBtZW50aW9uZWQg YmVsb3cuIAo+IAo+IDEuIEluIHRoZSBmdXR1cmUgdGhlIGNhcnJpZXIgbWF5IG5vdCBkZWxpdmVy IHNvZnR3YXJlIHdpdGggdGhlIGRhdGEKPiBjYXJkLCBzbyBpdCdzIHByb2JhYmx5IGEgYmFkIGFz c3VtcHRpb24gdG8gc2F5IHRoYXQgdGhlIGNhcnJpZXIgd291bGQKPiBzaW1wbHkgZGVsaXZlciBh IG1vYmlsaXR5IHN0YWNrIHdpdGggdGhlIGRldmljZS4KPiAKPiAyLiBJdCdzIHByb2JhYmx5IGEg Z29vZCBhc3N1bXB0aW9uIHRvIHNheSB0aGF0IGRldmljZXMgd2lsbCBldmVudHVhbGx5Cj4gaGF2 ZSBuYXRpdmUgbW9iaWxpdHkgc3RhY2tzLiBXZSBhcmUgYWxyZWFkeSBzZWVpbmcgdGhpcyBkZXZl bG9wbWVudCBpbgo+IG1haW5zdHJlYW0gb3BlcmF0aW5nIHN5c3RlbXMuIFRoaXMgaXMgc2ltaWxh ciB0byB0aGUgZXZvbHV0aW9uIG9mIFdpRmkuCj4gCj4gMy4gSXQncyBwcm9iYWJseSBub3QgYSBn b29kIGFzc3VtcHRpb24gdG8gc2F5IHRoYXQgKmFsbCogZGV2aWNlcyB3aWxsCj4gaGF2ZSB0aGUg cGVyZmVjdCBjb21iaW5hdGlvbiBvZiBuYXRpdmUgc3VwcG9ydCBvciBjYXJyaWVyIHN1cHBvcnQu Cj4gCj4gNC4gQXQgbGVhc3Qgc29tZSBjYXJyaWVycyBwcmVmZXIgdG8gbWFuYWdlIG1vYmlsaXR5 IGluc2lkZSB0aGUgbmV0d29yawo+IHJhdGhlciB0aGFuIG9uIHRoZSBjdXN0b21lciBkZXZpY2Uu IFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgd2UgYXJlCj4gY29uc3RhbnRseSBkaXNjdXNzaW5nIGlu dGVybmFsIHRvIG91ciBvcmdhbml6YXRpb24sIHdpdGggdmVuZG9ycywgYW5kCj4gd2l0aCBvdGhl ciBvcGVyYXRvcnMuCj4gCj4gQmFzZWQgb24gdGhpcywgdGhlIGNhc2UgZm9yIGV4dGVuZGluZyB0 aGUgZnVuY3Rpb25hbGl0eSBvZiBQTUlQNiBpcwo+IHByZXR0eSBzdHJvbmcsIGF0IGxlYXN0IGlu IG15IG9waW5pb24uIAoKQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgZXh0ZW5kZWQgZnVuY3Rpb25h bGl0eSBmb3IgUE1JUHY2ICBjYW4gYmUgZG93bmxvYWRlZCB3aXRoIHRoZSBkZXZpY2UgZHJpdmVy LCBvciBpbiB0aGUgZnV0dXJlIGl0IHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIE9TPwoKQ2FuIHlv dSBwbGVhc2UgZWxhYm9yYXRlIG9uIHRoaXMgYXMgdGhpcyBpcyB0aGUgbW9zdCByZWxldmFudCB0 byB0aGUgY3VycmVudCBkaXNjdXNzaW9uPyBXaHkgbm90IHRoZW4gc29tZSBvdGhlciB0aGluZ3Mg bGlrZSBNSVA2IGNsaWVudD8KClJlZ2FyZHMsCgpCZWhjZXQKCgogICAgICAKClRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyCkNhYmxl IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRp YWwsCm9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJs ZS4gVGhpcyBFLW1haWwKaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aGljaAppdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcwpFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sCmRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cwpvZiBhbmQgYXR0YWNobWVu dHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlCnVubGF3 ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeQp0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9y aWdpbmFsIGFuZCBhbnkKY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lgo= From behcetsarikaya@yahoo.com Wed Jul 1 08:51:52 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9F03A6F44 for ; Wed, 1 Jul 2009 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiZB-JX7Gv8U for ; Wed, 1 Jul 2009 08:51:51 -0700 (PDT) Received: from n79.bullet.mail.sp1.yahoo.com (n79.bullet.mail.sp1.yahoo.com [98.136.44.39]) by core3.amsl.com (Postfix) with SMTP id 0B1C43A6A12 for ; Wed, 1 Jul 2009 08:51:51 -0700 (PDT) Received: from [69.147.84.145] by n79.bullet.mail.sp1.yahoo.com with NNFMP; 01 Jul 2009 15:51:22 -0000 Received: from [67.195.9.83] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 01 Jul 2009 15:51:22 -0000 Received: from [67.195.9.105] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 15:51:22 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 15:51:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566259.7475.bm@omp109.mail.gq1.yahoo.com Received: (qmail 60662 invoked by uid 60001); 1 Jul 2009 15:51:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246463482; bh=Di9aXCQ/KYt1RrTQ2cXQeyfHo4tQ2uP4xHZO8ZDEBVc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1gMhksWVdTzt9FPPIgXlmmFZS33omOvW4uUKGbwUN39Pw5DU8Mp7LZC0IVHMvfb7yJ/8bCndypcxRbXtHYKJfJEh6Yl+07S+2/PnYWEKaWfhh178JiPTOircPT4pYZHQ+L5s8MQIpPgnquDLglUP2F/NeW4oSici+9P8oJc2YqQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HQq79L1Tse1MOJHO8JVdqekSSmkuRQDCBJKZKNpP5S/aF5xfI4jEjiZYht0ZUqymsWyYNeJNThvM17CGizWSKSkpnHN3aaCU0bWgt/avH5xnuAWWOk1oNOmFCK4D1UNgURqFDhS/fd0/Z6i2KKdTwqz6oebpPQIo//YniOty3tA=; Message-ID: <354857.60222.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: mI9EINcVM1nlP2_B6._n7EcQEhp06rISiSv7BpBCOWKh8rIDqkH7qBfe_GSKgSUU1jqD__2CB7_xPdd66RdmPGt0ea9roMK.l9xzr42bNU2GnlmZnj8TKPheBjNasnUoeBVgGvpl07ljEkbMglW5f.owwoE3KPQLTYVDGaTLnOQqM1DJeltebi5oXJqO9Vk.6MpYO8_XK73Y96fAHlYKKAf6clcmMvqO7.cwf4dRvz80sHzoTetWKUZO6VeyfwMB_J5wBtzUmvO15x_7npsoA2OCha2v4MUIN0HRTpkc1VD9uqbh1z2mHEuslFPDhq3mEB9pvP2AoVEv3m6Q5mnvjRk- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Wed, 01 Jul 2009 08:51:22 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <925933.41309.qm@web111401.mail.gq1.yahoo.com> Date: Wed, 1 Jul 2009 08:51:22 -0700 (PDT) From: Behcet Sarikaya To: "Noll, Kevin" , Behcet Sarikaya , netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:51:52 -0000 I don't see any enthusiasm on MIH anywhere.=0AI think the current discussio= n is around additional functionality for HO. I think PMIP supporters will a= rgue that this can be done in IETF and the opponents will argue that that i= s L2 and thus not an IETF issue.=0A=0AMy post to netext ML didn't go throug= h, anyways it is OK to exhange ideas with you. We can go to the list if you= like.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A>= From: "Noll, Kevin" =0A> To: Behcet Sarikaya ; netext@ietf.org=0A> Sent: Wednesday, July 1, 2009 10:39:59 = AM=0A> Subject: RE: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the b= of description=0A> =0A> =0A> Perhaps I didn't catch the whole intent of the= discussion, but I am assuming =0A> that there is *no* client software or s= tack requirement to support PMIP6 or any =0A> of its extensions.=0A> =0A> I= f there were extensions to PMIP6 that required client software changes, the= n we =0A> might as well install a complete MIP6 stack. On the other hand, I= can see =0A> scenarios where we might want some functionality on the clien= t to help make HO =0A> decisions or improve the efficiency of a HO, but not= want a complete IP mobility =0A> stack. This second scenario seems to sugg= est using extensions based on something =0A> like MIH.=0A> =0A> Based on th= is (only some brief thought given to it), perhaps an approach would =0A> be= to specify the ability for a PMIP6 client (not the MN, but the network =0A= > element) to converse with an MIH client and/or server. This could avoid t= he need =0A> to *require* something on the MN, but take advantage of it whe= n it is available.=0A> =0A> --kan--=0A> --=0A> Kevin A. Noll=0A> =0A> =0A> = =0A> P Go Green! Print this email only when necessary. Thank you for helpin= g Time =0A> Warner Cable be environmentally responsible.=0A> =0A> =0A> ----= -Original Message-----=0A> From: Behcet Sarikaya [mailto:behcetsarikaya@yah= oo.com] =0A> Sent: Wednesday, July 01, 2009 11:14 AM=0A> To: Noll, Kevin; n= etext@ietf.org=0A> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first dr= aft of the bof =0A> description=0A> =0A> =0A> Hi Kevin,=0A> =A0 Nice to hea= r from you!=0A> =0A> =0A> =0A> ----- Original Message ----=0A> > From: "Nol= l, Kevin" =0A> > To: netext@ietf.org; netlmm@ietf.org=0A> > Sent: Wednesday= , July 1, 2009 8:52:08 AM=0A> > Subject: Re: [netlmm] [MEXT] [netext] NEXTE= XT2: first draft of the bof =0A> description=0A> > =0A> > I've been lurking= here for a while watching the conversation. Please=0A> > accept my apologi= es for dropping in unexpectedly, but I thought I might=0A> > give at least = one operator's viewpoint.=0A> > =0A> > You are correct that most data cards= being sold today require you to=0A> > install the carrier's software. This= software typically contains a=0A> > connection manager and the OS drivers = required to operate the data card.=0A> > Technically speaking, the data car= ds that I have worked with do not all=0A> > *require* the connection manage= r to operate, though it varies from card=0A> > to card. Obviously, though, = they *do* need the drivers.=0A> > =0A> > What we saw with WiFi was a techno= logy that began as an add-on to our=0A> > computing devices (laptops, etc.)= .. WiFi grew, matured, and became so=0A> > widely accepted that operating sy= stems began to ship with native=0A> > drivers, the add-on device became int= egrated into the computing devices=0A> > and we no longer needed to install= 3rd-party drivers or connection=0A> > software.=0A> > =0A> > As a network = provider/operator, we like this model because it is very=0A> > expensive to= write and maintain the connection software and drivers and=0A> > keep the = user's device up to date. Adding a mobility stack to the=0A> > software bei= ng installed adds significantly to this cost. We are seeing=0A> > the cost = come down, but there's still the issue of configuration and=0A> > what-not.= =0A> > =0A> > We expect to see open networks and technologies like WiMAX (a= nd possibly=0A> > LTE) change the traditional cellular data-card model to o= ne that is more=0A> > similar to WiFi, hopefully driving down the cost of t= he software and=0A> > moving the software development tasks out of the oper= ator and into the=0A> > OS vendor community.=0A> > =0A> > This said, I thin= k it would be a mistake to make any assumptions on=0A> > either of the two = points mentioned below. =0A> > =0A> > 1. In the future the carrier may not = deliver software with the data=0A> > card, so it's probably a bad assumptio= n to say that the carrier would=0A> > simply deliver a mobility stack with = the device.=0A> > =0A> > 2. It's probably a good assumption to say that dev= ices will eventually=0A> > have native mobility stacks. We are already seei= ng this development in=0A> > mainstream operating systems. This is similar = to the evolution of WiFi.=0A> > =0A> > 3. It's probably not a good assumpti= on to say that *all* devices will=0A> > have the perfect combination of nat= ive support or carrier support.=0A> > =0A> > 4. At least some carriers pref= er to manage mobility inside the network=0A> > rather than on the customer = device. This is something that we are=0A> > constantly discussing internal = to our organization, with vendors, and=0A> > with other operators.=0A> > = =0A> > Based on this, the case for extending the functionality of PMIP6 is= =0A> > pretty strong, at least in my opinion. =0A> =0A> Are you saying that= the extended functionality for PMIPv6=A0 can be downloaded =0A> with the d= evice driver, or in the future it will be included in the OS?=0A> =0A> Can = you please elaborate on this as this is the most relevant to the current = =0A> discussion? Why not then some other things like MIP6 client?=0A> =0A> = Regards,=0A> =0A> Behcet=0A> =0A> =0A> =A0 =A0 =A0 =0A> =0A> This E-mail an= d any of its attachments may contain Time Warner=0A> Cable proprietary info= rmation, which is privileged, confidential,=0A> or subject to copyright bel= onging to Time Warner Cable. This E-mail=0A> is intended solely for the use= of the individual or entity to which=0A> it is addressed. If you are not t= he intended recipient of this=0A> E-mail, you are hereby notified that any = dissemination,=0A> distribution, copying, or action taken in relation to th= e contents=0A> of and attachments to this E-mail is strictly prohibited and= may be=0A> unlawful. If you have received this E-mail in error, please not= ify=0A> the sender immediately and permanently delete the original and any= =0A> copy of this E-mail and any printout.=0A=0A=0A=0A From kevin.noll@twcable.com Wed Jul 1 08:53:17 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7943A6A12 for ; Wed, 1 Jul 2009 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upk2rfZ9ScZ5 for ; Wed, 1 Jul 2009 08:53:17 -0700 (PDT) Received: from pblpas01.twcable.com (pblpas01.twcable.com [204.235.121.149]) by core3.amsl.com (Postfix) with ESMTP id B71643A69FD for ; Wed, 1 Jul 2009 08:53:16 -0700 (PDT) X-SENDER-IP: 10.157.247.213 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,324,1243828800"; d="scan'208";a="429206628" Received: from unknown (HELO prvpmailconn3.corp.twcable.com) ([10.157.247.213]) by pblpas01.twcable.com with ESMTP; 01 Jul 2009 11:53:02 -0400 Received: from PRVPVSMAIL07.corp.twcable.com ([10.157.247.203]) by prvpmailconn3.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 11:53:01 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Jul 2009 11:53:01 -0400 Message-ID: In-Reply-To: <925933.41309.qm@web111401.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description thread-index: Acn6Xo2xh19BdUUXQU+6fTh8MhtA8AABB1EQ References: <925933.41309.qm@web111401.mail.gq1.yahoo.com> From: "Noll, Kevin" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 01 Jul 2009 15:53:01.0976 (UTC) FILETIME=[03891980:01C9FA64] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:53:18 -0000 CkJlaGNldCwgSSBkaWRuJ3QgYW5zd2VyIHlvdXIgcXVlc3Rpb24gaW4gbXkgcHJldmlvdXMgZS1t YWlsLgoKSSBiZWxpZXZlIHRoZXJlIGFyZSBmYWN0b3JzIG91dHNpZGUgb2Ygb3VyIGNvbnRyb2wg dGhhdCB3aWxsIGRldGVybWluZSB3aGV0aGVyIHRoZXNlIGV4dGVuc2lvbnMgd2lsbCBiZSBpbmNs dWRlZCBpbiB0aGUgT1MuIFRoZXNlIGFyZSB0aGluZ3MgbGlrZSBtYXJrZXQgYWNjZXB0YW5jZSwg d2lkZXNwcmVhZCBkZXBsb3ltZW50LCBldGMuIAoKSXQgaXMgcmVhc29uYWJsZSB0byB0aGluayB0 aGF0IGxpZ2h0d2VpZ2h0IGV4dGVuc2lvbnMgY291bGQgYmUgaW5jbHVkZWQgaW4gZGF0YS1jYXJk IGRyaXZlcnMsIHdoZXRoZXIgdGhleSBhcmUgcHJvdmlkZWQgYnkgdGhlIGNhcnJpZXIsIGJ5IGFu IE9FTSwgb3Igc29tZW9uZSBlbHNlLgoKSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgdGhhdCBpZiB0 aGlzIHNvbHV0aW9uIGlzIGFuIElQLWJhc2VkIHNvbHV0aW9uLCB0aGUgZXh0ZW5zaW9ucyBtYXkg YmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIHR5cGljYWwgT1MtbGV2ZWwgZHJpdmVyIGltcGxl bWVudGF0aW9uLiBCYXNlZCBvbiB0aGlzLCB5b3UgbWF5IHNlZSB0aGF0IHlvdSBhcmUgZm9yY2Vk IGludG8gYSBzY2VuYXJpbyB0aGF0IHJlcXVpcmVzIGFuIGFjdHVhbCBzdGFjayBtb2RpZmljYXRp b24uIEkgZG91YnQgdGhpcyB3b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBhIGNhcnJpZXIgd291bGQg d2FudCB0byBzdXBwb3J0IHVubGVzcyB0aGVyZSBpcyBhIHNpZ25pZmljYW50IGVjb25vbWljLCBv cGVyYXRpb25hbCwgb3IgdXNlci1leHBlcmllbmNlIGFkdmFudGFnZS4gSW5zdGVhZCwgdGhleSB3 b3VsZCByYXRoZXIgbm90IHVzZSBpdCBhdCBhbGwsIG9yIHVzZSB3aGF0IGlzIG5hdGl2ZWx5IGF2 YWlsYWJsZSBpbiB0aGUgT1MuCgotLWthbi0tCi0tCktldmluIEEuIE5vbGwKCgoKUCBHbyBHcmVl biEgUHJpbnQgdGhpcyBlbWFpbCBvbmx5IHdoZW4gbmVjZXNzYXJ5LiBUaGFuayB5b3UgZm9yIGhl bHBpbmcgVGltZSBXYXJuZXIgQ2FibGUgYmUgZW52aXJvbm1lbnRhbGx5IHJlc3BvbnNpYmxlLgog CiAKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogQmVoY2V0IFNhcmlrYXlhIFttYWls dG86YmVoY2V0c2FyaWtheWFAeWFob28uY29tXSAKU2VudDogV2VkbmVzZGF5LCBKdWx5IDAxLCAy MDA5IDExOjE0IEFNClRvOiBOb2xsLCBLZXZpbjsgbmV0ZXh0QGlldGYub3JnClN1YmplY3Q6IFJl OiBbbmV0bG1tXSBbTUVYVF0gW25ldGV4dF0gTkVYVEVYVDI6IGZpcnN0IGRyYWZ0IG9mIHRoZSBi b2YgZGVzY3JpcHRpb24KCgpIaSBLZXZpbiwKICBOaWNlIHRvIGhlYXIgZnJvbSB5b3UhCgoKCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLQo+IEZyb206ICJOb2xsLCBLZXZpbiIgPGtldmluLm5v bGxAdHdjYWJsZS5jb20+Cj4gVG86IG5ldGV4dEBpZXRmLm9yZzsgbmV0bG1tQGlldGYub3JnCj4g U2VudDogV2VkbmVzZGF5LCBKdWx5IDEsIDIwMDkgODo1MjowOCBBTQo+IFN1YmplY3Q6IFJlOiBb bmV0bG1tXSBbTUVYVF0gW25ldGV4dF0gTkVYVEVYVDI6IGZpcnN0IGRyYWZ0IG9mIHRoZSBib2Yg ZGVzY3JpcHRpb24KPiAKPiBJJ3ZlIGJlZW4gbHVya2luZyBoZXJlIGZvciBhIHdoaWxlIHdhdGNo aW5nIHRoZSBjb252ZXJzYXRpb24uIFBsZWFzZQo+IGFjY2VwdCBteSBhcG9sb2dpZXMgZm9yIGRy b3BwaW5nIGluIHVuZXhwZWN0ZWRseSwgYnV0IEkgdGhvdWdodCBJIG1pZ2h0Cj4gZ2l2ZSBhdCBs ZWFzdCBvbmUgb3BlcmF0b3IncyB2aWV3cG9pbnQuCj4gCj4gWW91IGFyZSBjb3JyZWN0IHRoYXQg bW9zdCBkYXRhIGNhcmRzIGJlaW5nIHNvbGQgdG9kYXkgcmVxdWlyZSB5b3UgdG8KPiBpbnN0YWxs IHRoZSBjYXJyaWVyJ3Mgc29mdHdhcmUuIFRoaXMgc29mdHdhcmUgdHlwaWNhbGx5IGNvbnRhaW5z IGEKPiBjb25uZWN0aW9uIG1hbmFnZXIgYW5kIHRoZSBPUyBkcml2ZXJzIHJlcXVpcmVkIHRvIG9w ZXJhdGUgdGhlIGRhdGEgY2FyZC4KPiBUZWNobmljYWxseSBzcGVha2luZywgdGhlIGRhdGEgY2Fy ZHMgdGhhdCBJIGhhdmUgd29ya2VkIHdpdGggZG8gbm90IGFsbAo+ICpyZXF1aXJlKiB0aGUgY29u bmVjdGlvbiBtYW5hZ2VyIHRvIG9wZXJhdGUsIHRob3VnaCBpdCB2YXJpZXMgZnJvbSBjYXJkCj4g dG8gY2FyZC4gT2J2aW91c2x5LCB0aG91Z2gsIHRoZXkgKmRvKiBuZWVkIHRoZSBkcml2ZXJzLgo+ IAo+IFdoYXQgd2Ugc2F3IHdpdGggV2lGaSB3YXMgYSB0ZWNobm9sb2d5IHRoYXQgYmVnYW4gYXMg YW4gYWRkLW9uIHRvIG91cgo+IGNvbXB1dGluZyBkZXZpY2VzIChsYXB0b3BzLCBldGMuKS4gV2lG aSBncmV3LCBtYXR1cmVkLCBhbmQgYmVjYW1lIHNvCj4gd2lkZWx5IGFjY2VwdGVkIHRoYXQgb3Bl cmF0aW5nIHN5c3RlbXMgYmVnYW4gdG8gc2hpcCB3aXRoIG5hdGl2ZQo+IGRyaXZlcnMsIHRoZSBh ZGQtb24gZGV2aWNlIGJlY2FtZSBpbnRlZ3JhdGVkIGludG8gdGhlIGNvbXB1dGluZyBkZXZpY2Vz Cj4gYW5kIHdlIG5vIGxvbmdlciBuZWVkZWQgdG8gaW5zdGFsbCAzcmQtcGFydHkgZHJpdmVycyBv ciBjb25uZWN0aW9uCj4gc29mdHdhcmUuCj4gCj4gQXMgYSBuZXR3b3JrIHByb3ZpZGVyL29wZXJh dG9yLCB3ZSBsaWtlIHRoaXMgbW9kZWwgYmVjYXVzZSBpdCBpcyB2ZXJ5Cj4gZXhwZW5zaXZlIHRv IHdyaXRlIGFuZCBtYWludGFpbiB0aGUgY29ubmVjdGlvbiBzb2Z0d2FyZSBhbmQgZHJpdmVycyBh bmQKPiBrZWVwIHRoZSB1c2VyJ3MgZGV2aWNlIHVwIHRvIGRhdGUuIEFkZGluZyBhIG1vYmlsaXR5 IHN0YWNrIHRvIHRoZQo+IHNvZnR3YXJlIGJlaW5nIGluc3RhbGxlZCBhZGRzIHNpZ25pZmljYW50 bHkgdG8gdGhpcyBjb3N0LiBXZSBhcmUgc2VlaW5nCj4gdGhlIGNvc3QgY29tZSBkb3duLCBidXQg dGhlcmUncyBzdGlsbCB0aGUgaXNzdWUgb2YgY29uZmlndXJhdGlvbiBhbmQKPiB3aGF0LW5vdC4K PiAKPiBXZSBleHBlY3QgdG8gc2VlIG9wZW4gbmV0d29ya3MgYW5kIHRlY2hub2xvZ2llcyBsaWtl IFdpTUFYIChhbmQgcG9zc2libHkKPiBMVEUpIGNoYW5nZSB0aGUgdHJhZGl0aW9uYWwgY2VsbHVs YXIgZGF0YS1jYXJkIG1vZGVsIHRvIG9uZSB0aGF0IGlzIG1vcmUKPiBzaW1pbGFyIHRvIFdpRmks IGhvcGVmdWxseSBkcml2aW5nIGRvd24gdGhlIGNvc3Qgb2YgdGhlIHNvZnR3YXJlIGFuZAo+IG1v dmluZyB0aGUgc29mdHdhcmUgZGV2ZWxvcG1lbnQgdGFza3Mgb3V0IG9mIHRoZSBvcGVyYXRvciBh bmQgaW50byB0aGUKPiBPUyB2ZW5kb3IgY29tbXVuaXR5Lgo+IAo+IFRoaXMgc2FpZCwgSSB0aGlu ayBpdCB3b3VsZCBiZSBhIG1pc3Rha2UgdG8gbWFrZSBhbnkgYXNzdW1wdGlvbnMgb24KPiBlaXRo ZXIgb2YgdGhlIHR3byBwb2ludHMgbWVudGlvbmVkIGJlbG93LiAKPiAKPiAxLiBJbiB0aGUgZnV0 dXJlIHRoZSBjYXJyaWVyIG1heSBub3QgZGVsaXZlciBzb2Z0d2FyZSB3aXRoIHRoZSBkYXRhCj4g Y2FyZCwgc28gaXQncyBwcm9iYWJseSBhIGJhZCBhc3N1bXB0aW9uIHRvIHNheSB0aGF0IHRoZSBj YXJyaWVyIHdvdWxkCj4gc2ltcGx5IGRlbGl2ZXIgYSBtb2JpbGl0eSBzdGFjayB3aXRoIHRoZSBk ZXZpY2UuCj4gCj4gMi4gSXQncyBwcm9iYWJseSBhIGdvb2QgYXNzdW1wdGlvbiB0byBzYXkgdGhh dCBkZXZpY2VzIHdpbGwgZXZlbnR1YWxseQo+IGhhdmUgbmF0aXZlIG1vYmlsaXR5IHN0YWNrcy4g V2UgYXJlIGFscmVhZHkgc2VlaW5nIHRoaXMgZGV2ZWxvcG1lbnQgaW4KPiBtYWluc3RyZWFtIG9w ZXJhdGluZyBzeXN0ZW1zLiBUaGlzIGlzIHNpbWlsYXIgdG8gdGhlIGV2b2x1dGlvbiBvZiBXaUZp Lgo+IAo+IDMuIEl0J3MgcHJvYmFibHkgbm90IGEgZ29vZCBhc3N1bXB0aW9uIHRvIHNheSB0aGF0 ICphbGwqIGRldmljZXMgd2lsbAo+IGhhdmUgdGhlIHBlcmZlY3QgY29tYmluYXRpb24gb2YgbmF0 aXZlIHN1cHBvcnQgb3IgY2FycmllciBzdXBwb3J0Lgo+IAo+IDQuIEF0IGxlYXN0IHNvbWUgY2Fy cmllcnMgcHJlZmVyIHRvIG1hbmFnZSBtb2JpbGl0eSBpbnNpZGUgdGhlIG5ldHdvcmsKPiByYXRo ZXIgdGhhbiBvbiB0aGUgY3VzdG9tZXIgZGV2aWNlLiBUaGlzIGlzIHNvbWV0aGluZyB0aGF0IHdl IGFyZQo+IGNvbnN0YW50bHkgZGlzY3Vzc2luZyBpbnRlcm5hbCB0byBvdXIgb3JnYW5pemF0aW9u LCB3aXRoIHZlbmRvcnMsIGFuZAo+IHdpdGggb3RoZXIgb3BlcmF0b3JzLgo+IAo+IEJhc2VkIG9u IHRoaXMsIHRoZSBjYXNlIGZvciBleHRlbmRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgUE1JUDYg aXMKPiBwcmV0dHkgc3Ryb25nLCBhdCBsZWFzdCBpbiBteSBvcGluaW9uLiAKCkFyZSB5b3Ugc2F5 aW5nIHRoYXQgdGhlIGV4dGVuZGVkIGZ1bmN0aW9uYWxpdHkgZm9yIFBNSVB2NiAgY2FuIGJlIGRv d25sb2FkZWQgd2l0aCB0aGUgZGV2aWNlIGRyaXZlciwgb3IgaW4gdGhlIGZ1dHVyZSBpdCB3aWxs IGJlIGluY2x1ZGVkIGluIHRoZSBPUz8KCkNhbiB5b3UgcGxlYXNlIGVsYWJvcmF0ZSBvbiB0aGlz IGFzIHRoaXMgaXMgdGhlIG1vc3QgcmVsZXZhbnQgdG8gdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbj8g V2h5IG5vdCB0aGVuIHNvbWUgb3RoZXIgdGhpbmdzIGxpa2UgTUlQNiBjbGllbnQ/CgpSZWdhcmRz LAoKQmVoY2V0CgoKICAgICAgCgpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcgpDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwg d2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLApvciBzdWJqZWN0IHRvIGNvcHlyaWdo dCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsCmlzIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gK aXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMKRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLApkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0 byB0aGUgY29udGVudHMKb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQp1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkKdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55CmNvcHkgb2YgdGhp cyBFLW1haWwgYW5kIGFueSBwcmludG91dC4K From rkoodli@starentnetworks.com Wed Jul 1 08:55:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30F63A6A5F for ; Wed, 1 Jul 2009 08:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG384aoZhyf2 for ; Wed, 1 Jul 2009 08:55:44 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id C867A3A69B7 for ; Wed, 1 Jul 2009 08:55:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2D2EC90153 for ; Wed, 1 Jul 2009 11:32:21 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23831-17 for ; Wed, 1 Jul 2009 11:32:20 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 1 Jul 2009 11:32:20 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 11:32:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jul 2009 11:27:55 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666093829E1@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJx References: From: "Koodli, Rajeev" To: "Hesham Soliman" , "Rajeev Koodli" , "marcelo bagnulo braun" X-OriginalArrivalTime: 01 Jul 2009 15:32:20.0379 (UTC) FILETIME=[1F7C6EB0:01C9FA61] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:55:44 -0000 =20 ________________________________ From: netext-bounces@ietf.org on behalf of Hesham Soliman Sent: Tue 6/30/2009 5:59 PM To: Rajeev Koodli; marcelo bagnulo braun Cc: netext@ietf.org; Basavaraj.Patil@nokia.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof = description > "No host changes" is ill-defined. Perhaps we should use "no host > protocol extensions" to state this. =3D> That sort of makes sense. Or it's consistent with what you stated earlier. > > As I mentioned earlier, it would be premature to rule out L3 > extensions IF L2 capabilities and host configurations alone cannot > support the feature. =3D> That's 180 diversion from the above statement. Are L3 protocols = allowed or not? I don't call them extensions because it's not clear which = protocol is being extended. RKo> I suggested "no host protocol changes" for stating the it = precisely. It was not meant to say we should endorse the statement. We are discussing PMIP and extensions would be for PMIP. If we are forced to support L3 extensions, it > would be up to the operator to decide. =3D> I don't understand this sentence. Why "forced" to support L3? Do = you mean the operator will decide to use it or not? RKo:> If 1) L2 capabilities are sufficinet, 2) and host configurations = also are not sufficient, we would be forced to look into L3 extensions. = Subsequently, it is up to the operator to decide whether they would like = to deploy the feature or not. -Rajeev Hesham > > -Rajeev > > >> Regards, marcelo > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Wed Jul 1 08:57:54 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9087F3A67AF for ; Wed, 1 Jul 2009 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF4anuGvvFDy for ; Wed, 1 Jul 2009 08:57:53 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 24F913A6A12 for ; Wed, 1 Jul 2009 08:57:53 -0700 (PDT) Received: from [68.142.237.89] by n7.bullet.re3.yahoo.com with NNFMP; 01 Jul 2009 15:57:52 -0000 Received: from [67.195.9.82] by t5.bullet.re3.yahoo.com with NNFMP; 01 Jul 2009 15:57:51 -0000 Received: from [67.195.9.104] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 15:57:51 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 15:57:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353442.38671.bm@omp108.mail.gq1.yahoo.com Received: (qmail 39011 invoked by uid 60001); 1 Jul 2009 15:56:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246463779; bh=gXEMsj7gArahKjj7qPbGvI6WiUpKmTQybLMQrS5+I7o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oTyaDEveixntCHH+oMScs34htfHlXr3dOtl1pwRWB0jr+nBBpB99Ut0pVA78hhgGha+6rbYiSlETNKaY3TH6N+cszVfkQS/rkjg2ZwIjeAXq90xuR4sOfGVdGElO5emtDM7Plq7x8NXqBXQVf7UbKRJJ5B9tF8mhFZXPNAnLZNc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GCSO9Ou/wZIZ8HgF+0A055uVrIQmkFVbkGCF1NxqWPWtoQeOTr6cC3TpvS2KJnuABznIRCHGJFMrCCpjIZmxetkJWmsC37ihgLFKIzfc6dSkIk8nVKfvTeHZhi3O5xaMvyIjJ1/IbTuf2C7wty9UBgILZoYswIfF0L2pC6j/ySg=; Message-ID: <722257.38107.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: c__ykhcVM1kdQPsTrJL6EMqWthQ1Su84qsbDMsH1GHD5f6YlUoIq2Ql1tOonX1TreErJH8xRz5KUI8XcXAhuk.WsIr3xMpkcyLlKMal8Da2RX7RsZAZw6WBeBHjyIvN0wd8OZrMjG9.ZUXncZFWSW_C_jQxPFzwzAwi9s3678_nfH9gV3sliVJ6MM0zdn8PZOM3WiaL.F8nXJr7hOHCHTf3hbQ5DOsXuFF03BF5t9LVkqwaCOy13iGyg9r.QoZ9BnpDCx41L7eUna9nptWLO09.jtvMaBZPiF.PCVP1lOJkFgDAaTsNu68Xfik3FswNKWcbV9k2bOZy4HgAxN6mJR1D602wQneIPLU9x Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 01 Jul 2009 08:56:19 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <925933.41309.qm@web111401.mail.gq1.yahoo.com> Date: Wed, 1 Jul 2009 08:56:19 -0700 (PDT) From: Behcet Sarikaya To: netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [netext] RECALL NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:57:54 -0000 Behcet Sarikaya wants to recall this message.=0A=0AIt was intented to be a = private message, sent to the list by mistake.=0A=0A=0A=A0=0A=0A=0A----- For= warded Message ----=0A> From: Behcet Sarikaya =0A= > To: "Noll, Kevin" ; Behcet Sarikaya ; netext@ietf.org=0A> Sent: Wednesday, July 1, 2009 10:51:22 AM=0A> S= ubject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof descr= iption=0A> =0A> =0A> I don't see any enthusiasm on MIH anywhere.=0A> I thin= k the current discussion is around additional functionality for HO. I =0A> = think PMIP supporters will argue that this can be done in IETF and the oppo= nents =0A> will argue that that is L2 and thus not an IETF issue.=0A> =0A> = My post to netext ML didn't go through, anyways it is OK to exhange ideas w= ith =0A> you. We can go to the list if you like.=0A> =0A> Regards,=0A> =0A>= Behcet=0A> =0A> =0A> =0A> ----- Original Message ----=0A> > From: "Noll, K= evin" =0A> > To: Behcet Sarikaya ; netext@ietf.org=0A> > Sent: Wednesday, J= uly 1, 2009 10:39:59 AM=0A> > Subject: RE: [netlmm] [MEXT] [netext] NEXTEXT= 2: first draft of the bof =0A> description=0A> > =0A> > =0A> > Perhaps I di= dn't catch the whole intent of the discussion, but I am assuming =0A> > tha= t there is *no* client software or stack requirement to support PMIP6 or = =0A> any =0A> > of its extensions.=0A> > =0A> > If there were extensions to= PMIP6 that required client software changes, then =0A> we =0A> > might as = well install a complete MIP6 stack. On the other hand, I can see =0A> > sce= narios where we might want some functionality on the client to help make HO= =0A> =0A> > decisions or improve the efficiency of a HO, but not want a co= mplete IP =0A> mobility =0A> > stack. This second scenario seems to suggest= using extensions based on =0A> something =0A> > like MIH.=0A> > =0A> > Bas= ed on this (only some brief thought given to it), perhaps an approach would= =0A> =0A> > be to specify the ability for a PMIP6 client (not the MN, but = the network =0A> > element) to converse with an MIH client and/or server. T= his could avoid the =0A> need =0A> > to *require* something on the MN, but = take advantage of it when it is =0A> available.=0A> > =0A> > --kan--=0A> > = --=0A> > Kevin A. Noll=0A> > =0A> > =0A> > =0A> > P Go Green! Print this em= ail only when necessary. Thank you for helping Time =0A> > Warner Cable be = environmentally responsible.=0A> > =0A> > =0A> > -----Original Message-----= =0A> > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] =0A> > Sent:= Wednesday, July 01, 2009 11:14 AM=0A> > To: Noll, Kevin; netext@ietf.org= =0A> > Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the b= of =0A> > description=0A> > =0A> > =0A> > Hi Kevin,=0A> > =A0 Nice to hear = from you!=0A> > =0A> > =0A> > =0A> > ----- Original Message ----=0A> > > Fr= om: "Noll, Kevin" =0A> > > To: netext@ietf.org; netlmm@ietf.org=0A> > > Sen= t: Wednesday, July 1, 2009 8:52:08 AM=0A> > > Subject: Re: [netlmm] [MEXT] = [netext] NEXTEXT2: first draft of the bof =0A> > description=0A> > > =0A> >= > I've been lurking here for a while watching the conversation. Please=0A>= > > accept my apologies for dropping in unexpectedly, but I thought I migh= t=0A> > > give at least one operator's viewpoint.=0A> > > =0A> > > You are = correct that most data cards being sold today require you to=0A> > > instal= l the carrier's software. This software typically contains a=0A> > > connec= tion manager and the OS drivers required to operate the data card.=0A> > > = Technically speaking, the data cards that I have worked with do not all=0A>= > > *require* the connection manager to operate, though it varies from car= d=0A> > > to card. Obviously, though, they *do* need the drivers.=0A> > > = =0A> > > What we saw with WiFi was a technology that began as an add-on to = our=0A> > > computing devices (laptops, etc.).. WiFi grew, matured, and bec= ame so=0A> > > widely accepted that operating systems began to ship with na= tive=0A> > > drivers, the add-on device became integrated into the computin= g devices=0A> > > and we no longer needed to install 3rd-party drivers or c= onnection=0A> > > software.=0A> > > =0A> > > As a network provider/operator= , we like this model because it is very=0A> > > expensive to write and main= tain the connection software and drivers and=0A> > > keep the user's device= up to date. Adding a mobility stack to the=0A> > > software being installe= d adds significantly to this cost. We are seeing=0A> > > the cost come down= , but there's still the issue of configuration and=0A> > > what-not.=0A> > = > =0A> > > We expect to see open networks and technologies like WiMAX (and = possibly=0A> > > LTE) change the traditional cellular data-card model to on= e that is more=0A> > > similar to WiFi, hopefully driving down the cost of = the software and=0A> > > moving the software development tasks out of the o= perator and into the=0A> > > OS vendor community.=0A> > > =0A> > > This sai= d, I think it would be a mistake to make any assumptions on=0A> > > either = of the two points mentioned below. =0A> > > =0A> > > 1. In the future the c= arrier may not deliver software with the data=0A> > > card, so it's probabl= y a bad assumption to say that the carrier would=0A> > > simply deliver a m= obility stack with the device.=0A> > > =0A> > > 2. It's probably a good ass= umption to say that devices will eventually=0A> > > have native mobility st= acks. We are already seeing this development in=0A> > > mainstream operatin= g systems. This is similar to the evolution of WiFi.=0A> > > =0A> > > 3. It= 's probably not a good assumption to say that *all* devices will=0A> > > ha= ve the perfect combination of native support or carrier support.=0A> > > = =0A> > > 4. At least some carriers prefer to manage mobility inside the net= work=0A> > > rather than on the customer device. This is something that we = are=0A> > > constantly discussing internal to our organization, with vendor= s, and=0A> > > with other operators.=0A> > > =0A> > > Based on this, the ca= se for extending the functionality of PMIP6 is=0A> > > pretty strong, at le= ast in my opinion. =0A> > =0A> > Are you saying that the extended functiona= lity for PMIPv6=A0 can be downloaded =0A> > with the device driver, or in t= he future it will be included in the OS?=0A> > =0A> > Can you please elabor= ate on this as this is the most relevant to the current =0A> > discussion? = Why not then some other things like MIP6 client?=0A> > =0A> > Regards,=0A> = > =0A> > Behcet=0A> > =0A> > =0A> > =A0 =A0 =A0 =0A> > =0A> > This E-mail a= nd any of its attachments may contain Time Warner=0A> > Cable proprietary i= nformation, which is privileged, confidential,=0A> > or subject to copyrigh= t belonging to Time Warner Cable. This E-mail=0A> > is intended solely for = the use of the individual or entity to which=0A> > it is addressed. If you = are not the intended recipient of this=0A> > E-mail, you are hereby notifie= d that any dissemination,=0A> > distribution, copying, or action taken in r= elation to the contents=0A> > of and attachments to this E-mail is strictly= prohibited and may be=0A> > unlawful. If you have received this E-mail in = error, please notify=0A> > the sender immediately and permanently delete th= e original and any=0A> > copy of this E-mail and any printout.=0A=0A=0A=0A = From xiayangsong@huawei.com Wed Jul 1 09:01:00 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5864428C53A for ; Wed, 1 Jul 2009 09:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.577 X-Spam-Level: X-Spam-Status: No, score=0.577 tagged_above=-999 required=5 tests=[AWL=-1.379, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdpYJRcoc-o3 for ; Wed, 1 Jul 2009 09:00:59 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 036163A68F4 for ; Wed, 1 Jul 2009 09:00:59 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM4003LW1TEDR@szxga02-in.huawei.com> for netext@ietf.org; Thu, 02 Jul 2009 00:00:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM400KB61TE8N@szxga02-in.huawei.com> for netext@ietf.org; Thu, 02 Jul 2009 00:00:50 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM400AEJ1SYQ9@szxml04-in.huawei.com> for netext@ietf.org; Thu, 02 Jul 2009 00:00:50 +0800 (CST) Date: Wed, 01 Jul 2009 11:00:33 -0500 From: Frank Xia To: Min Hui Message-id: <00ac01c9fa65$14c9a510$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090630030223.8997528C0E6@core3.amsl.com> <5dca10d30906292027h669edd1ene3070492547efac0@mail.gmail.com> <009301c9f9a5$c03b6d90$3e0c7c0a@china.huawei.com> <5dca10d30906302308k1efb3b57o48333a48ec77c2a7@mail.gmail.com> Cc: netext@ietf.org Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:01:00 -0000 Hi Hui Please check my inline comments.. BR Frank ----- Original Message ----- From: "Min Hui" To: "Frank Xia" Cc: Sent: Wednesday, July 01, 2009 1:08 AM Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00 Hi, Frank Xia Thanks for your comments, please see my reply in line. - Hui Min 2009/7/1 Frank Xia : > Hi Min > > I had a quick look at the document which > looks clear. Some comments are below. > > 1)"multiple service flows of the mobile node can > be separately controlled based on the service > flow identifier in the Proxy Binding Update > and Acknowledge messages" > I could not find the motivation of separate > controlling of a service. It is for traffic > engineering, QoS enforcement or something else? > It is used for content charging, QoS enforcement, etc. It is important for operators to treat services separately. Frank=>Agree. is possible for LMA send a service flow identifier to MAG? > 2)it is also not clear to me how the mobile > node notifies the MAG the service type. > It seems that the MAG identifies the service > through data packets from the mobile node. > Deep Packet Inspection technology is required > for MAG? Yes, MAG is required to know the transport layer information. But I guess the service type you mentioned refer to the "TOS" in the service flow description. TOS is a field in the IP header, so DPI is not necessary in this respect. Frank=>I did not mean "TOS"£Ĵ but appliactions (or flows). > > 3)What is the relationship between this draft > and flow mobility being discussed in Netext BoF 2? > They both have key words "flow" :-). > We considered this question as well. This draft is about the granularity of PMIPv6, it is an important part of PMIPv6, although it is independent of flow mobility. So we are wondering whether the NETEXT BOF can add the granularity issue into the scope. > > BR > Frank > > > ----- Original Message ----- From: "Min Hui" > To: > Sent: Monday, June 29, 2009 10:27 PM > Subject: [netext] Fwd: New Version Notification > fordraft-hui-netext-service-flow-identifier-00 > > >> Hi, all >> >> I have just submitted a new draft: >> >> http://www.ietf.org/internet-drafts/draft-hui-netext-service-flow-identifier-00.txt >> >> This draft defines a new Service Flow Identifier option carrying the >> service flow identifier and service flow attributes in the Proxy >> Binding Update and Acknowledgement message, so that the granularity of >> PMIPv6 becomes per service flow basis. >> >> Any comment is welcomed. >> Thanks a lot. >> >> -Hui Min >> >> >> >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: 2009/6/30 >> Subject: New Version Notification for >> draft-hui-netext-service-flow-identifier-00 >> To: huimin.cmcc@gmail.com >> ³­ËÍ£ş chengang@chinamobile.com, denghui02@gmail.com >> >> >> >> A new version of I-D, draft-hui-netext-service-flow-identifier-00.txt >> has been successfuly submitted by Min Hui and posted to the IETF >> repository. >> >> Filename: draft-hui-netext-service-flow-identifier >> Revision: 00 >> Title: Service Flow Identifier in Proxy Mobile IPv6 >> Creation_date: 2009-06-29 >> WG ID: Independent Submission >> Number_of_pages: 18 >> >> Abstract: >> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 >> mobile node without requiring its participation in any mobility- >> related signaling. This document introduces extensions to Proxy >> Mobile IPv6 that allows network dynamically binding each service flow >> to the mobile node, respectively. Therefore, multiple service flows >> of the mobile node can be separately controlled based on the service >> flow identifier in the Proxy Binding Update and Acknowledge messages. >> >> >> >> The IETF Secretariat. >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > From behcetsarikaya@yahoo.com Wed Jul 1 09:04:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F39128C54F for ; Wed, 1 Jul 2009 09:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKBYjTMh6V7D for ; Wed, 1 Jul 2009 09:04:26 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 1EA6528C54B for ; Wed, 1 Jul 2009 09:04:26 -0700 (PDT) Received: from [68.142.230.29] by n9.bullet.re3.yahoo.com with NNFMP; 01 Jul 2009 16:03:42 -0000 Received: from [67.195.9.83] by t2.bullet.re2.yahoo.com with NNFMP; 01 Jul 2009 16:03:42 -0000 Received: from [67.195.9.111] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 16:03:42 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 16:03:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 161929.79739.bm@omp115.mail.gq1.yahoo.com Received: (qmail 39011 invoked by uid 60001); 1 Jul 2009 15:56:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246463779; bh=gXEMsj7gArahKjj7qPbGvI6WiUpKmTQybLMQrS5+I7o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oTyaDEveixntCHH+oMScs34htfHlXr3dOtl1pwRWB0jr+nBBpB99Ut0pVA78hhgGha+6rbYiSlETNKaY3TH6N+cszVfkQS/rkjg2ZwIjeAXq90xuR4sOfGVdGElO5emtDM7Plq7x8NXqBXQVf7UbKRJJ5B9tF8mhFZXPNAnLZNc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GCSO9Ou/wZIZ8HgF+0A055uVrIQmkFVbkGCF1NxqWPWtoQeOTr6cC3TpvS2KJnuABznIRCHGJFMrCCpjIZmxetkJWmsC37ihgLFKIzfc6dSkIk8nVKfvTeHZhi3O5xaMvyIjJ1/IbTuf2C7wty9UBgILZoYswIfF0L2pC6j/ySg=; Message-ID: <722257.38107.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: c__ykhcVM1kdQPsTrJL6EMqWthQ1Su84qsbDMsH1GHD5f6YlUoIq2Ql1tOonX1TreErJH8xRz5KUI8XcXAhuk.WsIr3xMpkcyLlKMal8Da2RX7RsZAZw6WBeBHjyIvN0wd8OZrMjG9.ZUXncZFWSW_C_jQxPFzwzAwi9s3678_nfH9gV3sliVJ6MM0zdn8PZOM3WiaL.F8nXJr7hOHCHTf3hbQ5DOsXuFF03BF5t9LVkqwaCOy13iGyg9r.QoZ9BnpDCx41L7eUna9nptWLO09.jtvMaBZPiF.PCVP1lOJkFgDAaTsNu68Xfik3FswNKWcbV9k2bOZy4HgAxN6mJR1D602wQneIPLU9x Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 01 Jul 2009 08:56:19 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <925933.41309.qm@web111401.mail.gq1.yahoo.com> Date: Wed, 1 Jul 2009 08:56:19 -0700 (PDT) From: Behcet Sarikaya To: netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [netext] RECALL NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:04:26 -0000 Behcet Sarikaya wants to recall this message.=0A=0AIt was intented to be a = private message, sent to the list by mistake.=0A=0A=0A=A0=0A=0A=0A----- For= warded Message ----=0A> From: Behcet Sarikaya =0A= > To: "Noll, Kevin" ; Behcet Sarikaya ; netext@ietf.org=0A> Sent: Wednesday, July 1, 2009 10:51:22 AM=0A> S= ubject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof descr= iption=0A> =0A> =0A> I don't see any enthusiasm on MIH anywhere.=0A> I thin= k the current discussion is around additional functionality for HO. I =0A> = think PMIP supporters will argue that this can be done in IETF and the oppo= nents =0A> will argue that that is L2 and thus not an IETF issue.=0A> =0A> = My post to netext ML didn't go through, anyways it is OK to exhange ideas w= ith =0A> you. We can go to the list if you like.=0A> =0A> Regards,=0A> =0A>= Behcet=0A> =0A> =0A> =0A> ----- Original Message ----=0A> > From: "Noll, K= evin" =0A> > To: Behcet Sarikaya ; netext@ietf.org=0A> > Sent: Wednesday, J= uly 1, 2009 10:39:59 AM=0A> > Subject: RE: [netlmm] [MEXT] [netext] NEXTEXT= 2: first draft of the bof =0A> description=0A> > =0A> > =0A> > Perhaps I di= dn't catch the whole intent of the discussion, but I am assuming =0A> > tha= t there is *no* client software or stack requirement to support PMIP6 or = =0A> any =0A> > of its extensions.=0A> > =0A> > If there were extensions to= PMIP6 that required client software changes, then =0A> we =0A> > might as = well install a complete MIP6 stack. On the other hand, I can see =0A> > sce= narios where we might want some functionality on the client to help make HO= =0A> =0A> > decisions or improve the efficiency of a HO, but not want a co= mplete IP =0A> mobility =0A> > stack. This second scenario seems to suggest= using extensions based on =0A> something =0A> > like MIH.=0A> > =0A> > Bas= ed on this (only some brief thought given to it), perhaps an approach would= =0A> =0A> > be to specify the ability for a PMIP6 client (not the MN, but = the network =0A> > element) to converse with an MIH client and/or server. T= his could avoid the =0A> need =0A> > to *require* something on the MN, but = take advantage of it when it is =0A> available.=0A> > =0A> > --kan--=0A> > = --=0A> > Kevin A. Noll=0A> > =0A> > =0A> > =0A> > P Go Green! Print this em= ail only when necessary. Thank you for helping Time =0A> > Warner Cable be = environmentally responsible.=0A> > =0A> > =0A> > -----Original Message-----= =0A> > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] =0A> > Sent:= Wednesday, July 01, 2009 11:14 AM=0A> > To: Noll, Kevin; netext@ietf.org= =0A> > Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the b= of =0A> > description=0A> > =0A> > =0A> > Hi Kevin,=0A> > =A0 Nice to hear = from you!=0A> > =0A> > =0A> > =0A> > ----- Original Message ----=0A> > > Fr= om: "Noll, Kevin" =0A> > > To: netext@ietf.org; netlmm@ietf.org=0A> > > Sen= t: Wednesday, July 1, 2009 8:52:08 AM=0A> > > Subject: Re: [netlmm] [MEXT] = [netext] NEXTEXT2: first draft of the bof =0A> > description=0A> > > =0A> >= > I've been lurking here for a while watching the conversation. Please=0A>= > > accept my apologies for dropping in unexpectedly, but I thought I migh= t=0A> > > give at least one operator's viewpoint.=0A> > > =0A> > > You are = correct that most data cards being sold today require you to=0A> > > instal= l the carrier's software. This software typically contains a=0A> > > connec= tion manager and the OS drivers required to operate the data card.=0A> > > = Technically speaking, the data cards that I have worked with do not all=0A>= > > *require* the connection manager to operate, though it varies from car= d=0A> > > to card. Obviously, though, they *do* need the drivers.=0A> > > = =0A> > > What we saw with WiFi was a technology that began as an add-on to = our=0A> > > computing devices (laptops, etc.).. WiFi grew, matured, and bec= ame so=0A> > > widely accepted that operating systems began to ship with na= tive=0A> > > drivers, the add-on device became integrated into the computin= g devices=0A> > > and we no longer needed to install 3rd-party drivers or c= onnection=0A> > > software.=0A> > > =0A> > > As a network provider/operator= , we like this model because it is very=0A> > > expensive to write and main= tain the connection software and drivers and=0A> > > keep the user's device= up to date. Adding a mobility stack to the=0A> > > software being installe= d adds significantly to this cost. We are seeing=0A> > > the cost come down= , but there's still the issue of configuration and=0A> > > what-not.=0A> > = > =0A> > > We expect to see open networks and technologies like WiMAX (and = possibly=0A> > > LTE) change the traditional cellular data-card model to on= e that is more=0A> > > similar to WiFi, hopefully driving down the cost of = the software and=0A> > > moving the software development tasks out of the o= perator and into the=0A> > > OS vendor community.=0A> > > =0A> > > This sai= d, I think it would be a mistake to make any assumptions on=0A> > > either = of the two points mentioned below. =0A> > > =0A> > > 1. In the future the c= arrier may not deliver software with the data=0A> > > card, so it's probabl= y a bad assumption to say that the carrier would=0A> > > simply deliver a m= obility stack with the device.=0A> > > =0A> > > 2. It's probably a good ass= umption to say that devices will eventually=0A> > > have native mobility st= acks. We are already seeing this development in=0A> > > mainstream operatin= g systems. This is similar to the evolution of WiFi.=0A> > > =0A> > > 3. It= 's probably not a good assumption to say that *all* devices will=0A> > > ha= ve the perfect combination of native support or carrier support.=0A> > > = =0A> > > 4. At least some carriers prefer to manage mobility inside the net= work=0A> > > rather than on the customer device. This is something that we = are=0A> > > constantly discussing internal to our organization, with vendor= s, and=0A> > > with other operators.=0A> > > =0A> > > Based on this, the ca= se for extending the functionality of PMIP6 is=0A> > > pretty strong, at le= ast in my opinion. =0A> > =0A> > Are you saying that the extended functiona= lity for PMIPv6=A0 can be downloaded =0A> > with the device driver, or in t= he future it will be included in the OS?=0A> > =0A> > Can you please elabor= ate on this as this is the most relevant to the current =0A> > discussion? = Why not then some other things like MIP6 client?=0A> > =0A> > Regards,=0A> = > =0A> > Behcet=0A> > =0A> > =0A> > =A0 =A0 =A0 =0A> > =0A> > This E-mail a= nd any of its attachments may contain Time Warner=0A> > Cable proprietary i= nformation, which is privileged, confidential,=0A> > or subject to copyrigh= t belonging to Time Warner Cable. This E-mail=0A> > is intended solely for = the use of the individual or entity to which=0A> > it is addressed. If you = are not the intended recipient of this=0A> > E-mail, you are hereby notifie= d that any dissemination,=0A> > distribution, copying, or action taken in r= elation to the contents=0A> > of and attachments to this E-mail is strictly= prohibited and may be=0A> > unlawful. If you have received this E-mail in = error, please notify=0A> > the sender immediately and permanently delete th= e original and any=0A> > copy of this E-mail and any printout.=0A=0A=0A=0A = From hesham@elevatemobile.com Wed Jul 1 09:21:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9808C3A6874 for ; Wed, 1 Jul 2009 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsSLh9pJtpCu for ; Wed, 1 Jul 2009 09:21:25 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C25863A6862 for ; Wed, 1 Jul 2009 09:21:24 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MM2Xx-0004ub-43; Thu, 02 Jul 2009 02:20:33 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 02:20:19 +1000 From: Hesham Soliman To: "Koodli, Rajeev" , Rajeev Koodli , marcelo bagnulo braun Message-ID: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIU= In-Reply-To: <4D35478224365146822AE9E3AD4A2666093829E1$0001@exchtewks3.starentnetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:21:26 -0000 > => That's 180 diversion from the above statement. Are L3 protocols allowed > or not? I don't call them extensions because it's not clear which protocol > is being extended. > > > RKo> I suggested "no host protocol changes" for stating the it precisely. It > was not meant to say we should endorse the statement. => Ok but I'm asking for your opinion on what the requirement should be. Is your opinion that the requirement should be "no protocol support in the host"? Hesham From Basavaraj.Patil@nokia.com Wed Jul 1 10:47:29 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA45D3A6967; Wed, 1 Jul 2009 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L4mTRl4PZSs; Wed, 1 Jul 2009 10:47:28 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0DFEF3A67F6; Wed, 1 Jul 2009 10:47:27 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n61Hkq35031499; Wed, 1 Jul 2009 20:46:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 20:46:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 20:46:19 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 1 Jul 2009 19:46:18 +0200 From: To: , Date: Wed, 1 Jul 2009 19:46:27 +0200 Thread-Topic: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof description Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYqABzl+6M= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2009 17:46:19.0638 (UTC) FILETIME=[D7420160:01C9FA73] X-Nokia-AV: Clean Cc: netext@ietf.org, netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 17:47:29 -0000 Hi Hesham, On 6/30/09 10:59 PM, "ext Hesham Soliman" wrote: >=20 >=20 > Hi Raj, >=20 > I had a brief offline chat with Julien and thought that I could refine my > suggestion a bit more to make the point clearer. My point is that there a= re > currently two slightly different points being made about the requirement = on > host involvement 1) no SW on the host and the more nuanced 2) no protocol > support on the host. I won't even get into the reasons for point 2) above > and I'll let the people who raise it provide those reasons, I can't figur= e > out any technical reasons there. I believe that host involvement is imperative to enable features such as inter-tech HO and flow binding/mobility for PMIP6. Some aspects of these features may be potentially accomplished by doing some additional signaling in the network itself and involving the policy store function to an even greater degree. I do not believe that you can avoid having some requirement= s on the host. =20 >=20 > Anyway, my point is that 1) above is not an issue today because it alread= y > happens on a very large scale, so requiring it for a specific feature lik= e > multihoming is hardly a leap. I can imagine ads for "download your wirele= ss > optimiser from wwww.operator.com and save money" (ok not very creative). > The subtle difference between 1) and 2) is IMO a moot point anyway becaus= e > 2) simply says that operators don't want protocol support in the network, > but that support already exists in the form of PMIP and if you have PMIP = you > have MIP.=20 While I agree that having PMIP equates to having MIP, it is only from the perspective of the fact that the LMA is also a DSMIP6 HA. But this fact is of no use in actual deployments. An LMA will not operate as a DSMIP6 HA unless there is explicit support enabled for it to operate as an HA. I just don't see the LMA accepting BUs from a (DS)MIP6 MN or establishing IPsec SA= s to secure the signaling. My point is that while the functionality of the DSMIP6 HA exists in the LMA, it is simply unable to operate as such without additional features being enabled. Regarding point 1 above, I don't know if you are suggesting that MIP6 clien= t SW can simply be downloaded on a host and would work subsequently. While I wish that were the case, I think we are still pretty far from such capability.=20 > So, both motivations seem to be on shaky ground. > And yes, you can of course integrate 3G modems in computers, but you can > also integrate mobility code in the same computers with the 3G support. T= he > SW that is provided with the modems is not only connection SW it actually > provides a number of features (e.g. Receiving SMS, account information, > email ....etc) so it's a clear move by operators to be present on those > machines. I don't think it's anything like WLAN connctions SW. If the 3G modem requires a mobility stack in order to attach and access a 3= G network, then yes the host will include such SW. But if the only thing needed is a device driver and some interface to a connection manager type o= f app, then I don't see OS vendors going out of their way to add SW that woul= d be considered optional. If all the connectivity aspects are in the 3G modem and the device driver then the need for mobility stack SW at L3 are diminished.=20 >=20 > Of course it's worth mentioning that the elephant in the room is the bina= ry > requirement on host support of protocols. We need to have a yes/no answer= as > to whether there is a requirement to NOT have protocol support in the hos= t. > At the moment this is being kept very vague. I think it is an unknown. Is there a need for L3 protocol support on the host to accomplish the functionality being aimed for? It might be the case that some of this L3 protocol support be achieved by extending existing protocols such as DHCPv6 or ND (just examples and not to be considered as solutions). Or there may be recommendations to L2s in whic= h case the IETF would only recommend some capabilities that L2 would be required to have to provide these features. This is probably the reason why there is no definitive yes/no answer on the need for protocol support in th= e host. It should also be pointed out that requiring protocol support on the host is not directly equilavalent to having a MIP client on the host. There are degrees of differences between a MIP client vs some simple protocol support.=20 -Raj >=20 > Hesham >=20 >>> =3D> No one I know can get a 3G data card to access the Internet from t= heir PC >>> without having to install a piece of software on their PC to make it w= ork. >>> So I think your assumption that the operator cannot mandate software on= the >>> host is questionable, because they already do (unfortunately). >>=20 >> The situation that you describe above was the same when 802.11 first rol= led >> around as well. >> You had to install a piece of software that came with the PC card. But t= hat >> has changed with >> wifi now being an integral part of the notebook computers. >> And I think you could expect 3G chipsets and access built-in as well in = due >> course of time. At least I know of a few >> operators in the US (as well as notebook manufacturers) who offer such >> net/notebook computers, >> i.e with integrated 3G access. I do not know what additional sw is loade= d on >> these but at least the end user >> is not installing anything else. >> Does it imply that such hosts will include the software that would enabl= e >> host >> mobility? Its an open question (i.e unknown) >> and will depend largely on operator choices and vendors. >>=20 >> -Raj >>=20 >>> Hesham >>=20 >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >=20 >=20 From hesham@elevatemobile.com Wed Jul 1 11:07:46 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6543A6821; Wed, 1 Jul 2009 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33IH0tQ6VnR6; Wed, 1 Jul 2009 11:07:45 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id EB1703A6832; Wed, 1 Jul 2009 11:07:44 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MM2d6-0004zY-7S; Thu, 02 Jul 2009 02:25:52 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 02:25:45 +1000 From: Hesham Soliman To: "Noll, Kevin" , , Message-ID: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYqABMlAnAABu917w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 18:07:46 -0000 Kevin, Thanks for the input. I understand where you're coming from and I have two small comments to make. First I think you're assuming that mobility support for the multihoming scenario we're discussing must be done in the kernel. This is not the case at all. Things can be done in user space as an add-on application. Second, you made this comment: > 4. At least some carriers prefer to manage mobility inside the network > rather than on the customer device. This is something that we are > constantly discussing internal to our organization, with vendors, and > with other operators. => To be precise, all carriers manage mobility from both the network and host sides. It's just not L3 mobility. So the question should be whether it is acceptable to manage L3 mobility on both sides as well. And there is pretty good reasons for doing that, especially that most mobile devices today have multiple interfaces to different technologies, which never happened before. Hesham On 1/07/09 11:52 PM, "Noll, Kevin" wrote: > I've been lurking here for a while watching the conversation. Please > accept my apologies for dropping in unexpectedly, but I thought I might > give at least one operator's viewpoint. > > You are correct that most data cards being sold today require you to > install the carrier's software. This software typically contains a > connection manager and the OS drivers required to operate the data card. > Technically speaking, the data cards that I have worked with do not all > *require* the connection manager to operate, though it varies from card > to card. Obviously, though, they *do* need the drivers. > > What we saw with WiFi was a technology that began as an add-on to our > computing devices (laptops, etc.). WiFi grew, matured, and became so > widely accepted that operating systems began to ship with native > drivers, the add-on device became integrated into the computing devices > and we no longer needed to install 3rd-party drivers or connection > software. > > As a network provider/operator, we like this model because it is very > expensive to write and maintain the connection software and drivers and > keep the user's device up to date. Adding a mobility stack to the > software being installed adds significantly to this cost. We are seeing > the cost come down, but there's still the issue of configuration and > what-not. > > We expect to see open networks and technologies like WiMAX (and possibly > LTE) change the traditional cellular data-card model to one that is more > similar to WiFi, hopefully driving down the cost of the software and > moving the software development tasks out of the operator and into the > OS vendor community. > > This said, I think it would be a mistake to make any assumptions on > either of the two points mentioned below. > > 1. In the future the carrier may not deliver software with the data > card, so it's probably a bad assumption to say that the carrier would > simply deliver a mobility stack with the device. > > 2. It's probably a good assumption to say that devices will eventually > have native mobility stacks. We are already seeing this development in > mainstream operating systems. This is similar to the evolution of WiFi. > > 3. It's probably not a good assumption to say that *all* devices will > have the perfect combination of native support or carrier support. > > 4. At least some carriers prefer to manage mobility inside the network > rather than on the customer device. This is something that we are > constantly discussing internal to our organization, with vendors, and > with other operators. > > Based on this, the case for extending the functionality of PMIP6 is > pretty strong, at least in my opinion. > > On the other hand, we will also continue following the development of > native stacks and evaluate when and how best to use them in our product > offerings. Similarly, we will continue to evaluate whether or not we > need to deliver a mobility stack with our data card software. > > Thanks! > > --kan-- > -- > Kevin A. Noll > > > > P Go Green! Print this email only when necessary. Thank you for helping Time > Warner Cable be environmentally responsible. > > > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On Behalf > Of Hesham Soliman > Sent: Tuesday, June 30, 2009 11:59 PM > To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es > Cc: netext@ietf.org; netlmm@ietf.org > Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof > description > > > Hi Raj, > > I had a brief offline chat with Julien and thought that I could refine > my > suggestion a bit more to make the point clearer. My point is that there > are > currently two slightly different points being made about the requirement > on > host involvement 1) no SW on the host and the more nuanced 2) no > protocol > support on the host. I won't even get into the reasons for point 2) > above > and I'll let the people who raise it provide those reasons, I can't > figure > out any technical reasons there. > > Anyway, my point is that 1) above is not an issue today because it > already > happens on a very large scale, so requiring it for a specific feature > like > multihoming is hardly a leap. I can imagine ads for "download your > wireless > optimiser from wwww.operator.com and save money" (ok not very creative). > The subtle difference between 1) and 2) is IMO a moot point anyway > because > 2) simply says that operators don't want protocol support in the > network, > but that support already exists in the form of PMIP and if you have PMIP > you > have MIP. So, both motivations seem to be on shaky ground. > And yes, you can of course integrate 3G modems in computers, but you can > also integrate mobility code in the same computers with the 3G support. > The > SW that is provided with the modems is not only connection SW it > actually > provides a number of features (e.g. Receiving SMS, account information, > email ....etc) so it's a clear move by operators to be present on those > machines. I don't think it's anything like WLAN connctions SW. > > Of course it's worth mentioning that the elephant in the room is the > binary > requirement on host support of protocols. We need to have a yes/no > answer as > to whether there is a requirement to NOT have protocol support in the > host. > At the moment this is being kept very vague. > > Hesham > >>> => No one I know can get a 3G data card to access the Internet from > their PC >>> without having to install a piece of software on their PC to make it > work. >>> So I think your assumption that the operator cannot mandate software > on the >>> host is questionable, because they already do (unfortunately). >> >> The situation that you describe above was the same when 802.11 first > rolled >> around as well. >> You had to install a piece of software that came with the PC card. But > that >> has changed with >> wifi now being an integral part of the notebook computers. >> And I think you could expect 3G chipsets and access built-in as well > in due >> course of time. At least I know of a few >> operators in the US (as well as notebook manufacturers) who offer such >> net/notebook computers, >> i.e with integrated 3G access. I do not know what additional sw is > loaded on >> these but at least the end user >> is not installing anything else. >> Does it imply that such hosts will include the software that would > enable host >> mobility? Its an open question (i.e unknown) >> and will depend largely on operator choices and vendors. >> >> -Raj >> >>> Hesham >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From kevin.noll@twcable.com Wed Jul 1 11:48:42 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2233A69F7; Wed, 1 Jul 2009 11:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id misukO9RKMKr; Wed, 1 Jul 2009 11:48:40 -0700 (PDT) Received: from pblpas02.twcable.com (pblpas02.twcable.com [204.235.121.150]) by core3.amsl.com (Postfix) with ESMTP id 36E173A682B; Wed, 1 Jul 2009 11:48:40 -0700 (PDT) X-SENDER-IP: 10.157.247.214 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.42,327,1243828800"; d="scan'208";a="428381024" Received: from unknown (HELO prvpmailconn4.corp.twcable.com) ([10.157.247.214]) by pblpas02.twcable.com with ESMTP; 01 Jul 2009 14:48:47 -0400 Received: from PRVPVSMAIL07.corp.twcable.com ([10.157.247.203]) by prvpmailconn4.corp.twcable.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 14:48:47 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Jul 2009 14:48:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYqABMlAnAABu917wAEel9A References: From: "Noll, Kevin" To: , X-OriginalArrivalTime: 01 Jul 2009 18:48:47.0247 (UTC) FILETIME=[9101C1F0:01C9FA7C] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 18:48:42 -0000 Hesham, I don't think I was assuming kernel-space or user-space. I *think* I was approaching this from how I have seen most implementations. It seems pretty typical that the connection manager is a user-space application, but the data-card drivers are OS-level. For example, in Windows a 3G data-card typically is installed as a RAS device and WiFi cards show up as NDIS. I don't think any solution *must* hold to this model. Thanks, though, for calling out what may be an unknown assumption on my part. Agreed, carriers manage mobility on both sides and at multiple layers. >From my point of view (at least for this discussion) I only care about L3 and assume that any lower-layer mobility is hidden from me. On the other hand, I think it is important, if not necessary, that L1/L2 information be available to L3 and above in order to make HO functions more robust. Also, I tend to think that network-based mobility (e.g. PMIP6) should be network-based and not place requirements on the MN. Similarly, if you are going to make a requirement on the MN, you might as well go all-in and make it CMIP. Of course, there are implications on memory, CPU, etc. so my all or nothing approach is probably not a very practical one.=20 --kan-- -- Kevin A. Noll -----Original Message----- From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 Sent: Wednesday, July 01, 2009 12:26 PM To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Kevin,=20 Thanks for the input. I understand where you're coming from and I have two small comments to make. First I think you're assuming that mobility support for the multihoming scenario we're discussing must be done in the kernel. This is not the case at all. Things can be done in user space as an add-on application. Second, you made this comment: > 4. At least some carriers prefer to manage mobility inside the network > rather than on the customer device. This is something that we are > constantly discussing internal to our organization, with vendors, and > with other operators. =3D> To be precise, all carriers manage mobility from both the network and host sides. It's just not L3 mobility. So the question should be whether it is acceptable to manage L3 mobility on both sides as well. And there is pretty good reasons for doing that, especially that most mobile devices today have multiple interfaces to different technologies, which never happened before.=20 Hesham On 1/07/09 11:52 PM, "Noll, Kevin" wrote: > I've been lurking here for a while watching the conversation. Please > accept my apologies for dropping in unexpectedly, but I thought I might > give at least one operator's viewpoint. >=20 > You are correct that most data cards being sold today require you to > install the carrier's software. This software typically contains a > connection manager and the OS drivers required to operate the data card. > Technically speaking, the data cards that I have worked with do not all > *require* the connection manager to operate, though it varies from card > to card. Obviously, though, they *do* need the drivers. >=20 > What we saw with WiFi was a technology that began as an add-on to our > computing devices (laptops, etc.). WiFi grew, matured, and became so > widely accepted that operating systems began to ship with native > drivers, the add-on device became integrated into the computing devices > and we no longer needed to install 3rd-party drivers or connection > software. >=20 > As a network provider/operator, we like this model because it is very > expensive to write and maintain the connection software and drivers and > keep the user's device up to date. Adding a mobility stack to the > software being installed adds significantly to this cost. We are seeing > the cost come down, but there's still the issue of configuration and > what-not. >=20 > We expect to see open networks and technologies like WiMAX (and possibly > LTE) change the traditional cellular data-card model to one that is more > similar to WiFi, hopefully driving down the cost of the software and > moving the software development tasks out of the operator and into the > OS vendor community. >=20 > This said, I think it would be a mistake to make any assumptions on > either of the two points mentioned below. >=20 > 1. In the future the carrier may not deliver software with the data > card, so it's probably a bad assumption to say that the carrier would > simply deliver a mobility stack with the device. >=20 > 2. It's probably a good assumption to say that devices will eventually > have native mobility stacks. We are already seeing this development in > mainstream operating systems. This is similar to the evolution of WiFi. >=20 > 3. It's probably not a good assumption to say that *all* devices will > have the perfect combination of native support or carrier support. >=20 > 4. At least some carriers prefer to manage mobility inside the network > rather than on the customer device. This is something that we are > constantly discussing internal to our organization, with vendors, and > with other operators. >=20 > Based on this, the case for extending the functionality of PMIP6 is > pretty strong, at least in my opinion. >=20 > On the other hand, we will also continue following the development of > native stacks and evaluate when and how best to use them in our product > offerings. Similarly, we will continue to evaluate whether or not we > need to deliver a mobility stack with our data card software. >=20 > Thanks! >=20 > --kan-- > -- > Kevin A. Noll >=20 >=20 >=20 > P Go Green! Print this email only when necessary. Thank you for helping Time > Warner Cable be environmentally responsible. > =20 > =20 > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On Behalf > Of Hesham Soliman > Sent: Tuesday, June 30, 2009 11:59 PM > To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es > Cc: netext@ietf.org; netlmm@ietf.org > Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof > description >=20 >=20 > Hi Raj,=20 >=20 > I had a brief offline chat with Julien and thought that I could refine > my > suggestion a bit more to make the point clearer. My point is that there > are > currently two slightly different points being made about the requirement > on > host involvement 1) no SW on the host and the more nuanced 2) no > protocol > support on the host. I won't even get into the reasons for point 2) > above > and I'll let the people who raise it provide those reasons, I can't > figure > out any technical reasons there. >=20 > Anyway, my point is that 1) above is not an issue today because it > already > happens on a very large scale, so requiring it for a specific feature > like > multihoming is hardly a leap. I can imagine ads for "download your > wireless > optimiser from wwww.operator.com and save money" (ok not very creative). > The subtle difference between 1) and 2) is IMO a moot point anyway > because > 2) simply says that operators don't want protocol support in the > network, > but that support already exists in the form of PMIP and if you have PMIP > you > have MIP. So, both motivations seem to be on shaky ground. > And yes, you can of course integrate 3G modems in computers, but you can > also integrate mobility code in the same computers with the 3G support. > The > SW that is provided with the modems is not only connection SW it > actually > provides a number of features (e.g. Receiving SMS, account information, > email ....etc) so it's a clear move by operators to be present on those > machines. I don't think it's anything like WLAN connctions SW. >=20 > Of course it's worth mentioning that the elephant in the room is the > binary > requirement on host support of protocols. We need to have a yes/no > answer as > to whether there is a requirement to NOT have protocol support in the > host. > At the moment this is being kept very vague. >=20 > Hesham >=20 >>> =3D> No one I know can get a 3G data card to access the Internet from > their PC >>> without having to install a piece of software on their PC to make it > work. >>> So I think your assumption that the operator cannot mandate software > on the >>> host is questionable, because they already do (unfortunately). >>=20 >> The situation that you describe above was the same when 802.11 first > rolled >> around as well. >> You had to install a piece of software that came with the PC card. But > that >> has changed with >> wifi now being an integral part of the notebook computers. >> And I think you could expect 3G chipsets and access built-in as well > in due >> course of time. At least I know of a few >> operators in the US (as well as notebook manufacturers) who offer such >> net/notebook computers, >> i.e with integrated 3G access. I do not know what additional sw is > loaded on >> these but at least the end user >> is not installing anything else. >> Does it imply that such hosts will include the software that would > enable host >> mobility? Its an open question (i.e unknown) >> and will depend largely on operator choices and vendors. >>=20 >> -Raj >>=20 >>> Hesham >>=20 >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From Basavaraj.Patil@nokia.com Wed Jul 1 14:12:10 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00393A6F3B for ; Wed, 1 Jul 2009 14:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tXzVnp3goKA for ; Wed, 1 Jul 2009 14:12:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F04B93A6F67 for ; Wed, 1 Jul 2009 14:12:06 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n61LCIXJ005903; Wed, 1 Jul 2009 16:12:21 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 00:11:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 00:11:37 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 1 Jul 2009 23:11:34 +0200 From: To: , Date: Wed, 1 Jul 2009 23:11:41 +0200 Thread-Topic: [netext] Questions for defining the NETEXT2 problem space Thread-Index: Acn6XnEx92kXYFQfQsqYVrrUbHjNjQAMhYrc Message-ID: In-Reply-To: <4A4B7CED.5090909@it.uc3m.es> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2009 21:11:37.0542 (UTC) FILETIME=[854CFE60:01C9FA90] X-Nokia-AV: Clean Subject: Re: [netext] Questions for defining the NETEXT2 problem space X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:12:11 -0000 Hi Marcelo, On 7/1/09 10:12 AM, "Marcelo Bagnulo" wrote: > Hi, >=20 > After the discussion so far, i have identified the following question > for which i think it would be important to provide answer to define the > requirements of the problems we are trying to tackle. >=20 > As stated earlier, the goal of this questions is to try to define the > "what are we trying to achieve?" question. >=20 > Once we have a set of answers, we will need to do the "Why?" part. >=20 > So, this is work in progress, but i woudl appreciate input in terms of > modificatiosn to the questions, answers to the questions and more questio= ns. >=20 > Questions: >=20 > 1)- What L2 technologies are supported? All the L2 technologies? A > subset of L2 technologies? I don't think we should be developing solutions for some subset of L2 technologies. I think the discussion of what L2s are applicable in the context of this discussion is a rat-hole. -Raj >=20 > 2)- What changes are acceptable in the MN? > Options include: > No host changes. > Only configuration required in the host. > New code is acceptable, but no protocol changes (the motivation for this > could include to interop with other devices already using the existent > protocol) > Protocol extensions are acceptable. >=20 > 3)- What capabilities need to be controlled by the network? > When the MN performs a handover from one interface to another one? > How the node distributes the load among interfaces? in which direction? > Which flow is routed through which interface? in which direction? >=20 > Hope this helps... >=20 > regards, marcelo >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Wed Jul 1 15:47:04 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781013A6884 for ; Wed, 1 Jul 2009 15:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0w3lpti-06j for ; Wed, 1 Jul 2009 15:47:03 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 9DB323A6802 for ; Wed, 1 Jul 2009 15:47:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id B15DF90009 for ; Wed, 1 Jul 2009 18:47:21 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01001-07 for ; Wed, 1 Jul 2009 18:47:21 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 1 Jul 2009 18:47:21 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 18:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jul 2009 18:47:21 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609ECF37F@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMA== References: <4D35478224365146822AE9E3AD4A2666093829E1$0001@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 01 Jul 2009 22:47:21.0158 (UTC) FILETIME=[E4C33E60:01C9FA9D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:47:04 -0000 =20 > > RKo> I suggested "no host protocol changes" for stating the it=20 > > RKo> precisely. It > > was not meant to say we should endorse the statement. >=20 > =3D> Ok but I'm asking for your opinion on what the requirement=20 > should be. Is your opinion that the requirement should be "no=20 > protocol support in the host"? >=20 No, we should not rule out protocol extensions which may be needed for a feature to work (just as an example, informing a mobile node that a flow is moving to another interface - I would like to have such indications at L2 whenever possible) The requirement should be "no L3 mobility protocol changes in the host". -Rajeev > Hesham >=20 >=20 >=20 >=20 From rkoodli@starentnetworks.com Wed Jul 1 15:57:49 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123613A697C for ; Wed, 1 Jul 2009 15:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9HNeKcPKmP9 for ; Wed, 1 Jul 2009 15:57:47 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 065AB3A6802 for ; Wed, 1 Jul 2009 15:57:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 078B09002D for ; Wed, 1 Jul 2009 18:58:06 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01687-10 for ; Wed, 1 Jul 2009 18:58:02 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 1 Jul 2009 18:58:02 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 18:57:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jul 2009 18:57:56 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609ECF38E@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYqABMlAnAABu917wAEel9AAAkr40A= References: From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 01 Jul 2009 22:57:56.0559 (UTC) FILETIME=[5F7DBDF0:01C9FA9F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:57:49 -0000 Hi Kevin, =20 > Agreed, carriers manage mobility on both sides and at multiple layers. > From my point of view (at least for this discussion) I only care about > L3 and assume that any lower-layer mobility is hidden from=20 > me. On the other hand, I think it is important, if not=20 > necessary, that L1/L2 information be available to L3 and=20 > above in order to make HO functions more robust. Yes, such indications could include the network informing the MN to use a different interface for a particular traffic flow. >=20 > Also, I tend to think that network-based mobility (e.g.=20 > PMIP6) should be network-based and not place requirements on=20 > the MN. Similarly, if you are going to make a requirement on=20 > the MN, you might as well go all-in and make it CMIP. Of=20 > course, there are implications on memory, CPU, etc. > so my all or nothing approach is probably not a very practical one.=20 >=20 Perhaps implicit here is the distinction between changes to mobility protocol that affects the MN and extensions in general (such as the ability to inform a MN to use a different i/f for a particular traffic flow). I agree that MN should still be unaware of how its mobility is managed. We should also allow for "supplementary" (for the lack of a better word) extensions (which may need to be done L3). Regards, -Rajeev > --kan-- > -- > Kevin A. Noll >=20 >=20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, July 01, 2009 12:26 PM > To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft=20 > of the bof description >=20 > Kevin,=20 >=20 > Thanks for the input. I understand where you're coming from=20 > and I have two small comments to make. >=20 > First I think you're assuming that mobility support for the=20 > multihoming scenario we're discussing must be done in the=20 > kernel. This is not the case at all. Things can be done in=20 > user space as an add-on application. >=20 > Second, you made this comment: >=20 > > 4. At least some carriers prefer to manage mobility inside=20 > the network=20 > > rather than on the customer device. This is something that we are=20 > > constantly discussing internal to our organization, with=20 > vendors, and=20 > > with other operators. >=20 > =3D> To be precise, all carriers manage mobility from both the=20 > network and host sides. It's just not L3 mobility. So the=20 > question should be whether it is acceptable to manage L3=20 > mobility on both sides as well. And there is pretty good=20 > reasons for doing that, especially that most mobile devices=20 > today have multiple interfaces to different technologies,=20 > which never happened before.=20 >=20 > Hesham >=20 >=20 > On 1/07/09 11:52 PM, "Noll, Kevin" wrote: >=20 > > I've been lurking here for a while watching the=20 > conversation. Please=20 > > accept my apologies for dropping in unexpectedly, but I thought I > might > > give at least one operator's viewpoint. > >=20 > > You are correct that most data cards being sold today=20 > require you to=20 > > install the carrier's software. This software typically contains a=20 > > connection manager and the OS drivers required to operate the data > card. > > Technically speaking, the data cards that I have worked with do not > all > > *require* the connection manager to operate, though it varies from > card > > to card. Obviously, though, they *do* need the drivers. > >=20 > > What we saw with WiFi was a technology that began as an=20 > add-on to our=20 > > computing devices (laptops, etc.). WiFi grew, matured, and=20 > became so=20 > > widely accepted that operating systems began to ship with native=20 > > drivers, the add-on device became integrated into the computing > devices > > and we no longer needed to install 3rd-party drivers or connection=20 > > software. > >=20 > > As a network provider/operator, we like this model because=20 > it is very=20 > > expensive to write and maintain the connection software and drivers > and > > keep the user's device up to date. Adding a mobility stack to the=20 > > software being installed adds significantly to this cost. We are > seeing > > the cost come down, but there's still the issue of=20 > configuration and=20 > > what-not. > >=20 > > We expect to see open networks and technologies like WiMAX (and > possibly > > LTE) change the traditional cellular data-card model to one that is > more > > similar to WiFi, hopefully driving down the cost of the=20 > software and=20 > > moving the software development tasks out of the operator=20 > and into the=20 > > OS vendor community. > >=20 > > This said, I think it would be a mistake to make any assumptions on=20 > > either of the two points mentioned below. > >=20 > > 1. In the future the carrier may not deliver software with the data=20 > > card, so it's probably a bad assumption to say that the=20 > carrier would=20 > > simply deliver a mobility stack with the device. > >=20 > > 2. It's probably a good assumption to say that devices will=20 > eventually=20 > > have native mobility stacks. We are already seeing this=20 > development in=20 > > mainstream operating systems. This is similar to the evolution of > WiFi. > >=20 > > 3. It's probably not a good assumption to say that *all*=20 > devices will=20 > > have the perfect combination of native support or carrier support. > >=20 > > 4. At least some carriers prefer to manage mobility inside=20 > the network=20 > > rather than on the customer device. This is something that we are=20 > > constantly discussing internal to our organization, with=20 > vendors, and=20 > > with other operators. > >=20 > > Based on this, the case for extending the functionality of PMIP6 is=20 > > pretty strong, at least in my opinion. > >=20 > > On the other hand, we will also continue following the=20 > development of=20 > > native stacks and evaluate when and how best to use them in our > product > > offerings. Similarly, we will continue to evaluate whether=20 > or not we=20 > > need to deliver a mobility stack with our data card software. > >=20 > > Thanks! > >=20 > > --kan-- > > -- > > Kevin A. Noll > >=20 > >=20 > >=20 > > P Go Green! Print this email only when necessary. Thank you for > helping Time > > Warner Cable be environmentally responsible. > > =20 > > =20 > > -----Original Message----- > > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > Behalf > > Of Hesham Soliman > > Sent: Tuesday, June 30, 2009 11:59 PM > > To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es > > Cc: netext@ietf.org; netlmm@ietf.org > > Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft=20 > of the bof=20 > > description > >=20 > >=20 > > Hi Raj, > >=20 > > I had a brief offline chat with Julien and thought that I=20 > could refine=20 > > my suggestion a bit more to make the point clearer. My point is that > there > > are > > currently two slightly different points being made about the > requirement > > on > > host involvement 1) no SW on the host and the more nuanced 2) no=20 > > protocol support on the host. I won't even get into the reasons for=20 > > point 2) above and I'll let the people who raise it provide those=20 > > reasons, I can't figure out any technical reasons there. > >=20 > > Anyway, my point is that 1) above is not an issue today because it=20 > > already happens on a very large scale, so requiring it for=20 > a specific=20 > > feature like multihoming is hardly a leap. I can imagine ads for=20 > > "download your wireless optimiser from wwww.operator.com and save=20 > > money" (ok not very > creative). > > The subtle difference between 1) and 2) is IMO a moot point anyway=20 > > because > > 2) simply says that operators don't want protocol support in the=20 > > network, but that support already exists in the form of PMIP and if=20 > > you have > PMIP > > you > > have MIP. So, both motivations seem to be on shaky ground. > > And yes, you can of course integrate 3G modems in computers, but you > can > > also integrate mobility code in the same computers with the 3G > support. > > The > > SW that is provided with the modems is not only connection SW it=20 > > actually provides a number of features (e.g. Receiving SMS, account > information, > > email ....etc) so it's a clear move by operators to be present on > those > > machines. I don't think it's anything like WLAN connctions SW. > >=20 > > Of course it's worth mentioning that the elephant in the=20 > room is the=20 > > binary requirement on host support of protocols. We need to have a=20 > > yes/no answer as to whether there is a requirement to NOT have=20 > > protocol support in the host. > > At the moment this is being kept very vague. > >=20 > > Hesham > >=20 > >>> =3D> No one I know can get a 3G data card to access the=20 > Internet from > > their PC > >>> without having to install a piece of software on their PC to make > it > > work. > >>> So I think your assumption that the operator cannot=20 > mandate software > > on the > >>> host is questionable, because they already do (unfortunately). > >>=20 > >> The situation that you describe above was the same when=20 > 802.11 first > > rolled > >> around as well. > >> You had to install a piece of software that came with the PC card. > But > > that > >> has changed with > >> wifi now being an integral part of the notebook computers. > >> And I think you could expect 3G chipsets and access=20 > built-in as well > > in due > >> course of time. At least I know of a few operators in the=20 > US (as well=20 > >> as notebook manufacturers) who offer > such > >> net/notebook computers, > >> i.e with integrated 3G access. I do not know what additional sw is > > loaded on > >> these but at least the end user > >> is not installing anything else. > >> Does it imply that such hosts will include the software that would > > enable host > >> mobility? Its an open question (i.e unknown) and will=20 > depend largely=20 > >> on operator choices and vendors. > >>=20 > >> -Raj > >>=20 > >>> Hesham > >>=20 > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/netlmm > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > > This E-mail and any of its attachments may contain Time=20 > Warner Cable=20 > > proprietary information, which is privileged, confidential,=20 > or subject=20 > > to copyright belonging to Time Warner Cable. This E-mail is=20 > intended=20 > > solely for the use of the individual or entity to which it is=20 > > addressed. If you are not the intended recipient of this=20 > E-mail, you=20 > > are hereby notified that any dissemination, distribution,=20 > copying, or=20 > > action taken in relation to the contents of and attachments to this=20 > > E-mail is strictly prohibited and may be unlawful. If you have=20 > > received this E-mail in error, please notify the sender immediately=20 > > and permanently delete the original and any copy of this E-mail and=20 > > any printout. > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 >=20 > This E-mail and any of its attachments may contain Time=20 > Warner Cable proprietary information, which is privileged,=20 > confidential, or subject to copyright belonging to Time=20 > Warner Cable. This E-mail is intended solely for the use of=20 > the individual or entity to which it is addressed. If you are=20 > not the intended recipient of this E-mail, you are hereby=20 > notified that any dissemination, distribution, copying, or=20 > action taken in relation to the contents of and attachments=20 > to this E-mail is strictly prohibited and may be unlawful. If=20 > you have received this E-mail in error, please notify the=20 > sender immediately and permanently delete the original and=20 > any copy of this E-mail and any printout. >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From rkoodli@starentnetworks.com Wed Jul 1 16:02:04 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF2B3A6A25; Wed, 1 Jul 2009 16:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbbVtxy2OV24; Wed, 1 Jul 2009 16:02:03 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 8653D28C113; Wed, 1 Jul 2009 16:02:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 9EB619009C; Wed, 1 Jul 2009 19:02:22 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01112-16; Wed, 1 Jul 2009 19:02:22 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Wed, 1 Jul 2009 19:02:22 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 19:02:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jul 2009 19:02:17 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609ECF396@exchtewks3.starentnetworks.com> In-Reply-To: <4A4B570E.5090301@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn6R9drnK83Eek2QQa5gE9wGd14YwAWKiog References: <4A4A3BD3.1040703@it.uc3m.es> <4D35478224365146822AE9E3AD4A266609E3BF87$0001@exchtewks3.starentnetworks.com> <4A4B570E.5090301@it.uc3m.es> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 01 Jul 2009 23:02:17.0998 (UTC) FILETIME=[FB522AE0:01C9FA9F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:02:04 -0000 Hi Marcelo,=20 > > As a starting point, the host is not involved in mobility management > > (aka, managing persistence and reachability). > > =20 > right, this is what i was asking >=20 > So, i think this can be defined in terms of what is in=20 > control of the network, correct? > So, would it make sense to define this as a requirement that=20 > it must be network that decides through wich interface the=20 > node sends traffic In particular, it is the network side that decides: > - when the node performs a handoff to the other interface > - how the traffic is distributed among interfaces > - which flow flows through each interface >=20 > Is that what you have in mind? Yes, this is a good formulation.=20 Thanks, -Rajeev From hesham@elevatemobile.com Wed Jul 1 17:31:20 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600703A67D8; Wed, 1 Jul 2009 17:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OPlgKfCJ0kz; Wed, 1 Jul 2009 17:31:18 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 7B3FB3A6941; Wed, 1 Jul 2009 17:31:17 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MMADA-0004JY-3A; Thu, 02 Jul 2009 10:31:36 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 10:31:31 +1000 From: Hesham Soliman To: "Noll, Kevin" , , Message-ID: Thread-Topic: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn5kqjXH9wejvH2ykym7Pqo3qqaXgACA+CbABI6J3sABjOLyQAA9SYqABMlAnAABu917wAEel9AAAx8udg= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 00:31:20 -0000 > Also, I tend to think that network-based mobility (e.g. PMIP6) should be > network-based and not place requirements on the MN. Similarly, if you > are going to make a requirement on the MN, you might as well go all-in > and make it CMIP. => I agree with this. I think it's a practical approach to do that, at least from a requirements point of view. I personally don't believe you can use PMIP to support multihoming, flow movements ....etc but as far as requirements go this is sensible because it's sticking for the reasons with going to PMIP in the first place. Of course, there are implications on memory, CPU, etc. > so my all or nothing approach is probably not a very practical one. => I wouldn't worry about memory/CPU requirements for MIP with today's 3G devices, by the time it's implemented it will be an insignificant part of the memory on a phone, not to mention a PC. Hesham > > --kan-- > -- > Kevin A. Noll > > > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Wednesday, July 01, 2009 12:26 PM > To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof > description > > Kevin, > > Thanks for the input. I understand where you're coming from and I have > two > small comments to make. > > First I think you're assuming that mobility support for the multihoming > scenario we're discussing must be done in the kernel. This is not the > case > at all. Things can be done in user space as an add-on application. > > Second, you made this comment: > >> 4. At least some carriers prefer to manage mobility inside the network >> rather than on the customer device. This is something that we are >> constantly discussing internal to our organization, with vendors, and >> with other operators. > > => To be precise, all carriers manage mobility from both the network and > host sides. It's just not L3 mobility. So the question should be whether > it > is acceptable to manage L3 mobility on both sides as well. And there is > pretty good reasons for doing that, especially that most mobile devices > today have multiple interfaces to different technologies, which never > happened before. > > Hesham > > > On 1/07/09 11:52 PM, "Noll, Kevin" wrote: > >> I've been lurking here for a while watching the conversation. Please >> accept my apologies for dropping in unexpectedly, but I thought I > might >> give at least one operator's viewpoint. >> >> You are correct that most data cards being sold today require you to >> install the carrier's software. This software typically contains a >> connection manager and the OS drivers required to operate the data > card. >> Technically speaking, the data cards that I have worked with do not > all >> *require* the connection manager to operate, though it varies from > card >> to card. Obviously, though, they *do* need the drivers. >> >> What we saw with WiFi was a technology that began as an add-on to our >> computing devices (laptops, etc.). WiFi grew, matured, and became so >> widely accepted that operating systems began to ship with native >> drivers, the add-on device became integrated into the computing > devices >> and we no longer needed to install 3rd-party drivers or connection >> software. >> >> As a network provider/operator, we like this model because it is very >> expensive to write and maintain the connection software and drivers > and >> keep the user's device up to date. Adding a mobility stack to the >> software being installed adds significantly to this cost. We are > seeing >> the cost come down, but there's still the issue of configuration and >> what-not. >> >> We expect to see open networks and technologies like WiMAX (and > possibly >> LTE) change the traditional cellular data-card model to one that is > more >> similar to WiFi, hopefully driving down the cost of the software and >> moving the software development tasks out of the operator and into the >> OS vendor community. >> >> This said, I think it would be a mistake to make any assumptions on >> either of the two points mentioned below. >> >> 1. In the future the carrier may not deliver software with the data >> card, so it's probably a bad assumption to say that the carrier would >> simply deliver a mobility stack with the device. >> >> 2. It's probably a good assumption to say that devices will eventually >> have native mobility stacks. We are already seeing this development in >> mainstream operating systems. This is similar to the evolution of > WiFi. >> >> 3. It's probably not a good assumption to say that *all* devices will >> have the perfect combination of native support or carrier support. >> >> 4. At least some carriers prefer to manage mobility inside the network >> rather than on the customer device. This is something that we are >> constantly discussing internal to our organization, with vendors, and >> with other operators. >> >> Based on this, the case for extending the functionality of PMIP6 is >> pretty strong, at least in my opinion. >> >> On the other hand, we will also continue following the development of >> native stacks and evaluate when and how best to use them in our > product >> offerings. Similarly, we will continue to evaluate whether or not we >> need to deliver a mobility stack with our data card software. >> >> Thanks! >> >> --kan-- >> -- >> Kevin A. Noll >> >> >> >> P Go Green! Print this email only when necessary. Thank you for > helping Time >> Warner Cable be environmentally responsible. >> >> >> -----Original Message----- >> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > Behalf >> Of Hesham Soliman >> Sent: Tuesday, June 30, 2009 11:59 PM >> To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es >> Cc: netext@ietf.org; netlmm@ietf.org >> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof >> description >> >> >> Hi Raj, >> >> I had a brief offline chat with Julien and thought that I could refine >> my >> suggestion a bit more to make the point clearer. My point is that > there >> are >> currently two slightly different points being made about the > requirement >> on >> host involvement 1) no SW on the host and the more nuanced 2) no >> protocol >> support on the host. I won't even get into the reasons for point 2) >> above >> and I'll let the people who raise it provide those reasons, I can't >> figure >> out any technical reasons there. >> >> Anyway, my point is that 1) above is not an issue today because it >> already >> happens on a very large scale, so requiring it for a specific feature >> like >> multihoming is hardly a leap. I can imagine ads for "download your >> wireless >> optimiser from wwww.operator.com and save money" (ok not very > creative). >> The subtle difference between 1) and 2) is IMO a moot point anyway >> because >> 2) simply says that operators don't want protocol support in the >> network, >> but that support already exists in the form of PMIP and if you have > PMIP >> you >> have MIP. So, both motivations seem to be on shaky ground. >> And yes, you can of course integrate 3G modems in computers, but you > can >> also integrate mobility code in the same computers with the 3G > support. >> The >> SW that is provided with the modems is not only connection SW it >> actually >> provides a number of features (e.g. Receiving SMS, account > information, >> email ....etc) so it's a clear move by operators to be present on > those >> machines. I don't think it's anything like WLAN connctions SW. >> >> Of course it's worth mentioning that the elephant in the room is the >> binary >> requirement on host support of protocols. We need to have a yes/no >> answer as >> to whether there is a requirement to NOT have protocol support in the >> host. >> At the moment this is being kept very vague. >> >> Hesham >> >>>> => No one I know can get a 3G data card to access the Internet from >> their PC >>>> without having to install a piece of software on their PC to make > it >> work. >>>> So I think your assumption that the operator cannot mandate software >> on the >>>> host is questionable, because they already do (unfortunately). >>> >>> The situation that you describe above was the same when 802.11 first >> rolled >>> around as well. >>> You had to install a piece of software that came with the PC card. > But >> that >>> has changed with >>> wifi now being an integral part of the notebook computers. >>> And I think you could expect 3G chipsets and access built-in as well >> in due >>> course of time. At least I know of a few >>> operators in the US (as well as notebook manufacturers) who offer > such >>> net/notebook computers, >>> i.e with integrated 3G access. I do not know what additional sw is >> loaded on >>> these but at least the end user >>> is not installing anything else. >>> Does it imply that such hosts will include the software that would >> enable host >>> mobility? Its an open question (i.e unknown) >>> and will depend largely on operator choices and vendors. >>> >>> -Raj >>> >>>> Hesham >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www.ietf.org/mailman/listinfo/netlmm >> This E-mail and any of its attachments may contain Time Warner >> Cable proprietary information, which is privileged, confidential, >> or subject to copyright belonging to Time Warner Cable. This E-mail >> is intended solely for the use of the individual or entity to which >> it is addressed. If you are not the intended recipient of this >> E-mail, you are hereby notified that any dissemination, >> distribution, copying, or action taken in relation to the contents >> of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > > This E-mail and any of its attachments may contain Time Warner > Cable proprietary information, which is privileged, confidential, > or subject to copyright belonging to Time Warner Cable. This E-mail > is intended solely for the use of the individual or entity to which > it is addressed. If you are not the intended recipient of this > E-mail, you are hereby notified that any dissemination, > distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From hesham@elevatemobile.com Wed Jul 1 19:12:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D53A3A699E for ; Wed, 1 Jul 2009 19:12:08 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiJLbrkH-xFk for ; Wed, 1 Jul 2009 19:12:07 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4DA9F3A6C36 for ; Wed, 1 Jul 2009 19:12:06 -0700 (PDT) Received: from [122.110.187.128] (helo=[192.168.0.3]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MMBmU-00016b-9L; Thu, 02 Jul 2009 12:12:10 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 12:11:57 +1000 From: Hesham Soliman To: "Koodli, Rajeev" , Message-ID: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMAAHL4SG In-Reply-To: <4D35478224365146822AE9E3AD4A266609ECF37F@exchtewks3.starentnetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 02:12:08 -0000 On 2/07/09 8:47 AM, "Koodli, Rajeev" wrote: > > >>> RKo> I suggested "no host protocol changes" for stating the it >>> RKo> precisely. It >>> was not meant to say we should endorse the statement. >> >> => Ok but I'm asking for your opinion on what the requirement >> should be. Is your opinion that the requirement should be "no >> protocol support in the host"? >> > > No, we should not rule out protocol extensions which may be needed for a > feature to work (just as an example, informing a mobile node that a flow > is moving to another interface - I would like to have such indications > at L2 whenever possible) > > The requirement should be "no L3 mobility protocol changes in the host". => In that case your requirement contradicts your own words above it, not to mention, it's a silly requirement to make because you seem to have a strange idea about what mobility protocol means (almost something like mobility protocol = binding update) and none of the reasons for eliminating the host from the conversation apply here. Actually, what you say above doesn't amount to a requirement, it's how you think things should be done. It's going to be very hard to answer the "why" part given the above. It's disappointing that this work has not progressed even to the point of producing decent requirements given the amount of attention it's getting on the mailing list. Hesham > > -Rajeev > > >> Hesham >> >> >> >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From hesham@elevatemobile.com Wed Jul 1 21:34:56 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8163A6B5C for ; Wed, 1 Jul 2009 21:34:56 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQuzqGZYD6oF for ; Wed, 1 Jul 2009 21:34:55 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id BEDD43A67E1 for ; Wed, 1 Jul 2009 21:34:54 -0700 (PDT) Received: from [114.75.11.124] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MME0h-00014w-M9; Thu, 02 Jul 2009 14:35:02 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 14:34:47 +1000 From: Hesham Soliman To: , , Message-ID: Thread-Topic: [netext] Questions for defining the NETEXT2 problem space Thread-Index: Acn6XnEx92kXYFQfQsqYVrrUbHjNjQAMhYrcAA95oBw= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] Questions for defining the NETEXT2 problem space X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:34:56 -0000 On 2/07/09 7:11 AM, "Basavaraj.Patil@nokia.com" wrote: > >> Hi, >> >> After the discussion so far, i have identified the following question >> for which i think it would be important to provide answer to define the >> requirements of the problems we are trying to tackle. >> >> As stated earlier, the goal of this questions is to try to define the >> "what are we trying to achieve?" question. >> >> Once we have a set of answers, we will need to do the "Why?" part. >> >> So, this is work in progress, but i woudl appreciate input in terms of >> modificatiosn to the questions, answers to the questions and more questions. >> >> Questions: >> >> 1)- What L2 technologies are supported? All the L2 technologies? A >> subset of L2 technologies? > > I don't think we should be developing solutions for some subset of L2 > technologies. I think the discussion of what L2s are applicable in the > context of this discussion is a rat-hole. => I agree with Raj on this. Hesham From rkoodli@starentnetworks.com Wed Jul 1 22:54:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9933A6811 for ; Wed, 1 Jul 2009 22:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBB7wQFDZ00F for ; Wed, 1 Jul 2009 22:54:18 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 650083A6CE3 for ; Wed, 1 Jul 2009 22:54:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 9471B90043 for ; Thu, 2 Jul 2009 01:54:24 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32664-17 for ; Thu, 2 Jul 2009 01:54:22 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 2 Jul 2009 01:54:22 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 01:54:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2009 01:54:22 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609ECF4B4@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMAAHL4SGAAeHRFA= References: <4D35478224365146822AE9E3AD4A266609ECF37F@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 02 Jul 2009 05:54:22.0638 (UTC) FILETIME=[8C5AD4E0:01C9FAD9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 05:54:19 -0000 I guess it was not clear.. I did not suggest that "no host protocol changes" should be a requirement, but a better use than saying "no host changes".=20 I think we are making progress. We (at least many folks) are receptive to 1) relying on L2 capabilities as much as possible, 2) using host configurations to address some of the issues, and 3) not ruling out L3 extensions without changing the PMIP mobility model (i.e., the MN is not involved in mobility management of persistence and reachbility). Please see Marcelo's e-mail below; it seems like a good formulation to me. -Rajeev > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Wednesday, July 01, 2009 5:31 AM > To: Koodli, Rajeev > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org; netlmm@ietf.org > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft=20 > of the bofdescription >=20 [snip] > > =20 > right, this is what i was asking >=20 > So, i think this can be defined in terms of what is in=20 > control of the network, correct? > So, would it make sense to define this as a requirement that=20 > it must be network that decides through wich interface the=20 > node sends traffic In particular, it is the network side that decides: > - when the node performs a handoff to the other interface > - how the traffic is distributed among interfaces > - which flow flows through each interface >=20 > Is that what you have in mind? >=20 > Regards, marcelo >=20 =20 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com]=20 > Sent: Wednesday, July 01, 2009 7:12 PM > To: Koodli, Rajeev; netext@ietf.org > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft=20 > of the bof description >=20 >=20 >=20 >=20 > On 2/07/09 8:47 AM, "Koodli, Rajeev"=20 > wrote: >=20 > > =20 > >=20 > >>> RKo> I suggested "no host protocol changes" for stating the it=20 > >>> RKo> precisely. It > >>> was not meant to say we should endorse the statement. > >>=20 > >> =3D> Ok but I'm asking for your opinion on what the=20 > requirement should=20 > >> be. Is your opinion that the requirement should be "no protocol=20 > >> support in the host"? > >>=20 > >=20 > > No, we should not rule out protocol extensions which may be=20 > needed for=20 > > a feature to work (just as an example, informing a mobile=20 > node that a=20 > > flow is moving to another interface - I would like to have such=20 > > indications at L2 whenever possible) > >=20 > > The requirement should be "no L3 mobility protocol changes=20 > in the host". >=20 > =3D> In that case your requirement contradicts your own words=20 > above it, not to mention, it's a silly requirement to make=20 > because you seem to have a strange idea about what mobility=20 > protocol means (almost something like mobility protocol =3D=20 > binding update) and none of the reasons for eliminating the=20 > host from the conversation apply here. Actually, what you say=20 > above doesn't amount to a requirement, it's how you think=20 > things should be done. It's going to be very hard to answer=20 > the "why" part given the above. >=20 > It's disappointing that this work has not progressed even to=20 > the point of producing decent requirements given the amount=20 > of attention it's getting on the mailing list.=20 >=20 > Hesham >=20 >=20 > >=20 > > -Rajeev > >=20 > >=20 > >> Hesham > >>=20 > >>=20 > >>=20 > >>=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 >=20 >=20 From Mohana.Jeyatharan@sg.panasonic.com Wed Jul 1 23:11:17 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D3B3A69B8 for ; Wed, 1 Jul 2009 23:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYPF34sVZykk for ; Wed, 1 Jul 2009 23:11:14 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id C7B963A68EB for ; Wed, 1 Jul 2009 23:09:59 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id n626AKBX029515; Thu, 2 Jul 2009 15:10:20 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id n626AIV08675; Thu, 2 Jul 2009 15:10:19 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2009 14:07:29 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD036EED97@pslexc01.psl.local> In-reply-to: <4D35478224365146822AE9E3AD4A266609ECF4B4@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMAAHL4SGAAeHRFAAAHF1YA== From: "Mohana Jeyatharan" To: "Koodli, Rajeev" , Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 06:11:17 -0000 Hi all, The below classification on requirements looks really good.=20 1) relying on L2 capabilities as much as possible, 2) using host > configurations to address some of the issues, and 3) not ruling out L3 > extensions without changing the PMIP mobility model One more point, the mobile node should be able to indicate flow prefernce, handoff indication etc to the network and the final decision can be made by the network. At least we should cater for mobile node indicating its prefernce to the network. As some of us have described in the ML, this should be supported. However, I am fine with the fact that the final decsion can be made by the network.=20 Thanks. BR, Mohana =20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Koodli, Rajeev > Sent: Thursday, July 02, 2009 1:54 PM > To: netext@ietf.org > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the > bofdescription >=20 >=20 > I guess it was not clear.. I did not suggest that "no host protocol > changes" should be a requirement, but a better use than saying "no host > changes". >=20 > I think we are making progress. We (at least many folks) are receptive > to 1) relying on L2 capabilities as much as possible, 2) using host > configurations to address some of the issues, and 3) not ruling out L3 > extensions without changing the PMIP mobility model (i.e., the MN is not > involved in mobility management of persistence and reachbility). Please > see Marcelo's e-mail below; it seems like a good formulation to me. >=20 > -Rajeev >=20 >=20 > > -----Original Message----- > > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > > Sent: Wednesday, July 01, 2009 5:31 AM > > To: Koodli, Rajeev > > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org; netlmm@ietf.org > > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft > > of the bofdescription > > > [snip] > > > > > right, this is what i was asking > > > > So, i think this can be defined in terms of what is in > > control of the network, correct? > > So, would it make sense to define this as a requirement that > > it must be network that decides through wich interface the > > node sends traffic In particular, it is the network side that decides: > > - when the node performs a handoff to the other interface > > - how the traffic is distributed among interfaces > > - which flow flows through each interface > > > > Is that what you have in mind? > > > > Regards, marcelo > > >=20 > > -----Original Message----- > > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > > Sent: Wednesday, July 01, 2009 7:12 PM > > To: Koodli, Rajeev; netext@ietf.org > > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft > > of the bof description > > > > > > > > > > On 2/07/09 8:47 AM, "Koodli, Rajeev" > > wrote: > > > > > > > > > > >>> RKo> I suggested "no host protocol changes" for stating the it > > >>> RKo> precisely. It > > >>> was not meant to say we should endorse the statement. > > >> > > >> =3D> Ok but I'm asking for your opinion on what the > > requirement should > > >> be. Is your opinion that the requirement should be "no protocol > > >> support in the host"? > > >> > > > > > > No, we should not rule out protocol extensions which may be > > needed for > > > a feature to work (just as an example, informing a mobile > > node that a > > > flow is moving to another interface - I would like to have such > > > indications at L2 whenever possible) > > > > > > The requirement should be "no L3 mobility protocol changes > > in the host". > > > > =3D> In that case your requirement contradicts your own words > > above it, not to mention, it's a silly requirement to make > > because you seem to have a strange idea about what mobility > > protocol means (almost something like mobility protocol =3D > > binding update) and none of the reasons for eliminating the > > host from the conversation apply here. Actually, what you say > > above doesn't amount to a requirement, it's how you think > > things should be done. It's going to be very hard to answer > > the "why" part given the above. > > > > It's disappointing that this work has not progressed even to > > the point of producing decent requirements given the amount > > of attention it's getting on the mailing list. > > > > Hesham > > > > > > > > > > -Rajeev > > > > > > > > >> Hesham > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > netext mailing list > > > netext@ietf.org > > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From hesham@elevatemobile.com Wed Jul 1 23:16:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495363A687C for ; Wed, 1 Jul 2009 23:16:57 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfQX+1B0plRy for ; Wed, 1 Jul 2009 23:16:56 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 298F13A6D31 for ; Wed, 1 Jul 2009 23:15:37 -0700 (PDT) Received: from [114.75.11.124] (helo=[192.168.0.2]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MMFaN-0007vu-8P; Thu, 02 Jul 2009 16:15:56 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 16:15:44 +1000 From: Hesham Soliman To: Mohana Jeyatharan , "Koodli, Rajeev" , Message-ID: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMAAHL4SGAAeHRFAAAHF1YAAAit/C In-Reply-To: <5F09D220B62F79418461A978CA0921BD036EED97@pslexc01.psl.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 06:16:57 -0000 On 2/07/09 4:07 PM, "Mohana Jeyatharan" wrote: > Hi all, > > The below classification on requirements looks really good. > 1) relying on L2 capabilities as much as possible, 2) using host >> configurations to address some of the issues, and 3) not ruling out L3 >> extensions without changing the PMIP mobility model > > One more point, the mobile node should be able to indicate flow > prefernce, handoff indication etc to the network and the final decision > can be made by the network. At least we should cater for mobile node > indicating its prefernce to the network. => Agree, but you're contradicting the paragraph you're quoting above, which you said "looks really good"..... Hesham As some of us have described in > the ML, this should be supported. However, I am fine with the fact that > the final decsion can be made by the network. > > Thanks. > > BR, > Mohana > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf >> Of Koodli, Rajeev >> Sent: Thursday, July 02, 2009 1:54 PM >> To: netext@ietf.org >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the >> bofdescription >> >> >> I guess it was not clear.. I did not suggest that "no host protocol >> changes" should be a requirement, but a better use than saying "no > host >> changes". >> >> I think we are making progress. We (at least many folks) are receptive >> to 1) relying on L2 capabilities as much as possible, 2) using host >> configurations to address some of the issues, and 3) not ruling out L3 >> extensions without changing the PMIP mobility model (i.e., the MN is > not >> involved in mobility management of persistence and reachbility). > Please >> see Marcelo's e-mail below; it seems like a good formulation to me. >> >> -Rajeev >> >> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: Wednesday, July 01, 2009 5:31 AM >>> To: Koodli, Rajeev >>> Cc: Basavaraj.Patil@nokia.com; netext@ietf.org; netlmm@ietf.org >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >>> of the bofdescription >>> >> [snip] >>>> >>> right, this is what i was asking >>> >>> So, i think this can be defined in terms of what is in >>> control of the network, correct? >>> So, would it make sense to define this as a requirement that >>> it must be network that decides through wich interface the >>> node sends traffic In particular, it is the network side that > decides: >>> - when the node performs a handoff to the other interface >>> - how the traffic is distributed among interfaces >>> - which flow flows through each interface >>> >>> Is that what you have in mind? >>> >>> Regards, marcelo >>> >> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, July 01, 2009 7:12 PM >>> To: Koodli, Rajeev; netext@ietf.org >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >>> of the bof description >>> >>> >>> >>> >>> On 2/07/09 8:47 AM, "Koodli, Rajeev" >>> wrote: >>> >>>> >>>> >>>>>> RKo> I suggested "no host protocol changes" for stating the it >>>>>> RKo> precisely. It >>>>>> was not meant to say we should endorse the statement. >>>>> >>>>> => Ok but I'm asking for your opinion on what the >>> requirement should >>>>> be. Is your opinion that the requirement should be "no protocol >>>>> support in the host"? >>>>> >>>> >>>> No, we should not rule out protocol extensions which may be >>> needed for >>>> a feature to work (just as an example, informing a mobile >>> node that a >>>> flow is moving to another interface - I would like to have such >>>> indications at L2 whenever possible) >>>> >>>> The requirement should be "no L3 mobility protocol changes >>> in the host". >>> >>> => In that case your requirement contradicts your own words >>> above it, not to mention, it's a silly requirement to make >>> because you seem to have a strange idea about what mobility >>> protocol means (almost something like mobility protocol = >>> binding update) and none of the reasons for eliminating the >>> host from the conversation apply here. Actually, what you say >>> above doesn't amount to a requirement, it's how you think >>> things should be done. It's going to be very hard to answer >>> the "why" part given the above. >>> >>> It's disappointing that this work has not progressed even to >>> the point of producing decent requirements given the amount >>> of attention it's getting on the mailing list. >>> >>> Hesham >>> >>> >>>> >>>> -Rajeev >>>> >>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Mohana.Jeyatharan@sg.panasonic.com Wed Jul 1 23:51:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A4F3A69C8 for ; Wed, 1 Jul 2009 23:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApL7ID8crdIs for ; Wed, 1 Jul 2009 23:51:56 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 411823A6E06 for ; Wed, 1 Jul 2009 23:50:11 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id n626oSCI012843; Thu, 2 Jul 2009 15:50:28 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n626oSZ07371; Thu, 2 Jul 2009 15:50:28 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2009 14:45:26 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD036EEDC1@pslexc01.psl.local> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMAAHL4SGAAeHRFAAAHF1YAAAit/CAABuxaA= From: "Mohana Jeyatharan" To: "Hesham Soliman" , "Koodli, Rajeev" , Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 06:51:57 -0000 Hi Hesham, I meant, network can decide MN interface for flow mobility, handoff based on its own policies or MN provided information. So, just wanted to highlight that MN should be able to indicate its prefernce via signaling and as Marcelo pointed network must decide. Even if the network initiates flow mobility, we still need some host changes. So, I was refering to the host changes tied to the host initiating the flow mobility process by indicating its prefernce. Just wanted to highlight that this too needs to be supported. BR, Mohana > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, July 02, 2009 2:16 PM > To: Mohana Jeyatharan; Koodli, Rajeev; netext@ietf.org > Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the > bofdescription >=20 >=20 >=20 >=20 > On 2/07/09 4:07 PM, "Mohana Jeyatharan" > > wrote: >=20 > > Hi all, > > > > The below classification on requirements looks really good. > > 1) relying on L2 capabilities as much as possible, 2) using host > >> configurations to address some of the issues, and 3) not ruling out L3 > >> extensions without changing the PMIP mobility model > > > > One more point, the mobile node should be able to indicate flow > > prefernce, handoff indication etc to the network and the final decision > > can be made by the network. At least we should cater for mobile node > > indicating its prefernce to the network. >=20 > =3D> Agree, but you're contradicting the paragraph you're quoting = above, > which > you said "looks really good"..... >=20 > Hesham >=20 >=20 >=20 >=20 > As some of us have described in > > the ML, this should be supported. However, I am fine with the fact that > > the final decsion can be made by the network. > > > > Thanks. > > > > BR, > > Mohana > > > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > Behalf > >> Of Koodli, Rajeev > >> Sent: Thursday, July 02, 2009 1:54 PM > >> To: netext@ietf.org > >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the > >> bofdescription > >> > >> > >> I guess it was not clear.. I did not suggest that "no host protocol > >> changes" should be a requirement, but a better use than saying "no > > host > >> changes". > >> > >> I think we are making progress. We (at least many folks) are receptive > >> to 1) relying on L2 capabilities as much as possible, 2) using host > >> configurations to address some of the issues, and 3) not ruling out L3 > >> extensions without changing the PMIP mobility model (i.e., the MN is > > not > >> involved in mobility management of persistence and reachbility). > > Please > >> see Marcelo's e-mail below; it seems like a good formulation to me. > >> > >> -Rajeev > >> > >> > >>> -----Original Message----- > >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >>> Sent: Wednesday, July 01, 2009 5:31 AM > >>> To: Koodli, Rajeev > >>> Cc: Basavaraj.Patil@nokia.com; netext@ietf.org; netlmm@ietf.org > >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft > >>> of the bofdescription > >>> > >> [snip] > >>>> > >>> right, this is what i was asking > >>> > >>> So, i think this can be defined in terms of what is in > >>> control of the network, correct? > >>> So, would it make sense to define this as a requirement that > >>> it must be network that decides through wich interface the > >>> node sends traffic In particular, it is the network side that > > decides: > >>> - when the node performs a handoff to the other interface > >>> - how the traffic is distributed among interfaces > >>> - which flow flows through each interface > >>> > >>> Is that what you have in mind? > >>> > >>> Regards, marcelo > >>> > >> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>> Sent: Wednesday, July 01, 2009 7:12 PM > >>> To: Koodli, Rajeev; netext@ietf.org > >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft > >>> of the bof description > >>> > >>> > >>> > >>> > >>> On 2/07/09 8:47 AM, "Koodli, Rajeev" > >>> wrote: > >>> > >>>> > >>>> > >>>>>> RKo> I suggested "no host protocol changes" for stating the it > >>>>>> RKo> precisely. It > >>>>>> was not meant to say we should endorse the statement. > >>>>> > >>>>> =3D> Ok but I'm asking for your opinion on what the > >>> requirement should > >>>>> be. Is your opinion that the requirement should be "no protocol > >>>>> support in the host"? > >>>>> > >>>> > >>>> No, we should not rule out protocol extensions which may be > >>> needed for > >>>> a feature to work (just as an example, informing a mobile > >>> node that a > >>>> flow is moving to another interface - I would like to have such > >>>> indications at L2 whenever possible) > >>>> > >>>> The requirement should be "no L3 mobility protocol changes > >>> in the host". > >>> > >>> =3D> In that case your requirement contradicts your own words > >>> above it, not to mention, it's a silly requirement to make > >>> because you seem to have a strange idea about what mobility > >>> protocol means (almost something like mobility protocol =3D > >>> binding update) and none of the reasons for eliminating the > >>> host from the conversation apply here. Actually, what you say > >>> above doesn't amount to a requirement, it's how you think > >>> things should be done. It's going to be very hard to answer > >>> the "why" part given the above. > >>> > >>> It's disappointing that this work has not progressed even to > >>> the point of producing decent requirements given the amount > >>> of attention it's getting on the mailing list. > >>> > >>> Hesham > >>> > >>> > >>>> > >>>> -Rajeev > >>>> > >>>> > >>>>> Hesham > >>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>> > >>> > >>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 From huimin.cmcc@gmail.com Thu Jul 2 00:16:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E496F3A6B65 for ; Thu, 2 Jul 2009 00:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3sodZLwiCRQ for ; Thu, 2 Jul 2009 00:16:45 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id E41D23A68B0 for ; Thu, 2 Jul 2009 00:16:44 -0700 (PDT) Received: by pzk36 with SMTP id 36so1661230pzk.29 for ; Thu, 02 Jul 2009 00:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qFsZ2SBN2g5TVExXpnz4LkqvP10BCM/SDE+5MrbFzkM=; b=R47GtCFbo8YC0wm7sDYZhfGF/Y0Do9XvjVxAqhF2dIfNpxsePAq8thjxplkEnajTy9 nxXt+9eTMk7bkq1c5cb1/eftVzHs8kuBs0EeTGAvrzBvomCNbkIKvjDHaksJu311NMG5 JlrbnbqbB4KMsWEdTL3zbwPs902BifUlY602A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uZ8xs6gCtVTjPpTtmM2co71KTGIZye1KdqA4YYcJMlk3xs0Q6NMMYruu0UTnzULuh8 FQa1dcIsig/ePR8TSKK6SxbxmVCsQuirf7gGXm0HTitu/qA3RflnwjRqath7xPSAjx5z /HhcbuMtICPIDnWHwo9tpeov0U80SdpAyWoq8= MIME-Version: 1.0 Received: by 10.114.67.17 with SMTP id p17mr16521340waa.203.1246519025188; Thu, 02 Jul 2009 00:17:05 -0700 (PDT) In-Reply-To: <00ac01c9fa65$14c9a510$3e0c7c0a@china.huawei.com> References: <20090630030223.8997528C0E6@core3.amsl.com> <5dca10d30906292027h669edd1ene3070492547efac0@mail.gmail.com> <009301c9f9a5$c03b6d90$3e0c7c0a@china.huawei.com> <5dca10d30906302308k1efb3b57o48333a48ec77c2a7@mail.gmail.com> <00ac01c9fa65$14c9a510$3e0c7c0a@china.huawei.com> Date: Thu, 2 Jul 2009 15:17:05 +0800 Message-ID: <5dca10d30907020017v30897b35g88d64e8aec5e1198@mail.gmail.com> From: Min Hui To: Frank Xia Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Fwd: New Version Notification fordraft-hui-netext-service-flow-identifier-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:16:46 -0000 Hi Frank, Pls see my answer below. -hui min 2009/7/2 Frank Xia : > Hi Hui > > Please check my inline comments.. > > BR > Frank > ----- Original Message ----- From: "Min Hui" > To: "Frank Xia" > Cc: > Sent: Wednesday, July 01, 2009 1:08 AM > Subject: Re: [netext] Fwd: New Version Notification > fordraft-hui-netext-service-flow-identifier-00 > > > Hi, Frank Xia > > Thanks for your comments, please see my reply in line. > > - Hui Min > > 2009/7/1 Frank Xia : >> >> Hi Min >> >> I had a quick look at the document which >> looks clear. Some comments are below. >> >> 1)"multiple service flows of the mobile node can >> be separately controlled based on the service >> flow identifier in the Proxy Binding Update >> and Acknowledge messages" >> I could not find the motivation of separate >> controlling of a service. It is for traffic >> engineering, QoS enforcement or something else? >> > > It is used for content charging, QoS enforcement, etc. It is important > for operators to treat services separately. > Frank=3D>Agree. is possible for LMA > send a service flow identifier to MAG? service flow identifier is generated by MAG, LMA uses the SFID which is sent by MAG. It seems not necessary for LMA to send SFID to MAG. > >> 2)it is also not clear to me how the mobile >> node notifies the MAG the service type. >> It seems that the MAG identifies the service >> through data packets from the mobile node. >> Deep Packet Inspection technology is required >> for MAG? > > Yes, MAG is required to know the transport layer information. But I > guess the service type you mentioned refer to the "TOS" in the service > flow description. TOS is a field in the IP header, so DPI is not > necessary in this respect. > > Frank=3D>I did not mean "TOS"=A3=AC but appliactions (or flows). MN isn't modified to carry the service type notification. It's MAG itself to check the data packet and generate service flow option. So the service type (or applications as you mentioned) is learned by MAG but not MN. > > >> >> 3)What is the relationship between this draft >> and flow mobility being discussed in Netext BoF 2? >> They both have key words "flow" :-). >> > > We considered this question as well. This draft is about the > granularity of PMIPv6, it is an important part of PMIPv6, although it > is independent of flow mobility. So we are wondering whether the > NETEXT BOF can add the granularity issue into the scope. > >> >> BR >> Frank >> >> >> ----- Original Message ----- From: "Min Hui" >> To: >> Sent: Monday, June 29, 2009 10:27 PM >> Subject: [netext] Fwd: New Version Notification >> fordraft-hui-netext-service-flow-identifier-00 >> >> >>> Hi, all >>> >>> I have just submitted a new draft: >>> >>> >>> http://www.ietf.org/internet-drafts/draft-hui-netext-service-flow-ident= ifier-00.txt >>> >>> This draft defines a new Service Flow Identifier option carrying the >>> service flow identifier and service flow attributes in the Proxy >>> Binding Update and Acknowledgement message, so that the granularity of >>> PMIPv6 becomes per service flow basis. >>> >>> Any comment is welcomed. >>> Thanks a lot. >>> >>> -Hui Min >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: IETF I-D Submission Tool >>> Date: 2009/6/30 >>> Subject: New Version Notification for >>> draft-hui-netext-service-flow-identifier-00 >>> To: huimin.cmcc@gmail.com >>> =B3=AD=CB=CD=A3=BA chengang@chinamobile.com, denghui02@gmail.com >>> >>> >>> >>> A new version of I-D, draft-hui-netext-service-flow-identifier-00.txt >>> has been successfuly submitted by Min Hui and posted to the IETF >>> repository. >>> >>> Filename: draft-hui-netext-service-flow-identifier >>> Revision: 00 >>> Title: Service Flow Identifier in Proxy Mobile IPv6 >>> Creation_date: 2009-06-29 >>> WG ID: Independent Submission >>> Number_of_pages: 18 >>> >>> Abstract: >>> Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 >>> mobile node without requiring its participation in any mobility- >>> related signaling. This document introduces extensions to Proxy >>> Mobile IPv6 that allows network dynamically binding each service flow >>> to the mobile node, respectively. Therefore, multiple service flows >>> of the mobile node can be separately controlled based on the service >>> flow identifier in the Proxy Binding Update and Acknowledge messages. >>> >>> >>> >>> The IETF Secretariat. >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> > > From marcelo@it.uc3m.es Thu Jul 2 00:21:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E603A685C; Thu, 2 Jul 2009 00:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oPV3iGKGKTy; Thu, 2 Jul 2009 00:21:43 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 183593A6BDD; Thu, 2 Jul 2009 00:21:42 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp02.uc3m.es (Postfix) with ESMTP id 51F48655242; Thu, 2 Jul 2009 09:21:55 +0200 (CEST) Message-ID: <4A4C6012.6070602@it.uc3m.es> Date: Thu, 02 Jul 2009 09:21:54 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.004 Cc: netext@ietf.org, netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:21:44 -0000 Raj, in one mail you wrote Basavaraj.Patil@nokia.com escribió: > > Or there may be recommendations to L2s in which > case the IETF would only recommend some capabilities that L2 would be > required to have to provide these features. and then in another where is posed : Questions: > > 1)- What L2 technologies are supported? All the L2 technologies? A > subset of L2 technologies? You answered: I don't think we should be developing solutions for some subset of L2 technologies. I think the discussion of what L2s are applicable in the context of this discussion is a rat-hole. So, I am very very confused now . Is the requirement that the solution works with any L2 or is the requirement that the solution works with only a subset of L2 that have some capabilties? Cause AFAIU, if we require that the solution applies to all L2, then the first option is not accetpable. Regards, marcelo From marcelo@it.uc3m.es Thu Jul 2 00:26:53 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6DD3A6BDD; Thu, 2 Jul 2009 00:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm1dLJKubY01; Thu, 2 Jul 2009 00:26:50 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F22B53A6CEC; Thu, 2 Jul 2009 00:24:13 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp01.uc3m.es (Postfix) with ESMTP id 246BABA0A43; Thu, 2 Jul 2009 09:24:34 +0200 (CEST) Message-ID: <4A4C60B0.70109@it.uc3m.es> Date: Thu, 02 Jul 2009 09:24:32 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.004 Cc: netext@ietf.org, netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:26:54 -0000 Basavaraj.Patil@nokia.com escribió: > >> Anyway, my point is that 1) above is not an issue today because it already >> happens on a very large scale, so requiring it for a specific feature like >> multihoming is hardly a leap. I can imagine ads for "download your wireless >> optimiser from wwww.operator.com and save money" (ok not very creative). >> The subtle difference between 1) and 2) is IMO a moot point anyway because >> 2) simply says that operators don't want protocol support in the network, >> but that support already exists in the form of PMIP and if you have PMIP you >> have MIP. >> > > While I agree that having PMIP equates to having MIP, it is only from the > perspective of the fact that the LMA is also a DSMIP6 HA. But this fact is > of no use in actual deployments. An LMA will not operate as a DSMIP6 HA > unless there is explicit support enabled for it to operate as an HA. I just > don't see the LMA accepting BUs from a (DS)MIP6 MN or establishing IPsec SAs > to secure the signaling. Are you implying some form of requirement in terms of which entities can have SAs? From marcelo@it.uc3m.es Thu Jul 2 00:36:04 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA513A6A94 for ; Thu, 2 Jul 2009 00:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XMmxJrNmq4L for ; Thu, 2 Jul 2009 00:36:04 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 02A9F3A6818 for ; Thu, 2 Jul 2009 00:36:03 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp02.uc3m.es (Postfix) with ESMTP id 72EEE65A1CC; Thu, 2 Jul 2009 09:36:24 +0200 (CEST) Message-ID: <4A4C6378.3070208@it.uc3m.es> Date: Thu, 02 Jul 2009 09:36:24 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4D35478224365146822AE9E3AD4A2666093829E1$0001@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609ECF37F@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609ECF37F@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.004 Cc: netext@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:36:05 -0000 Koodli, Rajeev escribió: > > > >>> RKo> I suggested "no host protocol changes" for stating the it >>> RKo> precisely. It >>> was not meant to say we should endorse the statement. >>> >> => Ok but I'm asking for your opinion on what the requirement >> should be. Is your opinion that the requirement should be "no >> protocol support in the host"? >> >> > > No, we should not rule out protocol extensions which may be needed for a > feature to work (just as an example, informing a mobile node that a flow > is moving to another interface - I would like to have such indications > at L2 whenever possible) > > I think it is imporntant to distinguish between the changes that are required for the protocol to work (i.e. the changes that are needed in order to be able to do an inter tech HO) and the changes that are needed to provide optimizations. I think we should simply forget about the ones for optimizations at this point and focus on the ones that are required for the protocol to work. > The requirement should be "no L3 mobility protocol changes in the host". > So, do you think that other L3 protocol changes that are not mobility protocols are acceptable? Or do you think that L2 mobility protocol changes are acceptable? Please note that requiring L2 protocol changes would colide with the potential requirement of supporting all L2... Regards, marcelo > -Rajeev > > > >> Hesham >> >> >> >> >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From marcelo@it.uc3m.es Thu Jul 2 00:37:27 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C286F3A6A94 for ; Thu, 2 Jul 2009 00:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgiH4oHrOVCI for ; Thu, 2 Jul 2009 00:37:26 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CAA553A6818 for ; Thu, 2 Jul 2009 00:37:25 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp02.uc3m.es (Postfix) with ESMTP id 9975065A1CC; Thu, 2 Jul 2009 09:37:46 +0200 (CEST) Message-ID: <4A4C63CA.7040708@it.uc3m.es> Date: Thu, 02 Jul 2009 09:37:46 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4D35478224365146822AE9E3AD4A266609ECF38E@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609ECF38E@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.004 Cc: netext@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:37:27 -0000 Koodli, Rajeev escribió: > Hi Kevin, > > > >> Agreed, carriers manage mobility on both sides and at multiple layers. >> From my point of view (at least for this discussion) I only care about >> L3 and assume that any lower-layer mobility is hidden from >> me. On the other hand, I think it is important, if not >> necessary, that L1/L2 information be available to L3 and >> above in order to make HO functions more robust. >> > > Yes, such indications could include the network informing the MN to use > a different interface for a particular traffic flow. > > >> Also, I tend to think that network-based mobility (e.g. >> PMIP6) should be network-based and not place requirements on >> the MN. Similarly, if you are going to make a requirement on >> the MN, you might as well go all-in and make it CMIP. Of >> course, there are implications on memory, CPU, etc. >> so my all or nothing approach is probably not a very practical one. >> >> > > Perhaps implicit here is the distinction between changes to mobility > protocol that affects the MN and extensions in general (such as the > ability to inform a MN to use a different i/f for a particular traffic > flow). > i fail to see how this is not central to the flow mobility feature that we need to provide Regards, marcelo > I agree that MN should still be unaware of how its mobility is managed. > We should also allow for "supplementary" (for the lack of a better word) > extensions (which may need to be done L3). > > > Regards, > > -Rajeev > > > >> --kan-- >> -- >> Kevin A. Noll >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, July 01, 2009 12:26 PM >> To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >> of the bof description >> >> Kevin, >> >> Thanks for the input. I understand where you're coming from >> and I have two small comments to make. >> >> First I think you're assuming that mobility support for the >> multihoming scenario we're discussing must be done in the >> kernel. This is not the case at all. Things can be done in >> user space as an add-on application. >> >> Second, you made this comment: >> >> >>> 4. At least some carriers prefer to manage mobility inside >>> >> the network >> >>> rather than on the customer device. This is something that we are >>> constantly discussing internal to our organization, with >>> >> vendors, and >> >>> with other operators. >>> >> => To be precise, all carriers manage mobility from both the >> network and host sides. It's just not L3 mobility. So the >> question should be whether it is acceptable to manage L3 >> mobility on both sides as well. And there is pretty good >> reasons for doing that, especially that most mobile devices >> today have multiple interfaces to different technologies, >> which never happened before. >> >> Hesham >> >> >> On 1/07/09 11:52 PM, "Noll, Kevin" wrote: >> >> >>> I've been lurking here for a while watching the >>> >> conversation. Please >> >>> accept my apologies for dropping in unexpectedly, but I thought I >>> >> might >> >>> give at least one operator's viewpoint. >>> >>> You are correct that most data cards being sold today >>> >> require you to >> >>> install the carrier's software. This software typically contains a >>> connection manager and the OS drivers required to operate the data >>> >> card. >> >>> Technically speaking, the data cards that I have worked with do not >>> >> all >> >>> *require* the connection manager to operate, though it varies from >>> >> card >> >>> to card. Obviously, though, they *do* need the drivers. >>> >>> What we saw with WiFi was a technology that began as an >>> >> add-on to our >> >>> computing devices (laptops, etc.). WiFi grew, matured, and >>> >> became so >> >>> widely accepted that operating systems began to ship with native >>> drivers, the add-on device became integrated into the computing >>> >> devices >> >>> and we no longer needed to install 3rd-party drivers or connection >>> software. >>> >>> As a network provider/operator, we like this model because >>> >> it is very >> >>> expensive to write and maintain the connection software and drivers >>> >> and >> >>> keep the user's device up to date. Adding a mobility stack to the >>> software being installed adds significantly to this cost. We are >>> >> seeing >> >>> the cost come down, but there's still the issue of >>> >> configuration and >> >>> what-not. >>> >>> We expect to see open networks and technologies like WiMAX (and >>> >> possibly >> >>> LTE) change the traditional cellular data-card model to one that is >>> >> more >> >>> similar to WiFi, hopefully driving down the cost of the >>> >> software and >> >>> moving the software development tasks out of the operator >>> >> and into the >> >>> OS vendor community. >>> >>> This said, I think it would be a mistake to make any assumptions on >>> either of the two points mentioned below. >>> >>> 1. In the future the carrier may not deliver software with the data >>> card, so it's probably a bad assumption to say that the >>> >> carrier would >> >>> simply deliver a mobility stack with the device. >>> >>> 2. It's probably a good assumption to say that devices will >>> >> eventually >> >>> have native mobility stacks. We are already seeing this >>> >> development in >> >>> mainstream operating systems. This is similar to the evolution of >>> >> WiFi. >> >>> 3. It's probably not a good assumption to say that *all* >>> >> devices will >> >>> have the perfect combination of native support or carrier support. >>> >>> 4. At least some carriers prefer to manage mobility inside >>> >> the network >> >>> rather than on the customer device. This is something that we are >>> constantly discussing internal to our organization, with >>> >> vendors, and >> >>> with other operators. >>> >>> Based on this, the case for extending the functionality of PMIP6 is >>> pretty strong, at least in my opinion. >>> >>> On the other hand, we will also continue following the >>> >> development of >> >>> native stacks and evaluate when and how best to use them in our >>> >> product >> >>> offerings. Similarly, we will continue to evaluate whether >>> >> or not we >> >>> need to deliver a mobility stack with our data card software. >>> >>> Thanks! >>> >>> --kan-- >>> -- >>> Kevin A. Noll >>> >>> >>> >>> P Go Green! Print this email only when necessary. Thank you for >>> >> helping Time >> >>> Warner Cable be environmentally responsible. >>> >>> >>> -----Original Message----- >>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On >>> >> Behalf >> >>> Of Hesham Soliman >>> Sent: Tuesday, June 30, 2009 11:59 PM >>> To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es >>> Cc: netext@ietf.org; netlmm@ietf.org >>> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft >>> >> of the bof >> >>> description >>> >>> >>> Hi Raj, >>> >>> I had a brief offline chat with Julien and thought that I >>> >> could refine >> >>> my suggestion a bit more to make the point clearer. My point is that >>> >> there >> >>> are >>> currently two slightly different points being made about the >>> >> requirement >> >>> on >>> host involvement 1) no SW on the host and the more nuanced 2) no >>> protocol support on the host. I won't even get into the reasons for >>> point 2) above and I'll let the people who raise it provide those >>> reasons, I can't figure out any technical reasons there. >>> >>> Anyway, my point is that 1) above is not an issue today because it >>> already happens on a very large scale, so requiring it for >>> >> a specific >> >>> feature like multihoming is hardly a leap. I can imagine ads for >>> "download your wireless optimiser from wwww.operator.com and save >>> money" (ok not very >>> >> creative). >> >>> The subtle difference between 1) and 2) is IMO a moot point anyway >>> because >>> 2) simply says that operators don't want protocol support in the >>> network, but that support already exists in the form of PMIP and if >>> you have >>> >> PMIP >> >>> you >>> have MIP. So, both motivations seem to be on shaky ground. >>> And yes, you can of course integrate 3G modems in computers, but you >>> >> can >> >>> also integrate mobility code in the same computers with the 3G >>> >> support. >> >>> The >>> SW that is provided with the modems is not only connection SW it >>> actually provides a number of features (e.g. Receiving SMS, account >>> >> information, >> >>> email ....etc) so it's a clear move by operators to be present on >>> >> those >> >>> machines. I don't think it's anything like WLAN connctions SW. >>> >>> Of course it's worth mentioning that the elephant in the >>> >> room is the >> >>> binary requirement on host support of protocols. We need to have a >>> yes/no answer as to whether there is a requirement to NOT have >>> protocol support in the host. >>> At the moment this is being kept very vague. >>> >>> Hesham >>> >>> >>>>> => No one I know can get a 3G data card to access the >>>>> >> Internet from >> >>> their PC >>> >>>>> without having to install a piece of software on their PC to make >>>>> >> it >> >>> work. >>> >>>>> So I think your assumption that the operator cannot >>>>> >> mandate software >> >>> on the >>> >>>>> host is questionable, because they already do (unfortunately). >>>>> >>>> The situation that you describe above was the same when >>>> >> 802.11 first >> >>> rolled >>> >>>> around as well. >>>> You had to install a piece of software that came with the PC card. >>>> >> But >> >>> that >>> >>>> has changed with >>>> wifi now being an integral part of the notebook computers. >>>> And I think you could expect 3G chipsets and access >>>> >> built-in as well >> >>> in due >>> >>>> course of time. At least I know of a few operators in the >>>> >> US (as well >> >>>> as notebook manufacturers) who offer >>>> >> such >> >>>> net/notebook computers, >>>> i.e with integrated 3G access. I do not know what additional sw is >>>> >>> loaded on >>> >>>> these but at least the end user >>>> is not installing anything else. >>>> Does it imply that such hosts will include the software that would >>>> >>> enable host >>> >>>> mobility? Its an open question (i.e unknown) and will >>>> >> depend largely >> >>>> on operator choices and vendors. >>>> >>>> -Raj >>>> >>>> >>>>> Hesham >>>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >>> This E-mail and any of its attachments may contain Time >>> >> Warner Cable >> >>> proprietary information, which is privileged, confidential, >>> >> or subject >> >>> to copyright belonging to Time Warner Cable. This E-mail is >>> >> intended >> >>> solely for the use of the individual or entity to which it is >>> addressed. If you are not the intended recipient of this >>> >> E-mail, you >> >>> are hereby notified that any dissemination, distribution, >>> >> copying, or >> >>> action taken in relation to the contents of and attachments to this >>> E-mail is strictly prohibited and may be unlawful. If you have >>> received this E-mail in error, please notify the sender immediately >>> and permanently delete the original and any copy of this E-mail and >>> any printout. >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> This E-mail and any of its attachments may contain Time >> Warner Cable proprietary information, which is privileged, >> confidential, or subject to copyright belonging to Time >> Warner Cable. This E-mail is intended solely for the use of >> the individual or entity to which it is addressed. If you are >> not the intended recipient of this E-mail, you are hereby >> notified that any dissemination, distribution, copying, or >> action taken in relation to the contents of and attachments >> to this E-mail is strictly prohibited and may be unlawful. If >> you have received this E-mail in error, please notify the >> sender immediately and permanently delete the original and >> any copy of this E-mail and any printout. >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From marcelo@it.uc3m.es Thu Jul 2 00:39:33 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D7F3A6A6C; Thu, 2 Jul 2009 00:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRP+v4wDoQDJ; Thu, 2 Jul 2009 00:39:32 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CE7153A6D3E; Thu, 2 Jul 2009 00:39:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp02.uc3m.es (Postfix) with ESMTP id 3EF8765587C; Thu, 2 Jul 2009 09:39:43 +0200 (CEST) Message-ID: <4A4C643E.5080509@it.uc3m.es> Date: Thu, 02 Jul 2009 09:39:42 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4A4A3BD3.1040703@it.uc3m.es> <4D35478224365146822AE9E3AD4A266609E3BF87$0001@exchtewks3.starentnetworks.com> <4A4B570E.5090301@it.uc3m.es> <4D35478224365146822AE9E3AD4A266609ECF396@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609ECF396@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.004 Cc: netext@ietf.org, netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:39:33 -0000 Koodli, Rajeev escribió: > Hi Marcelo, > > >>> As a starting point, the host is not involved in mobility management >>> > > >>> (aka, managing persistence and reachability). >>> >>> >> right, this is what i was asking >> >> So, i think this can be defined in terms of what is in >> control of the network, correct? >> So, would it make sense to define this as a requirement that >> it must be network that decides through wich interface the >> node sends traffic In particular, it is the network side that decides: >> - when the node performs a handoff to the other interface >> - how the traffic is distributed among interfaces >> - which flow flows through each interface >> >> Is that what you have in mind? >> > > Yes, this is a good formulation. > So, i understand that the answer to the question 3 3)- What capabilities need to be controlled by the network? When the MN performs a handover from one interface to another one? How the node distributes the load among interfaces? in which direction? Which flow is routed through which interface? in which direction? Is the network in all cases, correct? That would be a requirement for the solution? > Thanks, > > -Rajeev > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From marcelo@it.uc3m.es Thu Jul 2 00:43:09 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E0128C0D6 for ; Thu, 2 Jul 2009 00:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sJqwte8yocN for ; Thu, 2 Jul 2009 00:43:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 66F5D3A6B5E for ; Thu, 2 Jul 2009 00:43:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp01.uc3m.es (Postfix) with ESMTP id 06AFEBA2B7E; Thu, 2 Jul 2009 09:43:27 +0200 (CEST) Message-ID: <4A4C651F.6000308@it.uc3m.es> Date: Thu, 02 Jul 2009 09:43:27 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4D35478224365146822AE9E3AD4A266609ECF37F@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609ECF4B4@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609ECF4B4@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16738.004 Cc: netext@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:43:09 -0000 Koodli, Rajeev escribió: > I guess it was not clear.. I did not suggest that "no host protocol > changes" should be a requirement, but a better use than saying "no host > changes". > > I think we are making progress. We (at least many folks) are receptive > to 1) relying on L2 capabilities as much as possible, mmm, but if you want to support all L2, this is basically only an optimization, right? > 2) using host > configurations to address some of the issues, sure, but this is not a requiremnet but a preference, (with which i agree with) > and 3) not ruling out L3 > extensions so, basically we are not imposing the requirement of no L3 protocol changes in the host, correct? > without changing the PMIP mobility model > (i.e., the MN is not > involved in mobility management of persistence and reachbility). Please > see Marcelo's e-mail below; it seems like a good formulation to me. > > -Rajeev > > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Wednesday, July 01, 2009 5:31 AM >> To: Koodli, Rajeev >> Cc: Basavaraj.Patil@nokia.com; netext@ietf.org; netlmm@ietf.org >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >> of the bofdescription >> >> > [snip] > >>> >>> >> right, this is what i was asking >> >> So, i think this can be defined in terms of what is in >> control of the network, correct? >> So, would it make sense to define this as a requirement that >> it must be network that decides through wich interface the >> node sends traffic In particular, it is the network side that decides: >> - when the node performs a handoff to the other interface >> - how the traffic is distributed among interfaces >> - which flow flows through each interface >> >> Is that what you have in mind? >> >> Regards, marcelo >> >> > > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, July 01, 2009 7:12 PM >> To: Koodli, Rajeev; netext@ietf.org >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >> of the bof description >> >> >> >> >> On 2/07/09 8:47 AM, "Koodli, Rajeev" >> wrote: >> >> >>> >>> >>> >>>>> RKo> I suggested "no host protocol changes" for stating the it >>>>> RKo> precisely. It >>>>> was not meant to say we should endorse the statement. >>>>> >>>> => Ok but I'm asking for your opinion on what the >>>> >> requirement should >> >>>> be. Is your opinion that the requirement should be "no protocol >>>> support in the host"? >>>> >>>> >>> No, we should not rule out protocol extensions which may be >>> >> needed for >> >>> a feature to work (just as an example, informing a mobile >>> >> node that a >> >>> flow is moving to another interface - I would like to have such >>> indications at L2 whenever possible) >>> >>> The requirement should be "no L3 mobility protocol changes >>> >> in the host". >> >> => In that case your requirement contradicts your own words >> above it, not to mention, it's a silly requirement to make >> because you seem to have a strange idea about what mobility >> protocol means (almost something like mobility protocol = >> binding update) and none of the reasons for eliminating the >> host from the conversation apply here. Actually, what you say >> above doesn't amount to a requirement, it's how you think >> things should be done. It's going to be very hard to answer >> the "why" part given the above. >> >> It's disappointing that this work has not progressed even to >> the point of producing decent requirements given the amount >> of attention it's getting on the mailing list. >> >> Hesham >> >> >> >>> -Rajeev >>> >>> >>> >>>> Hesham >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From sunseawq@huawei.com Thu Jul 2 01:51:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563F63A6A63 for ; Thu, 2 Jul 2009 01:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q3oKI6fb2hV for ; Thu, 2 Jul 2009 01:51:18 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3BE053A69EA for ; Thu, 2 Jul 2009 01:51:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM5003MRCLP6I@szxga03-in.huawei.com> for netext@ietf.org; Thu, 02 Jul 2009 16:51:25 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM500MI2CLPRC@szxga03-in.huawei.com> for netext@ietf.org; Thu, 02 Jul 2009 16:51:25 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM5004Z2CLOT7@szxml06-in.huawei.com> for netext@ietf.org; Thu, 02 Jul 2009 16:51:25 +0800 (CST) Date: Thu, 02 Jul 2009 16:51:22 +0800 From: Qin Wu To: netext@ietf.org Message-id: <044d01c9faf2$468e4b90$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090702083001.F342B28C14F@core3.amsl.com> Subject: [netext] New Version: I-D Action:draft-wu-netext-local-ro-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:51:19 -0000 Hi, Folks: We have submitted the updated version draft on localized routing solution. http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-01.txt The main changes to the previous version is to strengthen negotiation aspects which is lacked in the RFC5213 and IPv4 aspects which is still in discussion in the mailist. Also we add one section to discuss how inter-LMA local routing works based on stateful entities discovery described in the localized routing PS draft. Your comments are welcome! Regards! -Qin The abstract: This document extends local routing in proxy Mobile IPv6 and defines a simplified localized routing optimization protocol within one PMIPv6 domain. The protocol supports IPv4 transport network operation, IPv4 home address mobility and handover. The Local mobility anchor/mobile access gateway initiates local routing for the mobile and correspondent node by sending messages to each mobile access gateway/local mobility anchor. In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways to the mobile access gateway attached by the mobile node afterwards. Mobile access gateways create and refresh bindings using proxy binding update and acknowledgement messages. ----- Original Message ----- From: To: Sent: Thursday, July 02, 2009 4:30 PM Subject: I-D Action:draft-wu-netext-local-ro-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Proxy MIP extension for local routing optimization > Author(s) : W. Wu, B. Sarikaya > Filename : draft-wu-netext-local-ro-01.txt > Pages : 26 > Date : 2009-07-02 > > This document extends local routing in proxy Mobile IPv6 and defines > a simplified localized routing optimization protocol within one > PMIPv6 domain. The protocol supports IPv4 transport network > operation, IPv4 home address mobility and handover. The Local > mobility anchor/mobile access gateway initiates local routing for > the mobile and correspondent node by sending messages to each mobile > access gateway/local mobility anchor. In case the correspondent node > is connected to another local mobility anchor, the local mobility > anchors connected by the correspondent node needs to be discovered > firstly so that it can notify its mobile access gateways to the > mobile access gateway attached by the mobile node afterwards. Mobile > access gateways create and refresh bindings using proxy binding > update and acknowledgement messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From hesham@elevatemobile.com Thu Jul 2 06:34:58 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0369C3A6906 for ; Thu, 2 Jul 2009 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCKzPGUbfvvG for ; Thu, 2 Jul 2009 06:34:57 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A69FD3A686C for ; Thu, 2 Jul 2009 06:34:55 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MMMRW-0007op-Eb; Thu, 02 Jul 2009 23:35:15 +1000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 02 Jul 2009 23:35:08 +1000 From: Hesham Soliman To: Mohana Jeyatharan , "Koodli, Rajeev" , Message-ID: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn55yiPpcZkFm6LIE2EHazYOQhMtwAeVlJxAAHUXIUADXoZMAAHL4SGAAeHRFAAAHF1YAAAit/CAABuxaAADunFuQ== In-Reply-To: <5F09D220B62F79418461A978CA0921BD036EEDC1@pslexc01.psl.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 13:34:58 -0000 On 2/07/09 4:45 PM, "Mohana Jeyatharan" wrote: > Hi Hesham, > > I meant, network can decide MN interface for flow mobility, handoff > based on its own policies or MN provided information. So, just wanted to > highlight that MN should be able to indicate its prefernce via signaling > and as Marcelo pointed network must decide. => Understood, but that's in direct contradiction with the text you quoted. > > Even if the network initiates flow mobility, we still need some host > changes. So, I was refering to the host changes tied to the host > initiating the flow mobility process by indicating its prefernce. Just > wanted to highlight that this too needs to be supported. => That's fine but you can't want that and still agree with that requirement you quoted. Hesham > BR, > Mohana > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Thursday, July 02, 2009 2:16 PM >> To: Mohana Jeyatharan; Koodli, Rajeev; netext@ietf.org >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the >> bofdescription >> >> >> >> >> On 2/07/09 4:07 PM, "Mohana Jeyatharan" >> >> wrote: >> >>> Hi all, >>> >>> The below classification on requirements looks really good. >>> 1) relying on L2 capabilities as much as possible, 2) using host >>>> configurations to address some of the issues, and 3) not ruling out > L3 >>>> extensions without changing the PMIP mobility model >>> >>> One more point, the mobile node should be able to indicate flow >>> prefernce, handoff indication etc to the network and the final > decision >>> can be made by the network. At least we should cater for mobile node >>> indicating its prefernce to the network. >> >> => Agree, but you're contradicting the paragraph you're quoting above, >> which >> you said "looks really good"..... >> >> Hesham >> >> >> >> >> As some of us have described in >>> the ML, this should be supported. However, I am fine with the fact > that >>> the final decsion can be made by the network. >>> >>> Thanks. >>> >>> BR, >>> Mohana >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>> Behalf >>>> Of Koodli, Rajeev >>>> Sent: Thursday, July 02, 2009 1:54 PM >>>> To: netext@ietf.org >>>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the >>>> bofdescription >>>> >>>> >>>> I guess it was not clear.. I did not suggest that "no host protocol >>>> changes" should be a requirement, but a better use than saying "no >>> host >>>> changes". >>>> >>>> I think we are making progress. We (at least many folks) are > receptive >>>> to 1) relying on L2 capabilities as much as possible, 2) using host >>>> configurations to address some of the issues, and 3) not ruling out > L3 >>>> extensions without changing the PMIP mobility model (i.e., the MN > is >>> not >>>> involved in mobility management of persistence and reachbility). >>> Please >>>> see Marcelo's e-mail below; it seems like a good formulation to me. >>>> >>>> -Rajeev >>>> >>>> >>>>> -----Original Message----- >>>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>>> Sent: Wednesday, July 01, 2009 5:31 AM >>>>> To: Koodli, Rajeev >>>>> Cc: Basavaraj.Patil@nokia.com; netext@ietf.org; netlmm@ietf.org >>>>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >>>>> of the bofdescription >>>>> >>>> [snip] >>>>>> >>>>> right, this is what i was asking >>>>> >>>>> So, i think this can be defined in terms of what is in >>>>> control of the network, correct? >>>>> So, would it make sense to define this as a requirement that >>>>> it must be network that decides through wich interface the >>>>> node sends traffic In particular, it is the network side that >>> decides: >>>>> - when the node performs a handoff to the other interface >>>>> - how the traffic is distributed among interfaces >>>>> - which flow flows through each interface >>>>> >>>>> Is that what you have in mind? >>>>> >>>>> Regards, marcelo >>>>> >>>> >>>>> -----Original Message----- >>>>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>>>> Sent: Wednesday, July 01, 2009 7:12 PM >>>>> To: Koodli, Rajeev; netext@ietf.org >>>>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >>>>> of the bof description >>>>> >>>>> >>>>> >>>>> >>>>> On 2/07/09 8:47 AM, "Koodli, Rajeev" >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>>>> RKo> I suggested "no host protocol changes" for stating the it >>>>>>>> RKo> precisely. It >>>>>>>> was not meant to say we should endorse the statement. >>>>>>> >>>>>>> => Ok but I'm asking for your opinion on what the >>>>> requirement should >>>>>>> be. Is your opinion that the requirement should be "no protocol >>>>>>> support in the host"? >>>>>>> >>>>>> >>>>>> No, we should not rule out protocol extensions which may be >>>>> needed for >>>>>> a feature to work (just as an example, informing a mobile >>>>> node that a >>>>>> flow is moving to another interface - I would like to have such >>>>>> indications at L2 whenever possible) >>>>>> >>>>>> The requirement should be "no L3 mobility protocol changes >>>>> in the host". >>>>> >>>>> => In that case your requirement contradicts your own words >>>>> above it, not to mention, it's a silly requirement to make >>>>> because you seem to have a strange idea about what mobility >>>>> protocol means (almost something like mobility protocol = >>>>> binding update) and none of the reasons for eliminating the >>>>> host from the conversation apply here. Actually, what you say >>>>> above doesn't amount to a requirement, it's how you think >>>>> things should be done. It's going to be very hard to answer >>>>> the "why" part given the above. >>>>> >>>>> It's disappointing that this work has not progressed even to >>>>> the point of producing decent requirements given the amount >>>>> of attention it's getting on the mailing list. >>>>> >>>>> Hesham >>>>> >>>>> >>>>>> >>>>>> -Rajeev >>>>>> >>>>>> >>>>>>> Hesham >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> > From rkoodli@starentnetworks.com Thu Jul 2 10:33:24 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213C328C219 for ; Thu, 2 Jul 2009 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjeWjpLetZ-T for ; Thu, 2 Jul 2009 10:33:22 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 301AF28C1DE for ; Thu, 2 Jul 2009 10:33:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 08D0D9010F for ; Thu, 2 Jul 2009 13:33:43 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05822-16 for ; Thu, 2 Jul 2009 13:33:39 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 2 Jul 2009 13:33:39 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 13:33:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2009 13:22:03 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666093829E4@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn66AT6AQWwVFueTwOqSD4lKluv1gAUZi0m References: <4D35478224365146822AE9E3AD4A266609ECF38E@exchtewks3.starentnetworks.com> <4A4C63CA.7040708@it.uc3m.es> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 02 Jul 2009 17:33:21.0147 (UTC) FILETIME=[31A774B0:01C9FB3B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:33:24 -0000 =20 Hi Marcelo, =20 > > Perhaps implicit here is the distinction between changes to mobility > protocol that affects the MN and extensions in general (such as the > ability to inform a MN to use a different i/f for a particular traffic > flow). > =20 >> i fail to see how this is not central to the flow mobility feature = that >> we need to provide RKo> if the network decides to move a flow from one interface to = another, it would be good to have the ability to inform the MN, no? -Rajeev Regards, marcelo > I agree that MN should still be unaware of how its mobility is = managed. > We should also allow for "supplementary" (for the lack of a better = word) > extensions (which may need to be done L3). > > =20 > Regards, > > -Rajeev > > > =20 >> --kan-- >> -- >> Kevin A. Noll >> >> >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Wednesday, July 01, 2009 12:26 PM >> To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org >> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >> of the bof description >> >> Kevin, >> >> Thanks for the input. I understand where you're coming from >> and I have two small comments to make. >> >> First I think you're assuming that mobility support for the >> multihoming scenario we're discussing must be done in the >> kernel. This is not the case at all. Things can be done in >> user space as an add-on application. >> >> Second, you made this comment: >> >> =20 >>> 4. At least some carriers prefer to manage mobility inside >>> =20 >> the network >> =20 >>> rather than on the customer device. This is something that we are >>> constantly discussing internal to our organization, with >>> =20 >> vendors, and >> =20 >>> with other operators. >>> =20 >> =3D> To be precise, all carriers manage mobility from both the >> network and host sides. It's just not L3 mobility. So the >> question should be whether it is acceptable to manage L3 >> mobility on both sides as well. And there is pretty good >> reasons for doing that, especially that most mobile devices >> today have multiple interfaces to different technologies, >> which never happened before. >> >> Hesham >> >> >> On 1/07/09 11:52 PM, "Noll, Kevin" wrote: >> >> =20 >>> I've been lurking here for a while watching the >>> =20 >> conversation. Please >> =20 >>> accept my apologies for dropping in unexpectedly, but I thought I >>> =20 >> might >> =20 >>> give at least one operator's viewpoint. >>> >>> You are correct that most data cards being sold today >>> =20 >> require you to >> =20 >>> install the carrier's software. This software typically contains a >>> connection manager and the OS drivers required to operate the data >>> =20 >> card. >> =20 >>> Technically speaking, the data cards that I have worked with do not >>> =20 >> all >> =20 >>> *require* the connection manager to operate, though it varies from >>> =20 >> card >> =20 >>> to card. Obviously, though, they *do* need the drivers. >>> >>> What we saw with WiFi was a technology that began as an >>> =20 >> add-on to our >> =20 >>> computing devices (laptops, etc.). WiFi grew, matured, and >>> =20 >> became so >> =20 >>> widely accepted that operating systems began to ship with native >>> drivers, the add-on device became integrated into the computing >>> =20 >> devices >> =20 >>> and we no longer needed to install 3rd-party drivers or connection >>> software. >>> >>> As a network provider/operator, we like this model because >>> =20 >> it is very >> =20 >>> expensive to write and maintain the connection software and drivers >>> =20 >> and >> =20 >>> keep the user's device up to date. Adding a mobility stack to the >>> software being installed adds significantly to this cost. We are >>> =20 >> seeing >> =20 >>> the cost come down, but there's still the issue of >>> =20 >> configuration and >> =20 >>> what-not. >>> >>> We expect to see open networks and technologies like WiMAX (and >>> =20 >> possibly >> =20 >>> LTE) change the traditional cellular data-card model to one that is >>> =20 >> more >> =20 >>> similar to WiFi, hopefully driving down the cost of the >>> =20 >> software and >> =20 >>> moving the software development tasks out of the operator >>> =20 >> and into the >> =20 >>> OS vendor community. >>> >>> This said, I think it would be a mistake to make any assumptions on >>> either of the two points mentioned below. >>> >>> 1. In the future the carrier may not deliver software with the data >>> card, so it's probably a bad assumption to say that the >>> =20 >> carrier would >> =20 >>> simply deliver a mobility stack with the device. >>> >>> 2. It's probably a good assumption to say that devices will >>> =20 >> eventually >> =20 >>> have native mobility stacks. We are already seeing this >>> =20 >> development in >> =20 >>> mainstream operating systems. This is similar to the evolution of >>> =20 >> WiFi. >> =20 >>> 3. It's probably not a good assumption to say that *all* >>> =20 >> devices will >> =20 >>> have the perfect combination of native support or carrier support. >>> >>> 4. At least some carriers prefer to manage mobility inside >>> =20 >> the network >> =20 >>> rather than on the customer device. This is something that we are >>> constantly discussing internal to our organization, with >>> =20 >> vendors, and >> =20 >>> with other operators. >>> >>> Based on this, the case for extending the functionality of PMIP6 is >>> pretty strong, at least in my opinion. >>> >>> On the other hand, we will also continue following the >>> =20 >> development of >> =20 >>> native stacks and evaluate when and how best to use them in our >>> =20 >> product >> =20 >>> offerings. Similarly, we will continue to evaluate whether >>> =20 >> or not we >> =20 >>> need to deliver a mobility stack with our data card software. >>> >>> Thanks! >>> >>> --kan-- >>> -- >>> Kevin A. Noll >>> >>> >>> >>> P Go Green! Print this email only when necessary. Thank you for >>> =20 >> helping Time >> =20 >>> Warner Cable be environmentally responsible. >>>=20 >>>=20 >>> -----Original Message----- >>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On >>> =20 >> Behalf >> =20 >>> Of Hesham Soliman >>> Sent: Tuesday, June 30, 2009 11:59 PM >>> To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es >>> Cc: netext@ietf.org; netlmm@ietf.org >>> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft >>> =20 >> of the bof >> =20 >>> description >>> >>> >>> Hi Raj, >>> >>> I had a brief offline chat with Julien and thought that I >>> =20 >> could refine >> =20 >>> my suggestion a bit more to make the point clearer. My point is that >>> =20 >> there >> =20 >>> are >>> currently two slightly different points being made about the >>> =20 >> requirement >> =20 >>> on >>> host involvement 1) no SW on the host and the more nuanced 2) no >>> protocol support on the host. I won't even get into the reasons for >>> point 2) above and I'll let the people who raise it provide those >>> reasons, I can't figure out any technical reasons there. >>> >>> Anyway, my point is that 1) above is not an issue today because it >>> already happens on a very large scale, so requiring it for >>> =20 >> a specific >> =20 >>> feature like multihoming is hardly a leap. I can imagine ads for >>> "download your wireless optimiser from wwww.operator.com and save >>> money" (ok not very >>> =20 >> creative). >> =20 >>> The subtle difference between 1) and 2) is IMO a moot point anyway >>> because >>> 2) simply says that operators don't want protocol support in the >>> network, but that support already exists in the form of PMIP and if >>> you have >>> =20 >> PMIP >> =20 >>> you >>> have MIP. So, both motivations seem to be on shaky ground. >>> And yes, you can of course integrate 3G modems in computers, but you >>> =20 >> can >> =20 >>> also integrate mobility code in the same computers with the 3G >>> =20 >> support. >> =20 >>> The >>> SW that is provided with the modems is not only connection SW it >>> actually provides a number of features (e.g. Receiving SMS, account >>> =20 >> information, >> =20 >>> email ....etc) so it's a clear move by operators to be present on >>> =20 >> those >> =20 >>> machines. I don't think it's anything like WLAN connctions SW. >>> >>> Of course it's worth mentioning that the elephant in the >>> =20 >> room is the >> =20 >>> binary requirement on host support of protocols. We need to have a >>> yes/no answer as to whether there is a requirement to NOT have >>> protocol support in the host. >>> At the moment this is being kept very vague. >>> >>> Hesham >>> >>> =20 >>>>> =3D> No one I know can get a 3G data card to access the >>>>> =20 >> Internet from >> =20 >>> their PC >>> =20 >>>>> without having to install a piece of software on their PC to make >>>>> =20 >> it >> =20 >>> work. >>> =20 >>>>> So I think your assumption that the operator cannot >>>>> =20 >> mandate software >> =20 >>> on the >>> =20 >>>>> host is questionable, because they already do (unfortunately). >>>>> =20 >>>> The situation that you describe above was the same when >>>> =20 >> 802.11 first >> =20 >>> rolled >>> =20 >>>> around as well. >>>> You had to install a piece of software that came with the PC card. >>>> =20 >> But >> =20 >>> that >>> =20 >>>> has changed with >>>> wifi now being an integral part of the notebook computers. >>>> And I think you could expect 3G chipsets and access >>>> =20 >> built-in as well >> =20 >>> in due >>> =20 >>>> course of time. At least I know of a few operators in the >>>> =20 >> US (as well >> =20 >>>> as notebook manufacturers) who offer >>>> =20 >> such >> =20 >>>> net/notebook computers, >>>> i.e with integrated 3G access. I do not know what additional sw is >>>> =20 >>> loaded on >>> =20 >>>> these but at least the end user >>>> is not installing anything else. >>>> Does it imply that such hosts will include the software that would >>>> =20 >>> enable host >>> =20 >>>> mobility? Its an open question (i.e unknown) and will >>>> =20 >> depend largely >> =20 >>>> on operator choices and vendors. >>>> >>>> -Raj >>>> >>>> =20 >>>>> Hesham >>>>> =20 >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>> =20 >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/netlmm >>> This E-mail and any of its attachments may contain Time >>> =20 >> Warner Cable >> =20 >>> proprietary information, which is privileged, confidential, >>> =20 >> or subject >> =20 >>> to copyright belonging to Time Warner Cable. This E-mail is >>> =20 >> intended >> =20 >>> solely for the use of the individual or entity to which it is >>> addressed. If you are not the intended recipient of this >>> =20 >> E-mail, you >> =20 >>> are hereby notified that any dissemination, distribution, >>> =20 >> copying, or >> =20 >>> action taken in relation to the contents of and attachments to this >>> E-mail is strictly prohibited and may be unlawful. If you have >>> received this E-mail in error, please notify the sender immediately >>> and permanently delete the original and any copy of this E-mail and >>> any printout. >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> =20 >> This E-mail and any of its attachments may contain Time >> Warner Cable proprietary information, which is privileged, >> confidential, or subject to copyright belonging to Time >> Warner Cable. This E-mail is intended solely for the use of >> the individual or entity to which it is addressed. If you are >> not the intended recipient of this E-mail, you are hereby >> notified that any dissemination, distribution, copying, or >> action taken in relation to the contents of and attachments >> to this E-mail is strictly prohibited and may be unlawful. If >> you have received this E-mail in error, please notify the >> sender immediately and permanently delete the original and >> any copy of this E-mail and any printout. >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > =20 From rkoodli@starentnetworks.com Thu Jul 2 11:02:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B6C3A6B8B; Thu, 2 Jul 2009 11:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuFuIP4lTSxk; Thu, 2 Jul 2009 11:02:12 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id B87BA3A6D84; Thu, 2 Jul 2009 11:02:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id AE8E490138; Thu, 2 Jul 2009 13:33:41 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05568-18; Thu, 2 Jul 2009 13:33:40 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 2 Jul 2009 13:33:40 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 13:33:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2009 13:30:49 -0400 Message-ID: <4D35478224365146822AE9E3AD4A2666093829E5@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription Thread-Index: Acn66EmnMaQvW/7GSu6IZL3dk43rbgAUdOLI References: <4A4A3BD3.1040703@it.uc3m.es> <4D35478224365146822AE9E3AD4A266609E3BF87$0001@exchtewks3.starentnetworks.com> <4A4B570E.5090301@it.uc3m.es> <4D35478224365146822AE9E3AD4A266609ECF396@exchtewks3.starentnetworks.com> <4A4C643E.5080509@it.uc3m.es> From: "Koodli, Rajeev" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 02 Jul 2009 17:33:21.0335 (UTC) FILETIME=[31C42470:01C9FB3B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: netext@ietf.org, netlmm@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:02:12 -0000 =20 >So, i understand that the answer to the question 3 >3)- What capabilities need to be controlled by the network? >When the MN performs a handover from one interface to another one? >How the node distributes the load among interfaces? in which direction? >Which flow is routed through which interface? in which direction? >Is the network in all cases, correct? >That would be a requirement for the solution? For network-based mobility, it is reasonable to think that the network = is in charge of inducing handovers. The control logic of when to induce = handover, "which direction" etc. are node-internal; we are only = interested in protocol aspects when a node does decide to act. The granularity of handover can vary - entire HNP is moved vs. a subset = of flows. Nevertheless, the design is from a network perspective.=20 -Rajeev =20 > Thanks, > > -Rajeev > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > =20 From marcelo@it.uc3m.es Thu Jul 2 11:12:53 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2BE28C252 for ; Thu, 2 Jul 2009 11:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD5Idny2Iw-F for ; Thu, 2 Jul 2009 11:12:51 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 51B9F28C245 for ; Thu, 2 Jul 2009 11:12:51 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (110.pool85-53-138.dynamic.orange.es [85.53.138.110]) by smtp03.uc3m.es (Postfix) with ESMTP id EF24772D672; Thu, 2 Jul 2009 20:13:06 +0200 (CEST) Message-ID: <4A4CF8B2.7010504@it.uc3m.es> Date: Thu, 02 Jul 2009 20:13:06 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4D35478224365146822AE9E3AD4A266609ECF38E@exchtewks3.starentnetworks.com> <4A4C63CA.7040708@it.uc3m.es> <4D35478224365146822AE9E3AD4A2666093829E4@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A2666093829E4@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16740.001 Cc: netext@ietf.org Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bofdescription X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:12:53 -0000 Koodli, Rajeev escribió: > > Hi Marcelo, > > > >> Perhaps implicit here is the distinction between changes to mobility >> protocol that affects the MN and extensions in general (such as the >> ability to inform a MN to use a different i/f for a particular traffic >> flow). >> >> > > >>> i fail to see how this is not central to the flow mobility feature that >>> we need to provide >>> > > RKo> if the network decides to move a flow from one interface to another, it would be good to have the ability to inform the MN, no? > > exactly, so this is why i fail to see how this is not central to the mobility mechanisms that we want to define > -Rajeev > > > Regards, marcelo > > >> I agree that MN should still be unaware of how its mobility is managed. >> We should also allow for "supplementary" (for the lack of a better word) >> extensions (which may need to be done L3). >> >> >> > > > >> Regards, >> >> -Rajeev >> >> >> >> >>> --kan-- >>> -- >>> Kevin A. Noll >>> >>> >>> -----Original Message----- >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >>> Sent: Wednesday, July 01, 2009 12:26 PM >>> To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft >>> of the bof description >>> >>> Kevin, >>> >>> Thanks for the input. I understand where you're coming from >>> and I have two small comments to make. >>> >>> First I think you're assuming that mobility support for the >>> multihoming scenario we're discussing must be done in the >>> kernel. This is not the case at all. Things can be done in >>> user space as an add-on application. >>> >>> Second, you made this comment: >>> >>> >>> >>>> 4. At least some carriers prefer to manage mobility inside >>>> >>>> >>> the network >>> >>> >>>> rather than on the customer device. This is something that we are >>>> constantly discussing internal to our organization, with >>>> >>>> >>> vendors, and >>> >>> >>>> with other operators. >>>> >>>> >>> => To be precise, all carriers manage mobility from both the >>> network and host sides. It's just not L3 mobility. So the >>> question should be whether it is acceptable to manage L3 >>> mobility on both sides as well. And there is pretty good >>> reasons for doing that, especially that most mobile devices >>> today have multiple interfaces to different technologies, >>> which never happened before. >>> >>> Hesham >>> >>> >>> On 1/07/09 11:52 PM, "Noll, Kevin" wrote: >>> >>> >>> >>>> I've been lurking here for a while watching the >>>> >>>> >>> conversation. Please >>> >>> >>>> accept my apologies for dropping in unexpectedly, but I thought I >>>> >>>> >>> might >>> >>> >>>> give at least one operator's viewpoint. >>>> >>>> You are correct that most data cards being sold today >>>> >>>> >>> require you to >>> >>> >>>> install the carrier's software. This software typically contains a >>>> connection manager and the OS drivers required to operate the data >>>> >>>> >>> card. >>> >>> >>>> Technically speaking, the data cards that I have worked with do not >>>> >>>> >>> all >>> >>> >>>> *require* the connection manager to operate, though it varies from >>>> >>>> >>> card >>> >>> >>>> to card. Obviously, though, they *do* need the drivers. >>>> >>>> What we saw with WiFi was a technology that began as an >>>> >>>> >>> add-on to our >>> >>> >>>> computing devices (laptops, etc.). WiFi grew, matured, and >>>> >>>> >>> became so >>> >>> >>>> widely accepted that operating systems began to ship with native >>>> drivers, the add-on device became integrated into the computing >>>> >>>> >>> devices >>> >>> >>>> and we no longer needed to install 3rd-party drivers or connection >>>> software. >>>> >>>> As a network provider/operator, we like this model because >>>> >>>> >>> it is very >>> >>> >>>> expensive to write and maintain the connection software and drivers >>>> >>>> >>> and >>> >>> >>>> keep the user's device up to date. Adding a mobility stack to the >>>> software being installed adds significantly to this cost. We are >>>> >>>> >>> seeing >>> >>> >>>> the cost come down, but there's still the issue of >>>> >>>> >>> configuration and >>> >>> >>>> what-not. >>>> >>>> We expect to see open networks and technologies like WiMAX (and >>>> >>>> >>> possibly >>> >>> >>>> LTE) change the traditional cellular data-card model to one that is >>>> >>>> >>> more >>> >>> >>>> similar to WiFi, hopefully driving down the cost of the >>>> >>>> >>> software and >>> >>> >>>> moving the software development tasks out of the operator >>>> >>>> >>> and into the >>> >>> >>>> OS vendor community. >>>> >>>> This said, I think it would be a mistake to make any assumptions on >>>> either of the two points mentioned below. >>>> >>>> 1. In the future the carrier may not deliver software with the data >>>> card, so it's probably a bad assumption to say that the >>>> >>>> >>> carrier would >>> >>> >>>> simply deliver a mobility stack with the device. >>>> >>>> 2. It's probably a good assumption to say that devices will >>>> >>>> >>> eventually >>> >>> >>>> have native mobility stacks. We are already seeing this >>>> >>>> >>> development in >>> >>> >>>> mainstream operating systems. This is similar to the evolution of >>>> >>>> >>> WiFi. >>> >>> >>>> 3. It's probably not a good assumption to say that *all* >>>> >>>> >>> devices will >>> >>> >>>> have the perfect combination of native support or carrier support. >>>> >>>> 4. At least some carriers prefer to manage mobility inside >>>> >>>> >>> the network >>> >>> >>>> rather than on the customer device. This is something that we are >>>> constantly discussing internal to our organization, with >>>> >>>> >>> vendors, and >>> >>> >>>> with other operators. >>>> >>>> Based on this, the case for extending the functionality of PMIP6 is >>>> pretty strong, at least in my opinion. >>>> >>>> On the other hand, we will also continue following the >>>> >>>> >>> development of >>> >>> >>>> native stacks and evaluate when and how best to use them in our >>>> >>>> >>> product >>> >>> >>>> offerings. Similarly, we will continue to evaluate whether >>>> >>>> >>> or not we >>> >>> >>>> need to deliver a mobility stack with our data card software. >>>> >>>> Thanks! >>>> >>>> --kan-- >>>> -- >>>> Kevin A. Noll >>>> >>>> >>>> >>>> P Go Green! Print this email only when necessary. Thank you for >>>> >>>> >>> helping Time >>> >>> >>>> Warner Cable be environmentally responsible. >>>> >>>> >>>> -----Original Message----- >>>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On >>>> >>>> >>> Behalf >>> >>> >>>> Of Hesham Soliman >>>> Sent: Tuesday, June 30, 2009 11:59 PM >>>> To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es >>>> Cc: netext@ietf.org; netlmm@ietf.org >>>> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft >>>> >>>> >>> of the bof >>> >>> >>>> description >>>> >>>> >>>> Hi Raj, >>>> >>>> I had a brief offline chat with Julien and thought that I >>>> >>>> >>> could refine >>> >>> >>>> my suggestion a bit more to make the point clearer. My point is that >>>> >>>> >>> there >>> >>> >>>> are >>>> currently two slightly different points being made about the >>>> >>>> >>> requirement >>> >>> >>>> on >>>> host involvement 1) no SW on the host and the more nuanced 2) no >>>> protocol support on the host. I won't even get into the reasons for >>>> point 2) above and I'll let the people who raise it provide those >>>> reasons, I can't figure out any technical reasons there. >>>> >>>> Anyway, my point is that 1) above is not an issue today because it >>>> already happens on a very large scale, so requiring it for >>>> >>>> >>> a specific >>> >>> >>>> feature like multihoming is hardly a leap. I can imagine ads for >>>> "download your wireless optimiser from wwww.operator.com and save >>>> money" (ok not very >>>> >>>> >>> creative). >>> >>> >>>> The subtle difference between 1) and 2) is IMO a moot point anyway >>>> because >>>> 2) simply says that operators don't want protocol support in the >>>> network, but that support already exists in the form of PMIP and if >>>> you have >>>> >>>> >>> PMIP >>> >>> >>>> you >>>> have MIP. So, both motivations seem to be on shaky ground. >>>> And yes, you can of course integrate 3G modems in computers, but you >>>> >>>> >>> can >>> >>> >>>> also integrate mobility code in the same computers with the 3G >>>> >>>> >>> support. >>> >>> >>>> The >>>> SW that is provided with the modems is not only connection SW it >>>> actually provides a number of features (e.g. Receiving SMS, account >>>> >>>> >>> information, >>> >>> >>>> email ....etc) so it's a clear move by operators to be present on >>>> >>>> >>> those >>> >>> >>>> machines. I don't think it's anything like WLAN connctions SW. >>>> >>>> Of course it's worth mentioning that the elephant in the >>>> >>>> >>> room is the >>> >>> >>>> binary requirement on host support of protocols. We need to have a >>>> yes/no answer as to whether there is a requirement to NOT have >>>> protocol support in the host. >>>> At the moment this is being kept very vague. >>>> >>>> Hesham >>>> >>>> >>>> >>>>>> => No one I know can get a 3G data card to access the >>>>>> >>>>>> >>> Internet from >>> >>> >>>> their PC >>>> >>>> >>>>>> without having to install a piece of software on their PC to make >>>>>> >>>>>> >>> it >>> >>> >>>> work. >>>> >>>> >>>>>> So I think your assumption that the operator cannot >>>>>> >>>>>> >>> mandate software >>> >>> >>>> on the >>>> >>>> >>>>>> host is questionable, because they already do (unfortunately). >>>>>> >>>>>> >>>>> The situation that you describe above was the same when >>>>> >>>>> >>> 802.11 first >>> >>> >>>> rolled >>>> >>>> >>>>> around as well. >>>>> You had to install a piece of software that came with the PC card. >>>>> >>>>> >>> But >>> >>> >>>> that >>>> >>>> >>>>> has changed with >>>>> wifi now being an integral part of the notebook computers. >>>>> And I think you could expect 3G chipsets and access >>>>> >>>>> >>> built-in as well >>> >>> >>>> in due >>>> >>>> >>>>> course of time. At least I know of a few operators in the >>>>> >>>>> >>> US (as well >>> >>> >>>>> as notebook manufacturers) who offer >>>>> >>>>> >>> such >>> >>> >>>>> net/notebook computers, >>>>> i.e with integrated 3G access. I do not know what additional sw is >>>>> >>>>> >>>> loaded on >>>> >>>> >>>>> these but at least the end user >>>>> is not installing anything else. >>>>> Does it imply that such hosts will include the software that would >>>>> >>>>> >>>> enable host >>>> >>>> >>>>> mobility? Its an open question (i.e unknown) and will >>>>> >>>>> >>> depend largely >>> >>> >>>>> on operator choices and vendors. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> >>>>>> Hesham >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netlmm >>>>> >>>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netlmm >>>> This E-mail and any of its attachments may contain Time >>>> >>>> >>> Warner Cable >>> >>> >>>> proprietary information, which is privileged, confidential, >>>> >>>> >>> or subject >>> >>> >>>> to copyright belonging to Time Warner Cable. This E-mail is >>>> >>>> >>> intended >>> >>> >>>> solely for the use of the individual or entity to which it is >>>> addressed. If you are not the intended recipient of this >>>> >>>> >>> E-mail, you >>> >>> >>>> are hereby notified that any dissemination, distribution, >>>> >>>> >>> copying, or >>> >>> >>>> action taken in relation to the contents of and attachments to this >>>> E-mail is strictly prohibited and may be unlawful. If you have >>>> received this E-mail in error, please notify the sender immediately >>>> and permanently delete the original and any copy of this E-mail and >>>> any printout. >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >>> This E-mail and any of its attachments may contain Time >>> Warner Cable proprietary information, which is privileged, >>> confidential, or subject to copyright belonging to Time >>> Warner Cable. This E-mail is intended solely for the use of >>> the individual or entity to which it is addressed. If you are >>> not the intended recipient of this E-mail, you are hereby >>> notified that any dissemination, distribution, copying, or >>> action taken in relation to the contents of and attachments >>> to this E-mail is strictly prohibited and may be unlawful. If >>> you have received this E-mail in error, please notify the >>> sender immediately and permanently delete the original and >>> any copy of this E-mail and any printout. >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> >> > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From rkoodli@starentnetworks.com Thu Jul 2 11:39:42 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3671F3A6B38 for ; Thu, 2 Jul 2009 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rIyARYixDrD for ; Thu, 2 Jul 2009 11:39:40 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 136A93A6A36 for ; Thu, 2 Jul 2009 11:39:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 6B06A900C6 for ; Thu, 2 Jul 2009 14:39:54 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12554-15 for ; Thu, 2 Jul 2009 14:39:52 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 2 Jul 2009 14:39:52 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 14:39:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jul 2009 14:39:52 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609F5D4B8@exchtewks3.starentnetworks.com> In-Reply-To: <4A4CF8B2.7010504@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] NEXTEXT2: first draft of the bof description Thread-Index: Acn7QMkoFfKmykB5RoGqCRPcBP0yYQAA/neA References: <4D35478224365146822AE9E3AD4A266609ECF38E@exchtewks3.starentnetworks.com> <4A4C63CA.7040708@it.uc3m.es> <4D35478224365146822AE9E3AD4A2666093829E4@exchtewks3.starentnetworks.com> <4A4CF8B2.7010504@it.uc3m.es> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 02 Jul 2009 18:39:51.0918 (UTC) FILETIME=[7C56C8E0:01C9FB44] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] NEXTEXT2: first draft of the bof description X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:39:42 -0000 =20 > > RKo> if the network decides to move a flow from one=20 > interface to another, it would be good to have the ability to=20 > inform the MN, no? > > =20 >=20 > exactly, so this is why i fail to see how this is not central=20 > to the mobility mechanisms that we want to define >=20 Okay, we seem to be in agreement largely.=20 I don't claim that this is central to mobility management, which is basically PMIP. However, this kind of indication may be necessary for a feature (such as flow mobility) to work - if we cannot find support in L2.=20 -Rajeev > > -Rajeev > > > > > > Regards, marcelo > > > > =20 > >> I agree that MN should still be unaware of how its=20 > mobility is managed. > >> We should also allow for "supplementary" (for the lack of a better=20 > >> word) extensions (which may need to be done L3). > >> > >> =20 > >> =20 > > > > > > =20 > >> Regards, > >> > >> -Rajeev > >> > >> > >> =20 > >> =20 > >>> --kan-- > >>> -- > >>> Kevin A. Noll > >>> > >>> > >>> -----Original Message----- > >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >>> Sent: Wednesday, July 01, 2009 12:26 PM > >>> To: Noll, Kevin; netext@ietf.org; netlmm@ietf.org > >>> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first=20 > draft of the=20 > >>> bof description > >>> > >>> Kevin, > >>> > >>> Thanks for the input. I understand where you're coming from and I=20 > >>> have two small comments to make. > >>> > >>> First I think you're assuming that mobility support for the=20 > >>> multihoming scenario we're discussing must be done in the kernel.=20 > >>> This is not the case at all. Things can be done in user=20 > space as an=20 > >>> add-on application. > >>> > >>> Second, you made this comment: > >>> > >>> =20 > >>> =20 > >>>> 4. At least some carriers prefer to manage mobility inside > >>>> =20 > >>>> =20 > >>> the network > >>> =20 > >>> =20 > >>>> rather than on the customer device. This is something=20 > that we are=20 > >>>> constantly discussing internal to our organization, with > >>>> =20 > >>>> =20 > >>> vendors, and > >>> =20 > >>> =20 > >>>> with other operators. > >>>> =20 > >>>> =20 > >>> =3D> To be precise, all carriers manage mobility from both=20 > the network=20 > >>> and host sides. It's just not L3 mobility. So the=20 > question should be=20 > >>> whether it is acceptable to manage L3 mobility on both sides as=20 > >>> well. And there is pretty good reasons for doing that, especially=20 > >>> that most mobile devices today have multiple interfaces=20 > to different=20 > >>> technologies, which never happened before. > >>> > >>> Hesham > >>> > >>> > >>> On 1/07/09 11:52 PM, "Noll, Kevin" wrote: > >>> > >>> =20 > >>> =20 > >>>> I've been lurking here for a while watching the > >>>> =20 > >>>> =20 > >>> conversation. Please > >>> =20 > >>> =20 > >>>> accept my apologies for dropping in unexpectedly, but I thought I > >>>> =20 > >>>> =20 > >>> might > >>> =20 > >>> =20 > >>>> give at least one operator's viewpoint. > >>>> > >>>> You are correct that most data cards being sold today > >>>> =20 > >>>> =20 > >>> require you to > >>> =20 > >>> =20 > >>>> install the carrier's software. This software typically=20 > contains a=20 > >>>> connection manager and the OS drivers required to=20 > operate the data > >>>> =20 > >>>> =20 > >>> card. > >>> =20 > >>> =20 > >>>> Technically speaking, the data cards that I have worked=20 > with do not > >>>> =20 > >>>> =20 > >>> all > >>> =20 > >>> =20 > >>>> *require* the connection manager to operate, though it=20 > varies from > >>>> =20 > >>>> =20 > >>> card > >>> =20 > >>> =20 > >>>> to card. Obviously, though, they *do* need the drivers. > >>>> > >>>> What we saw with WiFi was a technology that began as an > >>>> =20 > >>>> =20 > >>> add-on to our > >>> =20 > >>> =20 > >>>> computing devices (laptops, etc.). WiFi grew, matured, and > >>>> =20 > >>>> =20 > >>> became so > >>> =20 > >>> =20 > >>>> widely accepted that operating systems began to ship with native=20 > >>>> drivers, the add-on device became integrated into the computing > >>>> =20 > >>>> =20 > >>> devices > >>> =20 > >>> =20 > >>>> and we no longer needed to install 3rd-party drivers or=20 > connection=20 > >>>> software. > >>>> > >>>> As a network provider/operator, we like this model because > >>>> =20 > >>>> =20 > >>> it is very > >>> =20 > >>> =20 > >>>> expensive to write and maintain the connection software=20 > and drivers > >>>> =20 > >>>> =20 > >>> and > >>> =20 > >>> =20 > >>>> keep the user's device up to date. Adding a mobility=20 > stack to the=20 > >>>> software being installed adds significantly to this cost. We are > >>>> =20 > >>>> =20 > >>> seeing > >>> =20 > >>> =20 > >>>> the cost come down, but there's still the issue of > >>>> =20 > >>>> =20 > >>> configuration and > >>> =20 > >>> =20 > >>>> what-not. > >>>> > >>>> We expect to see open networks and technologies like WiMAX (and > >>>> =20 > >>>> =20 > >>> possibly > >>> =20 > >>> =20 > >>>> LTE) change the traditional cellular data-card model to=20 > one that is > >>>> =20 > >>>> =20 > >>> more > >>> =20 > >>> =20 > >>>> similar to WiFi, hopefully driving down the cost of the > >>>> =20 > >>>> =20 > >>> software and > >>> =20 > >>> =20 > >>>> moving the software development tasks out of the operator > >>>> =20 > >>>> =20 > >>> and into the > >>> =20 > >>> =20 > >>>> OS vendor community. > >>>> > >>>> This said, I think it would be a mistake to make any=20 > assumptions on=20 > >>>> either of the two points mentioned below. > >>>> > >>>> 1. In the future the carrier may not deliver software=20 > with the data=20 > >>>> card, so it's probably a bad assumption to say that the > >>>> =20 > >>>> =20 > >>> carrier would > >>> =20 > >>> =20 > >>>> simply deliver a mobility stack with the device. > >>>> > >>>> 2. It's probably a good assumption to say that devices will > >>>> =20 > >>>> =20 > >>> eventually > >>> =20 > >>> =20 > >>>> have native mobility stacks. We are already seeing this > >>>> =20 > >>>> =20 > >>> development in > >>> =20 > >>> =20 > >>>> mainstream operating systems. This is similar to the evolution of > >>>> =20 > >>>> =20 > >>> WiFi. > >>> =20 > >>> =20 > >>>> 3. It's probably not a good assumption to say that *all* > >>>> =20 > >>>> =20 > >>> devices will > >>> =20 > >>> =20 > >>>> have the perfect combination of native support or=20 > carrier support. > >>>> > >>>> 4. At least some carriers prefer to manage mobility inside > >>>> =20 > >>>> =20 > >>> the network > >>> =20 > >>> =20 > >>>> rather than on the customer device. This is something=20 > that we are=20 > >>>> constantly discussing internal to our organization, with > >>>> =20 > >>>> =20 > >>> vendors, and > >>> =20 > >>> =20 > >>>> with other operators. > >>>> > >>>> Based on this, the case for extending the functionality=20 > of PMIP6 is=20 > >>>> pretty strong, at least in my opinion. > >>>> > >>>> On the other hand, we will also continue following the > >>>> =20 > >>>> =20 > >>> development of > >>> =20 > >>> =20 > >>>> native stacks and evaluate when and how best to use them in our > >>>> =20 > >>>> =20 > >>> product > >>> =20 > >>> =20 > >>>> offerings. Similarly, we will continue to evaluate whether > >>>> =20 > >>>> =20 > >>> or not we > >>> =20 > >>> =20 > >>>> need to deliver a mobility stack with our data card software. > >>>> > >>>> Thanks! > >>>> > >>>> --kan-- > >>>> -- > >>>> Kevin A. Noll > >>>> > >>>> > >>>> > >>>> P Go Green! Print this email only when necessary. Thank you for > >>>> =20 > >>>> =20 > >>> helping Time > >>> =20 > >>> =20 > >>>> Warner Cable be environmentally responsible. > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > >>>> =20 > >>>> =20 > >>> Behalf > >>> =20 > >>> =20 > >>>> Of Hesham Soliman > >>>> Sent: Tuesday, June 30, 2009 11:59 PM > >>>> To: Basavaraj.Patil@nokia.com; marcelo@it.uc3m.es > >>>> Cc: netext@ietf.org; netlmm@ietf.org > >>>> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft > >>>> =20 > >>>> =20 > >>> of the bof > >>> =20 > >>> =20 > >>>> description > >>>> > >>>> > >>>> Hi Raj, > >>>> > >>>> I had a brief offline chat with Julien and thought that I > >>>> =20 > >>>> =20 > >>> could refine > >>> =20 > >>> =20 > >>>> my suggestion a bit more to make the point clearer. My point is=20 > >>>> that > >>>> =20 > >>>> =20 > >>> there > >>> =20 > >>> =20 > >>>> are > >>>> currently two slightly different points being made about the > >>>> =20 > >>>> =20 > >>> requirement > >>> =20 > >>> =20 > >>>> on > >>>> host involvement 1) no SW on the host and the more nuanced 2) no=20 > >>>> protocol support on the host. I won't even get into the=20 > reasons for=20 > >>>> point 2) above and I'll let the people who raise it=20 > provide those=20 > >>>> reasons, I can't figure out any technical reasons there. > >>>> > >>>> Anyway, my point is that 1) above is not an issue today=20 > because it=20 > >>>> already happens on a very large scale, so requiring it for > >>>> =20 > >>>> =20 > >>> a specific > >>> =20 > >>> =20 > >>>> feature like multihoming is hardly a leap. I can imagine ads for=20 > >>>> "download your wireless optimiser from wwww.operator.com=20 > and save=20 > >>>> money" (ok not very > >>>> =20 > >>>> =20 > >>> creative). > >>> =20 > >>> =20 > >>>> The subtle difference between 1) and 2) is IMO a moot=20 > point anyway=20 > >>>> because > >>>> 2) simply says that operators don't want protocol support in the=20 > >>>> network, but that support already exists in the form of=20 > PMIP and if=20 > >>>> you have > >>>> =20 > >>>> =20 > >>> PMIP > >>> =20 > >>> =20 > >>>> you > >>>> have MIP. So, both motivations seem to be on shaky ground. > >>>> And yes, you can of course integrate 3G modems in computers, but=20 > >>>> you > >>>> =20 > >>>> =20 > >>> can > >>> =20 > >>> =20 > >>>> also integrate mobility code in the same computers with the 3G > >>>> =20 > >>>> =20 > >>> support. > >>> =20 > >>> =20 > >>>> The > >>>> SW that is provided with the modems is not only connection SW it=20 > >>>> actually provides a number of features (e.g. Receiving=20 > SMS, account > >>>> =20 > >>>> =20 > >>> information, > >>> =20 > >>> =20 > >>>> email ....etc) so it's a clear move by operators to be present on > >>>> =20 > >>>> =20 > >>> those > >>> =20 > >>> =20 > >>>> machines. I don't think it's anything like WLAN connctions SW. > >>>> > >>>> Of course it's worth mentioning that the elephant in the > >>>> =20 > >>>> =20 > >>> room is the > >>> =20 > >>> =20 > >>>> binary requirement on host support of protocols. We need=20 > to have a=20 > >>>> yes/no answer as to whether there is a requirement to NOT have=20 > >>>> protocol support in the host. > >>>> At the moment this is being kept very vague. > >>>> > >>>> Hesham > >>>> > >>>> =20 > >>>> =20 > >>>>>> =3D> No one I know can get a 3G data card to access the > >>>>>> =20 > >>>>>> =20 > >>> Internet from > >>> =20 > >>> =20 > >>>> their PC > >>>> =20 > >>>> =20 > >>>>>> without having to install a piece of software on their PC to=20 > >>>>>> make > >>>>>> =20 > >>>>>> =20 > >>> it > >>> =20 > >>> =20 > >>>> work. > >>>> =20 > >>>> =20 > >>>>>> So I think your assumption that the operator cannot > >>>>>> =20 > >>>>>> =20 > >>> mandate software > >>> =20 > >>> =20 > >>>> on the > >>>> =20 > >>>> =20 > >>>>>> host is questionable, because they already do (unfortunately). > >>>>>> =20 > >>>>>> =20 > >>>>> The situation that you describe above was the same when > >>>>> =20 > >>>>> =20 > >>> 802.11 first > >>> =20 > >>> =20 > >>>> rolled > >>>> =20 > >>>> =20 > >>>>> around as well. > >>>>> You had to install a piece of software that came with=20 > the PC card. > >>>>> =20 > >>>>> =20 > >>> But > >>> =20 > >>> =20 > >>>> that > >>>> =20 > >>>> =20 > >>>>> has changed with > >>>>> wifi now being an integral part of the notebook computers. > >>>>> And I think you could expect 3G chipsets and access > >>>>> =20 > >>>>> =20 > >>> built-in as well > >>> =20 > >>> =20 > >>>> in due > >>>> =20 > >>>> =20 > >>>>> course of time. At least I know of a few operators in the > >>>>> =20 > >>>>> =20 > >>> US (as well > >>> =20 > >>> =20 > >>>>> as notebook manufacturers) who offer > >>>>> =20 > >>>>> =20 > >>> such > >>> =20 > >>> =20 > >>>>> net/notebook computers, > >>>>> i.e with integrated 3G access. I do not know what=20 > additional sw is > >>>>> =20 > >>>>> =20 > >>>> loaded on > >>>> =20 > >>>> =20 > >>>>> these but at least the end user > >>>>> is not installing anything else. > >>>>> Does it imply that such hosts will include the software=20 > that would > >>>>> =20 > >>>>> =20 > >>>> enable host > >>>> =20 > >>>> =20 > >>>>> mobility? Its an open question (i.e unknown) and will > >>>>> =20 > >>>>> =20 > >>> depend largely > >>> =20 > >>> =20 > >>>>> on operator choices and vendors. > >>>>> > >>>>> -Raj > >>>>> > >>>>> =20 > >>>>> =20 > >>>>>> Hesham > >>>>>> =20 > >>>>>> =20 > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netlmm > >>>>> =20 > >>>>> =20 > >>>> _______________________________________________ > >>>> netlmm mailing list > >>>> netlmm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netlmm > >>>> This E-mail and any of its attachments may contain Time > >>>> =20 > >>>> =20 > >>> Warner Cable > >>> =20 > >>> =20 > >>>> proprietary information, which is privileged, confidential, > >>>> =20 > >>>> =20 > >>> or subject > >>> =20 > >>> =20 > >>>> to copyright belonging to Time Warner Cable. This E-mail is > >>>> =20 > >>>> =20 > >>> intended > >>> =20 > >>> =20 > >>>> solely for the use of the individual or entity to which it is=20 > >>>> addressed. If you are not the intended recipient of this > >>>> =20 > >>>> =20 > >>> E-mail, you > >>> =20 > >>> =20 > >>>> are hereby notified that any dissemination, distribution, > >>>> =20 > >>>> =20 > >>> copying, or > >>> =20 > >>> =20 > >>>> action taken in relation to the contents of and=20 > attachments to this=20 > >>>> E-mail is strictly prohibited and may be unlawful. If you have=20 > >>>> received this E-mail in error, please notify the sender=20 > immediately=20 > >>>> and permanently delete the original and any copy of this=20 > E-mail and=20 > >>>> any printout. > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>> =20 > >>>> =20 > >>> This E-mail and any of its attachments may contain Time=20 > Warner Cable=20 > >>> proprietary information, which is privileged, confidential, or=20 > >>> subject to copyright belonging to Time Warner Cable. This=20 > E-mail is=20 > >>> intended solely for the use of the individual or entity=20 > to which it=20 > >>> is addressed. If you are not the intended recipient of=20 > this E-mail,=20 > >>> you are hereby notified that any dissemination, distribution,=20 > >>> copying, or action taken in relation to the contents of and=20 > >>> attachments to this E-mail is strictly prohibited and may be=20 > >>> unlawful. If you have received this E-mail in error,=20 > please notify=20 > >>> the sender immediately and permanently delete the=20 > original and any=20 > >>> copy of this E-mail and any printout. > >>> > >>> _______________________________________________ > >>> netext mailing list > >>> netext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netext > >>> > >>> =20 > >>> =20 > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > >> =20 > >> =20 > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > =20 >=20 >=20 From teemu.savolainen@nokia.com Thu Jul 2 13:38:37 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAC93A6DE7 for ; Thu, 2 Jul 2009 13:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqY0Jl2CfWxZ for ; Thu, 2 Jul 2009 13:38:37 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C76843A6DE4 for ; Thu, 2 Jul 2009 13:38:36 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n62KcGcS029458 for ; Thu, 2 Jul 2009 23:38:38 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 23:37:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 23:37:46 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 2 Jul 2009 22:37:44 +0200 From: To: Date: Thu, 2 Jul 2009 22:36:41 +0200 Thread-Topic: New I-D draft-savolainen-netext-intertech-handover-00 Thread-Index: Acn7Uv2Y5BPHLJbVRfyD5XkJ9zqSYAAAKYVA Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3A7012E1DE@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jul 2009 20:37:46.0182 (UTC) FILETIME=[F4EDCE60:01C9FB54] X-Nokia-AV: Clean Subject: [netext] New I-D draft-savolainen-netext-intertech-handover-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:38:38 -0000 Hi Netext, Here is a draft-savolainen-netext-intertech-handover, which replaces the dr= aft-premec-netlmm-intertech-handover-01.txt, and is related to NETEXT2 disc= ussion on inter-technology handover support extension for PMIP6. http://www.ietf.org/internet-drafts/draft-savolainen-netext-intertech-hando= ver-00.txt Abstract: -- Proxy Mobile IPv6 [RFC5213] is a network based mobility management protocol which provides IP mobility service to a host in a way which is transparent to the host itself. This document analyses the scenarios in which a multi-interfaced Mobile Node roams in a Proxy Mobile IPv6 domain which consists of access networks that are of different types. In order to support session continuity as the Mobile Node moves between access networks within the PMIP6 domain, the Mobile Node either needs to use host based Mobile IP or be enhanced with various capabilities described in this document. -- You may be particularly interested on chapter 11, where we conclude: -- 11. Conclusions and recommendations It is clear that for IP session continuity during PMIP6 inter- technology handovers changes on many if not all operating systems are necessary. While there are several technical ways to accomplish that, as described earlier, all those require support from both hosts and access network elements. Enhancing the MN with functionality to achieve inter-technology handovers is almost the same as installing host based mobility support. Since host based mobility is already specified and is capable of accomplishing inter-technology handovers and flow mobility, there is no reason to reinvent the same in the case of PMIP6. Therefore we recommend to: 1. Use host based mobility solutions, such as DSMIP6 [RFC5555], for inter-technology handovers. DSMIP6 has the benefit of not requiring special support from access networks (such as WLAN hotspots), it allows overlapping IPv4 care-of addresses, and has been standardized already. 2. On access technologies where PMIP6 based handovers are absolutely required, it is best to standardize access technology specific solutions that provide intra-technology looking handovers for hosts. 3. In the case NetExt working group chooses to standardize inter- technology handovers for PMIP6, we propose doing that with changes to DHCPv4 and to DHCPv6 and/or Router Solicitation/Router Advertisements as described in this document. -- Best regards, Teemu= From behcetsarikaya@yahoo.com Thu Jul 2 14:11:38 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1EC3A68A2 for ; Thu, 2 Jul 2009 14:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttcHXIkyHm+D for ; Thu, 2 Jul 2009 14:11:37 -0700 (PDT) Received: from n57.bullet.mail.sp1.yahoo.com (n57.bullet.mail.sp1.yahoo.com [98.136.44.49]) by core3.amsl.com (Postfix) with SMTP id 5C9C03A6AD0 for ; Thu, 2 Jul 2009 14:11:37 -0700 (PDT) Received: from [216.252.122.216] by n57.bullet.mail.sp1.yahoo.com with NNFMP; 02 Jul 2009 21:10:49 -0000 Received: from [67.195.9.82] by t1.bullet.sp1.yahoo.com with NNFMP; 02 Jul 2009 21:10:49 -0000 Received: from [67.195.9.105] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 02 Jul 2009 21:10:49 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 02 Jul 2009 21:10:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566085.66216.bm@omp109.mail.gq1.yahoo.com Received: (qmail 53252 invoked by uid 60001); 2 Jul 2009 21:10:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246569049; bh=EO3Wcmu6588lmB40aTPGqIdhGpXm81DVoA0u5LrArws=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KbuMMSwkva5pVk2VdNKSveTIQFKySJWADlNP0OoEmT/61Iq4T00rhpU8bDSbYbLRYtcGwZXBmJwy67K7lr2B5svWhDck9oNAV9mdDE75WZoa3uez5hWtZ2eUmaEa5Z7AJq7PmEG7P8v+Tju53pKfRFdt4b/vyeIfz90eOWKCfcc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0TczrrFI+eHD+pTElD4WMWa7JLERIPs8vgC05dHSGkvssbmN/I9fHjPUoKvfR7TOAEN72zuKuGMGrnAhfYi+BP+ucsuw/a0mgo+8ngqR1/aKoydPyVqF/cThy+mkc2XfpGdiUakRmG2s5RqJ6+c6sRxwkf5ZlX05UPLmfZTXkVA=; Message-ID: <164753.52323.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: _67PaOkVM1l6u6C5fWxaaPMdSTllVtdku7z_fcOYaMLYadO6vHqs6VT3KTWIGKEaJtgcSqSXcX6oQlcDB3ffmHyatENAJgwHtVVR9xZh44Ol6E1wEcsRafoKEIb3wkdh1SGFqFsuif7qoYHDHDsy7zr2eg9QH3fmU7nUcqh8hjKnXeHEIOEzh6RLphjo_YMAMZWfs4DEKHbzTB2vN4J6BWSZFMJWGnhQT7u2wymzbI.LWkZqNlZy4O0jiKBmcmcqkPmYz_SZOZoYBgm62a95st1DzcqO_Ldih7FfXGS__9dNAhbSw.h4rRY- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 02 Jul 2009 14:10:49 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <18034D4D7FE9AE48BF19AB1B0EF2729F3A7012E1DE@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 2 Jul 2009 14:10:49 -0700 (PDT) From: Behcet Sarikaya To: teemu.savolainen@nokia.com, netext@ietf.org In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3A7012E1DE@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] New I-D draft-savolainen-netext-intertech-handover-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:11:38 -0000 Hi Teemu,=0A=0A=0A=0Asnipped the beginning.=0A=0ATherefore we recommend to:= =0A> =0A> =A0 1.=A0 Use host based mobility solutions, such as DSMIP6 [RFC5= 555], for=0A> =A0 =A0 =A0 inter-technology handovers.=A0 DSMIP6 has the ben= efit of not=0A> =A0 =A0 =A0 requiring special support from access networks = (such as WLAN=0A> =A0 =A0 =A0 hotspots), it allows overlapping IPv4 care-of= addresses, and has=0A> =A0 =A0 =A0 been standardized already.=0A=0AYes it = is true that PMIPv6 requires special support on Wi-Fi links.=0A=0A> =0A> = =A0 2.=A0 On access technologies where PMIP6 based handovers are absolutely= =0A> =A0 =A0 =A0 required, it is best to standardize access technology spec= ific=0A> =A0 =A0 =A0 solutions that provide intra-technology looking handov= ers for=0A> =A0 =A0 =A0 hosts.=0A=0AThis is very difficult if not impossibl= e in WiMAX because PHY/MAC is IEEE based which is another SDO.=0A=0AI think= that WiMAX is very important for PMIPv6.=0A=0A=0A> =0A> =A0 3.=A0 In the c= ase NetExt working group chooses to standardize inter-=0A> =A0 =A0 =A0 tech= nology handovers for PMIP6, we propose doing that with=0A> =A0 =A0 =A0 chan= ges to DHCPv4 and to DHCPv6 and/or Router Solicitation/Router=0A> =A0 =A0 = =A0 Advertisements as described in this document.=0A=0A=0AWhy? Why not MN-A= R interface?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A From teemu.savolainen@nokia.com Thu Jul 2 14:27:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6428E3A68A2 for ; Thu, 2 Jul 2009 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okKOPzGrWX42 for ; Thu, 2 Jul 2009 14:27:12 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 289D128C26C for ; Thu, 2 Jul 2009 14:26:04 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n62LNU5M023619; Fri, 3 Jul 2009 00:26:12 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 00:26:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 00:26:04 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 2 Jul 2009 23:26:01 +0200 From: To: , Date: Thu, 2 Jul 2009 23:24:59 +0200 Thread-Topic: [netext] New I-D draft-savolainen-netext-intertech-handover-00 Thread-Index: Acn7WZkQMB/npWOfRUSM03FRTrB2SAAAQC1w Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3A7012E209@NOK-EUMSG-01.mgdnok.nokia.com> References: <18034D4D7FE9AE48BF19AB1B0EF2729F3A7012E1DE@NOK-EUMSG-01.mgdnok.nokia.com> <164753.52323.qm@web111416.mail.gq1.yahoo.com> In-Reply-To: <164753.52323.qm@web111416.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jul 2009 21:26:04.0062 (UTC) FILETIME=[B43333E0:01C9FB5B] X-Nokia-AV: Clean Subject: Re: [netext] New I-D draft-savolainen-netext-intertech-handover-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:27:13 -0000 Hi, (FYI: I'm on vacation so not very able to answer emails - I look forward on= discussions around IETF). >-----Original Message----- >From: ext Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 >Sent: 03 July, 2009 00:11 >To: Savolainen Teemu (Nokia-D-MSW/Tampere); netext@ietf.org >Subject: Re: [netext] New I-D=20 >draft-savolainen-netext-intertech-handover-00 > >> =A0 3.=A0 In the case NetExt working group chooses to standardize inter- >> =A0 =A0 =A0 technology handovers for PMIP6, we propose doing that with >> =A0 =A0 =A0 changes to DHCPv4 and to DHCPv6 and/or Router=20 >> Solicitation/Router >> =A0 =A0 =A0 Advertisements as described in this document. > > >Why? Why not MN-AR interface? We wrote to draft the following, does it help to answer your question? -- o Same interface identifier across access networks This approach is suggested in the [I-D.ietf-netlmm-mn-ar-if]. The idea is that the MN uses the same interface identifier in both access networks if it wants to move its IP session across interfaces. A MAG in a new access network is assumed to acquire the MN's interface identifier during the link establishment phase through link specific mechanisms. A MAG is also assumed to obtain an interface identifier that the MN was using at a previous MAG and the access technology type through context transfer between MAGs or some other unspecified mechanisms. If access technology type is different and the interface identifier is the same in both access networks than the new MAG should take that as an indication of the MN's capability and intention to move its IP sessions across interfaces. In this case the MAG would set the handoff indicator in the PBU message to the value "2: Handoff between two different interfaces of the mobile node". This solution is partly dependent on a link-layer as the MAG learns the MN's interface identifier during the link layer establishment. Note that there are link layers which do not allow for MAC address negotiation and where the MAC address assigned to the device is authenticated by the certificate and thus can not be changed. One example of such link layer is IEEE 802.16 defined in [IEEE802.16] and [IEEE802.16e]. The interface identifier approach is further complicated if the host is simultaneously utilizing multiple IPv6 addresses configured from the same prefix. -- Best regards, Teemu= From cjbc@it.uc3m.es Sat Jul 4 09:54:43 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09213A6921 for ; Sat, 4 Jul 2009 09:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LISnFrfAGxMG for ; Sat, 4 Jul 2009 09:54:42 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4F35C3A694D for ; Sat, 4 Jul 2009 09:54:22 -0700 (PDT) Received: from [192.168.0.10] (82.159.27.104.dyn.user.ono.com [82.159.27.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 0C275655C10; Sat, 4 Jul 2009 18:54:37 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-vvONti6O1M+V9V/WMYQf" Organization: Universidad Carlos III de Madrid Date: Sat, 04 Jul 2009 18:53:53 +0200 Message-Id: <1246726433.4911.11.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16744.000 Cc: MELIA TELEMACO Subject: [netext] New draft on multihoming extensions for PMIPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 16:54:44 -0000 --=-vvONti6O1M+V9V/WMYQf Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, We have posted the following ID: http://www.ietf.org/internet-drafts/draft-bernardos-mif-pmip-00.txt, and the abstract reads as follows: "Netlmm WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi- homing support to multi-mode mobile devices. Recently Netext WG is being chartered to work on optimizations for PMIPv6. While multi- homing item has been proposed to be part of the approved charter, discussions showed there are still many controversial issues to be addressed (i.e. the no-host modification theorem). This document, leveraging parallel activities in the MIF WG, explores solutions for the multi-homing use case aiming at helping Netext community where possible." As stated in the above text the goal is to leverage MIF activities and to investigate how an MIF node can be supported by PMIPv6 based network. We are aware MIF is not chartered to work on mobility, nevertheless we believe it is a promising approach especially if we consider the widely debated "no host modifications" issue. It is a proactive and concrete approach aiming at answering some of the many questions posted to this mailing list, too often left without any conclusion (at least this is our opinion). We hope it helps the Netext community to make good progress. Thanks, Telemaco, Pierrick and Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Advances in Vehicular Communications Networks http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-vvONti6O1M+V9V/WMYQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpPiSEACgkQNdy6TdFwT2fFeQCeIpI3Ybjm/xFPzqeXBo67snpd g+sAn3m+pOKDBwRteXbRygzgkR0PBqDA =rJgy -----END PGP SIGNATURE----- --=-vvONti6O1M+V9V/WMYQf-- From Telemaco.Melia@alcatel-lucent.com Sun Jul 5 06:24:15 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12BC03A6B72 for ; Sun, 5 Jul 2009 06:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeHvW4lz-aFh for ; Sun, 5 Jul 2009 06:24:14 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 74F4D3A6B65 for ; Sun, 5 Jul 2009 06:24:12 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n65DOZdu028798; Sun, 5 Jul 2009 15:24:35 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 15:24:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FD73.F015FB8F" Date: Sun, 5 Jul 2009 15:24:34 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C032F94DB@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-melia-netext-3gpp-mn-ar-if-00 Thread-Index: Acn9c++zoQvoFpm3RJChAJUGOJ1sdA== From: "MELIA TELEMACO" To: X-OriginalArrivalTime: 05 Jul 2009 13:24:35.0061 (UTC) FILETIME=[F040BA50:01C9FD73] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: JuanCarlos.Zuniga@InterDigital.com Subject: [netext] New Version Notification for draft-melia-netext-3gpp-mn-ar-if-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 13:24:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FD73.F015FB8F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, A new I-D draft-melia-netext-3gpp-mn-ar-if-00.txt has been submitted. This ID aims at helping the discussions in the Netext community around the MN-to-AR interface topic. Several folks expressed the importance of such interface being documented in IETF and we thought that starting from deployment decisions made by other SDOs (in this case 3GPP) would have been beneficial. In our view (along considerations expressed in I-D.gundavelli-netext-extensions-motivation) this document should be compounded by additional informational IDs covering for instance (but not limited to) WiMAX or 802.21. It is our believe that Nextext should publish such informational documents. Comments are welcome. Telemaco/Carlos/Juan Carlos ------_=_NextPart_001_01C9FD73.F015FB8F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable New Version Notification for draft-melia-netext-3gpp-mn-ar-if-00 =

Hi = all,

A new I-D = draft-melia-netext-3gpp-mn-ar-if-00.txt has been submitted.

This ID aims at = helping the discussions in the Netext community around the MN-to-AR = interface topic. Several = folks expressed the importance of such interface being documented in = IETF and we thought that starting from deployment decisions made by other SDOs (in this case = 3GPP) would have been beneficial. In our view (along considerations expressed in = I-D.gundavelli-netext-extensions-motivation) this document should be = compounded by additional informational IDs covering for instance (but not limited to) WiMAX or = 802.21. It is our believe = that Nextext should publish such informational = documents.

Comments are welcome.

Telemaco/Carlos/Juan Carlos

------_=_NextPart_001_01C9FD73.F015FB8F-- From Telemaco.Melia@alcatel-lucent.com Sun Jul 5 06:57:01 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9A53A6BB8 for ; Sun, 5 Jul 2009 06:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8vlCc5quRXE for ; Sun, 5 Jul 2009 06:57:00 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id BDD863A682F for ; Sun, 5 Jul 2009 06:56:58 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n65DvL1o010464 for ; Sun, 5 Jul 2009 15:57:21 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 15:57:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FD78.842B9AE7" Date: Sun, 5 Jul 2009 15:57:20 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C032F94DC@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-melia-netext-muho-solution-00 Thread-Index: Acn9eIPHbPn4oLCVSCOZnwdFqAq1XA== From: "MELIA TELEMACO" To: X-OriginalArrivalTime: 05 Jul 2009 13:57:21.0349 (UTC) FILETIME=[84407750:01C9FD78] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: MONGAZON-CAZAVET BRUNO Subject: [netext] New Version Notification for draft-melia-netext-muho-solution-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 13:57:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FD78.842B9AE7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, We just posted an ID on multi-homing extensions for PMIPv6 (http://www.ietf.org/internet-drafts/draft-melia-netext-muho-solution-00 .txt). The ID makes the assumption of using the same IP address on two or more interface and explores the possibility to transfer routing filters as part of the PBU/PBA signalling [It differentiates from http://www.ietf.org/internet-drafts/draft-bernardos-mif-pmip-00.txt where we consider MIF alike nodes]. Although this ID goes to the solution space while Netext still debates at problem space level, we believe that some solution insights could help in the decision process and to progress Netext work. Looking forward to a constructive discussion. Telemaco/Bruno =20 ------_=_NextPart_001_01C9FD78.842B9AE7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable New Version Notification for draft-melia-netext-muho-solution-00 =

Hi all,

We just posted an ID = on multi-homing extensions for PMIPv6 (http://www.ietf.org/internet-drafts/draft-melia-netext-muho-solution= -00.txt).

The = ID = makes the assumption of = using the same IP = address = on two or more interface = and explores the possibility to = transfer routing filters = as part of the PBU/PBA signalling [It = differentiates from http://www.ietf.org/internet-drafts/draft-bernardos-mif-pmip-00.txt<= /FONT> where we consider MIF alike = nodes]. = Although this ID goes to = the = solution space = while Netext still debates at = problem space level, = we believe = that some solution insights = could help in the decision = process and to progress = Netext work.

Looking forward to a = constructive discussion.

Telemaco/Bruno 

------_=_NextPart_001_01C9FD78.842B9AE7-- From cjbc@it.uc3m.es Tue Jul 7 05:19:47 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB563A6A35 for ; Tue, 7 Jul 2009 05:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLGBF8U+wP5T for ; Tue, 7 Jul 2009 05:19:45 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B4ED23A6A1E for ; Tue, 7 Jul 2009 05:19:45 -0700 (PDT) Received: from [192.168.253.55] (unknown [192.124.253.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 064727323E3; Tue, 7 Jul 2009 14:18:56 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj.Patil@nokia.com In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-x/obFr9Zf4/H8Fj2sHG9" Organization: Universidad Carlos III de Madrid Date: Tue, 07 Jul 2009 14:19:09 +0200 Message-Id: <1246969149.15922.50.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16748.007 Cc: netext@ietf.org, MELIA TELEMACO Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:19:47 -0000 --=-x/obFr9Zf4/H8Fj2sHG9 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear Raj, We'd like to have a slot to present our draft [1] analysing how an MIF node can be supported by a PMIPv6 based network. This draft is relevant to NETEXT and NETEXT2 efforts. Thanks, Telemaco, Pierrick and Carlos [1] http://www.ietf.org/internet-drafts/draft-bernardos-mif-pmip-00.txt On Tue, 2009-06-23 at 00:44 +0200, Basavaraj.Patil@nokia.com wrote: > Hello, >=20 > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. >=20 > Note that we will consider I-Ds that pertain to the scope of the charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot.=20 >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IEEE Network Special Issue on Advances in Vehicular Communications Networks http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm=20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-x/obFr9Zf4/H8Fj2sHG9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpTPT0ACgkQNdy6TdFwT2e6wQCaA98FYuRvyV2TDEKuCJvIxK9o 0VcAn0Xa00exR2Vitbeq4sRhVGMbW+xZ =TKkJ -----END PGP SIGNATURE----- --=-x/obFr9Zf4/H8Fj2sHG9-- From Telemaco.Melia@alcatel-lucent.com Tue Jul 7 05:40:18 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C1528C12F for ; Tue, 7 Jul 2009 05:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slxNDKOPFLWY for ; Tue, 7 Jul 2009 05:40:17 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 23CC13A6D0B for ; Tue, 7 Jul 2009 05:40:16 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n67CNsHn004088; Tue, 7 Jul 2009 14:24:04 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 14:24:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 7 Jul 2009 14:24:03 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C032F9E93@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Solicitations for agenda items thread-index: AcnzivxC61+jN2dLQUmPraRThFoneQLcjTDQ References: From: "MELIA TELEMACO" To: , X-OriginalArrivalTime: 07 Jul 2009 12:24:04.0170 (UTC) FILETIME=[D0E63AA0:01C9FEFD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:40:18 -0000 Hello, As a follow up of the discussions about Netext/Netext2 we would request = a slot to present ID draft-melia-netext-3gpp-mn-ar-if-00.txt. Cheers, telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Basavaraj.Patil@nokia.com Envoy=E9=A0: mardi 23 juin 2009 00:44 =C0=A0: netext@ietf.org Objet=A0: [netext] Solicitations for agenda items Hello, The NetExt WG will meet at IETF75. Please submit any requests for a slot on the agenda. Note that we will consider I-Ds that pertain to the scope of the = charter. Additionally please ensure that you have an accompanying I-D when you request a slot.=20 -Chairs _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From huimin.cmcc@gmail.com Wed Jul 8 05:13:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF123A6AA6 for ; Wed, 8 Jul 2009 05:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3yOgAw-xDAp for ; Wed, 8 Jul 2009 05:13:06 -0700 (PDT) Received: from mail-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by core3.amsl.com (Postfix) with ESMTP id BDA1B3A6894 for ; Wed, 8 Jul 2009 05:13:06 -0700 (PDT) Received: by pxi5 with SMTP id 5so1322249pxi.29 for ; Wed, 08 Jul 2009 05:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=v3yQO84cgYzhhovS/t3as9/soWNum3kBTnXA/ClrsUI=; b=qLaM5QB1siDeQnPNgcLp3Fg8p9exX7/FGYTYSkp8cbM+NyAawuVep+vRdw0mGe/UpR wogOtZGyoZR8qyJSksb8CL3qc5sblFBgFGmgwDmikCtobODdflkklfkv/9ZgVxCA7NhO 2sKVJszAHWQmStmpFLvP5M7YhU5yTPO3BopL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=xEAtCG+T6Ml02e8EFny6PH+vKUy49O3ejJQ7M4yAKokBUVqPEEqGThPCCUDtqxwivv vdBTmWEs0VW1tRi8KXjZ/TNSEP5U8ZxZqQ5vY3Etc3/B2LFjhdllMbc0KFukD1ylcnhx UkarjwpKvHBhUuukaEpg7FeV2pPmX0P84AkuI= MIME-Version: 1.0 Received: by 10.114.192.17 with SMTP id p17mr11166148waf.196.1247054805931; Wed, 08 Jul 2009 05:06:45 -0700 (PDT) In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C032F9E93@FRVELSMBS14.ad2.ad.alcatel.com> References: <853DD750D9C3724FBF2DF7164FCF641C032F9E93@FRVELSMBS14.ad2.ad.alcatel.com> Date: Wed, 8 Jul 2009 20:06:45 +0800 Message-ID: <5dca10d30907080506w1412cb4cw9b783b65a1b4fe91@mail.gmail.com> From: Min Hui To: Basavaraj.Patil@nokia.com, netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 12:13:07 -0000 Hi Raj, I'd like to request 10 min to present the I-D "Service Flow Identifier in Proxy Mobile IPv6" http://www.ietf.org/internet-drafts/draft-hui-netext-service-flow-identifie= r-00.txt Thanks. - Hui Min 2009/7/7 MELIA TELEMACO : > Hello, > > As a follow up of the discussions about Netext/Netext2 we would request a= slot to present ID draft-melia-netext-3gpp-mn-ar-if-00.txt. > > Cheers, > telemaco > > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t de Basavaraj.Patil@nokia.com > Envoy=E9=A0: mardi 23 juin 2009 00:44 > =C0=A0: netext@ietf.org > Objet=A0: [netext] Solicitations for agenda items > > > Hello, > > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. > > Note that we will consider I-Ds that pertain to the scope of the charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From julien.laganier.ietf@googlemail.com Wed Jul 8 18:05:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363923A6AE2 for ; Wed, 8 Jul 2009 18:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hnx3WuOWTO3c for ; Wed, 8 Jul 2009 18:05:02 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id F287F3A6FC4 for ; Wed, 8 Jul 2009 18:05:01 -0700 (PDT) Received: by fxm18 with SMTP id 18so6070312fxm.37 for ; Wed, 08 Jul 2009 18:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RJPCvLyHklb4JxQigguSV8sEzuIIN6+vdhdvsZkF45A=; b=ibqs+Kj3DvQDr8cQgjXgsdYlQO9siNdEea9AI7xqNKhJfR1beVWSHx2OEcrSRaLrpg NmM7v+GyEbTyvRZGNGt99fWwzrSGvt2VdBOg8iML1xJIRU+OKJmHwJ+FUcXdyY+yzNK0 inwHEOgHzmHl9rSfYk4bbe23WROT+qiRvXVco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FMHXAPCuACbCsguJdBMjpYN7APUOBPIehHwrDfvFXOPgqM8lQyRd5KMtNhgQRVOGKd 8RTVTfLB0joGXNJ84EKjEOcuNiVdQF1lUavAYlhPUZOJfLGCPHF17dsF0rO+Bb2kEALj U34T7msfA3jfD5eVwYJF947fgZTK9Q33VxP1c= MIME-Version: 1.0 Received: by 10.204.65.18 with SMTP id g18mr168502bki.5.1247101526490; Wed, 08 Jul 2009 18:05:26 -0700 (PDT) In-Reply-To: <4A4B7CED.5090909@it.uc3m.es> References: <4A4B7CED.5090909@it.uc3m.es> Date: Wed, 8 Jul 2009 18:05:26 -0700 Message-ID: <7ad6d6db0907081805n79080485j110db915eecc022@mail.gmail.com> From: Julien Laganier To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] Questions for defining the NETEXT2 problem space X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 01:05:03 -0000 Hi Marcelo, On Wed, Jul 1, 2009 at 8:12 AM, marcelo bagnulo braun wrote: > Hi, > > After the discussion so far, i have identified the following question for > which i think it would be important to provide answer to define the > requirements of the problems we are trying to tackle. > > As stated earlier, the goal of this questions is to try to define the "what > are we trying to achieve?" question. > > Once we have a set of answers, we will need to do the "Why?" part. > > So, this is work in progress, but i woudl appreciate input in terms of > modificatiosn to the questions, answers to the questions and more questions. > > Questions: > > 1)- What L2 technologies are supported? All the L2 technologies? A subset of > L2 technologies? I do not think we should restrict the type of L2 that can be used any further that what PMIPv6 already did (i.e., point-to-point link b/w MN and MAG.) > 2)- What changes are acceptable in the MN? > Options include: > No host changes. > Only configuration required in the host. > New code is acceptable, but no protocol changes (the motivation for this > could include to interop with other devices already using the existent > protocol) > Protocol extensions are acceptable. No change to the L3 software is acceptable in the MN. Changes at L2 are acceptable (and none of our business.) > 3)- What capabilities need to be controlled by the network? > When the MN performs a handover from one interface to another one? > How the node distributes the load among interfaces? in which direction? > Which flow is routed through which interface? in which direction? I think as long as the L3 software is untouched I doesn't matter. IOW that can be controlled in any possible way at L2. --julien From Basavaraj.Patil@nokia.com Mon Jul 13 16:37:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F53A3A6E07 for ; Mon, 13 Jul 2009 16:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQwrwGnJvliE for ; Mon, 13 Jul 2009 16:37:25 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 51B2C3A6DA8 for ; Mon, 13 Jul 2009 16:37:25 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6DNbods018499 for ; Mon, 13 Jul 2009 18:37:51 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 02:37:53 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 02:37:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 02:37:43 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 14 Jul 2009 01:36:49 +0200 From: To: Date: Tue, 14 Jul 2009 01:37:51 +0200 Thread-Topic: Agenda Requests received Thread-Index: AcoEEu+lSBU+nacy4UOlnJtzap3K/w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2009 23:37:43.0584 (UTC) FILETIME=[EB39DA00:01CA0412] X-Nokia-AV: Clean Subject: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 23:37:26 -0000 The following are the agenda requests received so far. Agenda requests received: 1. Runtime LMA Assignment Support for Proxy Mobile IPv6" I-D: draft-korhonen-netext-redirect-02 Jouni Korhonen - 10 Mins 2. Localized Routing PMIPv6 Localized Routing Problem Statement I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt PS and Scope discussion 10 Mins Solutions 15 Mins Marco Liebsch et al. Proxy MIP extension for local routing optimization I-D: draft-wu-netext-local-ro-02.txt Behcet Sarikaya 5 Mins 3. Tunnel Negotiation for Proxy Mobile IPv6 I-D: draft-xia-netext-tunnel-negotiation-01.txt Frank Xia 10 Mins 4. Mobile Node Group Identifier Option: I-D: draft-gundavelli-netext-mn-groupid-option-01 Sri Gundavelli 10 Mins 5. Retransmit Message Identifier Option: I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt Sri Gundavelli 10 Mins 6. Mobility session suspend I-D: draft-muhanna-netext-mobility-session-suspend-00.txt Ahmad Muhanna 10 Mins 7. Trace Control Support for Proxy Mobile IPv6 I-D: draft-wang-netext-trace-control-00.txt Yungui Wang 10 Mins 8. Multihoming extensions for Proxy Mobile IPv6 I-D: draft-bernardos-mif-pmip-00.txt Telemaco, Pierrick and Carlos 10 Mins 9. 3GPP MN-AR interface I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt Telemaco 5 Mins -Chairs From Mohana.Jeyatharan@sg.panasonic.com Mon Jul 13 17:05:56 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC533A6834 for ; Mon, 13 Jul 2009 17:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMMSkynttBff for ; Mon, 13 Jul 2009 17:05:55 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 364C23A659C for ; Mon, 13 Jul 2009 17:05:51 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id n6E06LbG002431; Tue, 14 Jul 2009 09:06:21 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id n6E06KH13977; Tue, 14 Jul 2009 09:06:20 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 08:03:33 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD037399FF@pslexc01.psl.local> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Agenda Requests received Thread-Index: AcoEEu+lSBU+nacy4UOlnJtzap3K/wAA8B/Q From: "Mohana Jeyatharan" To: , Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 00:05:56 -0000 Dear Chairs, Can we have 5 to 10 minute slot to present the=20 draft-jeyatharan-netext-PMIP-Partial-Handoff ID. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Basavaraj.Patil@nokia.com > Sent: Tuesday, July 14, 2009 7:38 AM > To: netext@ietf.org > Subject: [netext] Agenda Requests received >=20 >=20 > The following are the agenda requests received so far. >=20 >=20 > Agenda requests received: >=20 > 1. Runtime LMA Assignment Support for Proxy Mobile IPv6" > I-D: draft-korhonen-netext-redirect-02 > Jouni Korhonen - 10 Mins >=20 > 2. Localized Routing > PMIPv6 Localized Routing Problem Statement > I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt > PS and Scope discussion 10 Mins > Solutions 15 Mins > Marco Liebsch et al. >=20 > Proxy MIP extension for local routing optimization > I-D: draft-wu-netext-local-ro-02.txt > Behcet Sarikaya 5 Mins >=20 > 3. Tunnel Negotiation for Proxy Mobile IPv6 > I-D: draft-xia-netext-tunnel-negotiation-01.txt > Frank Xia 10 Mins >=20 > 4. Mobile Node Group Identifier Option: > I-D: draft-gundavelli-netext-mn-groupid-option-01 > Sri Gundavelli 10 Mins >=20 > 5. Retransmit Message Identifier Option: > I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt > Sri Gundavelli 10 Mins >=20 > 6. Mobility session suspend > I-D: draft-muhanna-netext-mobility-session-suspend-00.txt > Ahmad Muhanna 10 Mins >=20 > 7. Trace Control Support for Proxy Mobile IPv6 > I-D: draft-wang-netext-trace-control-00.txt > Yungui Wang 10 Mins >=20 > 8. Multihoming extensions for Proxy Mobile IPv6 > I-D: draft-bernardos-mif-pmip-00.txt > Telemaco, Pierrick and Carlos 10 Mins >=20 > 9. 3GPP MN-AR interface > I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt > Telemaco 5 Mins >=20 >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Jul 13 17:12:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DF728C3B4 for ; Mon, 13 Jul 2009 17:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hGxAu5nRcen for ; Mon, 13 Jul 2009 17:12:11 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7B9BE28C2A8 for ; Mon, 13 Jul 2009 17:12:00 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6E0CJH6015961 for ; Tue, 14 Jul 2009 03:12:20 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 03:12:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 03:12:12 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 14 Jul 2009 02:12:12 +0200 From: To: Date: Tue, 14 Jul 2009 02:12:23 +0200 Thread-Topic: Agenda for WG meeting at IETF75 Thread-Index: AcoEF8KnIeYMf20ZI02tYYtVYDWuGA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2009 00:12:12.0665 (UTC) FILETIME=[BC7E8E90:01CA0417] X-Nokia-AV: Clean Subject: [netext] Agenda for WG meeting at IETF75 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 00:12:12 -0000 http://www.ietf.org/proceedings/09jul/agenda/netext.txt or: Draft agenda as of July 13th, 09 NetExt WG Meeting THURSDAY, July 30, 2009 1300-1500 Afternoon Session I ----------------------------------------------- 1. Agenda bashing, Blueseheets, Note takers, Jabber scribes 5 Mins 2. WG Status update 10 Mins Chairs 3. Localized Routing discussion 30~40 Mins Problem statement, Scope and Solutions discussion I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt Marco Liebsch Other I-Ds may be added to the discussion 4. Runtime LMA Assignment Support for Proxy Mobile IPv6" I-D: draft-korhonen-netext-redirect-02 Jouni Korhonen - 10 Mins 5. Bulk refresh I-D discussion 10 Mins Discussion of new proposals: 6. Tunnel Negotiation for Proxy Mobile IPv6 I-D: draft-xia-netext-tunnel-negotiation-01.txt Frank Xia 5 Mins 7. Mobile Node Group Identifier Option: I-D: draft-gundavelli-netext-mn-groupid-option-01 Sri Gundavelli 10 Mins 8. Retransmit Message Identifier Option: I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt Sri Gundavelli 10 Mins 9. Mobility session suspend I-D: draft-muhanna-netext-mobility-session-suspend-00.txt Ahmad Muhanna 10 Mins 10. Trace Control Support for Proxy Mobile IPv6 I-D: draft-wang-netext-trace-control-00.txt Yungui Wang 10 Mins 11. Multihoming extensions for Proxy Mobile IPv6 I-D: draft-bernardos-mif-pmip-00.txt Telemaco, Pierrick and Carlos 10 Mins 12. 3GPP MN-AR interface I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt Telemaco 5 Mins Note: This is a tentative agenda only and subject to change. WG items will take precedence and chairs may decide to drop other items if they determine they are not relevant to the scope of the charter From Basavaraj.Patil@nokia.com Mon Jul 13 17:17:10 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F8928C35E for ; Mon, 13 Jul 2009 17:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy6Jv7lSCJtE for ; Mon, 13 Jul 2009 17:17:09 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0698D28C681 for ; Mon, 13 Jul 2009 17:14:56 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6E0FIp1027720; Tue, 14 Jul 2009 03:15:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 03:15:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 03:15:19 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 14 Jul 2009 02:15:19 +0200 From: To: , Date: Tue, 14 Jul 2009 02:15:30 +0200 Thread-Topic: [netext] Agenda Requests received Thread-Index: AcoEEu+lSBU+nacy4UOlnJtzap3K/wAA8B/QAABgf7Q= Message-ID: In-Reply-To: <5F09D220B62F79418461A978CA0921BD037399FF@pslexc01.psl.local> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2009 00:15:19.0575 (UTC) FILETIME=[2BE6C270:01CA0418] X-Nokia-AV: Clean Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 00:17:11 -0000 I think it would be better to wait for the outcome of the NetExt2 BoF befor= e considering this I-D on the agenda of the WG meeting. -Raj On 7/13/09 7:03 PM, "ext Mohana Jeyatharan" wrote: > Dear Chairs, >=20 > Can we have 5 to 10 minute slot to present the >=20 > draft-jeyatharan-netext-PMIP-Partial-Handoff ID. >=20 > Thanks. >=20 > BR, > Mohana >=20 >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf >> Of Basavaraj.Patil@nokia.com >> Sent: Tuesday, July 14, 2009 7:38 AM >> To: netext@ietf.org >> Subject: [netext] Agenda Requests received >>=20 >>=20 >> The following are the agenda requests received so far. >>=20 >>=20 >> Agenda requests received: >>=20 >> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6" >> I-D: draft-korhonen-netext-redirect-02 >> Jouni Korhonen - 10 Mins >>=20 >> 2. Localized Routing >> PMIPv6 Localized Routing Problem Statement >> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >> PS and Scope discussion 10 Mins >> Solutions 15 Mins >> Marco Liebsch et al. >>=20 >> Proxy MIP extension for local routing optimization >> I-D: draft-wu-netext-local-ro-02.txt >> Behcet Sarikaya 5 Mins >>=20 >> 3. Tunnel Negotiation for Proxy Mobile IPv6 >> I-D: draft-xia-netext-tunnel-negotiation-01.txt >> Frank Xia 10 Mins >>=20 >> 4. Mobile Node Group Identifier Option: >> I-D: draft-gundavelli-netext-mn-groupid-option-01 >> Sri Gundavelli 10 Mins >>=20 >> 5. Retransmit Message Identifier Option: >> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >> Sri Gundavelli 10 Mins >>=20 >> 6. Mobility session suspend >> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >> Ahmad Muhanna 10 Mins >>=20 >> 7. Trace Control Support for Proxy Mobile IPv6 >> I-D: draft-wang-netext-trace-control-00.txt >> Yungui Wang 10 Mins >>=20 >> 8. Multihoming extensions for Proxy Mobile IPv6 >> I-D: draft-bernardos-mif-pmip-00.txt >> Telemaco, Pierrick and Carlos 10 Mins >>=20 >> 9. 3GPP MN-AR interface >> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >> Telemaco 5 Mins >>=20 >>=20 >> -Chairs >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From Mohana.Jeyatharan@sg.panasonic.com Mon Jul 13 17:22:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EF43A694D for ; Mon, 13 Jul 2009 17:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF-vX1tSx4ca for ; Mon, 13 Jul 2009 17:22:07 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id B69413A659C for ; Mon, 13 Jul 2009 17:22:06 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id n6E0MEFV017143; Tue, 14 Jul 2009 09:22:14 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id n6E0MFt05045; Tue, 14 Jul 2009 09:22:15 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 08:19:26 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03739A03@pslexc01.psl.local> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Agenda Requests received Thread-Index: AcoEEu+lSBU+nacy4UOlnJtzap3K/wAA8B/QAABgf7QAADMkkA== From: "Mohana Jeyatharan" To: , Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 00:22:07 -0000 Hi Raj, Well, if you think we should wait for the outcome of NetExt2 BoF, it is fine. But if you have some spare time in the NetExt meeting please consider this presentation. Thanks. BR, Mohana > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Tuesday, July 14, 2009 8:16 AM > To: Mohana Jeyatharan; netext@ietf.org > Subject: Re: [netext] Agenda Requests received >=20 >=20 > I think it would be better to wait for the outcome of the NetExt2 BoF > before > considering this I-D on the agenda of the WG meeting. >=20 > -Raj >=20 >=20 > On 7/13/09 7:03 PM, "ext Mohana Jeyatharan" > wrote: >=20 > > Dear Chairs, > > > > Can we have 5 to 10 minute slot to present the > > > > draft-jeyatharan-netext-PMIP-Partial-Handoff ID. > > > > Thanks. > > > > BR, > > Mohana > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > Behalf > >> Of Basavaraj.Patil@nokia.com > >> Sent: Tuesday, July 14, 2009 7:38 AM > >> To: netext@ietf.org > >> Subject: [netext] Agenda Requests received > >> > >> > >> The following are the agenda requests received so far. > >> > >> > >> Agenda requests received: > >> > >> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6" > >> I-D: draft-korhonen-netext-redirect-02 > >> Jouni Korhonen - 10 Mins > >> > >> 2. Localized Routing > >> PMIPv6 Localized Routing Problem Statement > >> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt > >> PS and Scope discussion 10 Mins > >> Solutions 15 Mins > >> Marco Liebsch et al. > >> > >> Proxy MIP extension for local routing optimization > >> I-D: draft-wu-netext-local-ro-02.txt > >> Behcet Sarikaya 5 Mins > >> > >> 3. Tunnel Negotiation for Proxy Mobile IPv6 > >> I-D: draft-xia-netext-tunnel-negotiation-01.txt > >> Frank Xia 10 Mins > >> > >> 4. Mobile Node Group Identifier Option: > >> I-D: draft-gundavelli-netext-mn-groupid-option-01 > >> Sri Gundavelli 10 Mins > >> > >> 5. Retransmit Message Identifier Option: > >> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt > >> Sri Gundavelli 10 Mins > >> > >> 6. Mobility session suspend > >> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt > >> Ahmad Muhanna 10 Mins > >> > >> 7. Trace Control Support for Proxy Mobile IPv6 > >> I-D: draft-wang-netext-trace-control-00.txt > >> Yungui Wang 10 Mins > >> > >> 8. Multihoming extensions for Proxy Mobile IPv6 > >> I-D: draft-bernardos-mif-pmip-00.txt > >> Telemaco, Pierrick and Carlos 10 Mins > >> > >> 9. 3GPP MN-AR interface > >> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt > >> Telemaco 5 Mins > >> > >> > >> -Chairs > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext From marcelo@it.uc3m.es Tue Jul 14 01:30:04 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF2A3A6AE8 for ; Tue, 14 Jul 2009 01:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxAYCbe-df6c for ; Tue, 14 Jul 2009 01:30:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 3C2CE3A67B7 for ; Tue, 14 Jul 2009 01:30:03 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 359296BA0CB; Tue, 14 Jul 2009 09:31:00 +0200 (CEST) Message-ID: <4A5C3433.50704@it.uc3m.es> Date: Tue, 14 Jul 2009 09:30:59 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16762.004 Subject: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 08:30:04 -0000 Hi, We are proposing the following agenda for the meeting. Comments are welcome. ------------------------------------------------------- NETEXT2 BOF Meeting agenda TUESDAY, July 28, 2009 1300-1500 Afternoon Session I ------------------------------------------------------- 1. Blue sheets, scribe, agenda bashing Chairs - 5 min 2. Problem scope Jonne & Marcelo - 20 min 3. Overview of types of solutions Julien & Suresh - 30 min 4. Requirements Raj & Rajeev - 50 min 5. Next steps ADs - 15 min ------------------------------------------------------- From Basavaraj.Patil@nokia.com Tue Jul 14 10:35:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0C03A6F00 for ; Tue, 14 Jul 2009 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcZwfyBT5GR0 for ; Tue, 14 Jul 2009 10:35:43 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 861183A6EE4 for ; Tue, 14 Jul 2009 10:35:43 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6EHYYqT010023 for ; Tue, 14 Jul 2009 20:34:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 20:34:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 20:34:45 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 14 Jul 2009 19:34:42 +0200 From: To: , Date: Tue, 14 Jul 2009 19:34:55 +0200 Thread-Topic: [netext] Agenda Requests received Thread-Index: AcoEEu+lSBU+nacy4UOlnJtzap3K/wAlnbrg Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2009 17:34:45.0364 (UTC) FILETIME=[60CEF340:01CA04A9] X-Nokia-AV: Clean Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:35:44 -0000 As of 7/14 the chairs have received requests for agenda slots at IETF75. We would like to encourage WG members to review the I-Ds and provide feedback on the list prior to the meeting itself. -Chairs Agenda requests received: 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 I-D: draft-korhonen-netext-redirect-02 Jouni Korhonen - 10 Mins 2. Localized Routing PMIPv6 Localized Routing Problem Statement I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt PS and Scope discussion 10 Mins Solutions 15 Mins Marco Liebsch et al. Proxy MIP extension for local routing optimization I-D: draft-wu-netext-local-ro-02.txt Behcet Sarikaya 5 Mins 3. Tunnel Negotiation for Proxy Mobile IPv6 I-D: draft-xia-netext-tunnel-negotiation-01.txt Frank Xia 10 Mins 4. Mobile Node Group Identifier Option: I-D: draft-gundavelli-netext-mn-groupid-option-01 Sri Gundavelli 10 Mins 5. Retransmit Message Identifier Option: I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt Sri Gundavelli 10 Mins 6. Mobility session suspend I-D: draft-muhanna-netext-mobility-session-suspend-00.txt Ahmad Muhanna 10 Mins 7. Trace Control Support for Proxy Mobile IPv6 I-D: draft-wang-netext-trace-control-00.txt Yungui Wang 10 Mins 8. Multihoming extensions for Proxy Mobile IPv6 I-D: draft-bernardos-mif-pmip-00.txt Telemaco, Pierrick and Carlos 10 Mins 9. 3GPP MN-AR interface I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt Telemaco 5 Mins 10. Service Flow Identifier in Proxy Mobile IPv6 I-D: draft-hui-netext-service-flow-identifier-00.txt Min Hui 10 Mins 11. Connection Identifier for Proxy Mobile IPv6 I-D: draft-wolfner-netext-pmip6-connid-00 Jouni Korhonen 5 Mins 12. Bulk Re-registration for Proxy Mobile IPv6 I-D: draft-premec-netlmm-bulk-re-registration-02 Jouni Korhonen 5 Mins 13. Partial Handoff Support in PMIPv6 I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 Mohana Jeyatharan From Basavaraj.Patil@nokia.com Tue Jul 14 11:25:14 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B34D3A67FA for ; Tue, 14 Jul 2009 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2y6KHVN-CLQ for ; Tue, 14 Jul 2009 11:25:13 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 84B163A6778 for ; Tue, 14 Jul 2009 11:25:12 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6EHTXvR008095; Tue, 14 Jul 2009 20:29:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 20:29:34 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 20:29:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 20:29:29 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 14 Jul 2009 19:29:09 +0200 From: To: , Date: Tue, 14 Jul 2009 19:29:25 +0200 Thread-Topic: [netext] Draft NETEXT2 BOF agenda for comments Thread-Index: AcoEXWVfLmBjxg1iRP6tTfl32e5b/QASzx+P Message-ID: In-Reply-To: <4A5C3433.50704@it.uc3m.es> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2009 17:29:29.0107 (UTC) FILETIME=[A44DF630:01CA04A8] X-Nokia-AV: Clean Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 18:25:14 -0000 Hi Marcelo, I am wondering if we should analyse requirements prior to discussing solution approaches. If we were to follow a structured approach we would have the sequence of problem statement, requirements and then solutions. -Raj On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: > Hi, >=20 > We are proposing the following agenda for the meeting. > Comments are welcome. >=20 > ------------------------------------------------------- > NETEXT2 BOF > Meeting agenda >=20 > TUESDAY, July 28, 2009 > 1300-1500 Afternoon Session I > ------------------------------------------------------- > 1. Blue sheets, scribe, agenda bashing > Chairs - 5 min >=20 > 2. Problem scope > Jonne & Marcelo - 20 min >=20 > 3. Overview of types of solutions > Julien & Suresh - 30 min >=20 > 4. Requirements > Raj & Rajeev - 50 min >=20 > 5. Next steps > ADs - 15 min > ------------------------------------------------------- >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From marcelo@it.uc3m.es Tue Jul 14 12:05:54 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38F23A66B4 for ; Tue, 14 Jul 2009 12:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv3PomXmxbCM for ; Tue, 14 Jul 2009 12:05:54 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A285B3A635F for ; Tue, 14 Jul 2009 12:05:53 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (8.pool85-53-137.dynamic.orange.es [85.53.137.8]) by smtp03.uc3m.es (Postfix) with ESMTP id 3B3D37F008B; Tue, 14 Jul 2009 21:05:58 +0200 (CEST) Message-ID: <4A5CD715.4060503@it.uc3m.es> Date: Tue, 14 Jul 2009 21:05:57 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16764.001 Cc: netext@ietf.org Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 19:05:54 -0000 that would make sense, wouldn't it? more seriously, i think the agenda is much less ambitious than that. The idea of the presentation of the types of solutions is to provide an overview of the type of solutions that can be envisioned, so people understand what is on the table. The goal of that presentation is by no mean select one of them or to figure out if one is better (in any sense) to another one. Just to have a full picture of what can be done. Initially, i had assigned 10 min for this. We have expanded it, in case soem disucssion raises (in particular, i can expect some people adding additional details to the different approaches presented). Then we would move to the requirements. This will include the disucssion of what are the requirements and why these are reasonable. I am doubtful we will be able to move beyond that point. Of course the next step would be to contrast the solutions with the requirements and pick one approach. I don't think we will get that far... am i too pessimistic? This is the rationale behind the proposed agenda... sounds better? Regards, marcelo Basavaraj.Patil@nokia.com escribió: > Hi Marcelo, > > I am wondering if we should analyse requirements prior to discussing > solution approaches. If we were to follow a structured approach we would > have the sequence of problem statement, requirements and then solutions. > > -Raj > > > On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: > > >> Hi, >> >> We are proposing the following agenda for the meeting. >> Comments are welcome. >> >> ------------------------------------------------------- >> NETEXT2 BOF >> Meeting agenda >> >> TUESDAY, July 28, 2009 >> 1300-1500 Afternoon Session I >> ------------------------------------------------------- >> 1. Blue sheets, scribe, agenda bashing >> Chairs - 5 min >> >> 2. Problem scope >> Jonne & Marcelo - 20 min >> >> 3. Overview of types of solutions >> Julien & Suresh - 30 min >> >> 4. Requirements >> Raj & Rajeev - 50 min >> >> 5. Next steps >> ADs - 15 min >> ------------------------------------------------------- >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > > From behcetsarikaya@yahoo.com Tue Jul 14 20:18:25 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87C93A6836 for ; Tue, 14 Jul 2009 20:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t2fOpYyKKd9 for ; Tue, 14 Jul 2009 20:18:24 -0700 (PDT) Received: from n68.bullet.mail.sp1.yahoo.com (n68.bullet.mail.sp1.yahoo.com [98.136.44.44]) by core3.amsl.com (Postfix) with SMTP id BA8503A681F for ; Tue, 14 Jul 2009 20:18:24 -0700 (PDT) Received: from [216.252.122.219] by n68.bullet.mail.sp1.yahoo.com with NNFMP; 15 Jul 2009 03:14:21 -0000 Received: from [67.195.9.82] by t4.bullet.sp1.yahoo.com with NNFMP; 15 Jul 2009 03:14:21 -0000 Received: from [67.195.9.103] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2009 03:14:21 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 15 Jul 2009 03:14:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 199648.53469.bm@omp107.mail.gq1.yahoo.com Received: (qmail 31188 invoked by uid 60001); 15 Jul 2009 03:14:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247627660; bh=gsUzg1Oe6sXzhqSdXIIJbgGMKOgjrUG1v/TNPNlzTn8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=4eF6uzqTHiP2MxVfG6IEgPpffYGYCJPl5yIahpjepaj6HCekzQ73D4RIj7GRRK6u6JeMM76qfwv9tLL+BpyNBiV3tlibN/9GuxFSCEFWkZIV1jAMfRJ2JnM/2FMA1JaO/RA0av6+qZsQUOV9Sf7Xovnk3UEyYRLHCI4Oe2QmjLQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=sehzZS/cqBtMAS0YgJZx9lkH0tR6El3zyKGNOa/lMNaKm+4JHfDwut6Bz0v/b+3Ni2Q2jWfZ16J8pmNFT21Mgchv+besugZ37U89msNmdpOjyG9laUqYQZ3d8jYXDenNkALrLBdJrwh2zRlqIYIxq13q+/zBC8dfEVCMkUMfruI=; Message-ID: <735669.30926.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: gYtALy4VM1n5ORygQfZtVjuI1R3aML9Dh3_iM6Y7p5iaJc8SOdWmWJoQjvdWK2q1GkSVgSZTgiDcY7y5JjDbA7WZvLtWmyydukPGWwk5j7.zjDyXMagxMjAvo5QZwBWTmzy4jACQusY7H49z_L9NHY7mBJYGAXM2qcsett3P3xt.Timr24ElTOh1M4KzTtETpI.kL5eF0QE9PDsAg6dTDF9H0lV4ohn_Bb9ALqWsqGsuf6G2VyJXs5rCZkCEuc9gIp8p8nLcknTGNqmFxognxQ1epG1YfvknS5dihbD.kWzm0QjQsRqTq9KSpb70ekEslO71eHdv_YZHEA2tZ916CmDBHQw- Received: from [71.170.139.250] by web111413.mail.gq1.yahoo.com via HTTP; Tue, 14 Jul 2009 20:14:20 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 Date: Tue, 14 Jul 2009 20:14:20 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj Patil , netext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netext] Fw: New Version Notification for draft-sarikaya-netext-prefix-delegation-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 03:18:25 -0000 Hi Raj, Can you please reserve a slot for this draft in the upcoming Netext meeting? I think that this is one of the most exciting PMIPv6 extensions ever proposed :);. Regards, Behcet ----- Forwarded Message ---- > From: IETF I-D Submission Tool > To: sarikaya@ieee.org > Cc: xiayangsong@huawei.com > Sent: Wednesday, July 1, 2009 10:51:30 AM > Subject: New Version Notification for draft-sarikaya-netext-prefix-delegation-00 > > > A new version of I-D, draft-sarikaya-netext-prefix-delegation-00.txt has been > successfuly submitted by Behcet Sarikaya and posted to the IETF repository. > > Filename: draft-sarikaya-netext-prefix-delegation > Revision: 00 > Title: Local Mobility Anchor Based Prefix Management for PMIPv6 Using > DHCPv6PD > Creation_date: 2009-07-01 > WG ID: Independent Submission > Number_of_pages: 14 > > Abstract: > In Proxy Mobile IPv6, prefixes can only be assigned to one interface > of a mobile node by the local mobility anchor (LMA) and different > mobile nodes can not share these home network prefixes. Managing > per-MN's interface home network prefixes is likely to increase the > processing load at the LMA. Based on the idea that Dynamic Host > Configuration Protocol for IPv6 (DHCPv6) servers can manage prefixes, > we propose a new technique in which LMA offloads delegation and > release tasks of the prefixes to the DHCPv6 server. LMA requests > prefixes for an incoming mobile node to the DHCPv6 server. Based on > these prefixes, the mobile node can create home addresses for its > interface. When the mobile node leaves the network, the prefixes are > returned to the DHCPv6 server. Authentication, Authorization and > Accounting (AAA) servers can also play a role in prefix > authorization. > > > > > The IETF Secretariat. From Xiangsong.Cui@huawei.com Tue Jul 14 21:53:34 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E3928C0D9 for ; Tue, 14 Jul 2009 21:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.438 X-Spam-Level: X-Spam-Status: No, score=0.438 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpnBOVCPahMb for ; Tue, 14 Jul 2009 21:53:32 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D67923A696E for ; Tue, 14 Jul 2009 21:53:31 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMT00LBK47FU3@szxga04-in.huawei.com> for netext@ietf.org; Wed, 15 Jul 2009 12:52:27 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMT006BN47EJN@szxga04-in.huawei.com> for netext@ietf.org; Wed, 15 Jul 2009 12:52:27 +0800 (CST) Date: Wed, 15 Jul 2009 12:52:26 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, netext@ietf.org, Sri Gundavelli Message-id: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 04:53:34 -0000 Good idea. I have a question about item 5, "Retransmit Message Identifier Option". I ever posted a mail on 27 June, but it was ignored. So I copy the mail here: The draft says: ---------------------------------------- 1. Introduction The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the ability for the sender of a signaling message to mark retransmitted messages with a proper tag, so the receiver can differentiate between the original message to a retransmitted message. This semantic is important for the receiver to determine when to ignore processing a retransmitted packet, or for various other reasons. --------------------------------------------- Is the motive is just to distinguish the original and retransmitted PBU? I ask this question just because I think it is unnecessary. The reason is: 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" field in BU message, and section 11.8 [RFC3775] says: -------------------------------------------------------- Retransmitted Binding Updates MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. ---------------------------------------------------- So the BU messages are different for their sequence number. 2, section 6.6 [RFC5213] says: ----------------------------------------- 6.6. Acquiring Mobile Node's Identifier All the network entities in a Proxy Mobile IPv6 domain MUST be able to identify a mobile node, using its MN-Identifier. This identifier MUST be stable and unique across the Proxy Mobile IPv6 domain. The mobility entities in the Proxy Mobile IPv6 domain MUST be able to use this identifier in the signaling messages and unambiguously identify a given mobile node. The following are some of the considerations related to this MN-Identifier. ------------------------------------------- In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. PBU message format also shows there is a sequence # field in PBU message and "Mobile Node Identifier option" is valid. 3, section 6.9.4 [RFC5213] has specified the rule for Retransmissions and Rate Limiting. For these reasons, I believe the LMA can recognize the duplicate PBUs. The LMA has been capable of making binding for the first PBU and ignore other PBUs for the same mobile node. Do I make any mistakes? and why we need a new extension? Because I will not go to the meeting, I want to discuss the topic in list before the meeting. Thanks and regards Xiangsong ================================================= ----- Original Message ----- From: To: ; Sent: Wednesday, July 15, 2009 1:34 AM Subject: Re: [netext] Agenda Requests received > > As of 7/14 the chairs have received requests for agenda slots at IETF75. > We would like to encourage WG members to review the I-Ds and provide > feedback on the list prior to the meeting itself. > > -Chairs > > > Agenda requests received: > > 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 > I-D: draft-korhonen-netext-redirect-02 > Jouni Korhonen - 10 Mins > > 2. Localized Routing > PMIPv6 Localized Routing Problem Statement > I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt > PS and Scope discussion 10 Mins > Solutions 15 Mins > Marco Liebsch et al. > > Proxy MIP extension for local routing optimization > I-D: draft-wu-netext-local-ro-02.txt > Behcet Sarikaya 5 Mins > > 3. Tunnel Negotiation for Proxy Mobile IPv6 > I-D: draft-xia-netext-tunnel-negotiation-01.txt > Frank Xia 10 Mins > > 4. Mobile Node Group Identifier Option: > I-D: draft-gundavelli-netext-mn-groupid-option-01 > Sri Gundavelli 10 Mins > > 5. Retransmit Message Identifier Option: > I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt > Sri Gundavelli 10 Mins > > 6. Mobility session suspend > I-D: draft-muhanna-netext-mobility-session-suspend-00.txt > Ahmad Muhanna 10 Mins > > 7. Trace Control Support for Proxy Mobile IPv6 > I-D: draft-wang-netext-trace-control-00.txt > Yungui Wang 10 Mins > > 8. Multihoming extensions for Proxy Mobile IPv6 > I-D: draft-bernardos-mif-pmip-00.txt > Telemaco, Pierrick and Carlos 10 Mins > > 9. 3GPP MN-AR interface > I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt > Telemaco 5 Mins > > 10. Service Flow Identifier in Proxy Mobile IPv6 > I-D: draft-hui-netext-service-flow-identifier-00.txt > Min Hui 10 Mins > > 11. Connection Identifier for Proxy Mobile IPv6 > I-D: draft-wolfner-netext-pmip6-connid-00 > Jouni Korhonen 5 Mins > > 12. Bulk Re-registration for Proxy Mobile IPv6 > I-D: draft-premec-netlmm-bulk-re-registration-02 > Jouni Korhonen 5 Mins > > 13. Partial Handoff Support in PMIPv6 > I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 > Mohana Jeyatharan > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Tue Jul 14 22:25:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4E63A69C0 for ; Tue, 14 Jul 2009 22:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+TqD+L0jX-R for ; Tue, 14 Jul 2009 22:25:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3558C3A696E for ; Tue, 14 Jul 2009 22:25:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFkEXUqrR7PD/2dsb2JhbAC4IYgjkGsFgjOBVoFC X-IronPort-AV: E=Sophos;i="4.42,402,1243814400"; d="scan'208";a="214148815" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2009 05:22:45 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6F5Mjt6008427; Tue, 14 Jul 2009 22:22:45 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6F5MjJ9006126; Wed, 15 Jul 2009 05:22:45 GMT Date: Tue, 14 Jul 2009 22:22:45 -0700 (PDT) From: Sri Gundavelli To: Xiangsong Cui In-Reply-To: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> Message-ID: References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6805; t=1247635365; x=1248499365; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20Discussion=20about=20=22Retransmit=20Me ssage=20Identifier=20Option=22//Re=3A=0A=20[netext]=20Agenda =20Requests=20received |Sender:=20; bh=QvZFz+KCh37e4LaEs1GLxT6XrUb/01E7+PKCji3WOCo=; b=lNwCyckBj9X1Mg+Fv0kRHPOjGKgGkFS13AHPVA9bHnmAFV/cJ4+D4hdU3v eioNT/4TCFN4VH8TBV2H3odga/7xb8yfZ9+sP/PJMON21VQwUVrCk5czz6gt pZ2Hc7DjZw; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 05:25:45 -0000 Hi Xiangsong, Please see inline. On Wed, 15 Jul 2009, Xiangsong Cui wrote: > Good idea. > > I have a question about item 5, "Retransmit Message Identifier Option". > I ever posted a mail on 27 June, but it was ignored. So I copy the mail here: > Sorry, we missed that. > The draft says: > ---------------------------------------- > 1. Introduction > > The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the > ability for the sender of a signaling message to mark retransmitted > messages with a proper tag, so the receiver can differentiate between > the original message to a retransmitted message. This semantic is > important for the receiver to determine when to ignore processing a > retransmitted packet, or for various other reasons. > --------------------------------------------- > > Is the motive is just to distinguish the original and retransmitted PBU? > Yes > > I ask this question just because I think it is unnecessary. The reason is: > > 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" field in BU > message, and > section 11.8 [RFC3775] says: > -------------------------------------------------------- > Retransmitted Binding Updates MUST use a Sequence Number value > greater than that used for the previous transmission of this Binding > Update. > ---------------------------------------------------- > So the BU messages are different for their sequence number. > We need the ability to distinguish between a original message to a retransmitted request. Lets take the case, LMA receives a PBU and is in the midst of processing that request and a second message arrives. There is nothing in the message which allows the receiver to identify this message as a retransmit of the current message that is being processed. If you go with the seq num, or the time stamp, each message has a different values of those options. What we need is a tag that allows the LMA to see this marking and associate with the earlier request. In some interop, there was a case where the MAG was retransmitting a request and ignoring the response for an earlier sent request. This could be avoided, if there are such semantics for tagging retransmitted messages. > 2, section 6.6 [RFC5213] says: > ----------------------------------------- > 6.6. Acquiring Mobile Node's Identifier > > All the network entities in a Proxy Mobile IPv6 domain MUST be able > to identify a mobile node, using its MN-Identifier. This identifier > MUST be stable and unique across the Proxy Mobile IPv6 domain. The > mobility entities in the Proxy Mobile IPv6 domain MUST be able to use > this identifier in the signaling messages and unambiguously identify > a given mobile node. The following are some of the considerations > related to this MN-Identifier. > ------------------------------------------- > In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. > PBU message format also shows there is a sequence # field in PBU > message and "Mobile Node Identifier option" is valid. > > 3, section 6.9.4 [RFC5213] has specified the rule for Retransmissions and > Rate Limiting. > > > For these reasons, I believe the LMA can recognize the duplicate PBUs. > The LMA has been capable of making binding for the first PBU and ignore > other PBUs for the same mobile node. > The rules in 6.9.4 is for addressing the MAG contention issue. Its not about detecting duplicate messages. Its more of an out-of order delivery issue. > > Do I make any mistakes? and why we need a new extension? > These are good questions. The goal is to have a tag on retransmitted packets. This simple option provides such semantic. Relevant or not, such semantics are even present in protocols such as GTP. Regards Sri > > Because I will not go to the meeting, I want to discuss the topic in list > before the meeting. > > Thanks and regards > > Xiangsong > > ================================================= > ----- Original Message ----- From: > To: ; > Sent: Wednesday, July 15, 2009 1:34 AM > Subject: Re: [netext] Agenda Requests received > > >> >> As of 7/14 the chairs have received requests for agenda slots at IETF75. >> We would like to encourage WG members to review the I-Ds and provide >> feedback on the list prior to the meeting itself. >> >> -Chairs >> >> >> Agenda requests received: >> >> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >> I-D: draft-korhonen-netext-redirect-02 >> Jouni Korhonen - 10 Mins >> >> 2. Localized Routing >> PMIPv6 Localized Routing Problem Statement >> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >> PS and Scope discussion 10 Mins >> Solutions 15 Mins >> Marco Liebsch et al. >> >> Proxy MIP extension for local routing optimization >> I-D: draft-wu-netext-local-ro-02.txt >> Behcet Sarikaya 5 Mins >> >> 3. Tunnel Negotiation for Proxy Mobile IPv6 >> I-D: draft-xia-netext-tunnel-negotiation-01.txt >> Frank Xia 10 Mins >> >> 4. Mobile Node Group Identifier Option: >> I-D: draft-gundavelli-netext-mn-groupid-option-01 >> Sri Gundavelli 10 Mins >> >> 5. Retransmit Message Identifier Option: >> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >> Sri Gundavelli 10 Mins >> >> 6. Mobility session suspend >> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >> Ahmad Muhanna 10 Mins >> >> 7. Trace Control Support for Proxy Mobile IPv6 >> I-D: draft-wang-netext-trace-control-00.txt >> Yungui Wang 10 Mins >> >> 8. Multihoming extensions for Proxy Mobile IPv6 >> I-D: draft-bernardos-mif-pmip-00.txt >> Telemaco, Pierrick and Carlos 10 Mins >> >> 9. 3GPP MN-AR interface >> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >> Telemaco 5 Mins >> >> 10. Service Flow Identifier in Proxy Mobile IPv6 >> I-D: draft-hui-netext-service-flow-identifier-00.txt >> Min Hui 10 Mins >> >> 11. Connection Identifier for Proxy Mobile IPv6 >> I-D: draft-wolfner-netext-pmip6-connid-00 >> Jouni Korhonen 5 Mins >> >> 12. Bulk Re-registration for Proxy Mobile IPv6 >> I-D: draft-premec-netlmm-bulk-re-registration-02 >> Jouni Korhonen 5 Mins >> >> 13. Partial Handoff Support in PMIPv6 >> I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >> Mohana Jeyatharan >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > From Xiangsong.Cui@huawei.com Wed Jul 15 00:03:43 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594D33A68F2 for ; Wed, 15 Jul 2009 00:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.36 X-Spam-Level: X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vYyICDBklu5 for ; Wed, 15 Jul 2009 00:03:42 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 744FE3A6828 for ; Wed, 15 Jul 2009 00:03:41 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMT003FOA584L@szxga04-in.huawei.com> for netext@ietf.org; Wed, 15 Jul 2009 15:00:44 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMT00J88A574R@szxga04-in.huawei.com> for netext@ietf.org; Wed, 15 Jul 2009 15:00:44 +0800 (CST) Date: Wed, 15 Jul 2009 15:00:43 +0800 From: Xiangsong Cui To: Sri Gundavelli Message-id: <004801ca0519$f8a3b500$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 07:03:43 -0000 Hi Sri, Thank you for your response. I think I got your meaning but I really don't know why we need it. Let's look into the precise details. An assumed case: 1, At time T [in ms], MAG send a PBU to LMA, with SN, timestamp T and lifetime 30 second; 2, At time (T+1000), MAG resend a PBU to LMA, // retransmission in 1 second with (SN+1), timestamp (T+1000) and lifetime 30 second 3, At time (T+1020), first PBU arrives at LMA; 4, At time (T+1050), second PBU arrives at LMA. In my mind, as RFC5213 and RFC3775, LMA must process the second PBU, even if it has already processed the first one, because the timestamp is greater than the first one. As your draft, LMA may or should ignore the second PBU, because MAG insert a retransmission tag in the PBU. But by now, some difference, a very little difference happens. In RFC solution, lifetime in LMA expires at (T+1050+30000) , while in your draft solution, lifetime expires at (T+1020+30000). Is that right? I think there is no bug in original solution, but your modification bring a different behavior and different result. In my thought, all registration with lifetime in IETF protocols, are with the same character. But now your draft solution bring a modification, making NETEXT protocol different from MIP, PMIP, SIP or other protocols. I'm not sure, is it a bug need us to do a such fix? Regards/Xiangsong ======================================================= ----- Original Message ----- From: "Sri Gundavelli" To: "Xiangsong Cui" Cc: ; Sent: Wednesday, July 15, 2009 1:22 PM Subject: Re: Discussion about "Retransmit Message Identifier Option"//Re: [netext] Agenda Requests received > Hi Xiangsong, > > Please see inline. > > On Wed, 15 Jul 2009, Xiangsong Cui wrote: > >> Good idea. >> >> I have a question about item 5, "Retransmit Message Identifier Option". >> I ever posted a mail on 27 June, but it was ignored. So I copy the mail >> here: >> > > Sorry, we missed that. > > >> The draft says: >> ---------------------------------------- >> 1. Introduction >> >> The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the >> ability for the sender of a signaling message to mark retransmitted >> messages with a proper tag, so the receiver can differentiate between >> the original message to a retransmitted message. This semantic is >> important for the receiver to determine when to ignore processing a >> retransmitted packet, or for various other reasons. >> --------------------------------------------- >> >> Is the motive is just to distinguish the original and retransmitted PBU? >> > > Yes > >> >> I ask this question just because I think it is unnecessary. The reason >> is: >> >> 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" field in BU >> message, and >> section 11.8 [RFC3775] says: >> -------------------------------------------------------- >> Retransmitted Binding Updates MUST use a Sequence Number value >> greater than that used for the previous transmission of this Binding >> Update. >> ---------------------------------------------------- >> So the BU messages are different for their sequence number. >> > > We need the ability to distinguish between a original message to a > retransmitted request. Lets take the case, LMA receives a PBU and > is in the midst of processing that request and a second message > arrives. There is nothing in the message which allows the receiver > to identify this message as a retransmit of the current message > that is being processed. If you go with the seq num, or the time > stamp, each message has a different values of those options. What > we need is a tag that allows the LMA to see this marking and associate > with the earlier request. In some interop, there was a case where > the MAG was retransmitting a request and ignoring the response for > an earlier sent request. This could be avoided, if there are such > semantics for tagging retransmitted messages. > > > > >> 2, section 6.6 [RFC5213] says: >> ----------------------------------------- >> 6.6. Acquiring Mobile Node's Identifier >> >> All the network entities in a Proxy Mobile IPv6 domain MUST be able >> to identify a mobile node, using its MN-Identifier. This identifier >> MUST be stable and unique across the Proxy Mobile IPv6 domain. The >> mobility entities in the Proxy Mobile IPv6 domain MUST be able to use >> this identifier in the signaling messages and unambiguously identify >> a given mobile node. The following are some of the considerations >> related to this MN-Identifier. >> ------------------------------------------- >> In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. >> PBU message format also shows there is a sequence # field in PBU >> message and "Mobile Node Identifier option" is valid. >> >> 3, section 6.9.4 [RFC5213] has specified the rule for Retransmissions and >> Rate Limiting. >> >> >> For these reasons, I believe the LMA can recognize the duplicate PBUs. >> The LMA has been capable of making binding for the first PBU and ignore >> other PBUs for the same mobile node. >> > > The rules in 6.9.4 is for addressing the MAG contention issue. Its not > about detecting duplicate messages. Its more of an out-of order delivery > issue. > > >> >> Do I make any mistakes? and why we need a new extension? >> > > These are good questions. The goal is to have a tag on retransmitted > packets. This simple option provides such semantic. Relevant or not, > such semantics are even present in protocols such as GTP. > > Regards > Sri > > > > >> >> Because I will not go to the meeting, I want to discuss the topic in list >> before the meeting. >> >> Thanks and regards >> >> Xiangsong >> >> ================================================= >> ----- Original Message ----- From: >> To: ; >> Sent: Wednesday, July 15, 2009 1:34 AM >> Subject: Re: [netext] Agenda Requests received >> >> >>> >>> As of 7/14 the chairs have received requests for agenda slots at >>> IETF75. >>> We would like to encourage WG members to review the I-Ds and provide >>> feedback on the list prior to the meeting itself. >>> >>> -Chairs >>> >>> Agenda requests received: >>> >>> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >>> I-D: draft-korhonen-netext-redirect-02 >>> Jouni Korhonen - 10 Mins >>> >>> 2. Localized Routing >>> PMIPv6 Localized Routing Problem Statement >>> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >>> PS and Scope discussion 10 Mins >>> Solutions 15 Mins >>> Marco Liebsch et al. >>> >>> Proxy MIP extension for local routing optimization >>> I-D: draft-wu-netext-local-ro-02.txt >>> Behcet Sarikaya 5 Mins >>> >>> 3. Tunnel Negotiation for Proxy Mobile IPv6 >>> I-D: draft-xia-netext-tunnel-negotiation-01.txt >>> Frank Xia 10 Mins >>> >>> 4. Mobile Node Group Identifier Option: >>> I-D: draft-gundavelli-netext-mn-groupid-option-01 >>> Sri Gundavelli 10 Mins >>> >>> 5. Retransmit Message Identifier Option: >>> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >>> Sri Gundavelli 10 Mins >>> >>> 6. Mobility session suspend >>> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >>> Ahmad Muhanna 10 Mins >>> >>> 7. Trace Control Support for Proxy Mobile IPv6 >>> I-D: draft-wang-netext-trace-control-00.txt >>> Yungui Wang 10 Mins >>> >>> 8. Multihoming extensions for Proxy Mobile IPv6 >>> I-D: draft-bernardos-mif-pmip-00.txt >>> Telemaco, Pierrick and Carlos 10 Mins >>> >>> 9. 3GPP MN-AR interface >>> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >>> Telemaco 5 Mins >>> >>> 10. Service Flow Identifier in Proxy Mobile IPv6 >>> I-D: draft-hui-netext-service-flow-identifier-00.txt >>> Min Hui 10 Mins >>> >>> 11. Connection Identifier for Proxy Mobile IPv6 >>> I-D: draft-wolfner-netext-pmip6-connid-00 >>> Jouni Korhonen 5 Mins >>> >>> 12. Bulk Re-registration for Proxy Mobile IPv6 >>> I-D: draft-premec-netlmm-bulk-re-registration-02 >>> Jouni Korhonen 5 Mins >>> >>> 13. Partial Handoff Support in PMIPv6 >>> I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >>> Mohana Jeyatharan >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> From Basavaraj.Patil@nokia.com Wed Jul 15 09:32:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F15128C118 for ; Wed, 15 Jul 2009 09:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVTzI3NKJTP9 for ; Wed, 15 Jul 2009 09:32:25 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 99A0E28C116 for ; Wed, 15 Jul 2009 09:32:25 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6FGUkPe027344 for ; Wed, 15 Jul 2009 11:31:22 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 19:31:12 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 19:31:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 19:31:03 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 15 Jul 2009 18:30:58 +0200 From: To: Date: Wed, 15 Jul 2009 18:31:15 +0200 Thread-Topic: Review of I-D: draft-hui-netext-service-flow-identifier Thread-Index: AcoFaawRwzWdKHLp7U+ujl1HHnzuyQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jul 2009 16:31:03.0223 (UTC) FILETIME=[A50C4470:01CA0569] X-Nokia-AV: Clean Subject: [netext] Review of I-D: draft-hui-netext-service-flow-identifier X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:32:26 -0000 After reviewing the I-D draft-hui-netext-service-flow-identifier-00, I had a few questions for the authors: 1. In figure 1: - What does it mean to start a new service flow? =20 As per PMIP6 when the MN attaches to a MAG as part of initial attachment the BCE at the LMA is created and the bi-directional tunnel between the MAG/LMA established. In the figure you show a PBU with SFID option being sent after the MN starts a new SF. Can you elaborate on this statement: "2. When a new service flow of the mobile node is started, the data packet of this service will be routed to the mobile access gateway, which will trigger the service flow proxy binding update" 2. I am also not clear about what sort of control is expected to be enabled by including an SFID in the PBU. The following sentence in the introduction:=20 "Hence, the mobile access gateway can bind mobile node's each service flow to its home network prefix, respectively. Therefore, the mobile node's multiple service flows can be separately controlled based on the service flow identifier." I am not sure what the above means. 3. Assuming you do have granularity greater than a single tunnel between the MAG/LMA for the MNs traffic, do you really need an SFID? Is'nt the v6 address itself or in the case of GRE keys being used, the GRE key sufficient in terms of an identifier? 4. In sec 4 :=20 "Assume a mobile node establishes two service flows, called SF1 and SF2." Does the MN have a single HNP? Is the MN attached to the MAG via different interfaces? If not, what causes the MAG to establish separate tunnels with the LMA for each service flow? Assuming that there is a BCE for the MN already, do you modify the existing BCE or extend it? Obviously you are making certain assumptions about service flows and rules at the MAG that would trigger the establishment of a unique tunnel to handle some traffic to/from the MN. These assumptions are missing. Can you provide references to such assumptions? Or state the assumptions in this document itself. Lastly, the discussion of flow-binding is part of the NetExt2 BoF at IETF75. Hence we will not consider this I-D as part of the NetExt WG meeting at IETF75.=20 -Raj From Basavaraj.Patil@nokia.com Wed Jul 15 14:35:18 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053333A6F0C for ; Wed, 15 Jul 2009 14:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO0DAOx7VA3N for ; Wed, 15 Jul 2009 14:35:17 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E5FDC3A6C8C for ; Wed, 15 Jul 2009 14:35:16 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6FLXPeR021348 for ; Thu, 16 Jul 2009 00:33:34 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 00:33:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 00:33:29 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 15 Jul 2009 23:33:28 +0200 From: To: Date: Wed, 15 Jul 2009 23:33:42 +0200 Thread-Topic: Comments on I-D: draft-wolfner-netext-pmip6-connid-00 Thread-Index: AcoFk+yFEaqa4vLzb06ccvCQVvoWzA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jul 2009 21:33:29.0479 (UTC) FILETIME=[E50F3170:01CA0593] X-Nokia-AV: Clean Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 21:35:18 -0000 Hello, A few questions/comments related to the proposal to add a connection identifier to the PMIP6 signaling and BCE: 1. Each of the PDN bearers will have a unique prefix assigned to it by the LMA, right? Even though the MN-ID remains the same the LMA will have to create multiple BCEs for the MN. The scenario is equivalent to the MN attaching via different interfaces thru the same MAG/LMA pair.=20 =20 2. The I-D says that the mechanism by which the MAG figures out that a new bi-directional tunnel is needed to be established (and a new prefix obtained) is out of scope. In certain networks you are obtaining this information from L2 and is used by the MAG. Current RFC5213 lacks the ability by which an MN (which is already attached via an interface) can request dynamically a new prefix to be assigned to it for the same interface. The connection ID would be useful if we were to also specify how the MN can request an additional prefix via an interface that is already attached and has been assigned a prefix from a MAG/LMA pair. It might be useful to explain how L2s can provide such indications in an appendix. 3. In the case of HO the target MAG will not be aware of the CID unless there a context transfer mechanism between the MAGs. Please note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes context transfer capability between MAGs. 4. If each PDN bearer is assigned a unique prefix, can you not use the HNP assigned as the CID? I do agree with the need to support the ability by which multiple mobility sessions to the same LMA (via the same MAG) from a single interface is needed. This is applicable in EPC and other networks which use PMIP6.=20 -Raj From Basavaraj.Patil@nokia.com Wed Jul 15 15:03:21 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14143A6F5A for ; Wed, 15 Jul 2009 15:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YFEPN2ACKzy for ; Wed, 15 Jul 2009 15:03:21 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A5ED83A6F1A for ; Wed, 15 Jul 2009 15:03:20 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6FM2n8L011711 for ; Thu, 16 Jul 2009 01:02:50 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 01:02:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 01:02:53 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 16 Jul 2009 00:02:52 +0200 From: To: Date: Thu, 16 Jul 2009 00:03:06 +0200 Thread-Topic: Review of I-D: draft-wang-netext-trace-control-00 Thread-Index: AcoFmAfybpSoZyuQD0qJI1elB6tK3g== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jul 2009 22:02:53.0473 (UTC) FILETIME=[007B5110:01CA0598] X-Nokia-AV: Clean Subject: [netext] Review of I-D: draft-wang-netext-trace-control-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 22:03:21 -0000 The I-D is basically proposing a means by which tracing of a PMIP6 mobility session can be enabled. IMO, tracing of a mobility session by an external network manager or simila= r entity can be done without any changes to the PMIP6 protocol itself. Each PMIP6 session is uniquely identified by the MN-ID/HNP assigned to it. I realize that regulatory requirements may require the ability to trace a mobility session on a demand basis. But this can be accomplished without necessarily changing the protocol itself. Tracing the sessions of a specifi= c MN (identified by an MN-ID) can be controlled at the LMA. I see no reason for specifying such an extension. -Raj From xiayangsong@huawei.com Wed Jul 15 15:51:53 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143F028C15D for ; Wed, 15 Jul 2009 15:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGMBW52kmHU3 for ; Wed, 15 Jul 2009 15:51:52 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 333473A6F60 for ; Wed, 15 Jul 2009 15:51:52 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU0063II5UZ3@szxga04-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 06:51:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU00GK9I5U7P@szxga04-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 06:51:30 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMU00CPHI5SN8@szxml04-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 06:51:30 +0800 (CST) Date: Wed, 15 Jul 2009 17:51:28 -0500 From: Frank Xia To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <004401ca059e$cb348970$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: [netext] suggestion on improvement of individual technical involvement X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 22:51:53 -0000 Hi Raj It is very nice of you to comment so many drafts. It seems to me that there is lacking momentum of technical review in many IETF WGs. Just as MEXT tries to have ground rules for adopting WG documents, NETEXT could have new rules to inspire people for technical review. A technical review group could be established in the WG, and any one can be a member as long as he/she commit themselves to review documents in the WG as many as possible. BR Frank ----- Original Message ----- From: To: Sent: Wednesday, July 15, 2009 5:03 PM Subject: [netext] Review of I-D: draft-wang-netext-trace-control-00 > > The I-D is basically proposing a means by which tracing of a PMIP6 > mobility > session can be enabled. > > IMO, tracing of a mobility session by an external network manager or > similar > entity can be done without any changes to the PMIP6 protocol itself. Each > PMIP6 session is uniquely identified by the MN-ID/HNP assigned to it. > > I realize that regulatory requirements may require the ability to trace a > mobility session on a demand basis. But this can be accomplished without > necessarily changing the protocol itself. Tracing the sessions of a > specific > MN (identified by an MN-ID) can be controlled at the LMA. > > I see no reason for specifying such an extension. > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Wed Jul 15 17:45:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7CA3A69FA for ; Wed, 15 Jul 2009 17:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3ksQqLy15Jg for ; Wed, 15 Jul 2009 17:45:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 578013A6927 for ; Wed, 15 Jul 2009 17:45:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEALAUXkqrR7O6/2dsb2JhbACLCK1siCORCQWCNIFXgUU X-IronPort-AV: E=Sophos;i="4.42,407,1243814400"; d="scan'208";a="177246073" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2009 00:45:50 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6G0joA2032392; Wed, 15 Jul 2009 17:45:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6G0jjOq029641; Thu, 16 Jul 2009 00:45:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 17:45:49 -0700 Received: from sgundavewxp ([10.32.246.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 17:45:48 -0700 From: "Sri Gundavelli" To: "'Xiangsong Cui'" References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> Date: Wed, 15 Jul 2009 17:45:47 -0700 Message-ID: <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoFGfsv6/YQl+aWSV+BOTkc2TaXAAAk6/Qg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <004801ca0519$f8a3b500$40106f0a@china.huawei.com> X-OriginalArrivalTime: 16 Jul 2009 00:45:48.0700 (UTC) FILETIME=[C2F895C0:01CA05AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10689; t=1247705150; x=1248569150; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Discussion=20about=20=22Retransmit=20Me ssage=20Identifier=20Option=22//Re=3A=20[netext]=20Agenda=20 Requests=20received |Sender:=20; bh=s9qpnHkXGIQnJwk+27Q6mRnUHQy04P6be8VQW/D+1ws=; b=YJnm8KaAyWFCOybHAg+VYgJKwapwd4lqvXGI6+8Z5ag629dDHPsUjhXu9Q yjkhrcMZl2vQC3kaDQYnCqvU8FAs2UBNG0ZYVsJtQebzSlqhUfsT/tGvL1+V gVYFzRLfgf; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 00:45:19 -0000 Hi Xiangsong, > -----Original Message----- > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] > Sent: Wednesday, July 15, 2009 12:01 AM > To: Sri Gundavelli > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org > Subject: Re: Discussion about "Retransmit Message Identifier > Option"//Re: [netext] Agenda Requests received > > Hi Sri, > > Thank you for your response. > I think I got your meaning but I really don't know why we need it. > Let's look into the precise details. > > An assumed case: > 1, At time T [in ms], MAG send a PBU to LMA, > with SN, timestamp T and lifetime 30 second; > 2, At time (T+1000), MAG resend a PBU to LMA, // > retransmission in 1 second > with (SN+1), timestamp (T+1000) and lifetime 30 second > 3, At time (T+1020), first PBU arrives at LMA; > 4, At time (T+1050), second PBU arrives at LMA. > > In my mind, as RFC5213 and RFC3775, LMA must process > the second PBU, even if it has already processed the first one, > because the timestamp is greater than the first one. > Exactly. In the event, when these two messages are sent for the exact purpose, if the HA can determine that its a duplicate, it can just complete processing the first request and send a reply and it can even tag the response as the response to the latest. The MAG and the LMA have clear semantics on the handling retransmit messages. Without the option, every message has to be treated differently and the latest has the precedence. With the retransmit option, the peers know what messages can be safely ignored based on the retransmit tags. > As your draft, LMA may or should ignore the second PBU, > because MAG insert a retransmission tag in the PBU. > > But by now, some difference, a very little difference happens. > In RFC solution, lifetime in LMA expires at (T+1050+30000) , > while in your draft solution, lifetime expires at (T+1020+30000). > > Is that right? Deep. Dont get it. > > I think there is no bug in original solution, but your modification > bring a different behavior and different result. > In my thought, all registration with lifetime in IETF protocols, are > with the same character. > But now your draft solution bring a modification, making NETEXT > protocol different from MIP, PMIP, SIP or other protocols. > > I'm not sure, is it a bug need us to do a such fix? > Its not about a bug. As I keep saying, the sender and receiver need to have the ability to differentiate between a new request to a retransmit request, either because the retransmit times and the processing times are not synchronised or when the messages are lost. The tag is a simple marker. Regards Sri > Regards/Xiangsong > > ======================================================= > ----- Original Message ----- > From: "Sri Gundavelli" > To: "Xiangsong Cui" > Cc: ; > Sent: Wednesday, July 15, 2009 1:22 PM > Subject: Re: Discussion about "Retransmit Message Identifier > Option"//Re: > [netext] Agenda Requests received > > > > Hi Xiangsong, > > > > Please see inline. > > > > On Wed, 15 Jul 2009, Xiangsong Cui wrote: > > > >> Good idea. > >> > >> I have a question about item 5, "Retransmit Message > Identifier Option". > >> I ever posted a mail on 27 June, but it was ignored. So I > copy the mail > >> here: > >> > > > > Sorry, we missed that. > > > > > >> The draft says: > >> ---------------------------------------- > >> 1. Introduction > >> > >> The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the > >> ability for the sender of a signaling message to mark > retransmitted > >> messages with a proper tag, so the receiver can > differentiate between > >> the original message to a retransmitted message. This > semantic is > >> important for the receiver to determine when to ignore > processing a > >> retransmitted packet, or for various other reasons. > >> --------------------------------------------- > >> > >> Is the motive is just to distinguish the original and > retransmitted PBU? > >> > > > > Yes > > > >> > >> I ask this question just because I think it is > unnecessary. The reason > >> is: > >> > >> 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" > field in BU > >> message, and > >> section 11.8 [RFC3775] says: > >> -------------------------------------------------------- > >> Retransmitted Binding Updates MUST use a Sequence Number value > >> greater than that used for the previous transmission of > this Binding > >> Update. > >> ---------------------------------------------------- > >> So the BU messages are different for their sequence number. > >> > > > > We need the ability to distinguish between a original message to a > > retransmitted request. Lets take the case, LMA receives a PBU and > > is in the midst of processing that request and a second message > > arrives. There is nothing in the message which allows the receiver > > to identify this message as a retransmit of the current message > > that is being processed. If you go with the seq num, or the time > > stamp, each message has a different values of those options. What > > we need is a tag that allows the LMA to see this marking > and associate > > with the earlier request. In some interop, there was a case where > > the MAG was retransmitting a request and ignoring the response for > > an earlier sent request. This could be avoided, if there are such > > semantics for tagging retransmitted messages. > > > > > > > > > >> 2, section 6.6 [RFC5213] says: > >> ----------------------------------------- > >> 6.6. Acquiring Mobile Node's Identifier > >> > >> All the network entities in a Proxy Mobile IPv6 domain > MUST be able > >> to identify a mobile node, using its MN-Identifier. > This identifier > >> MUST be stable and unique across the Proxy Mobile IPv6 > domain. The > >> mobility entities in the Proxy Mobile IPv6 domain MUST > be able to use > >> this identifier in the signaling messages and > unambiguously identify > >> a given mobile node. The following are some of the > considerations > >> related to this MN-Identifier. > >> ------------------------------------------- > >> In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. > >> PBU message format also shows there is a sequence # field in PBU > >> message and "Mobile Node Identifier option" is valid. > >> > >> 3, section 6.9.4 [RFC5213] has specified the rule for > Retransmissions and > >> Rate Limiting. > >> > >> > >> For these reasons, I believe the LMA can recognize the > duplicate PBUs. > >> The LMA has been capable of making binding for the first > PBU and ignore > >> other PBUs for the same mobile node. > >> > > > > The rules in 6.9.4 is for addressing the MAG contention > issue. Its not > > about detecting duplicate messages. Its more of an out-of > order delivery > > issue. > > > > > >> > >> Do I make any mistakes? and why we need a new extension? > >> > > > > These are good questions. The goal is to have a tag on retransmitted > > packets. This simple option provides such semantic. Relevant or not, > > such semantics are even present in protocols such as GTP. > > > > Regards > > Sri > > > > > > > > > >> > >> Because I will not go to the meeting, I want to discuss > the topic in list > >> before the meeting. > >> > >> Thanks and regards > >> > >> Xiangsong > >> > >> ================================================= > >> ----- Original Message ----- From: > >> To: ; > >> Sent: Wednesday, July 15, 2009 1:34 AM > >> Subject: Re: [netext] Agenda Requests received > >> > >> > >>> > >>> As of 7/14 the chairs have received requests for agenda slots at > >>> IETF75. > >>> We would like to encourage WG members to review the I-Ds > and provide > >>> feedback on the list prior to the meeting itself. > >>> > >>> -Chairs > >>> > >>> Agenda requests received: > >>> > >>> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 > >>> I-D: draft-korhonen-netext-redirect-02 > >>> Jouni Korhonen - 10 Mins > >>> > >>> 2. Localized Routing > >>> PMIPv6 Localized Routing Problem Statement > >>> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt > >>> PS and Scope discussion 10 Mins > >>> Solutions 15 Mins > >>> Marco Liebsch et al. > >>> > >>> Proxy MIP extension for local routing optimization > >>> I-D: draft-wu-netext-local-ro-02.txt > >>> Behcet Sarikaya 5 Mins > >>> > >>> 3. Tunnel Negotiation for Proxy Mobile IPv6 > >>> I-D: draft-xia-netext-tunnel-negotiation-01.txt > >>> Frank Xia 10 Mins > >>> > >>> 4. Mobile Node Group Identifier Option: > >>> I-D: draft-gundavelli-netext-mn-groupid-option-01 > >>> Sri Gundavelli 10 Mins > >>> > >>> 5. Retransmit Message Identifier Option: > >>> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt > >>> Sri Gundavelli 10 Mins > >>> > >>> 6. Mobility session suspend > >>> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt > >>> Ahmad Muhanna 10 Mins > >>> > >>> 7. Trace Control Support for Proxy Mobile IPv6 > >>> I-D: draft-wang-netext-trace-control-00.txt > >>> Yungui Wang 10 Mins > >>> > >>> 8. Multihoming extensions for Proxy Mobile IPv6 > >>> I-D: draft-bernardos-mif-pmip-00.txt > >>> Telemaco, Pierrick and Carlos 10 Mins > >>> > >>> 9. 3GPP MN-AR interface > >>> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt > >>> Telemaco 5 Mins > >>> > >>> 10. Service Flow Identifier in Proxy Mobile IPv6 > >>> I-D: draft-hui-netext-service-flow-identifier-00.txt > >>> Min Hui 10 Mins > >>> > >>> 11. Connection Identifier for Proxy Mobile IPv6 > >>> I-D: draft-wolfner-netext-pmip6-connid-00 > >>> Jouni Korhonen 5 Mins > >>> > >>> 12. Bulk Re-registration for Proxy Mobile IPv6 > >>> I-D: draft-premec-netlmm-bulk-re-registration-02 > >>> Jouni Korhonen 5 Mins > >>> > >>> 13. Partial Handoff Support in PMIPv6 > >>> I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 > >>> Mohana Jeyatharan > >>> > >>> _______________________________________________ > >>> netext mailing list > >>> netext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netext > >> > >> > From Xiangsong.Cui@huawei.com Wed Jul 15 18:18:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA92528C1B5 for ; Wed, 15 Jul 2009 18:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEdeJw5UwYFR for ; Wed, 15 Jul 2009 18:18:18 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0E6C03A6FA3 for ; Wed, 15 Jul 2009 18:18:18 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU00IUUOYZ1Y@szxga02-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 09:18:35 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMU00HNUOYYQM@szxga02-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 09:18:35 +0800 (CST) Date: Thu, 16 Jul 2009 09:18:43 +0800 From: Xiangsong Cui To: Sri Gundavelli Message-id: <001701ca05b3$5c79a000$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 01:18:19 -0000 Yes, I agree it is a very simple tag. I just don't understand what benefit we can get from the extension. That's all my question. Thanks Xiangsong ----- Original Message ----- From: "Sri Gundavelli" To: "'Xiangsong Cui'" Cc: ; Sent: Thursday, July 16, 2009 8:45 AM Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received > Hi Xiangsong, > >> -----Original Message----- >> From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] >> Sent: Wednesday, July 15, 2009 12:01 AM >> To: Sri Gundavelli >> Cc: Basavaraj.Patil@nokia.com; netext@ietf.org >> Subject: Re: Discussion about "Retransmit Message Identifier >> Option"//Re: [netext] Agenda Requests received >> >> Hi Sri, >> >> Thank you for your response. >> I think I got your meaning but I really don't know why we need it. >> Let's look into the precise details. >> >> An assumed case: >> 1, At time T [in ms], MAG send a PBU to LMA, >> with SN, timestamp T and lifetime 30 second; >> 2, At time (T+1000), MAG resend a PBU to LMA, // >> retransmission in 1 second >> with (SN+1), timestamp (T+1000) and lifetime 30 second >> 3, At time (T+1020), first PBU arrives at LMA; >> 4, At time (T+1050), second PBU arrives at LMA. >> >> In my mind, as RFC5213 and RFC3775, LMA must process >> the second PBU, even if it has already processed the first one, >> because the timestamp is greater than the first one. >> > > Exactly. In the event, when these two messages are sent for > the exact purpose, if the HA can determine that its a duplicate, > it can just complete processing the first request and send a > reply and it can even tag the response as the response to the > latest. The MAG and the LMA have clear semantics on the handling > retransmit messages. Without the option, every message has to > be treated differently and the latest has the precedence. With > the retransmit option, the peers know what messages can be > safely ignored based on the retransmit tags. > > >> As your draft, LMA may or should ignore the second PBU, >> because MAG insert a retransmission tag in the PBU. >> >> But by now, some difference, a very little difference happens. >> In RFC solution, lifetime in LMA expires at (T+1050+30000) , >> while in your draft solution, lifetime expires at (T+1020+30000). >> >> Is that right? > > Deep. Dont get it. > > >> >> I think there is no bug in original solution, but your modification >> bring a different behavior and different result. >> In my thought, all registration with lifetime in IETF protocols, are >> with the same character. >> But now your draft solution bring a modification, making NETEXT >> protocol different from MIP, PMIP, SIP or other protocols. >> >> I'm not sure, is it a bug need us to do a such fix? >> > > > Its not about a bug. As I keep saying, the sender and receiver need > to have the ability to differentiate between a new request to a > retransmit request, either because the retransmit times and the > processing times are not synchronised or when the messages are lost. > The tag is a simple marker. > > Regards > Sri > > > >> Regards/Xiangsong >> >> ======================================================= >> ----- Original Message ----- >> From: "Sri Gundavelli" >> To: "Xiangsong Cui" >> Cc: ; >> Sent: Wednesday, July 15, 2009 1:22 PM >> Subject: Re: Discussion about "Retransmit Message Identifier >> Option"//Re: >> [netext] Agenda Requests received >> >> >> > Hi Xiangsong, >> > >> > Please see inline. >> > >> > On Wed, 15 Jul 2009, Xiangsong Cui wrote: >> > >> >> Good idea. >> >> >> >> I have a question about item 5, "Retransmit Message >> Identifier Option". >> >> I ever posted a mail on 27 June, but it was ignored. So I >> copy the mail >> >> here: >> >> >> > >> > Sorry, we missed that. >> > >> > >> >> The draft says: >> >> ---------------------------------------- >> >> 1. Introduction >> >> >> >> The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the >> >> ability for the sender of a signaling message to mark >> retransmitted >> >> messages with a proper tag, so the receiver can >> differentiate between >> >> the original message to a retransmitted message. This >> semantic is >> >> important for the receiver to determine when to ignore >> processing a >> >> retransmitted packet, or for various other reasons. >> >> --------------------------------------------- >> >> >> >> Is the motive is just to distinguish the original and >> retransmitted PBU? >> >> >> > >> > Yes >> > >> >> >> >> I ask this question just because I think it is >> unnecessary. The reason >> >> is: >> >> >> >> 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" >> field in BU >> >> message, and >> >> section 11.8 [RFC3775] says: >> >> -------------------------------------------------------- >> >> Retransmitted Binding Updates MUST use a Sequence Number value >> >> greater than that used for the previous transmission of >> this Binding >> >> Update. >> >> ---------------------------------------------------- >> >> So the BU messages are different for their sequence number. >> >> >> > >> > We need the ability to distinguish between a original message to a >> > retransmitted request. Lets take the case, LMA receives a PBU and >> > is in the midst of processing that request and a second message >> > arrives. There is nothing in the message which allows the receiver >> > to identify this message as a retransmit of the current message >> > that is being processed. If you go with the seq num, or the time >> > stamp, each message has a different values of those options. What >> > we need is a tag that allows the LMA to see this marking >> and associate >> > with the earlier request. In some interop, there was a case where >> > the MAG was retransmitting a request and ignoring the response for >> > an earlier sent request. This could be avoided, if there are such >> > semantics for tagging retransmitted messages. >> > >> > >> > >> > >> >> 2, section 6.6 [RFC5213] says: >> >> ----------------------------------------- >> >> 6.6. Acquiring Mobile Node's Identifier >> >> >> >> All the network entities in a Proxy Mobile IPv6 domain >> MUST be able >> >> to identify a mobile node, using its MN-Identifier. >> This identifier >> >> MUST be stable and unique across the Proxy Mobile IPv6 >> domain. The >> >> mobility entities in the Proxy Mobile IPv6 domain MUST >> be able to use >> >> this identifier in the signaling messages and >> unambiguously identify >> >> a given mobile node. The following are some of the >> considerations >> >> related to this MN-Identifier. >> >> ------------------------------------------- >> >> In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. >> >> PBU message format also shows there is a sequence # field in PBU >> >> message and "Mobile Node Identifier option" is valid. >> >> >> >> 3, section 6.9.4 [RFC5213] has specified the rule for >> Retransmissions and >> >> Rate Limiting. >> >> >> >> >> >> For these reasons, I believe the LMA can recognize the >> duplicate PBUs. >> >> The LMA has been capable of making binding for the first >> PBU and ignore >> >> other PBUs for the same mobile node. >> >> >> > >> > The rules in 6.9.4 is for addressing the MAG contention >> issue. Its not >> > about detecting duplicate messages. Its more of an out-of >> order delivery >> > issue. >> > >> > >> >> >> >> Do I make any mistakes? and why we need a new extension? >> >> >> > >> > These are good questions. The goal is to have a tag on retransmitted >> > packets. This simple option provides such semantic. Relevant or not, >> > such semantics are even present in protocols such as GTP. >> > >> > Regards >> > Sri >> > >> > >> > >> > >> >> >> >> Because I will not go to the meeting, I want to discuss >> the topic in list >> >> before the meeting. >> >> >> >> Thanks and regards >> >> >> >> Xiangsong >> >> >> >> ================================================= >> >> ----- Original Message ----- From: >> >> To: ; >> >> Sent: Wednesday, July 15, 2009 1:34 AM >> >> Subject: Re: [netext] Agenda Requests received >> >> >> >> >> >>> >> >>> As of 7/14 the chairs have received requests for agenda slots at >> >>> IETF75. >> >>> We would like to encourage WG members to review the I-Ds >> and provide >> >>> feedback on the list prior to the meeting itself. >> >>> >> >>> -Chairs >> >>> >> >>> Agenda requests received: >> >>> >> >>> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >> >>> I-D: draft-korhonen-netext-redirect-02 >> >>> Jouni Korhonen - 10 Mins >> >>> >> >>> 2. Localized Routing >> >>> PMIPv6 Localized Routing Problem Statement >> >>> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >> >>> PS and Scope discussion 10 Mins >> >>> Solutions 15 Mins >> >>> Marco Liebsch et al. >> >>> >> >>> Proxy MIP extension for local routing optimization >> >>> I-D: draft-wu-netext-local-ro-02.txt >> >>> Behcet Sarikaya 5 Mins >> >>> >> >>> 3. Tunnel Negotiation for Proxy Mobile IPv6 >> >>> I-D: draft-xia-netext-tunnel-negotiation-01.txt >> >>> Frank Xia 10 Mins >> >>> >> >>> 4. Mobile Node Group Identifier Option: >> >>> I-D: draft-gundavelli-netext-mn-groupid-option-01 >> >>> Sri Gundavelli 10 Mins >> >>> >> >>> 5. Retransmit Message Identifier Option: >> >>> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >> >>> Sri Gundavelli 10 Mins >> >>> >> >>> 6. Mobility session suspend >> >>> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >> >>> Ahmad Muhanna 10 Mins >> >>> >> >>> 7. Trace Control Support for Proxy Mobile IPv6 >> >>> I-D: draft-wang-netext-trace-control-00.txt >> >>> Yungui Wang 10 Mins >> >>> >> >>> 8. Multihoming extensions for Proxy Mobile IPv6 >> >>> I-D: draft-bernardos-mif-pmip-00.txt >> >>> Telemaco, Pierrick and Carlos 10 Mins >> >>> >> >>> 9. 3GPP MN-AR interface >> >>> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >> >>> Telemaco 5 Mins >> >>> >> >>> 10. Service Flow Identifier in Proxy Mobile IPv6 >> >>> I-D: draft-hui-netext-service-flow-identifier-00.txt >> >>> Min Hui 10 Mins >> >>> >> >>> 11. Connection Identifier for Proxy Mobile IPv6 >> >>> I-D: draft-wolfner-netext-pmip6-connid-00 >> >>> Jouni Korhonen 5 Mins >> >>> >> >>> 12. Bulk Re-registration for Proxy Mobile IPv6 >> >>> I-D: draft-premec-netlmm-bulk-re-registration-02 >> >>> Jouni Korhonen 5 Mins >> >>> >> >>> 13. Partial Handoff Support in PMIPv6 >> >>> I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >> >>> Mohana Jeyatharan >> >>> >> >>> _______________________________________________ >> >>> netext mailing list >> >>> netext@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/netext >> >> >> >> >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sgundave@cisco.com Wed Jul 15 18:23:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399BB3A6B9F for ; Wed, 15 Jul 2009 18:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9Eti32VYYbR for ; Wed, 15 Jul 2009 18:23:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9731D3A69D6 for ; Wed, 15 Jul 2009 18:23:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA8eXkqrR7PE/2dsb2JhbAC4ZogjkQ0FgjSBV4FF X-IronPort-AV: E=Sophos;i="4.42,408,1243814400"; d="scan'208";a="177247990" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2009 01:23:57 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6G1Nv7v012023; Wed, 15 Jul 2009 18:23:57 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n6G1Nuo9015393; Thu, 16 Jul 2009 01:23:56 GMT Date: Wed, 15 Jul 2009 18:23:56 -0700 (PDT) From: Sri Gundavelli To: Xiangsong Cui In-Reply-To: <001701ca05b3$5c79a000$40106f0a@china.huawei.com> Message-ID: References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13267; t=1247707437; x=1248571437; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[netext]=20Discussion=20about=20=22Retr ansmit=20Message=20Identifier=0A=20Option=22//Re=3A=20Agenda =20Requests=20received |Sender:=20; bh=mCbNquUIxNnkU+bdhtGJwLr7va0LWYvyujTCgsoSt10=; b=DDKHyCaHM2m+ofnyW+RdiMdumKDaX5pqnADT94UfvLk8+mOWAKPMEMY3Lm oVrXyAFKJY6e8uTMeCAUkLhJH99nX8d7oMm6kWZcPpxy74/067QPoyrCZl3X rjfW9+PneE; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 01:23:26 -0000 On Thu, 16 Jul 2009, Xiangsong Cui wrote: > Yes, I agree it is a very simple tag. > I just don't understand what benefit we can get from the extension. > That's all my question. > So, you are saying, LMA has no need to identify retransmitted packets ? When a new message arrives, drop the existing one and process the new message. The sender receives reply for the older message and it should drop and send a new request ? In this scenario is it not better for the sender and receiver to have an understanding of what is being processed and what is the new message for and its relation to the older message ? Sri > Thanks > > Xiangsong > > > ----- Original Message ----- From: "Sri Gundavelli" > To: "'Xiangsong Cui'" > Cc: ; > Sent: Thursday, July 16, 2009 8:45 AM > Subject: Re: [netext] Discussion about "Retransmit Message Identifier > Option"//Re: Agenda Requests received > > >> Hi Xiangsong, >> >> > -----Original Message----- >> > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] >> > Sent: Wednesday, July 15, 2009 12:01 AM >> > To: Sri Gundavelli >> > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org >> > Subject: Re: Discussion about "Retransmit Message Identifier >> > Option"//Re: [netext] Agenda Requests received >> > >> > Hi Sri, >> > >> > Thank you for your response. >> > I think I got your meaning but I really don't know why we need it. >> > Let's look into the precise details. >> > >> > An assumed case: >> > 1, At time T [in ms], MAG send a PBU to LMA, >> > with SN, timestamp T and lifetime 30 second; >> > 2, At time (T+1000), MAG resend a PBU to LMA, // >> > retransmission in 1 second >> > with (SN+1), timestamp (T+1000) and lifetime 30 second >> > 3, At time (T+1020), first PBU arrives at LMA; >> > 4, At time (T+1050), second PBU arrives at LMA. >> > >> > In my mind, as RFC5213 and RFC3775, LMA must process >> > the second PBU, even if it has already processed the first one, >> > because the timestamp is greater than the first one. >> > >> >> Exactly. In the event, when these two messages are sent for >> the exact purpose, if the HA can determine that its a duplicate, >> it can just complete processing the first request and send a >> reply and it can even tag the response as the response to the >> latest. The MAG and the LMA have clear semantics on the handling >> retransmit messages. Without the option, every message has to >> be treated differently and the latest has the precedence. With >> the retransmit option, the peers know what messages can be >> safely ignored based on the retransmit tags. >> >> >> > As your draft, LMA may or should ignore the second PBU, >> > because MAG insert a retransmission tag in the PBU. >> > >> > But by now, some difference, a very little difference happens. >> > In RFC solution, lifetime in LMA expires at (T+1050+30000) , >> > while in your draft solution, lifetime expires at (T+1020+30000). >> > >> > Is that right? >> >> Deep. Dont get it. >> >> >> > >> > I think there is no bug in original solution, but your modification >> > bring a different behavior and different result. >> > In my thought, all registration with lifetime in IETF protocols, are >> > with the same character. >> > But now your draft solution bring a modification, making NETEXT >> > protocol different from MIP, PMIP, SIP or other protocols. >> > >> > I'm not sure, is it a bug need us to do a such fix? >> > >> >> >> Its not about a bug. As I keep saying, the sender and receiver need >> to have the ability to differentiate between a new request to a >> retransmit request, either because the retransmit times and the >> processing times are not synchronised or when the messages are lost. >> The tag is a simple marker. >> >> Regards >> Sri >> >> >> >> > Regards/Xiangsong >> > >> > ======================================================= >> > ----- Original Message ----- From: "Sri Gundavelli" >> > To: "Xiangsong Cui" >> > Cc: ; >> > Sent: Wednesday, July 15, 2009 1:22 PM >> > Subject: Re: Discussion about "Retransmit Message Identifier >> > Option"//Re: >> > [netext] Agenda Requests received >> > >> > >> > > Hi Xiangsong, >> > > >> > > Please see inline. >> > > >> > > On Wed, 15 Jul 2009, Xiangsong Cui wrote: >> > > >> > > > Good idea. >> > > > >> > > > I have a question about item 5, "Retransmit Message >> > Identifier Option". >> > > > I ever posted a mail on 27 June, but it was ignored. So I >> > copy the mail >> > > > here: >> > > > >> > > >> > > Sorry, we missed that. >> > > >> > > >> > > > The draft says: >> > > > ---------------------------------------- >> > > > 1. Introduction >> > > > >> > > > The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the >> > > > ability for the sender of a signaling message to mark >> > retransmitted >> > > > messages with a proper tag, so the receiver can >> > differentiate between >> > > > the original message to a retransmitted message. This >> > semantic is >> > > > important for the receiver to determine when to ignore >> > processing a >> > > > retransmitted packet, or for various other reasons. >> > > > --------------------------------------------- >> > > > >> > > > Is the motive is just to distinguish the original and >> > retransmitted PBU? >> > > > >> > > >> > > Yes >> > > >> > > > >> > > > I ask this question just because I think it is >> > unnecessary. The reason >> > > > is: >> > > > >> > > > 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" >> > field in BU >> > > > message, and >> > > > section 11.8 [RFC3775] says: >> > > > -------------------------------------------------------- >> > > > Retransmitted Binding Updates MUST use a Sequence Number value >> > > > greater than that used for the previous transmission of >> > this Binding >> > > > Update. >> > > > ---------------------------------------------------- >> > > > So the BU messages are different for their sequence number. >> > > > >> > > >> > > We need the ability to distinguish between a original message to a >> > > retransmitted request. Lets take the case, LMA receives a PBU and >> > > is in the midst of processing that request and a second message >> > > arrives. There is nothing in the message which allows the receiver >> > > to identify this message as a retransmit of the current message >> > > that is being processed. If you go with the seq num, or the time >> > > stamp, each message has a different values of those options. What >> > > we need is a tag that allows the LMA to see this marking >> > and associate >> > > with the earlier request. In some interop, there was a case where >> > > the MAG was retransmitting a request and ignoring the response for >> > > an earlier sent request. This could be avoided, if there are such >> > > semantics for tagging retransmitted messages. >> > > >> > > >> > > >> > > >> > > > 2, section 6.6 [RFC5213] says: >> > > > ----------------------------------------- >> > > > 6.6. Acquiring Mobile Node's Identifier >> > > > >> > > > All the network entities in a Proxy Mobile IPv6 domain >> > MUST be able >> > > > to identify a mobile node, using its MN-Identifier. >> > This identifier >> > > > MUST be stable and unique across the Proxy Mobile IPv6 >> > domain. The >> > > > mobility entities in the Proxy Mobile IPv6 domain MUST >> > be able to use >> > > > this identifier in the signaling messages and >> > unambiguously identify >> > > > a given mobile node. The following are some of the >> > considerations >> > > > related to this MN-Identifier. >> > > > ------------------------------------------- >> > > > In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. >> > > > PBU message format also shows there is a sequence # field in PBU >> > > > message and "Mobile Node Identifier option" is valid. >> > > > >> > > > 3, section 6.9.4 [RFC5213] has specified the rule for >> > Retransmissions and >> > > > Rate Limiting. >> > > > >> > > > >> > > > For these reasons, I believe the LMA can recognize the >> > duplicate PBUs. >> > > > The LMA has been capable of making binding for the first >> > PBU and ignore >> > > > other PBUs for the same mobile node. >> > > > >> > > >> > > The rules in 6.9.4 is for addressing the MAG contention >> > issue. Its not >> > > about detecting duplicate messages. Its more of an out-of >> > order delivery >> > > issue. >> > > >> > > >> > > > >> > > > Do I make any mistakes? and why we need a new extension? >> > > > >> > > >> > > These are good questions. The goal is to have a tag on retransmitted >> > > packets. This simple option provides such semantic. Relevant or not, >> > > such semantics are even present in protocols such as GTP. >> > > >> > > Regards >> > > Sri >> > > >> > > >> > > >> > > >> > > > >> > > > Because I will not go to the meeting, I want to discuss >> > the topic in list >> > > > before the meeting. >> > > > >> > > > Thanks and regards >> > > > >> > > > Xiangsong >> > > > >> > > > ================================================= >> > > > ----- Original Message ----- From: >> > > > To: ; >> > > > Sent: Wednesday, July 15, 2009 1:34 AM >> > > > Subject: Re: [netext] Agenda Requests received >> > > > >> > > > >> > > > > >> > > > > As of 7/14 the chairs have received requests for agenda slots at >> > > > > IETF75. >> > > > > We would like to encourage WG members to review the I-Ds >> > and provide >> > > > > feedback on the list prior to the meeting itself. >> > > > > >> > > > > -Chairs >> > > > > >> > > > > Agenda requests received: >> > > > > >> > > > > 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >> > > > > I-D: draft-korhonen-netext-redirect-02 >> > > > > Jouni Korhonen - 10 Mins >> > > > > >> > > > > 2. Localized Routing >> > > > > PMIPv6 Localized Routing Problem Statement >> > > > > I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >> > > > > PS and Scope discussion 10 Mins >> > > > > Solutions 15 Mins >> > > > > Marco Liebsch et al. >> > > > > >> > > > > Proxy MIP extension for local routing optimization >> > > > > I-D: draft-wu-netext-local-ro-02.txt >> > > > > Behcet Sarikaya 5 Mins >> > > > > >> > > > > 3. Tunnel Negotiation for Proxy Mobile IPv6 >> > > > > I-D: draft-xia-netext-tunnel-negotiation-01.txt >> > > > > Frank Xia 10 Mins >> > > > > >> > > > > 4. Mobile Node Group Identifier Option: >> > > > > I-D: draft-gundavelli-netext-mn-groupid-option-01 >> > > > > Sri Gundavelli 10 Mins >> > > > > >> > > > > 5. Retransmit Message Identifier Option: >> > > > > I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >> > > > > Sri Gundavelli 10 Mins >> > > > > >> > > > > 6. Mobility session suspend >> > > > > I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >> > > > > Ahmad Muhanna 10 Mins >> > > > > >> > > > > 7. Trace Control Support for Proxy Mobile IPv6 >> > > > > I-D: draft-wang-netext-trace-control-00.txt >> > > > > Yungui Wang 10 Mins >> > > > > >> > > > > 8. Multihoming extensions for Proxy Mobile IPv6 >> > > > > I-D: draft-bernardos-mif-pmip-00.txt >> > > > > Telemaco, Pierrick and Carlos 10 Mins >> > > > > >> > > > > 9. 3GPP MN-AR interface >> > > > > I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >> > > > > Telemaco 5 Mins >> > > > > >> > > > > 10. Service Flow Identifier in Proxy Mobile IPv6 >> > > > > I-D: draft-hui-netext-service-flow-identifier-00.txt >> > > > > Min Hui 10 Mins >> > > > > >> > > > > 11. Connection Identifier for Proxy Mobile IPv6 >> > > > > I-D: draft-wolfner-netext-pmip6-connid-00 >> > > > > Jouni Korhonen 5 Mins >> > > > > >> > > > > 12. Bulk Re-registration for Proxy Mobile IPv6 >> > > > > I-D: draft-premec-netlmm-bulk-re-registration-02 >> > > > > Jouni Korhonen 5 Mins >> > > > > >> > > > > 13. Partial Handoff Support in PMIPv6 >> > > > > I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >> > > > > Mohana Jeyatharan >> > > > > >> > > > > _______________________________________________ >> > > > > netext mailing list >> > > > > netext@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/netext >> > > > >> > > > >> > >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > > From Xiangsong.Cui@huawei.com Wed Jul 15 19:10:36 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC313A6CAC for ; Wed, 15 Jul 2009 19:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNFDa48aWJoD for ; Wed, 15 Jul 2009 19:10:35 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A01E63A6C95 for ; Wed, 15 Jul 2009 19:10:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU00L4NRDC92@szxga03-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 10:10:24 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMU0012CRDBNL@szxga03-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 10:10:24 +0800 (CST) Date: Thu, 16 Jul 2009 10:10:23 +0800 From: Xiangsong Cui To: Sri Gundavelli Message-id: <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 02:10:37 -0000 Hi Sri, Please see inline. Thanks and regards ----- Original Message ----- From: "Sri Gundavelli" To: "Xiangsong Cui" Cc: ; Sent: Thursday, July 16, 2009 9:23 AM Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received > > > On Thu, 16 Jul 2009, Xiangsong Cui wrote: > >> Yes, I agree it is a very simple tag. >> I just don't understand what benefit we can get from the extension. >> That's all my question. >> > > So, you are saying, LMA has no need to identify retransmitted packets ? I think LMA need identify the packets, but need not care the intention. Maybe it is the retransmitted message, maybe a new one, what is the difference for LMA? > When a new message arrives, drop the existing one and process the > new message. Maybe drop the existing one, or maybe process both messages (I think latter is the right way in RFCs) and responds two binding Ack message. > The sender receives reply for the older message and it > should drop and send a new request ? Yes, sender will receive reply message, maybe one or two response. If sender send two request, one is for binding and the other one is for retransmission, I think there is only one timer and only one timer for retransmission in the sender. If the sender receives reply message, it has achieved the registration and it must kill the timer, and will not retransmit request any more. This is the key point, Do you agree it? If the timer has been killed, I don't know why the sender will send a new request. > In this scenario is it not better > for the sender and receiver to have an understanding of what is being > processed and what is the new message for and its relation to the > older message ? I am not sure which one is better. > > Sri > > > >> Thanks >> >> Xiangsong >> >> >> ----- Original Message ----- From: "Sri Gundavelli" >> To: "'Xiangsong Cui'" >> Cc: ; >> Sent: Thursday, July 16, 2009 8:45 AM >> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >> Option"//Re: Agenda Requests received >> >> >>> Hi Xiangsong, >>> >>> > -----Original Message----- >>> > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] >>> > Sent: Wednesday, July 15, 2009 12:01 AM >>> > To: Sri Gundavelli >>> > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org >>> > Subject: Re: Discussion about "Retransmit Message Identifier >>> > Option"//Re: [netext] Agenda Requests received >>> > >>> > Hi Sri, >>> > >>> > Thank you for your response. >>> > I think I got your meaning but I really don't know why we need it. >>> > Let's look into the precise details. >>> > >>> > An assumed case: >>> > 1, At time T [in ms], MAG send a PBU to LMA, >>> > with SN, timestamp T and lifetime 30 second; >>> > 2, At time (T+1000), MAG resend a PBU to LMA, // >>> > retransmission in 1 second >>> > with (SN+1), timestamp (T+1000) and lifetime 30 second >>> > 3, At time (T+1020), first PBU arrives at LMA; >>> > 4, At time (T+1050), second PBU arrives at LMA. >>> > >>> > In my mind, as RFC5213 and RFC3775, LMA must process >>> > the second PBU, even if it has already processed the first one, >>> > because the timestamp is greater than the first one. >>> > >>> >>> Exactly. In the event, when these two messages are sent for >>> the exact purpose, if the HA can determine that its a duplicate, >>> it can just complete processing the first request and send a >>> reply and it can even tag the response as the response to the >>> latest. The MAG and the LMA have clear semantics on the handling >>> retransmit messages. Without the option, every message has to >>> be treated differently and the latest has the precedence. With >>> the retransmit option, the peers know what messages can be >>> safely ignored based on the retransmit tags. >>> >>> >>> > As your draft, LMA may or should ignore the second PBU, >>> > because MAG insert a retransmission tag in the PBU. >>> > >>> > But by now, some difference, a very little difference happens. >>> > In RFC solution, lifetime in LMA expires at (T+1050+30000) , >>> > while in your draft solution, lifetime expires at (T+1020+30000). >>> > >>> > Is that right? >>> >>> Deep. Dont get it. >>> >>> >>> > >>> > I think there is no bug in original solution, but your modification >>> > bring a different behavior and different result. >>> > In my thought, all registration with lifetime in IETF protocols, are >>> > with the same character. >>> > But now your draft solution bring a modification, making NETEXT >>> > protocol different from MIP, PMIP, SIP or other protocols. >>> > >>> > I'm not sure, is it a bug need us to do a such fix? >>> > >>> >>> Its not about a bug. As I keep saying, the sender and receiver need >>> to have the ability to differentiate between a new request to a >>> retransmit request, either because the retransmit times and the >>> processing times are not synchronised or when the messages are lost. >>> The tag is a simple marker. >>> >>> Regards >>> Sri >>> >>> >>> >>> > Regards/Xiangsong >>> > >>> > ======================================================= >>> > ----- Original Message ----- From: "Sri Gundavelli" >>> > >>> > To: "Xiangsong Cui" >>> > Cc: ; >>> > Sent: Wednesday, July 15, 2009 1:22 PM >>> > Subject: Re: Discussion about "Retransmit Message Identifier >>> > Option"//Re: >>> > [netext] Agenda Requests received >>> > >>> > >>> > > Hi Xiangsong, >>> > > >>> > > Please see inline. >>> > > >>> > > On Wed, 15 Jul 2009, Xiangsong Cui wrote: >>> > > >>> > > > Good idea. >>> > > > >>> > > > I have a question about item 5, "Retransmit Message >>> > Identifier Option". >>> > > > I ever posted a mail on 27 June, but it was ignored. So I >>> > copy the mail >>> > > > here: >>> > > > >>> > > >>> > > Sorry, we missed that. >>> > > >>> > > >>> > > > The draft says: >>> > > > ---------------------------------------- >>> > > > 1. Introduction >>> > > > >>> > > > The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the >>> > > > ability for the sender of a signaling message to mark >>> > retransmitted >>> > > > messages with a proper tag, so the receiver can >>> > differentiate between >>> > > > the original message to a retransmitted message. This >>> > semantic is >>> > > > important for the receiver to determine when to ignore >>> > processing a >>> > > > retransmitted packet, or for various other reasons. >>> > > > --------------------------------------------- >>> > > > >>> > > > Is the motive is just to distinguish the original and >>> > retransmitted PBU? >>> > > > >>> > > >>> > > Yes >>> > > >>> > > > >>> > > > I ask this question just because I think it is >>> > unnecessary. The reason >>> > > > is: >>> > > > >>> > > > 1, section 6.1.7 [RFC3775] shows there is a "Sequence #" >>> > field in BU >>> > > > message, and >>> > > > section 11.8 [RFC3775] says: >>> > > > -------------------------------------------------------- >>> > > > Retransmitted Binding Updates MUST use a Sequence Number >>> > > > value >>> > > > greater than that used for the previous transmission of >>> > this Binding >>> > > > Update. >>> > > > ---------------------------------------------------- >>> > > > So the BU messages are different for their sequence number. >>> > > > >>> > > >>> > > We need the ability to distinguish between a original message to a >>> > > retransmitted request. Lets take the case, LMA receives a PBU and >>> > > is in the midst of processing that request and a second message >>> > > arrives. There is nothing in the message which allows the receiver >>> > > to identify this message as a retransmit of the current message >>> > > that is being processed. If you go with the seq num, or the time >>> > > stamp, each message has a different values of those options. What >>> > > we need is a tag that allows the LMA to see this marking >>> > and associate >>> > > with the earlier request. In some interop, there was a case where >>> > > the MAG was retransmitting a request and ignoring the response for >>> > > an earlier sent request. This could be avoided, if there are such >>> > > semantics for tagging retransmitted messages. >>> > > >>> > > >>> > > >>> > > >>> > > > 2, section 6.6 [RFC5213] says: >>> > > > ----------------------------------------- >>> > > > 6.6. Acquiring Mobile Node's Identifier >>> > > > >>> > > > All the network entities in a Proxy Mobile IPv6 domain >>> > MUST be able >>> > > > to identify a mobile node, using its MN-Identifier. >>> > This identifier >>> > > > MUST be stable and unique across the Proxy Mobile IPv6 >>> > domain. The >>> > > > mobility entities in the Proxy Mobile IPv6 domain MUST >>> > be able to use >>> > > > this identifier in the signaling messages and >>> > unambiguously identify >>> > > > a given mobile node. The following are some of the >>> > considerations >>> > > > related to this MN-Identifier. >>> > > > ------------------------------------------- >>> > > > In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID. >>> > > > PBU message format also shows there is a sequence # field in >>> > > > PBU >>> > > > message and "Mobile Node Identifier option" is valid. >>> > > > >>> > > > 3, section 6.9.4 [RFC5213] has specified the rule for >>> > Retransmissions and >>> > > > Rate Limiting. >>> > > > >>> > > > >>> > > > For these reasons, I believe the LMA can recognize the >>> > duplicate PBUs. >>> > > > The LMA has been capable of making binding for the first >>> > PBU and ignore >>> > > > other PBUs for the same mobile node. >>> > > > >>> > > >>> > > The rules in 6.9.4 is for addressing the MAG contention >>> > issue. Its not >>> > > about detecting duplicate messages. Its more of an out-of >>> > order delivery >>> > > issue. >>> > > >>> > > >>> > > > >>> > > > Do I make any mistakes? and why we need a new extension? >>> > > > >>> > > >>> > > These are good questions. The goal is to have a tag on >>> > > retransmitted >>> > > packets. This simple option provides such semantic. Relevant or >>> > > not, >>> > > such semantics are even present in protocols such as GTP. >>> > > >>> > > Regards >>> > > Sri >>> > > >>> > > >>> > > >>> > > >>> > > > >>> > > > Because I will not go to the meeting, I want to discuss >>> > the topic in list >>> > > > before the meeting. >>> > > > >>> > > > Thanks and regards >>> > > > >>> > > > Xiangsong >>> > > > >>> > > > ================================================= >>> > > > ----- Original Message ----- From: >>> > > > To: ; >>> > > > Sent: Wednesday, July 15, 2009 1:34 AM >>> > > > Subject: Re: [netext] Agenda Requests received >>> > > > >>> > > > >>> > > > > >>> > > > > As of 7/14 the chairs have received requests for agenda slots >>> > > > > at >>> > > > > IETF75. >>> > > > > We would like to encourage WG members to review the I-Ds >>> > and provide >>> > > > > feedback on the list prior to the meeting itself. >>> > > > > >>> > > > > -Chairs >>> > > > > >>> > > > > Agenda requests received: >>> > > > > >>> > > > > 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >>> > > > > I-D: draft-korhonen-netext-redirect-02 >>> > > > > Jouni Korhonen - 10 Mins >>> > > > > >>> > > > > 2. Localized Routing >>> > > > > PMIPv6 Localized Routing Problem Statement >>> > > > > I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >>> > > > > PS and Scope discussion 10 Mins >>> > > > > Solutions 15 Mins >>> > > > > Marco Liebsch et al. >>> > > > > >>> > > > > Proxy MIP extension for local routing optimization >>> > > > > I-D: draft-wu-netext-local-ro-02.txt >>> > > > > Behcet Sarikaya 5 Mins >>> > > > > >>> > > > > 3. Tunnel Negotiation for Proxy Mobile IPv6 >>> > > > > I-D: draft-xia-netext-tunnel-negotiation-01.txt >>> > > > > Frank Xia 10 Mins >>> > > > > >>> > > > > 4. Mobile Node Group Identifier Option: >>> > > > > I-D: draft-gundavelli-netext-mn-groupid-option-01 >>> > > > > Sri Gundavelli 10 Mins >>> > > > > >>> > > > > 5. Retransmit Message Identifier Option: >>> > > > > I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >>> > > > > Sri Gundavelli 10 Mins >>> > > > > >>> > > > > 6. Mobility session suspend >>> > > > > I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >>> > > > > Ahmad Muhanna 10 Mins >>> > > > > >>> > > > > 7. Trace Control Support for Proxy Mobile IPv6 >>> > > > > I-D: draft-wang-netext-trace-control-00.txt >>> > > > > Yungui Wang 10 Mins >>> > > > > >>> > > > > 8. Multihoming extensions for Proxy Mobile IPv6 >>> > > > > I-D: draft-bernardos-mif-pmip-00.txt >>> > > > > Telemaco, Pierrick and Carlos 10 Mins >>> > > > > >>> > > > > 9. 3GPP MN-AR interface >>> > > > > I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >>> > > > > Telemaco 5 Mins >>> > > > > >>> > > > > 10. Service Flow Identifier in Proxy Mobile IPv6 >>> > > > > I-D: draft-hui-netext-service-flow-identifier-00.txt >>> > > > > Min Hui 10 Mins >>> > > > > >>> > > > > 11. Connection Identifier for Proxy Mobile IPv6 >>> > > > > I-D: draft-wolfner-netext-pmip6-connid-00 >>> > > > > Jouni Korhonen 5 Mins >>> > > > > >>> > > > > 12. Bulk Re-registration for Proxy Mobile IPv6 >>> > > > > I-D: draft-premec-netlmm-bulk-re-registration-02 >>> > > > > Jouni Korhonen 5 Mins >>> > > > > >>> > > > > 13. Partial Handoff Support in PMIPv6 >>> > > > > I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >>> > > > > Mohana Jeyatharan >>> > > > > >>> > > > > _______________________________________________ >>> > > > > netext mailing list >>> > > > > netext@ietf.org >>> > > > > https://www.ietf.org/mailman/listinfo/netext >>> > > > >>> > > > >>> > >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> >> From sgundave@cisco.com Wed Jul 15 21:14:59 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A7B3A6914 for ; Wed, 15 Jul 2009 21:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyAdmDIqgMAC for ; Wed, 15 Jul 2009 21:14:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BD4D83A6B1E for ; Wed, 15 Jul 2009 21:14:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADJFXkqrR7O6/2dsb2JhbAC4LYgjkQcFgjSBVw X-IronPort-AV: E=Sophos;i="4.42,409,1243814400"; d="scan'208";a="214662948" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2009 04:14:08 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6G4E834021364; Wed, 15 Jul 2009 21:14:08 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6G4E78F024883; Thu, 16 Jul 2009 04:14:07 GMT Date: Wed, 15 Jul 2009 21:14:07 -0700 (PDT) From: Sri Gundavelli To: Xiangsong Cui In-Reply-To: <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> Message-ID: References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3068; t=1247717648; x=1248581648; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[netext]=20Discussion=20about=20=22Retr ansmit=20Message=20Identifier=0A=20Option=22//Re=3A=20Agenda =20Requests=20received |Sender:=20; bh=QToN0u29LTmEyOHenOKsyiJU5yqokuIjxGLhvnN6rbs=; b=KnE+UsWMacwEz+GrGY8e1mQ95/QQKiD7r/gEZ1Cr4Ey/nxM+G6wXlAOEl5 Q0v4c3FmyuWcZHWbzNvZnl2c9CQEjFATHubRgd5rPWiEYVh+Z3PIh/ZLnbE3 3pCz0//6I7; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 04:15:00 -0000 Hi Xiangsong, On Thu, 16 Jul 2009, Xiangsong Cui wrote: > Hi Sri, > Please see inline. > > Thanks and regards > > ----- Original Message ----- From: "Sri Gundavelli" > To: "Xiangsong Cui" > Cc: ; > Sent: Thursday, July 16, 2009 9:23 AM > Subject: Re: [netext] Discussion about "Retransmit Message Identifier > Option"//Re: Agenda Requests received > > >> >> >> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >> >> > Yes, I agree it is a very simple tag. >> > I just don't understand what benefit we can get from the extension. >> > That's all my question. >> > >> >> So, you are saying, LMA has no need to identify retransmitted packets ? > I think LMA need identify the packets, but need not care the intention. > Maybe it is the retransmitted message, maybe a new one, what is the > difference for LMA? > It makes a difference. When the LMA is waiting for a AAA response or waiting for some other resource, this distinction will be critical. A response that it constructs, can simply be sent as a response to the latest request, if it knows that the newly recvd request and the request under processing are the same. The MAG would always be able to know that the response that is received is the response for the latest. With the current lack of semantics, there can be cases where the MAG keeps sending requests, LMA keeps responding as it processes and the MAG still waiting for the latest response. >> When a new message arrives, drop the existing one and process the >> new message. > Maybe drop the existing one, or maybe process both messages (I think > latter is the right way in RFCs) and responds two binding Ack message. > But, the current text is not considering this scenario. There is not much consideration given to retransmit packets. >> The sender receives reply for the older message and it >> should drop and send a new request ? > Yes, sender will receive reply message, maybe one or two response. > If sender send two request, one is for binding and the other one is for > retransmission, I think there is only one timer and only one timer for > retransmission in the sender. If the sender receives reply message, it > has achieved the registration and it must kill the timer, and will not > retransmit request any more. > This is the key point, Do you agree it? > If the timer has been killed, I don't know why the sender will send a > new request. > But, there is a req to reply corelator when using seq numbers, that wont match. >> In this scenario is it not better >> for the sender and receiver to have an understanding of what is being >> processed and what is the new message for and its relation to the >> older message ? > I am not sure which one is better. > The bigger question would be do we need the ability to understand the sender intent and benifit in the processing logic in knowing the same, and avoiding the looping issue. Sri From Xiangsong.Cui@huawei.com Wed Jul 15 22:21:56 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828163A6ACF for ; Wed, 15 Jul 2009 22:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02aJbOB9+Fis for ; Wed, 15 Jul 2009 22:21:54 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0B30C3A657C for ; Wed, 15 Jul 2009 22:21:54 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMV00MPL04G67@szxga02-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 13:19:29 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMV000VE04GTM@szxga02-in.huawei.com> for netext@ietf.org; Thu, 16 Jul 2009 13:19:28 +0800 (CST) Date: Thu, 16 Jul 2009 13:19:28 +0800 From: Xiangsong Cui To: Sri Gundavelli Message-id: <00b001ca05d4$fe0beb00$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 05:21:56 -0000 Hi Sri, I think we meet some key detail in MAG. Maybe they are implement issues How does MAG start its timer for binding request? case 1: ONLY one timer for the binding request thread; or case 2: One timer for per binding request message. I prefer the case 1, and in case 1, as I said no trouble happen. Without multi-homing, MAG and LMA can identify the thread by source IP address and destination IP address, if with multi-homing, BID may be plus to identify the thread. In case 1, MAG and LMA identify request/response by thread, but not by sequence number. One reply can kill the thread timer. So only one timer starts and SN mismatch will not happen in case 1. In case 2, multi timer are started for multi request messages, and SN is used to identify message. If only one response returned as your solution, what will happen? some timer still running (because only reply SN timer is killed) and requests are sent in period. Looping issue will happen in this case, if your solution is applied. By the way, if you just want to distinguish original request and retransmitted request, I have another idea, without any message or option format modified in the protocol. We can claim a rule or suggestion: When MAG retransmits a binding request, it uses the original timestamp, as the value in original request message. For LMA, when a binding request message is received, timestamp is checked: If new-arrived timestamp is greater, new request; if new-arrived timestamp is equal, duplicate request, ignore or other process. if new-arrived timestamp is less, old request, drop it. Timestamp details is missed in RFCs, there are only sequence number increase. We can highlight the rule or suggestion in bis version. How do you think about the idea? Xiangsong ----- Original Message ----- From: "Sri Gundavelli" To: "Xiangsong Cui" Cc: ; Sent: Thursday, July 16, 2009 12:14 PM Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received > Hi Xiangsong, > > > On Thu, 16 Jul 2009, Xiangsong Cui wrote: > >> Hi Sri, >> Please see inline. >> >> Thanks and regards >> >> ----- Original Message ----- From: "Sri Gundavelli" >> To: "Xiangsong Cui" >> Cc: ; >> Sent: Thursday, July 16, 2009 9:23 AM >> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >> Option"//Re: Agenda Requests received >> >> >>> >>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>> >>> > Yes, I agree it is a very simple tag. >>> > I just don't understand what benefit we can get from the extension. >>> > That's all my question. >>> > >>> >>> So, you are saying, LMA has no need to identify retransmitted packets ? >> I think LMA need identify the packets, but need not care the intention. >> Maybe it is the retransmitted message, maybe a new one, what is the >> difference for LMA? >> > > It makes a difference. When the LMA is waiting for a AAA response or > waiting for some other resource, this distinction will be critical. > A response that it constructs, can simply be sent as a response to > the latest request, if it knows that the newly recvd request and > the request under processing are the same. The MAG would always > be able to know that the response that is received is the response > for the latest. With the current lack of semantics, there can be > cases where the MAG keeps sending requests, LMA keeps responding > as it processes and the MAG still waiting for the latest response. > > >>> When a new message arrives, drop the existing one and process the >>> new message. >> Maybe drop the existing one, or maybe process both messages (I think >> latter is the right way in RFCs) and responds two binding Ack message. >> > > But, the current text is not considering this scenario. There is > not much consideration given to retransmit packets. > > >>> The sender receives reply for the older message and it >>> should drop and send a new request ? >> Yes, sender will receive reply message, maybe one or two response. >> If sender send two request, one is for binding and the other one is for >> retransmission, I think there is only one timer and only one timer for >> retransmission in the sender. If the sender receives reply message, it >> has achieved the registration and it must kill the timer, and will not >> retransmit request any more. >> This is the key point, Do you agree it? >> If the timer has been killed, I don't know why the sender will send a >> new request. >> > > But, there is a req to reply corelator when using seq numbers, that > wont match. > >>> In this scenario is it not better >>> for the sender and receiver to have an understanding of what is being >>> processed and what is the new message for and its relation to the >>> older message ? >> I am not sure which one is better. >> > > The bigger question would be do we need the ability to understand > the sender intent and benifit in the processing logic in knowing > the same, and avoiding the looping issue. > > Sri > From jouni.nospam@gmail.com Thu Jul 16 05:49:16 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F8228C1C6 for ; Thu, 16 Jul 2009 05:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWny-y5Yimvr for ; Thu, 16 Jul 2009 05:49:15 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 5A14F28C1D1 for ; Thu, 16 Jul 2009 05:49:00 -0700 (PDT) Received: by ewy26 with SMTP id 26so90993ewy.37 for ; Thu, 16 Jul 2009 05:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=PGSyaD4o1cpBGgtUM8oUS3T4XbTYkHaQNPZI26LZn5M=; b=NK9hujgnHhOl0+9BkgaCTWv9jGnJrdZQFcrW6fGwjplBIDdqUdwQDN/Phtr2n/C1pw m+useitS5Gjod372R6PzJTNOhkAechK1MEnyrLABwPiCmI1TSqUi0Yhj72+23c5z45Wz RLtqDa+XcoxKZ27UteUe/GwFnLD4Jwq6M67as= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=fpNO1FxmsVQogGNuczUV+Y9rmFzEz+iKFllcvG4/3/z3Xsi+p7Al0WqX9nwnkeByrl 2r4maR+XKJ2ba/NkLWqwmriH7CA/UOOXCzvo6E27K0pe5PGGl8n2IlyGqwVD6eROEhEb r7zk9KENlIQ0PzOTm8FtpnZ1K4/+iv9zOvb34= Received: by 10.211.196.3 with SMTP id y3mr2368712ebp.34.1247748558625; Thu, 16 Jul 2009 05:49:18 -0700 (PDT) Received: from a88-114-66-140.elisa-laajakaista.fi (a88-114-66-140.elisa-laajakaista.fi [88.114.66.140]) by mx.google.com with ESMTPS id 28sm71458eye.26.2009.07.16.05.49.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Jul 2009 05:49:18 -0700 (PDT) Message-Id: From: jouni korhonen To: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 16 Jul 2009 15:49:16 +0300 References: X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 12:49:16 -0000 Hi Raj, Thanks for the quick review. I got some answer inline. On Jul 16, 2009, at 12:33 AM, wrote: > > > Hello, > > A few questions/comments related to the proposal to add a connection > identifier to the PMIP6 signaling and BCE: > > 1. Each of the PDN bearers will have a unique prefix assigned to it by > the LMA, right? Even though the MN-ID remains the same the LMA will right. > have to create multiple BCEs for the MN. The scenario is equivalent > to the MN attaching via different interfaces thru the same MAG/LMA > pair. To some extent it is the same. However, the introductory text the draft scopes the work to a single interface. Maybe there is a way to express the whole solution independent of the number of interfaces. > > 2. The I-D says that the mechanism by which the MAG figures out that > a new bi-directional tunnel is needed to be established (and a new > prefix obtained) is out of scope. In certain networks you are > obtaining this information from L2 and is used by the MAG. Current Correct. > RFC5213 lacks the ability by which an MN (which is already attached > via an interface) can request dynamically a new prefix to be > assigned to it for the same interface. The connection ID would be > useful if we were to also specify how the MN can request an > additional prefix via an interface that is already attached and has > been assigned a prefix from a MAG/LMA pair. > It might be useful to explain how L2s can provide such indications > in an > appendix. Good point. We'll add this. > > 3. In the case of HO the target MAG will not be aware of the CID > unless there a context transfer mechanism between the MAGs. Please > note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes > context transfer capability between MAGs. I'll have a look at this. > > 4. If each PDN bearer is assigned a unique prefix, can you not use the > HNP assigned as the CID? Actually, this would be the clean solution. The problem is that is the MN has multiple mobility sessions to the same service, the target MAG (after a handover) does not necessarily know which of those sessions the MN wants to use and in which order. Once the MN reattaches to MAG, which initiates the PBU/PBA exchange, there is no prefix information available from the MN side yet.. however, most probably the L2 has some additional information that the MAG and the LMA can use to make the distinction. We do not really define what this L2 information is and how to retrieve it, but still we need a mechanism to transfer that around and take into account when doing BC lookups. > > I do agree with the need to support the ability by which multiple > mobility sessions to the same LMA (via the same MAG) from a single > interface is needed. This is applicable in EPC and other networks > which use PMIP6. > > -Raj Cheers, Jouni > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Thu Jul 16 07:42:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5723A6D8D for ; Thu, 16 Jul 2009 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYmXuX-altsz for ; Thu, 16 Jul 2009 07:42:07 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id 7286E3A6D7D for ; Thu, 16 Jul 2009 07:42:07 -0700 (PDT) Received: from [69.147.84.144] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 16 Jul 2009 14:42:38 -0000 Received: from [67.195.9.83] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 16 Jul 2009 14:42:38 -0000 Received: from [67.195.9.107] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 16 Jul 2009 14:42:38 -0000 Received: from [127.0.0.1] by omp111.mail.gq1.yahoo.com with NNFMP; 16 Jul 2009 14:42:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 718425.14003.bm@omp111.mail.gq1.yahoo.com Received: (qmail 28097 invoked by uid 60001); 16 Jul 2009 14:42:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247755358; bh=YA8pSqYdt9aNWiCw9hAy1QHvrRliD9QwUA2N2QjJuFo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nj9bT4q7/gVv7ie5C2Pf8IGH2jIleDx1AyJvk2F7rli8A2FoHAlvNo2FP1J5R0gKdkGx95ljcjjYeJHPONk5v5DjKx9YqiGULrk4JORvjk9nhxMRuoCWv3NAqsqXAMlObgtMP+9AU/pxfDXI0d0tgCABgzGJN/gI4E69UTPD3nY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aNCJUJ/SlZszthKgBstOcSR9t8LCoRl9AxvuqJvAXcvQTdxxI0FXSWkqq/HHbJBUhQhYcmiUAXd2fq7x5BRfnhrRlnsBp2TPeF9fBTZkhgT1MmAnjJY6+IH/V4i7hHkmO8Six6JtjrM/ICCvx+Hef23fLxCE/Rcq/BxcQxaMuUo=; Message-ID: <597118.26339.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: kx1239MVM1k.llEAGzKfLg9ke5vkSOhT4q2D6W34L8UP4_niafukK6c2RqSPavWSFg6fQP71U6FzVIUI07bYITLpkdBG0BsHVxuws4bOngclDOozO22.ULJLBbEiD6iPqhSnTfe6yNq.SBW5r6OFIxCgHGPT_OtquhNw4_VbHGU8VMl5uhMtR2uSOB1uyREWJA6vh3EuTCfODurRr3CDiOGGaSj6KpAs_vfJOZKXNSWPwwkLDpTaN9OkrFju_72lxSgtFlrjRQQ4wHGUnPuJZxtKO0.5zLB_3R9FWUKdapQfHCZr_QwHyBoHAchg3QiLiBH_7hLezpMnQXqH2lRxa2c- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 16 Jul 2009 07:42:38 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 References: Date: Thu, 16 Jul 2009 07:42:38 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 14:42:08 -0000 Hi Raj,=0A=A0 It seems to me that you are talking about prefix management. = =0AThis issue of requesting prefixes etc. falls into how LMA should manage = prefixes. These issues can be seen as different aspects of what we cover in= =0Ahttp://tools.ietf.org/id/draft-sarikaya-netext-prefix-delegation-00.txt= =0A=0A=A0 Regards,=0A=0ABehcet=0A=0A=0A----- Original Message ----=0A> From= : "Basavaraj.Patil@nokia.com" =0A> To: netext@ie= tf.org=0A> Sent: Wednesday, July 15, 2009 4:33:42 PM=0A> Subject: [netext] = Comments on I-D: draft-wolfner-netext-pmip6-connid-00=0A> =0A> =0A> =0A> He= llo,=0A> =0A> A few questions/comments related to the proposal to add a con= nection=0A> identifier to the PMIP6 signaling and BCE:=0A> =0A> 1. Each of = the PDN bearers will have a unique prefix assigned to it by=0A> =A0 the LMA= , right? Even though the MN-ID remains the same the LMA will=0A> =A0 have t= o create multiple BCEs for the MN. The scenario is equivalent=0A> =A0 to th= e MN attaching via different interfaces thru the same MAG/LMA=0A> =A0 pair.= =0A> =A0 =0A> 2. The I-D says that the mechanism by which the MAG figures = out that=0A> =A0 a new bi-directional tunnel is needed to be established (a= nd a new=0A> =A0 prefix obtained) is out of scope. In certain networks you = are=0A> =A0 obtaining this information from L2 and is used by the MAG. Curr= ent=0A> =A0 RFC5213 lacks the ability by which an MN (which is already atta= ched=0A> =A0 via an interface) can request dynamically a new prefix to be= =0A> =A0 assigned to it for the same interface. The connection ID would be= =0A> =A0 useful if we were to also specify how the MN can request an=0A> = =A0 additional prefix via an interface that is already attached and has=0A>= =A0 been assigned a prefix from a MAG/LMA pair.=0A> =A0 It might be useful= to explain how L2s can provide such indications in an=0A> appendix.=0A> = =0A> 3. In the case of HO the target MAG will not be aware of the CID=0A> = =A0 unless there a context transfer mechanism between the MAGs. Please=0A> = =A0 note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes=0A> =A0 c= ontext transfer capability between MAGs.=0A> =0A> 4. If each PDN bearer is = assigned a unique prefix, can you not use the=0A> =A0 HNP assigned as the C= ID?=0A> =0A> I do agree with the need to support the ability by which multi= ple=0A> mobility sessions to the same LMA (via the same MAG) from a single= =0A> interface is needed. This is applicable in EPC and other networks=0A> = which use PMIP6. =0A> =0A> -Raj=0A> =0A> __________________________________= _____________=0A> netext mailing list=0A> netext@ietf.org=0A> https://www.i= etf.org/mailman/listinfo/netext=0A=0A=0A=0A From Basavaraj.Patil@nokia.com Thu Jul 16 13:16:39 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093533A69DD for ; Thu, 16 Jul 2009 13:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuV2nm7S3Jtc for ; Thu, 16 Jul 2009 13:16:38 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BAB6A3A6823 for ; Thu, 16 Jul 2009 13:16:37 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6GKGqmv031901; Thu, 16 Jul 2009 23:16:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:16:57 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:16:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:16:52 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 16 Jul 2009 22:16:51 +0200 From: To: , Date: Thu, 16 Jul 2009 22:17:05 +0200 Thread-Topic: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 Thread-Index: AcoGI7JFcIoa+UbqS+62shxfcFm2KAALrCjg Message-ID: In-Reply-To: <597118.26339.qm@web111410.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2009 20:16:52.0239 (UTC) FILETIME=[5B4DC9F0:01CA0652] X-Nokia-AV: Clean Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 20:16:39 -0000 Inline: On 7/16/09 9:42 AM, "ext Behcet Sarikaya" wrote: >=20 >=20 > Hi Raj, > =A0 It seems to me that you are talking about prefix management. Not really.=20 The concept of a connection identifier is different from prefix management. The connid I-D is proposing a solution which enables the establishment of multiple mobility sessions via the same MAG/LMA pair. Each of the mobility sessions is assigned an HNP. But the concept of connection ID is different from prefix management. -Raj > This issue of requesting prefixes etc. falls into how LMA should manage > prefixes. These issues can be seen as different aspects of what we cover = in > http://tools.ietf.org/id/draft-sarikaya-netext-prefix-delegation-00.txt >=20 > =A0 Regards, >=20 > Behcet >=20 >=20 > ----- Original Message ---- >> From: "Basavaraj.Patil@nokia.com" >> To: netext@ietf.org >> Sent: Wednesday, July 15, 2009 4:33:42 PM >> Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 >>=20 >>=20 >>=20 >> Hello, >>=20 >> A few questions/comments related to the proposal to add a connection >> identifier to the PMIP6 signaling and BCE: >>=20 >> 1. Each of the PDN bearers will have a unique prefix assigned to it by >> =A0 the LMA, right? Even though the MN-ID remains the same the LMA will >> =A0 have to create multiple BCEs for the MN. The scenario is equivalent >> =A0 to the MN attaching via different interfaces thru the same MAG/LMA >> =A0 pair. >> =A0 >> 2. The I-D says that the mechanism by which the MAG figures out that >> =A0 a new bi-directional tunnel is needed to be established (and a new >> =A0 prefix obtained) is out of scope. In certain networks you are >> =A0 obtaining this information from L2 and is used by the MAG. Current >> =A0 RFC5213 lacks the ability by which an MN (which is already attached >> =A0 via an interface) can request dynamically a new prefix to be >> =A0 assigned to it for the same interface. The connection ID would be >> =A0 useful if we were to also specify how the MN can request an >> =A0 additional prefix via an interface that is already attached and has >> =A0 been assigned a prefix from a MAG/LMA pair. >> =A0 It might be useful to explain how L2s can provide such indications i= n an >> appendix. >>=20 >> 3. In the case of HO the target MAG will not be aware of the CID >> =A0 unless there a context transfer mechanism between the MAGs. Please >> =A0 note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes >> =A0 context transfer capability between MAGs. >>=20 >> 4. If each PDN bearer is assigned a unique prefix, can you not use the >> =A0 HNP assigned as the CID? >>=20 >> I do agree with the need to support the ability by which multiple >> mobility sessions to the same LMA (via the same MAG) from a single >> interface is needed. This is applicable in EPC and other networks >> which use PMIP6. >>=20 >> -Raj >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 >=20 >=20 > =20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Jul 16 13:25:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAE03A689F for ; Thu, 16 Jul 2009 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RF1KAh1CVhZ for ; Thu, 16 Jul 2009 13:25:56 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 363443A69DD for ; Thu, 16 Jul 2009 13:25:55 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6GKQ3Ld028085; Thu, 16 Jul 2009 15:26:21 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:26:21 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:26:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:26:16 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 16 Jul 2009 22:26:16 +0200 From: To: Date: Thu, 16 Jul 2009 22:26:28 +0200 Thread-Topic: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 Thread-Index: AcoGE95/9VDChexER/eFvgm7F5/1LAAP9P/m Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2009 20:26:16.0217 (UTC) FILETIME=[AB760090:01CA0653] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 20:25:57 -0000 Hi Jouni, Response inline: On 7/16/09 7:49 AM, "ext jouni korhonen" wrote: > Hi Raj, >=20 > Thanks for the quick review. I got some answer inline. >=20 >=20 > On Jul 16, 2009, at 12:33 AM, > > wrote: >=20 >>=20 >>=20 >> Hello, >>=20 >> A few questions/comments related to the proposal to add a connection >> identifier to the PMIP6 signaling and BCE: >>=20 >> 1. Each of the PDN bearers will have a unique prefix assigned to it by >> the LMA, right? Even though the MN-ID remains the same the LMA will >=20 > right. >=20 >> have to create multiple BCEs for the MN. The scenario is equivalent >> to the MN attaching via different interfaces thru the same MAG/LMA >> pair. >=20 > To some extent it is the same. However, the introductory text the > draft scopes the work to a single interface. Maybe there is a way to > express the whole solution independent of the number of interfaces. I believe there is no problem in establishing a new mobility session when the MN attaches via a second interface. However there is currently no way t= o establish multiple mobility sessions via a single interface. I think there is a need to solve this issue. It would be useful to explicitly state the intent of enabling multiple mobility sessions via a single interface in the I-D.=20 >=20 >>=20 >> 2. The I-D says that the mechanism by which the MAG figures out that >> a new bi-directional tunnel is needed to be established (and a new >> prefix obtained) is out of scope. In certain networks you are >> obtaining this information from L2 and is used by the MAG. Current >=20 > Correct. >=20 >> RFC5213 lacks the ability by which an MN (which is already attached >> via an interface) can request dynamically a new prefix to be >> assigned to it for the same interface. The connection ID would be >> useful if we were to also specify how the MN can request an >> additional prefix via an interface that is already attached and has >> been assigned a prefix from a MAG/LMA pair. >> It might be useful to explain how L2s can provide such indications >> in an >> appendix. >=20 > Good point. We'll add this. >=20 >=20 >>=20 >> 3. In the case of HO the target MAG will not be aware of the CID >> unless there a context transfer mechanism between the MAGs. Please >> note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes >> context transfer capability between MAGs. >=20 > I'll have a look at this. >=20 >>=20 >> 4. If each PDN bearer is assigned a unique prefix, can you not use the >> HNP assigned as the CID? >=20 > Actually, this would be the clean solution. The problem is that is the > MN has multiple mobility sessions to the same service, the target MAG > (after a handover) does not necessarily know which of those sessions > the MN wants to use and in which order. So the assumption is that only a selective set of mobility sessions would b= e activated when the MN does a HO to a new MAG? > Once the MN reattaches to MAG, > which initiates the PBU/PBA exchange, there is no prefix information > available from the MN side yet.. however, most probably the L2 has > some additional information that the MAG and the LMA can use to make > the distinction. We do not really define what this L2 information is > and how to retrieve it, but still we need a mechanism to transfer that > around and take into account when doing BC lookups. >=20 Okay... Obviously this will require the ability by which the MN can inform the MAG about which mobility sessions to activate. If it is essentially information that is being delivered at L2 and used by the MAG to trigger th= e mobility sessions, it is still conformant to the PMIP6 protocol design principle which limits (or actually forbids) signaling between the MN and MAG. Based on the Connection ID in the PBU, the LMA would respond with the approriate HNP which is in the BCE. I think this extension is something we can discuss at the WG meeting in Stockholm. -Raj >>=20 >> I do agree with the need to support the ability by which multiple >> mobility sessions to the same LMA (via the same MAG) from a single >> interface is needed. This is applicable in EPC and other networks >> which use PMIP6. >>=20 >> -Raj >=20 > Cheers, > Jouni >=20 >=20 >=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From behcetsarikaya@yahoo.com Thu Jul 16 13:50:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CDC428C0E1 for ; Thu, 16 Jul 2009 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS3p44ihBzc6 for ; Thu, 16 Jul 2009 13:50:50 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 0F0973A67F3 for ; Thu, 16 Jul 2009 13:50:49 -0700 (PDT) Received: from [68.142.230.28] by n7.bullet.re3.yahoo.com with NNFMP; 16 Jul 2009 20:51:20 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 16 Jul 2009 20:51:20 -0000 Received: from [67.195.9.111] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 16 Jul 2009 20:51:20 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 16 Jul 2009 20:51:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 93158.40164.bm@omp115.mail.gq1.yahoo.com Received: (qmail 67970 invoked by uid 60001); 16 Jul 2009 20:51:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247777479; bh=TXJdCU/mpQNQ+CECr9lblmFWbKpR0un+yDqQ3KtLAd0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=16OOMzYYB2dS40zTF58t7qaiLAm5ZFGQGSQvs77eXxx8iHNdaofHxpHW5Av/dQa/qdfYT8NS+44KSWTnOjVZWidseAW77R749J83BrKx09flbOdMS6BcxvnieEDVId7+kEWLUn7BpS1ytJl8xHwWAlq20BAvWZX+xx49PPXnlnk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mWdse7tGpgbp0Bu8D8zxAcaONhFtLtwjEU/Q+b4K8ZLN65uBmXOs9K2I3T991/vrxjR/2u3ltnjp+YOJzgQjXX9YWY7SLao5TykZ17c2u/4OIriejv7bLeaehAnXxVnhOr1H3B7ZJZTcogQR5re0pEyuFajbPJhSemVnAokVu0M=; Message-ID: <904646.67815.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: KMy6heMVM1kkEnqCo8805CaTJAuBkBEcWzCGXcOWHdqcaUABn92O7eml9ZINyjV.K0H8w0_da1QUEHXTKCUnCGXcpqA_j6_EJhGBLSzGTMFvSunvSqw0uhLnULlQ3DqIK..dtYSxvJri7IgHw8dQJScUpJ38isE5rF3npR6Z.ZBESsnUjcwDPs8bctogU4I11gtERkwh1sik48sMvTVHWfD07.aCSc5CuHOVS6U2TWF3mFQlZ4qZu2RE11SEkU6dJ85LjP3jdlgvDnHNLtw7sfahqYxaHc6_vlRqYWmcUj.busxQTAfdpA16drtWPgNSYdGyfNaUPJ.JlwqEBTdP0D0- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 16 Jul 2009 13:51:19 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 References: Date: Thu, 16 Jul 2009 13:51:19 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 20:50:51 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: "Basavaraj.Patil@nokia.co= m" =0A> To: sarikaya@ieee.org; netext@ietf.org= =0A> Sent: Thursday, July 16, 2009 3:17:05 PM=0A> Subject: Re: [netext] Com= ments on I-D: draft-wolfner-netext-pmip6-connid-00=0A> =0A> =0A> Inline:=0A= > =0A> =0A> On 7/16/09 9:42 AM, "ext Behcet Sarikaya" wrote:=0A> =0A> > =0A= > > =0A> > Hi Raj,=0A> > =A0 It seems to me that you are talking about pref= ix management.=0A> =0A> Not really. =0A> The concept of a connection identi= fier is different from prefix management.=0A> The connid I-D is proposing a= solution which enables the establishment of=0A> multiple mobility sessions= via the same MAG/LMA pair. =0AEach of the mobility=0A> sessions is assigne= d an HNP.=0A=0AFirst of all let's clarify this as HNPs.=0A=0A=A0But the con= cept of connection ID is different=0A> from prefix management.=0A=0AThe way= draft-wolfner-netext-pmip6-connid-00 currently presents it, yes. =0A=0ABut= as per your interpretation, this is basically treating as MN like many MNs= for which requests will be made to the prefix management at the LMA. =0A= =0AIt makes it more important to have manage prefixes, I think. =0A=0A=0ARe= gards,=0A=0ABehcet=0A=0A=0A From vijay@wichorus.com Thu Jul 16 17:22:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF3A3A6A85 for ; Thu, 16 Jul 2009 17:22:12 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWuJylO6YA6E for ; Thu, 16 Jul 2009 17:22:11 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id A295A3A69EA for ; Thu, 16 Jul 2009 17:22:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2009 20:22:45 -0400 Message-ID: In-Reply-To: <4A5CD715.4060503@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Draft NETEXT2 BOF agenda for comments Thread-Index: AcoEtjHsZOMJMk++RYi2lHQf+hrGHgBvjaEg References: <4A5CD715.4060503@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , Cc: netext@ietf.org Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 00:22:12 -0000 Hi Marcelo, Can we see the list of "types of solutions" on the mailing list much = before the meeting? For example, I would like to know if this list = contains the context transfer solution being standardized in the MIPSHOP = WG between two MAGs. This enables a lot of extensions that under the = scope of NETEXT2 BOF. And it would avoid the need for signaling from the = MN is (L2 or L3) in many cases. Vijay=20 > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Tuesday, July 14, 2009 12:06 PM > To: Basavaraj.Patil@nokia.com > Cc: netext@ietf.org > Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >=20 > that would make sense, wouldn't it? >=20 > more seriously, i think the agenda is much less ambitious than that. >=20 > The idea of the presentation of the types of solutions is to=20 > provide an=20 > overview of the type of solutions that can be envisioned, so people=20 > understand what is on the table. >=20 > The goal of that presentation is by no mean select one of them or to=20 > figure out if one is better (in any sense) to another one.=20 > Just to have=20 > a full picture of what can be done. Initially, i had assigned=20 > 10 min for=20 > this. We have expanded it, in case soem disucssion raises (in=20 > particular, i can expect some people adding additional details to the=20 > different approaches presented). >=20 > Then we would move to the requirements. This will include the=20 > disucssion=20 > of what are the requirements and why these are reasonable. I=20 > am doubtful=20 > we will be able to move beyond that point. >=20 > Of course the next step would be to contrast the solutions with the=20 > requirements and pick one approach. I don't think we will get that=20 > far... am i too pessimistic? >=20 > This is the rationale behind the proposed agenda... sounds better? >=20 > Regards, marcelo >=20 >=20 >=20 > Basavaraj.Patil@nokia.com escribi=F3: > > Hi Marcelo, > > > > I am wondering if we should analyse requirements prior to discussing > > solution approaches. If we were to follow a structured=20 > approach we would > > have the sequence of problem statement, requirements and=20 > then solutions. > > > > -Raj > > > > > > On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: > > > > =20 > >> Hi, > >> > >> We are proposing the following agenda for the meeting. > >> Comments are welcome. > >> > >> ------------------------------------------------------- > >> NETEXT2 BOF > >> Meeting agenda > >> > >> TUESDAY, July 28, 2009 > >> 1300-1500 Afternoon Session I > >> ------------------------------------------------------- > >> 1. Blue sheets, scribe, agenda bashing > >> Chairs - 5 min > >> > >> 2. Problem scope > >> Jonne & Marcelo - 20 min > >> > >> 3. Overview of types of solutions > >> Julien & Suresh - 30 min > >> > >> 4. Requirements > >> Raj & Rajeev - 50 min > >> > >> 5. Next steps > >> ADs - 15 min > >> ------------------------------------------------------- > >> > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> =20 > > > > > > =20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From Mohana.Jeyatharan@sg.panasonic.com Thu Jul 16 17:57:50 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCDE28C23A for ; Thu, 16 Jul 2009 17:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e4eBQh3MBGK for ; Thu, 16 Jul 2009 17:57:49 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 7BFAD28C26C for ; Thu, 16 Jul 2009 17:57:48 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id n6H0wJrS001159; Fri, 17 Jul 2009 09:58:19 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n6H0wJ318159; Fri, 17 Jul 2009 09:58:19 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 08:55:29 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0373A0F3@pslexc01.psl.local> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Draft NETEXT2 BOF agenda for comments Thread-Index: AcoEtjHsZOMJMk++RYi2lHQf+hrGHgBvjaEgAAEi1vA= From: "Mohana Jeyatharan" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , Cc: netext@ietf.org Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 00:57:50 -0000 Hi Marcelo, Adding on to what Vijay has highlighted, in the solution space = discussion in Netext BOF2=20 (1)Will there be discussions on soultions that only use L2 modification,=20 solutions that use L3 modification,=20 solutions that use L2 and L3 modifications. (2)Will there be reference to published IDs in this area(PMIP inter = access technology handoff and PMIP multihoming) when solution space is = presented. I think already many IDs are there, so refernce to those IDs will be = good. Because currently, not very clear what is going to be discussed under = the categories outlined. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf > Of Vijay Devarapalli > Sent: Friday, July 17, 2009 8:23 AM > To: marcelo bagnulo braun; Basavaraj.Patil@nokia.com > Cc: netext@ietf.org > Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >=20 > Hi Marcelo, >=20 > Can we see the list of "types of solutions" on the mailing list much > before the meeting? For example, I would like to know if this list > contains the context transfer solution being standardized in the = MIPSHOP > WG between two MAGs. This enables a lot of extensions that under the = scope > of NETEXT2 BOF. And it would avoid the need for signaling from the MN = is > (L2 or L3) in many cases. >=20 > Vijay >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org > > [mailto:netext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > > Sent: Tuesday, July 14, 2009 12:06 PM > > To: Basavaraj.Patil@nokia.com > > Cc: netext@ietf.org > > Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments > > > > that would make sense, wouldn't it? > > > > more seriously, i think the agenda is much less ambitious than that. > > > > The idea of the presentation of the types of solutions is to > > provide an > > overview of the type of solutions that can be envisioned, so people > > understand what is on the table. > > > > The goal of that presentation is by no mean select one of them or to > > figure out if one is better (in any sense) to another one. > > Just to have > > a full picture of what can be done. Initially, i had assigned > > 10 min for > > this. We have expanded it, in case soem disucssion raises (in > > particular, i can expect some people adding additional details to = the > > different approaches presented). > > > > Then we would move to the requirements. This will include the > > disucssion > > of what are the requirements and why these are reasonable. I > > am doubtful > > we will be able to move beyond that point. > > > > Of course the next step would be to contrast the solutions with the > > requirements and pick one approach. I don't think we will get that > > far... am i too pessimistic? > > > > This is the rationale behind the proposed agenda... sounds better? > > > > Regards, marcelo > > > > > > > > Basavaraj.Patil@nokia.com escribi=F3: > > > Hi Marcelo, > > > > > > I am wondering if we should analyse requirements prior to = discussing > > > solution approaches. If we were to follow a structured > > approach we would > > > have the sequence of problem statement, requirements and > > then solutions. > > > > > > -Raj > > > > > > > > > On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: > > > > > > > > >> Hi, > > >> > > >> We are proposing the following agenda for the meeting. > > >> Comments are welcome. > > >> > > >> ------------------------------------------------------- > > >> NETEXT2 BOF > > >> Meeting agenda > > >> > > >> TUESDAY, July 28, 2009 > > >> 1300-1500 Afternoon Session I > > >> ------------------------------------------------------- > > >> 1. Blue sheets, scribe, agenda bashing > > >> Chairs - 5 min > > >> > > >> 2. Problem scope > > >> Jonne & Marcelo - 20 min > > >> > > >> 3. Overview of types of solutions > > >> Julien & Suresh - 30 min > > >> > > >> 4. Requirements > > >> Raj & Rajeev - 50 min > > >> > > >> 5. Next steps > > >> ADs - 15 min > > >> ------------------------------------------------------- > > >> > > >> > > >> _______________________________________________ > > >> netext mailing list > > >> netext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netext > > >> > > > > > > > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From w52006@huawei.com Thu Jul 16 18:50:48 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B1B28C28A for ; Thu, 16 Jul 2009 18:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8L2MYLB162S for ; Thu, 16 Jul 2009 18:50:47 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 98A4E28C278 for ; Thu, 16 Jul 2009 18:50:47 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMW00DX4L5A59@szxga03-in.huawei.com> for netext@ietf.org; Fri, 17 Jul 2009 09:51:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMW001RHL5ATE@szxga03-in.huawei.com> for netext@ietf.org; Fri, 17 Jul 2009 09:51:10 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMW00432L5978@szxml06-in.huawei.com> for netext@ietf.org; Fri, 17 Jul 2009 09:51:10 +0800 (CST) Date: Fri, 17 Jul 2009 09:51:09 +0800 From: Yungui Wang In-reply-to: To: Basavaraj.Patil@nokia.com Message-id: <004401ca0681$0ecd8be0$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoFmAfybpSoZyuQD0qJI1elB6tK3gA6EObQ Cc: netext@ietf.org Subject: Re: [netext] Review of I-D: draft-wang-netext-trace-control-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 01:50:48 -0000 Hello Thanks for your comments. Please see inline... > > IMO, tracing of a mobility session by an external network > manager or similar entity can be done without any changes to > the PMIP6 protocol itself. Each > PMIP6 session is uniquely identified by the MN-ID/HNP assigned to it. Of course, the out of band signaling can be used by network manager to trace per-MN mobility session, however the network manger can not keep track of MN's location and also can not perceive when the Per MN's mobility session is created or to which LMA the MN is registered. Therefore it is hard to trace per MN mobility session on demand or in real time. > > I realize that regulatory requirements may require the > ability to trace a mobility session on a demand basis. But > this can be accomplished without necessarily changing the > protocol itself. Tracing the sessions of a specific MN > (identified by an MN-ID) can be controlled at the LMA. > The difficulty to ask LMA to control tracing per MN's mobility session is LMA does not know which MN's mobility session needs to be traced and what trace parameters associated with per MN's mobility session is. Therefore what LMA can do is to record and report all the MN's mobility session to the network manager. In many cases, it is not necessary to do that. Because it costs too much to trace everything and report everying. What do you think of it? B.R. Yungui From marcelo@it.uc3m.es Thu Jul 16 23:35:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55623A683B for ; Thu, 16 Jul 2009 23:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WvBblLWQ1Gl for ; Thu, 16 Jul 2009 23:35:02 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 67D903A6359 for ; Thu, 16 Jul 2009 23:35:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (8.pool85-53-137.dynamic.orange.es [85.53.137.8]) by smtp03.uc3m.es (Postfix) with ESMTP id 21910730F69; Fri, 17 Jul 2009 08:34:10 +0200 (CEST) Message-ID: <4A601B61.80604@it.uc3m.es> Date: Fri, 17 Jul 2009 08:34:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Mohana Jeyatharan References: <5F09D220B62F79418461A978CA0921BD0373A0F3@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD0373A0F3@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16768.004 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 06:35:03 -0000 Mohana Jeyatharan escribió: > Hi Marcelo, > > Adding on to what Vijay has highlighted, in the solution space discussion in Netext BOF2 > (1)Will there be discussions on > soultions that only use L2 modification, > solutions that use L3 modification, > solutions that use L2 and L3 modifications. > correct > (2)Will there be reference to published IDs in this area(PMIP inter access technology handoff and PMIP multihoming) when solution space is presented. > I think already many IDs are there, so refernce to those IDs will be good. > > maybe some references to draft can be incldued as examples, but this is up to presenters. Regards, marcelo > Because currently, not very clear what is going to be discussed under the categories outlined. > > BR, > Mohana > > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >> Of Vijay Devarapalli >> Sent: Friday, July 17, 2009 8:23 AM >> To: marcelo bagnulo braun; Basavaraj.Patil@nokia.com >> Cc: netext@ietf.org >> Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >> >> Hi Marcelo, >> >> Can we see the list of "types of solutions" on the mailing list much >> before the meeting? For example, I would like to know if this list >> contains the context transfer solution being standardized in the MIPSHOP >> WG between two MAGs. This enables a lot of extensions that under the scope >> of NETEXT2 BOF. And it would avoid the need for signaling from the MN is >> (L2 or L3) in many cases. >> >> Vijay >> >> >>> -----Original Message----- >>> From: netext-bounces@ietf.org >>> [mailto:netext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >>> Sent: Tuesday, July 14, 2009 12:06 PM >>> To: Basavaraj.Patil@nokia.com >>> Cc: netext@ietf.org >>> Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >>> >>> that would make sense, wouldn't it? >>> >>> more seriously, i think the agenda is much less ambitious than that. >>> >>> The idea of the presentation of the types of solutions is to >>> provide an >>> overview of the type of solutions that can be envisioned, so people >>> understand what is on the table. >>> >>> The goal of that presentation is by no mean select one of them or to >>> figure out if one is better (in any sense) to another one. >>> Just to have >>> a full picture of what can be done. Initially, i had assigned >>> 10 min for >>> this. We have expanded it, in case soem disucssion raises (in >>> particular, i can expect some people adding additional details to the >>> different approaches presented). >>> >>> Then we would move to the requirements. This will include the >>> disucssion >>> of what are the requirements and why these are reasonable. I >>> am doubtful >>> we will be able to move beyond that point. >>> >>> Of course the next step would be to contrast the solutions with the >>> requirements and pick one approach. I don't think we will get that >>> far... am i too pessimistic? >>> >>> This is the rationale behind the proposed agenda... sounds better? >>> >>> Regards, marcelo >>> >>> >>> >>> Basavaraj.Patil@nokia.com escribió: >>> >>>> Hi Marcelo, >>>> >>>> I am wondering if we should analyse requirements prior to discussing >>>> solution approaches. If we were to follow a structured >>>> >>> approach we would >>> >>>> have the sequence of problem statement, requirements and >>>> >>> then solutions. >>> >>>> -Raj >>>> >>>> >>>> On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> We are proposing the following agenda for the meeting. >>>>> Comments are welcome. >>>>> >>>>> ------------------------------------------------------- >>>>> NETEXT2 BOF >>>>> Meeting agenda >>>>> >>>>> TUESDAY, July 28, 2009 >>>>> 1300-1500 Afternoon Session I >>>>> ------------------------------------------------------- >>>>> 1. Blue sheets, scribe, agenda bashing >>>>> Chairs - 5 min >>>>> >>>>> 2. Problem scope >>>>> Jonne & Marcelo - 20 min >>>>> >>>>> 3. Overview of types of solutions >>>>> Julien & Suresh - 30 min >>>>> >>>>> 4. Requirements >>>>> Raj & Rajeev - 50 min >>>>> >>>>> 5. Next steps >>>>> ADs - 15 min >>>>> ------------------------------------------------------- >>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > From yokota@kddilabs.jp Fri Jul 17 00:19:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A31C3A6981 for ; Fri, 17 Jul 2009 00:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAlLdkHLS1Jn for ; Fri, 17 Jul 2009 00:19:44 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id DC1713A6CF4 for ; Fri, 17 Jul 2009 00:19:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 58CE0EC8E1; Fri, 17 Jul 2009 16:19:45 +0900 (JST) Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6888AEC8E2; Fri, 17 Jul 2009 16:19:44 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 279F71BFFB; Fri, 17 Jul 2009 16:15:57 +0900 (JST) Message-ID: <4A602602.9050503@kddilabs.jp> Date: Fri, 17 Jul 2009 16:19:30 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: marcelo bagnulo braun References: <5F09D220B62F79418461A978CA0921BD0373A0F3@pslexc01.psl.local> <4A601B61.80604@it.uc3m.es> In-Reply-To: <4A601B61.80604@it.uc3m.es> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: netext@ietf.org, Mohana Jeyatharan , Basavaraj.Patil@nokia.com Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 07:19:45 -0000 Hi Marcelo, Mohana and all, marcelo bagnulo braun wrote: > Mohana Jeyatharan escribio': >> Hi Marcelo, >> >> Adding on to what Vijay has highlighted, in the solution space >> discussion in Netext BOF2 (1)Will there be discussions on >> soultions that only use L2 modification, solutions that use L3 >> modification, solutions that use L2 and L3 modifications. >> > correct > >> (2)Will there be reference to published IDs in this area(PMIP inter >> access technology handoff and PMIP multihoming) when solution space >> is presented. >> I think already many IDs are there, so refernce to those IDs will be >> good. >> >> > > maybe some references to draft can be incldued as examples, but this is > up to presenters. Before going to the solutions references, there is a PS draft for the inter access technology handoff... I'm not sure if this topic is included in the agenda, but that should also be referred to and hopefully captured as well to align our understanding and goal. Regards, -- Hidetoshi > Regards, marcelo > > >> Because currently, not very clear what is going to be discussed under >> the categories outlined. >> >> BR, >> Mohana >> >> >> >>> -----Original Message----- >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >>> Of Vijay Devarapalli >>> Sent: Friday, July 17, 2009 8:23 AM >>> To: marcelo bagnulo braun; Basavaraj.Patil@nokia.com >>> Cc: netext@ietf.org >>> Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >>> >>> Hi Marcelo, >>> >>> Can we see the list of "types of solutions" on the mailing list much >>> before the meeting? For example, I would like to know if this list >>> contains the context transfer solution being standardized in the MIPSHOP >>> WG between two MAGs. This enables a lot of extensions that under the >>> scope >>> of NETEXT2 BOF. And it would avoid the need for signaling from the MN is >>> (L2 or L3) in many cases. >>> >>> Vijay >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org >>>> [mailto:netext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >>>> Sent: Tuesday, July 14, 2009 12:06 PM >>>> To: Basavaraj.Patil@nokia.com >>>> Cc: netext@ietf.org >>>> Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >>>> >>>> that would make sense, wouldn't it? >>>> >>>> more seriously, i think the agenda is much less ambitious than that. >>>> >>>> The idea of the presentation of the types of solutions is to >>>> provide an >>>> overview of the type of solutions that can be envisioned, so people >>>> understand what is on the table. >>>> >>>> The goal of that presentation is by no mean select one of them or to >>>> figure out if one is better (in any sense) to another one. >>>> Just to have >>>> a full picture of what can be done. Initially, i had assigned >>>> 10 min for >>>> this. We have expanded it, in case soem disucssion raises (in >>>> particular, i can expect some people adding additional details to the >>>> different approaches presented). >>>> >>>> Then we would move to the requirements. This will include the >>>> disucssion >>>> of what are the requirements and why these are reasonable. I >>>> am doubtful >>>> we will be able to move beyond that point. >>>> >>>> Of course the next step would be to contrast the solutions with the >>>> requirements and pick one approach. I don't think we will get that >>>> far... am i too pessimistic? >>>> >>>> This is the rationale behind the proposed agenda... sounds better? >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> Basavaraj.Patil@nokia.com escribio': >>>> >>>>> Hi Marcelo, >>>>> >>>>> I am wondering if we should analyse requirements prior to discussing >>>>> solution approaches. If we were to follow a structured >>>>> >>>> approach we would >>>> >>>>> have the sequence of problem statement, requirements and >>>>> >>>> then solutions. >>>> >>>>> -Raj >>>>> >>>>> >>>>> On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> We are proposing the following agenda for the meeting. >>>>>> Comments are welcome. >>>>>> >>>>>> ------------------------------------------------------- >>>>>> NETEXT2 BOF >>>>>> Meeting agenda >>>>>> >>>>>> TUESDAY, July 28, 2009 >>>>>> 1300-1500 Afternoon Session I >>>>>> ------------------------------------------------------- >>>>>> 1. Blue sheets, scribe, agenda bashing >>>>>> Chairs - 5 min >>>>>> >>>>>> 2. Problem scope >>>>>> Jonne & Marcelo - 20 min >>>>>> >>>>>> 3. Overview of types of solutions >>>>>> Julien & Suresh - 30 min >>>>>> >>>>>> 4. Requirements >>>>>> Raj & Rajeev - 50 min >>>>>> >>>>>> 5. Next steps >>>>>> ADs - 15 min >>>>>> ------------------------------------------------------- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > From marcelo@it.uc3m.es Fri Jul 17 00:27:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A5C3A68DD for ; Fri, 17 Jul 2009 00:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5O5uDpdTnK5 for ; Fri, 17 Jul 2009 00:27:34 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 076553A6981 for ; Fri, 17 Jul 2009 00:27:33 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (8.pool85-53-137.dynamic.orange.es [85.53.137.8]) by smtp02.uc3m.es (Postfix) with ESMTP id B2FEA6BA5B2; Fri, 17 Jul 2009 08:33:24 +0200 (CEST) Message-ID: <4A601B35.2040101@it.uc3m.es> Date: Fri, 17 Jul 2009 08:33:25 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Vijay Devarapalli References: <4A5CD715.4060503@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16768.004 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 07:27:35 -0000 Hi Vijay, Not answering you question at this point, but just in order to describe a bit more in detail what is the goal of such presentation. The idea of the solution overview presentation is to include every possible approach that can be used to provide the support of multiple interfaces (of potentially different technologies) to a network that is running PMIP. The only requirement at this point is that the final result must still use PMIP for the single interface case like it is currently supported. All possible approaches are then presented ( a very high level description of course). Nothing is ruled out of such presentation. this is just to give background of the possible ways to tackle the problem and to make the point that every possible approach is on the table for consideration at this point. For this reason i was expecting this presentation not to generate much discussion (yes, right...) since it was expected to be all inclusive. Of course, the different solutions have veru different properties and the meet a different set of requirements. So, the goal was to have a discussion about what requirements we consider need to be imposed to the solution. this is pretty much what will decide what way to go. And this is the next presentation, where the discussion seems more likely, i.e. the requirement presentation. would that approach make sense to you? Regards, marcelo Vijay Devarapalli escribió: > Hi Marcelo, > > Can we see the list of "types of solutions" on the mailing list much before the meeting? For example, I would like to know if this list contains the context transfer solution being standardized in the MIPSHOP WG between two MAGs. This enables a lot of extensions that under the scope of NETEXT2 BOF. And it would avoid the need for signaling from the MN is (L2 or L3) in many cases. > > Vijay > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Tuesday, July 14, 2009 12:06 PM >> To: Basavaraj.Patil@nokia.com >> Cc: netext@ietf.org >> Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >> >> that would make sense, wouldn't it? >> >> more seriously, i think the agenda is much less ambitious than that. >> >> The idea of the presentation of the types of solutions is to >> provide an >> overview of the type of solutions that can be envisioned, so people >> understand what is on the table. >> >> The goal of that presentation is by no mean select one of them or to >> figure out if one is better (in any sense) to another one. >> Just to have >> a full picture of what can be done. Initially, i had assigned >> 10 min for >> this. We have expanded it, in case soem disucssion raises (in >> particular, i can expect some people adding additional details to the >> different approaches presented). >> >> Then we would move to the requirements. This will include the >> disucssion >> of what are the requirements and why these are reasonable. I >> am doubtful >> we will be able to move beyond that point. >> >> Of course the next step would be to contrast the solutions with the >> requirements and pick one approach. I don't think we will get that >> far... am i too pessimistic? >> >> This is the rationale behind the proposed agenda... sounds better? >> >> Regards, marcelo >> >> >> >> Basavaraj.Patil@nokia.com escribió: >> >>> Hi Marcelo, >>> >>> I am wondering if we should analyse requirements prior to discussing >>> solution approaches. If we were to follow a structured >>> >> approach we would >> >>> have the sequence of problem statement, requirements and >>> >> then solutions. >> >>> -Raj >>> >>> >>> On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: >>> >>> >>> >>>> Hi, >>>> >>>> We are proposing the following agenda for the meeting. >>>> Comments are welcome. >>>> >>>> ------------------------------------------------------- >>>> NETEXT2 BOF >>>> Meeting agenda >>>> >>>> TUESDAY, July 28, 2009 >>>> 1300-1500 Afternoon Session I >>>> ------------------------------------------------------- >>>> 1. Blue sheets, scribe, agenda bashing >>>> Chairs - 5 min >>>> >>>> 2. Problem scope >>>> Jonne & Marcelo - 20 min >>>> >>>> 3. Overview of types of solutions >>>> Julien & Suresh - 30 min >>>> >>>> 4. Requirements >>>> Raj & Rajeev - 50 min >>>> >>>> 5. Next steps >>>> ADs - 15 min >>>> ------------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > > From yokota@kddilabs.jp Fri Jul 17 00:28:36 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EF33A6981 for ; Fri, 17 Jul 2009 00:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cd05q8xk+1i for ; Fri, 17 Jul 2009 00:28:35 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 939363A68DD for ; Fri, 17 Jul 2009 00:28:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 39078EC88F; Fri, 17 Jul 2009 16:29:07 +0900 (JST) Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id 1A85EEC8AF; Fri, 17 Jul 2009 16:29:05 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 2F1441D230; Fri, 17 Jul 2009 16:25:17 +0900 (JST) Message-ID: <4A602834.4030906@kddilabs.jp> Date: Fri, 17 Jul 2009 16:28:52 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Vijay Devarapalli References: <4A5CD715.4060503@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 07:28:36 -0000 Hi Marcelo and Vijay, Vijay Devarapalli wrote: > Hi Marcelo, > > Can we see the list of "types of solutions" on the mailing list much before the meeting? For example, I would like to know if this list contains the context transfer solution being standardized in the MIPSHOP WG between two MAGs. This enables a lot of extensions that under the scope of NETEXT2 BOF. And it would avoid the need for signaling from the MN is (L2 or L3) in many cases. That is a good point. If the network can help provide necessary information, that will save some protocol extensions on the client side, which would also fit the purpose of the network-based mobility management. I think it is a good idea to distinguish the situations where the context transfer type of mechanism is available or not. Regards, -- Hidetoshi > Vijay > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Tuesday, July 14, 2009 12:06 PM >> To: Basavaraj.Patil@nokia.com >> Cc: netext@ietf.org >> Subject: Re: [netext] Draft NETEXT2 BOF agenda for comments >> >> that would make sense, wouldn't it? >> >> more seriously, i think the agenda is much less ambitious than that. >> >> The idea of the presentation of the types of solutions is to >> provide an >> overview of the type of solutions that can be envisioned, so people >> understand what is on the table. >> >> The goal of that presentation is by no mean select one of them or to >> figure out if one is better (in any sense) to another one. >> Just to have >> a full picture of what can be done. Initially, i had assigned >> 10 min for >> this. We have expanded it, in case soem disucssion raises (in >> particular, i can expect some people adding additional details to the >> different approaches presented). >> >> Then we would move to the requirements. This will include the >> disucssion >> of what are the requirements and why these are reasonable. I >> am doubtful >> we will be able to move beyond that point. >> >> Of course the next step would be to contrast the solutions with the >> requirements and pick one approach. I don't think we will get that >> far... am i too pessimistic? >> >> This is the rationale behind the proposed agenda... sounds better? >> >> Regards, marcelo >> >> >> >> Basavaraj.Patil@nokia.com escribio': >>> Hi Marcelo, >>> >>> I am wondering if we should analyse requirements prior to discussing >>> solution approaches. If we were to follow a structured >> approach we would >>> have the sequence of problem statement, requirements and >> then solutions. >>> -Raj >>> >>> >>> On 7/14/09 2:30 AM, "Marcelo Bagnulo" wrote: >>> >>> >>>> Hi, >>>> >>>> We are proposing the following agenda for the meeting. >>>> Comments are welcome. >>>> >>>> ------------------------------------------------------- >>>> NETEXT2 BOF >>>> Meeting agenda >>>> >>>> TUESDAY, July 28, 2009 >>>> 1300-1500 Afternoon Session I >>>> ------------------------------------------------------- >>>> 1. Blue sheets, scribe, agenda bashing >>>> Chairs - 5 min >>>> >>>> 2. Problem scope >>>> Jonne & Marcelo - 20 min >>>> >>>> 3. Overview of types of solutions >>>> Julien & Suresh - 30 min >>>> >>>> 4. Requirements >>>> Raj & Rajeev - 50 min >>>> >>>> 5. Next steps >>>> ADs - 15 min >>>> ------------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > From huimin.cmcc@gmail.com Fri Jul 17 05:02:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364F328C2C5 for ; Fri, 17 Jul 2009 05:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG-duDnXwsGo for ; Fri, 17 Jul 2009 05:02:56 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 538B028C2C4 for ; Fri, 17 Jul 2009 05:02:56 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so457486wah.5 for ; Fri, 17 Jul 2009 05:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8bknuYL4P8HuGADnHwGRP2U95K+A4ZXk9zpkM98Zqn4=; b=HKRTiUiGsPCtRuebbNbusdA12CR1Mc/8v4bO8GbphQxIDFV506qnJwhCMPe+u5dD3A 9ab0Ov2fO1+Xsv11XECr42u2xtIuN8iyFgT+H1s6Y7CZSG6unc8Joyac+cq7OlO2+GOZ AUyhZ+k0YRC6HBW8EUUNEHzLOkUrY4sPx5q/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FCcpCpRPfX8RZ3Nb5u/f0kBHhvno6eXSQtArmOadtR4qzF2E0OgrQ3TqHMQUxzmEDP lZviYhUFvqjMxEYOXMuzI1fZymBDaV+/jqWTR2271bTHqAzzieHeFEwgMbjvpp6njWeV CPOD8NyW+PNQnkzfHxv1uECOi+E5ndCtreM7w= MIME-Version: 1.0 Received: by 10.114.157.1 with SMTP id f1mr1493422wae.155.1247832207670; Fri, 17 Jul 2009 05:03:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2009 20:03:27 +0800 Message-ID: <5dca10d30907170503k3a0665a2y68b4ea1eddd470cf@mail.gmail.com> From: Min Hui To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Review of I-D: draft-hui-netext-service-flow-identifier X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 12:02:57 -0000 Hi Raj, Thanks for the reply, pls see my answer in line. - Hui Min 2009/7/16 : > > After reviewing the I-D draft-hui-netext-service-flow-identifier-00, I > had a few questions for the authors: > > 1. In figure 1: > =A0 - What does it mean to start a new service flow? > > As per PMIP6 when the MN attaches to a MAG as part of initial > attachment the BCE at the LMA is created and the bi-directional tunnel > between the MAG/LMA established. In the figure you show a PBU with > SFID option being sent after the MN starts a new SF. > > Can you elaborate on this statement: > "2. When a new service flow of the mobile node is started, the data > =A0 =A0 =A0packet of this service will be routed to the mobile access gat= eway, > =A0 =A0 =A0which will trigger the service flow proxy binding update" Start a new service flow means the MN send IP packet with parameters different with previous ones. The parameter used to defined a service flow is described in the "Service Flow Description Option". In this draft the PMIP6 is modified to sent PBU whenever a new service flow startes, so that the tunnel can be set for each service flow but not the interface. MAG is responsible for checking the IP packet and decide whether to send the PBU or not. > > 2. I am also not clear about what sort of control is expected to be > enabled by including an SFID in the PBU. The following sentence in the > introduction: > "Hence, the mobile access gateway can bind mobile node's each service > flow to its home network prefix, respectively. Therefore, the mobile > node's multiple service flows can be separately controlled based on > the service flow identifier." > > I am not sure what the above means. QoS, content charging, traffic control can be enabled by tunnelling service flow respectively according to SFID. > > 3. Assuming you do have granularity greater than a single tunnel > between the MAG/LMA for the MNs traffic, do you really need an SFID? > Is'nt the v6 address itself or in the case of GRE keys being used, the > GRE key sufficient in terms of an identifier? GRE key is indeed the identifier of PMIP tunnel, but the PMIP tunnel will not be per service flow basis if the SFID is lacked. That's why we need SFID. > > 4. In sec 4 : > "Assume a mobile node establishes two service flows, called SF1 and > =A0 SF2." > > Does the MN have a single HNP? Both single HNP and multiple HNP are supported. > Is the MN attached to the MAG via different interfaces? Both single interface and multiple interfaces are supported. > If not, what causes the MAG to establish separate tunnels with the LMA > for each service flow? QoS, content charging, etc. If all the service flows use single tunnel, different services cannot be treated separately. > Assuming that there is a BCE for the MN already, do you modify the > existing BCE or extend it? I think it will modify BCE. > > Obviously you are making certain assumptions about service flows and > rules at the MAG that would trigger the establishment of a unique > tunnel to handle some traffic to/from the MN. These assumptions are > missing. Can you provide references to such assumptions? Or state the > assumptions in this document itself. The assumption is that the tunnel is established for each interface of MN, and I believe the description of BCE in section 5.1 of RFC5213 shows this assumption is correct. I will state the detailed reference in the updated draft, thanks for your comment. > > Lastly, the discussion of flow-binding is part of the NetExt2 BoF at > IETF75. Hence we will not consider this I-D as part of the NetExt WG > meeting at IETF75. Ok, I see. Thanks. > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From behcetsarikaya@yahoo.com Fri Jul 17 08:14:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93713A6A8E for ; Fri, 17 Jul 2009 08:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvpEWs5w19Af for ; Fri, 17 Jul 2009 08:14:45 -0700 (PDT) Received: from n68.bullet.mail.sp1.yahoo.com (n68.bullet.mail.sp1.yahoo.com [98.136.44.44]) by core3.amsl.com (Postfix) with SMTP id E735B28C224 for ; Fri, 17 Jul 2009 08:14:11 -0700 (PDT) Received: from [69.147.84.145] by n68.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jul 2009 15:13:41 -0000 Received: from [67.195.9.81] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jul 2009 15:13:41 -0000 Received: from [67.195.9.99] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 17 Jul 2009 15:13:41 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 17 Jul 2009 15:13:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 465049.21506.bm@omp103.mail.gq1.yahoo.com Received: (qmail 55710 invoked by uid 60001); 17 Jul 2009 15:13:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247843620; bh=vh4q7xLrnT7iqyusyT/qtk0D411OcvpRNpPEy4lBgpY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OVNWwBJQ6rXVOEs6/ISWy8N2l6scM+Cm9M/0LIuWnXuBdtFjTUlTwQ8blbUtl993v+ivLE/Wg2WiCa8XuHZx9Qur2HpBAyYAoGGVhMXLjwml/oO3c2hRnbsqF7zwTykYtNFZEC9ZPS0iv03DDvn/40ptNvQ/GGM3AYNQDKZsIUU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HIphT5D3herpK7QHf5kjyie8Fv8f4CaII5SdbeSN0LvaC8Z32xfSx/xLnqMBUcR5ljZ+afSyWELzfPgkfwQrLIVXK/kDgitWBphL6H3AIIvqZSVRhm0CxcxGDkqbyE9qbOhuKlCu0u3+sCIhs0GlGAl+ggKFbw5NTREJWbYOiHA=; Message-ID: <918815.55376.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: Zfnw7R0VM1kcBKDlwE8Y9tFYuS7ST0PbrCWf7hQZ2Q82nYUe.TzM0WSOd12c1hY7qg5bBma8DwSWYxUjvbPuos9SbHDxnYhVx8njmZQ5OQ6KAWIOOvZh4Awlb97xUCMssCbVw_w5F1wICj2zKnqSnHp4yCN93d97Rntf_adsq9l6l80yZuet3z42z9Nc_A87mBLHWNAExg8MV_Ki59MRCgKq5QIQEyS.GVW6kgx5PiucHlxrmtJZmJQYzIm_2Eud.iN_0k1w_N4TGnUv613_bCk5UZX59JWbEBA_U4cPAaOZl9IlzFtYjjJ4oIjzb_02Mwu.knYWxHS5urYum5plKcs- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Fri, 17 Jul 2009 08:13:40 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 References: Date: Fri, 17 Jul 2009 08:13:40 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen , "" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 15:14:46 -0000 Hi Jouni, Raj,=0A=A0 After a little bit of reflection I started to question= this connid extension.=0A=0ARFC 5213 clearly makes it possible to assign m= ultiple unique HNPs to each MN (see Sec. 8.3). =0A=0ASo I think that the ba= se protocol already enables multiple pdp context stuff. It is upto certain = MNs to use it.=A0=0A=0AI don't think we need a standard to add things like = connid into the BCE and complicate things.=0A=0AWhat do you think?=0A=0ABeh= cet=0A=0A=0A=0A----- Original Message ----=0A> From: jouni korhonen =0A> To: "" =0A> Cc: netext@ietf.org=0A> Sent: Thursday, July 16, 2009 7:49:16 = AM=0A> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-co= nnid-00=0A> =0A> Hi Raj,=0A> =0A> Thanks for the quick review. I got some a= nswer inline.=0A> =0A> =0A> On Jul 16, 2009, at 12:33 AM, =0A> wrote:=0A> = =0A> > =0A> > =0A> > Hello,=0A> > =0A> > A few questions/comments related t= o the proposal to add a connection=0A> > identifier to the PMIP6 signaling = and BCE:=0A> > =0A> > 1. Each of the PDN bearers will have a unique prefix = assigned to it by=0A> >=A0 the LMA, right? Even though the MN-ID remains th= e same the LMA will=0A> =0A> right.=0A> =0A> >=A0 have to create multiple B= CEs for the MN. The scenario is equivalent=0A> >=A0 to the MN attaching via= different interfaces thru the same MAG/LMA=0A> >=A0 pair.=0A> =0A> To some= extent it is the same. However, the introductory text the draft scopes =0A= > the work to a single interface. Maybe there is a way to express the whole= =0A> solution independent of the number of interfaces.=0A> =0A> > =0A> > 2= .. The I-D says that the mechanism by which the MAG figures out that=0A> >= =A0 a new bi-directional tunnel is needed to be established (and a new=0A> = >=A0 prefix obtained) is out of scope. In certain networks you are=0A> >=A0= obtaining this information from L2 and is used by the MAG. Current=0A> =0A= > Correct.=0A> =0A> >=A0 RFC5213 lacks the ability by which an MN (which is= already attached=0A> >=A0 via an interface) can request dynamically a new = prefix to be=0A> >=A0 assigned to it for the same interface. The connection= ID would be=0A> >=A0 useful if we were to also specify how the MN can requ= est an=0A> >=A0 additional prefix via an interface that is already attached= and has=0A> >=A0 been assigned a prefix from a MAG/LMA pair.=0A> >=A0 It m= ight be useful to explain how L2s can provide such indications in an=0A> > = appendix.=0A> =0A> Good point. We'll add this.=0A> =0A> =0A> > =0A> > 3. In= the case of HO the target MAG will not be aware of the CID=0A> >=A0 unless= there a context transfer mechanism between the MAGs. Please=0A> >=A0 note = the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes=0A> >=A0 context t= ransfer capability between MAGs.=0A> =0A> I'll have a look at this.=0A> =0A= > > =0A> > 4. If each PDN bearer is assigned a unique prefix, can you not u= se the=0A> >=A0 HNP assigned as the CID?=0A> =0A> Actually, this would be t= he clean solution. The problem is that is the MN has =0A> multiple mobility= sessions to the same service, the target MAG (after a =0A> handover) does = not necessarily know which of those sessions the MN wants to use =0A> and i= n which order. Once the MN reattaches to MAG, which initiates the PBU/PBA = =0A> exchange, there is no prefix information available from the MN side ye= t.. =0A> however, most probably the L2 has some additional information that= the MAG and =0A> the LMA can use to make the distinction. We do not really= define what this L2 =0A> information is and how to retrieve it, but still = we need a mechanism to transfer =0A> that around and take into account when= doing BC lookups.=0A> =0A> > =0A> > I do agree with the need to support th= e ability by which multiple=0A> > mobility sessions to the same LMA (via th= e same MAG) from a single=0A> > interface is needed. This is applicable in = EPC and other networks=0A> > which use PMIP6.=0A> > =0A> > -Raj=0A> =0A> Ch= eers,=0A> =A0=A0=A0 Jouni=0A> =0A> =0A> =0A> > =0A> > _____________________= __________________________=0A> > netext mailing list=0A> > netext@ietf.org= =0A> > https://www.ietf.org/mailman/listinfo/netext=0A> =0A> ______________= _________________________________=0A> netext mailing list=0A> netext@ietf.o= rg=0A> https://www.ietf.org/mailman/listinfo/netext=0A=0A=0A=0A From Basavaraj.Patil@nokia.com Fri Jul 17 08:58:36 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFED23A67E6 for ; Fri, 17 Jul 2009 08:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWY-q2akFBPP for ; Fri, 17 Jul 2009 08:58:35 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E97513A680E for ; Fri, 17 Jul 2009 08:58:34 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6HFvxAs026789; Fri, 17 Jul 2009 18:58:00 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 18:58:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 18:57:55 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 17 Jul 2009 17:57:55 +0200 From: To: , Date: Fri, 17 Jul 2009 17:58:06 +0200 Thread-Topic: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 Thread-Index: AcoG8TsELvXsPkt7QbmAckU+eVN6hAABiRWF Message-ID: In-Reply-To: <918815.55376.qm@web111416.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2009 15:57:55.0863 (UTC) FILETIME=[5950B270:01CA06F7] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 15:58:36 -0000 Hi Behcet, It is possible to assign multiple HNPs to an MN via RFC5213. However it is not possible to request dynamically (after initial attachment and being assigned an HNP and a BCE created) a new mobility session. The LMA would essentially view a new PBU request from the MAG for the MN as being a renewal request and hence not assign a new HNP. I think it is clear (at least in the 3GPP EPC context) that it with RFC5213 it is not possible to establish multiple mobility sessions with the same LMA via a single interface. -Raj On 7/17/09 10:13 AM, "ext Behcet Sarikaya" wrote= : >=20 >=20 > Hi Jouni, Raj, > =A0 After a little bit of reflection I started to question this connid > extension. >=20 > RFC 5213 clearly makes it possible to assign multiple unique HNPs to each= MN > (see Sec. 8.3). >=20 > So I think that the base protocol already enables multiple pdp context st= uff. > It is upto certain MNs to use it.=A0 >=20 > I don't think we need a standard to add things like connid into the BCE a= nd > complicate things. >=20 > What do you think? >=20 > Behcet >=20 >=20 >=20 > ----- Original Message ---- >> From: jouni korhonen >> To: "" >> Cc: netext@ietf.org >> Sent: Thursday, July 16, 2009 7:49:16 AM >> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid= -00 >>=20 >> Hi Raj, >>=20 >> Thanks for the quick review. I got some answer inline. >>=20 >>=20 >> On Jul 16, 2009, at 12:33 AM, >> wrote: >>=20 >>>=20 >>>=20 >>> Hello, >>>=20 >>> A few questions/comments related to the proposal to add a connection >>> identifier to the PMIP6 signaling and BCE: >>>=20 >>> 1. Each of the PDN bearers will have a unique prefix assigned to it by >>> =A0 the LMA, right? Even though the MN-ID remains the same the LMA will >>=20 >> right. >>=20 >>> =A0 have to create multiple BCEs for the MN. The scenario is equivalent >>> =A0 to the MN attaching via different interfaces thru the same MAG/LMA >>> =A0 pair. >>=20 >> To some extent it is the same. However, the introductory text the draft >> scopes >> the work to a single interface. Maybe there is a way to express the whol= e >> solution independent of the number of interfaces. >>=20 >>>=20 >>> 2.. The I-D says that the mechanism by which the MAG figures out that >>> =A0 a new bi-directional tunnel is needed to be established (and a new >>> =A0 prefix obtained) is out of scope. In certain networks you are >>> =A0 obtaining this information from L2 and is used by the MAG. Current >>=20 >> Correct. >>=20 >>> =A0 RFC5213 lacks the ability by which an MN (which is already attached >>> =A0 via an interface) can request dynamically a new prefix to be >>> =A0 assigned to it for the same interface. The connection ID would be >>> =A0 useful if we were to also specify how the MN can request an >>> =A0 additional prefix via an interface that is already attached and has >>> =A0 been assigned a prefix from a MAG/LMA pair. >>> =A0 It might be useful to explain how L2s can provide such indications = in an >>> appendix. >>=20 >> Good point. We'll add this. >>=20 >>=20 >>>=20 >>> 3. In the case of HO the target MAG will not be aware of the CID >>> =A0 unless there a context transfer mechanism between the MAGs. Please >>> =A0 note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes >>> =A0 context transfer capability between MAGs. >>=20 >> I'll have a look at this. >>=20 >>>=20 >>> 4. If each PDN bearer is assigned a unique prefix, can you not use the >>> =A0 HNP assigned as the CID? >>=20 >> Actually, this would be the clean solution. The problem is that is the M= N has >> multiple mobility sessions to the same service, the target MAG (after a >> handover) does not necessarily know which of those sessions the MN wants= to >> use >> and in which order. Once the MN reattaches to MAG, which initiates the >> PBU/PBA >> exchange, there is no prefix information available from the MN side yet.= . >> however, most probably the L2 has some additional information that the M= AG >> and >> the LMA can use to make the distinction. We do not really define what th= is L2 >> information is and how to retrieve it, but still we need a mechanism to >> transfer >> that around and take into account when doing BC lookups. >>=20 >>>=20 >>> I do agree with the need to support the ability by which multiple >>> mobility sessions to the same LMA (via the same MAG) from a single >>> interface is needed. This is applicable in EPC and other networks >>> which use PMIP6. >>>=20 >>> -Raj >>=20 >> Cheers, >> =A0=A0=A0 Jouni >>=20 >>=20 >>=20 >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 >=20 >=20 > =20 >=20 From behcetsarikaya@yahoo.com Fri Jul 17 09:17:15 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAE228C1F6 for ; Fri, 17 Jul 2009 09:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UT6bGCYBHMP for ; Fri, 17 Jul 2009 09:17:14 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id C6DEF28C1A4 for ; Fri, 17 Jul 2009 09:17:14 -0700 (PDT) Received: (qmail 46612 invoked by uid 60001); 17 Jul 2009 16:17:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247847466; bh=yLY0G3+Nf5S8sztXwNRHU4+SYbuWpO3vlG2Efpdcsdw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HU7obenzy4YphgvcX29qdb9KIL8Rbe/eIrzMaZ8NwzpOUUobJCF1lHbiMD40YYtCyBUHPXN24CNtA2cbqQzRXFzjRmv9VlfOFJ0dpZHyVq++ipc2jE8IldxG602H8aV0gVbLcmb7qIZ+r/GDO/DGcIf0y2DmP7sUxKn/KWqhaos= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GP8HlgmVjzf9iN04jPKjouCCo9uUInXhImSXdaDs7dW3OVcXch6w6Fa6rXgHJANU9mDvpAPXoSlEyWzyDBuU22vOfOJPVrkGMaFD1a24T11Tv3WZmJNLlLD8+KsVeDrOCOll8vuWtPBadcpBtha/87ipCcJPZbhYbg58c4ABIwA=; Message-ID: <988600.46170.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: C3Jt50MVM1ksPuRB3p00te4d5WJsiMcSMY6S3DD_Mgu_eRykJVH.ptdUkqgN7nOETvDAnm85FAOR.WLbb9ZJbciaFDC_eT.SeWFvwkb4aFVhGA3nZqH1Nd0ZS1l0nCJtU8k75xmNXcM1hQJdrXPhlnfil9yt4QuGeWc3u7ir4zzp48_sZ86t5_kWuZzMwfQUoslQpHww0sleYGb60fACV66FChoGZkMrgEEwOh88rrTJL3l1LW5osTipqPkVz3k4WlyH5X9syTubG3S3d_cWHZcSzmGwfXkECmAVWPkpdTNHO6RkGPp7Ju8hGvI9xvGn0dszQueDOIcnqUG7NpCdfWA- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 17 Jul 2009 09:17:46 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 References: Date: Fri, 17 Jul 2009 09:17:46 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, jouni.nospam@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 16:17:15 -0000 Hi Raj, ----- Original Message ---- > From: "Basavaraj.Patil@nokia.com" > To: sarikaya@ieee.org; jouni.nospam@gmail.com > Cc: netext@ietf.org > Sent: Friday, July 17, 2009 10:58:06 AM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > > > Hi Behcet, > > It is possible to assign multiple HNPs to an MN via RFC5213. However it is > not possible to request dynamically (after initial attachment and being > assigned an HNP and a BCE created) a new mobility session. > The LMA would essentially view a new PBU request from the MAG for the MN as > being a renewal request and hence not assign a new HNP. I think it is clear > (at least in the 3GPP EPC context) that it with RFC5213 it is not possible > to establish multiple mobility sessions with the same LMA via a single > interface. Yes, I think it is clear. The question is do we want to change it? I think sending a non-renewal PBU is a big semantic change to the base protocol. I was thinking that such a thing could happen below PMIP level possibly using the other prefix. I don't know what would you say to that? Regards, Behcet From Basavaraj.Patil@nokia.com Fri Jul 17 09:35:34 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1923A6D07 for ; Fri, 17 Jul 2009 09:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iknjkhIveu9J for ; Fri, 17 Jul 2009 09:35:33 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7B42B3A6BB8 for ; Fri, 17 Jul 2009 09:35:33 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6HGZhEe019427; Fri, 17 Jul 2009 11:35:53 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 19:35:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 19:35:50 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 17 Jul 2009 18:35:49 +0200 From: To: , Date: Fri, 17 Jul 2009 18:36:02 +0200 Thread-Topic: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 Thread-Index: AcoG+iI7ZsPRIFAwT0uIILfUFf+g0AAAom7X Message-ID: In-Reply-To: <988600.46170.qm@web111414.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2009 16:35:50.0210 (UTC) FILETIME=[A4EE8220:01CA06FC] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 16:35:34 -0000 On 7/17/09 11:17 AM, "ext Behcet Sarikaya" wrote= : >=20 >=20 > Hi Raj, >=20 >=20 >=20 > ----- Original Message ---- >> From: "Basavaraj.Patil@nokia.com" >> To: sarikaya@ieee.org; jouni.nospam@gmail.com >> Cc: netext@ietf.org >> Sent: Friday, July 17, 2009 10:58:06 AM >> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid= -00 >>=20 >>=20 >> Hi Behcet, >>=20 >> It is possible to assign multiple HNPs to an MN via RFC5213. However it = is >> not possible to request dynamically (after initial attachment and being >> assigned an HNP and a BCE created) a new mobility session. >> The LMA would essentially view a new PBU request from the MAG for the MN= as >> being a renewal request and hence not assign a new HNP. I think it is cl= ear >> (at least in the 3GPP EPC context) that it with RFC5213 it is not possib= le >> to establish multiple mobility sessions with the same LMA via a single >> interface. >=20 > Yes, I think it is clear. The question is do we want to change it? Yes. Extend the capability by which the LMA is aware that the PBU is a request for establishing a new mobility session. > I think sending a non-renewal PBU is a big semantic change to the base > protocol. Not really. A PBU can indicate already whether it is a result of a HO or a renewal or the result of a new attachment via a different interface. > I was thinking that such a thing could happen below PMIP level possibly u= sing > the other prefix. I don't know what would you say to that? Not sure what you mean by "below PMIP level". Maybe you have some other ideas of how to achieve the same functionality. Also I don't understand wha= t you mean by "the other prefix". What other prefix are you refering to? When the MN requests an additional mobility session, there is no prefix assigned to it yet. -Raj=20 >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > =20 From behcetsarikaya@yahoo.com Fri Jul 17 11:35:39 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47CDC28C32A for ; Fri, 17 Jul 2009 11:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scGGbmeIaisM for ; Fri, 17 Jul 2009 11:35:38 -0700 (PDT) Received: from n58.bullet.mail.sp1.yahoo.com (n58.bullet.mail.sp1.yahoo.com [98.136.44.46]) by core3.amsl.com (Postfix) with SMTP id 7BAC228C327 for ; Fri, 17 Jul 2009 11:35:38 -0700 (PDT) Received: from [216.252.122.218] by n58.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jul 2009 18:36:10 -0000 Received: from [67.195.9.81] by t3.bullet.sp1.yahoo.com with NNFMP; 17 Jul 2009 18:36:10 -0000 Received: from [67.195.9.105] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 17 Jul 2009 18:36:10 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 17 Jul 2009 18:36:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 438673.96581.bm@omp109.mail.gq1.yahoo.com Received: (qmail 73173 invoked by uid 60001); 17 Jul 2009 18:36:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247855770; bh=tYhnjaYihG1h+4BkdAZYNFkuwBMvJVki8VWzTNVyY4c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Rc6DnuE3ry9ni6ItRsob6dmW7kkRcIrY9RRrWDElQOTVhjpC9/7d8G4+JF4uEPfF935Hk1L22gZZFAlz/m5DPUewcqVlNpI0FAHDrxbhyCDg+hD9r45nCooDqofJqhS4Mk6xxOYPJVXr9+nY7cL2f43PU+RD9d7QFltal6nujg0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YpO6YzkECzM+/2X+6MeqtuvrMB5Rz0enPwLHiIuS3v+dI2bCJaKFnulLRea9s9MBWMGwidUuOjK3ms+ximg5WXHTCpUsXZVvCKxE9pYVAKLQ6j2dNk8rMmAchYRz1MPtWvAL+j681PVoAkgtHSnT1smtMgEd3wR7CWO1Nm3Hvww=; Message-ID: <95739.51992.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: OnTMqzYVM1k5RlrvL9PEmWOzznOlciEKXzwiKsE7jJCrEsaVerjI_lAAJvwMhffzJyYBCHsfjzLCKnh9S6Wn9SoYLbqbMPlpOG0w7t7cb2DRWHvUDlJ_.gKfMsiw7VSSTNstt.pg9OqD351ZsrSFCehniGDJY_mqNuRJidZodz9EZOjLK2l2aud1bWUEEDnOcKhTqGM0jEbrjY.W99TlimpBLZZfvnML0HSwwAyRuXRE2ex89VLDINkYSy7ulr2yJvFT_fkTeHEqkPXw4AEEgVCN1ck42MtSB3FugpTFmkgb_OoTBXvjH15gSNJrHspW4cSP92ZP2GJERaMgfflST_0- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 17 Jul 2009 11:36:09 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 References: Date: Fri, 17 Jul 2009 11:36:09 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, jouni.nospam@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 18:35:39 -0000 ----- Original Message ---- > From: "Basavaraj.Patil@nokia.com" > To: sarikaya@ieee.org; jouni.nospam@gmail.com > Cc: netext@ietf.org > Sent: Friday, July 17, 2009 11:36:02 AM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > > > > > On 7/17/09 11:17 AM, "ext Behcet Sarikaya" wrote: > > > > > > > Hi Raj, > > > > > > > > ----- Original Message ---- > >> From: "Basavaraj.Patil@nokia.com" > >> To: sarikaya@ieee.org; jouni.nospam@gmail.com > >> Cc: netext@ietf.org > >> Sent: Friday, July 17, 2009 10:58:06 AM > >> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > >> > >> > >> Hi Behcet, > >> > >> It is possible to assign multiple HNPs to an MN via RFC5213. However it is > >> not possible to request dynamically (after initial attachment and being > >> assigned an HNP and a BCE created) a new mobility session. > >> The LMA would essentially view a new PBU request from the MAG for the MN as > >> being a renewal request and hence not assign a new HNP. I think it is clear > >> (at least in the 3GPP EPC context) that it with RFC5213 it is not possible > >> to establish multiple mobility sessions with the same LMA via a single > >> interface. > > > > Yes, I think it is clear. The question is do we want to change it? > > Yes. Extend the capability by which the LMA is aware that the PBU is a > request for establishing a new mobility session. That's what I was referring to as a big semantic change to PBU/PBA. > > > I think sending a non-renewal PBU is a big semantic change to the base > > protocol. > > Not really. A PBU can indicate already whether it is a result of a HO or a > renewal or the result of a new attachment via a different interface. > > > I was thinking that such a thing could happen below PMIP level possibly using > > the other prefix. I don't know what would you say to that? > > Not sure what you mean by "below PMIP level". Maybe you have some other > ideas of how to achieve the same functionality. Also I don't understand what > you mean by "the other prefix". What other prefix are you refering to? When > the MN requests an additional mobility session, there is no prefix assigned > to it yet. PBA sends more than one prefixes to MAG and MAG advertizes them. What does MN do? I think hosts create addresses for each prefix they receive. So my suggestion was to use a different address for each PDP connection. In fact you need a single address to access the Internet. More than one addresses create problems that MIF WG is trying to address. Regards, Behcet From jouni.nospam@gmail.com Sun Jul 19 13:37:09 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973B13A6CB1 for ; Sun, 19 Jul 2009 13:37:09 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd-Vm2vDosFW for ; Sun, 19 Jul 2009 13:37:08 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 60DD33A6CAE for ; Sun, 19 Jul 2009 13:37:08 -0700 (PDT) Received: from a88-114-70-156.elisa-laajakaista.fi (a88-114-70-156.elisa-laajakaista.fi [88.114.70.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id ECC85216664; Sun, 19 Jul 2009 23:36:46 +0300 (EEST) Message-Id: <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> From: jouni To: Behcet Sarikaya In-Reply-To: <95739.51992.qm@web111413.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 19 Jul 2009 23:36:46 +0300 References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 20:37:09 -0000 Hi Behcet, On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: [snip] >>>> >>>> Hi Behcet, >>>> >>>> It is possible to assign multiple HNPs to an MN via RFC5213. >>>> However it is >>>> not possible to request dynamically (after initial attachment and >>>> being >>>> assigned an HNP and a BCE created) a new mobility session. >>>> The LMA would essentially view a new PBU request from the MAG for >>>> the MN as >>>> being a renewal request and hence not assign a new HNP. I think >>>> it is clear >>>> (at least in the 3GPP EPC context) that it with RFC5213 it is not >>>> possible >>>> to establish multiple mobility sessions with the same LMA via a >>>> single >>>> interface. >>> >>> Yes, I think it is clear. The question is do we want to change it? >> >> Yes. Extend the capability by which the LMA is aware that the PBU >> is a >> request for establishing a new mobility session. > > That's what I was referring to as a big semantic change to PBU/PBA. It is a change but I would not call it semantic change. Similar type of extensions what you already have e.g. with RFC5149. What the I-D adds here is more detail and a new key to help with lookups to binding cache (obviously adds more data to binding cache entries as well) when you want to identify exactly one of several mobility sessions without really knowing its assigned HNP. >> >>> I think sending a non-renewal PBU is a big semantic change to the >>> base >>> protocol. >> >> Not really. A PBU can indicate already whether it is a result of a >> HO or a >> renewal or the result of a new attachment via a different interface. >> >>> I was thinking that such a thing could happen below PMIP level >>> possibly using >>> the other prefix. I don't know what would you say to that? >> >> Not sure what you mean by "below PMIP level". Maybe you have some >> other >> ideas of how to achieve the same functionality. Also I don't >> understand what >> you mean by "the other prefix". What other prefix are you refering >> to? When >> the MN requests an additional mobility session, there is no prefix >> assigned >> to it yet. > > PBA sends more than one prefixes to MAG and MAG advertizes them. > What does MN do? > > I think hosts create addresses for each prefix they receive. If it is a case that PBA contains more than one HNP. This is, however, always not the case. > So my suggestion was to use a different address for each PDP > connection. In fact you need a single address to Eh? In this particular example, each PDN connection already has a different HNP. The issue is that the HNP information is not enough, or merely not available, when a link gets set up after a handover. > access the Internet. More than one addresses create problems that > MIF WG is trying to address. This is a completely different discussion imho. Cheers, Jouni > > Regards, > > Behcet > > > > > From jouni.nospam@gmail.com Mon Jul 20 00:36:46 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022B93A6C8F for ; Mon, 20 Jul 2009 00:36:46 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqieSJucRKTn for ; Mon, 20 Jul 2009 00:36:45 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id F02653A6CDE for ; Mon, 20 Jul 2009 00:36:44 -0700 (PDT) Received: by ewy26 with SMTP id 26so2083867ewy.37 for ; Mon, 20 Jul 2009 00:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=gfD/2S7jVBkAZJfDMQwZJejTUcsFeBAe+mtkLHbvbpw=; b=V5fkNdmeNOvfr/A3EwpoUhy8UZNKetiMI4irerZnlylj8UKO5ATdfU6PcCbko2lzXA skb6kIctbAtFg9y3zVERvmqQfDB5boSVmaWGoR/qeoYM2GnezOVcX6HhFAJQKTv1cZpZ ttvbzNmEr7PXDH68NZWt5lzQ4qmorH2xod/Kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=HopmMRgxrqcQ+r3fYjlGOdwlksL7R5QvWAZ+9wiA6Y/OjeBL+vF4N20qXxojj2MqS0 50ZZVWUmaEJk5mXN3pkGONTgtEIQNRZZpSPIngIbNFXo/PDuR0VuY5eV8Qj6DFw3i36M jif5hQo2yrK6xsuNBH8+vybssddkibYbFUtyA= Received: by 10.210.52.15 with SMTP id z15mr3260698ebz.8.1248075400923; Mon, 20 Jul 2009 00:36:40 -0700 (PDT) Received: from a88-112-140-13.elisa-laajakaista.fi (a88-112-140-13.elisa-laajakaista.fi [88.112.140.13]) by mx.google.com with ESMTPS id 7sm10417565eyb.55.2009.07.20.00.36.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 00:36:40 -0700 (PDT) Message-Id: <430DF442-A218-424D-B66B-724F7A011A4F@gmail.com> From: jouni korhonen To: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 20 Jul 2009 10:36:41 +0300 References: X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 07:36:46 -0000 Hi Raj, On Jul 16, 2009, at 11:26 PM, wrote: [snip] > > I think this extension is something we can discuss at the WG meeting > in > Stockholm. > > -Raj > Is there a presentation slot for this in the agenda? I did not spot it. Cheers, Jouni From Marco.Liebsch@nw.neclab.eu Mon Jul 20 01:30:58 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCB13A6872 for ; Mon, 20 Jul 2009 01:30:58 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym3+ctEPz-uZ for ; Mon, 20 Jul 2009 01:30:57 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1947D3A67F8 for ; Mon, 20 Jul 2009 01:30:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 715E72C01C9AF; Mon, 20 Jul 2009 10:29:53 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BjupQ+9rkCp; Mon, 20 Jul 2009 10:29:53 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 394612C00C51C; Mon, 20 Jul 2009 10:29:33 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:29:33 +0200 Message-ID: <4A642AEA.9030504@nw.neclab.eu> Date: Mon, 20 Jul 2009 10:29:30 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> <00b001ca05d4$fe0beb00$40106f0a@china.huawei.com> In-Reply-To: <00b001ca05d4$fe0beb00$40106f0a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 08:29:33.0212 (UTC) FILETIME=[35532DC0:01CA0914] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 08:30:58 -0000 Hi Xiangsong, Sri, Xiangsong Cui wrote: > Hi Sri, > > I think we meet some key detail in MAG. > Maybe they are implement issues > > How does MAG start its timer for binding request? > case 1: ONLY one timer for the binding request thread; or > case 2: One timer for per binding request message. I think the result is the same, as the MAG retransmits only after the retransmit timer has fired. I think there is implicitly only one timer scheduled in the context of one binding. If there is some good reason to send an updating PBU before the PBA for the previous PBU has been received, it's not a retransmission anymore. > > I prefer the case 1, and in case 1, as I said no trouble happen. > Without multi-homing, MAG and LMA can identify the thread > by source IP address and destination IP address, > if with multi-homing, BID may be plus to identify the thread. > In case 1, MAG and LMA identify request/response by thread, > but not by sequence number. One reply can kill the thread timer. > So only one timer starts and SN mismatch will not happen in case 1. > > In case 2, multi timer are started for multi request messages, and > SN is used to identify message. > If only one response returned as your solution, what will happen? > some timer still running (because only reply SN timer is killed) and > requests are sent in period. > Looping issue will happen in this case, if your solution is applied. > > > By the way, if you just want to distinguish original request and > retransmitted request, I have another idea, without any message > or option format modified in the protocol. > > We can claim a rule or suggestion: > When MAG retransmits a binding request, it uses the original > timestamp, as the value in original request message. > For LMA, when a binding request message is received, > timestamp is checked: > If new-arrived timestamp is greater, new request; > if new-arrived timestamp is equal, duplicate request, ignore or other > process. > if new-arrived timestamp is less, old request, drop it. > > Timestamp details is missed in RFCs, there are only sequence number > increase. RFC5213 mandates using the latest timer in a retransmit PBU. The mechanism you propose may work, but conflicts with the original meaning of a timestamp. However, using the previous timestamp in retransmits may work, and it still works for the handover scenario, where timestamps should resolve potential race conditions. Even if a pMAG uses in a retransmit message not the actual but the original timestamp, the timestamp of the nMAG is always higher. I've more doubts in how realistic the problem is that should be resolved with the retransmit tag? Is this a case that happened in real testbed and did it cause serious issues? I think it introduces some complexity, whereas the benefit is less. At least there is no benefit in protocol stability when introducing such identification of retransmit packets. Ok, the only benefit I see is to reply only to the latest retransmit, which is not a huge gain. My 2 cents, marco > We can highlight the rule or suggestion in bis version. > > How do you think about the idea? > > Xiangsong > > > ----- Original Message ----- From: "Sri Gundavelli" > To: "Xiangsong Cui" > Cc: ; > Sent: Thursday, July 16, 2009 12:14 PM > Subject: Re: [netext] Discussion about "Retransmit Message Identifier > Option"//Re: Agenda Requests received > > >> Hi Xiangsong, >> >> >> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >> >>> Hi Sri, >>> Please see inline. >>> >>> Thanks and regards >>> >>> ----- Original Message ----- From: "Sri Gundavelli" >>> >>> To: "Xiangsong Cui" >>> Cc: ; >>> Sent: Thursday, July 16, 2009 9:23 AM >>> Subject: Re: [netext] Discussion about "Retransmit Message >>> Identifier Option"//Re: Agenda Requests received >>> >>> >>>> >>>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>>> >>>> > Yes, I agree it is a very simple tag. >>>> > I just don't understand what benefit we can get from the extension. >>>> > That's all my question. >>>> > >>>> >>>> So, you are saying, LMA has no need to identify retransmitted >>>> packets ? >>> I think LMA need identify the packets, but need not care the intention. >>> Maybe it is the retransmitted message, maybe a new one, what is the >>> difference for LMA? >>> >> >> It makes a difference. When the LMA is waiting for a AAA response or >> waiting for some other resource, this distinction will be critical. >> A response that it constructs, can simply be sent as a response to >> the latest request, if it knows that the newly recvd request and >> the request under processing are the same. The MAG would always >> be able to know that the response that is received is the response >> for the latest. With the current lack of semantics, there can be >> cases where the MAG keeps sending requests, LMA keeps responding >> as it processes and the MAG still waiting for the latest response. >> >> >>>> When a new message arrives, drop the existing one and process the >>>> new message. >>> Maybe drop the existing one, or maybe process both messages (I think >>> latter is the right way in RFCs) and responds two binding Ack message. >>> >> >> But, the current text is not considering this scenario. There is >> not much consideration given to retransmit packets. >> >> >>>> The sender receives reply for the older message and it >>>> should drop and send a new request ? >>> Yes, sender will receive reply message, maybe one or two response. >>> If sender send two request, one is for binding and the other one is for >>> retransmission, I think there is only one timer and only one timer for >>> retransmission in the sender. If the sender receives reply message, it >>> has achieved the registration and it must kill the timer, and will not >>> retransmit request any more. >>> This is the key point, Do you agree it? >>> If the timer has been killed, I don't know why the sender will send a >>> new request. >>> >> >> But, there is a req to reply corelator when using seq numbers, that >> wont match. >> >>>> In this scenario is it not better >>>> for the sender and receiver to have an understanding of what is being >>>> processed and what is the new message for and its relation to the >>>> older message ? >>> I am not sure which one is better. >>> >> >> The bigger question would be do we need the ability to understand >> the sender intent and benifit in the processing logic in knowing >> the same, and avoiding the looping issue. >> >> Sri >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Mon Jul 20 01:52:30 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9533A6D1E for ; Mon, 20 Jul 2009 01:52:30 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYG3q4GUP14s for ; Mon, 20 Jul 2009 01:52:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 7074C3A67A2 for ; Mon, 20 Jul 2009 01:52:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C1FEC2C01C8EC for ; Mon, 20 Jul 2009 10:49:53 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ1hx5Zp8yD5 for ; Mon, 20 Jul 2009 10:49:53 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 9D9B92C00C51C for ; Mon, 20 Jul 2009 10:49:48 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:49:48 +0200 Message-ID: <4A642FAE.6040908@nw.neclab.eu> Date: Mon, 20 Jul 2009 10:49:50 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 08:49:48.0641 (UTC) FILETIME=[09C6ED10:01CA0917] Subject: [netext] Update of Localized Routing PS X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 08:52:30 -0000 Folks, we updated the PMIPv6 Localized Routing Problem Statement. We took all comments received so far and discussion from last IETF and from the ML into account. A new section about IPv4 considerations has been included according to the discussion we had so far. The issues being addressed in the PS are valid problems. In particular some items of the IPv4 considerations section should be further discussed to get a common picture about what needs to be addressed by the protocol solution. Any comments are appreciated. marco A new version of I-D, draft-liebsch-netext-pmip6-ro-ps-01.txt has been successfuly submitted by Marco Liebsch and posted to the IETF repository. Filename: draft-liebsch-netext-pmip6-ro-ps Revision: 01 Title: PMIPv6 Localized Routing Problem Statement Creation_date: 2009-07-13 WG ID: Independent Submission Number_of_pages: 15 Abstract: Proxy Mobile IPv6 is the IETF standard for network-based localized mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. The IETF Secretariat. From Xiangsong.Cui@huawei.com Mon Jul 20 03:09:31 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E5D3A6A4F for ; Mon, 20 Jul 2009 03:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hynvHYEnTZTp for ; Mon, 20 Jul 2009 03:09:24 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 060973A6A12 for ; Mon, 20 Jul 2009 03:09:24 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN2002DBQVW2Y@szxga04-in.huawei.com> for netext@ietf.org; Mon, 20 Jul 2009 17:40:45 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN2007PKQVWPU@szxga04-in.huawei.com> for netext@ietf.org; Mon, 20 Jul 2009 17:40:44 +0800 (CST) Date: Mon, 20 Jul 2009 17:40:43 +0800 From: Xiangsong Cui To: Marco Liebsch Message-id: <00b701ca091e$272fbfb0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> <00b001ca05d4$fe0beb00$40106f0a@china.huawei.com> <4A642AEA.9030504@nw.neclab.eu> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 10:09:31 -0000 Hi Marco, Please see inline. Regards/ Xiangsong ----- Original Message ----- From: "Marco Liebsch" To: "Xiangsong Cui" Cc: ; Sent: Monday, July 20, 2009 4:29 PM Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received > Hi Xiangsong, Sri, > > Xiangsong Cui wrote: >> Hi Sri, >> >> I think we meet some key detail in MAG. >> Maybe they are implement issues >> >> How does MAG start its timer for binding request? >> case 1: ONLY one timer for the binding request thread; or >> case 2: One timer for per binding request message. > I think the result is the same, as the MAG retransmits only after the > retransmit timer > has fired. I think there is implicitly only one timer scheduled in the > context of > one binding. If there is some good reason to send an updating PBU before > the > PBA for the previous PBU has been received, it's not a retransmission > anymore. > Yes, I agree there is only one timer is running, but the different timer has different meaning in fact. So the result maybe different. If the timer is for the given request message, the timer is associated with the request message. Whether the sequence number is used to match the message and timer is an implement issue. For example, if sender sends a request SN, and starts a timer(SN). When timer(SN) expires, the sender resends request SN+1, and starts timer(SN+1). When the sender receives binding Ack with SN, is it can kill timer(SN+1)? I ever see an acknowledgement with SN can ack Cumulative sequence numbers that equal or less than SN, but I never see a SN ack message can acknowledge a request with number SN+1. So, I prefer the LMA responds the latter request, and acknowledge the greater sequence number. >> >> I prefer the case 1, and in case 1, as I said no trouble happen. >> Without multi-homing, MAG and LMA can identify the thread >> by source IP address and destination IP address, >> if with multi-homing, BID may be plus to identify the thread. >> In case 1, MAG and LMA identify request/response by thread, >> but not by sequence number. One reply can kill the thread timer. >> So only one timer starts and SN mismatch will not happen in case 1. >> >> In case 2, multi timer are started for multi request messages, and >> SN is used to identify message. >> If only one response returned as your solution, what will happen? >> some timer still running (because only reply SN timer is killed) and >> requests are sent in period. >> Looping issue will happen in this case, if your solution is applied. >> >> >> By the way, if you just want to distinguish original request and >> retransmitted request, I have another idea, without any message >> or option format modified in the protocol. >> >> We can claim a rule or suggestion: >> When MAG retransmits a binding request, it uses the original >> timestamp, as the value in original request message. >> For LMA, when a binding request message is received, >> timestamp is checked: >> If new-arrived timestamp is greater, new request; >> if new-arrived timestamp is equal, duplicate request, ignore or other >> process. >> if new-arrived timestamp is less, old request, drop it. >> >> Timestamp details is missed in RFCs, there are only sequence number >> increase. > RFC5213 mandates using the latest timer in a retransmit PBU. The mechanism > you propose may work, but conflicts with the original meaning of a > timestamp. I really want to find the content in RFC for the issue, can you tell me where is the conflicts? which section in RFC5213 should I read? I ever found a description in 3GPP TS29.275 v8.3.0(PMIPv6, Stage 3) , in subclause 5.3.1.2, Table 5.3.1.2-2: Mobility Options in a PBA message for the PMIPv6 PDN Connection Handover procedure. For Timestamp option, it says "Copied from corresponding field of PBU, or set to the current time of LMA in case of timestamp error". I think since the Ack message keeps the same timerstamp in request, so the retransmitted PBU keep the same original timerstamp is also reasonable. > However, using the previous timestamp in retransmits may work, and it > still > works for the handover scenario, where timestamps should resolve potential > race > conditions. Even if a pMAG uses in a retransmit message not the actual but > the > original timestamp, the timestamp of the nMAG is always higher. > > I've more doubts in how realistic the problem is that should be resolved > with > the retransmit tag? Is this a case that happened in real testbed and did > it cause > serious issues? I think it introduces some complexity, whereas the benefit > is less. At least there is no benefit in protocol stability when > introducing such > identification of retransmit packets. I agree with you on this point. > Ok, the only benefit I see is to reply only to the > latest retransmit, which is not a huge gain. I also agree with you on this point, if only reponse, I prefer the latest. > > My 2 cents, > > marco > >> We can highlight the rule or suggestion in bis version. >> >> How do you think about the idea? >> >> Xiangsong >> >> >> ----- Original Message ----- From: "Sri Gundavelli" >> To: "Xiangsong Cui" >> Cc: ; >> Sent: Thursday, July 16, 2009 12:14 PM >> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >> Option"//Re: Agenda Requests received >> >> >>> Hi Xiangsong, >>> >>> >>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>> >>>> Hi Sri, >>>> Please see inline. >>>> >>>> Thanks and regards >>>> >>>> ----- Original Message ----- From: "Sri Gundavelli" >>>> >>>> To: "Xiangsong Cui" >>>> Cc: ; >>>> Sent: Thursday, July 16, 2009 9:23 AM >>>> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >>>> Option"//Re: Agenda Requests received >>>> >>>> >>>>> >>>>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>>>> >>>>> > Yes, I agree it is a very simple tag. >>>>> > I just don't understand what benefit we can get from the extension. >>>>> > That's all my question. >>>>> > >>>>> >>>>> So, you are saying, LMA has no need to identify retransmitted packets >>>>> ? >>>> I think LMA need identify the packets, but need not care the intention. >>>> Maybe it is the retransmitted message, maybe a new one, what is the >>>> difference for LMA? >>>> >>> >>> It makes a difference. When the LMA is waiting for a AAA response or >>> waiting for some other resource, this distinction will be critical. >>> A response that it constructs, can simply be sent as a response to >>> the latest request, if it knows that the newly recvd request and >>> the request under processing are the same. The MAG would always >>> be able to know that the response that is received is the response >>> for the latest. With the current lack of semantics, there can be >>> cases where the MAG keeps sending requests, LMA keeps responding >>> as it processes and the MAG still waiting for the latest response. >>> >>> >>>>> When a new message arrives, drop the existing one and process the >>>>> new message. >>>> Maybe drop the existing one, or maybe process both messages (I think >>>> latter is the right way in RFCs) and responds two binding Ack message. >>>> >>> >>> But, the current text is not considering this scenario. There is >>> not much consideration given to retransmit packets. >>> >>> >>>>> The sender receives reply for the older message and it >>>>> should drop and send a new request ? >>>> Yes, sender will receive reply message, maybe one or two response. >>>> If sender send two request, one is for binding and the other one is for >>>> retransmission, I think there is only one timer and only one timer for >>>> retransmission in the sender. If the sender receives reply message, it >>>> has achieved the registration and it must kill the timer, and will not >>>> retransmit request any more. >>>> This is the key point, Do you agree it? >>>> If the timer has been killed, I don't know why the sender will send a >>>> new request. >>>> >>> >>> But, there is a req to reply corelator when using seq numbers, that >>> wont match. >>> >>>>> In this scenario is it not better >>>>> for the sender and receiver to have an understanding of what is being >>>>> processed and what is the new message for and its relation to the >>>>> older message ? >>>> I am not sure which one is better. >>>> >>> >>> The bigger question would be do we need the ability to understand >>> the sender intent and benifit in the processing logic in knowing >>> the same, and avoiding the looping issue. >>> >>> Sri >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Mon Jul 20 05:29:02 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE0A3A69E1 for ; Mon, 20 Jul 2009 05:29:02 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obHfuzJpvggd for ; Mon, 20 Jul 2009 05:28:59 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3513A28C157 for ; Mon, 20 Jul 2009 05:28:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EA2752C00C51C; Mon, 20 Jul 2009 14:28:49 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXM6a28SsQ-Q; Mon, 20 Jul 2009 14:28:49 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id BA0352C02047C; Mon, 20 Jul 2009 14:28:34 +0200 (CEST) Received: from [127.0.0.1] ([10.1.2.187]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 14:28:35 +0200 Message-ID: <4A6462F1.4040502@nw.neclab.eu> Date: Mon, 20 Jul 2009 14:28:33 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Xiangsong Cui References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> <00b001ca05d4$fe0beb00$40106f0a@china.huawei.com> <4A642AEA.9030504@nw.neclab.eu> <00b701ca091e$272fbfb0$40106f0a@china.huawei.com> In-Reply-To: <00b701ca091e$272fbfb0$40106f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 12:28:35.0077 (UTC) FILETIME=[99BE1B50:01CA0935] Cc: Marco Liebsch , netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 12:29:02 -0000 Hi Xiangsong, please find some reply inline. marco Xiangsong Cui schrieb: > Hi Marco, > > Please see inline. > > Regards/ Xiangsong > > > ----- Original Message ----- From: "Marco Liebsch" > To: "Xiangsong Cui" > Cc: ; > Sent: Monday, July 20, 2009 4:29 PM > Subject: Re: [netext] Discussion about "Retransmit Message Identifier > Option"//Re: Agenda Requests received > > >> Hi Xiangsong, Sri, >> >> Xiangsong Cui wrote: >>> Hi Sri, >>> >>> I think we meet some key detail in MAG. >>> Maybe they are implement issues >>> >>> How does MAG start its timer for binding request? >>> case 1: ONLY one timer for the binding request thread; or >>> case 2: One timer for per binding request message. >> I think the result is the same, as the MAG retransmits only after the >> retransmit timer >> has fired. I think there is implicitly only one timer scheduled in >> the context of >> one binding. If there is some good reason to send an updating PBU >> before the >> PBA for the previous PBU has been received, it's not a retransmission >> anymore. >> > > Yes, I agree there is only one timer is running, but the different > timer has > different meaning in fact. So the result maybe different. > If the timer is for the given request message, the timer is associated > with > the request message. Whether the sequence number is used to match the > message and timer is an implement issue. > > For example, if sender sends a request SN, and starts a timer(SN). > When timer(SN) expires, the sender resends request SN+1, and starts > timer(SN+1). > When the sender receives binding Ack with SN, is it can kill timer(SN+1)? Hmm, but the packet carries a different sequence number than the packet which has the timer scheduled for. And if a MAG really behaves like you said, then the MAG could be satisfied, as it received at least a PBA for a registration in the same context. If it receives a PBA for the restransmit PBU, well, tht could be ignored then. So it does not matter if the retransmit message has a timer scheduled or not, or? > I ever see an acknowledgement with SN can ack Cumulative sequence numbers > that equal or less than SN, but I never see a SN ack message can > acknowledge a > request with number SN+1. > > So, I prefer the LMA responds the latter request, and acknowledge the > greater > sequence number. > >>> >>> I prefer the case 1, and in case 1, as I said no trouble happen. >>> Without multi-homing, MAG and LMA can identify the thread >>> by source IP address and destination IP address, >>> if with multi-homing, BID may be plus to identify the thread. >>> In case 1, MAG and LMA identify request/response by thread, >>> but not by sequence number. One reply can kill the thread timer. >>> So only one timer starts and SN mismatch will not happen in case 1. >>> >>> In case 2, multi timer are started for multi request messages, and >>> SN is used to identify message. >>> If only one response returned as your solution, what will happen? >>> some timer still running (because only reply SN timer is killed) and >>> requests are sent in period. >>> Looping issue will happen in this case, if your solution is applied. >>> >>> >>> By the way, if you just want to distinguish original request and >>> retransmitted request, I have another idea, without any message >>> or option format modified in the protocol. >>> >>> We can claim a rule or suggestion: >>> When MAG retransmits a binding request, it uses the original >>> timestamp, as the value in original request message. >>> For LMA, when a binding request message is received, >>> timestamp is checked: >>> If new-arrived timestamp is greater, new request; >>> if new-arrived timestamp is equal, duplicate request, ignore or >>> other process. >>> if new-arrived timestamp is less, old request, drop it. >>> >>> Timestamp details is missed in RFCs, there are only sequence number >>> increase. >> RFC5213 mandates using the latest timer in a retransmit PBU. The >> mechanism >> you propose may work, but conflicts with the original meaning of a >> timestamp. > > I really want to find the content in RFC for the issue, can you tell me > where is the conflicts? which section in RFC5213 should I read? 6.9.4 sais: 4. If the Timestamp-based scheme is in use, the retransmitted Proxy Binding Update messages MUST use the latest timestamp. I read this as to use a new timestamp for the retransmit packet. Btw, this is about the MAG. In general, I see timestamps to a packet as stamp when the packet is sent. According to my knowledge, also IEEE 802.11 puts timestamps only when the packet is about to be transmitted on the radio. I just interpret using an out-of-date (better: out-of-time ;-) timestamp as conflict with that. Does not mean that it cannot be changed. > > I ever found a description in 3GPP TS29.275 v8.3.0(PMIPv6, Stage 3) , > in subclause 5.3.1.2, Table 5.3.1.2-2: Mobility Options in a PBA message > for the PMIPv6 PDN Connection Handover procedure. > For Timestamp option, it says "Copied from corresponding field of PBU, > or set to the current time of LMA in case of timestamp error". > I think since the Ack message keeps the same timerstamp in request, > so the retransmitted PBU keep the same original timerstamp is also > reasonable. > >> However, using the previous timestamp in retransmits may work, and it >> still >> works for the handover scenario, where timestamps should resolve >> potential race >> conditions. Even if a pMAG uses in a retransmit message not the >> actual but the >> original timestamp, the timestamp of the nMAG is always higher. >> >> I've more doubts in how realistic the problem is that should be >> resolved with >> the retransmit tag? Is this a case that happened in real testbed and >> did it cause >> serious issues? I think it introduces some complexity, whereas the >> benefit >> is less. At least there is no benefit in protocol stability when >> introducing such >> identification of retransmit packets. > > I agree with you on this point. > >> Ok, the only benefit I see is to reply only to the >> latest retransmit, which is not a huge gain. > > I also agree with you on this point, if only reponse, I prefer the > latest. > >> >> My 2 cents, >> >> marco >> >>> We can highlight the rule or suggestion in bis version. >>> >>> How do you think about the idea? >>> >>> Xiangsong >>> >>> >>> ----- Original Message ----- From: "Sri Gundavelli" >>> >>> To: "Xiangsong Cui" >>> Cc: ; >>> Sent: Thursday, July 16, 2009 12:14 PM >>> Subject: Re: [netext] Discussion about "Retransmit Message >>> Identifier Option"//Re: Agenda Requests received >>> >>> >>>> Hi Xiangsong, >>>> >>>> >>>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>>> >>>>> Hi Sri, >>>>> Please see inline. >>>>> >>>>> Thanks and regards >>>>> >>>>> ----- Original Message ----- From: "Sri Gundavelli" >>>>> >>>>> To: "Xiangsong Cui" >>>>> Cc: ; >>>>> Sent: Thursday, July 16, 2009 9:23 AM >>>>> Subject: Re: [netext] Discussion about "Retransmit Message >>>>> Identifier Option"//Re: Agenda Requests received >>>>> >>>>> >>>>>> >>>>>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>>>>> >>>>>> > Yes, I agree it is a very simple tag. >>>>>> > I just don't understand what benefit we can get from the >>>>>> extension. >>>>>> > That's all my question. >>>>>> > >>>>>> >>>>>> So, you are saying, LMA has no need to identify retransmitted >>>>>> packets ? >>>>> I think LMA need identify the packets, but need not care the >>>>> intention. >>>>> Maybe it is the retransmitted message, maybe a new one, what is the >>>>> difference for LMA? >>>>> >>>> >>>> It makes a difference. When the LMA is waiting for a AAA response or >>>> waiting for some other resource, this distinction will be critical. >>>> A response that it constructs, can simply be sent as a response to >>>> the latest request, if it knows that the newly recvd request and >>>> the request under processing are the same. The MAG would always >>>> be able to know that the response that is received is the response >>>> for the latest. With the current lack of semantics, there can be >>>> cases where the MAG keeps sending requests, LMA keeps responding >>>> as it processes and the MAG still waiting for the latest response. >>>> >>>> >>>>>> When a new message arrives, drop the existing one and process the >>>>>> new message. >>>>> Maybe drop the existing one, or maybe process both messages (I think >>>>> latter is the right way in RFCs) and responds two binding Ack >>>>> message. >>>>> >>>> >>>> But, the current text is not considering this scenario. There is >>>> not much consideration given to retransmit packets. >>>> >>>> >>>>>> The sender receives reply for the older message and it >>>>>> should drop and send a new request ? >>>>> Yes, sender will receive reply message, maybe one or two response. >>>>> If sender send two request, one is for binding and the other one >>>>> is for >>>>> retransmission, I think there is only one timer and only one timer >>>>> for >>>>> retransmission in the sender. If the sender receives reply >>>>> message, it >>>>> has achieved the registration and it must kill the timer, and will >>>>> not >>>>> retransmit request any more. >>>>> This is the key point, Do you agree it? >>>>> If the timer has been killed, I don't know why the sender will send a >>>>> new request. >>>>> >>>> >>>> But, there is a req to reply corelator when using seq numbers, that >>>> wont match. >>>> >>>>>> In this scenario is it not better >>>>>> for the sender and receiver to have an understanding of what is >>>>>> being >>>>>> processed and what is the new message for and its relation to the >>>>>> older message ? >>>>> I am not sure which one is better. >>>>> >>>> >>>> The bigger question would be do we need the ability to understand >>>> the sender intent and benifit in the processing logic in knowing >>>> the same, and avoiding the looping issue. >>>> >>>> Sri >>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Mon Jul 20 13:51:52 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D1628C23F for ; Mon, 20 Jul 2009 13:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Sqy2lXMHYP for ; Mon, 20 Jul 2009 13:51:46 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2C75B28C22E for ; Mon, 20 Jul 2009 13:51:45 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6KKOrA5012483 for ; Mon, 20 Jul 2009 23:24:59 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 23:25:00 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 23:24:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 23:24:50 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 20 Jul 2009 22:24:47 +0200 From: To: Date: Mon, 20 Jul 2009 22:25:01 +0200 Thread-Topic: Question on I-D: draft-bernardos-mif-pmip-00.txt Thread-Index: AcoJeChH/kLi3e4m80C4iS3ZY/tpCA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2009 20:24:50.0661 (UTC) FILETIME=[221E3150:01CA0978] X-Nokia-AV: Clean Subject: [netext] Question on I-D: draft-bernardos-mif-pmip-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:51:52 -0000 Hello, The I-D states: " In the context of PMIPv6, current specification [RFC5213] does not address the case of a MIF node attaching to a PMIPv6 domain. We argue it is important to enable PMIPv6 to bring MIF nodes the advantages related to the simultaneous use of multiple interfaces. Moreover a MIF node could be seen as a not-modified host implementing the right technology for multi-interface handling. " RFC5213 does support a multi-interface host to connect to a PMIP6 domain. A MIF host which attaches via multiple interfaces to a PMIP6 domain will be assigned unique HNPs for each of the interfaces. A separate BCE is created in the LMA for each interface. Hence I am not sure what you are refering to in the I-D w.r.t MIF hosts attaching to a PMIP6 domain. The use case in Sec 3 is a bit more illustrative of the problem statement that you are trying to solve. The capability to move a flow between interfaces is being dealt with as part of the flow mobility work. This is a discussion item in the NetExt2 BoF at IETF75. The outcome of the BoF will determine what we do in the NetExt WG w.r.t flow mobility. The experiments that you have conducted on different OS' are interesting. -Raj From Basavaraj.Patil@nokia.com Mon Jul 20 14:36:28 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966D93A6DDD for ; Mon, 20 Jul 2009 14:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKY3ovKQhnXU for ; Mon, 20 Jul 2009 14:36:21 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8D2A73A6DBD for ; Mon, 20 Jul 2009 14:36:21 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6KLY1xf007526 for ; Tue, 21 Jul 2009 00:34:04 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:34:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:34:02 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 20 Jul 2009 23:34:01 +0200 From: To: Date: Mon, 20 Jul 2009 23:34:15 +0200 Thread-Topic: Suspend a PMIP6 session??? Thread-Index: AcoJgdRBwO3T1VHXDkC3mANRKxaccQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2009 21:34:02.0340 (UTC) FILETIME=[CCB62240:01CA0981] X-Nokia-AV: Clean Subject: [netext] Suspend a PMIP6 session??? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:36:28 -0000 Hello, In I-D: draft-muhanna-netext-mobility-session-suspend-00 you propose that i= n certain types of networks it may be useful to suspend a PMIP6 session. Do we need to really specify such a feature in the IETF? IMO this is a very specific requirement in 3GPP type of deployments which cannot support simultaneous CS and PS sessions. And hence it should be the responsibility of 3GPP to define specific mechanisms to deal with the problem. In what other types of deployments is there a need to suspend a mobility session?=20 I think we need more discussion on the merits of this feature before we consider it in Netext. -Raj From Basavaraj.Patil@nokia.com Mon Jul 20 14:39:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBFA3A6DE4 for ; Mon, 20 Jul 2009 14:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWjttVAZrjND for ; Mon, 20 Jul 2009 14:39:11 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CD7A13A6866 for ; Mon, 20 Jul 2009 14:39:10 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6KLaoQB009195; Tue, 21 Jul 2009 00:36:51 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:36:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:36:51 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 20 Jul 2009 23:36:50 +0200 From: To: Date: Mon, 20 Jul 2009 23:37:04 +0200 Thread-Topic: [netext] Solicitations for agenda items Thread-Index: Acn+/R74IPCoICKURZayX+NU5XELnwKhRoEQ Message-ID: In-Reply-To: <1246969149.15922.50.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2009 21:36:51.0212 (UTC) FILETIME=[315DF4C0:01CA0982] X-Nokia-AV: Clean Cc: netext@ietf.org, Telemaco.Melia@alcatel-lucent.com Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:39:12 -0000 Hi Carlos, I believe that the discussion of this I-D in the context of Netext is usefu= l only after we have determined the outcome of Netext2 BoF. Hence I am inclined to not allocate a slot for this I-D in the Netext WG meeting at IETF75. -Raj On 7/7/09 7:19 AM, "ext Carlos Jes=FAs Bernardos Cano" wrote: > Dear Raj, >=20 > We'd like to have a slot to present our draft [1] analysing how an MIF > node can be supported by a PMIPv6 based network. This draft is relevant > to NETEXT and NETEXT2 efforts. >=20 > Thanks, >=20 > Telemaco, Pierrick and Carlos >=20 > [1] http://www.ietf.org/internet-drafts/draft-bernardos-mif-pmip-00.txt >=20 > On Tue, 2009-06-23 at 00:44 +0200, Basavaraj.Patil@nokia.com wrote: >> Hello, >>=20 >> The NetExt WG will meet at IETF75. >> Please submit any requests for a slot on the agenda. >>=20 >> Note that we will consider I-Ds that pertain to the scope of the charter= . >> Additionally please ensure that you have an accompanying I-D when you >> request a slot.=20 >>=20 >> -Chairs >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Jul 20 14:41:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B69D3A6DB1 for ; Mon, 20 Jul 2009 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5O6tpMrW+hB for ; Mon, 20 Jul 2009 14:41:02 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 36B503A6DD6 for ; Mon, 20 Jul 2009 14:41:02 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6KLe6Yv030136; Mon, 20 Jul 2009 16:40:10 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:40:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:40:01 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 20 Jul 2009 23:40:00 +0200 From: To: , Date: Mon, 20 Jul 2009 23:40:15 +0200 Thread-Topic: [netext] Solicitations for agenda items Thread-Index: AcnzivxC61+jN2dLQUmPraRThFoneQLcjTDQAqFedLw= Message-ID: In-Reply-To: <853DD750D9C3724FBF2DF7164FCF641C032F9E93@FRVELSMBS14.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2009 21:40:01.0099 (UTC) FILETIME=[A28C69B0:01CA0982] X-Nokia-AV: Clean Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:41:03 -0000 Hi Telemaco, I don't see the need for discussing this I-D in the Netext WG meeting. The content may be useful in the context of the discussion in the Netext2 BoF meeting at IETF75. Based on the outcome of the Netext2 BoF, there may be an interest to consider this work in Netext (as informational). But given the current scop= e and charter of Netext I don't see a need to allocate a slot for this I-D at IETF75.=20 -Raj On 7/7/09 7:24 AM, "ext MELIA TELEMACO" wrote: > Hello, >=20 > As a follow up of the discussions about Netext/Netext2 we would request a= slot > to present ID draft-melia-netext-3gpp-mn-ar-if-00.txt. >=20 > Cheers, > telemaco >=20 > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t de > Basavaraj.Patil@nokia.com > Envoy=E9=A0: mardi 23 juin 2009 00:44 > =C0=A0: netext@ietf.org > Objet=A0: [netext] Solicitations for agenda items >=20 >=20 > Hello, >=20 > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. >=20 > Note that we will consider I-Ds that pertain to the scope of the charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot. >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Jul 20 14:51:21 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243CF28C240 for ; Mon, 20 Jul 2009 14:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.752 X-Spam-Level: X-Spam-Status: No, score=-5.752 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwY+W+C8I9qB for ; Mon, 20 Jul 2009 14:51:20 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4ADB93A6CF6 for ; Mon, 20 Jul 2009 14:51:20 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6KLor5P005689 for ; Mon, 20 Jul 2009 16:51:04 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:51:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:50:59 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 20 Jul 2009 23:50:58 +0200 From: To: Date: Mon, 20 Jul 2009 23:51:08 +0200 Thread-Topic: Revised agenda for NetExt meeting at IETF75 Thread-Index: AcoJhDANCbNlxSR4ZEiS2hDrtpijeQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2009 21:50:59.0087 (UTC) FILETIME=[2ABD69F0:01CA0984] X-Nokia-AV: Clean Subject: [netext] Revised agenda for NetExt meeting at IETF75 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:51:21 -0000 Posted at: http://www.ietf.org/proceedings/75/agenda/netext.txt NetExt WG Meeting THURSDAY, July 30, 2009 1300-1500 Afternoon Session I ----------------------------------------------- 1. Agenda bashing, Blueseheets, Note takers, Jabber scribes 5 Mins 2. WG Status update 10 Mins Chairs 3. Localized Routing discussion 30~40 Mins Problem statement, Scope and Solutions discussion I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt Marco Liebsch Solution I-Ds include: [1] draft-loureiro-netext-pmipv6-ro-00.txt [2] draft-koodli-netext-local-forwarding-00.txt [3] draft-oulai-netext-opt-local-routing-00.txt [4] draft-wu-netext-local-ro-03.txt 4. Runtime LMA Assignment Support for Proxy Mobile IPv6" I-D: draft-korhonen-netext-redirect-02 Jouni Korhonen - 10 Mins 5. Bulk Re-registration for Proxy Mobile IPv6 10 Mins I-D: draft-premec-netlmm-bulk-re-registration-02 Jouni Korhonen Discussion of new proposals: 6. Tunnel Negotiation for Proxy Mobile IPv6 5 Mins I-D: draft-xia-netext-tunnel-negotiation-01.txt Frank Xia =20 7. Mobile Node Group Identifier Option 10 Mins I-D: draft-gundavelli-netext-mn-groupid-option-01 Sri Gundavelli =20 8. Retransmit Message Identifier Option 5 Mins I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt Sri Gundavelli =20 9. Connection Identifier for Proxy Mobile IPv6 5 Mins I-D: draft-wolfner-netext-pmip6-connid-00 Jouni Korhonen From AMUHANNA@nortel.com Mon Jul 20 15:49:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B873A6AB1 for ; Mon, 20 Jul 2009 15:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.734 X-Spam-Level: X-Spam-Status: No, score=-5.734 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQA6xdfjHPPq for ; Mon, 20 Jul 2009 15:49:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F23E23A696A for ; Mon, 20 Jul 2009 15:49:10 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6KMl0f12586; Mon, 20 Jul 2009 22:47:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2009 17:46:51 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Suspend a PMIP6 session??? thread-index: AcoJgdRBwO3T1VHXDkC3mANRKxaccQACfuww References: From: "Ahmad Muhanna" To: , Subject: Re: [netext] Suspend a PMIP6 session??? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:49:11 -0000 Hi Raj, The same concept is applicable to 3GPP2. Regards, Ahmad =20 > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of=20 > Basavaraj.Patil@nokia.com > Sent: Tuesday, July 21, 2009 6:34 AM > To: netext@ietf.org > Subject: [netext] Suspend a PMIP6 session??? >=20 >=20 > Hello, >=20 > In I-D: draft-muhanna-netext-mobility-session-suspend-00 you=20 > propose that in certain types of networks it may be useful to=20 > suspend a PMIP6 session. >=20 > Do we need to really specify such a feature in the IETF? IMO=20 > this is a very specific requirement in 3GPP type of=20 > deployments which cannot support simultaneous CS and PS=20 > sessions. And hence it should be the responsibility of 3GPP=20 > to define specific mechanisms to deal with the problem. >=20 > In what other types of deployments is there a need to suspend=20 > a mobility session?=20 >=20 > I think we need more discussion on the merits of this feature=20 > before we consider it in Netext. >=20 > -Raj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From vijay@wichorus.com Mon Jul 20 16:12:33 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4793A6885 for ; Mon, 20 Jul 2009 16:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV2j-b51xWtX for ; Mon, 20 Jul 2009 16:12:32 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id C26E73A63D3 for ; Mon, 20 Jul 2009 16:12:32 -0700 (PDT) Received: from OMTA19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id JFM31c00B1eYJf8AEPCRYl; Mon, 20 Jul 2009 23:12:25 +0000 Received: from [192.168.1.193] ([67.161.28.136]) by OMTA19.emeryville.ca.mail.comcast.net with comcast id JPCL1c00J2wC77n01PCQy3; Mon, 20 Jul 2009 23:12:24 +0000 Message-ID: <4A64F9D7.9000508@wichorus.com> Date: Mon, 20 Jul 2009 16:12:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] Suspend a PMIP6 session??? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 23:12:33 -0000 Hi Raj, Basavaraj.Patil@nokia.com wrote: > Hello, > > In I-D: draft-muhanna-netext-mobility-session-suspend-00 you propose that in > certain types of networks it may be useful to suspend a PMIP6 session. > > Do we need to really specify such a feature in the IETF? IMO this is a very > specific requirement in 3GPP type of deployments which cannot support > simultaneous CS and PS sessions. And hence it should be the responsibility > of 3GPP to define specific mechanisms to deal with the problem. What kind of mechanism? Using a vendor specific mobility option? But that would result in more 3GPP-specific modifications for PMIPv6 resulting in a 3GPP PMIPv6 flavor. Vijay > > In what other types of deployments is there a need to suspend a mobility > session? > > I think we need more discussion on the merits of this feature before we > consider it in Netext. > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Mon Jul 20 18:09:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E473A67E4 for ; Mon, 20 Jul 2009 18:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFWt4Qt-A4V6 for ; Mon, 20 Jul 2009 18:09:34 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D65B13A6846 for ; Mon, 20 Jul 2009 18:09:33 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN300DUTXVKZR@szxga04-in.huawei.com> for netext@ietf.org; Tue, 21 Jul 2009 09:09:20 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN3001VBXVJU9@szxga04-in.huawei.com> for netext@ietf.org; Tue, 21 Jul 2009 09:09:20 +0800 (CST) Date: Tue, 21 Jul 2009 09:09:23 +0800 From: Xiangsong Cui To: Marco Liebsch Message-id: <002301ca099f$e2f83d90$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com> <004801ca0519$f8a3b500$40106f0a@china.huawei.com> <06bd01ca05ae$c27cfd20$d6f6200a@amer.cisco.com> <001701ca05b3$5c79a000$40106f0a@china.huawei.com> <002a01ca05ba$93fe4150$40106f0a@china.huawei.com> <00b001ca05d4$fe0beb00$40106f0a@china.huawei.com> <4A642AEA.9030504@nw.neclab.eu> <00b701ca091e$272fbfb0$40106f0a@china.huawei.com> <4A6462F1.4040502@nw.neclab.eu> Cc: Marco Liebsch , netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 01:09:35 -0000 Hi Marco, Thank you for your response, please see inline. Regards Xiangsong ----- Original Message ----- From: "Marco Liebsch" To: "Xiangsong Cui" Cc: "Marco Liebsch" ; ; Sent: Monday, July 20, 2009 8:28 PM Subject: Re: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received > Hi Xiangsong, > please find some reply inline. > > marco > > Xiangsong Cui schrieb: >> Hi Marco, >> >> Please see inline. >> >> Regards/ Xiangsong >> >> >> ----- Original Message ----- From: "Marco Liebsch" >> To: "Xiangsong Cui" >> Cc: ; >> Sent: Monday, July 20, 2009 4:29 PM >> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >> Option"//Re: Agenda Requests received >> >> >>> Hi Xiangsong, Sri, >>> >>> Xiangsong Cui wrote: >>>> Hi Sri, >>>> >>>> I think we meet some key detail in MAG. >>>> Maybe they are implement issues >>>> >>>> How does MAG start its timer for binding request? >>>> case 1: ONLY one timer for the binding request thread; or >>>> case 2: One timer for per binding request message. >>> I think the result is the same, as the MAG retransmits only after the >>> retransmit timer >>> has fired. I think there is implicitly only one timer scheduled in the >>> context of >>> one binding. If there is some good reason to send an updating PBU before >>> the >>> PBA for the previous PBU has been received, it's not a retransmission >>> anymore. >>> >> >> Yes, I agree there is only one timer is running, but the different timer >> has >> different meaning in fact. So the result maybe different. >> If the timer is for the given request message, the timer is associated >> with >> the request message. Whether the sequence number is used to match the >> message and timer is an implement issue. >> >> For example, if sender sends a request SN, and starts a timer(SN). >> When timer(SN) expires, the sender resends request SN+1, and starts >> timer(SN+1). >> When the sender receives binding Ack with SN, is it can kill timer(SN+1)? > Hmm, but the packet carries a different sequence number than the packet > which has > the timer scheduled for. And if a MAG really behaves like you said, then > the MAG > could be satisfied, as it received at least a PBA for a registration in > the same context. > If it receives a PBA for the restransmit PBU, well, tht could be ignored > then. So it does > not matter if the retransmit message has a timer scheduled or not, or? > I think this a implement issue, I assume the case 2 is using one timer match one message, and the case 1 is using one timer match one request thread, i.e. one context. Maybe there is only one case in fact. I think we can stop discussing it now. >> I ever see an acknowledgement with SN can ack Cumulative sequence numbers >> that equal or less than SN, but I never see a SN ack message can >> acknowledge a >> request with number SN+1. >> >> So, I prefer the LMA responds the latter request, and acknowledge the >> greater >> sequence number. >> >>>> >>>> I prefer the case 1, and in case 1, as I said no trouble happen. >>>> Without multi-homing, MAG and LMA can identify the thread >>>> by source IP address and destination IP address, >>>> if with multi-homing, BID may be plus to identify the thread. >>>> In case 1, MAG and LMA identify request/response by thread, >>>> but not by sequence number. One reply can kill the thread timer. >>>> So only one timer starts and SN mismatch will not happen in case 1. >>>> >>>> In case 2, multi timer are started for multi request messages, and >>>> SN is used to identify message. >>>> If only one response returned as your solution, what will happen? >>>> some timer still running (because only reply SN timer is killed) and >>>> requests are sent in period. >>>> Looping issue will happen in this case, if your solution is applied. >>>> >>>> >>>> By the way, if you just want to distinguish original request and >>>> retransmitted request, I have another idea, without any message >>>> or option format modified in the protocol. >>>> >>>> We can claim a rule or suggestion: >>>> When MAG retransmits a binding request, it uses the original >>>> timestamp, as the value in original request message. >>>> For LMA, when a binding request message is received, >>>> timestamp is checked: >>>> If new-arrived timestamp is greater, new request; >>>> if new-arrived timestamp is equal, duplicate request, ignore or other >>>> process. >>>> if new-arrived timestamp is less, old request, drop it. >>>> >>>> Timestamp details is missed in RFCs, there are only sequence number >>>> increase. >>> RFC5213 mandates using the latest timer in a retransmit PBU. The >>> mechanism >>> you propose may work, but conflicts with the original meaning of a >>> timestamp. >> >> I really want to find the content in RFC for the issue, can you tell me >> where is the conflicts? which section in RFC5213 should I read? > > 6.9.4 sais: > > 4. If the Timestamp-based scheme is in use, the retransmitted Proxy > Binding Update messages MUST use the latest timestamp. > I read this as to use a new timestamp for the retransmit packet. > Btw, this is about the MAG. > > > In general, I see timestamps to a packet as stamp when the packet is sent. > According > to my knowledge, also IEEE 802.11 puts timestamps only when the packet > is about to be transmitted on the radio. I just interpret using an > out-of-date > (better: out-of-time ;-) timestamp as conflict with that. Does not mean > that it > cannot be changed. > Yes, I got it, thank you. Xiangsong >> >> I ever found a description in 3GPP TS29.275 v8.3.0(PMIPv6, Stage 3) , >> in subclause 5.3.1.2, Table 5.3.1.2-2: Mobility Options in a PBA message >> for the PMIPv6 PDN Connection Handover procedure. >> For Timestamp option, it says "Copied from corresponding field of PBU, >> or set to the current time of LMA in case of timestamp error". >> I think since the Ack message keeps the same timerstamp in request, >> so the retransmitted PBU keep the same original timerstamp is also >> reasonable. >> >>> However, using the previous timestamp in retransmits may work, and it >>> still >>> works for the handover scenario, where timestamps should resolve >>> potential race >>> conditions. Even if a pMAG uses in a retransmit message not the actual >>> but the >>> original timestamp, the timestamp of the nMAG is always higher. >>> >>> I've more doubts in how realistic the problem is that should be resolved >>> with >>> the retransmit tag? Is this a case that happened in real testbed and did >>> it cause >>> serious issues? I think it introduces some complexity, whereas the >>> benefit >>> is less. At least there is no benefit in protocol stability when >>> introducing such >>> identification of retransmit packets. >> >> I agree with you on this point. > >> >>> Ok, the only benefit I see is to reply only to the >>> latest retransmit, which is not a huge gain. >> >> I also agree with you on this point, if only reponse, I prefer the >> latest. >> >>> >>> My 2 cents, >>> >>> marco >>> >>>> We can highlight the rule or suggestion in bis version. >>>> >>>> How do you think about the idea? >>>> >>>> Xiangsong >>>> >>>> >>>> ----- Original Message ----- From: "Sri Gundavelli" >>>> >>>> To: "Xiangsong Cui" >>>> Cc: ; >>>> Sent: Thursday, July 16, 2009 12:14 PM >>>> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >>>> Option"//Re: Agenda Requests received >>>> >>>> >>>>> Hi Xiangsong, >>>>> >>>>> >>>>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>>>> >>>>>> Hi Sri, >>>>>> Please see inline. >>>>>> >>>>>> Thanks and regards >>>>>> >>>>>> ----- Original Message ----- From: "Sri Gundavelli" >>>>>> >>>>>> To: "Xiangsong Cui" >>>>>> Cc: ; >>>>>> Sent: Thursday, July 16, 2009 9:23 AM >>>>>> Subject: Re: [netext] Discussion about "Retransmit Message Identifier >>>>>> Option"//Re: Agenda Requests received >>>>>> >>>>>> >>>>>>> >>>>>>> On Thu, 16 Jul 2009, Xiangsong Cui wrote: >>>>>>> >>>>>>> > Yes, I agree it is a very simple tag. >>>>>>> > I just don't understand what benefit we can get from the >>>>>>> extension. >>>>>>> > That's all my question. >>>>>>> > >>>>>>> >>>>>>> So, you are saying, LMA has no need to identify retransmitted >>>>>>> packets ? >>>>>> I think LMA need identify the packets, but need not care the >>>>>> intention. >>>>>> Maybe it is the retransmitted message, maybe a new one, what is the >>>>>> difference for LMA? >>>>>> >>>>> >>>>> It makes a difference. When the LMA is waiting for a AAA response or >>>>> waiting for some other resource, this distinction will be critical. >>>>> A response that it constructs, can simply be sent as a response to >>>>> the latest request, if it knows that the newly recvd request and >>>>> the request under processing are the same. The MAG would always >>>>> be able to know that the response that is received is the response >>>>> for the latest. With the current lack of semantics, there can be >>>>> cases where the MAG keeps sending requests, LMA keeps responding >>>>> as it processes and the MAG still waiting for the latest response. >>>>> >>>>> >>>>>>> When a new message arrives, drop the existing one and process the >>>>>>> new message. >>>>>> Maybe drop the existing one, or maybe process both messages (I think >>>>>> latter is the right way in RFCs) and responds two binding Ack >>>>>> message. >>>>>> >>>>> >>>>> But, the current text is not considering this scenario. There is >>>>> not much consideration given to retransmit packets. >>>>> >>>>> >>>>>>> The sender receives reply for the older message and it >>>>>>> should drop and send a new request ? >>>>>> Yes, sender will receive reply message, maybe one or two response. >>>>>> If sender send two request, one is for binding and the other one is >>>>>> for >>>>>> retransmission, I think there is only one timer and only one timer >>>>>> for >>>>>> retransmission in the sender. If the sender receives reply message, >>>>>> it >>>>>> has achieved the registration and it must kill the timer, and will >>>>>> not >>>>>> retransmit request any more. >>>>>> This is the key point, Do you agree it? >>>>>> If the timer has been killed, I don't know why the sender will send a >>>>>> new request. >>>>>> >>>>> >>>>> But, there is a req to reply corelator when using seq numbers, that >>>>> wont match. >>>>> >>>>>>> In this scenario is it not better >>>>>>> for the sender and receiver to have an understanding of what is >>>>>>> being >>>>>>> processed and what is the new message for and its relation to the >>>>>>> older message ? >>>>>> I am not sure which one is better. >>>>>> >>>>> >>>>> The bigger question would be do we need the ability to understand >>>>> the sender intent and benifit in the processing logic in knowing >>>>> the same, and avoiding the looping issue. >>>>> >>>>> Sri >>>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> > > From Xiangsong.Cui@huawei.com Mon Jul 20 21:12:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258BB3A6DD2 for ; Mon, 20 Jul 2009 21:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oKT7DLGlHKL for ; Mon, 20 Jul 2009 21:12:06 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0E6DE3A6E07 for ; Mon, 20 Jul 2009 21:12:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN400LDJ6BLKL@szxga03-in.huawei.com> for netext@ietf.org; Tue, 21 Jul 2009 12:11:45 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN400BSC6BKU4@szxga03-in.huawei.com> for netext@ietf.org; Tue, 21 Jul 2009 12:11:45 +0800 (CST) Date: Tue, 21 Jul 2009 12:11:44 +0800 From: Xiangsong Cui To: jouni , Behcet Sarikaya Message-id: <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 04:12:07 -0000 Hi Jouni, I also wonder at the motivation. > Similar type > of extensions what you already have e.g. with RFC5149. What the I-D > adds here is more detail and a new key to help with lookups to binding Yes, RFC5149 introduces some extensions, we can accept the extension because there are many use cases. Can you give us some use case too? >From the draft, it says: " However, in a case of multiple PDN connections to the same APN, and assuming that Home Network Prefixes (HNP) are not always available in a Mobile Access Gateway (MAG) after a handover and that the "APN name" in the Service Selection mobility option cannot be decorated (i.e. making each APN unique), there is a need for a new identifier to uniquely identify PDN connections to the same APN. " I am confused by the case, could you please figure it more clearly? Thanks in advance. Xiangsong ----- Original Message ----- From: "jouni" To: "Behcet Sarikaya" Cc: ; Sent: Monday, July 20, 2009 4:36 AM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > Hi Behcet, > > > On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: > > [snip] > >>>>> >>>>> Hi Behcet, >>>>> >>>>> It is possible to assign multiple HNPs to an MN via RFC5213. >>>>> However it is >>>>> not possible to request dynamically (after initial attachment and >>>>> being >>>>> assigned an HNP and a BCE created) a new mobility session. >>>>> The LMA would essentially view a new PBU request from the MAG for >>>>> the MN as >>>>> being a renewal request and hence not assign a new HNP. I think >>>>> it is clear >>>>> (at least in the 3GPP EPC context) that it with RFC5213 it is not >>>>> possible >>>>> to establish multiple mobility sessions with the same LMA via a >>>>> single >>>>> interface. >>>> >>>> Yes, I think it is clear. The question is do we want to change it? >>> >>> Yes. Extend the capability by which the LMA is aware that the PBU >>> is a >>> request for establishing a new mobility session. >> >> That's what I was referring to as a big semantic change to PBU/PBA. > > It is a change but I would not call it semantic change. Similar type > of extensions what you already have e.g. with RFC5149. What the I-D > adds here is more detail and a new key to help with lookups to binding > cache (obviously adds more data to binding cache entries as well) when > you want to identify exactly one of several mobility sessions without > really knowing its assigned HNP. > >>> >>>> I think sending a non-renewal PBU is a big semantic change to the >>>> base >>>> protocol. >>> >>> Not really. A PBU can indicate already whether it is a result of a >>> HO or a >>> renewal or the result of a new attachment via a different interface. >>> >>>> I was thinking that such a thing could happen below PMIP level >>>> possibly using >>>> the other prefix. I don't know what would you say to that? >>> >>> Not sure what you mean by "below PMIP level". Maybe you have some >>> other >>> ideas of how to achieve the same functionality. Also I don't >>> understand what >>> you mean by "the other prefix". What other prefix are you refering >>> to? When >>> the MN requests an additional mobility session, there is no prefix >>> assigned >>> to it yet. >> >> PBA sends more than one prefixes to MAG and MAG advertizes them. >> What does MN do? >> >> I think hosts create addresses for each prefix they receive. > > If it is a case that PBA contains more than one HNP. This is, however, > always not the case. > > >> So my suggestion was to use a different address for each PDP >> connection. In fact you need a single address to > > Eh? In this particular example, each PDN connection already has a > different HNP. The issue is that the HNP information is not enough, or > merely not available, when a link gets set up after a handover. > >> access the Internet. More than one addresses create problems that >> MIF WG is trying to address. > > This is a completely different discussion imho. > > Cheers, > Jouni > > > >> >> Regards, >> >> Behcet >> >> >> >> >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Tue Jul 21 01:18:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCCD28C1EF for ; Tue, 21 Jul 2009 01:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mDSMWVKuCUz for ; Tue, 21 Jul 2009 01:18:56 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id EC1B928C1CF for ; Tue, 21 Jul 2009 01:18:39 -0700 (PDT) Received: by fxm18 with SMTP id 18so2438548fxm.37 for ; Tue, 21 Jul 2009 01:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=WMr/xQK8o2+7JyOZQPcqculmSQ2hvmy0MoN7I4FM/vo=; b=TRMocCXnuxVFI1XZZHU21Ruz7d3DTjEi/SzpCoJfLaal9e31WwO79xNchCjVG6uK1q 53jLad14hKTizhj7/HSfEEI1sOs5d7UjriZq/ocmPFWw3/Y1Nlu8KOeX+BnclAO2OSpC HX+qzz1kf/gnW4R9R43hwn5/7TZbrPAjfOcl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=JCX3dLvCRqRX8297o9WPX79NiYZcZiHpzS/ISaFuOZTMjH0h31C1ItAQqIHs610NXe WMAEHmYGUFH6F6weEmU2ZpeKSd0OBzWGXr45YvRUnUG0T5SKxKkerZzVK2xC/wbfl2PG HRe4iG6ZRVBy5Jdomjq6jybTB//TtBWpf9C0Q= Received: by 10.204.64.67 with SMTP id d3mr5241003bki.142.1248164316929; Tue, 21 Jul 2009 01:18:36 -0700 (PDT) Received: from a88-112-140-13.elisa-laajakaista.fi (a88-112-140-13.elisa-laajakaista.fi [88.112.140.13]) by mx.google.com with ESMTPS id b17sm9266481fka.6.2009.07.21.01.18.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Jul 2009 01:18:36 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> X-Priority: 3 References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> Message-Id: <9408201D-9CD1-4C73-9600-31AA3567B561@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 11:18:34 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 08:18:57 -0000 Hi Xiangsong, See inline. On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote: > Hi Jouni, > > I also wonder at the motivation. > >> Similar type of extensions what you already have e.g. with >> RFC5149. What the I-D adds here is more detail and a new key to >> help with lookups to binding > > Yes, RFC5149 introduces some extensions, we can accept the extension > because there are many use cases. > Can you give us some use case too? > > From the draft, it says: > " However, in a case of multiple PDN > connections to the same APN, and assuming that Home Network Prefixes > (HNP) are not always available in a Mobile Access Gateway (MAG) after > a handover and that the "APN name" in the Service Selection mobility > option cannot be decorated (i.e. making each APN unique), there is a > need for a new identifier to uniquely identify PDN connections to the > same APN. " > > I am confused by the case, could you please figure it more clearly? Right. Assume MN establishes three connections through the same radio to the MAG. Connection 1 gets HNP1 and is identified with Service Selection (SS) ="foo". Connection 2 gets HNP2 and is again identified by SS="foo". Connection 3 gets HNP3 and is also identified by SS="foo". This is possible by some popular access technologies already today. MN and MAG also know these connections by some lower layer identifier/radio level thing. When a handover takes place the MN re-attaches to a new MAG and starts setting up connections to the new MAG. Now the MAG knows which connection the MN sets up based on the SS and the "lower layer thing" but does not necessarily know the associated HNP yet. So the PBU sent to the LMA needs more info. Otherwise the LMA is not able to return the correct HNP to the MAG. If the LMA were to return HNP1 for the connection 2 after a handover that would break the IP connectivity in the MN. That's why we propose to add "yet another" identifier to all PBU/PBA messages. Using MN-LL would look tempting but the solution must also work with one interface and cases where interfaces do not have real identifiers (would mean overloading the existing meaning of the MN-LL). Cheers, Jouni > > Thanks in advance. > > Xiangsong > > ----- Original Message ----- From: "jouni" > To: "Behcet Sarikaya" > Cc: ; > Sent: Monday, July 20, 2009 4:36 AM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- > connid-00 > > >> Hi Behcet, >> On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: >> [snip] >>>>>> >>>>>> Hi Behcet, >>>>>> >>>>>> It is possible to assign multiple HNPs to an MN via RFC5213. >>>>>> However it is >>>>>> not possible to request dynamically (after initial attachment >>>>>> and being >>>>>> assigned an HNP and a BCE created) a new mobility session. >>>>>> The LMA would essentially view a new PBU request from the MAG >>>>>> for the MN as >>>>>> being a renewal request and hence not assign a new HNP. I >>>>>> think it is clear >>>>>> (at least in the 3GPP EPC context) that it with RFC5213 it is >>>>>> not possible >>>>>> to establish multiple mobility sessions with the same LMA via >>>>>> a single >>>>>> interface. >>>>> >>>>> Yes, I think it is clear. The question is do we want to change it? >>>> >>>> Yes. Extend the capability by which the LMA is aware that the >>>> PBU is a >>>> request for establishing a new mobility session. >>> >>> That's what I was referring to as a big semantic change to PBU/PBA. >> It is a change but I would not call it semantic change. Similar >> type of extensions what you already have e.g. with RFC5149. What >> the I-D adds here is more detail and a new key to help with >> lookups to binding cache (obviously adds more data to binding >> cache entries as well) when you want to identify exactly one of >> several mobility sessions without really knowing its assigned HNP. >>>> >>>>> I think sending a non-renewal PBU is a big semantic change to >>>>> the base >>>>> protocol. >>>> >>>> Not really. A PBU can indicate already whether it is a result of >>>> a HO or a >>>> renewal or the result of a new attachment via a different >>>> interface. >>>> >>>>> I was thinking that such a thing could happen below PMIP level >>>>> possibly using >>>>> the other prefix. I don't know what would you say to that? >>>> >>>> Not sure what you mean by "below PMIP level". Maybe you have >>>> some other >>>> ideas of how to achieve the same functionality. Also I don't >>>> understand what >>>> you mean by "the other prefix". What other prefix are you >>>> refering to? When >>>> the MN requests an additional mobility session, there is no >>>> prefix assigned >>>> to it yet. >>> >>> PBA sends more than one prefixes to MAG and MAG advertizes them. >>> What does MN do? >>> >>> I think hosts create addresses for each prefix they receive. >> If it is a case that PBA contains more than one HNP. This is, >> however, always not the case. >>> So my suggestion was to use a different address for each PDP >>> connection. In fact you need a single address to >> Eh? In this particular example, each PDN connection already has a >> different HNP. The issue is that the HNP information is not enough, >> or merely not available, when a link gets set up after a handover. >>> access the Internet. More than one addresses create problems that >>> MIF WG is trying to address. >> This is a completely different discussion imho. >> Cheers, >> Jouni >>> >>> Regards, >>> >>> Behcet >>> >>> >>> >>> >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Tue Jul 21 01:40:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA4228C28C for ; Tue, 21 Jul 2009 01:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=0.864, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxmOTpDX949y for ; Tue, 21 Jul 2009 01:40:50 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A75A628C23D for ; Tue, 21 Jul 2009 01:40:49 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN400L13IS08T@szxga04-in.huawei.com> for netext@ietf.org; Tue, 21 Jul 2009 16:40:48 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN400KPLIRYV9@szxga04-in.huawei.com> for netext@ietf.org; Tue, 21 Jul 2009 16:40:47 +0800 (CST) Date: Tue, 21 Jul 2009 16:40:41 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <013501ca09de$ee79cd70$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> <9408201D-9CD1-4C73-9600-31AA3567B561@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 08:40:51 -0000 Hi Jouni, > Right. Assume MN establishes three connections through the same radio > to the MAG. Connection 1 gets HNP1 and is identified with Service Do you mean a MN has three 3GPP interface connection, or three WLAN connection? I don't understand the case, IMO, a MN may has a 3GPP interface + a WLAN interface + a Wimax interface, but I can't image a MN with three WLAN interfaces, do the interfaces use the same link layer address? Even in Nextext2, there is only inter RAT handover. If there is only one RAT, in my mind, there is only one connection, to previous AR before handover and to new AR after handover. Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Tuesday, July 21, 2009 4:18 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > Hi Xiangsong, > > See inline. > > > On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote: > >> Hi Jouni, >> >> I also wonder at the motivation. >> >>> Similar type of extensions what you already have e.g. with >>> RFC5149. What the I-D adds here is more detail and a new key to >>> help with lookups to binding >> >> Yes, RFC5149 introduces some extensions, we can accept the extension >> because there are many use cases. >> Can you give us some use case too? >> >> From the draft, it says: >> " However, in a case of multiple PDN >> connections to the same APN, and assuming that Home Network Prefixes >> (HNP) are not always available in a Mobile Access Gateway (MAG) after >> a handover and that the "APN name" in the Service Selection mobility >> option cannot be decorated (i.e. making each APN unique), there is a >> need for a new identifier to uniquely identify PDN connections to the >> same APN. " >> >> I am confused by the case, could you please figure it more clearly? > > Right. Assume MN establishes three connections through the same radio > to the MAG. Connection 1 gets HNP1 and is identified with Service > Selection (SS) ="foo". Connection 2 gets HNP2 and is again identified > by SS="foo". Connection 3 gets HNP3 and is also identified by > SS="foo". This is possible by some popular access technologies already > today. MN and MAG also know these connections by some lower layer > identifier/radio level thing. > > When a handover takes place the MN re-attaches to a new MAG and starts > setting up connections to the new MAG. Now the MAG knows which > connection the MN sets up based on the SS and the "lower layer thing" > but does not necessarily know the associated HNP yet. So the PBU sent > to the LMA needs more info. Otherwise the LMA is not able to return > the correct HNP to the MAG. If the LMA were to return HNP1 for the > connection 2 after a handover that would break the IP connectivity in > the MN. That's why we propose to add "yet another" identifier to all > PBU/PBA messages. Using MN-LL would look tempting but the solution > must also work with one interface and cases where interfaces do not > have real identifiers (would mean overloading the existing meaning of > the MN-LL). > > Cheers, > Jouni > > >> >> Thanks in advance. >> >> Xiangsong >> >> ----- Original Message ----- From: "jouni" >> To: "Behcet Sarikaya" >> Cc: ; >> Sent: Monday, July 20, 2009 4:36 AM >> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >> connid-00 >> >> >>> Hi Behcet, >>> On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: >>> [snip] >>>>>>> >>>>>>> Hi Behcet, >>>>>>> >>>>>>> It is possible to assign multiple HNPs to an MN via RFC5213. >>>>>>> However it is >>>>>>> not possible to request dynamically (after initial attachment >>>>>>> and being >>>>>>> assigned an HNP and a BCE created) a new mobility session. >>>>>>> The LMA would essentially view a new PBU request from the MAG >>>>>>> for the MN as >>>>>>> being a renewal request and hence not assign a new HNP. I >>>>>>> think it is clear >>>>>>> (at least in the 3GPP EPC context) that it with RFC5213 it is >>>>>>> not possible >>>>>>> to establish multiple mobility sessions with the same LMA via >>>>>>> a single >>>>>>> interface. >>>>>> >>>>>> Yes, I think it is clear. The question is do we want to change it? >>>>> >>>>> Yes. Extend the capability by which the LMA is aware that the >>>>> PBU is a >>>>> request for establishing a new mobility session. >>>> >>>> That's what I was referring to as a big semantic change to PBU/PBA. >>> It is a change but I would not call it semantic change. Similar >>> type of extensions what you already have e.g. with RFC5149. What >>> the I-D adds here is more detail and a new key to help with >>> lookups to binding cache (obviously adds more data to binding >>> cache entries as well) when you want to identify exactly one of >>> several mobility sessions without really knowing its assigned HNP. >>>>> >>>>>> I think sending a non-renewal PBU is a big semantic change to >>>>>> the base >>>>>> protocol. >>>>> >>>>> Not really. A PBU can indicate already whether it is a result of >>>>> a HO or a >>>>> renewal or the result of a new attachment via a different >>>>> interface. >>>>> >>>>>> I was thinking that such a thing could happen below PMIP level >>>>>> possibly using >>>>>> the other prefix. I don't know what would you say to that? >>>>> >>>>> Not sure what you mean by "below PMIP level". Maybe you have >>>>> some other >>>>> ideas of how to achieve the same functionality. Also I don't >>>>> understand what >>>>> you mean by "the other prefix". What other prefix are you >>>>> refering to? When >>>>> the MN requests an additional mobility session, there is no >>>>> prefix assigned >>>>> to it yet. >>>> >>>> PBA sends more than one prefixes to MAG and MAG advertizes them. >>>> What does MN do? >>>> >>>> I think hosts create addresses for each prefix they receive. >>> If it is a case that PBA contains more than one HNP. This is, >>> however, always not the case. >>>> So my suggestion was to use a different address for each PDP >>>> connection. In fact you need a single address to >>> Eh? In this particular example, each PDN connection already has a >>> different HNP. The issue is that the HNP information is not enough, >>> or merely not available, when a link gets set up after a handover. >>>> access the Internet. More than one addresses create problems that >>>> MIF WG is trying to address. >>> This is a completely different discussion imho. >>> Cheers, >>> Jouni >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Telemaco.Melia@alcatel-lucent.com Tue Jul 21 02:22:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3413A6B72 for ; Tue, 21 Jul 2009 02:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.119 X-Spam-Level: X-Spam-Status: No, score=-5.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrcNdptn10w7 for ; Tue, 21 Jul 2009 02:22:54 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B00AD3A6C49 for ; Tue, 21 Jul 2009 02:22:53 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6L9LMhA008757; Tue, 21 Jul 2009 11:21:22 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 11:21:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2009 11:21:21 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C033DBE8C@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Solicitations for agenda items Thread-Index: AcnzivxC61+jN2dLQUmPraRThFoneQLcjTDQAqFedLwAGGE3kA== References: <853DD750D9C3724FBF2DF7164FCF641C032F9E93@FRVELSMBS14.ad2.ad.alcatel.com> From: "MELIA TELEMACO" To: , X-OriginalArrivalTime: 21 Jul 2009 09:21:22.0738 (UTC) FILETIME=[9D28F120:01CA09E4] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 09:22:57 -0000 Hi Raj, Fine with me, the main goal of the ID was to stimulate discussion around = the L2 vs. L3 matter. We will raise the issue during the Netext2 BOF. Telemaco -----Message d'origine----- De=A0: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Envoy=E9=A0: lundi 20 juillet 2009 23:40 =C0=A0: MELIA TELEMACO; netext@ietf.org Objet=A0: Re: [netext] Solicitations for agenda items Hi Telemaco, I don't see the need for discussing this I-D in the Netext WG meeting. = The content may be useful in the context of the discussion in the Netext2 = BoF meeting at IETF75. Based on the outcome of the Netext2 BoF, there may be an interest to consider this work in Netext (as informational). But given the current = scope and charter of Netext I don't see a need to allocate a slot for this I-D = at IETF75.=20 -Raj On 7/7/09 7:24 AM, "ext MELIA TELEMACO" = wrote: > Hello, >=20 > As a follow up of the discussions about Netext/Netext2 we would = request a slot > to present ID draft-melia-netext-3gpp-mn-ar-if-00.txt. >=20 > Cheers, > telemaco >=20 > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de > Basavaraj.Patil@nokia.com > Envoy=E9=A0: mardi 23 juin 2009 00:44 > =C0=A0: netext@ietf.org > Objet=A0: [netext] Solicitations for agenda items >=20 >=20 > Hello, >=20 > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. >=20 > Note that we will consider I-Ds that pertain to the scope of the = charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot. >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Tue Jul 21 02:36:41 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA433A6994 for ; Tue, 21 Jul 2009 02:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVigVH9F4vht for ; Tue, 21 Jul 2009 02:36:35 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 03CEF3A6A60 for ; Tue, 21 Jul 2009 02:36:34 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 697AE7EF450; Tue, 21 Jul 2009 11:23:58 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj.Patil@nokia.com In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WJTVhLItDkXwPGw3njvl" Organization: Universidad Carlos III de Madrid Date: Tue, 21 Jul 2009 11:24:01 +0200 Message-Id: <1248168241.4661.5.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16776.004 Cc: netext@ietf.org Subject: Re: [netext] Question on I-D: draft-bernardos-mif-pmip-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 09:36:41 -0000 --=-WJTVhLItDkXwPGw3njvl Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Raj, On Mon, 2009-07-20 at 22:25 +0200, Basavaraj.Patil@nokia.com wrote:=20 > Hello, >=20 > The I-D states: >=20 > " In the context of PMIPv6, current specification [RFC5213] does not > address the case of a MIF node attaching to a PMIPv6 domain. We > argue it is important to enable PMIPv6 to bring MIF nodes the > advantages related to the simultaneous use of multiple interfaces. > Moreover a MIF node could be seen as a not-modified host implementing > the right technology for multi-interface handling. > " >=20 > RFC5213 does support a multi-interface host to connect to a PMIP6 domain.= A > MIF host which attaches via multiple interfaces to a PMIP6 domain will be > assigned unique HNPs for each of the interfaces. A separate BCE is create= d > in the LMA for each interface. Hence I am not sure what you are refering = to > in the I-D w.r.t MIF hosts attaching to a PMIP6 domain. We are referring to use cases such as the one you mentions below. Current PMIPv6 specification does not fully address how to support multi-interfaces nodes, since a different mobility session is devoted for each interface, this making some things (such as flow mobility) hard to provide. In addition a MIF node could help to meet the no-host-modifications requirement as showed in the preliminary test we conducted. >=20 > The use case in Sec 3 is a bit more illustrative of the problem statement > that you are trying to solve. The capability to move a flow between > interfaces is being dealt with as part of the flow mobility work. This is= a > discussion item in the NetExt2 BoF at IETF75. The outcome of the BoF will > determine what we do in the NetExt WG w.r.t flow mobility. >=20 > The experiments that you have conducted on different OS' are interesting. Thanks, we plan to conduct more experiments in the future. We will further compound the initial experiments with a complete solution exploiting weak host model capabilities. Carlos >=20 > -Raj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-WJTVhLItDkXwPGw3njvl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpliTEACgkQNdy6TdFwT2f3bgCfdDNDHQYqOGSyI0LiTj2K0+6X nZ8Anjl47/FHWlb5hDOn0qu0l/E+5ooU =ecPF -----END PGP SIGNATURE----- --=-WJTVhLItDkXwPGw3njvl-- From jouni.nospam@gmail.com Wed Jul 22 00:37:46 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2B628C10C for ; Wed, 22 Jul 2009 00:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L26-nvg9h8TW for ; Wed, 22 Jul 2009 00:37:45 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 08BA728C103 for ; Wed, 22 Jul 2009 00:37:44 -0700 (PDT) Received: by bwz28 with SMTP id 28so5579bwz.37 for ; Wed, 22 Jul 2009 00:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=DBHFt2ufnYHKu3Zz9uJIoj7SZxCMb48h6t6Cczy/CWo=; b=Jzgf+AHUTNv91xfs7qfmkx3EH5RYwO/wzHz8Roc+ETU81neN953CI6hl7biHkybtxA AHRUg+2bmW0o63mHN6hVsImC68Cn4e9qQmFLLh4nSvapS3mlixW5XIX0URY1+ZXezddE h2LmKDiiL0YGWs3AyRIODeRywmCyX+NWRvlNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=eZe3oQjq+6T8zL/v/r+vkXHUtIYafD7S7Y8c+vxBDRJAK1LUw0TEwJv9SdqS++ivpi A+3by4C7bY0vRfH4lT9t0ppZ4VN5FnYGCismBtVSVukFCjqcW1BYSt+OnNBga0FDIKh3 XCZWEVjLQHX29M+ik8H6JENuZp6fp0ui9tRfY= Received: by 10.204.118.69 with SMTP id u5mr584680bkq.77.1248248168446; Wed, 22 Jul 2009 00:36:08 -0700 (PDT) Received: from a88-112-140-13.elisa-laajakaista.fi (a88-112-140-13.elisa-laajakaista.fi [88.112.140.13]) by mx.google.com with ESMTPS id g28sm16747fkg.15.2009.07.22.00.36.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 00:36:07 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <013501ca09de$ee79cd70$40106f0a@china.huawei.com> X-Priority: 3 References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> <9408201D-9CD1-4C73-9600-31AA3567B561@gmail.com> <013501ca09de$ee79cd70$40106f0a@china.huawei.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 10:36:06 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:37:47 -0000 Hi Xiangsong, On Jul 21, 2009, at 11:40 AM, Xiangsong Cui wrote: > Hi Jouni, > >> Right. Assume MN establishes three connections through the same >> radio to the MAG. Connection 1 gets HNP1 and is identified with >> Service > > Do you mean a MN has three 3GPP interface connection, or three WLAN > connection? > I don't understand the case, IMO, a MN may has a 3GPP interface + a > WLAN interface + a Wimax interface, but I can't image a MN with three > WLAN interfaces, do the interfaces use the same link layer address? So far we have been discussing about a single interface. > > Even in Nextext2, there is only inter RAT handover. Imho this is a separate topic. > If there is only one RAT, in my mind, there is only one connection, > to previous AR before handover and to new AR after handover. What type of connection you are talking about here. The draft discusses about PDN Connections. Cheers, Jouni > > Xiangsong > > > ----- Original Message ----- From: "jouni korhonen" > > To: "Xiangsong Cui" > Cc: ; > Sent: Tuesday, July 21, 2009 4:18 PM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- > connid-00 > > >> Hi Xiangsong, >> See inline. >> On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote: >>> Hi Jouni, >>> >>> I also wonder at the motivation. >>> >>>> Similar type of extensions what you already have e.g. with >>>> RFC5149. What the I-D adds here is more detail and a new key to >>>> help with lookups to binding >>> >>> Yes, RFC5149 introduces some extensions, we can accept the >>> extension because there are many use cases. >>> Can you give us some use case too? >>> >>> From the draft, it says: >>> " However, in a case of multiple PDN >>> connections to the same APN, and assuming that Home Network Prefixes >>> (HNP) are not always available in a Mobile Access Gateway (MAG) >>> after >>> a handover and that the "APN name" in the Service Selection mobility >>> option cannot be decorated (i.e. making each APN unique), there is a >>> need for a new identifier to uniquely identify PDN connections to >>> the >>> same APN. " >>> >>> I am confused by the case, could you please figure it more clearly? >> Right. Assume MN establishes three connections through the same >> radio to the MAG. Connection 1 gets HNP1 and is identified with >> Service Selection (SS) ="foo". Connection 2 gets HNP2 and is again >> identified by SS="foo". Connection 3 gets HNP3 and is also >> identified by SS="foo". This is possible by some popular access >> technologies already today. MN and MAG also know these connections >> by some lower layer identifier/radio level thing. >> When a handover takes place the MN re-attaches to a new MAG and >> starts setting up connections to the new MAG. Now the MAG knows >> which connection the MN sets up based on the SS and the "lower >> layer thing" but does not necessarily know the associated HNP yet. >> So the PBU sent to the LMA needs more info. Otherwise the LMA is >> not able to return the correct HNP to the MAG. If the LMA were to >> return HNP1 for the connection 2 after a handover that would break >> the IP connectivity in the MN. That's why we propose to add "yet >> another" identifier to all PBU/PBA messages. Using MN-LL would >> look tempting but the solution must also work with one interface >> and cases where interfaces do not have real identifiers (would >> mean overloading the existing meaning of the MN-LL). >> Cheers, >> Jouni >>> >>> Thanks in advance. >>> >>> Xiangsong >>> >>> ----- Original Message ----- From: "jouni" >>> To: "Behcet Sarikaya" >>> Cc: ; >>> Sent: Monday, July 20, 2009 4:36 AM >>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >>> connid-00 >>> >>> >>>> Hi Behcet, >>>> On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: >>>> [snip] >>>>>>>> >>>>>>>> Hi Behcet, >>>>>>>> >>>>>>>> It is possible to assign multiple HNPs to an MN via >>>>>>>> RFC5213. However it is >>>>>>>> not possible to request dynamically (after initial >>>>>>>> attachment and being >>>>>>>> assigned an HNP and a BCE created) a new mobility session. >>>>>>>> The LMA would essentially view a new PBU request from the >>>>>>>> MAG for the MN as >>>>>>>> being a renewal request and hence not assign a new HNP. I >>>>>>>> think it is clear >>>>>>>> (at least in the 3GPP EPC context) that it with RFC5213 it >>>>>>>> is not possible >>>>>>>> to establish multiple mobility sessions with the same LMA >>>>>>>> via a single >>>>>>>> interface. >>>>>>> >>>>>>> Yes, I think it is clear. The question is do we want to change >>>>>>> it? >>>>>> >>>>>> Yes. Extend the capability by which the LMA is aware that the >>>>>> PBU is a >>>>>> request for establishing a new mobility session. >>>>> >>>>> That's what I was referring to as a big semantic change to PBU/ >>>>> PBA. >>>> It is a change but I would not call it semantic change. Similar >>>> type of extensions what you already have e.g. with RFC5149. >>>> What the I-D adds here is more detail and a new key to help >>>> with lookups to binding cache (obviously adds more data to >>>> binding cache entries as well) when you want to identify >>>> exactly one of several mobility sessions without really knowing >>>> its assigned HNP. >>>>>> >>>>>>> I think sending a non-renewal PBU is a big semantic change to >>>>>>> the base >>>>>>> protocol. >>>>>> >>>>>> Not really. A PBU can indicate already whether it is a result >>>>>> of a HO or a >>>>>> renewal or the result of a new attachment via a different >>>>>> interface. >>>>>> >>>>>>> I was thinking that such a thing could happen below PMIP >>>>>>> level possibly using >>>>>>> the other prefix. I don't know what would you say to that? >>>>>> >>>>>> Not sure what you mean by "below PMIP level". Maybe you have >>>>>> some other >>>>>> ideas of how to achieve the same functionality. Also I don't >>>>>> understand what >>>>>> you mean by "the other prefix". What other prefix are you >>>>>> refering to? When >>>>>> the MN requests an additional mobility session, there is no >>>>>> prefix assigned >>>>>> to it yet. >>>>> >>>>> PBA sends more than one prefixes to MAG and MAG advertizes >>>>> them. What does MN do? >>>>> >>>>> I think hosts create addresses for each prefix they receive. >>>> If it is a case that PBA contains more than one HNP. This is, >>>> however, always not the case. >>>>> So my suggestion was to use a different address for each PDP >>>>> connection. In fact you need a single address to >>>> Eh? In this particular example, each PDN connection already has >>>> a different HNP. The issue is that the HNP information is not >>>> enough, or merely not available, when a link gets set up after >>>> a handover. >>>>> access the Internet. More than one addresses create problems >>>>> that MIF WG is trying to address. >>>> This is a completely different discussion imho. >>>> Cheers, >>>> Jouni >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Wed Jul 22 02:43:28 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333AF3A67F9 for ; Wed, 22 Jul 2009 02:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=1.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vphA-WM59yqK for ; Wed, 22 Jul 2009 02:43:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id F06D93A6B4D for ; Wed, 22 Jul 2009 02:43:25 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN60003PGA19V@szxga01-in.huawei.com> for netext@ietf.org; Wed, 22 Jul 2009 17:42:02 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN6003XDGA098@szxga01-in.huawei.com> for netext@ietf.org; Wed, 22 Jul 2009 17:42:01 +0800 (CST) Date: Wed, 22 Jul 2009 17:42:00 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <0d3e01ca0ab0$aa07a4f0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> <9408201D-9CD1-4C73-9600-31AA3567B561@gmail.com> <013501ca09de$ee79cd70$40106f0a@china.huawei.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:43:28 -0000 Yes, I know the draft is discussing PDN connections. But I don't know, in what a scenario, a MN can establish multiple connections to one PDN? Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Wednesday, July 22, 2009 3:36 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > Hi Xiangsong, > > On Jul 21, 2009, at 11:40 AM, Xiangsong Cui wrote: > >> Hi Jouni, >> >>> Right. Assume MN establishes three connections through the same radio >>> to the MAG. Connection 1 gets HNP1 and is identified with Service >> >> Do you mean a MN has three 3GPP interface connection, or three WLAN >> connection? >> I don't understand the case, IMO, a MN may has a 3GPP interface + a >> WLAN interface + a Wimax interface, but I can't image a MN with three >> WLAN interfaces, do the interfaces use the same link layer address? > > So far we have been discussing about a single interface. > >> >> Even in Nextext2, there is only inter RAT handover. > > Imho this is a separate topic. > > >> If there is only one RAT, in my mind, there is only one connection, >> to previous AR before handover and to new AR after handover. > > What type of connection you are talking about here. The draft discusses > about PDN Connections. > > Cheers, > Jouni > > >> >> Xiangsong >> >> >> ----- Original Message ----- From: "jouni korhonen" >> > > >> To: "Xiangsong Cui" >> Cc: ; >> Sent: Tuesday, July 21, 2009 4:18 PM >> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >> connid-00 >> >> >>> Hi Xiangsong, >>> See inline. >>> On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>> Hi Jouni, >>>> >>>> I also wonder at the motivation. >>>> >>>>> Similar type of extensions what you already have e.g. with RFC5149. >>>>> What the I-D adds here is more detail and a new key to help with >>>>> lookups to binding >>>> >>>> Yes, RFC5149 introduces some extensions, we can accept the extension >>>> because there are many use cases. >>>> Can you give us some use case too? >>>> >>>> From the draft, it says: >>>> " However, in a case of multiple PDN >>>> connections to the same APN, and assuming that Home Network Prefixes >>>> (HNP) are not always available in a Mobile Access Gateway (MAG) after >>>> a handover and that the "APN name" in the Service Selection mobility >>>> option cannot be decorated (i.e. making each APN unique), there is a >>>> need for a new identifier to uniquely identify PDN connections to the >>>> same APN. " >>>> >>>> I am confused by the case, could you please figure it more clearly? >>> Right. Assume MN establishes three connections through the same radio >>> to the MAG. Connection 1 gets HNP1 and is identified with Service >>> Selection (SS) ="foo". Connection 2 gets HNP2 and is again identified >>> by SS="foo". Connection 3 gets HNP3 and is also identified by >>> SS="foo". This is possible by some popular access technologies already >>> today. MN and MAG also know these connections by some lower layer >>> identifier/radio level thing. >>> When a handover takes place the MN re-attaches to a new MAG and starts >>> setting up connections to the new MAG. Now the MAG knows which >>> connection the MN sets up based on the SS and the "lower layer thing" >>> but does not necessarily know the associated HNP yet. So the PBU sent >>> to the LMA needs more info. Otherwise the LMA is not able to return >>> the correct HNP to the MAG. If the LMA were to return HNP1 for the >>> connection 2 after a handover that would break the IP connectivity in >>> the MN. That's why we propose to add "yet another" identifier to all >>> PBU/PBA messages. Using MN-LL would look tempting but the solution >>> must also work with one interface and cases where interfaces do not >>> have real identifiers (would mean overloading the existing meaning of >>> the MN-LL). >>> Cheers, >>> Jouni >>>> >>>> Thanks in advance. >>>> >>>> Xiangsong >>>> >>>> ----- Original Message ----- From: "jouni" >>>> To: "Behcet Sarikaya" >>>> Cc: ; >>>> Sent: Monday, July 20, 2009 4:36 AM >>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >>>> connid-00 >>>> >>>> >>>>> Hi Behcet, >>>>> On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: >>>>> [snip] >>>>>>>>> >>>>>>>>> Hi Behcet, >>>>>>>>> >>>>>>>>> It is possible to assign multiple HNPs to an MN via RFC5213. >>>>>>>>> However it is >>>>>>>>> not possible to request dynamically (after initial attachment >>>>>>>>> and being >>>>>>>>> assigned an HNP and a BCE created) a new mobility session. >>>>>>>>> The LMA would essentially view a new PBU request from the MAG >>>>>>>>> for the MN as >>>>>>>>> being a renewal request and hence not assign a new HNP. I think >>>>>>>>> it is clear >>>>>>>>> (at least in the 3GPP EPC context) that it with RFC5213 it is >>>>>>>>> not possible >>>>>>>>> to establish multiple mobility sessions with the same LMA via a >>>>>>>>> single >>>>>>>>> interface. >>>>>>>> >>>>>>>> Yes, I think it is clear. The question is do we want to change it? >>>>>>> >>>>>>> Yes. Extend the capability by which the LMA is aware that the PBU >>>>>>> is a >>>>>>> request for establishing a new mobility session. >>>>>> >>>>>> That's what I was referring to as a big semantic change to PBU/ PBA. >>>>> It is a change but I would not call it semantic change. Similar type >>>>> of extensions what you already have e.g. with RFC5149. What the I-D >>>>> adds here is more detail and a new key to help with lookups to >>>>> binding cache (obviously adds more data to binding cache entries as >>>>> well) when you want to identify exactly one of several mobility >>>>> sessions without really knowing its assigned HNP. >>>>>>> >>>>>>>> I think sending a non-renewal PBU is a big semantic change to the >>>>>>>> base >>>>>>>> protocol. >>>>>>> >>>>>>> Not really. A PBU can indicate already whether it is a result of a >>>>>>> HO or a >>>>>>> renewal or the result of a new attachment via a different >>>>>>> interface. >>>>>>> >>>>>>>> I was thinking that such a thing could happen below PMIP level >>>>>>>> possibly using >>>>>>>> the other prefix. I don't know what would you say to that? >>>>>>> >>>>>>> Not sure what you mean by "below PMIP level". Maybe you have some >>>>>>> other >>>>>>> ideas of how to achieve the same functionality. Also I don't >>>>>>> understand what >>>>>>> you mean by "the other prefix". What other prefix are you refering >>>>>>> to? When >>>>>>> the MN requests an additional mobility session, there is no prefix >>>>>>> assigned >>>>>>> to it yet. >>>>>> >>>>>> PBA sends more than one prefixes to MAG and MAG advertizes them. >>>>>> What does MN do? >>>>>> >>>>>> I think hosts create addresses for each prefix they receive. >>>>> If it is a case that PBA contains more than one HNP. This is, >>>>> however, always not the case. >>>>>> So my suggestion was to use a different address for each PDP >>>>>> connection. In fact you need a single address to >>>>> Eh? In this particular example, each PDN connection already has a >>>>> different HNP. The issue is that the HNP information is not enough, >>>>> or merely not available, when a link gets set up after a handover. >>>>>> access the Internet. More than one addresses create problems that >>>>>> MIF WG is trying to address. >>>>> This is a completely different discussion imho. >>>>> Cheers, >>>>> Jouni >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext > From Xiangsong.Cui@huawei.com Wed Jul 22 02:59:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6733A6A3C for ; Wed, 22 Jul 2009 02:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.576 X-Spam-Level: X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbppXdO-EHDl for ; Wed, 22 Jul 2009 02:59:34 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E13C43A68DA for ; Wed, 22 Jul 2009 02:59:33 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN6001NGH0U8G@szxga02-in.huawei.com> for netext@ietf.org; Wed, 22 Jul 2009 17:58:07 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN6005ZGH0UHO@szxga02-in.huawei.com> for netext@ietf.org; Wed, 22 Jul 2009 17:58:06 +0800 (CST) Date: Wed, 22 Jul 2009 17:58:06 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <0d4901ca0ab2$e9472210$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:59:35 -0000 I have a question about the item #12, the draft "bulk-re-registration". In the section 1, there is a formula: transactions/sec = (number of registered MNs) / (binding lifetime*4) I don't understand it, why we multiply lifetime by 4? In my mind, there are two messages in the re-register flow, a PBU message and a PBA message, and the re-register interval is the lifetime. A PBU and a PBA also constitutes one transaction. So, for one MN, in the duration of the lifetime, there are two messages, and the message rate is: message/sec = 2/lifetime, the transaction rate is: transaction/sec = 1/lifetime. For a MAG or a LMA, the total transaction rate is: transactions/sec = (number of registered MNs) / binding lifetime. Is it right? Regards Xiangsong ----- Original Message ----- From: To: ; Sent: Wednesday, July 15, 2009 1:34 AM Subject: Re: [netext] Agenda Requests received > > As of 7/14 the chairs have received requests for agenda slots at IETF75. > We would like to encourage WG members to review the I-Ds and provide > feedback on the list prior to the meeting itself. > > -Chairs > > > Agenda requests received: > > 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 > I-D: draft-korhonen-netext-redirect-02 > Jouni Korhonen - 10 Mins > > 2. Localized Routing > PMIPv6 Localized Routing Problem Statement > I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt > PS and Scope discussion 10 Mins > Solutions 15 Mins > Marco Liebsch et al. > > Proxy MIP extension for local routing optimization > I-D: draft-wu-netext-local-ro-02.txt > Behcet Sarikaya 5 Mins > > 3. Tunnel Negotiation for Proxy Mobile IPv6 > I-D: draft-xia-netext-tunnel-negotiation-01.txt > Frank Xia 10 Mins > > 4. Mobile Node Group Identifier Option: > I-D: draft-gundavelli-netext-mn-groupid-option-01 > Sri Gundavelli 10 Mins > > 5. Retransmit Message Identifier Option: > I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt > Sri Gundavelli 10 Mins > > 6. Mobility session suspend > I-D: draft-muhanna-netext-mobility-session-suspend-00.txt > Ahmad Muhanna 10 Mins > > 7. Trace Control Support for Proxy Mobile IPv6 > I-D: draft-wang-netext-trace-control-00.txt > Yungui Wang 10 Mins > > 8. Multihoming extensions for Proxy Mobile IPv6 > I-D: draft-bernardos-mif-pmip-00.txt > Telemaco, Pierrick and Carlos 10 Mins > > 9. 3GPP MN-AR interface > I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt > Telemaco 5 Mins > > 10. Service Flow Identifier in Proxy Mobile IPv6 > I-D: draft-hui-netext-service-flow-identifier-00.txt > Min Hui 10 Mins > > 11. Connection Identifier for Proxy Mobile IPv6 > I-D: draft-wolfner-netext-pmip6-connid-00 > Jouni Korhonen 5 Mins > > 12. Bulk Re-registration for Proxy Mobile IPv6 > I-D: draft-premec-netlmm-bulk-re-registration-02 > Jouni Korhonen 5 Mins > > 13. Partial Handoff Support in PMIPv6 > I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 > Mohana Jeyatharan > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Wed Jul 22 03:44:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420CE3A6C11 for ; Wed, 22 Jul 2009 03:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYaRB4u4bQBG for ; Wed, 22 Jul 2009 03:44:44 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 5739C3A6C10 for ; Wed, 22 Jul 2009 03:44:43 -0700 (PDT) Received: by bwz28 with SMTP id 28so92206bwz.37 for ; Wed, 22 Jul 2009 03:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=MFgVq8Wce7V0V+fVi/DDnSY5Hph1yiusRmDfbAO5h8c=; b=QKy0m6sqqaS4AUuSqGgzYu+C4vYe/hgWAogteQFzkAhDFL4OuLejBNQ2BZtvVxyL0H 4/zZO6T3bYMungcfFkTBmjVjPqpG0EnSRQJuNkUOGRKkulrjjheTlnD6P76+ghY9Tq15 //0DkYlZ37o/+oZpkQ3GFmUJT/t13wACrBTMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=vTqg0G/s5zAm1ozYkorpom+ITHWchXqRrt12FjxsJf7mKWs87EgOf2kDb/n56OPGQ/ nRDP/PnSwUzZOTsL8Spq4+hbuX31jlXwfkcPFYmR3QGtV2diydGe0DU82wh6eORZ8GFF DG15uUZGKLT3EuX+uQgWaUfCBOrS+Ddlu+Pio= Received: by 10.204.58.73 with SMTP id f9mr684541bkh.164.1248257469811; Wed, 22 Jul 2009 03:11:09 -0700 (PDT) Received: from a88-112-140-13.elisa-laajakaista.fi (a88-112-140-13.elisa-laajakaista.fi [88.112.140.13]) by mx.google.com with ESMTPS id y15sm239533fkd.47.2009.07.22.03.11.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 03:11:09 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <0d3e01ca0ab0$aa07a4f0$40106f0a@china.huawei.com> X-Priority: 3 References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> <9408201D-9CD1-4C73-9600-31AA3567B561@gmail.com> <013501ca09de$ee79cd70$40106f0a@china.huawei.com> <0d3e01ca0ab0$aa07a4f0$40106f0a@china.huawei.com> Message-Id: <30083ADE-A33C-45C8-945D-8371EB5FEC84@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 13:11:07 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:44:45 -0000 On Jul 22, 2009, at 12:42 PM, Xiangsong Cui wrote: > Yes, I know the draft is discussing PDN connections. > But I don't know, in what a scenario, a MN can establish > multiple connections to one PDN? Multiple PDN Connections to the same Service (i.e. APN). Not the other way around. Cheers, Jouni > > Xiangsong > > > ----- Original Message ----- From: "jouni korhonen" > > To: "Xiangsong Cui" > Cc: ; > Sent: Wednesday, July 22, 2009 3:36 PM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- > connid-00 > > >> Hi Xiangsong, >> >> On Jul 21, 2009, at 11:40 AM, Xiangsong Cui wrote: >> >>> Hi Jouni, >>> >>>> Right. Assume MN establishes three connections through the same >>>> radio to the MAG. Connection 1 gets HNP1 and is identified with >>>> Service >>> >>> Do you mean a MN has three 3GPP interface connection, or three >>> WLAN connection? >>> I don't understand the case, IMO, a MN may has a 3GPP interface + a >>> WLAN interface + a Wimax interface, but I can't image a MN with >>> three >>> WLAN interfaces, do the interfaces use the same link layer address? >> >> So far we have been discussing about a single interface. >> >>> >>> Even in Nextext2, there is only inter RAT handover. >> >> Imho this is a separate topic. >> >> >>> If there is only one RAT, in my mind, there is only one connection, >>> to previous AR before handover and to new AR after handover. >> >> What type of connection you are talking about here. The draft >> discusses about PDN Connections. >> >> Cheers, >> Jouni >> >> >>> >>> Xiangsong >>> >>> >>> ----- Original Message ----- From: "jouni korhonen" >> > >>> To: "Xiangsong Cui" >>> Cc: ; >>> Sent: Tuesday, July 21, 2009 4:18 PM >>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >>> connid-00 >>> >>> >>>> Hi Xiangsong, >>>> See inline. >>>> On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>>> Hi Jouni, >>>>> >>>>> I also wonder at the motivation. >>>>> >>>>>> Similar type of extensions what you already have e.g. with >>>>>> RFC5149. What the I-D adds here is more detail and a new key >>>>>> to help with lookups to binding >>>>> >>>>> Yes, RFC5149 introduces some extensions, we can accept the >>>>> extension because there are many use cases. >>>>> Can you give us some use case too? >>>>> >>>>> From the draft, it says: >>>>> " However, in a case of multiple PDN >>>>> connections to the same APN, and assuming that Home Network >>>>> Prefixes >>>>> (HNP) are not always available in a Mobile Access Gateway (MAG) >>>>> after >>>>> a handover and that the "APN name" in the Service Selection >>>>> mobility >>>>> option cannot be decorated (i.e. making each APN unique), there >>>>> is a >>>>> need for a new identifier to uniquely identify PDN connections >>>>> to the >>>>> same APN. " >>>>> >>>>> I am confused by the case, could you please figure it more >>>>> clearly? >>>> Right. Assume MN establishes three connections through the same >>>> radio to the MAG. Connection 1 gets HNP1 and is identified with >>>> Service Selection (SS) ="foo". Connection 2 gets HNP2 and is >>>> again identified by SS="foo". Connection 3 gets HNP3 and is >>>> also identified by SS="foo". This is possible by some popular >>>> access technologies already today. MN and MAG also know these >>>> connections by some lower layer identifier/radio level thing. >>>> When a handover takes place the MN re-attaches to a new MAG and >>>> starts setting up connections to the new MAG. Now the MAG knows >>>> which connection the MN sets up based on the SS and the "lower >>>> layer thing" but does not necessarily know the associated HNP >>>> yet. So the PBU sent to the LMA needs more info. Otherwise the >>>> LMA is not able to return the correct HNP to the MAG. If the LMA >>>> were to return HNP1 for the connection 2 after a handover that >>>> would break the IP connectivity in the MN. That's why we propose >>>> to add "yet another" identifier to all PBU/PBA messages. Using >>>> MN-LL would look tempting but the solution must also work with >>>> one interface and cases where interfaces do not have real >>>> identifiers (would mean overloading the existing meaning of the >>>> MN-LL). >>>> Cheers, >>>> Jouni >>>>> >>>>> Thanks in advance. >>>>> >>>>> Xiangsong >>>>> >>>>> ----- Original Message ----- From: "jouni" >>>>> >>>>> To: "Behcet Sarikaya" >>>>> Cc: ; >>>>> Sent: Monday, July 20, 2009 4:36 AM >>>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- >>>>> pmip6- connid-00 >>>>> >>>>> >>>>>> Hi Behcet, >>>>>> On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: >>>>>> [snip] >>>>>>>>>> >>>>>>>>>> Hi Behcet, >>>>>>>>>> >>>>>>>>>> It is possible to assign multiple HNPs to an MN via >>>>>>>>>> RFC5213. However it is >>>>>>>>>> not possible to request dynamically (after initial >>>>>>>>>> attachment and being >>>>>>>>>> assigned an HNP and a BCE created) a new mobility session. >>>>>>>>>> The LMA would essentially view a new PBU request from the >>>>>>>>>> MAG for the MN as >>>>>>>>>> being a renewal request and hence not assign a new HNP. I >>>>>>>>>> think it is clear >>>>>>>>>> (at least in the 3GPP EPC context) that it with RFC5213 it >>>>>>>>>> is not possible >>>>>>>>>> to establish multiple mobility sessions with the same LMA >>>>>>>>>> via a single >>>>>>>>>> interface. >>>>>>>>> >>>>>>>>> Yes, I think it is clear. The question is do we want to >>>>>>>>> change it? >>>>>>>> >>>>>>>> Yes. Extend the capability by which the LMA is aware that >>>>>>>> the PBU is a >>>>>>>> request for establishing a new mobility session. >>>>>>> >>>>>>> That's what I was referring to as a big semantic change to >>>>>>> PBU/ PBA. >>>>>> It is a change but I would not call it semantic change. >>>>>> Similar type of extensions what you already have e.g. with >>>>>> RFC5149. What the I-D adds here is more detail and a new key >>>>>> to help with lookups to binding cache (obviously adds more >>>>>> data to binding cache entries as well) when you want to >>>>>> identify exactly one of several mobility sessions without >>>>>> really knowing its assigned HNP. >>>>>>>> >>>>>>>>> I think sending a non-renewal PBU is a big semantic change >>>>>>>>> to the base >>>>>>>>> protocol. >>>>>>>> >>>>>>>> Not really. A PBU can indicate already whether it is a >>>>>>>> result of a HO or a >>>>>>>> renewal or the result of a new attachment via a different >>>>>>>> interface. >>>>>>>> >>>>>>>>> I was thinking that such a thing could happen below PMIP >>>>>>>>> level possibly using >>>>>>>>> the other prefix. I don't know what would you say to that? >>>>>>>> >>>>>>>> Not sure what you mean by "below PMIP level". Maybe you >>>>>>>> have some other >>>>>>>> ideas of how to achieve the same functionality. Also I don't >>>>>>>> understand what >>>>>>>> you mean by "the other prefix". What other prefix are you >>>>>>>> refering to? When >>>>>>>> the MN requests an additional mobility session, there is no >>>>>>>> prefix assigned >>>>>>>> to it yet. >>>>>>> >>>>>>> PBA sends more than one prefixes to MAG and MAG advertizes >>>>>>> them. What does MN do? >>>>>>> >>>>>>> I think hosts create addresses for each prefix they receive. >>>>>> If it is a case that PBA contains more than one HNP. This is, >>>>>> however, always not the case. >>>>>>> So my suggestion was to use a different address for each PDP >>>>>>> connection. In fact you need a single address to >>>>>> Eh? In this particular example, each PDN connection already >>>>>> has a different HNP. The issue is that the HNP information is >>>>>> not enough, or merely not available, when a link gets set up >>>>>> after a handover. >>>>>>> access the Internet. More than one addresses create problems >>>>>>> that MIF WG is trying to address. >>>>>> This is a completely different discussion imho. >>>>>> Cheers, >>>>>> Jouni >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext > From jouni.nospam@gmail.com Wed Jul 22 04:15:59 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975433A6948 for ; Wed, 22 Jul 2009 04:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDQ2EkujCgyZ for ; Wed, 22 Jul 2009 04:15:58 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id D11B83A6C1C for ; Wed, 22 Jul 2009 04:15:57 -0700 (PDT) Received: by bwz28 with SMTP id 28so107622bwz.37 for ; Wed, 22 Jul 2009 04:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=F/xkTM2u6onGPQRDj9LG8z8gszjRxGqOWQsZg2AokmA=; b=Dz8ktHSKqpfvfiyEvC7NpljqPXyy+XT2TmqSosYy/gSUJv3RciOvrk01MQHHTdiJjC 4BK8YbxKXcgB2/DgAce53XjjcxENd3qI/Iy1pR8W8blPnckKUCFjLtrnDEyhDp9wx2uQ Bof94ms1hKBQGuqXdMn5ZTKs1fFrYa9l7vBNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=cQ+KFHL8X7f2hYSYl0ozcKKSZi7pqWnmREq9NP01bytFGF8IcqCkOV77t2yW8uqQDc SGIlKyQRAL95gN9IWD/wHC7sKYT5wO9joM7askT0G50BVUvGSlPs8XzZYyPUNQtIwdRb mjMiIOeCjO9q9Ufx8gpo+Q6KDN0X5bdaHGi1Y= Received: by 10.204.115.139 with SMTP id i11mr729936bkq.199.1248261266499; Wed, 22 Jul 2009 04:14:26 -0700 (PDT) Received: from a88-112-140-13.elisa-laajakaista.fi (a88-112-140-13.elisa-laajakaista.fi [88.112.140.13]) by mx.google.com with ESMTPS id g28sm354056fkg.45.2009.07.22.04.14.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 04:14:26 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <0d4901ca0ab2$e9472210$40106f0a@china.huawei.com> X-Priority: 3 References: <0d4901ca0ab2$e9472210$40106f0a@china.huawei.com> Message-Id: <051017E8-0188-4FF3-8238-18278DC30C8F@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 14:14:24 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:15:59 -0000 Hi Xiangsong, On Jul 22, 2009, at 12:58 PM, Xiangsong Cui wrote: > I have a question about the item #12, > the draft "bulk-re-registration". > > In the section 1, there is a formula: > transactions/sec = (number of registered MNs) / (binding lifetime*4) > I don't understand it, why we multiply lifetime by 4? The lifetime is expressed as a unit of 4 seconds. See Section 6.1.7. of RFC3775. The 'lifetime' here means the value inside the PBU message. Cheers, Jouni > > In my mind, there are two messages in the re-register flow, a PBU > message and a PBA message, and the re-register interval is the > lifetime. > A PBU and a PBA also constitutes one transaction. > So, for one MN, in the duration of the lifetime, there are two > messages, > and the message rate is: message/sec = 2/lifetime, > the transaction rate is: transaction/sec = 1/lifetime. > For a MAG or a LMA, the total transaction rate is: > transactions/sec = (number of registered MNs) / binding lifetime. > > Is it right? > > Regards > Xiangsong > > > ----- Original Message ----- From: > To: ; > Sent: Wednesday, July 15, 2009 1:34 AM > Subject: Re: [netext] Agenda Requests received > > >> As of 7/14 the chairs have received requests for agenda slots at >> IETF75. >> We would like to encourage WG members to review the I-Ds and provide >> feedback on the list prior to the meeting itself. >> -Chairs >> Agenda requests received: >> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >> I-D: draft-korhonen-netext-redirect-02 >> Jouni Korhonen - 10 Mins >> 2. Localized Routing >> PMIPv6 Localized Routing Problem Statement >> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >> PS and Scope discussion 10 Mins >> Solutions 15 Mins >> Marco Liebsch et al. >> Proxy MIP extension for local routing optimization >> I-D: draft-wu-netext-local-ro-02.txt >> Behcet Sarikaya 5 Mins >> 3. Tunnel Negotiation for Proxy Mobile IPv6 >> I-D: draft-xia-netext-tunnel-negotiation-01.txt >> Frank Xia 10 Mins >> 4. Mobile Node Group Identifier Option: >> I-D: draft-gundavelli-netext-mn-groupid-option-01 >> Sri Gundavelli 10 Mins >> 5. Retransmit Message Identifier Option: >> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >> Sri Gundavelli 10 Mins >> 6. Mobility session suspend >> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >> Ahmad Muhanna 10 Mins >> 7. Trace Control Support for Proxy Mobile IPv6 >> I-D: draft-wang-netext-trace-control-00.txt >> Yungui Wang 10 Mins >> 8. Multihoming extensions for Proxy Mobile IPv6 >> I-D: draft-bernardos-mif-pmip-00.txt >> Telemaco, Pierrick and Carlos 10 Mins >> 9. 3GPP MN-AR interface >> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >> Telemaco 5 Mins >> 10. Service Flow Identifier in Proxy Mobile IPv6 >> I-D: draft-hui-netext-service-flow-identifier-00.txt >> Min Hui 10 Mins >> 11. Connection Identifier for Proxy Mobile IPv6 >> I-D: draft-wolfner-netext-pmip6-connid-00 >> Jouni Korhonen 5 Mins >> 12. Bulk Re-registration for Proxy Mobile IPv6 >> I-D: draft-premec-netlmm-bulk-re-registration-02 >> Jouni Korhonen 5 Mins >> 13. Partial Handoff Support in PMIPv6 >> I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >> Mohana Jeyatharan >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Jul 22 14:44:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29D53A68A8 for ; Wed, 22 Jul 2009 14:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwoVF91eb5FV for ; Wed, 22 Jul 2009 14:44:44 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B589A3A67AA for ; Wed, 22 Jul 2009 14:44:43 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6MLh6xl010099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Jul 2009 00:43:07 +0300 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6MLdojt031890 for ; Thu, 23 Jul 2009 00:39:53 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 00:39:41 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 00:39:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 00:39:32 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 22 Jul 2009 23:39:31 +0200 From: "Basavaraj.Patil@nokia.com" To: Date: Wed, 22 Jul 2009 23:39:47 +0200 Thread-Topic: Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt Thread-Index: AcoLFO74Jz4WBqLf90iiyx0HVkSy8Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2009 21:39:32.0661 (UTC) FILETIME=[E66C9E50:01CA0B14] X-Nokia-AV: Clean Subject: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:44:44 -0000 After reviewing this I-D I have the following comments: 1. Why do we need a tunnel negotiation mechanism? Is the protocol broken without such capability? No. Does this negotiation make the protocol operation somehow more optimal? I dont believe that is the case either. 2. The I-D states that the LMA and MAG may have different capabilities and preferences. However a MAG is part of the PMIP6 domain. The MAG/LMA have a security association between them. Hence it is unlikely that the LMA or MAG will be unaware of the tunnelling capabilities or preferences. The document does not provide a strong reason why such negotiation is needed. 3. Deployments will choose to use either GRE or IP-in-IP tunnelling between the MAG/LMA depending on the requirements. Negotiating the type of tunnelling in the signaling is not required. It might be useful to provide a better explanation of the problems in choosing a tunnelling method between the MAG/LMA which would warrant such negotiation. But in the absence of such I dont think we really need to go down this route. -Raj From xiayangsong@huawei.com Wed Jul 22 15:20:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022933A6C45 for ; Wed, 22 Jul 2009 15:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZHlt+hgZJpB for ; Wed, 22 Jul 2009 15:20:56 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0A8833A69FB for ; Wed, 22 Jul 2009 15:20:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7001JLFBSB3@szxga04-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 06:19:04 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700LOBFBSYF@szxga04-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 06:19:04 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN700NJAFBP2F@szxml06-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 06:19:04 +0800 (CST) Date: Wed, 22 Jul 2009 17:19:01 -0500 From: Frank Xia To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <011801ca0b1a$6bb9bbb0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:20:57 -0000 Hi Raj Thank for your review. Please check my response... BR Frank ----- Original Message ----- From: To: Sent: Wednesday, July 22, 2009 4:39 PM Subject: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt > > After reviewing this I-D I have the following comments: > > 1. Why do we need a tunnel negotiation mechanism? Is the protocol > broken without such capability? No. > Does this negotiation make the protocol operation somehow more > optimal? I dont believe that is the case either. Frank=>Yes. Here is a use case. LMA is related to muliple MAGs. MAG 1 may choose IPv6/IPv4 in IPv6, MAG 2 may select GRE, MAG 3 prefers IPsec ESP, while MAG 4 picks IPv6/IPv4 in IPv4-UDP. Without negotiation mechanism, LMA must implement all the tunnel! > > 2. The I-D states that the LMA and MAG may have different capabilities > and preferences. However a MAG is part of the PMIP6 domain. The > MAG/LMA have a security association between them. Hence it is > unlikely that the LMA or MAG will be unaware of the tunnelling > capabilities or preferences. The document does not provide a strong > reason why such negotiation is needed. Frank=> LMA and MAG are very possible located in different domains. For example, non-3GPP accesses (such as WiMAX ASN-GW) belong to domains which are different from 3GPP core network domains. > > 3. Deployments will choose to use either GRE or IP-in-IP > tunnelling between the MAG/LMA depending on the > requirements. Negotiating the type of tunnelling in the signaling > is not required. Frank=> Just we list in the documents, there are a bunch of tunnels. I could not find requirements in SDO's specification on the criteria of selecting a tunnel. 0x01: IPv6/IPv4 in IPv6 0x02: IPv6/IPv4 in IPv4 0x03: GRE 0x04: IPsec ESP 0x05: IPv6/IPv4 in IPv4-UDP 0x06: IPv6/IPv4 in IPv4-UDP-TLV 0x07: IPv6/IPv4 in IPv4-UDP-ESP > > It might be useful to provide a better explanation of the problems in > choosing a tunnelling method between the MAG/LMA which would warrant > such negotiation. But in the absence of such I dont think we really > need to go down this route. Frank=> We will try to explain this in the presentation. > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Jul 22 15:39:38 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6CA83A6C3E for ; Wed, 22 Jul 2009 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KICnc6ob9C-i for ; Wed, 22 Jul 2009 15:39:38 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 354453A6C1F for ; Wed, 22 Jul 2009 15:38:58 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6MMWjsb025166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Jul 2009 01:35:59 +0300 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6MMVrpU010144; Wed, 22 Jul 2009 17:32:22 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 01:32:28 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 01:32:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 01:32:22 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 23 Jul 2009 00:32:21 +0200 From: "Basavaraj.Patil@nokia.com" To: , Date: Thu, 23 Jul 2009 00:32:37 +0200 Thread-Topic: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt Thread-Index: AcoLGnHQwbRtLsKXRn+UDBpagkd56AAAd6ja Message-ID: In-Reply-To: <011801ca0b1a$6bb9bbb0$3e0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jul 2009 22:32:22.0939 (UTC) FILETIME=[480EA6B0:01CA0B1C] X-Nokia-AV: Clean Subject: Re: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:39:38 -0000 Hi Frank, On 7/22/09 5:19 PM, "ext Frank Xia" wrote: > Hi Raj >=20 > Thank for your review. > Please check my response... >=20 > BR > Frank >=20 > ----- Original Message ----- > From: > To: > Sent: Wednesday, July 22, 2009 4:39 PM > Subject: [netext] Comments on I-D: > draft-xia-netext-tunnel-negotiation-01.txt >=20 >=20 >>=20 >> After reviewing this I-D I have the following comments: >>=20 >> 1. Why do we need a tunnel negotiation mechanism? Is the protocol >> broken without such capability? No. >> Does this negotiation make the protocol operation somehow more >> optimal? I dont believe that is the case either. > Frank=3D>Yes. Here is a use case. LMA is related to muliple MAGs. > MAG 1 may choose IPv6/IPv4 in IPv6, MAG 2 may select GRE, > MAG 3 prefers IPsec ESP, while MAG 4 picks IPv6/IPv4 in IPv4-UDP. > Without negotiation mechanism, LMA must implement all the tunnel! The MAGs and LMA are all part of the same PMIP6 domain. The MAG/LMA pairs are aware of what tunnelling capability is supported or preferred. The LMA will need to support whatever set of tunnelling mechanisms are used in that PMIP6 domain. And since they are all part of a single domain, there can be simply a policy which requires all tunnelling to be over GRE in which case the MAG/LMA entities in that domain will support only GRE tunnelling. >=20 >>=20 >> 2. The I-D states that the LMA and MAG may have different capabilities >> and preferences. However a MAG is part of the PMIP6 domain. The >> MAG/LMA have a security association between them. Hence it is >> unlikely that the LMA or MAG will be unaware of the tunnelling >> capabilities or preferences. The document does not provide a strong >> reason why such negotiation is needed. > Frank=3D> LMA and MAG are very possible located in > different domains. For example, non-3GPP accesses > (such as WiMAX ASN-GW) belong to domains which are > different from 3GPP core network domains. When you say different domains, I suppose you mean administrative domains. But from the PMIP6 protocol perspective the MAG and LMA are part of a singl= e PMIP6 domain. A MAG in a WiMAX network and the LMA in a 3GPP core still logically belong to the same PMIP6 domain. >=20 >>=20 >> 3. Deployments will choose to use either GRE or IP-in-IP >> tunnelling between the MAG/LMA depending on the >> requirements. Negotiating the type of tunnelling in the signaling >> is not required. > Frank=3D> Just we list in the documents, there are > a bunch of tunnels. I could not find requirements in SDO's > specification on the criteria of selecting a tunnel. >=20 > 0x01: IPv6/IPv4 in IPv6 > 0x02: IPv6/IPv4 in IPv4 > 0x03: GRE > 0x04: IPsec ESP > 0x05: IPv6/IPv4 in IPv4-UDP > 0x06: IPv6/IPv4 in IPv4-UDP-TLV > 0x07: IPv6/IPv4 in IPv4-UDP-ESP >=20 I think you exaggerate the list here :) Basically you have IP-in-IP or GRE. The rest are variants. And given the requirement to secure the signaling via IPsec, the MAG/LMA already support IPsec. >>=20 >> It might be useful to provide a better explanation of the problems in >> choosing a tunnelling method between the MAG/LMA which would warrant >> such negotiation. But in the absence of such I dont think we really >> need to go down this route. > Frank=3D> We will try to explain this in the presentation. >=20 That's fine. But I am just saying that the extension itself does not seem t= o be solving any critical problem or need. -Raj >>=20 >> -Raj >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From Xiangsong.Cui@huawei.com Wed Jul 22 18:26:14 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FB028C0FF for ; Wed, 22 Jul 2009 18:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHWehufKe-iD for ; Wed, 22 Jul 2009 18:26:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A59693A6C94 for ; Wed, 22 Jul 2009 18:26:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7007XHNY50T@szxga03-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 09:25:17 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN700IWANY46M@szxga03-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 09:25:17 +0800 (CST) Date: Thu, 23 Jul 2009 09:25:20 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <002d01ca0b34$7216c420$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <95739.51992.qm@web111413.mail.gq1.yahoo.com> <987AE408-EBA7-4D63-B06E-510D5BF3A12B@gmail.com> <010601ca09b9$5c154ce0$40106f0a@china.huawei.com> <9408201D-9CD1-4C73-9600-31AA3567B561@gmail.com> <013501ca09de$ee79cd70$40106f0a@china.huawei.com> <0d3e01ca0ab0$aa07a4f0$40106f0a@china.huawei.com> <30083ADE-A33C-45C8-945D-8371EB5FEC84@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:26:14 -0000 Hi Jouni, I ever read 3GPP 23.402 of Rel 8, there is explicitly statement "PDN is indicated with APN" in the specification, so I am strange at the draft. But now, I do find the function of "Multiple PDN connections to the same APN" in the 3GPP document of Rel 9. So I will read the 3GPP document first. Thank you and regards Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Wednesday, July 22, 2009 6:11 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > > On Jul 22, 2009, at 12:42 PM, Xiangsong Cui wrote: > >> Yes, I know the draft is discussing PDN connections. >> But I don't know, in what a scenario, a MN can establish >> multiple connections to one PDN? > > Multiple PDN Connections to the same Service (i.e. APN). Not the other > way around. > > Cheers, > Jouni > > >> >> Xiangsong >> >> >> ----- Original Message ----- From: "jouni korhonen" >> > > >> To: "Xiangsong Cui" >> Cc: ; >> Sent: Wednesday, July 22, 2009 3:36 PM >> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >> connid-00 >> >> >>> Hi Xiangsong, >>> >>> On Jul 21, 2009, at 11:40 AM, Xiangsong Cui wrote: >>> >>>> Hi Jouni, >>>> >>>>> Right. Assume MN establishes three connections through the same >>>>> radio to the MAG. Connection 1 gets HNP1 and is identified with >>>>> Service >>>> >>>> Do you mean a MN has three 3GPP interface connection, or three WLAN >>>> connection? >>>> I don't understand the case, IMO, a MN may has a 3GPP interface + a >>>> WLAN interface + a Wimax interface, but I can't image a MN with three >>>> WLAN interfaces, do the interfaces use the same link layer address? >>> >>> So far we have been discussing about a single interface. >>> >>>> >>>> Even in Nextext2, there is only inter RAT handover. >>> >>> Imho this is a separate topic. >>> >>> >>>> If there is only one RAT, in my mind, there is only one connection, >>>> to previous AR before handover and to new AR after handover. >>> >>> What type of connection you are talking about here. The draft >>> discusses about PDN Connections. >>> >>> Cheers, >>> Jouni >>> >>> >>>> >>>> Xiangsong >>>> >>>> >>>> ----- Original Message ----- From: "jouni korhonen" >>>> >>> > >>>> To: "Xiangsong Cui" >>>> Cc: ; >>>> Sent: Tuesday, July 21, 2009 4:18 PM >>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- >>>> connid-00 >>>> >>>> >>>>> Hi Xiangsong, >>>>> See inline. >>>>> On Jul 21, 2009, at 7:11 AM, Xiangsong Cui wrote: >>>>>> Hi Jouni, >>>>>> >>>>>> I also wonder at the motivation. >>>>>> >>>>>>> Similar type of extensions what you already have e.g. with >>>>>>> RFC5149. What the I-D adds here is more detail and a new key to >>>>>>> help with lookups to binding >>>>>> >>>>>> Yes, RFC5149 introduces some extensions, we can accept the >>>>>> extension because there are many use cases. >>>>>> Can you give us some use case too? >>>>>> >>>>>> From the draft, it says: >>>>>> " However, in a case of multiple PDN >>>>>> connections to the same APN, and assuming that Home Network Prefixes >>>>>> (HNP) are not always available in a Mobile Access Gateway (MAG) >>>>>> after >>>>>> a handover and that the "APN name" in the Service Selection mobility >>>>>> option cannot be decorated (i.e. making each APN unique), there is a >>>>>> need for a new identifier to uniquely identify PDN connections to >>>>>> the >>>>>> same APN. " >>>>>> >>>>>> I am confused by the case, could you please figure it more clearly? >>>>> Right. Assume MN establishes three connections through the same >>>>> radio to the MAG. Connection 1 gets HNP1 and is identified with >>>>> Service Selection (SS) ="foo". Connection 2 gets HNP2 and is again >>>>> identified by SS="foo". Connection 3 gets HNP3 and is also >>>>> identified by SS="foo". This is possible by some popular access >>>>> technologies already today. MN and MAG also know these connections >>>>> by some lower layer identifier/radio level thing. >>>>> When a handover takes place the MN re-attaches to a new MAG and >>>>> starts setting up connections to the new MAG. Now the MAG knows >>>>> which connection the MN sets up based on the SS and the "lower layer >>>>> thing" but does not necessarily know the associated HNP yet. So the >>>>> PBU sent to the LMA needs more info. Otherwise the LMA is not able >>>>> to return the correct HNP to the MAG. If the LMA were to return HNP1 >>>>> for the connection 2 after a handover that would break the IP >>>>> connectivity in the MN. That's why we propose to add "yet another" >>>>> identifier to all PBU/PBA messages. Using MN-LL would look tempting >>>>> but the solution must also work with one interface and cases where >>>>> interfaces do not have real identifiers (would mean overloading the >>>>> existing meaning of the MN-LL). >>>>> Cheers, >>>>> Jouni >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Xiangsong >>>>>> >>>>>> ----- Original Message ----- From: "jouni" >>>>>> To: "Behcet Sarikaya" >>>>>> Cc: ; >>>>>> Sent: Monday, July 20, 2009 4:36 AM >>>>>> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext- pmip6- >>>>>> connid-00 >>>>>> >>>>>> >>>>>>> Hi Behcet, >>>>>>> On Jul 17, 2009, at 9:36 PM, Behcet Sarikaya wrote: >>>>>>> [snip] >>>>>>>>>>> >>>>>>>>>>> Hi Behcet, >>>>>>>>>>> >>>>>>>>>>> It is possible to assign multiple HNPs to an MN via RFC5213. >>>>>>>>>>> However it is >>>>>>>>>>> not possible to request dynamically (after initial attachment >>>>>>>>>>> and being >>>>>>>>>>> assigned an HNP and a BCE created) a new mobility session. >>>>>>>>>>> The LMA would essentially view a new PBU request from the MAG >>>>>>>>>>> for the MN as >>>>>>>>>>> being a renewal request and hence not assign a new HNP. I >>>>>>>>>>> think it is clear >>>>>>>>>>> (at least in the 3GPP EPC context) that it with RFC5213 it is >>>>>>>>>>> not possible >>>>>>>>>>> to establish multiple mobility sessions with the same LMA via >>>>>>>>>>> a single >>>>>>>>>>> interface. >>>>>>>>>> >>>>>>>>>> Yes, I think it is clear. The question is do we want to change >>>>>>>>>> it? >>>>>>>>> >>>>>>>>> Yes. Extend the capability by which the LMA is aware that the >>>>>>>>> PBU is a >>>>>>>>> request for establishing a new mobility session. >>>>>>>> >>>>>>>> That's what I was referring to as a big semantic change to PBU/ >>>>>>>> PBA. >>>>>>> It is a change but I would not call it semantic change. Similar >>>>>>> type of extensions what you already have e.g. with RFC5149. What >>>>>>> the I-D adds here is more detail and a new key to help with >>>>>>> lookups to binding cache (obviously adds more data to binding >>>>>>> cache entries as well) when you want to identify exactly one of >>>>>>> several mobility sessions without really knowing its assigned >>>>>>> HNP. >>>>>>>>> >>>>>>>>>> I think sending a non-renewal PBU is a big semantic change to >>>>>>>>>> the base >>>>>>>>>> protocol. >>>>>>>>> >>>>>>>>> Not really. A PBU can indicate already whether it is a result of >>>>>>>>> a HO or a >>>>>>>>> renewal or the result of a new attachment via a different >>>>>>>>> interface. >>>>>>>>> >>>>>>>>>> I was thinking that such a thing could happen below PMIP level >>>>>>>>>> possibly using >>>>>>>>>> the other prefix. I don't know what would you say to that? >>>>>>>>> >>>>>>>>> Not sure what you mean by "below PMIP level". Maybe you have >>>>>>>>> some other >>>>>>>>> ideas of how to achieve the same functionality. Also I don't >>>>>>>>> understand what >>>>>>>>> you mean by "the other prefix". What other prefix are you >>>>>>>>> refering to? When >>>>>>>>> the MN requests an additional mobility session, there is no >>>>>>>>> prefix assigned >>>>>>>>> to it yet. >>>>>>>> >>>>>>>> PBA sends more than one prefixes to MAG and MAG advertizes them. >>>>>>>> What does MN do? >>>>>>>> >>>>>>>> I think hosts create addresses for each prefix they receive. >>>>>>> If it is a case that PBA contains more than one HNP. This is, >>>>>>> however, always not the case. >>>>>>>> So my suggestion was to use a different address for each PDP >>>>>>>> connection. In fact you need a single address to >>>>>>> Eh? In this particular example, each PDN connection already has a >>>>>>> different HNP. The issue is that the HNP information is not >>>>>>> enough, or merely not available, when a link gets set up after a >>>>>>> handover. >>>>>>>> access the Internet. More than one addresses create problems that >>>>>>>> MIF WG is trying to address. >>>>>>> This is a completely different discussion imho. >>>>>>> Cheers, >>>>>>> Jouni >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> netext mailing list >>>>>>> netext@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Wed Jul 22 18:39:38 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126B93A6CB9 for ; Wed, 22 Jul 2009 18:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvchHbs7y45M for ; Wed, 22 Jul 2009 18:39:37 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 055713A6C8E for ; Wed, 22 Jul 2009 18:39:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700MCFO1HHQ@szxga03-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 09:27:17 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN700CW6O1GRZ@szxga03-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 09:27:17 +0800 (CST) Date: Thu, 23 Jul 2009 09:27:19 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <003901ca0b34$b8a5d0c0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0d4901ca0ab2$e9472210$40106f0a@china.huawei.com> <051017E8-0188-4FF3-8238-18278DC30C8F@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Agenda Requests received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:39:38 -0000 I see, thank you very much. Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Wednesday, July 22, 2009 7:14 PM Subject: Re: [netext] Agenda Requests received > > Hi Xiangsong, > > On Jul 22, 2009, at 12:58 PM, Xiangsong Cui wrote: > >> I have a question about the item #12, >> the draft "bulk-re-registration". >> >> In the section 1, there is a formula: >> transactions/sec = (number of registered MNs) / (binding lifetime*4) >> I don't understand it, why we multiply lifetime by 4? > > > The lifetime is expressed as a unit of 4 seconds. See Section 6.1.7. > of RFC3775. The 'lifetime' here means the value inside the PBU message. > > Cheers, > Jouni > > >> >> In my mind, there are two messages in the re-register flow, a PBU >> message and a PBA message, and the re-register interval is the >> lifetime. >> A PBU and a PBA also constitutes one transaction. >> So, for one MN, in the duration of the lifetime, there are two >> messages, >> and the message rate is: message/sec = 2/lifetime, >> the transaction rate is: transaction/sec = 1/lifetime. >> For a MAG or a LMA, the total transaction rate is: >> transactions/sec = (number of registered MNs) / binding lifetime. >> >> Is it right? >> >> Regards >> Xiangsong >> >> >> ----- Original Message ----- From: >> To: ; >> Sent: Wednesday, July 15, 2009 1:34 AM >> Subject: Re: [netext] Agenda Requests received >> >> >>> As of 7/14 the chairs have received requests for agenda slots at >>> IETF75. >>> We would like to encourage WG members to review the I-Ds and provide >>> feedback on the list prior to the meeting itself. >>> -Chairs >>> Agenda requests received: >>> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6 >>> I-D: draft-korhonen-netext-redirect-02 >>> Jouni Korhonen - 10 Mins >>> 2. Localized Routing >>> PMIPv6 Localized Routing Problem Statement >>> I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt >>> PS and Scope discussion 10 Mins >>> Solutions 15 Mins >>> Marco Liebsch et al. >>> Proxy MIP extension for local routing optimization >>> I-D: draft-wu-netext-local-ro-02.txt >>> Behcet Sarikaya 5 Mins >>> 3. Tunnel Negotiation for Proxy Mobile IPv6 >>> I-D: draft-xia-netext-tunnel-negotiation-01.txt >>> Frank Xia 10 Mins >>> 4. Mobile Node Group Identifier Option: >>> I-D: draft-gundavelli-netext-mn-groupid-option-01 >>> Sri Gundavelli 10 Mins >>> 5. Retransmit Message Identifier Option: >>> I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt >>> Sri Gundavelli 10 Mins >>> 6. Mobility session suspend >>> I-D: draft-muhanna-netext-mobility-session-suspend-00.txt >>> Ahmad Muhanna 10 Mins >>> 7. Trace Control Support for Proxy Mobile IPv6 >>> I-D: draft-wang-netext-trace-control-00.txt >>> Yungui Wang 10 Mins >>> 8. Multihoming extensions for Proxy Mobile IPv6 >>> I-D: draft-bernardos-mif-pmip-00.txt >>> Telemaco, Pierrick and Carlos 10 Mins >>> 9. 3GPP MN-AR interface >>> I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt >>> Telemaco 5 Mins >>> 10. Service Flow Identifier in Proxy Mobile IPv6 >>> I-D: draft-hui-netext-service-flow-identifier-00.txt >>> Min Hui 10 Mins >>> 11. Connection Identifier for Proxy Mobile IPv6 >>> I-D: draft-wolfner-netext-pmip6-connid-00 >>> Jouni Korhonen 5 Mins >>> 12. Bulk Re-registration for Proxy Mobile IPv6 >>> I-D: draft-premec-netlmm-bulk-re-registration-02 >>> Jouni Korhonen 5 Mins >>> 13. Partial Handoff Support in PMIPv6 >>> I-D: draft-jeyatharan-netext-pmip-partial-handoff-00 >>> Mohana Jeyatharan >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From xiayangsong@huawei.com Wed Jul 22 18:52:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794D03A6B86 for ; Wed, 22 Jul 2009 18:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt93cVNWh9eQ for ; Wed, 22 Jul 2009 18:52:44 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id EB1473A693F for ; Wed, 22 Jul 2009 18:52:43 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700KG5P7ESK@szxga01-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 09:52:26 +0800 (CST) Received: from X24512z ([10.51.0.61]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN700KI1P7BZ7@szxga01-in.huawei.com> for netext@ietf.org; Thu, 23 Jul 2009 09:52:26 +0800 (CST) Date: Wed, 22 Jul 2009 19:47:33 -0500 From: Frank Xia To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <015401ca0b30$4afa64e0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:52:45 -0000 Hi Raj Please check my response. BR Frank ----- Original Message ----- From: To: ; Sent: Wednesday, July 22, 2009 5:32 PM Subject: Re: [netext] Comments on I-D: draft-xia-netext-tunnel-negotiation-01.txt Hi Frank, On 7/22/09 5:19 PM, "ext Frank Xia" wrote: > Hi Raj > > Thank for your review. > Please check my response... > > BR > Frank > > ----- Original Message ----- > From: > To: > Sent: Wednesday, July 22, 2009 4:39 PM > Subject: [netext] Comments on I-D: > draft-xia-netext-tunnel-negotiation-01.txt > > >> >> After reviewing this I-D I have the following comments: >> >> 1. Why do we need a tunnel negotiation mechanism? Is the protocol >> broken without such capability? No. >> Does this negotiation make the protocol operation somehow more >> optimal? I dont believe that is the case either. > Frank=>Yes. Here is a use case. LMA is related to muliple MAGs. > MAG 1 may choose IPv6/IPv4 in IPv6, MAG 2 may select GRE, > MAG 3 prefers IPsec ESP, while MAG 4 picks IPv6/IPv4 in IPv4-UDP. > Without negotiation mechanism, LMA must implement all the tunnel! The MAGs and LMA are all part of the same PMIP6 domain. The MAG/LMA pairs are aware of what tunnelling capability is supported or preferred. The LMA will need to support whatever set of tunnelling mechanisms are used in that PMIP6 domain. And since they are all part of a single domain, there can be simply a policy which requires all tunnelling to be over GRE in which case the MAG/LMA entities in that domain will support only GRE tunnelling. Frank=>Probably we see "domain" from different respectives . Let me reword the use case. LMA is located in MN's home networks, while the MN moves to visited networks adminsterd by different entities. The MAG/LMA pairs are not neccessarily aware of tunnelling preference of each other. > >> >> 2. The I-D states that the LMA and MAG may have different capabilities >> and preferences. However a MAG is part of the PMIP6 domain. The >> MAG/LMA have a security association between them. Hence it is >> unlikely that the LMA or MAG will be unaware of the tunnelling >> capabilities or preferences. The document does not provide a strong >> reason why such negotiation is needed. > Frank=> LMA and MAG are very possible located in > different domains. For example, non-3GPP accesses > (such as WiMAX ASN-GW) belong to domains which are > different from 3GPP core network domains. When you say different domains, I suppose you mean administrative domains. But from the PMIP6 protocol perspective the MAG and LMA are part of a single PMIP6 domain. A MAG in a WiMAX network and the LMA in a 3GPP core still logically belong to the same PMIP6 domain. Frank=>Just my aformentioned explanation, WiMAX networks and 3GPP core are probably adminstered by different entities. > >> >> 3. Deployments will choose to use either GRE or IP-in-IP >> tunnelling between the MAG/LMA depending on the >> requirements. Negotiating the type of tunnelling in the signaling >> is not required. > Frank=> Just we list in the documents, there are > a bunch of tunnels. I could not find requirements in SDO's > specification on the criteria of selecting a tunnel. > > 0x01: IPv6/IPv4 in IPv6 > 0x02: IPv6/IPv4 in IPv4 > 0x03: GRE > 0x04: IPsec ESP > 0x05: IPv6/IPv4 in IPv4-UDP > 0x06: IPv6/IPv4 in IPv4-UDP-TLV > 0x07: IPv6/IPv4 in IPv4-UDP-ESP > I think you exaggerate the list here :) Basically you have IP-in-IP or GRE. The rest are variants. And given the requirement to secure the signaling via IPsec, the MAG/LMA already support IPsec. Frank=>Each variant is unique that special considerations are needed when implementing them. You can categorize them into two: IP-in-IP or GRE for better understanding, while you still need treat variants differently. >> >> It might be useful to provide a better explanation of the problems in >> choosing a tunnelling method between the MAG/LMA which would warrant >> such negotiation. But in the absence of such I dont think we really >> need to go down this route. > Frank=> We will try to explain this in the presentation. > That's fine. But I am just saying that the extension itself does not seem to be solving any critical problem or need. -Raj >> >> -Raj >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From xiayangsong@huawei.com Thu Jul 23 13:21:21 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E023A676A for ; Thu, 23 Jul 2009 13:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWQ5roo1LUuQ for ; Thu, 23 Jul 2009 13:21:20 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4D22D3A659A for ; Thu, 23 Jul 2009 13:21:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN900APY4GH0G@szxga04-in.huawei.com> for netext@ietf.org; Fri, 24 Jul 2009 04:19:29 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN9007IO4GEFW@szxga04-in.huawei.com> for netext@ietf.org; Fri, 24 Jul 2009 04:19:29 +0800 (CST) Date: Thu, 23 Jul 2009 15:19:26 -0500 From: Frank Xia To: liu dapeng , "Giaretta, Gerardo" Message-id: <012c01ca0bd2$e19a6470$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <057632CE4CE10D45A1A3D6D19206C3A3DF69309B@NASANEXMB08.na.qualcomm.com> <25e1aaa40907231017v6454062du837ac83b0e13758d@mail.gmail.com> Cc: netext@mail.mobileip.jp, netext@ietf.org Subject: Re: [netext] [Netext] PMIP multihoming/flow mobility: a different perspective X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 20:21:21 -0000 Hi Dapeng Probably, you can use netext@ietf.org for the WG. IEEE802.21 is kind of 2.5 layer stuff, and it is not bad idea to be used for multi-homing/ flow mobility. BR Frank ----- Original Message ----- From: "liu dapeng" To: "Giaretta, Gerardo" Cc: Sent: Thursday, July 23, 2009 12:17 PM Subject: Re: [Netext] PMIP multihoming/flow mobility: a different perspective > 2009/4/8, Giaretta, Gerardo : >> Hi all, >> >> I would like to provide a different perspective on the discussion about >> the >> need of this work. Note that I am focusing only on the multihoming and >> flow >> mobility aspects of Netext and not on other issues. This perspective >> comes >> mainly from the discussion 3GPP had in the last 6 months, therefore it >> cannot be considered a complete analysis for the Internet but just an >> input >> to the discussion. >> >> As many have mentioned, 3GPP is currently studying the possibility of >> standardizing flow mobility. After some initial broad scope discussion, >> the >> study is now focusing on two specific radio technologies, one being >> cellular >> and the other being WiFi. This restriction is not yet official but it is >> pretty clear from the discussion at the meetings, the inputs from >> operators >> and the contributions from companies. The motivation for this restriction >> is >> twofold: first this is the only scenario operators see as beneficial; >> second >> from a terminal point of view, this seems to be the only realistic >> assumption (i.e. two high power radios on at the same time do not seem >> feasible, acceptable or desirable). >> >> As discussed, to enable PMIPv6 multihoming and flow mobility, dedicated >> L2 >> signaling is needed between the MN and the MAG. However WiFi does not >> support any type of L2 signaling to enable this scenario and therefore >> PMIPv6 multihoming/flow mobility is not possible in the scenarios >> mentioned >> above (unless we change/enhance the L2 of 802.11 WLAN). > > Actually, the L2 of 802.11 has been enhanced by the IEEE 802.21 > specification which aims to provide link layer intelligence to > optimise IP layer mobility protocol. > Here is a link for reference, > http://grouper.ieee.org/groups/802/21/index.html > >> In my opinion this boils down to the following point: if we look at >> deployment scenarios industry is looking at, a PMIPv6 solution for >> multihoming and flow mobility is basically not possible due to lack of >> support of L2 signaling in the accesses which are considered. Therefore >> the >> work proposed in Netext tends to be an academic exercise, rather than >> something really needed by the industry. At least this is what I think >> after >> having looked at this issue with other companies in the last 6 months. > > Do you think there is a possibility that the industry(3GPP) would adopt > 802.21? > > 802.21 requires upgrading both UE and the network, that is maybe the > main reason that prevent its widely deployment. > > BR, > Dapeng Liu > >> Gerardo >> >> _______________________________________________ >> NetExt mailing list >> NetExt@mail.mobileip.jp >> http://www.mobileip.jp/mailman/listinfo/netext >> > _______________________________________________ > NetExt mailing list > NetExt@mail.mobileip.jp > http://www.mobileip.jp/mailman/listinfo/netext From maxpassion@gmail.com Thu Jul 23 20:32:38 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BC93A6CB3 for ; Thu, 23 Jul 2009 20:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWPUSRhPn9TG for ; Thu, 23 Jul 2009 20:32:37 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 411EE3A6BFD for ; Thu, 23 Jul 2009 20:32:37 -0700 (PDT) Received: by mail-fx0-f218.google.com with SMTP id 18so1212236fxm.37 for ; Thu, 23 Jul 2009 20:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OxYVAtmiS20QTS+yjhBt02CIYVvee87JFcDxfo9YLr8=; b=khojpGIOgPr9zMMFIiAUFnPDSlB5MHXaxULv6H0wh+FcZ4cuFuHUE/W6BHHpQ6gHtl 243Lf4iAkwSJaZJgSkYpweOvEYAEbCKHxo//pXnAK7RDR3bwf+o3N+m91K3cfyBmK2/b LcInQv0R3UibjCTgtsDshpIqpd5hR415b6Tss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tAZ3LtAhyTeU4n1hv7dWTq8SNIjOARM+d3f6K3yIDYQaX10KTfLOOvQeWHKIQkhllp JKPJ2JCIkwOlY/71v5QE4XQPtJCTIH72mUKFU91dH1ubW78Zz97oNz10ZpodTjIPudVV w3+tnQw6NbjHlV2GWIp3Ml2y0zfTG1ys2Xh4k= MIME-Version: 1.0 Received: by 10.223.120.5 with SMTP id b5mr1490861far.22.1248406357976; Thu, 23 Jul 2009 20:32:37 -0700 (PDT) In-Reply-To: <012c01ca0bd2$e19a6470$3e0c7c0a@china.huawei.com> References: <057632CE4CE10D45A1A3D6D19206C3A3DF69309B@NASANEXMB08.na.qualcomm.com> <25e1aaa40907231017v6454062du837ac83b0e13758d@mail.gmail.com> <012c01ca0bd2$e19a6470$3e0c7c0a@china.huawei.com> Date: Fri, 24 Jul 2009 11:32:37 +0800 Message-ID: <25e1aaa40907232032n2d0c655ek976152410baf7a22@mail.gmail.com> From: liu dapeng To: Frank Xia Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Giaretta, Gerardo" , netext@ietf.org Subject: Re: [netext] [Netext] PMIP multihoming/flow mobility: a different perspective X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 03:32:39 -0000 2009/7/24, Frank Xia : > Hi Dapeng > > Probably, you can use netext@ietf.org for the WG. Thanks for reminding. > IEEE802.21 is kind of 2.5 layer stuff, and > it is not bad idea to be used for multi-homing/ > flow mobility. Do you think that IEEE802.21's requirment for upgrading both UE and network would prevent it be adopted by the industry? BR, Dapeng Liu > BR > Frank > > ----- Original Message ----- > From: "liu dapeng" > To: "Giaretta, Gerardo" > Cc: > Sent: Thursday, July 23, 2009 12:17 PM > Subject: Re: [Netext] PMIP multihoming/flow mobility: a different > perspective > > >> 2009/4/8, Giaretta, Gerardo : >>> Hi all, >>> >>> I would like to provide a different perspective on the discussion about >>> the >>> need of this work. Note that I am focusing only on the multihoming and >>> flow >>> mobility aspects of Netext and not on other issues. This perspective >>> comes >>> mainly from the discussion 3GPP had in the last 6 months, therefore it >>> cannot be considered a complete analysis for the Internet but just an >>> input >>> to the discussion. >>> >>> As many have mentioned, 3GPP is currently studying the possibility of >>> standardizing flow mobility. After some initial broad scope discussion, >>> the >>> study is now focusing on two specific radio technologies, one being >>> cellular >>> and the other being WiFi. This restriction is not yet official but it is >>> pretty clear from the discussion at the meetings, the inputs from >>> operators >>> and the contributions from companies. The motivation for this restriction >>> >>> is >>> twofold: first this is the only scenario operators see as beneficial; >>> second >>> from a terminal point of view, this seems to be the only realistic >>> assumption (i.e. two high power radios on at the same time do not seem >>> feasible, acceptable or desirable). >>> >>> As discussed, to enable PMIPv6 multihoming and flow mobility, dedicated >>> L2 >>> signaling is needed between the MN and the MAG. However WiFi does not >>> support any type of L2 signaling to enable this scenario and therefore >>> PMIPv6 multihoming/flow mobility is not possible in the scenarios >>> mentioned >>> above (unless we change/enhance the L2 of 802.11 WLAN). >> >> Actually, the L2 of 802.11 has been enhanced by the IEEE 802.21 >> specification which aims to provide link layer intelligence to >> optimise IP layer mobility protocol. >> Here is a link for reference, >> http://grouper.ieee.org/groups/802/21/index.html >> >>> In my opinion this boils down to the following point: if we look at >>> deployment scenarios industry is looking at, a PMIPv6 solution for >>> multihoming and flow mobility is basically not possible due to lack of >>> support of L2 signaling in the accesses which are considered. Therefore >>> the >>> work proposed in Netext tends to be an academic exercise, rather than >>> something really needed by the industry. At least this is what I think >>> after >>> having looked at this issue with other companies in the last 6 months. >> >> Do you think there is a possibility that the industry(3GPP) would adopt >> 802.21? >> >> 802.21 requires upgrading both UE and the network, that is maybe the >> main reason that prevent its widely deployment. >> >> BR, >> Dapeng Liu >> >>> Gerardo >>> >>> _______________________________________________ >>> NetExt mailing list >>> NetExt@mail.mobileip.jp >>> http://www.mobileip.jp/mailman/listinfo/netext >>> >> _______________________________________________ >> NetExt mailing list >> NetExt@mail.mobileip.jp >> http://www.mobileip.jp/mailman/listinfo/netext > > From xiayangsong@huawei.com Fri Jul 24 08:06:14 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815FB28C1C1 for ; Fri, 24 Jul 2009 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 049xVx3m-LNM for ; Fri, 24 Jul 2009 08:06:13 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 24FD528C1E2 for ; Fri, 24 Jul 2009 08:06:13 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNA00GK6KMCCT@szxga04-in.huawei.com> for netext@ietf.org; Fri, 24 Jul 2009 23:06:12 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNA0018OKMAED@szxga04-in.huawei.com> for netext@ietf.org; Fri, 24 Jul 2009 23:06:12 +0800 (CST) Date: Fri, 24 Jul 2009 10:06:09 -0500 From: Frank Xia To: liu dapeng Message-id: <007f01ca0c70$4821b700$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <057632CE4CE10D45A1A3D6D19206C3A3DF69309B@NASANEXMB08.na.qualcomm.com> <25e1aaa40907231017v6454062du837ac83b0e13758d@mail.gmail.com> <012c01ca0bd2$e19a6470$3e0c7c0a@china.huawei.com> <25e1aaa40907232032n2d0c655ek976152410baf7a22@mail.gmail.com> Cc: "Giaretta, Gerardo" , netext@ietf.org Subject: Re: [netext] [Netext] PMIP multihoming/flow mobility: a different perspective X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 15:06:14 -0000 Hi Dapeng It is reasonable to have deterrance when introducing new things, such as 802.21. IMO, the motivation and requirement of 802.21 are not picky. It takes time to be adopted in the industry. BR Frank ----- Original Message ----- From: "liu dapeng" To: "Frank Xia" Cc: "Giaretta, Gerardo" ; Sent: Thursday, July 23, 2009 10:32 PM Subject: Re: [Netext] PMIP multihoming/flow mobility: a different perspective > 2009/7/24, Frank Xia : >> Hi Dapeng >> >> Probably, you can use netext@ietf.org for the WG. > > Thanks for reminding. > >> IEEE802.21 is kind of 2.5 layer stuff, and >> it is not bad idea to be used for multi-homing/ >> flow mobility. > > Do you think that IEEE802.21's requirment for upgrading both UE and > network would prevent it be adopted by the industry? > > > BR, > Dapeng Liu > >> BR >> Frank >> >> ----- Original Message ----- >> From: "liu dapeng" >> To: "Giaretta, Gerardo" >> Cc: >> Sent: Thursday, July 23, 2009 12:17 PM >> Subject: Re: [Netext] PMIP multihoming/flow mobility: a different >> perspective >> >> >>> 2009/4/8, Giaretta, Gerardo : >>>> Hi all, >>>> >>>> I would like to provide a different perspective on the discussion about >>>> the >>>> need of this work. Note that I am focusing only on the multihoming and >>>> flow >>>> mobility aspects of Netext and not on other issues. This perspective >>>> comes >>>> mainly from the discussion 3GPP had in the last 6 months, therefore it >>>> cannot be considered a complete analysis for the Internet but just an >>>> input >>>> to the discussion. >>>> >>>> As many have mentioned, 3GPP is currently studying the possibility of >>>> standardizing flow mobility. After some initial broad scope discussion, >>>> the >>>> study is now focusing on two specific radio technologies, one being >>>> cellular >>>> and the other being WiFi. This restriction is not yet official but it >>>> is >>>> pretty clear from the discussion at the meetings, the inputs from >>>> operators >>>> and the contributions from companies. The motivation for this >>>> restriction >>>> >>>> is >>>> twofold: first this is the only scenario operators see as beneficial; >>>> second >>>> from a terminal point of view, this seems to be the only realistic >>>> assumption (i.e. two high power radios on at the same time do not seem >>>> feasible, acceptable or desirable). >>>> >>>> As discussed, to enable PMIPv6 multihoming and flow mobility, dedicated >>>> L2 >>>> signaling is needed between the MN and the MAG. However WiFi does not >>>> support any type of L2 signaling to enable this scenario and therefore >>>> PMIPv6 multihoming/flow mobility is not possible in the scenarios >>>> mentioned >>>> above (unless we change/enhance the L2 of 802.11 WLAN). >>> >>> Actually, the L2 of 802.11 has been enhanced by the IEEE 802.21 >>> specification which aims to provide link layer intelligence to >>> optimise IP layer mobility protocol. >>> Here is a link for reference, >>> http://grouper.ieee.org/groups/802/21/index.html >>> >>>> In my opinion this boils down to the following point: if we look at >>>> deployment scenarios industry is looking at, a PMIPv6 solution for >>>> multihoming and flow mobility is basically not possible due to lack of >>>> support of L2 signaling in the accesses which are considered. Therefore >>>> the >>>> work proposed in Netext tends to be an academic exercise, rather than >>>> something really needed by the industry. At least this is what I think >>>> after >>>> having looked at this issue with other companies in the last 6 months. >>> >>> Do you think there is a possibility that the industry(3GPP) would adopt >>> 802.21? >>> >>> 802.21 requires upgrading both UE and the network, that is maybe the >>> main reason that prevent its widely deployment. >>> >>> BR, >>> Dapeng Liu >>> >>>> Gerardo >>>> >>>> _______________________________________________ >>>> NetExt mailing list >>>> NetExt@mail.mobileip.jp >>>> http://www.mobileip.jp/mailman/listinfo/netext >>>> >>> _______________________________________________ >>> NetExt mailing list >>> NetExt@mail.mobileip.jp >>> http://www.mobileip.jp/mailman/listinfo/netext >> >> From Xiangsong.Cui@huawei.com Mon Jul 27 00:55:59 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FA028C11B for ; Mon, 27 Jul 2009 00:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZCNMqg+ZQi0 for ; Mon, 27 Jul 2009 00:55:58 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8102A28C108 for ; Mon, 27 Jul 2009 00:55:58 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNF0092LKP9MJ@szxga02-in.huawei.com> for netext@ietf.org; Mon, 27 Jul 2009 15:55:58 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNF00B9IKP9X3@szxga02-in.huawei.com> for netext@ietf.org; Mon, 27 Jul 2009 15:55:57 +0800 (CST) Date: Mon, 27 Jul 2009 15:55:57 +0800 From: Xiangsong Cui To: netext@ietf.org Message-id: <004201ca0e8f$acc89860$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [netext] Fw: New Version Notification for draft-cui-netext-lma-redirection-solution-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 07:55:59 -0000 Hi all, I have just submitted a draft about the LMA Redirection solution. You may find the draft by the link: http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 Please take a look and any comment is welcomed. Thanks and regards Xiangsong ----- Original Message ----- From: "IETF I-D Submission Tool" To: Sent: Monday, July 27, 2009 3:31 PM Subject: New Version Notification for draft-cui-netext-lma-redirection-solution-00 > > A new version of I-D, draft-cui-netext-lma-redirection-solution-00.txt has > been successfuly submitted by Xiangsong Cui and posted to the IETF > repository. > > Filename: draft-cui-netext-lma-redirection-solution > Revision: 00 > Title: LMA Redirection Solution > Creation_date: 2009-07-27 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > In network-based mobility management domain, LMA is used to manage > the mobility of IP node attached to MAG. LMA discovery and LMA > redirection mechanism are used to improve the network flexibility. > This document is used to introduce a recommended solution for this > purpose. In this solution Redirect Agent function is adopted to > accomplish the requirement. > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > The IETF Secretariat. > > From Xiangsong.Cui@huawei.com Mon Jul 27 01:11:21 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B403A6C0F for ; Mon, 27 Jul 2009 01:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoELx9PEUlHy for ; Mon, 27 Jul 2009 01:11:19 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9AD0B3A6C0B for ; Mon, 27 Jul 2009 01:11:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNF00F25LEMLT@szxga04-in.huawei.com> for netext@ietf.org; Mon, 27 Jul 2009 16:11:10 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNF004GELELNF@szxga04-in.huawei.com> for netext@ietf.org; Mon, 27 Jul 2009 16:11:10 +0800 (CST) Date: Mon, 27 Jul 2009 16:11:09 +0800 From: Xiangsong Cui To: netext@ietf.org, Basavaraj.Patil@nokia.com Message-id: <0d0c01ca0e91$cc7c1090$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: wuyajuan 26753 Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 08:11:21 -0000 Dear Raj, I am sorry for the late solicitation but I would like to request a 10 min slot for the draft "draft-cui-netext-lma-redirection-solution-00", which may be get by the link: http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 If there is some spare time in the Netext meeting, would you please arrange a slot for this draft? My colleague will present it on behalf of me. Thanks and regards. Xiangsong ----- Original Message ----- From: To: Sent: Tuesday, June 23, 2009 6:44 AM Subject: [netext] Solicitations for agenda items > > Hello, > > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. > > Note that we will consider I-Ds that pertain to the scope of the charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From marcelo@it.uc3m.es Tue Jul 28 00:55:29 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF463A6C79 for ; Tue, 28 Jul 2009 00:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+hlZiig0nxT for ; Tue, 28 Jul 2009 00:55:28 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 95D363A6AE0 for ; Tue, 28 Jul 2009 00:55:28 -0700 (PDT) Received: from dhcp-10ea.meeting.ietf.org (dhcp-10ea.meeting.ietf.org [130.129.16.234]) by smtp02.uc3m.es (Postfix) with ESMTP id D79B86BAE1C for ; Tue, 28 Jul 2009 09:54:51 +0200 (CEST) Message-ID: <4A6EAECB.1040904@it.uc3m.es> Date: Tue, 28 Jul 2009 09:54:51 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16790.003 Subject: [netext] slides for netext2 bof uploaded X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:55:29 -0000 does anybody volunteers for taking minutes and jabber? let me know regards, marcelo From Basavaraj.Patil@nokia.com Wed Jul 29 05:55:41 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C6B3A703C for ; Wed, 29 Jul 2009 05:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p907IZiCUT7N for ; Wed, 29 Jul 2009 05:55:40 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DAA3D3A700B for ; Wed, 29 Jul 2009 05:55:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6TCsU8Y012055; Wed, 29 Jul 2009 07:55:01 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:55:02 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 15:54:57 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 29 Jul 2009 14:54:57 +0200 From: To: , Date: Wed, 29 Jul 2009 14:54:53 +0200 Thread-Topic: [netext] Solicitations for agenda items Thread-Index: AcoOkdNWALCIAgdXT62efTUE3W7MMQBubsDg Message-ID: References: <0d0c01ca0e91$cc7c1090$40106f0a@china.huawei.com> In-Reply-To: <0d0c01ca0e91$cc7c1090$40106f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2009 12:54:57.0998 (UTC) FILETIME=[C6F46EE0:01CA104B] X-Nokia-AV: Clean Cc: wuyajuan@huawei.com Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:55:41 -0000 It's a bit too late for making this request.=20 And the agenda is already packed. Sorry.=20 -Raj=20 -----Original Message----- From: ext Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com]=20 Sent: Monday, July 27, 2009 3:11 AM To: netext@ietf.org; Patil Basavaraj (Nokia-D/Dallas) Cc: wuyajuan 26753 Subject: Re: [netext] Solicitations for agenda items Dear Raj, I am sorry for the late solicitation but I would like to request a 10 min s= lot for the draft "draft-cui-netext-lma-redirection-solution-00", which may be get by the link: http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 If there is some spare time in the Netext meeting, would you please arrange= a slot for this draft? My colleague will present it on behalf of me. Thanks and regards. Xiangsong ----- Original Message ----- From: To: Sent: Tuesday, June 23, 2009 6:44 AM Subject: [netext] Solicitations for agenda items >=20 > Hello, >=20 > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. >=20 > Note that we will consider I-Ds that pertain to the scope of the charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot.=20 >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Jul 29 10:19:22 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2477B3A6F41 for ; Wed, 29 Jul 2009 10:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH6vrgjdaT-y for ; Wed, 29 Jul 2009 10:19:21 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 03B003A6ACF for ; Wed, 29 Jul 2009 10:19:20 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6THIhF6030809 for ; Wed, 29 Jul 2009 20:19:11 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 20:19:06 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 20:19:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 20:19:01 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 29 Jul 2009 19:19:00 +0200 From: To: Date: Wed, 29 Jul 2009 19:19:00 +0200 Thread-Topic: Slides uploaded... Thread-Index: AcoQblQiD/3jZLOmTLWCvowtoXeKwQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FAAB54171A6C764E969E6B4CB3C2ADD20A490022AFNOKEUMSG03mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2009 17:19:01.0395 (UTC) FILETIME=[AA5AF630:01CA1070] X-Nokia-AV: Clean Subject: [netext] Slides uploaded... X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:19:22 -0000 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20A490022AFNOKEUMSG03mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have uploaded most of the presentation slides for the Netext meeting sche= duled for Thursday, July 30th fronm 1300-1500. Thanks to all who have sent their slides on time. These are available at: http://tools.ietf.org/wg/netext/agenda -Chairs --_000_FAAB54171A6C764E969E6B4CB3C2ADD20A490022AFNOKEUMSG03mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
I have uploaded most of the presentation slides for t= he Netext meeting scheduled for Thursday, July 30th fronm 1300-1500.
Thanks to all who have sent their slides on time.
 
These are available at:
 
 
-Chairs
 
 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20A490022AFNOKEUMSG03mgd_-- From vijay@wichorus.com Wed Jul 29 12:00:15 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96B43A7108 for ; Wed, 29 Jul 2009 12:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7iTi8yU30lB for ; Wed, 29 Jul 2009 12:00:14 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 0C9943A70CA for ; Wed, 29 Jul 2009 12:00:06 -0700 (PDT) Received: from 98.97.75.6 ([98.97.75.6]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Jul 2009 19:00:05 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 29 Jul 2009 12:00:03 -0700 From: Vijay Devarapalli To: Jouni Korhonen , "Sri Gundavelli (sgundave)" , Hidetoshi Yokota Message-ID: Thread-Topic: Comments on draft-korhonen-netext-redirect Thread-Index: AcoQfsda2W4fLAaU4USXylAmquPqaw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: netext@ietf.org Subject: [netext] Comments on draft-korhonen-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:00:15 -0000 Hello, I have a few comments on the runtime LMA assignment functionality. - I am not comfortable with the second solution, the one where the first LMA just forwards the PBU to the second LMA and the response comes back from the second LMA. Anwyay, we SHOULD NOT have two solutions. We should pick one. The proxied one is better. Have you guys also considered a solution where the PBA comes back from the first LMA with the redirect mobility option, and then the MAG sends a PBU to the second LMA? This would involve an additional round trip, but is a much simpler solution that does not involve forwarding or proxying of the PBU between the LMAs. Since this additional round trip is during the initial session setup, I don't think it is a big deal - I think the draft should be extended to also address LMA-initiated redirect. Not just redirects when the MAG sends a PBU. This would be a mid-session redirect. You would need a new mobility header message from the LMA to the MAG to do this redirect. One option would be to re-use the HA Switch Message from RFC 5142 and carry the redirect mobility option in this message. This would avoid defining a new message. I can provide some text on LMA-initiated redirect if you want. - I would like to see the following paragraph expanded as per the previous conference call we had with the chairs, Jonne and Jari. :) In case of load balancing, the runtime assignment approach is just one implementation option. MAGs and LMAs can implement other solutions that are, for example, completely transparent at PMIPv6 protocol level and do not depend on the functionality defined in this specification. It needs to say that there are implementations where the multiple application blades in a chassis are visible to the external networks as one LMA with one IP address. The load balancing between these application blades is done transparently without having to redirect the MAG to another LMA. - You should also highlight the fact that the IKEv2 redirect mechanism (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here. It is good enough for Mobile IPv6, but not for PMIPv6, since IKEv2 is not run between the MAG and the LMA for every session setup. Just once, with the same IPsec SA re-used for all mobility session setups. This is just to avoid questions later in the standardization phase when folks ask you why the IKEv2 redirect mechanisms cannot be used. As I understand it, the default redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 redirect mechanism. Hope this helps. Vijay From Xiangsong.Cui@huawei.com Wed Jul 29 18:41:10 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191C93A6995 for ; Wed, 29 Jul 2009 18:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek4cUZgL8G9F for ; Wed, 29 Jul 2009 18:41:09 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 269A93A6849 for ; Wed, 29 Jul 2009 18:41:09 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNK00DM6NCA4Q@szxga04-in.huawei.com> for netext@ietf.org; Thu, 30 Jul 2009 09:40:58 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNK00G6ONC9O1@szxga04-in.huawei.com> for netext@ietf.org; Thu, 30 Jul 2009 09:40:58 +0800 (CST) Date: Thu, 30 Jul 2009 09:41:01 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <001401ca10b6$cbdb0020$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0d0c01ca0e91$cc7c1090$40106f0a@china.huawei.com> Subject: Re: [netext] Solicitations for agenda items X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 01:41:10 -0000 That's all right. Because I don't know well the cut off time, I missed uploading the draft before that time. I wish we can discuss the draft in the mail list. Regards Xiangsong ----- Original Message ----- From: To: ; Cc: Sent: Wednesday, July 29, 2009 8:54 PM Subject: RE: [netext] Solicitations for agenda items It's a bit too late for making this request. And the agenda is already packed. Sorry. -Raj -----Original Message----- From: ext Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] Sent: Monday, July 27, 2009 3:11 AM To: netext@ietf.org; Patil Basavaraj (Nokia-D/Dallas) Cc: wuyajuan 26753 Subject: Re: [netext] Solicitations for agenda items Dear Raj, I am sorry for the late solicitation but I would like to request a 10 min slot for the draft "draft-cui-netext-lma-redirection-solution-00", which may be get by the link: http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 If there is some spare time in the Netext meeting, would you please arrange a slot for this draft? My colleague will present it on behalf of me. Thanks and regards. Xiangsong ----- Original Message ----- From: To: Sent: Tuesday, June 23, 2009 6:44 AM Subject: [netext] Solicitations for agenda items > > Hello, > > The NetExt WG will meet at IETF75. > Please submit any requests for a slot on the agenda. > > Note that we will consider I-Ds that pertain to the scope of the charter. > Additionally please ensure that you have an accompanying I-D when you > request a slot. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Wed Jul 29 19:03:23 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B223A690C for ; Wed, 29 Jul 2009 19:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+mF0io8QYAP for ; Wed, 29 Jul 2009 19:03:22 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 17CD83A68F7 for ; Wed, 29 Jul 2009 19:03:22 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNK00FDQODBP9@szxga03-in.huawei.com> for netext@ietf.org; Thu, 30 Jul 2009 10:03:11 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNK00BWHODA98@szxga03-in.huawei.com> for netext@ietf.org; Thu, 30 Jul 2009 10:03:11 +0800 (CST) Date: Thu, 30 Jul 2009 10:03:11 +0800 From: Xiangsong Cui To: Vijay Devarapalli Message-id: <003401ca10b9$e4a08640$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: netext@ietf.org, Jouni Korhonen Subject: Re: [netext] Comments on draft-korhonen-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 02:03:23 -0000 Hi Vijay, I'm sorry for jumping into the discussion. > Have you guys also considered a solution where the PBA comes back from the > first LMA with the redirect mobility option, and then the MAG sends a PBU > to > the second LMA? This would involve an additional round trip, but is a much > simpler solution that does not involve forwarding or proxying of the PBU > between the LMAs. Since this additional round trip is during the initial > session setup, I don't think it is a big deal I very agree with you and I have submitted a draft about this solution. http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 Because I missed the deadline, I failed to request a slot for this draft. Regards Xiangsong ----- Original Message ----- From: "Vijay Devarapalli" To: "Jouni Korhonen" ; "Sri Gundavelli (sgundave)" ; "Hidetoshi Yokota" Cc: Sent: Thursday, July 30, 2009 3:00 AM Subject: [netext] Comments on draft-korhonen-netext-redirect > Hello, > > I have a few comments on the runtime LMA assignment functionality. > > - I am not comfortable with the second solution, the one where the first > LMA > just forwards the PBU to the second LMA and the response comes back from > the > second LMA. Anwyay, we SHOULD NOT have two solutions. We should pick one. > The proxied one is better. > > Have you guys also considered a solution where the PBA comes back from the > first LMA with the redirect mobility option, and then the MAG sends a PBU > to > the second LMA? This would involve an additional round trip, but is a much > simpler solution that does not involve forwarding or proxying of the PBU > between the LMAs. Since this additional round trip is during the initial > session setup, I don't think it is a big deal > > - I think the draft should be extended to also address LMA-initiated > redirect. Not just redirects when the MAG sends a PBU. This would be a > mid-session redirect. You would need a new mobility header message from > the > LMA to the MAG to do this redirect. One option would be to re-use the HA > Switch Message from RFC 5142 and carry the redirect mobility option in > this > message. This would avoid defining a new message. > > I can provide some text on LMA-initiated redirect if you want. > > - I would like to see the following paragraph expanded as per the previous > conference call we had with the chairs, Jonne and Jari. :) > > In case of > load balancing, the runtime assignment approach is just one > implementation option. MAGs and LMAs can implement other solutions > that are, for example, completely transparent at PMIPv6 protocol > level and do not depend on the functionality defined in this > specification. > > It needs to say that there are implementations where the multiple > application blades in a chassis are visible to the external networks as > one > LMA with one IP address. The load balancing between these application > blades > is done transparently without having to redirect the MAG to another LMA. > > - You should also highlight the fact that the IKEv2 redirect mechanism > (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here. It is > good enough for Mobile IPv6, but not for PMIPv6, since IKEv2 is not run > between the MAG and the LMA for every session setup. Just once, with the > same IPsec SA re-used for all mobility session setups. This is just to > avoid > questions later in the standardization phase when folks ask you why the > IKEv2 redirect mechanisms cannot be used. As I understand it, the default > redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 redirect > mechanism. > > Hope this helps. > > Vijay > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Jul 30 00:38:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DF43A7166 for ; Thu, 30 Jul 2009 00:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRn2cu9dXsg8 for ; Thu, 30 Jul 2009 00:38:19 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C32003A6AFC for ; Thu, 30 Jul 2009 00:38:18 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6U7bv27028346 for ; Thu, 30 Jul 2009 10:38:07 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:38:12 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:38:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:38:07 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 30 Jul 2009 09:38:06 +0200 From: To: Date: Thu, 30 Jul 2009 09:38:02 +0200 Thread-Topic: Scribe volunteers needed for NetExt meeting.. Thread-Index: AcoQ6KsKNnOVVTG9T+WEaAZJmAgWjQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FAAB54171A6C764E969E6B4CB3C2ADD20A49093BF4NOKEUMSG03mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2009 07:38:07.0459 (UTC) FILETIME=[AE342330:01CA10E8] X-Nokia-AV: Clean Subject: [netext] Scribe volunteers needed for NetExt meeting.. X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:38:19 -0000 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20A49093BF4NOKEUMSG03mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, If you are willing to take meeting notes or be a jabber scribe for the NetE= xt WG meeting scheduled for Jul 30th from 1300-1500, please let the chairs = know. -Chairs --_000_FAAB54171A6C764E969E6B4CB3C2ADD20A49093BF4NOKEUMSG03mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
If you are willing to take meeting notes or be a jabb= er scribe for the NetExt WG meeting scheduled for Jul 30th from 1300-1500, = please let the chairs know.
 
-Chairs
 
 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20A49093BF4NOKEUMSG03mgd_-- From jouni.nospam@gmail.com Thu Jul 30 01:29:38 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB5F3A717E for ; Thu, 30 Jul 2009 01:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyaS03k8gKHg for ; Thu, 30 Jul 2009 01:29:38 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id CF5B33A7181 for ; Thu, 30 Jul 2009 01:29:32 -0700 (PDT) Received: by bwz19 with SMTP id 19so436257bwz.37 for ; Thu, 30 Jul 2009 01:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=16Sh/b2sVE1/8DbLPPVZLvAAmPFFhaE4kwQ8S0+gB74=; b=qxHYatkisW/voRw3CS6aCzQ5a9c5eceTr8enypvc4OhzAl+Hf2R3/eDxP6RMc8QCS3 qBSlqbSd2cTXpwxEzfOcCvyZtKjpIhrK/xChOOru5L4shEJoPWV0HiqFuBar6boyd3j/ M6QQ20nsPWviqoeXWO6RSlXxRBlyT8s2+iwtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=p+3SvC+ilPutWMztHXfE8ZOONJU7GDvlEIAxeNxHBop10bKr9PndmvPdVBY1WAyqHi uKklEXQ50sUj7DLkUTxjPWe1n21WuXXxg0E0Uqz1o2ptNdNaeXVXsKSioDlnPC1ZQ75h tbQrTr8jUIVzgNvmmeQ5i3I9BFjxfa+QTcBfM= Received: by 10.103.181.9 with SMTP id i9mr515930mup.15.1248942571698; Thu, 30 Jul 2009 01:29:31 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org ([130.129.84.246]) by mx.google.com with ESMTPS id j10sm4741338muh.59.2009.07.30.01.29.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 01:29:31 -0700 (PDT) Message-Id: <0B6D1311-267E-4629-88C3-864680B12E3C@gmail.com> From: jouni korhonen To: Vijay Devarapalli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 11:29:29 +0300 References: X-Mailer: Apple Mail (2.935.3) Cc: Jouni Korhonen , netext@ietf.org Subject: Re: [netext] Comments on draft-korhonen-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:29:39 -0000 Hi Vijay, On Jul 29, 2009, at 10:00 PM, Vijay Devarapalli wrote: > Hello, > > I have a few comments on the runtime LMA assignment functionality. > > - I am not comfortable with the second solution, the one where the > first LMA > just forwards the PBU to the second LMA and the response comes back > from the > second LMA. Anwyay, we SHOULD NOT have two solutions. We should pick > one. > The proxied one is better. If you check the presentation material I have provided, it should answer this ;) > > Have you guys also considered a solution where the PBA comes back > from the > first LMA with the redirect mobility option, and then the MAG sends > a PBU to > the second LMA? This would involve an additional round trip, but is > a much > simpler solution that does not involve forwarding or proxying of the > PBU > between the LMAs. Since this additional round trip is during the > initial > session setup, I don't think it is a big deal We have considered it (for real, I even wrote a version of draft -00 with that approach) but chose not to go with an additional roundtrip at the end. > > - I think the draft should be extended to also address LMA-initiated > redirect. Not just redirects when the MAG sends a PBU. This would be a > mid-session redirect. You would need a new mobility header message > from the > LMA to the MAG to do this redirect. One option would be to re-use > the HA > Switch Message from RFC 5142 and carry the redirect mobility option > in this > message. This would avoid defining a new message. Currently I am not too enthusiast of LMA initiated explicit mid- session LMA reassignment. If we were to proceed to that direction, RFC5142 could be adjusted for it. I would avoid defining any new messages. > > I can provide some text on LMA-initiated redirect if you want. > > - I would like to see the following paragraph expanded as per the > previous > conference call we had with the chairs, Jonne and Jari. :) I should remind that, for an unknown reason to me, I was not part of that call. Therefore, I generally feel uncomfortable referring it as a common agreement to scope my document. We can discuss this, no problem with that. > > In case of > load balancing, the runtime assignment approach is just one > implementation option. MAGs and LMAs can implement other solutions > that are, for example, completely transparent at PMIPv6 protocol > level and do not depend on the functionality defined in this > specification. > > It needs to say that there are implementations where the multiple > application blades in a chassis are visible to the external networks > as one > LMA with one IP address. The load balancing between these > application blades > is done transparently without having to redirect the MAG to another > LMA. And the above existing text is not enough to apply for this case? I think it is. > > - You should also highlight the fact that the IKEv2 redirect mechanism > (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here. > It is We don't reference to the above draft in our document, so I don't understand the dependency. > good enough for Mobile IPv6, but not for PMIPv6, since IKEv2 is not > run > between the MAG and the LMA for every session setup. Just once, with > the > same IPsec SA re-used for all mobility session setups. This is just > to avoid > questions later in the standardization phase when folks ask you why > the > IKEv2 redirect mechanisms cannot be used. As I understand it, the > default > redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 redirect > mechanism. Hmm, right. Current text says that the SAs with r2LMAs and rfLMAs must have been setup in advance. The text could be more explicit here and more verbal on the background assumptions & issues regarding the SAs. > > Hope this helps. Thanks. It always does. Jouni > > Vijay > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Thu Jul 30 03:00:36 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE6D3A6FF7 for ; Thu, 30 Jul 2009 03:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijqb3TrpHd9u for ; Thu, 30 Jul 2009 03:00:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E10DD3A63C9 for ; Thu, 30 Jul 2009 03:00:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL007EWACPNT@szxga04-in.huawei.com> for netext@ietf.org; Thu, 30 Jul 2009 17:58:01 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL0093CACPEH@szxga04-in.huawei.com> for netext@ietf.org; Thu, 30 Jul 2009 17:58:01 +0800 (CST) Date: Thu, 30 Jul 2009 17:58:00 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, jouni korhonen , netext@ietf.org Message-id: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 10:00:37 -0000 Hello Raj and Jouni, I have a question about the draft. Firstly, I agree the requirement of multiple PDN connections to the same APN. IMO, the major idea of this draft is as mentioned in the draft: The combination of MN-Identifier + Service Selection + Connection Identifier can uniquely identify mobility sessions even if the selected service on each mobility session for the same MN- Identifier are the same. It recall me to another draft, "draft-ietf-netlmm-grekey-option-09.txt". In the GREKEY draft, it says: This specification defines the GRE Key option to be used for the negotiation of GRE encapsulation mode and exchange of the uplink and downlink GRE keys. The negotiated downlink and uplink GRE keys can be used for marking the downlink and uplink traffic for a specific mobility session. The connid draft is used to identify a certain session among multiple sessions, while the grekey draft is used to identify a certain link/flow in the tunnel between the MAG and the LMA. When I look at figure 1 in the grekey draft, it seems similar for the both cases, because we just need to identify a connection, and the connection may be a session or a flow. So I have the question: if we expand the meaning of GRE Key option, without protocol expansion, can we use the combination "MN-Identifier + Service Selection + GRE key" to identify the connections to the same APN? Regards Xiangsong ----- Original Message ----- From: To: Sent: Thursday, July 16, 2009 5:33 AM Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > > > Hello, > > A few questions/comments related to the proposal to add a connection > identifier to the PMIP6 signaling and BCE: > > 1. Each of the PDN bearers will have a unique prefix assigned to it by > the LMA, right? Even though the MN-ID remains the same the LMA will > have to create multiple BCEs for the MN. The scenario is equivalent > to the MN attaching via different interfaces thru the same MAG/LMA > pair. > > 2. The I-D says that the mechanism by which the MAG figures out that > a new bi-directional tunnel is needed to be established (and a new > prefix obtained) is out of scope. In certain networks you are > obtaining this information from L2 and is used by the MAG. Current > RFC5213 lacks the ability by which an MN (which is already attached > via an interface) can request dynamically a new prefix to be > assigned to it for the same interface. The connection ID would be > useful if we were to also specify how the MN can request an > additional prefix via an interface that is already attached and has > been assigned a prefix from a MAG/LMA pair. > It might be useful to explain how L2s can provide such indications in an > appendix. > > 3. In the case of HO the target MAG will not be aware of the CID > unless there a context transfer mechanism between the MAGs. Please > note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes > context transfer capability between MAGs. > > 4. If each PDN bearer is assigned a unique prefix, can you not use the > HNP assigned as the CID? > > I do agree with the need to support the ability by which multiple > mobility sessions to the same LMA (via the same MAG) from a single > interface is needed. This is applicable in EPC and other networks > which use PMIP6. > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From alper.yegin@yegin.org Thu Jul 30 05:02:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD1028C165 for ; Thu, 30 Jul 2009 05:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt9iUr-I3LSz for ; Thu, 30 Jul 2009 05:02:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 041D528C162 for ; Thu, 30 Jul 2009 05:02:10 -0700 (PDT) Received: from LENOVO (dhcp-57aa.meeting.ietf.org [130.129.87.170]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MWUKk2aLb-000PEn; Thu, 30 Jul 2009 08:02:08 -0400 From: "Alper Yegin" To: Date: Thu, 30 Jul 2009 15:02:05 +0300 Message-ID: <060f01ca110d$903ca120$b0b5e360$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0610_01CA1126.B589D920" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRDY3vYI+oJ9LbQhuRXYYW4CQ2tg== Content-Language: en-us X-Provags-ID: V01U2FsdGVkX19p6AlxiKAfVsymlfm3kwY0gM4zO3cr7ONkRgG +2bgLW13R8EJZ90BW/+DKzX2P+jl9c+Z5KvD6ZnzL3YjVWbAex LASTMoKqx5P5cPkeyxvUw== Subject: [netext] PMIP6 and roaming X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:02:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0610_01CA1126.B589D920 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Continuing the discussion on the ML.. Consider mobile1 and mobile2 subscribed to data service in USA. They are in Sweden, accessing Internet by "roaming" to a Swedish operator network. Does PMIP6 not support this case where MAG is in Swedish operator network, and LMA in USA operator's network? I think the answer is yes. Wouldn't we want to optimize the path between mobile1 and mobile2 to save the traffic from making the unnecessary USA trip? I think the answer is yes again. Comments? Alper ------=_NextPart_000_0610_01CA1126.B589D920 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Continuing the discussion on the = ML……

 

 

Consider mobile1 and mobile2 subscribed to data = service in USA.

They are in Sweden, accessing Internet by = “roaming” to a Swedish operator network.

 

Does PMIP6 not support this case where MAG is in = Swedish operator network, and LMA in USA operator’s network? I think the = answer is yes.

 

Wouldn’t we want to optimize the path between = mobile1 and mobile2 to save the traffic from making the unnecessary USA trip? I = think the answer is yes again.

 

Comments?

 

Alper

 

 

 

 

 

 

 

------=_NextPart_000_0610_01CA1126.B589D920-- From desire.oulai@ericsson.com Thu Jul 30 06:14:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFE43A69FA for ; Thu, 30 Jul 2009 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyQizLXvtg4s for ; Thu, 30 Jul 2009 06:14:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 2CA7F3A6FB0 for ; Thu, 30 Jul 2009 06:13:42 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n6UDDfWt021816; Thu, 30 Jul 2009 08:13:43 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 08:13:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 09:13:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] PMIP6 and roaming Thread-Index: AcoRDY3vYI+oJ9LbQhuRXYYW4CQ2tgACGU1J References: <060f01ca110d$903ca120$b0b5e360$@yegin@yegin.org> From: "Desire Oulai" To: "Alper Yegin" , X-OriginalArrivalTime: 30 Jul 2009 13:13:31.0804 (UTC) FILETIME=[893F7DC0:01CA1117] Subject: [netext] =?iso-8859-1?q?RE=A0=3A__PMIP6_and_roaming?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 13:14:09 -0000 Hi Alper, =20 See inline! =20 Desire ________________________________ De: netext-bounces@ietf.org de la part de Alper Yegin Date: jeu. 2009-07-30 08:02 =C0: netext@ietf.org Objet : [netext] PMIP6 and roaming =20 Continuing the discussion on the ML...... =20 =20 Consider mobile1 and mobile2 subscribed to data service in USA. They are in Sweden, accessing Internet by "roaming" to a Swedish = operator network. =20 Does PMIP6 not support this case where MAG is in Swedish operator = network, and LMA in USA operator's network? I think the answer is yes. [Desire]: I think PMIP6 as defined in RFC5213 does not support this = scenario as the MAG are not in the same PMIP domain. However, SDOs like = 3GPP supports home tunnelling. =20 Wouldn't we want to optimize the path between mobile1 and mobile2 to = save the traffic from making the unnecessary USA trip? I think the = answer is yes again. [Desire]: I agree that it is an interesting optimization. But we need = first to clarify the relation between the MAG in sweden and the LMA in = USA. So we need to specify PMIP6 roaming before talking about Localized = routing in PMIP6 roaming. =20 Comments? =20 Alper =20 =20 =20 =20 =20 =20 =20 From alper.yegin@yegin.org Thu Jul 30 06:31:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C093A6C57 for ; Thu, 30 Jul 2009 06:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd2Yi7Ecfh33 for ; Thu, 30 Jul 2009 06:31:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A974F3A6C30 for ; Thu, 30 Jul 2009 06:31:11 -0700 (PDT) Received: from LENOVO (dhcp-35ee.meeting.ietf.org [130.129.53.238]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MWViv4B8Q-000PNZ; Thu, 30 Jul 2009 09:31:13 -0400 From: "Alper Yegin" To: "'Desire Oulai'" , References: <060f01ca110d$903ca120$b0b5e360$@yegin@yegin.org> In-Reply-To: Date: Thu, 30 Jul 2009 16:31:09 +0300 Message-ID: <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRDY3vYI+oJ9LbQhuRXYYW4CQ2tgACGU1JAADpwjA= Content-Language: en-us X-Provags-ID: V01U2FsdGVkX19zg0BqgUZu8l7o+2UXQFPhFkCZRXCXKfOIe0T NVxeOAoA678fNuVPvrKk/83ogjNsGfvGgz6n4p/+g2enfvvx3H FXvRyxzn/sEHm0oc7ljrQ== Subject: Re: [netext] PMIP6 and roaming X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 13:31:12 -0000 Hi Desire, RFC 5213: Proxy Mobile IPv6 Domain (PMIPv6-Domain) Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be set up and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured. I remember this was specifically discussed and we had come up with a = text that refers to "local mobility anchors and mobile access gateways = between which security associations can be set up" as the limiting factor that = sets the boundary. And security associations can be setup between MAGs and = LMAs belonging to separate operators when there is a roaming agreement. WiMAX architecture already does that. Alper > -----Original Message----- > From: Desire Oulai [mailto:desire.oulai@ericsson.com] > Sent: Thursday, July 30, 2009 4:13 PM > To: Alper Yegin; netext@ietf.org > Subject: RE=A0: [netext] PMIP6 and roaming >=20 > Hi Alper, >=20 > See inline! >=20 > Desire >=20 > ________________________________ >=20 > De: netext-bounces@ietf.org de la part de Alper Yegin > Date: jeu. 2009-07-30 08:02 > =C0: netext@ietf.org > Objet : [netext] PMIP6 and roaming >=20 >=20 >=20 >=20 >=20 > Continuing the discussion on the ML...... >=20 >=20 >=20 >=20 >=20 > Consider mobile1 and mobile2 subscribed to data service in USA. >=20 > They are in Sweden, accessing Internet by "roaming" to a Swedish > operator network. >=20 >=20 >=20 > Does PMIP6 not support this case where MAG is in Swedish operator > network, and LMA in USA operator's network? I think the answer is yes. >=20 > [Desire]: I think PMIP6 as defined in RFC5213 does not support this > scenario as the MAG are not in the same PMIP domain. However, SDOs = like > 3GPP supports home tunnelling. >=20 >=20 >=20 > Wouldn't we want to optimize the path between mobile1 and mobile2 to > save the traffic from making the unnecessary USA trip? I think the > answer is yes again. >=20 > [Desire]: I agree that it is an interesting optimization. But we need > first to clarify the relation between the MAG in sweden and the LMA in > USA. So we need to specify PMIP6 roaming before talking about = Localized > routing in PMIP6 roaming. >=20 >=20 >=20 > Comments? >=20 >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From jouni.nospam@gmail.com Thu Jul 30 08:50:01 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DE13A698F for ; Thu, 30 Jul 2009 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd+UtPD-9wdc for ; Thu, 30 Jul 2009 08:50:00 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id AC1D73A6C11 for ; Thu, 30 Jul 2009 08:49:59 -0700 (PDT) Received: by ewy10 with SMTP id 10so851962ewy.37 for ; Thu, 30 Jul 2009 08:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=iAIalKwz4v9PlS3uhS502c6CrJq+sI6/Iqmo1pOCLqE=; b=rMLy2oYzPYzgsv83jZaVlPStOSig7EMSYBrapaopTI3a8yNp6nW1WGx0VzjFWk9pUH Kd91b0rySPrbCkoefNcsTbN0ZUqzNxqPhfMN4qVRqYbVlNbYzuuhCPqv5YDpE9WkHYMN PoTJ2ZOXm18zmoJV+p8vKVRif4d2+MBibFqSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=cGUjjHf3xR2FFUL3EiY3/kRioeCNlD6dpkBbpjfF5kaKbMTJQLgPB9Sjwr89z20hqj 8RGbwdjOqEYOUCrVQFrnMHs87L/9N1eJZFZfkhqEH4ELCO8Yj5guQmlBKjKDAwFzRJez D5QFeOLhM/TJf3xeVEhajqSKwPxu8DlsMvvRY= Received: by 10.216.19.68 with SMTP id m46mr284620wem.7.1248968999186; Thu, 30 Jul 2009 08:49:59 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org (dhcp-54f6.meeting.ietf.org [130.129.84.246]) by mx.google.com with ESMTPS id 10sm2532514eyz.51.2009.07.30.08.49.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 08:49:58 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> X-Priority: 3 References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 18:49:56 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 15:50:01 -0000 Hi Xiangsong, On Jul 30, 2009, at 12:58 PM, Xiangsong Cui wrote: > Hello Raj and Jouni, > > I have a question about the draft. > > Firstly, I agree the requirement of multiple PDN connections > to the same APN. > > IMO, the major idea of this draft is as mentioned in the draft: > > The combination of MN-Identifier + Service Selection + > Connection Identifier can uniquely identify mobility sessions even if > the selected service on each mobility session for the same MN- > Identifier are the same. > > It recall me to another draft, "draft-ietf-netlmm-grekey- > option-09.txt". > In the GREKEY draft, it says: > This specification defines the GRE Key option to be used for the > negotiation of GRE encapsulation mode and exchange of the uplink and > downlink GRE keys. The negotiated downlink and uplink GRE keys can > be used for marking the downlink and uplink traffic for a specific > mobility session. > > The connid draft is used to identify a certain session among > multiple sessions, while the grekey draft is used to identify a > certain link/flow in the tunnel between the MAG and the LMA. > > When I look at figure 1 in the grekey draft, it seems similar for the > both cases, because we just need to identify a connection, and the > connection may be a session or a flow. > > So I have the question: > if we expand the meaning of GRE Key option, without protocol > expansion, > can we use the combination "MN-Identifier + Service Selection + GRE > key" > to identify the connections to the same APN? There are few reasons. First, which GRE key to use? Uplink or downlink? Obviously, the MAG does not know the uplink GRE key when sending a PBU during the initial attach or after a handover.. so you would lack the "identifier" in the MAG in some situations. If we were to use the downlink key, according to the GRE key draft it is not guaranteed that the downlink remains the same between inter-MAG handover. Second, the use of GRE keys and GRE tunneling is optional in PMIP6. Well, so is Service Selection too but I would avoid building additional dependencies between different documents if just possible. Third, overloading the function of the GRE key option does not sound a good idea in general, even if it were possible. Cheers, Jouni > > Regards > > Xiangsong > > ----- Original Message ----- From: > To: > Sent: Thursday, July 16, 2009 5:33 AM > Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6- > connid-00 > > >> >> >> Hello, >> >> A few questions/comments related to the proposal to add a connection >> identifier to the PMIP6 signaling and BCE: >> >> 1. Each of the PDN bearers will have a unique prefix assigned to it >> by >> the LMA, right? Even though the MN-ID remains the same the LMA will >> have to create multiple BCEs for the MN. The scenario is equivalent >> to the MN attaching via different interfaces thru the same MAG/LMA >> pair. >> >> 2. The I-D says that the mechanism by which the MAG figures out that >> a new bi-directional tunnel is needed to be established (and a new >> prefix obtained) is out of scope. In certain networks you are >> obtaining this information from L2 and is used by the MAG. Current >> RFC5213 lacks the ability by which an MN (which is already attached >> via an interface) can request dynamically a new prefix to be >> assigned to it for the same interface. The connection ID would be >> useful if we were to also specify how the MN can request an >> additional prefix via an interface that is already attached and has >> been assigned a prefix from a MAG/LMA pair. >> It might be useful to explain how L2s can provide such indications >> in an >> appendix. >> >> 3. In the case of HO the target MAG will not be aware of the CID >> unless there a context transfer mechanism between the MAGs. Please >> note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes >> context transfer capability between MAGs. >> >> 4. If each PDN bearer is assigned a unique prefix, can you not use >> the >> HNP assigned as the CID? >> >> I do agree with the need to support the ability by which multiple >> mobility sessions to the same LMA (via the same MAG) from a single >> interface is needed. This is applicable in EPC and other networks >> which use PMIP6. >> >> -Raj >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From vijay@wichorus.com Thu Jul 30 09:36:56 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACC528C186 for ; Thu, 30 Jul 2009 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZVbx36Sw2MC for ; Thu, 30 Jul 2009 09:36:55 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E30E03A635F for ; Thu, 30 Jul 2009 09:36:54 -0700 (PDT) Received: from 67.161.28.136 ([67.161.28.136]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jul 2009 16:36:56 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 30 Jul 2009 09:36:54 -0700 From: Vijay Devarapalli To: jouni korhonen Message-ID: Thread-Topic: [netext] Comments on draft-korhonen-netext-redirect Thread-Index: AcoRM/JSPbtbgzXFQEup2JeU8MXZ/Q== In-Reply-To: <0B6D1311-267E-4629-88C3-864680B12E3C@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Jouni Korhonen , netext@ietf.org Subject: Re: [netext] Comments on draft-korhonen-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:36:56 -0000 Hi Jouni, On 7/30/09 1:29 AM, "jouni korhonen" wrote: > Hi Vijay, > > On Jul 29, 2009, at 10:00 PM, Vijay Devarapalli wrote: > >> Hello, >> >> I have a few comments on the runtime LMA assignment functionality. >> >> - I am not comfortable with the second solution, the one where the >> first LMA >> just forwards the PBU to the second LMA and the response comes back >> from the >> second LMA. Anwyay, we SHOULD NOT have two solutions. We should pick >> one. >> The proxied one is better. > > If you check the presentation material I have provided, it should > answer this ;) Ok, cool. >> Have you guys also considered a solution where the PBA comes back >> from the >> first LMA with the redirect mobility option, and then the MAG sends >> a PBU to >> the second LMA? This would involve an additional round trip, but is >> a much >> simpler solution that does not involve forwarding or proxying of the >> PBU >> between the LMAs. Since this additional round trip is during the >> initial >> session setup, I don't think it is a big deal > > We have considered it (for real, I even wrote a version of draft -00 > with that approach) but chose not to go with an additional roundtrip > at the end. Hmm... I still think it would be lot simpler to just redirect the MAG to the new LMA. Proxying the PBU obviously is a bit tricky. Does the first LMA replace the destination address of the PBU with the new LMA's IP address? Or does the first LMA append some sort of information to the proxied PBU? Will the hop count get incremented? We probably need some more information on how the proxied PBU looks like. >> - I think the draft should be extended to also address LMA-initiated >> redirect. Not just redirects when the MAG sends a PBU. This would be a >> mid-session redirect. You would need a new mobility header message >> from the >> LMA to the MAG to do this redirect. One option would be to re-use >> the HA >> Switch Message from RFC 5142 and carry the redirect mobility option >> in this >> message. This would avoid defining a new message. > > Currently I am not too enthusiast of LMA initiated explicit mid- > session LMA reassignment. If we were to proceed to that direction, > RFC5142 could be adjusted for it. I would avoid defining any new > messages. Well, we do have a mechanism currently for MIPv6 and PMIPv6 to redirect the MN/MAG to another HA/LMA in the middle of a session. It is a Proposed Standard. It would be good, if that mechanism is consistent with the runtime assignment of the LMA. It would be a bad idea to have two different sets of mechanisms. Or are you saying that the LMA initiated mid session redirect does not have any use cases? >> I can provide some text on LMA-initiated redirect if you want. >> >> - I would like to see the following paragraph expanded as per the >> previous >> conference call we had with the chairs, Jonne and Jari. :) > > > I should remind that, for an unknown reason to me, I was not part of > that call. Therefore, I generally feel uncomfortable referring it as a > common agreement to scope my document. We can discuss this, no problem > with that. Jouni, I sent the comments assuming your document is going to become the WG document soon. You are of course free to have whatever text you want in your document. :) BTW, that call was about adding the LMA redirect to the NETEXT charter. If you remember, there was no time for discussing this during the BoF. There was a 2 min presentation followed by 30 seconds time at the mic. I had some concerns. The redirect item was not amount the list of items originally proposed for the NETEXT charter. This call was about discussing my concerns before adding the item to the NETEXT charter. We weren't discussing a specific draft. And after the call, I updated you on what was discussed. If you prefer, I can bring this up during the consensus call for adopting the document then. >> In case of >> load balancing, the runtime assignment approach is just one >> implementation option. MAGs and LMAs can implement other solutions >> that are, for example, completely transparent at PMIPv6 protocol >> level and do not depend on the functionality defined in this >> specification. >> >> It needs to say that there are implementations where the multiple >> application blades in a chassis are visible to the external networks >> as one >> LMA with one IP address. The load balancing between these >> application blades >> is done transparently without having to redirect the MAG to another >> LMA. > > And the above existing text is not enough to apply for this case? I > think it is. Not really. Runtime LMA assignment can be done transparently among multiple application blades without any external node knowing about it. It is actually a solution for the problem we are trying to address. I can provide the text if you want. >> - You should also highlight the fact that the IKEv2 redirect mechanism >> (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here. >> It is > > We don't reference to the above draft in our document, so I don't > understand the dependency. I was trying to say that the IKEv2 redirect has become the default redirect mechanism for MIPv6. So there might questions later on on why that is not sufficient for PMIPv6 too. So adding some text that says it is not really application, because IKEv2 is not run between the MAG and the LMA for every session setup, would be good. > >> good enough for Mobile IPv6, but not for PMIPv6, since IKEv2 is not >> run >> between the MAG and the LMA for every session setup. Just once, with >> the >> same IPsec SA re-used for all mobility session setups. This is just >> to avoid >> questions later in the standardization phase when folks ask you why >> the >> IKEv2 redirect mechanisms cannot be used. As I understand it, the >> default >> redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 redirect >> mechanism. > > Hmm, right. Current text says that the SAs with r2LMAs and rfLMAs must > have been setup in advance. The text could be more explicit here and > more verbal on the background assumptions & issues regarding the SAs. Ok. Vijay > >> >> Hope this helps. > > Thanks. It always does. > > Jouni > > > >> >> Vijay >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From jouni.nospam@gmail.com Thu Jul 30 09:45:50 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE4A3A68FD for ; Thu, 30 Jul 2009 09:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfK9THK+WOx3 for ; Thu, 30 Jul 2009 09:45:49 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 9590B3A68EF for ; Thu, 30 Jul 2009 09:45:49 -0700 (PDT) Received: by ewy10 with SMTP id 10so898315ewy.37 for ; Thu, 30 Jul 2009 09:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=VBOI3rTUBY+YEGpANQUMx6NJfiE7Dx8ke0h2lqS5HoU=; b=bYQUq7jOLbnkFAVCSh8r44mj99BV18kLyU/UD/8ddaEEjDGwPn0ZoGJO+JkAEzExva 18POgxwgLvok+ah/BZNqq8/I/WNF3xvdB/pt11kmeVWx/ntdrf42mgOcP1vnIsOD4ioy vJRZ5AGx0vVlAPdn6ZFQ0I8xyin9QKIpc19GE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=VOkcHyjOTy0f/GlrHZg7o7SZMPcLMyDVCsScheCafwISpm7l9OqG5qPvNdG+JpYcfV PTgTDo8s/6+lGQHPu2xrjKnJy3hxjhEFG/X7iLK96Ndq4fyJIbzC2RfUD/OOXcQbiJG5 VmXHwmjUaasxDJrvZ+zE+RbFCjDYuZIsf48MU= Received: by 10.216.29.82 with SMTP id h60mr274708wea.162.1248972348554; Thu, 30 Jul 2009 09:45:48 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org ([130.129.84.246]) by mx.google.com with ESMTPS id 28sm2982249eyg.50.2009.07.30.09.45.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 09:45:48 -0700 (PDT) Message-Id: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> From: jouni korhonen To: netext@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 19:45:46 +0300 X-Mailer: Apple Mail (2.935.3) Subject: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:45:50 -0000 Hi all, To follow up and clarify the questions from Rajeev, here is something that hopefully makes things clearer. The "proxied" case can be represented as below. The assumption is that the rfLMA and the r2LMA can exchange information between each other, and that the MAG has SAs with both rfLMA and the r2LMA. We do not define how and what goes between the rfLMA and the r2LMA. That is internal to the "LMA system", whatever that "LMA system" constitutes of (that would imply a single vendor within a "LMA system" but I guess it would reflect the reality anyway). We need to state in the draft, though, that a MAG can be sure the r2LMA has a binding setup when it receives a PBA with both redirection information and a successful result code. There is both vendor and operator interest in this approach, so I consider it important. MAG rfLMA r2LMA | | | |--PBU-->|- - - - | (redirection takes place, |<--PBA--| - - - -| PBA contains rfLMA & r2LMA | | | information) | | | |<=====data======>| | | | |-------PBU------>| (lifetime extension, |<------PBA-------| de-registration, etc | | | I don't mind nuking the "direct" solution in the draft. Actually I would be happy to do that ;) If folks are fine with options, we could add a variation of the "proxied" case, where another roundtrip of PBU/ PBA is needed between a MAG and a r2LMA before data can flow. This would, of course, be runtime negotiated. Cheers, Jouni From jouni.nospam@gmail.com Thu Jul 30 10:25:02 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9487A3A6AAC for ; Thu, 30 Jul 2009 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YcHa2wcNYKR for ; Thu, 30 Jul 2009 10:25:01 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id F1FA53A6969 for ; Thu, 30 Jul 2009 10:25:00 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so427540eye.31 for ; Thu, 30 Jul 2009 10:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=hKgNEkSz31VwVn4BvZzfGlEzGPxil0c8rIVIuhqDm18=; b=W2RkFDpMDGWzZPzsGMe8SU3stIzLNkq7LPuZY5SPJSk74+8VEu3AR4Z2n3tidMabrD ikyvGJEucjrQKUe47p9g1IT3auGJa/5Bfer0LOmE2F/wyDQyYtGOCVAKni45qb1z8QR4 pTqtF5TB2VfVp26nViQI0luk24N7J1is+Mgng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=hd6KkVtf2L29onZblogbT/QtDJOvNvq/DlS/LzxtzrHgI9Vu/uVAAcLoRx65DPMG/R b9rCHi0gfYb85rnnR6wLpMvfhp4VM2A6ygLn3ZyupFIN38sd5iqDHcd9gNFEEjeIFYh5 LiCHd5C97ncoqqJ/RQx5rfku2PsfAIVpEqC5Q= Received: by 10.210.86.1 with SMTP id j1mr1987617ebb.61.1248974700030; Thu, 30 Jul 2009 10:25:00 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org (dhcp-54f6.meeting.ietf.org [130.129.84.246]) by mx.google.com with ESMTPS id 24sm490487eyx.3.2009.07.30.10.24.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 10:24:59 -0700 (PDT) Message-Id: <3EC96AA0-3F09-4497-879B-3138BE4464EB@gmail.com> From: jouni korhonen To: Vijay Devarapalli In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 20:24:58 +0300 References: X-Mailer: Apple Mail (2.935.3) Cc: Jouni Korhonen , netext@ietf.org Subject: Re: [netext] Comments on draft-korhonen-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 17:25:02 -0000 Hi Vijay, On Jul 30, 2009, at 7:36 PM, Vijay Devarapalli wrote: [snipeti-snap] >>> >> >> We have considered it (for real, I even wrote a version of draft -00 >> with that approach) but chose not to go with an additional roundtrip >> at the end. > > Hmm... I still think it would be lot simpler to just redirect the > MAG to the > new LMA. Proxying the PBU obviously is a bit tricky. Does the first > LMA > replace the destination address of the PBU with the new LMA's IP > address? Or > does the first LMA append some sort of information to the proxied > PBU? Will > the hop count get incremented? We probably need some more > information on how > the proxied PBU looks like. These are good questions. I would still argue that what happens between the rfLMA and the r2LMA in this particular scenario is internal to the "LMA system". However, I do not mind describing a possible solution approach or two, especially if it makes things clearer for other folks. > >>> - I think the draft should be extended to also address LMA-initiated >>> redirect. Not just redirects when the MAG sends a PBU. This would >>> be a >>> mid-session redirect. You would need a new mobility header message >>> from the >>> LMA to the MAG to do this redirect. One option would be to re-use >>> the HA >>> Switch Message from RFC 5142 and carry the redirect mobility option >>> in this >>> message. This would avoid defining a new message. >> >> Currently I am not too enthusiast of LMA initiated explicit mid- >> session LMA reassignment. If we were to proceed to that direction, >> RFC5142 could be adjusted for it. I would avoid defining any new >> messages. > > Well, we do have a mechanism currently for MIPv6 and PMIPv6 to > redirect the > MN/MAG to another HA/LMA in the middle of a session. It is a Proposed > Standard. It would be good, if that mechanism is consistent with the > runtime > assignment of the LMA. It would be a bad idea to have two different > sets of > mechanisms. > > Or are you saying that the LMA initiated mid session redirect does > not have > any use cases? I am not saying it does not have use cases. However, I could argue the mid-session redirect would be far far less probable to happen than during the initial PBU/PBA exchange. And the mid-session redirect is not trivial, unless we can state that there is no need to preserve the HNP. >>> I can provide some text on LMA-initiated redirect if you want. >>> >>> - I would like to see the following paragraph expanded as per the >>> previous >>> conference call we had with the chairs, Jonne and Jari. :) >> >> >> I should remind that, for an unknown reason to me, I was not part of >> that call. Therefore, I generally feel uncomfortable referring it >> as a >> common agreement to scope my document. We can discuss this, no >> problem >> with that. > > Jouni, I sent the comments assuming your document is going to become > the WG > document soon. You are of course free to have whatever text you want > in your > document. :) Ah, well that is what I hope too ;) > BTW, that call was about adding the LMA redirect to the NETEXT > charter. If > you remember, there was no time for discussing this during the BoF. > There Well, I was not there. I was using my proxy while handing off to other continent. Anyway, got your point. > was a 2 min presentation followed by 30 seconds time at the mic. I > had some > concerns. The redirect item was not amount the list of items > originally > proposed for the NETEXT charter. This call was about discussing my > concerns > before adding the item to the NETEXT charter. We weren't discussing a > specific draft. > > And after the call, I updated you on what was discussed. > > If you prefer, I can bring this up during the consensus call for > adopting > the document then. Heh ;) > >>> In case of >>> load balancing, the runtime assignment approach is just one >>> implementation option. MAGs and LMAs can implement other solutions >>> that are, for example, completely transparent at PMIPv6 protocol >>> level and do not depend on the functionality defined in this >>> specification. >>> >>> It needs to say that there are implementations where the multiple >>> application blades in a chassis are visible to the external networks >>> as one >>> LMA with one IP address. The load balancing between these >>> application blades >>> is done transparently without having to redirect the MAG to another >>> LMA. >> >> And the above existing text is not enough to apply for this case? I >> think it is. > > Not really. Runtime LMA assignment can be done transparently among > multiple > application blades without any external node knowing about it. It is Sure. One can do it transparently. We specifically do not want complete transparency, thus these modifications to the base protocol. > actually a solution for the problem we are trying to address. I can > provide > the text if you want. Sure, go ahead. > >>> - You should also highlight the fact that the IKEv2 redirect >>> mechanism >>> (draft-ietf-ipsecme-ikev2-redirect-11.txt) is not sufficient here. >>> It is >> >> We don't reference to the above draft in our document, so I don't >> understand the dependency. > > I was trying to say that the IKEv2 redirect has become the default > redirect > mechanism for MIPv6. So there might questions later on on why that > is not > sufficient for PMIPv6 too. So adding some text that says it is not > really > application, because IKEv2 is not run between the MAG and the LMA > for every > session setup, would be good. Right, good point. Will add this. >>> good enough for Mobile IPv6, but not for PMIPv6, since IKEv2 is not >>> run >>> between the MAG and the LMA for every session setup. Just once, with >>> the >>> same IPsec SA re-used for all mobility session setups. This is just >>> to avoid >>> questions later in the standardization phase when folks ask you why >>> the >>> IKEv2 redirect mechanisms cannot be used. As I understand it, the >>> default >>> redirect mechanism for Mobile IPv6 in 3GPP specs is the IKEv2 >>> redirect >>> mechanism. >> >> Hmm, right. Current text says that the SAs with r2LMAs and rfLMAs >> must >> have been setup in advance. The text could be more explicit here and >> more verbal on the background assumptions & issues regarding the SAs. > > Ok. > > Vijay Cheers, Jouni [snapeti-snip] From vijay@wichorus.com Thu Jul 30 11:46:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31363A69D3 for ; Thu, 30 Jul 2009 11:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDfHbOTWeXtl for ; Thu, 30 Jul 2009 11:46:44 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E9A983A682F for ; Thu, 30 Jul 2009 11:46:43 -0700 (PDT) Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jul 2009 18:46:44 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 30 Jul 2009 11:46:43 -0700 From: Vijay Devarapalli To: Alper Yegin , 'Desire Oulai' , Message-ID: Thread-Topic: [netext] PMIP6 and roaming Thread-Index: AcoRDY3vYI+oJ9LbQhuRXYYW4CQ2tgACGU1JAADpwjAACx6wRw== In-Reply-To: <063901ca111a$01ce9c60$056bd520$@yegin@yegin.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [netext] PMIP6 and roaming X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 18:46:44 -0000 On 7/30/09 6:31 AM, "Alper Yegin" wrote: > Hi Desire, >=20 > RFC 5213: >=20 > Proxy Mobile IPv6 Domain (PMIPv6-Domain) >=20 > Proxy Mobile IPv6 domain refers to the network where the mobility > management of a mobile node is handled using the Proxy Mobile IPv6 > protocol as defined in this specification. The Proxy Mobile IPv6 > domain includes local mobility anchors and mobile access gateways > between which security associations can be set up and > authorization for sending Proxy Binding Updates on behalf of the > mobile nodes can be ensured. >=20 >=20 > I remember this was specifically discussed and we had come up with a text > that refers to "local mobility anchors and mobile access gateways between > which security associations can be set up" as the limiting factor that se= ts > the boundary. And security associations can be setup between MAGs and LMA= s > belonging to separate operators when there is a roaming agreement. WiMAX > architecture already does that. Exactly. Even if the LMA and the MAG are in different operator networks, they can be part of the same PMIPv6 domain. So you can have a mobility session between the MAG and the LMA in different operator networks. Vijay >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Desire Oulai [mailto:desire.oulai@ericsson.com] >> Sent: Thursday, July 30, 2009 4:13 PM >> To: Alper Yegin; netext@ietf.org >> Subject: RE=A0: [netext] PMIP6 and roaming >>=20 >> Hi Alper, >>=20 >> See inline! >>=20 >> Desire >>=20 >> ________________________________ >>=20 >> De: netext-bounces@ietf.org de la part de Alper Yegin >> Date: jeu. 2009-07-30 08:02 >> =C0: netext@ietf.org >> Objet : [netext] PMIP6 and roaming >>=20 >>=20 >>=20 >>=20 >>=20 >> Continuing the discussion on the ML...... >>=20 >>=20 >>=20 >>=20 >>=20 >> Consider mobile1 and mobile2 subscribed to data service in USA. >>=20 >> They are in Sweden, accessing Internet by "roaming" to a Swedish >> operator network. >>=20 >>=20 >>=20 >> Does PMIP6 not support this case where MAG is in Swedish operator >> network, and LMA in USA operator's network? I think the answer is yes. >>=20 >> [Desire]: I think PMIP6 as defined in RFC5213 does not support this >> scenario as the MAG are not in the same PMIP domain. However, SDOs like >> 3GPP supports home tunnelling. >>=20 >>=20 >>=20 >> Wouldn't we want to optimize the path between mobile1 and mobile2 to >> save the traffic from making the unnecessary USA trip? I think the >> answer is yes again. >>=20 >> [Desire]: I agree that it is an interesting optimization. But we need >> first to clarify the relation between the MAG in sweden and the LMA in >> USA. So we need to specify PMIP6 roaming before talking about Localized >> routing in PMIP6 roaming. >>=20 >>=20 >>=20 >> Comments? >>=20 >>=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From vijay@wichorus.com Thu Jul 30 11:54:42 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373C43A682F for ; Thu, 30 Jul 2009 11:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+b-Z2Q2ImFd for ; Thu, 30 Jul 2009 11:54:41 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 744443A71FB for ; Thu, 30 Jul 2009 11:54:15 -0700 (PDT) Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jul 2009 18:54:17 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 30 Jul 2009 11:54:13 -0700 From: Vijay Devarapalli To: jouni korhonen , Message-ID: Thread-Topic: [netext] Clarifications regarding the runtime LMA assignment Thread-Index: AcoRRyEmgmDHgxxIkEqGED8/gJdRfg== In-Reply-To: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 18:54:42 -0000 Hi Jouni, On 7/30/09 9:45 AM, "jouni korhonen" wrote: > Hi all, > > To follow up and clarify the questions from Rajeev, here is something > that hopefully makes things clearer. The "proxied" case can be > represented as below. The assumption is that the rfLMA and the r2LMA > can exchange information between each other, and that the MAG has SAs > with both rfLMA and the r2LMA. We do not define how and what goes > between the rfLMA and the r2LMA. That is internal to the "LMA system", > whatever that "LMA system" constitutes of (that would imply a single > vendor within a "LMA system" but I guess it would reflect the reality > anyway). It is NOT ok to say that the rfLMA-r2LMA interactions are implementation specific, if the LMA assignment mechanism is going to be used between multiple physical LMAs in a cluster. Tying the cluster to one vendor, using an IETF specification, does not make sense. > We need to state in the draft, though, that a MAG can be sure > the r2LMA has a binding setup when it receives a PBA with both > redirection information and a successful result code. There is both > vendor and operator interest in this approach, so I consider it > important. > > MAG rfLMA r2LMA > | | | > |--PBU-->|- - - - | (redirection takes place, > |<--PBA--| - - - -| PBA contains rfLMA & r2LMA > | | | information) > | | | > |<=====data======>| > | | | > |-------PBU------>| (lifetime extension, > |<------PBA-------| de-registration, etc > | | | > > I don't mind nuking the "direct" solution in the draft. Actually I > would be happy to do that ;) If folks are fine with options, we could > add a variation of the "proxied" case, where another roundtrip of PBU/ > PBA is needed between a MAG and a r2LMA before data can flow. This > would, of course, be runtime negotiated. I would strongly be in favor of standardizing just one mechanism. No optional stuff, no variations, no runtime negotiation, please... Vijay > > > Cheers, > Jouni > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From vijay@wichorus.com Thu Jul 30 11:59:37 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BFD3A7203 for ; Thu, 30 Jul 2009 11:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l1ebBeY-VxA for ; Thu, 30 Jul 2009 11:59:36 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 9D8403A7208 for ; Thu, 30 Jul 2009 11:59:03 -0700 (PDT) Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jul 2009 18:59:05 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 30 Jul 2009 11:59:04 -0700 From: Vijay Devarapalli To: Xiangsong Cui , Message-ID: Thread-Topic: draft-cui-netext-lma-redirection-solution-00 Thread-Index: AcoRR86ZlBcVHbhYU0mtElJmMzsm7g== In-Reply-To: <004201ca0e8f$acc89860$40106f0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [netext] draft-cui-netext-lma-redirection-solution-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 18:59:37 -0000 Hi Xiangsong, As Jouni pointed, this mechanism was already there in version 00 of draft-korhonen-netext-redirect. The normal IETF practice is to send comments saying that you prefer the mechanism in the original draft compared to the new mechanism. You can suggest enhancements too. There might be some minor differences between what is in your draft and draft-korhonen-netext-redirect-00.txt, but writing yet another draft is not the right approach. Vijay On 7/27/09 12:55 AM, "Xiangsong Cui" wrote: > Hi all, > > I have just submitted a draft about the LMA Redirection solution. > You may find the draft by the link: > http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 > > Please take a look and any comment is welcomed. > > Thanks and regards > > Xiangsong > > ----- Original Message ----- > From: "IETF I-D Submission Tool" > To: > Sent: Monday, July 27, 2009 3:31 PM > Subject: New Version Notification for > draft-cui-netext-lma-redirection-solution-00 > > >> >> A new version of I-D, draft-cui-netext-lma-redirection-solution-00.txt has >> been successfuly submitted by Xiangsong Cui and posted to the IETF >> repository. >> >> Filename: draft-cui-netext-lma-redirection-solution >> Revision: 00 >> Title: LMA Redirection Solution >> Creation_date: 2009-07-27 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> In network-based mobility management domain, LMA is used to manage >> the mobility of IP node attached to MAG. LMA discovery and LMA >> redirection mechanism are used to improve the network flexibility. >> This document is used to introduce a recommended solution for this >> purpose. In this solution Redirect Agent function is adopted to >> accomplish the requirement. >> >> Conventions used in this document >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Thu Jul 30 13:09:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB813A6959 for ; Thu, 30 Jul 2009 13:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYbWlXoC6Sh0 for ; Thu, 30 Jul 2009 13:09:56 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 2B06E3A693C for ; Thu, 30 Jul 2009 13:09:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5E02FC9334 for ; Thu, 30 Jul 2009 16:09:54 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06782-06 for ; Thu, 30 Jul 2009 16:09:50 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 30 Jul 2009 16:09:50 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jul 2009 16:09:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 16:09:26 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Clarifications regarding the runtime LMA assignment Thread-Index: AcoRNS0gUUMn1h7KSmas77FhT2Zx9wAG6E6M References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 30 Jul 2009 20:09:26.0228 (UTC) FILETIME=[A33E6940:01CA1151] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:09:57 -0000 =20 Hi Jouni, =20 as I mentioned during the meeting, there are two separate issues here: = 1) runtime LMA selection, which is simply LMA-1 informing MAG to use = LMA-2, and 2) establishing BCE at LMA-2 at the same time that LMA-1 = informs MAG. =20 As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about LMA-2, = and MAG then contacts LMA-2 with PBU/PBA; only then BCE is set up at = LMA-2. =20 We can consider 2) as a special case which MAY be allowed under specific = conditions. But, we need to spell out those conditions clearly and = agree. In any case, 2) cannot be the general-purpose protocol.=20 =20 Regards, =20 -Rajeev =20 ________________________________ From: netext-bounces@ietf.org on behalf of jouni korhonen Sent: Thu 7/30/2009 9:45 AM To: netext@ietf.org Subject: [netext] Clarifications regarding the runtime LMA assignment Hi all, To follow up and clarify the questions from Rajeev, here is something=20 that hopefully makes things clearer. The "proxied" case can be=20 represented as below. The assumption is that the rfLMA and the r2LMA=20 can exchange information between each other, and that the MAG has SAs=20 with both rfLMA and the r2LMA. We do not define how and what goes=20 between the rfLMA and the r2LMA. That is internal to the "LMA system",=20 whatever that "LMA system" constitutes of (that would imply a single=20 vendor within a "LMA system" but I guess it would reflect the reality=20 anyway). We need to state in the draft, though, that a MAG can be sure=20 the r2LMA has a binding setup when it receives a PBA with both=20 redirection information and a successful result code. There is both=20 vendor and operator interest in this approach, so I consider it=20 important. MAG rfLMA r2LMA | | | |--PBU-->|- - - - | (redirection takes place, |<--PBA--| - - - -| PBA contains rfLMA & r2LMA | | | information) | | | |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| | | | |-------PBU------>| (lifetime extension, |<------PBA-------| de-registration, etc | | | I don't mind nuking the "direct" solution in the draft. Actually I=20 would be happy to do that ;) If folks are fine with options, we could=20 add a variation of the "proxied" case, where another roundtrip of PBU/ PBA is needed between a MAG and a r2LMA before data can flow. This=20 would, of course, be runtime negotiated. Cheers, Jouni _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Thu Jul 30 13:47:25 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A883A28C125 for ; Thu, 30 Jul 2009 13:47:25 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfi-HVUZCMYU for ; Thu, 30 Jul 2009 13:47:24 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 31ACC28C2D1 for ; Thu, 30 Jul 2009 13:47:23 -0700 (PDT) Received: by ewy10 with SMTP id 10so1074170ewy.37 for ; Thu, 30 Jul 2009 13:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=6uX+jDp+vdPs56G1Hkj7u0XL8boCK0+kHwmoCZoyH2U=; b=Q1JKVxRXdIh3Z+uVYqvnCj8jFVX1TMQ5lebrB9IpYmNyw1lXZZreh6dxVhWsSiMV/O uiDkXp9Bgs9oyCzIMTFpAZ5o8iAo1uV4XU+eyVcue7zNdjve/QHgPDndkiz+1SWuJZ7R CNobnZkQ1XcB38t5iLtxXUuc7nXc/WB0omUhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=xg3A0Gqeo8UWr/sOQCOiSEQma4u5YtT5pXZ/Js2IfYHn3Kb1rJf9W1ZTFfy02qctm6 +pfZulVsGVfMkZ3gZbsbdsFzV0+cC6QthpQTItC91dtCjpFs3Z6SrHJfZdK8QbIj2zh8 LyEjPrrRctrQg10PcfuJgYeaI0Ng3AeymKOhg= Received: by 10.210.61.8 with SMTP id j8mr1999449eba.75.1248986841378; Thu, 30 Jul 2009 13:47:21 -0700 (PDT) Received: from ?10.102.80.52? ([77.241.100.67]) by mx.google.com with ESMTPS id 10sm1755247eyd.32.2009.07.30.13.47.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 13:47:21 -0700 (PDT) Message-Id: From: jouni korhonen To: "Koodli, Rajeev" In-Reply-To: <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 23:47:17 +0300 References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 20:47:25 -0000 Hi Rajeev, On Jul 30, 2009, at 11:09 PM, Koodli, Rajeev wrote: > > Hi Jouni, > > as I mentioned during the meeting, there are two separate issues > here: 1) runtime LMA selection, which is simply LMA-1 informing MAG > to use LMA-2, and 2) establishing BCE at LMA-2 at the same time that > LMA-1 informs MAG. > > As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about > LMA-2, and MAG then contacts LMA-2 with PBU/PBA; only then BCE is > set up at LMA-2. Ok. Fine. The case 1) where LMA1 informs MAG about LMA2, is what we all agree on. > > We can consider 2) as a special case which MAY be allowed under > specific conditions. But, we need to spell out those conditions > clearly and agree. In any case, 2) cannot be the general-purpose > protocol. For the case 2) would you be OK if we, for example: o Add a flag in the response mobility option, which indicates whether there is already a BCE setup in LMA2. o Describe the conditions required for the above to be possible. Cheers, Jouni > > Regards, > > -Rajeev > > > ________________________________ > > From: netext-bounces@ietf.org on behalf of jouni korhonen > Sent: Thu 7/30/2009 9:45 AM > To: netext@ietf.org > Subject: [netext] Clarifications regarding the runtime LMA assignment > > > > Hi all, > > To follow up and clarify the questions from Rajeev, here is something > that hopefully makes things clearer. The "proxied" case can be > represented as below. The assumption is that the rfLMA and the r2LMA > can exchange information between each other, and that the MAG has SAs > with both rfLMA and the r2LMA. We do not define how and what goes > between the rfLMA and the r2LMA. That is internal to the "LMA system", > whatever that "LMA system" constitutes of (that would imply a single > vendor within a "LMA system" but I guess it would reflect the reality > anyway). We need to state in the draft, though, that a MAG can be sure > the r2LMA has a binding setup when it receives a PBA with both > redirection information and a successful result code. There is both > vendor and operator interest in this approach, so I consider it > important. > > MAG rfLMA r2LMA > | | | > |--PBU-->|- - - - | (redirection takes place, > |<--PBA--| - - - -| PBA contains rfLMA & r2LMA > | | | information) > | | | > |<=====data======>| > | | | > |-------PBU------>| (lifetime extension, > |<------PBA-------| de-registration, etc > | | | > > I don't mind nuking the "direct" solution in the draft. Actually I > would be happy to do that ;) If folks are fine with options, we could > add a variation of the "proxied" case, where another roundtrip of PBU/ > PBA is needed between a MAG and a r2LMA before data can flow. This > would, of course, be runtime negotiated. > > > Cheers, > Jouni > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Thu Jul 30 19:12:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC963A6C7A for ; Thu, 30 Jul 2009 19:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUMkdcaOuuEv for ; Thu, 30 Jul 2009 19:12:43 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 86E433A6C6A for ; Thu, 30 Jul 2009 19:12:38 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM00AO1JGRY6@szxga01-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 10:12:27 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNM00JQOJGQRZ@szxga01-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 10:12:27 +0800 (CST) Date: Fri, 31 Jul 2009 10:12:24 +0800 From: Xiangsong Cui To: Vijay Devarapalli , netext@ietf.org Message-id: <004301ca1184$582b7a00$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] draft-cui-netext-lma-redirection-solution-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 02:12:44 -0000 Hi Vijay, Thank you for your response, and I think we should do more discussion on the issue. > As Jouni pointed, this mechanism was already there in version 00 of > draft-korhonen-netext-redirect. I have to say I can't agree that. Because I didn't read the early version (i.e. draft-00) in the past, I check the document just now. In my understanding, the version 00 is similar with version 02, but different with my draft. The key points are: who send the first PBA to MAG? When the old LMA decide to do redirection, whom does the old LMA send message to? In my draft, it is the old LMA sends PBA to MAG, indicating the redirection procedure and the new LMA information. When the old LMA decide to do redirection, it sends message to the MAG, but not the new LMA. In the drafts of Jouni, it is the new LMA sends PBA, it is the new LMA sends the option to MAG, indicating the redirection procedure and with the old LMA information attached. I get this conclusion, because of the following text (copied from draft 00): Section 3: " The Redirect mobility option in the PBA MUST contain the IPv6 address (unicast or anycast) of the rfLMA and MAY contain the IPv4 address of the rfLMA. The PBA containing the Redirect mobility option MUST be sent from the r2LMA. After receiving the PBA containing the Redirect mobility option from the r2LMA, the MAG MUST send subsequent PBUs and user traffic to the r2LMA that concern the redirected mobility session." The draft says the PBA MUST be sent from the r2LMA, which is the new one. Section 5.1: " If the MAG receives a PBA that contains the Redirect mobility option from a LMA without first including the Redirect mobility option in the corresponding PBU, the MAG MUST treat the PBA as if the binding update failed and log the event. If the MAG receives a PBA that contains the Redirect mobility option and the MAG had included the Redirect mobility option in the corresponding PBU, then the MAG MUST perform the following steps in addition to the normal RFC 5213 PBA processing: o Check if the Redirect mobility option contains the IP address of the LMA to whom the MAG originally sent the PBU (i.e. the rfLMA). If the check fails, then the MAG MUST treat the PBA as if the binding update failed and log the event. o Update the Binding Update List to correspond to the LMA Address where the newly received PBA came from." Notice the last sentence, I believe the LMA is the new LMA, so the MAG need update the binding update list, isn't it? Section 5.2: " In the case of redirection, the r2LMA MUST always include the IPv6 address (unicast or anycast) of the rfLMA in the Redirect mobility option in the PBA." The draft says r2LMA MUST include the information of the old LMA, while in my draft, it is the old LMA indicates the new LMA. Vijay, would you like to read the draft-00 of Jouni and check my conclusion? > The normal IETF practice is to send comments > saying that you prefer the mechanism in the original draft compared to the > new mechanism. You can suggest enhancements too. I agree the mechanism in my draft is widely used in other protocols, but I don't think it is introduced in the drafts of Jouni. > There might be some minor > differences between what is in your draft and > draft-korhonen-netext-redirect-00.txt, but writing yet another draft is > not > the right approach. > Because my draft is different from the drafts of Jouni, I think I can submit it to the WG. We just discussed several drafts on the topic of RO, IMO, two drafts on the Redirection is reasonable. Regards Xiangsong ----- Original Message ----- From: "Vijay Devarapalli" To: "Xiangsong Cui" ; Sent: Friday, July 31, 2009 2:59 AM Subject: [netext] draft-cui-netext-lma-redirection-solution-00 > Hi Xiangsong, > > As Jouni pointed, this mechanism was already there in version 00 of > draft-korhonen-netext-redirect. The normal IETF practice is to send > comments > saying that you prefer the mechanism in the original draft compared to the > new mechanism. You can suggest enhancements too. There might be some minor > differences between what is in your draft and > draft-korhonen-netext-redirect-00.txt, but writing yet another draft is > not > the right approach. > > Vijay > > > On 7/27/09 12:55 AM, "Xiangsong Cui" wrote: > >> Hi all, >> >> I have just submitted a draft about the LMA Redirection solution. >> You may find the draft by the link: >> http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 >> >> Please take a look and any comment is welcomed. >> >> Thanks and regards >> >> Xiangsong >> >> ----- Original Message ----- >> From: "IETF I-D Submission Tool" >> To: >> Sent: Monday, July 27, 2009 3:31 PM >> Subject: New Version Notification for >> draft-cui-netext-lma-redirection-solution-00 >> >> >>> >>> A new version of I-D, draft-cui-netext-lma-redirection-solution-00.txt >>> has >>> been successfuly submitted by Xiangsong Cui and posted to the IETF >>> repository. >>> >>> Filename: draft-cui-netext-lma-redirection-solution >>> Revision: 00 >>> Title: LMA Redirection Solution >>> Creation_date: 2009-07-27 >>> WG ID: Independent Submission >>> Number_of_pages: 8 >>> >>> Abstract: >>> In network-based mobility management domain, LMA is used to manage >>> the mobility of IP node attached to MAG. LMA discovery and LMA >>> redirection mechanism are used to improve the network flexibility. >>> This document is used to introduce a recommended solution for this >>> purpose. In this solution Redirect Agent function is adopted to >>> accomplish the requirement. >>> >>> Conventions used in this document >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in [RFC2119]. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Thu Jul 30 20:20:58 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5B83A69EB for ; Thu, 30 Jul 2009 20:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed6pISQquOIn for ; Thu, 30 Jul 2009 20:20:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 382463A6809 for ; Thu, 30 Jul 2009 20:20:57 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM0080YMMXHI@szxga04-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 11:20:57 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNM008YMMMXST@szxga04-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 11:20:57 +0800 (CST) Date: Fri, 31 Jul 2009 11:20:56 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <00c101ca118d$eb2ee360$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [netext] Request for adopting draft-cui-netext-lma-redirection-solution-00 as a WG baseline X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 03:20:58 -0000 Hi Raj, After the discussion, I think the WG have got a consensus on the principle. As Koodli mentioned in the message: http://www.ietf.org/mail-archive/web/netext/current/msg00745.html, "As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about LMA-2, and MAG then contacts LMA-2 with PBU/PBA; only then BCE is set up at LMA-2." Basing on this principle, I believe the draft http://tools.ietf.org/id/draft-cui-netext-lma-redirection-solution-00.txt is more conformable than the draft http://tools.ietf.org/id/draft-korhonen-netext-redirect-02.txt. (I attach a message in the end to explain that the drafts are different.) So I would like to ask WG to accept my draft http://tools.ietf.org/id/draft-cui-netext-lma-redirection-solution-00.txt as the baseline of LMA Redirection. Regards Xiangsong ----- Original Message ----- From: "Xiangsong Cui" To: "Vijay Devarapalli" ; Sent: Friday, July 31, 2009 10:12 AM Subject: Re: [netext] draft-cui-netext-lma-redirection-solution-00 > Hi Vijay, > > Thank you for your response, and I think we should do more > discussion on the issue. > >> As Jouni pointed, this mechanism was already there in version 00 of >> draft-korhonen-netext-redirect. > > I have to say I can't agree that. > Because I didn't read the early version (i.e. draft-00) in the past, > I check the document just now. > > In my understanding, the version 00 is similar with version 02, but > different with my draft. > > The key points are: who send the first PBA to MAG? > When the old LMA decide to do redirection, whom does the > old LMA send message to? > > In my draft, it is the old LMA sends PBA to MAG, indicating > the redirection procedure and the new LMA information. > When the old LMA decide to do redirection, it sends message > to the MAG, but not the new LMA. > > In the drafts of Jouni, it is the new LMA sends PBA, it is the new LMA > sends the option to MAG, indicating the redirection procedure and with > the old LMA information attached. > I get this conclusion, because of the following text (copied from draft > 00): > > Section 3: > " The Redirect mobility option in the PBA MUST contain the > IPv6 address (unicast or anycast) of the rfLMA and MAY contain the > IPv4 address of the rfLMA. The PBA containing the Redirect mobility > option MUST be sent from the r2LMA. After receiving the PBA > containing the Redirect mobility option from the r2LMA, the MAG MUST > send subsequent PBUs and user traffic to the r2LMA that concern the > redirected mobility session." > > The draft says the PBA MUST be sent from the r2LMA, which is the new > one. > > Section 5.1: > " If the MAG receives a PBA that contains the Redirect mobility option > from a LMA without first including the Redirect mobility option in > the corresponding PBU, the MAG MUST treat the PBA as if the binding > update failed and log the event. If the MAG receives a PBA that > contains the Redirect mobility option and the MAG had included the > Redirect mobility option in the corresponding PBU, then the MAG MUST > perform the following steps in addition to the normal RFC 5213 PBA > processing: > > o Check if the Redirect mobility option contains the IP address of > the LMA to whom the MAG originally sent the PBU (i.e. the rfLMA). > If the check fails, then the MAG MUST treat the PBA as if the > binding update failed and log the event. > > o Update the Binding Update List to correspond to the LMA Address > where the newly received PBA came from." > > Notice the last sentence, I believe the LMA is the new LMA, so the MAG > need update the binding update list, isn't it? > > Section 5.2: > " In > the case of redirection, the r2LMA MUST always include the IPv6 > address (unicast or anycast) of the rfLMA in the Redirect mobility > option in the PBA." > > The draft says r2LMA MUST include the information of the old LMA, > while in my draft, it is the old LMA indicates the new LMA. > > Vijay, would you like to read the draft-00 of Jouni and check my > conclusion? > > >> The normal IETF practice is to send comments >> saying that you prefer the mechanism in the original draft compared to >> the >> new mechanism. You can suggest enhancements too. > > I agree the mechanism in my draft is widely used in other protocols, but > I don't think it is introduced in the drafts of Jouni. > > >> There might be some minor >> differences between what is in your draft and >> draft-korhonen-netext-redirect-00.txt, but writing yet another draft is >> not >> the right approach. >> > > Because my draft is different from the drafts of Jouni, I think I can > submit > it to the WG. We just discussed several drafts on the topic of RO, IMO, > two drafts on the Redirection is reasonable. > > > Regards > > Xiangsong > > > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Xiangsong Cui" ; > Sent: Friday, July 31, 2009 2:59 AM > Subject: [netext] draft-cui-netext-lma-redirection-solution-00 > > >> Hi Xiangsong, >> >> As Jouni pointed, this mechanism was already there in version 00 of >> draft-korhonen-netext-redirect. The normal IETF practice is to send >> comments >> saying that you prefer the mechanism in the original draft compared to >> the >> new mechanism. You can suggest enhancements too. There might be some >> minor >> differences between what is in your draft and >> draft-korhonen-netext-redirect-00.txt, but writing yet another draft is >> not >> the right approach. >> >> Vijay >> >> >> On 7/27/09 12:55 AM, "Xiangsong Cui" wrote: >> >>> Hi all, >>> >>> I have just submitted a draft about the LMA Redirection solution. >>> You may find the draft by the link: >>> http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 >>> >>> Please take a look and any comment is welcomed. >>> >>> Thanks and regards >>> >>> Xiangsong >>> >>> ----- Original Message ----- >>> From: "IETF I-D Submission Tool" >>> To: >>> Sent: Monday, July 27, 2009 3:31 PM >>> Subject: New Version Notification for >>> draft-cui-netext-lma-redirection-solution-00 >>> >>> >>>> >>>> A new version of I-D, draft-cui-netext-lma-redirection-solution-00.txt >>>> has >>>> been successfuly submitted by Xiangsong Cui and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-cui-netext-lma-redirection-solution >>>> Revision: 00 >>>> Title: LMA Redirection Solution >>>> Creation_date: 2009-07-27 >>>> WG ID: Independent Submission >>>> Number_of_pages: 8 >>>> >>>> Abstract: >>>> In network-based mobility management domain, LMA is used to manage >>>> the mobility of IP node attached to MAG. LMA discovery and LMA >>>> redirection mechanism are used to improve the network flexibility. >>>> This document is used to introduce a recommended solution for this >>>> purpose. In this solution Redirect Agent function is adopted to >>>> accomplish the requirement. >>>> >>>> Conventions used in this document >>>> >>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>>> document are to be interpreted as described in [RFC2119]. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Thu Jul 30 21:13:12 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374183A6AB9 for ; Thu, 30 Jul 2009 21:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4SlvedGsFAk for ; Thu, 30 Jul 2009 21:13:11 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BB2E13A6A04 for ; Thu, 30 Jul 2009 21:13:10 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM008GVOYRHE@szxga04-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 12:11:15 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNM009FKOYQ58@szxga04-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 12:11:15 +0800 (CST) Date: Fri, 31 Jul 2009 12:11:14 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 04:13:12 -0000 Hi Jouni, Thank you for your response. > There are few reasons. First, which GRE key to use? Uplink or downlink? I think Uplink and downlink may be used to identify the connection for different direction. MAG and LMA know well both uplink and downlink after the registration. > Obviously, the MAG does not know the uplink GRE key when sending a PBU > during the initial attach or after a handover.. so you would lack the > "identifier" in the MAG in some situations. I don't know in which situation the identifier would be lacking. If you refer to handover, I think the GRE Key may also be a part of the context, as connection-id does. > If we were to use the downlink key, according to the GRE key draft it is > not guaranteed that the downlink remains the same between inter-MAG > handover. The same problem with connection-id, if you use connection-id, can you guarantee that the connection-id is always same? Inter-MAG handover is the common issue for all identifiers. > > Second, the use of GRE keys and GRE tunneling is optional in PMIP6. Well, > so is Service Selection too but I would avoid building additional > dependencies between different documents if just possible. Yes, GRE Key is an optional option. I think an optional option is used for a optional feature is reasonable > > Third, overloading the function of the GRE key option does not sound a > good idea in general, even if it were possible. If it works well, why not take it as the solution? I see many messages recently on the issue of expansion to protocol. For example (Suresh and Vijay, I supposed you permit me to cite your words), http://www.ietf.org/proceedings/75/slides/mext-0.ppt, slide 7, Suresh says: "There have been several extensions to CMIPv6; . But, there is no cohesive mobility architecture that holds these extensions together; . This causes a lot of confusion and incompatible implementations" http://www.ietf.org/mail-archive/web/netext/current/msg00729.html, Vijay says: "One option would be to re-use the HA Switch Message from RFC 5142 and carry the redirect mobility option in this message. This would avoid defining a new message." http://www.ietf.org/mail-archive/web/netext/current/msg00739.html, Vijay also says: It would be a bad idea to have two different sets of mechanisms. I'm also in the position, if we can re-use some mechanisms, we need NO expansion, so the protocols may be more simple. Regards Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Thursday, July 30, 2009 11:49 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > Hi Xiangsong, > > On Jul 30, 2009, at 12:58 PM, Xiangsong Cui wrote: > >> Hello Raj and Jouni, >> >> I have a question about the draft. >> >> Firstly, I agree the requirement of multiple PDN connections >> to the same APN. >> >> IMO, the major idea of this draft is as mentioned in the draft: >> >> The combination of MN-Identifier + Service Selection + >> Connection Identifier can uniquely identify mobility sessions even if >> the selected service on each mobility session for the same MN- >> Identifier are the same. >> >> It recall me to another draft, "draft-ietf-netlmm-grekey- option-09.txt". >> In the GREKEY draft, it says: >> This specification defines the GRE Key option to be used for the >> negotiation of GRE encapsulation mode and exchange of the uplink and >> downlink GRE keys. The negotiated downlink and uplink GRE keys can >> be used for marking the downlink and uplink traffic for a specific >> mobility session. >> >> The connid draft is used to identify a certain session among >> multiple sessions, while the grekey draft is used to identify a >> certain link/flow in the tunnel between the MAG and the LMA. >> >> When I look at figure 1 in the grekey draft, it seems similar for the >> both cases, because we just need to identify a connection, and the >> connection may be a session or a flow. >> >> So I have the question: >> if we expand the meaning of GRE Key option, without protocol expansion, >> can we use the combination "MN-Identifier + Service Selection + GRE key" >> to identify the connections to the same APN? > > There are few reasons. First, which GRE key to use? Uplink or downlink? > Obviously, the MAG does not know the uplink GRE key when sending a PBU > during the initial attach or after a handover.. so you would lack the > "identifier" in the MAG in some situations. If we were to use the > downlink key, according to the GRE key draft it is not guaranteed that > the downlink remains the same between inter-MAG handover. > > Second, the use of GRE keys and GRE tunneling is optional in PMIP6. Well, > so is Service Selection too but I would avoid building additional > dependencies between different documents if just possible. > > Third, overloading the function of the GRE key option does not sound a > good idea in general, even if it were possible. > > Cheers, > Jouni > > > > > >> >> Regards >> >> Xiangsong >> >> ----- Original Message ----- From: >> To: >> Sent: Thursday, July 16, 2009 5:33 AM >> Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6- connid-00 >> >> >>> >>> >>> Hello, >>> >>> A few questions/comments related to the proposal to add a connection >>> identifier to the PMIP6 signaling and BCE: >>> >>> 1. Each of the PDN bearers will have a unique prefix assigned to it by >>> the LMA, right? Even though the MN-ID remains the same the LMA will >>> have to create multiple BCEs for the MN. The scenario is equivalent >>> to the MN attaching via different interfaces thru the same MAG/LMA >>> pair. >>> >>> 2. The I-D says that the mechanism by which the MAG figures out that >>> a new bi-directional tunnel is needed to be established (and a new >>> prefix obtained) is out of scope. In certain networks you are >>> obtaining this information from L2 and is used by the MAG. Current >>> RFC5213 lacks the ability by which an MN (which is already attached >>> via an interface) can request dynamically a new prefix to be >>> assigned to it for the same interface. The connection ID would be >>> useful if we were to also specify how the MN can request an >>> additional prefix via an interface that is already attached and has >>> been assigned a prefix from a MAG/LMA pair. >>> It might be useful to explain how L2s can provide such indications in >>> an >>> appendix. >>> >>> 3. In the case of HO the target MAG will not be aware of the CID >>> unless there a context transfer mechanism between the MAGs. Please >>> note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes >>> context transfer capability between MAGs. >>> >>> 4. If each PDN bearer is assigned a unique prefix, can you not use the >>> HNP assigned as the CID? >>> >>> I do agree with the need to support the ability by which multiple >>> mobility sessions to the same LMA (via the same MAG) from a single >>> interface is needed. This is applicable in EPC and other networks >>> which use PMIP6. >>> >>> -Raj >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Fri Jul 31 02:16:25 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9D23A6805 for ; Fri, 31 Jul 2009 02:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eje2Jc9156sa for ; Fri, 31 Jul 2009 02:16:24 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id DE8293A6DD0 for ; Fri, 31 Jul 2009 02:16:23 -0700 (PDT) Received: by bwz19 with SMTP id 19so1077877bwz.37 for ; Fri, 31 Jul 2009 02:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=R/pIC+j/RlC0A16XsqlLwLKnEZ990xKPuVL9+XzXtXc=; b=W5v7Dq/ApLLP/HUKG21tv+9bcZyG91biwLM++lznXDJzPYfIw0O5hAnsFv4OzFJS/Z rcjoYGmnMAGNfWt4UQKv5MIAfZzwMmyl//9mM5laD2S2XjQq1kDn6uQT4M9AmTcOrnV+ CGufKI1BxY0Bt19IaKHEfWNCLCv9KUtuXIf34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=las1ihhIBohGC3yQPv8zceAlepSZjngGqoSEhK5CNZGJ1TrOi/Iev5E8b4GIqXPrla RGgnRZ/1WCybsUr8kZ33wdmp9D6mH5eJmjMi1Ca5jGPyCyjdZAMWmN+eNoLNKFI6FxmE ozXNLtNYMNsjEbpU4rfeC53J1VKopkLgeTtBU= Received: by 10.103.212.2 with SMTP id o2mr1348169muq.18.1249031783027; Fri, 31 Jul 2009 02:16:23 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org ([130.129.84.246]) by mx.google.com with ESMTPS id e9sm19583781muf.32.2009.07.31.02.16.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 02:16:22 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> X-Priority: 3 References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> Message-Id: <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 12:16:20 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:16:25 -0000 Hi, On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: > Hi Jouni, > > Thank you for your response. > >> There are few reasons. First, which GRE key to use? Uplink or >> downlink? > I think Uplink and downlink may be used to identify the connection Uh.. so you would use combination of both keys simultaneously? > for different direction. MAG and LMA know well both uplink and > downlink after the registration. > >> Obviously, the MAG does not know the uplink GRE key when sending a >> PBU during the initial attach or after a handover.. so you would >> lack the "identifier" in the MAG in some situations. > I don't know in which situation the identifier would be lacking. > If you refer to handover, I think the GRE Key may also be a part > of the context, as connection-id does. Few things. Now you are making context transfer between MAGs mandatory as otherwise there is no guarantee GRE keys are present. I do not want to mandate context transfer. It can be used, if available, but mandating it is not good. There are also cases (specific to certain architectures and deployments), where a MN is first using access mechanism that does not use GRE but still supports the Service Selection/APNs. Now when you do a handover from such to PMIP6, the MAG just don't have GRE key information as they do not exist yet. The common anchor (LMA/HA) already has the bindings for multiple services with the same name. It is safer to rely on something else than GRE keys. > >> If we were to use the downlink key, according to the GRE key draft >> it is not guaranteed that the downlink remains the same between >> inter-MAG handover. > The same problem with connection-id, if you use connection-id, can > you guarantee that the connection-id is always same? > Inter-MAG handover is the common issue for all identifiers. The draft says the connection identifier potentially comes from lower layers or other mechanisms than context transfer. If I can really assume context transfer is always in place, then I would be just find with using HNP/IP4-HoA + MN-ID + Service Selection. As said before, currently I cannot rely on either HNP/IP4-HoA or GRE information to be available at the MAG when the MN first camps there. > >> >> Second, the use of GRE keys and GRE tunneling is optional in >> PMIP6. Well, so is Service Selection too but I would avoid >> building additional dependencies between different documents if >> just possible. > Yes, GRE Key is an optional option. I think an optional option is used > for a optional feature is reasonable The less the better. I.e. if I can choose between two optional features versus three optional features, I would go for two. > >> >> Third, overloading the function of the GRE key option does not >> sound a good idea in general, even if it were possible. > If it works well, why not take it as the solution? Overloading existing semantics is always a bad practice. I'll skip the rest as I don't see how they relate to this discussion. Cheers, Jouni > > I see many messages recently on the issue of expansion to protocol. > > For example (Suresh and Vijay, I supposed you permit me to cite your > words), > > http://www.ietf.org/proceedings/75/slides/mext-0.ppt, slide 7, > Suresh says: > "There have been several extensions to CMIPv6; > . > But, there is no cohesive mobility architecture that holds these > extensions together; > . > This causes a lot of confusion and incompatible implementations" > > http://www.ietf.org/mail-archive/web/netext/current/msg00729.html, > Vijay says: > "One option would be to re-use the HA > Switch Message from RFC 5142 and carry the redirect mobility option > in this > message. This would avoid defining a new message." > > http://www.ietf.org/mail-archive/web/netext/current/msg00739.html, > Vijay also says: > It would be a bad idea to have two different sets of > mechanisms. > > I'm also in the position, if we can re-use some mechanisms, > we need NO expansion, so the protocols may be more simple. > > Regards > > Xiangsong > > [snip] From rkoodli@starentnetworks.com Fri Jul 31 02:49:27 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF9E3A6D31 for ; Fri, 31 Jul 2009 02:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFLh8DH+IJUF for ; Fri, 31 Jul 2009 02:49:26 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id AC3D428C288 for ; Fri, 31 Jul 2009 02:48:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5AC79CA7EB for ; Fri, 31 Jul 2009 05:48:41 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26717-11 for ; Fri, 31 Jul 2009 05:48:36 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 31 Jul 2009 05:48:36 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 05:48:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 05:48:11 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382A44@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Request for adopting draft-cui-netext-lma-redirection-solution-00 as a WG baseline Thread-Index: AcoRjeTdh1ZjnR0LQP2cS86vya1a2AAMdFGC References: <00c101ca118d$eb2ee360$40106f0a@china.huawei.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 31 Jul 2009 09:48:11.0588 (UTC) FILETIME=[043D7840:01CA11C4] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] Request for adopting draft-cui-netext-lma-redirection-solution-00 as a WG baseline X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:49:27 -0000 =20 Hi Xiangsong, it is the common practice to discuss a draft and make revisions; that's = how we work in IETF WGs. My comments are inline with that and not meant = to compare one draft against another.=20 Please provide your comments on the topic. Your input will be discussed = just as any other input and taken into consideration in making progress = on the topic.=20 Thanks, -Rajeev =20 ________________________________ From: netext-bounces@ietf.org on behalf of Xiangsong Cui Sent: Thu 7/30/2009 8:20 PM To: Basavaraj.Patil@nokia.com; netext@ietf.org Subject: [netext] Request for adopting = draft-cui-netext-lma-redirection-solution-00 as a WG baseline Hi Raj, After the discussion, I think the WG have got a consensus on the principle. As Koodli mentioned in the message: http://www.ietf.org/mail-archive/web/netext/current/msg00745.html, "As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about LMA-2, and MAG then contacts LMA-2 with PBU/PBA; only then BCE is set up at LMA-2." Basing on this principle, I believe the draft http://tools.ietf.org/id/draft-cui-netext-lma-redirection-solution-00.txt= is more conformable than the draft http://tools.ietf.org/id/draft-korhonen-netext-redirect-02.txt. (I attach a message in the end to explain that the drafts are = different.) So I would like to ask WG to accept my draft http://tools.ietf.org/id/draft-cui-netext-lma-redirection-solution-00.txt= as the baseline of LMA Redirection. Regards Xiangsong ----- Original Message ----- From: "Xiangsong Cui" To: "Vijay Devarapalli" ; Sent: Friday, July 31, 2009 10:12 AM Subject: Re: [netext] draft-cui-netext-lma-redirection-solution-00 > Hi Vijay, > > Thank you for your response, and I think we should do more > discussion on the issue. > >> As Jouni pointed, this mechanism was already there in version 00 of >> draft-korhonen-netext-redirect. > > I have to say I can't agree that. > Because I didn't read the early version (i.e. draft-00) in the past, > I check the document just now. > > In my understanding, the version 00 is similar with version 02, but > different with my draft. > > The key points are: who send the first PBA to MAG? > When the old LMA decide to do redirection, whom does the > old LMA send message to? > > In my draft, it is the old LMA sends PBA to MAG, indicating > the redirection procedure and the new LMA information. > When the old LMA decide to do redirection, it sends message > to the MAG, but not the new LMA. > > In the drafts of Jouni, it is the new LMA sends PBA, it is the new LMA > sends the option to MAG, indicating the redirection procedure and with > the old LMA information attached. > I get this conclusion, because of the following text (copied from = draft > 00): > > Section 3: > " The Redirect mobility option in the PBA MUST contain the > IPv6 address (unicast or anycast) of the rfLMA and MAY contain the > IPv4 address of the rfLMA. The PBA containing the Redirect mobility > option MUST be sent from the r2LMA. After receiving the PBA > containing the Redirect mobility option from the r2LMA, the MAG MUST > send subsequent PBUs and user traffic to the r2LMA that concern the > redirected mobility session." > > The draft says the PBA MUST be sent from the r2LMA, which is the new > one. > > Section 5.1: > " If the MAG receives a PBA that contains the Redirect mobility option > from a LMA without first including the Redirect mobility option in > the corresponding PBU, the MAG MUST treat the PBA as if the binding > update failed and log the event. If the MAG receives a PBA that > contains the Redirect mobility option and the MAG had included the > Redirect mobility option in the corresponding PBU, then the MAG MUST > perform the following steps in addition to the normal RFC 5213 PBA > processing: > > o Check if the Redirect mobility option contains the IP address of > the LMA to whom the MAG originally sent the PBU (i.e. the rfLMA). > If the check fails, then the MAG MUST treat the PBA as if the > binding update failed and log the event. > > o Update the Binding Update List to correspond to the LMA Address > where the newly received PBA came from." > > Notice the last sentence, I believe the LMA is the new LMA, so the MAG > need update the binding update list, isn't it? > > Section 5.2: > " In > the case of redirection, the r2LMA MUST always include the IPv6 > address (unicast or anycast) of the rfLMA in the Redirect mobility > option in the PBA." > > The draft says r2LMA MUST include the information of the old LMA, > while in my draft, it is the old LMA indicates the new LMA. > > Vijay, would you like to read the draft-00 of Jouni and check my > conclusion? > > >> The normal IETF practice is to send comments >> saying that you prefer the mechanism in the original draft compared = to >> the >> new mechanism. You can suggest enhancements too. > > I agree the mechanism in my draft is widely used in other protocols, = but > I don't think it is introduced in the drafts of Jouni. > > >> There might be some minor >> differences between what is in your draft and >> draft-korhonen-netext-redirect-00.txt, but writing yet another draft = is >> not >> the right approach. >> > > Because my draft is different from the drafts of Jouni, I think I can > submit > it to the WG. We just discussed several drafts on the topic of RO, = IMO, > two drafts on the Redirection is reasonable. > > > Regards > > Xiangsong > > > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Xiangsong Cui" ; > Sent: Friday, July 31, 2009 2:59 AM > Subject: [netext] draft-cui-netext-lma-redirection-solution-00 > > >> Hi Xiangsong, >> >> As Jouni pointed, this mechanism was already there in version 00 of >> draft-korhonen-netext-redirect. The normal IETF practice is to send >> comments >> saying that you prefer the mechanism in the original draft compared = to >> the >> new mechanism. You can suggest enhancements too. There might be some >> minor >> differences between what is in your draft and >> draft-korhonen-netext-redirect-00.txt, but writing yet another draft = is >> not >> the right approach. >> >> Vijay >> >> >> On 7/27/09 12:55 AM, "Xiangsong Cui" wrote: >> >>> Hi all, >>> >>> I have just submitted a draft about the LMA Redirection solution. >>> You may find the draft by the link: >>> = http://tools.ietf.org/html/draft-cui-netext-lma-redirection-solution-00 >>> >>> Please take a look and any comment is welcomed. >>> >>> Thanks and regards >>> >>> Xiangsong >>> >>> ----- Original Message ----- >>> From: "IETF I-D Submission Tool" >>> To: >>> Sent: Monday, July 27, 2009 3:31 PM >>> Subject: New Version Notification for >>> draft-cui-netext-lma-redirection-solution-00 >>> >>> >>>> >>>> A new version of I-D, = draft-cui-netext-lma-redirection-solution-00.txt >>>> has >>>> been successfuly submitted by Xiangsong Cui and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-cui-netext-lma-redirection-solution >>>> Revision: 00 >>>> Title: LMA Redirection Solution >>>> Creation_date: 2009-07-27 >>>> WG ID: Independent Submission >>>> Number_of_pages: 8 >>>> >>>> Abstract: >>>> In network-based mobility management domain, LMA is used to manage >>>> the mobility of IP node attached to MAG. LMA discovery and LMA >>>> redirection mechanism are used to improve the network flexibility. >>>> This document is used to introduce a recommended solution for this >>>> purpose. In this solution Redirect Agent function is adopted to >>>> accomplish the requirement. >>>> >>>> Conventions used in this document >>>> >>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this >>>> document are to be interpreted as described in [RFC2119]. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Fri Jul 31 02:54:36 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320F23A6CD8 for ; Fri, 31 Jul 2009 02:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsItnWr-xU5Z for ; Fri, 31 Jul 2009 02:54:35 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 458E83A6C9F for ; Fri, 31 Jul 2009 02:53:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2C6BBCA937 for ; Fri, 31 Jul 2009 05:53:36 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27597-04 for ; Fri, 31 Jul 2009 05:53:33 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 31 Jul 2009 05:53:33 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 05:53:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 05:49:27 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382A45@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Clarifications regarding the runtime LMA assignment Thread-Index: AcoRVueqebvXxJNLSkSsPbQQ/mQ2qQAbUm4Q References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 31 Jul 2009 09:53:08.0303 (UTC) FILETIME=[B51895F0:01CA11C4] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:54:36 -0000 =20 Hi, =20 > > We can consider 2) as a special case which MAY be allowed under=20 > specific conditions. But, we need to spell out those conditions=20 > clearly and agree. In any case, 2) cannot be the general-purpose=20 > protocol. For the case 2) would you be OK if we, for example: o Add a flag in the response mobility option, which indicates=20 whether there is already a BCE setup in LMA2. o Describe the conditions required for the above to be possible. Rajeev:> I would start with the second bullet. Once we agree on that, it = would be trivial to add a flag IMO. -Rajeev Cheers, Jouni > > Regards, > > -Rajeev > > > ________________________________ > > From: netext-bounces@ietf.org on behalf of jouni korhonen > Sent: Thu 7/30/2009 9:45 AM > To: netext@ietf.org > Subject: [netext] Clarifications regarding the runtime LMA assignment > > > > Hi all, > > To follow up and clarify the questions from Rajeev, here is something > that hopefully makes things clearer. The "proxied" case can be > represented as below. The assumption is that the rfLMA and the r2LMA > can exchange information between each other, and that the MAG has SAs > with both rfLMA and the r2LMA. We do not define how and what goes > between the rfLMA and the r2LMA. That is internal to the "LMA system", > whatever that "LMA system" constitutes of (that would imply a single > vendor within a "LMA system" but I guess it would reflect the reality > anyway). We need to state in the draft, though, that a MAG can be sure > the r2LMA has a binding setup when it receives a PBA with both > redirection information and a successful result code. There is both > vendor and operator interest in this approach, so I consider it > important. > > MAG rfLMA r2LMA > | | | > |--PBU-->|- - - - | (redirection takes place, > |<--PBA--| - - - -| PBA contains rfLMA & r2LMA > | | | information) > | | | > |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| > | | | > |-------PBU------>| (lifetime extension, > |<------PBA-------| de-registration, etc > | | | > > I don't mind nuking the "direct" solution in the draft. Actually I > would be happy to do that ;) If folks are fine with options, we could > add a variation of the "proxied" case, where another roundtrip of PBU/ > PBA is needed between a MAG and a r2LMA before data can flow. This > would, of course, be runtime negotiated. > > > Cheers, > Jouni > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Fri Jul 31 03:02:05 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E1B28C2E8 for ; Fri, 31 Jul 2009 03:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P566VsHFhhXt for ; Fri, 31 Jul 2009 03:02:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 177D03A6D1F for ; Fri, 31 Jul 2009 03:02:04 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN00EWP54WEI@szxga03-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 18:00:32 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNN00NH554V3C@szxga03-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 18:00:32 +0800 (CST) Date: Fri, 31 Jul 2009 18:00:31 +0800 From: Xiangsong Cui To: jouni korhonen Message-id: <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 10:02:05 -0000 Hi Jouni, Please see inline. Regards/Xiangsong ----- Original Message ----- From: "jouni korhonen" To: "Xiangsong Cui" Cc: ; Sent: Friday, July 31, 2009 5:16 PM Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 > Hi, > > > On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: > >> Hi Jouni, >> >> Thank you for your response. >> >>> There are few reasons. First, which GRE key to use? Uplink or >>> downlink? >> I think Uplink and downlink may be used to identify the connection > > Uh.. so you would use combination of both keys simultaneously? Yes, I think GRE Key is designed for this manner. > >> for different direction. MAG and LMA know well both uplink and >> downlink after the registration. >> >>> Obviously, the MAG does not know the uplink GRE key when sending a >>> PBU during the initial attach or after a handover.. so you would >>> lack the "identifier" in the MAG in some situations. >> I don't know in which situation the identifier would be lacking. >> If you refer to handover, I think the GRE Key may also be a part >> of the context, as connection-id does. > > Few things. Now you are making context transfer between MAGs mandatory > as otherwise there is no guarantee GRE keys are present. I do not want > to mandate context transfer. It can be used, if available, but > mandating it is not good. > > There are also cases (specific to certain architectures and > deployments), where a MN is first using access mechanism that does not > use GRE but still supports the Service Selection/APNs. Now when you do > a handover from such to PMIP6, the MAG just don't have GRE key > information as they do not exist yet. The common anchor (LMA/HA) > already has the bindings for multiple services with the same name. It > is safer to rely on something else than GRE keys. In your draft, section 5.3, it says " How the MAG knows/learns the connection identifiers after a handover between MAGs is out of scope of this specification. However, mechanisms such as context transfer between MAGs may be used. ** Editor's note: these assumptions are subject to changes ** " I don't know which mechanism do you use to keep the connection-id during the handover procedure. > >> >>> If we were to use the downlink key, according to the GRE key draft >>> it is not guaranteed that the downlink remains the same between >>> inter-MAG handover. >> The same problem with connection-id, if you use connection-id, can >> you guarantee that the connection-id is always same? >> Inter-MAG handover is the common issue for all identifiers. > > The draft says the connection identifier potentially comes from lower > layers or other mechanisms than context transfer. If I can really > assume context transfer is always in place, then I would be just find > with using HNP/IP4-HoA + MN-ID + Service Selection. As said before, > currently I cannot rely on either HNP/IP4-HoA or GRE information to be > available at the MAG when the MN first camps there. > You do mention the "lower layers" in section 1, but it is for connection-id creation. If you want to use this mechanism in handover, I don't know how can you keep the connection-id, because the MAGs are using different lower layers. >> >>> >>> Second, the use of GRE keys and GRE tunneling is optional in >>> PMIP6. Well, so is Service Selection too but I would avoid >>> building additional dependencies between different documents if >>> just possible. >> Yes, GRE Key is an optional option. I think an optional option is used >> for a optional feature is reasonable > > The less the better. I.e. if I can choose between two optional > features versus three optional features, I would go for two. > > >> >>> >>> Third, overloading the function of the GRE key option does not >>> sound a good idea in general, even if it were possible. >> If it works well, why not take it as the solution? > > Overloading existing semantics is always a bad practice. > Yes, I agree it is a trouble. But if the overloading is in the acceptable scope, IMO, we need balance the impact of overloading and introducing a new expansion. It is the motivation behind my original question. > I'll skip the rest as I don't see how they relate to this discussion. > > Cheers, > Jouni > > [snip] From jouni.nospam@gmail.com Fri Jul 31 03:57:22 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923003A6ABA for ; Fri, 31 Jul 2009 03:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeGJfl+JBq5H for ; Fri, 31 Jul 2009 03:57:21 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 422633A686D for ; Fri, 31 Jul 2009 03:57:21 -0700 (PDT) Received: by bwz19 with SMTP id 19so1119251bwz.37 for ; Fri, 31 Jul 2009 03:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=sceXzHyrGw8L1MRtZK+IVgFifFRMVR54Ga+dM/Ynosk=; b=bPNlK0qe0LMXyNqbtn7ojBomk/Th56lxPwdxeN1RWkCwjZle3LdhibOCpDWGj5TxWh gSFY+vV92/YOFTiFUoKlaWN1ajDT7gBM6D47k8qarAi0Yn3G5m6XTm+rFzS3bi0wkoyX 87tnElvV3BT73WbQ5aURNfL4eG+4MoweJTZoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=FyeyKnRbULY9FKltjuawdgpZPhTLrGd9S9QFVZD7mbdvqV1HqWLegbTpuZkkODYl4e DVcq8k3zNraMTGY9SXxmd6lDgTzQyzZMbDvbNTgc4TgZQQpKeVS4RYsPzozLRaatsusD vyQdp1+MDMe42bs94afv8J+CwQK+rfkobdd2U= Received: by 10.103.247.17 with SMTP id z17mr1216812mur.84.1249037839588; Fri, 31 Jul 2009 03:57:19 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org (dhcp-54f6.meeting.ietf.org [130.129.84.246]) by mx.google.com with ESMTPS id 7sm6019188mup.24.2009.07.31.03.57.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 03:57:19 -0700 (PDT) Message-Id: <4B6D3652-388D-4739-9683-69244AD2C90A@gmail.com> From: jouni korhonen To: "Koodli, Rajeev" In-Reply-To: <4D35478224365146822AE9E3AD4A266609382A45@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 13:57:17 +0300 References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266609382A45@exchtewks3.starentnetworks.com> X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 10:57:22 -0000 On Jul 31, 2009, at 12:49 PM, Koodli, Rajeev wrote: > > Hi, > > >> >> We can consider 2) as a special case which MAY be allowed under >> specific conditions. But, we need to spell out those conditions >> clearly and agree. In any case, 2) cannot be the general-purpose >> protocol. > > For the case 2) would you be OK if we, for example: > o Add a flag in the response mobility option, which indicates > whether there is already a BCE setup in LMA2. > o Describe the conditions required for the above to be possible. > > Rajeev:> I would start with the second bullet. Once we agree on > that, it would be trivial to add a flag IMO.' Righty, I'll work for that. Cheers, Jouni > > -Rajeev > > > Cheers, > Jouni > > > > >> >> Regards, >> >> -Rajeev >> >> >> ________________________________ >> >> From: netext-bounces@ietf.org on behalf of jouni korhonen >> Sent: Thu 7/30/2009 9:45 AM >> To: netext@ietf.org >> Subject: [netext] Clarifications regarding the runtime LMA assignment >> >> >> >> Hi all, >> >> To follow up and clarify the questions from Rajeev, here is something >> that hopefully makes things clearer. The "proxied" case can be >> represented as below. The assumption is that the rfLMA and the r2LMA >> can exchange information between each other, and that the MAG has SAs >> with both rfLMA and the r2LMA. We do not define how and what goes >> between the rfLMA and the r2LMA. That is internal to the "LMA >> system", >> whatever that "LMA system" constitutes of (that would imply a single >> vendor within a "LMA system" but I guess it would reflect the reality >> anyway). We need to state in the draft, though, that a MAG can be >> sure >> the r2LMA has a binding setup when it receives a PBA with both >> redirection information and a successful result code. There is both >> vendor and operator interest in this approach, so I consider it >> important. >> >> MAG rfLMA r2LMA >> | | | >> |--PBU-->|- - - - | (redirection takes place, >> |<--PBA--| - - - -| PBA contains rfLMA & r2LMA >> | | | information) >> | | | >> |<=====data======>| >> | | | >> |-------PBU------>| (lifetime extension, >> |<------PBA-------| de-registration, etc >> | | | >> >> I don't mind nuking the "direct" solution in the draft. Actually I >> would be happy to do that ;) If folks are fine with options, we could >> add a variation of the "proxied" case, where another roundtrip of >> PBU/ >> PBA is needed between a MAG and a r2LMA before data can flow. This >> would, of course, be runtime negotiated. >> >> >> Cheers, >> Jouni >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Fri Jul 31 05:47:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3883A6DD8 for ; Fri, 31 Jul 2009 05:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUdR3V8SsAfF for ; Fri, 31 Jul 2009 05:47:07 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A7D963A69C7 for ; Fri, 31 Jul 2009 05:47:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN00EMNCUGEI@szxga03-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 20:47:04 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN00K0ICUG2U@szxga03-in.huawei.com> for netext@ietf.org; Fri, 31 Jul 2009 20:47:04 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [221.223.252.85]) by szxmc03-in.huawei.com (mshttpd); Fri, 31 Jul 2009 20:47:04 +0800 Date: Fri, 31 Jul 2009 20:47:04 +0800 From: cuixiangsong 00111037 In-reply-to: <4D35478224365146822AE9E3AD4A266609382A44@exchtewks3.starentnetworks.com> To: "Koodli, Rajeev" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_Q0cpPhal24+cB7xHbG0k5g)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <00c101ca118d$eb2ee360$40106f0a@china.huawei.com> <4D35478224365146822AE9E3AD4A266609382A44@exchtewks3.starentnetworks.com> Cc: netext@ietf.org Subject: Re: [netext] Request for adopting draft-cui-netext-lma-redirection-solution-00 as a WG baseline X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 12:47:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Q0cpPhal24+cB7xHbG0k5g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Rajeev=2C Very thank you for your response=2E =3E it is the common practice to discuss a draft and make revisions=3B = =3E that=27s how we work in IETF WGs=2E = Yes=2C I very agree the rule=2E = But in my mind=2C the current fact is that there are two drafts on the topic and WG almost got the shape of the final solution=2E (We all agree that the LMA-1 indicate the MAG the redirextion and MAG send PBU to the LMA-2=2E) I want to say=2C my draft is a more alike approach to this final solution=2E Before we make revisions=2C which draft should be taken as the baseline=3F I think a nearer draft will save our time=2E So I remind the WG to review my draft and I think it is more suitable for this topic=2E We can make revisions on the draft in a better approach=2E =3E My comments are inline with that = =3E and not meant to compare one draft against another=2E = I cited your comment just to clarify the fact that we have got a consensus on the final solution and I also want to show what the final solution looks like=2E That is all=2E As to the =22comments are inline=22 you mentioned=2C do you mean you give me some comments in the mail=3F = I find no one=2C so I take it as the comments I cited in my = previous mail=2E Best Regards Xiangsong ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Koodli=2C Rajeev=22 =3Crkoodli=40starentnetworks= =2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C6=DF=D4=C2 31=C8=D5=2C 2009 =CF=C2= =CE=E75=3A52 =D6=F7=CC=E2=3A Re=3A =5Bnetext=5D Request for adopting draft-cui-netext-= lma-redirection-solution-00 as a WG baseline =CA=D5=BC=FE=C8=CB=3A netext=40ietf=2Eorg =3E = =3E Hi Xiangsong=2C =3E = =3E it is the common practice to discuss a draft and make revisions=3B = =3E that=27s how we work in IETF WGs=2E My comments are inline with that = =3E and not meant to compare one draft against another=2E = =3E = =3E Please provide your comments on the topic=2E Your input will be = =3E discussed just as any other input and taken into consideration in = =3E making progress on the topic=2E = =3E = =3E Thanks=2C =3E = =3E -Rajeev =3E = =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E = =3E From=3A netext-bounces=40ietf=2Eorg on behalf of Xiangsong Cui =3E Sent=3A Thu 7/30/2009 8=3A20 PM =3E To=3A Basavaraj=2EPatil=40nokia=2Ecom=3B netext=40ietf=2Eorg =3E Subject=3A =5Bnetext=5D Request for adopting draft-cui-netext-lma- =3E redirection-solution-00 as a WG baseline =3E = =3E = =3E = =3E Hi Raj=2C =3E = =3E After the discussion=2C I think the WG have got a consensus =3E on the principle=2E =3E = =3E As Koodli mentioned in the message=3A =3E http=3A//www=2Eietf=2Eorg/mail-archive/web/netext/current/msg00745=2E= html=2C =3E =22As a baseline protocol=2C we need 1)=2C i=2Ee=2E=2C LMA-1 informs = MAG =3E about LMA-2=2C and MAG then contacts LMA-2 with PBU/PBA=3B =3E only then BCE is set up at LMA-2=2E=22 =3E = =3E Basing on this principle=2C I believe the draft =3E http=3A//tools=2Eietf=2Eorg/id/draft-cui-netext-lma-redirection-solut= ion- =3E 00=2Etxtis more conformable than the draft =3E http=3A//tools=2Eietf=2Eorg/id/draft-korhonen-netext-redirect-02=2Etx= t=2E =3E = =3E (I attach a message in the end to explain that the drafts are = =3E different=2E) =3E = =3E So I would like to ask WG to accept my draft =3E http=3A//tools=2Eietf=2Eorg/id/draft-cui-netext-lma-redirection-solut= ion- =3E 00=2Etxtas the baseline of LMA Redirection=2E =3E = =3E Regards =3E = =3E Xiangsong =3E = =3E = =3E ----- Original Message ----- =3E From=3A =22Xiangsong Cui=22 =3CXiangsong=2ECui=40huawei=2Ecom=3E =3E To=3A =22Vijay Devarapalli=22 =3Cvijay=40wichorus=2Ecom=3E=3B =3Cnete= xt=40ietf=2Eorg=3E =3E Sent=3A Friday=2C July 31=2C 2009 10=3A12 AM =3E Subject=3A Re=3A =5Bnetext=5D draft-cui-netext-lma-redirection-soluti= on-00 =3E = =3E = =3E =3E Hi Vijay=2C =3E =3E =3E =3E Thank you for your response=2C and I think we should do more =3E =3E discussion on the issue=2E =3E =3E =3E =3E=3E As Jouni pointed=2C this mechanism was already there in versio= n = =3E 00 of =3E =3E=3E draft-korhonen-netext-redirect=2E =3E =3E =3E =3E I have to say I can=27t agree that=2E =3E =3E Because I didn=27t read the early version (i=2Ee=2E draft-00) in = the past=2C =3E =3E I check the document just now=2E =3E =3E =3E =3E In my understanding=2C the version 00 is similar with version 02=2C= but =3E =3E different with my draft=2E =3E =3E =3E =3E The key points are=3A who send the first PBA to MAG=3F =3E =3E When the old LMA decide to do redirection=2C whom does the =3E =3E old LMA send message to=3F =3E =3E =3E =3E In my draft=2C it is the old LMA sends PBA to MAG=2C indicating =3E =3E the redirection procedure and the new LMA information=2E =3E =3E When the old LMA decide to do redirection=2C it sends message =3E =3E to the MAG=2C but not the new LMA=2E =3E =3E =3E =3E In the drafts of Jouni=2C it is the new LMA sends PBA=2C it is th= e = =3E new LMA =3E =3E sends the option to MAG=2C indicating the redirection procedure = =3E and with =3E =3E the old LMA information attached=2E =3E =3E I get this conclusion=2C because of the following text (copied = =3E from draft =3E =3E 00)=3A =3E =3E =3E =3E Section 3=3A =3E =3E =22 The Redirect mobility option in the PBA MUST contain the =3E =3E IPv6 address (unicast or anycast) of the rfLMA and MAY contain = the =3E =3E IPv4 address of the rfLMA=2E The PBA containing the Redirect = =3E mobility=3E option MUST be sent from the r2LMA=2E After receiving = =3E the PBA =3E =3E containing the Redirect mobility option from the r2LMA=2C the = =3E MAG MUST =3E =3E send subsequent PBUs and user traffic to the r2LMA that = =3E concern the =3E =3E redirected mobility session=2E=22 =3E =3E =3E =3E The draft says the PBA MUST be sent from the r2LMA=2C which is th= e new =3E =3E one=2E =3E =3E =3E =3E Section 5=2E1=3A =3E =3E =22 If the MAG receives a PBA that contains the Redirect mobility= = =3E option=3E from a LMA without first including the Redirect mobility = =3E option in =3E =3E the corresponding PBU=2C the MAG MUST treat the PBA as if the = =3E binding=3E update failed and log the event=2E If the MAG receives = a = =3E PBA that =3E =3E contains the Redirect mobility option and the MAG had included = the =3E =3E Redirect mobility option in the corresponding PBU=2C then the = =3E MAG MUST =3E =3E perform the following steps in addition to the normal RFC 5213 = PBA =3E =3E processing=3A =3E =3E =3E =3E o Check if the Redirect mobility option contains the IP = =3E address of =3E =3E the LMA to whom the MAG originally sent the PBU (i=2Ee=2E th= e = =3E rfLMA)=2E=3E If the check fails=2C then the MAG MUST treat the P= BA = =3E as if the =3E =3E binding update failed and log the event=2E =3E =3E =3E =3E o Update the Binding Update List to correspond to the LMA Addr= ess =3E =3E where the newly received PBA came from=2E=22 =3E =3E =3E =3E Notice the last sentence=2C I believe the LMA is the new LMA=2C s= o = =3E the MAG =3E =3E need update the binding update list=2C isn=27t it=3F =3E =3E =3E =3E Section 5=2E2=3A =3E =3E =22 In =3E =3E the case of redirection=2C the r2LMA MUST always include the IP= v6 =3E =3E address (unicast or anycast) of the rfLMA in the Redirect mobil= ity =3E =3E option in the PBA=2E=22 =3E =3E =3E =3E The draft says r2LMA MUST include the information of the old LMA=2C= =3E =3E while in my draft=2C it is the old LMA indicates the new LMA=2E =3E =3E =3E =3E Vijay=2C would you like to read the draft-00 of Jouni and check m= y =3E =3E conclusion=3F =3E =3E =3E =3E =3E =3E=3E The normal IETF practice is to send comments =3E =3E=3E saying that you prefer the mechanism in the original draft = =3E compared to =3E =3E=3E the =3E =3E=3E new mechanism=2E You can suggest enhancements too=2E =3E =3E =3E =3E I agree the mechanism in my draft is widely used in other = =3E protocols=2C but =3E =3E I don=27t think it is introduced in the drafts of Jouni=2E =3E =3E =3E =3E =3E =3E=3E There might be some minor =3E =3E=3E differences between what is in your draft and =3E =3E=3E draft-korhonen-netext-redirect-00=2Etxt=2C but writing yet ano= ther = =3E draft is =3E =3E=3E not =3E =3E=3E the right approach=2E =3E =3E=3E =3E =3E =3E =3E Because my draft is different from the drafts of Jouni=2C I think= = =3E I can =3E =3E submit =3E =3E it to the WG=2E We just discussed several drafts on the topic of = =3E RO=2C IMO=2C =3E =3E two drafts on the Redirection is reasonable=2E =3E =3E =3E =3E =3E =3E Regards =3E =3E =3E =3E Xiangsong =3E =3E =3E =3E =3E =3E =3E =3E ----- Original Message ----- =3E =3E From=3A =22Vijay Devarapalli=22 =3Cvijay=40wichorus=2Ecom=3E =3E =3E To=3A =22Xiangsong Cui=22 =3CXiangsong=2ECui=40huawei=2Ecom=3E=3B= =3Cnetext=40ietf=2Eorg=3E =3E =3E Sent=3A Friday=2C July 31=2C 2009 2=3A59 AM =3E =3E Subject=3A =5Bnetext=5D draft-cui-netext-lma-redirection-solution= -00 =3E =3E =3E =3E =3E =3E=3E Hi Xiangsong=2C =3E =3E=3E =3E =3E=3E As Jouni pointed=2C this mechanism was already there in versio= n = =3E 00 of =3E =3E=3E draft-korhonen-netext-redirect=2E The normal IETF practice is = to send =3E =3E=3E comments =3E =3E=3E saying that you prefer the mechanism in the original draft = =3E compared to =3E =3E=3E the =3E =3E=3E new mechanism=2E You can suggest enhancements too=2E There mig= ht be = =3E some=3E=3E minor =3E =3E=3E differences between what is in your draft and =3E =3E=3E draft-korhonen-netext-redirect-00=2Etxt=2C but writing yet ano= ther = =3E draft is =3E =3E=3E not =3E =3E=3E the right approach=2E =3E =3E=3E =3E =3E=3E Vijay =3E =3E=3E =3E =3E=3E =3E =3E=3E On 7/27/09 12=3A55 AM=2C =22Xiangsong Cui=22 wrote=3A =3E =3E=3E =3E =3E=3E=3E Hi all=2C =3E =3E=3E=3E =3E =3E=3E=3E I have just submitted a draft about the LMA Redirection sol= ution=2E =3E =3E=3E=3E You may find the draft by the link=3A =3E =3E=3E=3E http=3A//tools=2Eietf=2Eorg/html/draft-cui-netext-lma-redir= ection- =3E solution-00 =3E =3E=3E=3E =3E =3E=3E=3E Please take a look and any comment is welcomed=2E =3E =3E=3E=3E =3E =3E=3E=3E Thanks and regards =3E =3E=3E=3E =3E =3E=3E=3E Xiangsong =3E =3E=3E=3E =3E =3E=3E=3E ----- Original Message ----- =3E =3E=3E=3E From=3A =22IETF I-D Submission Tool=22 =3Cidsubmission=40ie= tf=2Eorg=3E =3E =3E=3E=3E To=3A =3CXiangsong=2ECui=40huawei=2Ecom=3E =3E =3E=3E=3E Sent=3A Monday=2C July 27=2C 2009 3=3A31 PM =3E =3E=3E=3E Subject=3A New Version Notification for =3E =3E=3E=3E draft-cui-netext-lma-redirection-solution-00 =3E =3E=3E=3E =3E =3E=3E=3E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E A new version of I-D=2C draft-cui-netext-lma-redirection= - =3E solution-00=2Etxt =3E =3E=3E=3E=3E has =3E =3E=3E=3E=3E been successfuly submitted by Xiangsong Cui and posted t= o the = =3E IETF=3E=3E=3E=3E repository=2E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E Filename=3A draft-cui-netext-lma-redirection-solution =3E =3E=3E=3E=3E Revision=3A 00 =3E =3E=3E=3E=3E Title=3A LMA Redirection Solution =3E =3E=3E=3E=3E Creation=5Fdate=3A 2009-07-27 =3E =3E=3E=3E=3E WG ID=3A Independent Submission =3E =3E=3E=3E=3E Number=5Fof=5Fpages=3A 8 =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E Abstract=3A =3E =3E=3E=3E=3E In network-based mobility management domain=2C LMA is us= ed to = =3E manage=3E=3E=3E=3E the mobility of IP node attached to MAG=2E LMA dis= covery = =3E and LMA =3E =3E=3E=3E=3E redirection mechanism are used to improve the network = =3E flexibility=2E=3E=3E=3E=3E This document is used to introduce a recom= mended = =3E solution for this =3E =3E=3E=3E=3E purpose=2E In this solution Redirect Agent function is a= dopted to =3E =3E=3E=3E=3E accomplish the requirement=2E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E Conventions used in this document =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E The key words =22MUST=22=2C =22MUST NOT=22=2C =22REQUIRE= D=22=2C =22SHALL=22=2C =22SHALL = =3E NOT=22=2C=3E=3E=3E=3E =22SHOULD=22=2C =22SHOULD NOT=22=2C =22RECOMMEN= DED=22=2C =22MAY=22=2C and = =3E =22OPTIONAL=22 in this =3E =3E=3E=3E=3E document are to be interpreted as described in =5BRFC211= 9=5D=2E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E The IETF Secretariat=2E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E =3E =3E=3E=3E =3E =3E=3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F =3E =3E=3E=3E netext mailing list =3E =3E=3E=3E netext=40ietf=2Eorg =3E =3E=3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netext =3E =3E=3E =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E=3E netext mailing list =3E =3E=3E netext=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netext =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E netext mailing list =3E =3E netext=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netext =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E netext mailing list =3E netext=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netext =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E netext mailing list =3E netext=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/netext =3E --Boundary_(ID_Q0cpPhal24+cB7xHbG0k5g) Content-type: text/x-vcard; name=c00111037.vcf; charset=gb2312 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c00111037.vcf Content-description: Card for cuixiangsong 00111037 begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:Xiangsong.Cui@huawei.com end:vcard --Boundary_(ID_Q0cpPhal24+cB7xHbG0k5g)-- From jouni.nospam@gmail.com Fri Jul 31 06:37:27 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BDF3A6E5D for ; Fri, 31 Jul 2009 06:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwWdjMB1jWqY for ; Fri, 31 Jul 2009 06:37:26 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id A1A3A3A69F9 for ; Fri, 31 Jul 2009 06:37:25 -0700 (PDT) Received: by ewy10 with SMTP id 10so1505616ewy.37 for ; Fri, 31 Jul 2009 06:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=zKVIyvknNvJrjr3gRckewMGO1r0Yl8+xWnyq3bQp//o=; b=an7J/yj+1TU+pihMG/3xx7L41YFDXpMtn0egthe2BEI946jtrpMJV+VkhS3mky4k7f I2+DEwZv8IOZR9a6OJPeJ1IeMRGxJU+Q61M3hZLylRwLQSjAhqBn9rJuf55nz4G/NHiA LJc9gzZvNd79wY6u2TQ5g0gUmNKtrsr1kPeI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=PAtcNC1VfUTBHThs8maf2OhE4gH3zWzCW6NV4mNxmtH6fiu/XCNEaxeo0Rn/1IFw3e xt2iz7pYElNvHNVwBnW1lFW6WlGxF5cATvhFoqAG0LzBdd3AiHQzp9CpXSB9qjmhkeOt vVjBLnF07Wt+J4WWmbUHcyUv6zejiBTSwjlaE= Received: by 10.216.13.74 with SMTP id a52mr469807wea.145.1249047444399; Fri, 31 Jul 2009 06:37:24 -0700 (PDT) Received: from dhcp-54f6.meeting.ietf.org ([130.129.84.246]) by mx.google.com with ESMTPS id 7sm3403808eyb.37.2009.07.31.06.37.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 06:37:23 -0700 (PDT) From: jouni korhonen To: Xiangsong Cui In-Reply-To: <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> X-Priority: 3 References: <018b01ca10fc$396761c0$40106f0a@china.huawei.com> <00e501ca1194$f20d4b70$40106f0a@china.huawei.com> <63E93F6E-5066-4DF9-B634-ECAED67E322F@gmail.com> <017b01ca11c5$bd5defc0$40106f0a@china.huawei.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 16:37:21 +0300 X-Mailer: Apple Mail (2.935.3) Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 13:37:27 -0000 Lets first resolve whether the GRE keys are usable in the first place. Then we can return to the rest of the discussion. Some more stuff inline. On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote: > Hi Jouni, > Please see inline. > > Regards/Xiangsong > > > ----- Original Message ----- From: "jouni korhonen" > > To: "Xiangsong Cui" > Cc: ; > Sent: Friday, July 31, 2009 5:16 PM > Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- > connid-00 > > >> Hi, >> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote: >>> Hi Jouni, >>> >>> Thank you for your response. >>> >>>> There are few reasons. First, which GRE key to use? Uplink or >>>> downlink? >>> I think Uplink and downlink may be used to identify the connection >> Uh.. so you would use combination of both keys simultaneously? > > Yes, I think GRE Key is designed for this manner. I am a bit confused. Do you mean using 64-bit identifier made of both uplink & downlink GRE keys? Anyway, downlink GRE keys are no good in general as they may change during handovers. If there is context transfer between MAGs it still does not solve the downlink key issue. One would need to start coordinating downlink key space between MAGs, which is a new requirement. The Uplink GRE key would be an usable connection Id, assuming MAGs can do a context transfer, the exception mentioned in Section 3.3.2 of draft-ietf-netlmm-grekey-option does not happen and that GRE is used in the first place. However, the GRE key option in a PBU contains only the downlink key. This means, you need something beyond draft-ietf- netlmm-grekey-option to send the uplink GRE key in the PBU (if the uplink GRE key were used as the connection Id). [snap] >>>> >>>> Second, the use of GRE keys and GRE tunneling is optional in >>>> PMIP6. Well, so is Service Selection too but I would avoid >>>> building additional dependencies between different documents if >>>> just possible. >>> Yes, GRE Key is an optional option. I think an optional option is >>> used >>> for a optional feature is reasonable >> The less the better. I.e. if I can choose between two optional >> features versus three optional features, I would go for two. >>> >>>> >>>> Third, overloading the function of the GRE key option does not >>>> sound a good idea in general, even if it were possible. >>> If it works well, why not take it as the solution? >> Overloading existing semantics is always a bad practice. > Yes, I agree it is a trouble. > But if the overloading is in the acceptable scope, IMO, we need > balance the impact of overloading and introducing a new expansion. > It is the motivation behind my original question. You would still need a document that describes how the GRE keys are used to extend the BCE lookup, how they are used with RFC5149, and how to indicate to the LMA that the GRE keys are used in this special overloaded way etc. If you go down this road, what is the benefit of it over defining a new option specifically made for connection identifier purpose? At the end, the connection identifier content can be anything that is a stable identifier within the system where this extension is being used.. be that a GRE key or not. Cheers, Jouni > >> I'll skip the rest as I don't see how they relate to this discussion. >> Cheers, >> Jouni > [snip] > > From yokota@kddilabs.jp Fri Jul 31 10:55:50 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C591C3A6E31 for ; Fri, 31 Jul 2009 10:55:50 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlOLxnekQXKd for ; Fri, 31 Jul 2009 10:55:50 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 5EE153A6DF2 for ; Fri, 31 Jul 2009 10:55:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0D53AEC8D0; Sat, 1 Aug 2009 02:55:47 +0900 (JST) Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id 74265EC8C2; Sat, 1 Aug 2009 02:55:46 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 6E21D1BA74; Sat, 1 Aug 2009 02:51:38 +0900 (JST) Message-ID: <4A733014.8050705@kddilabs.jp> Date: Sat, 01 Aug 2009 02:55:32 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: netext@ietf.org Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:55:50 -0000 Hi Rajeev, Koodli, Rajeev wrote: > > Hi Jouni, > > as I mentioned during the meeting, there are two separate issues here: 1) runtime LMA selection, which is simply LMA-1 informing MAG to use LMA-2, and 2) establishing BCE at LMA-2 at the same time that LMA-1 informs MAG. > > As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about LMA-2, and MAG then contacts LMA-2 with PBU/PBA; only then BCE is set up at LMA-2. > > We can consider 2) as a special case which MAY be allowed under specific conditions. But, we need to spell out those conditions clearly and agree. In any case, 2) cannot be the general-purpose protocol. We don't necessarily have to make 2) as a special case. It's just one way of realization and can be treated equally. Regards, -- Hidetoshi > Regards, > > -Rajeev > > > ________________________________ > > From: netext-bounces@ietf.org on behalf of jouni korhonen > Sent: Thu 7/30/2009 9:45 AM > To: netext@ietf.org > Subject: [netext] Clarifications regarding the runtime LMA assignment > > > > Hi all, > > To follow up and clarify the questions from Rajeev, here is something > that hopefully makes things clearer. The "proxied" case can be > represented as below. The assumption is that the rfLMA and the r2LMA > can exchange information between each other, and that the MAG has SAs > with both rfLMA and the r2LMA. We do not define how and what goes > between the rfLMA and the r2LMA. That is internal to the "LMA system", > whatever that "LMA system" constitutes of (that would imply a single > vendor within a "LMA system" but I guess it would reflect the reality > anyway). We need to state in the draft, though, that a MAG can be sure > the r2LMA has a binding setup when it receives a PBA with both > redirection information and a successful result code. There is both > vendor and operator interest in this approach, so I consider it > important. > > MAG rfLMA r2LMA > | | | > |--PBU-->|- - - - | (redirection takes place, > |<--PBA--| - - - -| PBA contains rfLMA & r2LMA > | | | information) > | | | > |<=====data======>| > | | | > |-------PBU------>| (lifetime extension, > |<------PBA-------| de-registration, etc > | | | > > I don't mind nuking the "direct" solution in the draft. Actually I > would be happy to do that ;) If folks are fine with options, we could > add a variation of the "proxied" case, where another roundtrip of PBU/ > PBA is needed between a MAG and a r2LMA before data can flow. This > would, of course, be runtime negotiated. > > > Cheers, > Jouni > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > From rkoodli@starentnetworks.com Fri Jul 31 13:40:28 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5993A6B25 for ; Fri, 31 Jul 2009 13:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqfumeSxKuDy for ; Fri, 31 Jul 2009 13:40:25 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 831AF3A6986 for ; Fri, 31 Jul 2009 13:40:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id F18EE108003 for ; Fri, 31 Jul 2009 16:40:23 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26332-14 for ; Fri, 31 Jul 2009 16:40:19 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (unknown [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 31 Jul 2009 16:40:19 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Jul 2009 16:39:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Jul 2009 16:37:33 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382A47@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Clarifications regarding the runtime LMA assignment Thread-Index: AcoSCBobefBAqU3OTVKhyvwX5NFpswAFqEGv References: <01C58952-A8B2-460D-BE11-E9F01541AF71@gmail.com> <4D35478224365146822AE9E3AD4A266609382A43@exchtewks3.starentnetworks.com> <4A733014.8050705@kddilabs.jp> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 31 Jul 2009 20:39:49.0210 (UTC) FILETIME=[0C3D23A0:01CA121F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [netext] Clarifications regarding the runtime LMA assignment X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 20:40:29 -0000 =20 Hello Yokota-san. =20 >We don't necessarily have to make 2) as a special case. It's just one > way of realization and can be treated equally. Well, redirecting MAG is to a different LMA and establishing BCE at the = redirected LMA are two different things. We need to solve the first part for sure, and we can consider allowing = the second once we understand the picture clearly. Regards, -Rajeev Regards, -- Hidetoshi > Regards, >=20 > -Rajeev >=20 > > ________________________________ > > From: netext-bounces@ietf.org on behalf of jouni korhonen > Sent: Thu 7/30/2009 9:45 AM > To: netext@ietf.org > Subject: [netext] Clarifications regarding the runtime LMA assignment > > > > Hi all, > > To follow up and clarify the questions from Rajeev, here is something > that hopefully makes things clearer. The "proxied" case can be > represented as below. The assumption is that the rfLMA and the r2LMA > can exchange information between each other, and that the MAG has SAs > with both rfLMA and the r2LMA. We do not define how and what goes > between the rfLMA and the r2LMA. That is internal to the "LMA system", > whatever that "LMA system" constitutes of (that would imply a single > vendor within a "LMA system" but I guess it would reflect the reality > anyway). We need to state in the draft, though, that a MAG can be sure > the r2LMA has a binding setup when it receives a PBA with both > redirection information and a successful result code. There is both > vendor and operator interest in this approach, so I consider it > important. > > MAG rfLMA r2LMA > | | | > |--PBU-->|- - - - | (redirection takes place, > |<--PBA--| - - - -| PBA contains rfLMA & r2LMA > | | | information) > | | | > |<=3D=3D=3D=3D=3Ddata=3D=3D=3D=3D=3D=3D>| > | | | > |-------PBU------>| (lifetime extension, > |<------PBA-------| de-registration, etc > | | | > > I don't mind nuking the "direct" solution in the draft. Actually I > would be happy to do that ;) If folks are fine with options, we could > add a variation of the "proxied" case, where another roundtrip of PBU/ > PBA is needed between a MAG and a r2LMA before data can flow. This > would, of course, be runtime negotiated. > > > Cheers, > Jouni > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > >