From nobody Wed Apr 6 03:21:57 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F3F12D18C for ; Wed, 6 Apr 2016 03:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvsv3hLAnhl7 for ; Wed, 6 Apr 2016 03:21:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7CF12D153 for ; Wed, 6 Apr 2016 03:21:52 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7BEB92644CB for ; Wed, 6 Apr 2016 12:21:50 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [10.114.50.50]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5ADA627C072 for ; Wed, 6 Apr 2016 12:21:50 +0200 (CEST) Received: from OPEXCNORM2E.corporate.adroot.infra.ftgroup ([fe80::c505:acb8:89e0:c6d6]) by OPEXCNORM52.corporate.adroot.infra.ftgroup ([fe80::c482:2589:c116:5790%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 12:21:50 +0200 From: To: "dmm@ietf.org" Thread-Topic: update:: draft-ietf-dmm-mag-multihoming Thread-Index: AdGP7fvFpZYbo5skSL619JABS+SBOg== Date: Wed, 6 Apr 2016 10:21:49 +0000 Message-ID: <31499_1459938110_5704E33E_31499_1506_1_81C77F07008CA24F9783A98CFD706F71161814C9@OPEXCNORM2E.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71161814C9OPEXCNORM2Ecorp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416 Archived-At: Subject: [DMM] update:: draft-ietf-dmm-mag-multihoming X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:21:55 -0000 --_000_81C77F07008CA24F9783A98CFD706F71161814C9OPEXCNORM2Ecorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have updated draft-ietf-dmm-mag-multihoming: https://tools.ietf.org/id/d= raft-ietf-dmm-mag-multihoming-01.txt This release addresses comments received during wg last call, namely: all r= eferences to dsl and bbf use-case have been removed. Pierrick ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71161814C9OPEXCNORM2Ecorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have updated draft-ietf= -dmm-mag-multihoming: https://tools.ietf.org/id/draft-ietf-dmm-mag-multihoming-01.txt

 

This release addresses com= ments received during wg last call, namely: all references to dsl and bbf u= se-case have been removed.

 

Pierrick= 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71161814C9OPEXCNORM2Ecorp_-- From nobody Wed Apr 6 05:42:40 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD812D0A2 for ; Wed, 6 Apr 2016 05:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYu_Kfvk089F for ; Wed, 6 Apr 2016 05:42:35 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935E412D09D for ; Wed, 6 Apr 2016 05:42:35 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 3A1F740387; Wed, 6 Apr 2016 14:42:34 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.54]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 197221A0072; Wed, 6 Apr 2016 14:42:34 +0200 (CEST) Received: from OPEXCNORM2E.corporate.adroot.infra.ftgroup ([fe80::c505:acb8:89e0:c6d6]) by OPEXCNORM62.corporate.adroot.infra.ftgroup ([fe80::711e:8fd9:cdba:7676%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 14:42:33 +0200 From: To: "Moses, Danny" , "sarikaya@ieee.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGMnprVpgPBYC0SClZi/Ek/Av59rOExogAFHQwCAAyINgIADGUuAgAA64gCAAWjSAIAJKZYQ Date: Wed, 6 Apr 2016 12:42:33 +0000 Message-ID: <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> References: <565DE1DD.2070007@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:42:39 -0000 Hi Dany, I support this I-D. I find the document very useful, and well written. We a= ll agree that mobility management must be activated on purpose, it likely = requires an enhanced source address selection framework where applications = can obtain IP address with specific properties. By allowing applications to= request prefix properties, this I-D is clearly a part of this framework. M= aybe the document could be better by stressing clearly that it should be us= ed together with solutions allowing the network to expose prefix properties= to the host, for example with draft-korhonen-dmm-prefix-properties and dra= ft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... Lik= e I said, it is a framework :-) BR, Pierrick > -----Message d'origine----- > De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Moses, Danny > Envoy=E9=A0: jeudi 31 mars 2016 18:44 > =C0=A0: sarikaya@ieee.org > Cc=A0: dmm@ietf.org > Objet=A0: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >=20 > Hi, > Good, see my reply inline (surrounded by >>>>>>>>>>>>) . >=20 > Thanks again for investing the time to review the drafts, > /Danny >=20 > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: Wednesday, March 30, 2016 12:12 > To: Moses, Danny > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >=20 > Hi Danny, >=20 > I am removing all previous conversation because it all got mixed up. > Let's start afresh. >=20 >=20 > I read you dhcp draft also. >=20 > There is confusion in several levels. Your API draft talks about different > applications on a MN needing different types of mobility services. Your D= HCPv6 > draft seems to give a solution on how a host can get different types of > addresses/prefixes from DHCPv6 server, so is it for a host or an applicat= ion? > Prefix or address is assigned for an interface, that is another well know= n concept > which your draft seem to completely ignore, i.e. a host may have multiple > interfaces. > DM>>>>>>>>>>>>>>>>>>>>>> > Yes, I understand were the confusion might arise. The only entity in the = host (or - > mobile device) which uses DHCP is the DHCP client that is part of the TCP= /IP > stack. There may be several triggers to cause the DHCP client to request = a source > IP address: > - When the mobile node initially attaches to a network. > - When the mobile node moves to a different location and needs to refres= h its > source IP address. > The On-Demand concept implies a new trigger: > - When an application is launched, opens an IP Socket and requires a spe= cial type > of source IP address which was not already assigned to the mobile node. > So, it is the responsibility of the TCP/IP stack in the mobile node to fi= gure out > when it is required to initiate a DHCP transaction to serve the applicati= on's needs. >=20 > Regarding multiple interface, you are correct once more. A mobile node ma= y have > multiple interfaces. When this occurs, the mobile node needs to send at l= east one > DHCP request on each interface and the network assigns the source IP addr= ess to > the interface from which the DHCP request had arrived. This is not new an= d the > DHCP draft does not mention it because there are no changes or extensions > required. > >>>>>>>>>>>>>>>>>>>>>>>>>DM >=20 > Another concept is (as I already mentioned) topological correctness. > If MN changes subnet, its previous prefix becomes topologically incorrect= . Either it > has to get a new prefix or there must be some system support, e.g. host r= outes. > Of course another case is anchoring, like in 3GPP or in MIP. If you are a= nchored > your prefix does not change. >=20 > So you seem to ignore all these and instead introduce three types of addr= esses > among which the sustained IP address/prefix is the key to your solution. >=20 > Sustained address/prefix has this magical property: > the IP address used at the beginning of the session remains usable despi= te the > movement of the mobile host. >=20 > and then you say >=20 > access network anchoring, corresponding network anchoring, or some > other solution > can provide sustained address/prefixes. > what does corresponding network anchoring mean? >=20 > DM>>>>>>>>>>>>>>>>>> > Corresponding network is a concept from Alper Yegin's draft - > https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It defines= the > concept of having the mobility anchor in the network of the mobile node's > corresponding node, rather than in the access network. It is an interesti= ng concept > with its advantages (and disadvantages...). > >>>>>>>>>>>>>>>>>>>DM >=20 > I have a feeling that what your drafts are saying that right now we don't= know but > we anticipate in the future some ways will be found to make sustained IP > addresses. > Is this true? > DM>>>>>>>>>>>>>>>>>>>> > Well, we do know how the network can support sustained addresses. But I b= elieve > that in our DMM work, new alternatives for supporting Fixed and Sustained= IP > addresses will be defined. > >>>>>>>>>>>>>>>>>>>>>DM >=20 > BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained > address/prefix but it does not say how it will be different than the fixe= d one? > DM>>>>>>>>>>>>>>>>>>>>>>> > That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in ord= er to > support the requests and replies. DHCP does not define how IP addresses a= re > allocated. > >>>>>>>>>>>>>>>>>>>>>>>>DM >=20 > Suppose we want to develop an access network anchoring for sustained IP > addresses. > What about the needs for signaling? I have a feeling that a host running = very many > applications, like in today's smart phones, and so many smart phones in t= he > system that is going to involve huge amount of signaling to get/release s= ustained > address/prefixes, right? > DM>>>>>>>>>>>>>>>>>>>>> > Yes, a mobile host may activate several applications concurrently, but th= is does > not mean that each application requires its own unique source IP address.= Let's > assume that a large amount of application are launched, some require Fixe= d IP > addresses, some require Sustained IP addresses and the rest settle for No= madic > IP addresses. In that case, only three source IP addresses are required b= y the > mobile node: One Fixed IP address, one Sustained and one Nomadic IP addre= ss. > So the signaling overhead is not that huge. > >>>>>>>>>>>>>>>>>>>>>>DM >=20 >=20 > My conclusion from all of the above is that, I think what you propose sou= nds like a > flashy idea but it seems to me that the complications involved in any sol= ution is > intractable. > Unless you can show me otherwise. > DM>>>>>>>>>>>>>>>>>>>>> > I hope I managed to convince you that it is not that complicated. I reall= y think (and > there are other members who share this belief) that the tunneling overhea= d and un- > optimized routes are much more costly than what we are suggesting in this= new > concept. > >>>>>>>>>>>>>>>>>>>>>>>DM >=20 > Regards, >=20 > Behcet > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies >=20 > This e-mail and any attachments may contain confidential material for the= sole use > of the intended recipient(s). Any review or distribution by others is str= ictly > prohibited. If you are not the intended recipient, please contact the sen= der and > delete all copies. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 6 10:40:07 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD9212D6D9 for ; Wed, 6 Apr 2016 10:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kes0pEbVqsoX for ; Wed, 6 Apr 2016 10:40:03 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id CC15B12D0F3 for ; Wed, 6 Apr 2016 10:40:03 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 06 Apr 2016 10:39:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,447,1455004800"; d="scan'208";a="939674006" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 06 Apr 2016 10:39:58 -0700 Received: from lcsmsx153.ger.corp.intel.com (10.186.165.228) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 6 Apr 2016 10:39:58 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.105]) by LCSMSX153.ger.corp.intel.com ([169.254.8.131]) with mapi id 14.03.0248.002; Wed, 6 Apr 2016 20:39:56 +0300 From: "Moses, Danny" To: "pierrick.seite@orange.com" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWCAAGoVAIAEdKFAgACboYCAM1UhgIABgxHggAMH1YCAA0Q/cIAAD+0AgAGOdYCACQUJgIAAhIqQ Date: Wed, 6 Apr 2016 17:39:55 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> In-Reply-To: <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjllODg5ZWEtMTEyYi00ZjM4LWE1MDAtYmI3MDA4ZTdhNWE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjlHS054ZDVpSGZ3QmhqZ2JqZ08rOTRNTzF5MFlWeERhRWpya3ZSNkRyZjQ9In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:40:05 -0000 H Pierrick, Thanks for the support. Yes, we will look for a place to add the clarification that these API exten= sion rely on other protocol enhancements to communicate the address type re= quest to the network. We cannot currently provide reference to the specific= documents you gave in your examples because they are not RFCs (yet...). Danny -----Original Message----- From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] = Sent: Wednesday, April 06, 2016 05:43 To: Moses, Danny; sarikaya@ieee.org Cc: dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hi Dany, I support this I-D. I find the document very useful, and well written. We a= ll agree that mobility management must be activated on purpose, it likely = requires an enhanced source address selection framework where applications = can obtain IP address with specific properties. By allowing applications to= request prefix properties, this I-D is clearly a part of this framework. M= aybe the document could be better by stressing clearly that it should be us= ed together with solutions allowing the network to expose prefix properties= to the host, for example with draft-korhonen-dmm-prefix-properties and dra= ft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... Lik= e I said, it is a framework :-) BR, Pierrick > -----Message d'origine----- > De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Moses, Danny = > Envoy=E9=A0: jeudi 31 mars 2016 18:44 =C0=A0: sarikaya@ieee.org Cc=A0: = > dmm@ietf.org Objet=A0: Re: [DMM] WGLC #1 for = > draft-ietf-dmm-ondemand-mobility-01 > = > Hi, > Good, see my reply inline (surrounded by >>>>>>>>>>>>) . > = > Thanks again for investing the time to review the drafts, > /Danny > = > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: Wednesday, March 30, 2016 12:12 > To: Moses, Danny > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > = > Hi Danny, > = > I am removing all previous conversation because it all got mixed up. > Let's start afresh. > = > = > I read you dhcp draft also. > = > There is confusion in several levels. Your API draft talks about = > different applications on a MN needing different types of mobility = > services. Your DHCPv6 draft seems to give a solution on how a host can = > get different types of addresses/prefixes from DHCPv6 server, so is it fo= r a host or an application? > Prefix or address is assigned for an interface, that is another well = > known concept which your draft seem to completely ignore, i.e. a host = > may have multiple interfaces. > DM>>>>>>>>>>>>>>>>>>>>>> > Yes, I understand were the confusion might arise. The only entity in = > the host (or - mobile device) which uses DHCP is the DHCP client that = > is part of the TCP/IP stack. There may be several triggers to cause = > the DHCP client to request a source IP address: > - When the mobile node initially attaches to a network. > - When the mobile node moves to a different location and needs to = > refresh its source IP address. > The On-Demand concept implies a new trigger: > - When an application is launched, opens an IP Socket and requires a = > special type of source IP address which was not already assigned to the m= obile node. > So, it is the responsibility of the TCP/IP stack in the mobile node to = > figure out when it is required to initiate a DHCP transaction to serve th= e application's needs. > = > Regarding multiple interface, you are correct once more. A mobile node = > may have multiple interfaces. When this occurs, the mobile node needs = > to send at least one DHCP request on each interface and the network = > assigns the source IP address to the interface from which the DHCP = > request had arrived. This is not new and the DHCP draft does not = > mention it because there are no changes or extensions required. > >>>>>>>>>>>>>>>>>>>>>>>>>DM > = > Another concept is (as I already mentioned) topological correctness. > If MN changes subnet, its previous prefix becomes topologically = > incorrect. Either it has to get a new prefix or there must be some system= support, e.g. host routes. > Of course another case is anchoring, like in 3GPP or in MIP. If you = > are anchored your prefix does not change. > = > So you seem to ignore all these and instead introduce three types of = > addresses among which the sustained IP address/prefix is the key to your = solution. > = > Sustained address/prefix has this magical property: > the IP address used at the beginning of the session remains usable = > despite the movement of the mobile host. > = > and then you say > = > access network anchoring, corresponding network anchoring, or some > other solution > can provide sustained address/prefixes. > what does corresponding network anchoring mean? > = > DM>>>>>>>>>>>>>>>>>> > Corresponding network is a concept from Alper Yegin's draft - = > https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It = > defines the concept of having the mobility anchor in the network of = > the mobile node's corresponding node, rather than in the access = > network. It is an interesting concept with its advantages (and disadvanta= ges...). > >>>>>>>>>>>>>>>>>>>DM > = > I have a feeling that what your drafts are saying that right now we = > don't know but we anticipate in the future some ways will be found to = > make sustained IP addresses. > Is this true? > DM>>>>>>>>>>>>>>>>>>>> > Well, we do know how the network can support sustained addresses. But = > I believe that in our DMM work, new alternatives for supporting Fixed = > and Sustained IP addresses will be defined. > >>>>>>>>>>>>>>>>>>>>>DM > = > BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained = > address/prefix but it does not say how it will be different than the fixe= d one? > DM>>>>>>>>>>>>>>>>>>>>>>> > That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in = > order to support the requests and replies. DHCP does not define how IP = > addresses are allocated. > >>>>>>>>>>>>>>>>>>>>>>>>DM > = > Suppose we want to develop an access network anchoring for sustained = > IP addresses. > What about the needs for signaling? I have a feeling that a host = > running very many applications, like in today's smart phones, and so = > many smart phones in the system that is going to involve huge amount = > of signaling to get/release sustained address/prefixes, right? > DM>>>>>>>>>>>>>>>>>>>>> > Yes, a mobile host may activate several applications concurrently, but = > this does not mean that each application requires its own unique = > source IP address. Let's assume that a large amount of application are = > launched, some require Fixed IP addresses, some require Sustained IP = > addresses and the rest settle for Nomadic IP addresses. In that case, = > only three source IP addresses are required by the mobile node: One Fixed= IP address, one Sustained and one Nomadic IP address. > So the signaling overhead is not that huge. > >>>>>>>>>>>>>>>>>>>>>>DM > = > = > My conclusion from all of the above is that, I think what you propose = > sounds like a flashy idea but it seems to me that the complications = > involved in any solution is intractable. > Unless you can show me otherwise. > DM>>>>>>>>>>>>>>>>>>>>> > I hope I managed to convince you that it is not that complicated. I = > really think (and there are other members who share this belief) that = > the tunneling overhead and un- optimized routes are much more costly = > than what we are suggesting in this new concept. > >>>>>>>>>>>>>>>>>>>>>>>DM > = > Regards, > = > Behcet > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > = > This e-mail and any attachments may contain confidential material for = > the sole use of the intended recipient(s). Any review or distribution = > by others is strictly prohibited. If you are not the intended = > recipient, please contact the sender and delete all copies. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From nobody Wed Apr 6 11:01:27 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3626A12D70A for ; Wed, 6 Apr 2016 11:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKiiRmbOtfxe for ; Wed, 6 Apr 2016 11:01:22 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5D312D6BC for ; Wed, 6 Apr 2016 11:01:22 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id bc4so34912069lbc.2 for ; Wed, 06 Apr 2016 11:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=BgcjhV1ypIPUT0f0/LRvycqPFtVTOhS28GH91Y1EaUQ=; b=PxgY8//X4Bkt1lOWaQnimMrd8JansHfWzW4lLZNfiW4Z7sm6yFcknAHcUHS9o4UoHj JwSl07TcChBLBeiC0pkTxdX31ESZdfrep/oXgkM77VB/y1cf6pOWDu36cPvukuXiHMGi opDh/tjhGuQjF1lUh0htHJ3TjZC28KhDnxJ4Qyn2g0J51SVrtxq0TPg6yJ6J5Iaep299 I4mcwBE1R6k+rr25AXJ2JkFrG5hw5PMjvHSgGXiLgJqX7LfXB4fH9UMMHvsm/UrbglM6 sL076S1b0NPV+wgykRsGjW7YOIscr+UXP7fR07Obk40+UpmY/4TLgmn+Z6FRKFsiB+gl FIBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=BgcjhV1ypIPUT0f0/LRvycqPFtVTOhS28GH91Y1EaUQ=; b=ZVBZtlKZc5DFiP4XKNlAIcNjsWfq4CUXjxpIgS4uVS34jC3yjByQtJ327qEnrp6eJG guVvQV/nIi1UdbHyhy4lTm3uSISl9jphcpAu8E2K9ecGreKjUbedTn9mAKuouzMC2naq jw4Yft5I7uTro9CGpkEf9MIYf84paZISJ6/V5gD3UkyKsm+/+akhfJb4RG5SuP21NVmN 5V60BwLFCilSZr2EojcwreN9y9LXtIcxQHoyA94cnToDOR1rsqwgMakvojMCjSVU/P5F oULs8PiXJ7CBGFxCaFM3gna/3vDPK80EGGbKpfZF12aG3k7et7fpp5XBEVobarF/Vu4Z Bz3Q== X-Gm-Message-State: AD7BkJKfZ8/UbNZch5PP9YK6x1fm+nN3hB2Hyed1wjyBvgAfzaTqTfoGYrKzt/PzptZEj6Cjz7Tk63GqrE23yA== MIME-Version: 1.0 X-Received: by 10.112.209.99 with SMTP id ml3mr2100048lbc.26.1459965680360; Wed, 06 Apr 2016 11:01:20 -0700 (PDT) Received: by 10.112.252.135 with HTTP; Wed, 6 Apr 2016 11:01:20 -0700 (PDT) In-Reply-To: <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> References: <565DE1DD.2070007@gmail.com> <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> Date: Wed, 6 Apr 2016 13:01:20 -0500 Message-ID: From: Behcet Sarikaya To: Pierrick Seite Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:01:25 -0000 I am hoping that someone can show me a protocol that exists in some form, maybe a draft, that implements fine-grained anchoring as required by Sustained IP Addresses. We will write sometime in the future is not acceptable, then this and similar drafts have to wait until that time comes. One implication of this is such a protocol is willing to cope with the host routes. Behcet On Wed, Apr 6, 2016 at 7:42 AM, wrote: > Hi Dany, > > I support this I-D. I find the document very useful, and well written. We= all agree that mobility management must be activated on purpose, it likel= y requires an enhanced source address selection framework where application= s can obtain IP address with specific properties. By allowing applications = to request prefix properties, this I-D is clearly a part of this framework.= Maybe the document could be better by stressing clearly that it should be = used together with solutions allowing the network to expose prefix properti= es to the host, for example with draft-korhonen-dmm-prefix-properties and d= raft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... L= ike I said, it is a framework :-) > > > BR, > Pierrick > >> -----Message d'origine----- >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Moses, Danny >> Envoy=C3=A9 : jeudi 31 mars 2016 18:44 >> =C3=80 : sarikaya@ieee.org >> Cc : dmm@ietf.org >> Objet : Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >> >> Hi, >> Good, see my reply inline (surrounded by >>>>>>>>>>>>) . >> >> Thanks again for investing the time to review the drafts, >> /Danny >> >> -----Original Message----- >> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Sent: Wednesday, March 30, 2016 12:12 >> To: Moses, Danny >> Cc: dmm@ietf.org >> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >> >> Hi Danny, >> >> I am removing all previous conversation because it all got mixed up. >> Let's start afresh. >> >> >> I read you dhcp draft also. >> >> There is confusion in several levels. Your API draft talks about differe= nt >> applications on a MN needing different types of mobility services. Your = DHCPv6 >> draft seems to give a solution on how a host can get different types of >> addresses/prefixes from DHCPv6 server, so is it for a host or an applica= tion? >> Prefix or address is assigned for an interface, that is another well kno= wn concept >> which your draft seem to completely ignore, i.e. a host may have multipl= e >> interfaces. >> DM>>>>>>>>>>>>>>>>>>>>>> >> Yes, I understand were the confusion might arise. The only entity in the= host (or - >> mobile device) which uses DHCP is the DHCP client that is part of the TC= P/IP >> stack. There may be several triggers to cause the DHCP client to request= a source >> IP address: >> - When the mobile node initially attaches to a network. >> - When the mobile node moves to a different location and needs to refre= sh its >> source IP address. >> The On-Demand concept implies a new trigger: >> - When an application is launched, opens an IP Socket and requires a sp= ecial type >> of source IP address which was not already assigned to the mobile node. >> So, it is the responsibility of the TCP/IP stack in the mobile node to f= igure out >> when it is required to initiate a DHCP transaction to serve the applicat= ion's needs. >> >> Regarding multiple interface, you are correct once more. A mobile node m= ay have >> multiple interfaces. When this occurs, the mobile node needs to send at = least one >> DHCP request on each interface and the network assigns the source IP add= ress to >> the interface from which the DHCP request had arrived. This is not new a= nd the >> DHCP draft does not mention it because there are no changes or extension= s >> required. >> >>>>>>>>>>>>>>>>>>>>>>>>>DM >> >> Another concept is (as I already mentioned) topological correctness. >> If MN changes subnet, its previous prefix becomes topologically incorrec= t. Either it >> has to get a new prefix or there must be some system support, e.g. host = routes. >> Of course another case is anchoring, like in 3GPP or in MIP. If you are = anchored >> your prefix does not change. >> >> So you seem to ignore all these and instead introduce three types of add= resses >> among which the sustained IP address/prefix is the key to your solution. >> >> Sustained address/prefix has this magical property: >> the IP address used at the beginning of the session remains usable desp= ite the >> movement of the mobile host. >> >> and then you say >> >> access network anchoring, corresponding network anchoring, or some >> other solution >> can provide sustained address/prefixes. >> what does corresponding network anchoring mean? >> >> DM>>>>>>>>>>>>>>>>>> >> Corresponding network is a concept from Alper Yegin's draft - >> https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It define= s the >> concept of having the mobility anchor in the network of the mobile node'= s >> corresponding node, rather than in the access network. It is an interest= ing concept >> with its advantages (and disadvantages...). >> >>>>>>>>>>>>>>>>>>>DM >> >> I have a feeling that what your drafts are saying that right now we don'= t know but >> we anticipate in the future some ways will be found to make sustained IP >> addresses. >> Is this true? >> DM>>>>>>>>>>>>>>>>>>>> >> Well, we do know how the network can support sustained addresses. But I = believe >> that in our DMM work, new alternatives for supporting Fixed and Sustaine= d IP >> addresses will be defined. >> >>>>>>>>>>>>>>>>>>>>>DM >> >> BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained >> address/prefix but it does not say how it will be different than the fix= ed one? >> DM>>>>>>>>>>>>>>>>>>>>>>> >> That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in or= der to >> support the requests and replies. DHCP does not define how IP addresses = are >> allocated. >> >>>>>>>>>>>>>>>>>>>>>>>>DM >> >> Suppose we want to develop an access network anchoring for sustained IP >> addresses. >> What about the needs for signaling? I have a feeling that a host running= very many >> applications, like in today's smart phones, and so many smart phones in = the >> system that is going to involve huge amount of signaling to get/release = sustained >> address/prefixes, right? >> DM>>>>>>>>>>>>>>>>>>>>> >> Yes, a mobile host may activate several applications concurrently, but t= his does >> not mean that each application requires its own unique source IP address= . Let's >> assume that a large amount of application are launched, some require Fix= ed IP >> addresses, some require Sustained IP addresses and the rest settle for N= omadic >> IP addresses. In that case, only three source IP addresses are required = by the >> mobile node: One Fixed IP address, one Sustained and one Nomadic IP addr= ess. >> So the signaling overhead is not that huge. >> >>>>>>>>>>>>>>>>>>>>>>DM >> >> >> My conclusion from all of the above is that, I think what you propose so= unds like a >> flashy idea but it seems to me that the complications involved in any so= lution is >> intractable. >> Unless you can show me otherwise. >> DM>>>>>>>>>>>>>>>>>>>>> >> I hope I managed to convince you that it is not that complicated. I real= ly think (and >> there are other members who share this belief) that the tunneling overhe= ad and un- >> optimized routes are much more costly than what we are suggesting in thi= s new >> concept. >> >>>>>>>>>>>>>>>>>>>>>>>DM >> >> Regards, >> >> Behcet >> --------------------------------------------------------------------- >> A member of the Intel Corporation group of companies >> >> This e-mail and any attachments may contain confidential material for th= e sole use >> of the intended recipient(s). Any review or distribution by others is st= rictly >> prohibited. If you are not the intended recipient, please contact the se= nder and >> delete all copies. >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Thu Apr 7 02:03:00 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEB312D604 for ; Thu, 7 Apr 2016 02:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXSEu0CYDIAg for ; Thu, 7 Apr 2016 02:02:56 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E318012D5E5 for ; Thu, 7 Apr 2016 02:02:55 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 689AC4048C; Thu, 7 Apr 2016 11:02:54 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 3F1221A0072; Thu, 7 Apr 2016 11:02:54 +0200 (CEST) Received: from OPEXCNORM2E.corporate.adroot.infra.ftgroup ([fe80::c505:acb8:89e0:c6d6]) by OPEXCNORM74.corporate.adroot.infra.ftgroup ([fe80::fc94:9a93:d000:681d%21]) with mapi id 14.03.0279.002; Thu, 7 Apr 2016 11:02:54 +0200 From: To: "Moses, Danny" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGMnprVpgPBYC0SClZi/Ek/Av59rOExogAFHQwCAAyINgIADGUuAgAA64gCAAWjSAIAJKZYQgABUK4CAASNWgA== Date: Thu, 7 Apr 2016 09:02:53 +0000 Message-ID: <7496_1460019774_5706223E_7496_1043_1_81C77F07008CA24F9783A98CFD706F7116183A05@OPEXCNORM2E.corporate.adroot.infra.ftgroup> References: <565DE1DD.2070007@gmail.com> <7697_1459946554_5705043A_7697_9734_1_81C77F07008CA24F9783A98CFD706F71161825F7@OPEXCNORM2E.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 09:02:59 -0000 > -----Message d'origine----- > De=A0: Moses, Danny [mailto:danny.moses@intel.com] > Envoy=E9=A0: mercredi 6 avril 2016 19:40 > =C0=A0: SEITE Pierrick IMT/OLN > Cc=A0: dmm@ietf.org; sarikaya@ieee.org > Objet=A0: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >=20 > H Pierrick, >=20 > Thanks for the support. > Yes, we will look for a place to add the clarification that these API ext= ension rely > on other protocol enhancements to communicate the address type request to= the > network. We cannot currently provide reference to the specific documents = you > gave in your examples because they are not RFCs (yet...). >=20 Correct.. thanks. > Danny >=20 > -----Original Message----- > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > Sent: Wednesday, April 06, 2016 05:43 > To: Moses, Danny; sarikaya@ieee.org > Cc: dmm@ietf.org > Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >=20 > Hi Dany, >=20 > I support this I-D. I find the document very useful, and well written. We= all agree > that mobility management must be activated on purpose, it likely require= s an > enhanced source address selection framework where applications can obtain= IP > address with specific properties. By allowing applications to request pre= fix > properties, this I-D is clearly a part of this framework. Maybe the docum= ent could > be better by stressing clearly that it should be used together with solut= ions > allowing the network to expose prefix properties to the host, for example= with > draft-korhonen-dmm-prefix-properties and draft-moses-dmm-dhcp-ondemand- > mobility, which are somehow complementary... Like I said, it is a framew= ork :-) >=20 >=20 > BR, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Moses, Danny > > Envoy=E9=A0: jeudi 31 mars 2016 18:44 =C0=A0: sarikaya@ieee.org Cc=A0: > > dmm@ietf.org Objet=A0: Re: [DMM] WGLC #1 for > > draft-ietf-dmm-ondemand-mobility-01 > > > > Hi, > > Good, see my reply inline (surrounded by >>>>>>>>>>>>) . > > > > Thanks again for investing the time to review the drafts, > > /Danny > > > > -----Original Message----- > > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > > Sent: Wednesday, March 30, 2016 12:12 > > To: Moses, Danny > > Cc: dmm@ietf.org > > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > > > Hi Danny, > > > > I am removing all previous conversation because it all got mixed up. > > Let's start afresh. > > > > > > I read you dhcp draft also. > > > > There is confusion in several levels. Your API draft talks about > > different applications on a MN needing different types of mobility > > services. Your DHCPv6 draft seems to give a solution on how a host can > > get different types of addresses/prefixes from DHCPv6 server, so is it = for a > host or an application? > > Prefix or address is assigned for an interface, that is another well > > known concept which your draft seem to completely ignore, i.e. a host > > may have multiple interfaces. > > DM>>>>>>>>>>>>>>>>>>>>>> > > Yes, I understand were the confusion might arise. The only entity in > > the host (or - mobile device) which uses DHCP is the DHCP client that > > is part of the TCP/IP stack. There may be several triggers to cause > > the DHCP client to request a source IP address: > > - When the mobile node initially attaches to a network. > > - When the mobile node moves to a different location and needs to > > refresh its source IP address. > > The On-Demand concept implies a new trigger: > > - When an application is launched, opens an IP Socket and requires a > > special type of source IP address which was not already assigned to the= mobile > node. > > So, it is the responsibility of the TCP/IP stack in the mobile node to > > figure out when it is required to initiate a DHCP transaction to serve = the > application's needs. > > > > Regarding multiple interface, you are correct once more. A mobile node > > may have multiple interfaces. When this occurs, the mobile node needs > > to send at least one DHCP request on each interface and the network > > assigns the source IP address to the interface from which the DHCP > > request had arrived. This is not new and the DHCP draft does not > > mention it because there are no changes or extensions required. > > >>>>>>>>>>>>>>>>>>>>>>>>>DM > > > > Another concept is (as I already mentioned) topological correctness. > > If MN changes subnet, its previous prefix becomes topologically > > incorrect. Either it has to get a new prefix or there must be some syst= em > support, e.g. host routes. > > Of course another case is anchoring, like in 3GPP or in MIP. If you > > are anchored your prefix does not change. > > > > So you seem to ignore all these and instead introduce three types of > > addresses among which the sustained IP address/prefix is the key to your > solution. > > > > Sustained address/prefix has this magical property: > > the IP address used at the beginning of the session remains usable > > despite the movement of the mobile host. > > > > and then you say > > > > access network anchoring, corresponding network anchoring, or some > > other solution > > can provide sustained address/prefixes. > > what does corresponding network anchoring mean? > > > > DM>>>>>>>>>>>>>>>>>> > > Corresponding network is a concept from Alper Yegin's draft - > > https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It > > defines the concept of having the mobility anchor in the network of > > the mobile node's corresponding node, rather than in the access > > network. It is an interesting concept with its advantages (and disadvan= tages...). > > >>>>>>>>>>>>>>>>>>>DM > > > > I have a feeling that what your drafts are saying that right now we > > don't know but we anticipate in the future some ways will be found to > > make sustained IP addresses. > > Is this true? > > DM>>>>>>>>>>>>>>>>>>>> > > Well, we do know how the network can support sustained addresses. But > > I believe that in our DMM work, new alternatives for supporting Fixed > > and Sustained IP addresses will be defined. > > >>>>>>>>>>>>>>>>>>>>>DM > > > > BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained > > address/prefix but it does not say how it will be different than the fi= xed one? > > DM>>>>>>>>>>>>>>>>>>>>>>> > > That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in > > order to support the requests and replies. DHCP does not define how IP > > addresses are allocated. > > >>>>>>>>>>>>>>>>>>>>>>>>DM > > > > Suppose we want to develop an access network anchoring for sustained > > IP addresses. > > What about the needs for signaling? I have a feeling that a host > > running very many applications, like in today's smart phones, and so > > many smart phones in the system that is going to involve huge amount > > of signaling to get/release sustained address/prefixes, right? > > DM>>>>>>>>>>>>>>>>>>>>> > > Yes, a mobile host may activate several applications concurrently, but > > this does not mean that each application requires its own unique > > source IP address. Let's assume that a large amount of application are > > launched, some require Fixed IP addresses, some require Sustained IP > > addresses and the rest settle for Nomadic IP addresses. In that case, > > only three source IP addresses are required by the mobile node: One Fix= ed IP > address, one Sustained and one Nomadic IP address. > > So the signaling overhead is not that huge. > > >>>>>>>>>>>>>>>>>>>>>>DM > > > > > > My conclusion from all of the above is that, I think what you propose > > sounds like a flashy idea but it seems to me that the complications > > involved in any solution is intractable. > > Unless you can show me otherwise. > > DM>>>>>>>>>>>>>>>>>>>>> > > I hope I managed to convince you that it is not that complicated. I > > really think (and there are other members who share this belief) that > > the tunneling overhead and un- optimized routes are much more costly > > than what we are suggesting in this new concept. > > >>>>>>>>>>>>>>>>>>>>>>>DM > > > > Regards, > > > > Behcet > > --------------------------------------------------------------------- > > A member of the Intel Corporation group of companies > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute respo= nsabilite si > ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used or > copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >=20 > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies >=20 > This e-mail and any attachments may contain confidential material for the= sole use > of the intended recipient(s). Any review or distribution by others is str= ictly > prohibited. If you are not the intended recipient, please contact the sen= der and > delete all copies. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 13 16:37:24 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5BE12DA3B; Wed, 13 Apr 2016 16:37:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413233721.17328.15248.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 16:37:21 -0700 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-lma-controlled-mag-params-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 23:37:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : LMA Controlled MAG Session Parameters Authors : Dhananjay Patki Sri Gundavelli Jong-Hyouk Lee Qiao Fu Lyle T Bertz Filename : draft-ietf-dmm-lma-controlled-mag-params-01.txt Pages : 12 Date : 2016-04-13 Abstract: This specification defines a new extension, LMA-Controlled-MAG- Session-Params to Proxy Mobile IPv6. This option can be used by the LMA in PMIPv6 signaling for notifying the MAG to conform to various parameters contained in this extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-lma-controlled-mag-params/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-lma-controlled-mag-params-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-lma-controlled-mag-params-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 19 00:51:59 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAB512ECF1 for ; Tue, 19 Apr 2016 00:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqcYI3ekGRxi for ; Tue, 19 Apr 2016 00:51:50 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EC912ECE3 for ; Tue, 19 Apr 2016 00:51:43 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id p64so1283595lfg.0 for ; Tue, 19 Apr 2016 00:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=BA09CKUWsSOfGPqvhFORRqFEhNEDup2jb/gMWbsVGAU=; b=j2IGGfBhKE4PUGrIroNv/0KHal9gcqF/Qp6QsVGeQ7hQ8ickVx6kw0pz2+QeA+3GA+ ShnRRE+/VAm16XO45yB7Wnkvi29dSoBHs90DnlVbJ2l4fNwnmb6c0SBL6FUcYbHRAS6V 4JM74T4kQIzn8tK5U+LZX7rZ0+u8lj6E4FMgI19RFOdjuh78PPmTShuSYsUoJD/be7fC 4hfiiPu0CE0mpM4D53IxMcAoizQvnRTtto3v59WukVrvM7ZJhJtScjOV/CxQ4pAYdWog cpc2TT7sGpDgAvB1JnIujKm8cO34Y486x2s+n15GZbq9a6JmAynoqzWacwqgb3qapuKF MGMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=BA09CKUWsSOfGPqvhFORRqFEhNEDup2jb/gMWbsVGAU=; b=ArAhYVSRAFt6X7ZGspIFx28U/1R6NnicHWHRD7tzbA//+K6bLZtRQeB7rInzBF9teE qsL8N5fzbH/MH2Tcup+EiCY2BrvQGgxEs3ct5CGmxVv+ZMLwGR0dLVgI6W5yp8thp+aC nx6T9AM4Pw6MArs6SWjs7CZnaIN9shdlQ4LOwVPXGAC4k8plYHTUsLcEPMz8IYO+Ql4N dW2xKgZBlN50yISz0Wg6AJlEi623PK3G1O8VpTyFZzsBAYM+unBm7El4bluNnt1tN4Zn 8YPk9bczOL34EPWis+FH2TbjdPhwUL/vvJcnzRD+akTTao9IX2aPnvUoVfS2g0L4GcaN F8PQ== X-Gm-Message-State: AOPr4FXii/7UMmn9OkvajHJrBirnNR3tqcpYKZGNZFDCDW0m+7LoT6UbCH1dGTBe/khiu1Wu0XLAWQmiMfyALQ== MIME-Version: 1.0 X-Received: by 10.112.144.202 with SMTP id so10mr746347lbb.108.1461052301364; Tue, 19 Apr 2016 00:51:41 -0700 (PDT) Received: by 10.112.252.135 with HTTP; Tue, 19 Apr 2016 00:51:41 -0700 (PDT) In-Reply-To: <565DE1DD.2070007@gmail.com> References: <565DE1DD.2070007@gmail.com> Date: Tue, 19 Apr 2016 02:51:41 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:51:55 -0000 Hello Folks, At IETF 95 session, there was some discussion on the mention of on demand mobility in 3GPP 5G documents, e.g. 23.799. It seems like 3GPP meaning of on demand mobility is that the UE asks or demands mobility support or not. So that has nothing to do with the sustained IP addresses. Regards, Behcet On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen wrote: > Folks, > > This mail starts two week WGLC for the I-D: > https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 > > The WGLC ends 12/15/2015. > > Provide your reviews and comments to the mailing list. For the better > tracking of issues and proposed changed use the Issue Tracker to submit your > issues/proposals. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Apr 20 03:35:46 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F9312EE6C for ; Wed, 20 Apr 2016 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0hb6aI6bMZq for ; Wed, 20 Apr 2016 03:35:41 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AF512EE67 for ; Wed, 20 Apr 2016 03:35:41 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id n1so17177102pfn.2 for ; Wed, 20 Apr 2016 03:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=WemTKFbEHoCIdvS7HHTkjyATajjjSvczKMkmH24ESdM=; b=Z9GyOu+g1CaT2wmCcagyvn7U7PD11i6a3AYcLGWBYCohOYlozSHTww3SoCkIL/sOOm bHSBBEQ226fPJ+y16J79HhLGEm29BiIk9EEbzFhdsOn81yeffeQHp7ENBZ5y4b9RERqB PJEv1opEeTZbIsa0EUYgEOBQd0Rzf0Og1P/MZZVFGkbJHG+OU3G8WkBsGrZUyDSUD8Z2 MHCsCqMEIihPla0J8vO8bi6ScFE1GBKfyMLtDEgys1thWt6P70o+17yQiel2YjaH4u4u hlSMTDcJwhez0LQUVkj1hX9bOiwsxnYvoZqaYTS+cL4EA0EHAeqzrXbJ5sJRawMHWGyC hh+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=WemTKFbEHoCIdvS7HHTkjyATajjjSvczKMkmH24ESdM=; b=E/nLfrLEwoPtDPB9Hlpqh/6Vi5FW4fO7RhCLwPop7NDIGmdZkiyMHi/UtFflZQHo+0 ub6LwEEJ3MQu3Wi+Vl9cP9sELys5v2qgIogmbR3vtTVw6PziZsX+w5BX9KQo/hNTRLS4 eqdPw4GUPlLvS9dLwBa7si/QZbYPULiFYiGBSqOOhu6jGNBNNsmOTFICpm19V1fhYex/ VWguslqgAd2fQh4WgmuQKYuRIVQPR6Rqd+Yw/Uy1FTcGuQ6mqHEabwaR7OSOT4R+V5VX sxNOI/e/ABI6ALr7Gi4LB1EUu5RxbKQQAq1eDBRLIHWP2nMJd4LS9fcDfU3sASwW2F0Y G/nw== X-Gm-Message-State: AOPr4FXcskEeEejp/Rx+dzcZcUg5Z0XX42YKGZxmehhpKiHWEj9mrEhSgI+GDFLyeLx0ew== X-Received: by 10.98.86.77 with SMTP id k74mr10993964pfb.28.1461148541291; Wed, 20 Apr 2016 03:35:41 -0700 (PDT) Received: from SeilPC ([115.145.171.202]) by smtp.gmail.com with ESMTPSA id k65sm97345043pfb.30.2016.04.20.03.35.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2016 03:35:40 -0700 (PDT) From: "Seil Jeon" To: References: <565DE1DD.2070007@gmail.com> In-Reply-To: Date: Wed, 20 Apr 2016 19:35:30 +0900 Message-ID: <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 thread-index: AQICB8bfdrnDgk3PhANVwWUWOfTk8AKWIGJGnx0bejA= Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 10:35:44 -0000 Hi Behcet, As I was not there, what discussions was given. However, let me speak a few words. The specs. you referenced seems talking about need of different levels of mobility support, e.g. high/medium/low mobility and so on. Within the frame, I think having a proper level of mobility support based on IP session continuity and IP address reachability for an application, with the defined source IP address type request will make sense in the scope of mobility support in the specs. Besides, as you know, the spec. currently remains at 0.2 version, describing work items briefly and concisely. It doesn't constraint potentials for on-demand mobility. And we don't know how/where the direction will be going. Regards, Seil Jeon -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Tuesday, April 19, 2016 4:52 PM To: Jouni Korhonen Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hello Folks, At IETF 95 session, there was some discussion on the mention of on demand mobility in 3GPP 5G documents, e.g. 23.799. It seems like 3GPP meaning of on demand mobility is that the UE asks or demands mobility support or not. So that has nothing to do with the sustained IP addresses. Regards, Behcet On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen wrote: > Folks, > > This mail starts two week WGLC for the I-D: > > https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 > > The WGLC ends 12/15/2015. > > Provide your reviews and comments to the mailing list. For the better > tracking of issues and proposed changed use the Issue Tracker to > submit your issues/proposals. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Apr 21 00:23:55 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3612D8A0 for ; Thu, 21 Apr 2016 00:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRhxbLod6E1W for ; Thu, 21 Apr 2016 00:23:51 -0700 (PDT) Received: from mail-lb0-x244.google.com (mail-lb0-x244.google.com [IPv6:2a00:1450:4010:c04::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6A312DA75 for ; Thu, 21 Apr 2016 00:23:51 -0700 (PDT) Received: by mail-lb0-x244.google.com with SMTP id w1so2452700lbl.1 for ; Thu, 21 Apr 2016 00:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=x/zq6n8f9/9h1lQN0lZSkQt9RSnyMzhalnR8IwH/qWU=; b=J41J4pqLk82I1SMwPo1BDrOpSFm7s4qjHh8M0BzbmOlOlU8eSz4u8iINsH38/IeKS9 Si7TwryUN0PksfHDU0W1klR6SmOE0uufuejQvnjLoY5V8YyQevNwXqmvbmxRUzehtncm fwbpxGbgn+WigTZzjVeADlZQK9HbVE22VaR7D20uDCFRT1JgUikK6wK630/+lmeIklIE tT5E8qSVC06vew37eKvKjNKShyN154Q87/4xMlgrXiQ2+TsvLkFadSeZDszGab6251t+ 2R9BSKWBsWNSaMbVUr7Vmj40teUl5IYmCceg+jnGrs/w6nP2vvI/3AMMyCu7n5rRQbKv HQTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=x/zq6n8f9/9h1lQN0lZSkQt9RSnyMzhalnR8IwH/qWU=; b=V9PuwzK3Z34eEq5cKcq3uxeYpwkXQv/E+w+sX2GNZYXTy90NDmsVS53Gn6HS6pWQ60 7GwtV8xomX/ryoc+W0N3YMpSTYAkB6AJqxgE9MS145z7acttDd73fB3ffqHWj40q07un HJLcwrAaivkZ2pkObaa90b0kT6+v1Hbp1hGKg/Jv71p4Bt/Ega5xl2p6wa5/2hIs2F2+ j2cTJdka0MCAopUnXQjUjDP1lupGZqJbkjuKLa5ZTp+Uuxh00P1bZEXHKVgjmMvwtuuK oN0O5I6teKqMq88VuWwoR9r4Y4Kmqtu9Czoxo67hAT3tTg3Yo9BPsK6/kksIB+Ro5MgC KRWw== X-Gm-Message-State: AOPr4FX2TAcOZplU/YgpAB5+c+CnUr3jx/hlsk1E1VdXnslvgW6WArZ8BY7BTF4n09dIejz7Bm6RTjssIJfrog== MIME-Version: 1.0 X-Received: by 10.112.144.202 with SMTP id so10mr5777646lbb.108.1461223429602; Thu, 21 Apr 2016 00:23:49 -0700 (PDT) Received: by 10.112.252.135 with HTTP; Thu, 21 Apr 2016 00:23:49 -0700 (PDT) In-Reply-To: <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> References: <565DE1DD.2070007@gmail.com> <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> Date: Thu, 21 Apr 2016 02:23:49 -0500 Message-ID: From: Behcet Sarikaya To: Seil Jeon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:23:53 -0000 On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon wrote: > Hi Behcet, > > As I was not there, what discussions was given. > However, let me speak a few words. > > The specs. you referenced seems talking about need of different levels of > mobility support, e.g. high/medium/low mobility and so on. > Within the frame, I think having a proper level of mobility support based on > IP session continuity and IP address reachability for an application, with > the defined source IP address type request will make sense in the scope of > mobility support in the specs. > Did I say below that it does or does not say these things? What I said is the current thinking is to tie it to the UE asking for mobility support or not. If you have time, I would recommend spending it on coming up with a solution for the so-called sustained IP address. Behcet > Besides, as you know, the spec. currently remains at 0.2 version, describing > work items briefly and concisely. It doesn't constraint potentials for > on-demand mobility. And we don't know how/where the direction will be going. > > Regards, > Seil Jeon > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, April 19, 2016 4:52 PM > To: Jouni Korhonen > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > Hello Folks, > > At IETF 95 session, there was some discussion on the mention of on demand > mobility in 3GPP 5G documents, e.g. 23.799. > > It seems like 3GPP meaning of on demand mobility is that the UE asks or > demands mobility support or not. > > So that has nothing to do with the sustained IP addresses. > > Regards, > > Behcet > > On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen > wrote: >> Folks, >> >> This mail starts two week WGLC for the I-D: >> >> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 >> >> The WGLC ends 12/15/2015. >> >> Provide your reviews and comments to the mailing list. For the better >> tracking of issues and proposed changed use the Issue Tracker to >> submit your issues/proposals. >> >> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Apr 21 01:43:08 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3094C12D1E8 for ; Thu, 21 Apr 2016 01:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1avPl-bcsb2Y for ; Thu, 21 Apr 2016 01:43:05 -0700 (PDT) Received: from mail-lb0-x243.google.com (mail-lb0-x243.google.com [IPv6:2a00:1450:4010:c04::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B938412DD94 for ; Thu, 21 Apr 2016 01:43:04 -0700 (PDT) Received: by mail-lb0-x243.google.com with SMTP id q4so2761721lbq.3 for ; Thu, 21 Apr 2016 01:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=ibZmeXxoNlQPIfLyN4T4biR8fpuyjJ41FmniOHh07I8=; b=xer/3TFlQIz+sedkqez7fagzVMfZgGCpDanpTE9SPFSD+cReSt5J9AVgJT2oa2qYOo 36LXOc9a4wM3YPeKezpiphB1Oxg50K3cAAXxGp7IbsTqnmgSoE3haKc+74Wp0qf3k5nX Bwy0bi6Jiwev+m8qWSAb+8roOT/Nnww9NoDMhFd5O2GGJ1uyHOuPqR7LauJ6qKpgizaH Eil6kXtkOWRdeWHGUccw5XjF1nkJXhraNXV1xdyrmAmPtjjK6gi3qL0v+8M52l+QzKVr n7XzCy0XOyrmPrSaWHOiKjQ1imAiDDHi5VoJSXIvLOlflfQx8SdkOC9T+tsXKwMtSlj/ DTCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=ibZmeXxoNlQPIfLyN4T4biR8fpuyjJ41FmniOHh07I8=; b=GCDkJoWHSem4Ot6br96sNYR2o1AJHb3AOhe3WK6DrfFaiz8G4+BVY1+VHtiAKXpihp oNhyZy6gJ0vxjHjHGuV1ZZWvXUJJf+8gpNh1f2TmqicLBsrhLNjuE2OXxyZSKivax0Eu iSQWKj0M4GvCUQWzSHsvVn/66cKoXL+ldpNY3qAgJwwLbU525zBJbLYWfnmdxFSrVB7Z 0SEJdmdCeoC8p9zERfqPMafQgMH7Tq3Bul4oM/GGkHhD8nec/cFBIf538dPwc7gbAScy HZPMevstkn52UuSLOZ3LxNtfudsMT0E6oCHm3xulesHjqAO56+CLc5bMIqueh7mXWcc9 2f+g== X-Gm-Message-State: AOPr4FVijBAvuViJsUvJ64m7uhyeoEF1BO/pq3gBaJ6CpKxd1elxWxoH3nL38Zx5xeni9oTZbgCv1KM3ZxvUhg== MIME-Version: 1.0 X-Received: by 10.112.143.163 with SMTP id sf3mr5588245lbb.117.1461228182931; Thu, 21 Apr 2016 01:43:02 -0700 (PDT) Received: by 10.112.252.135 with HTTP; Thu, 21 Apr 2016 01:43:02 -0700 (PDT) In-Reply-To: <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> References: <565DE1DD.2070007@gmail.com> <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> Date: Thu, 21 Apr 2016 03:43:02 -0500 Message-ID: From: Behcet Sarikaya To: Seil Jeon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:43:07 -0000 On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon wrote: > Hi Behcet, > > As I was not there, what discussions was given. > However, let me speak a few words. > > The specs. you referenced seems talking about need of different levels of > mobility support, e.g. high/medium/low mobility and so on. I am looking at Rev 0.3, they no longer have those. I am hearing that Rev 0.4 is being worked out and maybe posted sometime next week. I hope this clarifies. Behcet > Within the frame, I think having a proper level of mobility support based on > IP session continuity and IP address reachability for an application, with > the defined source IP address type request will make sense in the scope of > mobility support in the specs. > > Besides, as you know, the spec. currently remains at 0.2 version, describing > work items briefly and concisely. It doesn't constraint potentials for > on-demand mobility. And we don't know how/where the direction will be going. > > Regards, > Seil Jeon > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, April 19, 2016 4:52 PM > To: Jouni Korhonen > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > Hello Folks, > > At IETF 95 session, there was some discussion on the mention of on demand > mobility in 3GPP 5G documents, e.g. 23.799. > > It seems like 3GPP meaning of on demand mobility is that the UE asks or > demands mobility support or not. > > So that has nothing to do with the sustained IP addresses. > > Regards, > > Behcet > > On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen > wrote: >> Folks, >> >> This mail starts two week WGLC for the I-D: >> >> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 >> >> The WGLC ends 12/15/2015. >> >> Provide your reviews and comments to the mailing list. For the better >> tracking of issues and proposed changed use the Issue Tracker to >> submit your issues/proposals. >> >> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Apr 21 02:06:52 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9912DE5B for ; Thu, 21 Apr 2016 02:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOCriN4bAyad for ; Thu, 21 Apr 2016 02:06:48 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 49AEC12DE0D for ; Thu, 21 Apr 2016 02:06:48 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 21 Apr 2016 02:06:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,512,1455004800"; d="scan'208";a="963372087" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 21 Apr 2016 02:06:47 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 21 Apr 2016 02:06:46 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 21 Apr 2016 02:06:46 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.105]) by HASMSX110.ger.corp.intel.com ([169.254.11.243]) with mapi id 14.03.0248.002; Thu, 21 Apr 2016 12:06:43 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ+RlY2AgAHAGgCAAXLoAIAAN2AA Date: Thu, 21 Apr 2016 09:06:43 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODBlOTU5YTEtODRiYS00ZWE5LTk5ODUtMTEwMzUxNTY2Y2U2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjBCVUtkUkdSVms1cFM2SjZPakZpSEZcL3ltY0lMU2JFVDV3UUJ4VG5qRlFFPSJ9 x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 09:06:50 -0000 Hi guys, Alper and I are in the process of compiling all the new comments we receive= d in the last DMM face to face. We plan to issue a new version of the draft= that, hopefully, clarifies the definitions and will provide a written resp= onse on the mailing list with further explanation and responses to all the = comments. Please be patient for a couple of days. Thanks, Alper and Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, April 21, 2016 11:43 To: Seil Jeon Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon wrote: > Hi Behcet, > > As I was not there, what discussions was given. > However, let me speak a few words. > > The specs. you referenced seems talking about need of different levels = > of mobility support, e.g. high/medium/low mobility and so on. I am looking at Rev 0.3, they no longer have those. I am hearing that Rev 0.4 is being worked out and maybe posted sometime nex= t week. I hope this clarifies. Behcet > Within the frame, I think having a proper level of mobility support = > based on IP session continuity and IP address reachability for an = > application, with the defined source IP address type request will make = > sense in the scope of mobility support in the specs. > > Besides, as you know, the spec. currently remains at 0.2 version, = > describing work items briefly and concisely. It doesn't constraint = > potentials for on-demand mobility. And we don't know how/where the direct= ion will be going. > > Regards, > Seil Jeon > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, April 19, 2016 4:52 PM > To: Jouni Korhonen > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > Hello Folks, > > At IETF 95 session, there was some discussion on the mention of on = > demand mobility in 3GPP 5G documents, e.g. 23.799. > > It seems like 3GPP meaning of on demand mobility is that the UE asks = > or demands mobility support or not. > > So that has nothing to do with the sustained IP addresses. > > Regards, > > Behcet > > On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen = > > wrote: >> Folks, >> >> This mail starts two week WGLC for the I-D: >> >> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 >> >> The WGLC ends 12/15/2015. >> >> Provide your reviews and comments to the mailing list. For the better = >> tracking of issues and proposed changed use the Issue Tracker to = >> submit your issues/proposals. >> >> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From nobody Thu Apr 21 03:02:43 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FB312EB2A for ; Thu, 21 Apr 2016 03:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NathRibvVDzs for ; Thu, 21 Apr 2016 03:02:40 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7679812D954 for ; Thu, 21 Apr 2016 03:02:40 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id y69so11718287pfb.1 for ; Thu, 21 Apr 2016 03:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=QY/am2S19Yjb0wtc+DpBKO+WQQ+KbHB2F2ng4xdJuRE=; b=M2Urq6wFfvCfJEv74Kdw20L87vBnRGGtlbGexSK9B70ezDEBKF6eq4S+2La+tZy17n pZpA+oOQSa/IAhXmVX/sA8nPCfGeYzwvSth04gMRIaWUoLeuTFr1nVQarAY/rWAJcVgH UjjUH/v0r/zxtH6DCcjnQTzHuIl6M8NBHdeXod7BkXyfTB6akgqz34dKJgClBn9r5Mgq /abfGpBm7MXX8Uk4+DsdYkI3beUSz2f2ghfM2JRsEWHNjss7SbYQPAUlCLEGpyrByOxg g9unjYdbrDTlBHlZz4unDJ7xJYJmyH+vD3694MQ7Dp1S1+cOamwArUD0CcGrNcmAmb4h ehlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=QY/am2S19Yjb0wtc+DpBKO+WQQ+KbHB2F2ng4xdJuRE=; b=iU1nYe5auqHvAOOjN/AO5KQtUWvlFXVp6MgJtK/HrVFx30mcGdwA1FJmSUcQf/XHu2 +YV9d6+WCaZvpvM2cp5EmMXuhnCcKMK970CgHFsIHUr+euIPw/IgZ3fgVkTG9Y4HQUdG RmycarGy60X/jWeD0K6yZXApxYR0f7bLuZHGFnBXNGhWV/FsWCeoWjzTJBHp7Ng2sLes UVTFAC1/Cp9yA0MmnO5UfjMRsT2z4pviB7NOR57g9Vmjo0GlJ0ginptTclBjTHxk72jD z+AxVdNGUTH2SnipN22atW4Ptj7tZ50crZnq73lZn+lqjFfyUlTL+nzcXesNkSLE04G9 Zpbg== X-Gm-Message-State: AOPr4FWAwqXHZh7NRg1Fcpz5+Plw+ParYpSdPTtutRDKaY9fny6kCsEHUA9cvm+vdWz2yw== X-Received: by 10.98.68.208 with SMTP id m77mr1234860pfi.25.1461232959589; Thu, 21 Apr 2016 03:02:39 -0700 (PDT) Received: from SeilPC ([115.145.171.202]) by smtp.gmail.com with ESMTPSA id 28sm3572562pfr.89.2016.04.21.03.02.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 03:02:39 -0700 (PDT) From: "Seil Jeon" To: References: <565DE1DD.2070007@gmail.com> <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> In-Reply-To: Date: Thu, 21 Apr 2016 19:02:29 +0900 Message-ID: <049001d19bb4$ec0145e0$c403d1a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQICB8bfdrnDgk3PhANVwWUWOfTk8AKWIGJGAbOJBzMCfgjcSZ79HKtw Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 10:02:42 -0000 Hi Behcet, I don't know where you could get rev 0.3. Currently in my access, rev = 0.2 is the latest one. http://www.3gpp.org/DynaReport/23799.htm And it is saying following "The types of mobility the system should support, e.g. high mobility, = medium mobility, low mobility, no mobility and mobility on demand;" Regards, Seil Jeon -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 Sent: Thursday, April 21, 2016 5:43 PM To: Seil Jeon Cc: dmm@ietf.org; Jouni Korhonen Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon wrote: > Hi Behcet, > > As I was not there, what discussions was given. > However, let me speak a few words. > > The specs. you referenced seems talking about need of different levels = > of mobility support, e.g. high/medium/low mobility and so on. I am looking at Rev 0.3, they no longer have those. I am hearing that Rev 0.4 is being worked out and maybe posted sometime = next week. I hope this clarifies. Behcet > Within the frame, I think having a proper level of mobility support=20 > based on IP session continuity and IP address reachability for an=20 > application, with the defined source IP address type request will make = > sense in the scope of mobility support in the specs. > > Besides, as you know, the spec. currently remains at 0.2 version,=20 > describing work items briefly and concisely. It doesn't constraint=20 > potentials for on-demand mobility. And we don't know how/where the = direction will be going. > > Regards, > Seil Jeon > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, April 19, 2016 4:52 PM > To: Jouni Korhonen > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > Hello Folks, > > At IETF 95 session, there was some discussion on the mention of on=20 > demand mobility in 3GPP 5G documents, e.g. 23.799. > > It seems like 3GPP meaning of on demand mobility is that the UE asks=20 > or demands mobility support or not. > > So that has nothing to do with the sustained IP addresses. > > Regards, > > Behcet > > On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen=20 > > wrote: >> Folks, >> >> This mail starts two week WGLC for the I-D: >> >> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 >> >> The WGLC ends 12/15/2015. >> >> Provide your reviews and comments to the mailing list. For the better = >> tracking of issues and proposed changed use the Issue Tracker to=20 >> submit your issues/proposals. >> >> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Apr 21 03:05:32 2016 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F028412EB47 for ; Thu, 21 Apr 2016 03:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ_vfpGBxEC4 for ; Thu, 21 Apr 2016 03:05:28 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC0A12EB44 for ; Thu, 21 Apr 2016 03:05:27 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id n1so28788709pfn.2 for ; Thu, 21 Apr 2016 03:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=cKiRH0/oTeCfsgVbOF2QdKO1pTHY733AIuBRgNQ50KE=; b=fy+p+1xJHr4MTJWQLXKpLZGse4ZLRVPe5meM+kdCPGG+ZfX98OZiyhYAUrba9SHA97 NN0pegr5VrXSCorcwq77w7dwR5K0ew8grJumzqevYCjSswi67Vr3PBz7DG+qb2MktA9R sx94DuN77Sf+l/crbayChxHMKtBVRKzY3kKDlIIdlIjTMHSKpiAywCBKDqzqpNgRvVAZ VZJ4UGzID76vEnBkGqX1ScGQarx89gDFpz64U+r22P0GgSpk0NXuwd71FSvfDoPYKVMe 7Vq9mA4XkPakcksWsk7j+09EuKdkywa62k8V1NseenygzvZ4EZFxweG5A6x3T8isEcxz 1USQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=cKiRH0/oTeCfsgVbOF2QdKO1pTHY733AIuBRgNQ50KE=; b=gVlKVmVPwsI5I7k1622hy1LKMqA5D4jL8YBCYaJQ3Q33R1zniGzIY22kV7ypfVZBzV O/fNdR3lR+qwpZ7urh7vs6VR621JBtHMRlJzMThU2/5q/aEjPCny0lykqZAygXolgARG OslkwDud52c1d7meQh0yTkUe5Ehdsva9LF9VCpUMRpJZ6HMCny+axU6jOwMr4r+sZwV4 9K3mAyWurRKMdqV6mBbcnvSRTSMjCPsWgQT9XG2KKwcCUFEzrtePw2K8FlBnbMLLo+QN vxr+ta9ExJotjCD27Xte/01fWL+WUEVQ4Jqjz1JR8GbAjgoNNcC9osEvloPbQki1C8pF qHEA== X-Gm-Message-State: AOPr4FU/zIbh74bxiHLoitO0CJEyRFDgg6g08+3r8ujf5Edtd4JXc+ynDML4aDYcuuGQUQ== X-Received: by 10.98.70.144 with SMTP id o16mr7531241pfi.26.1461233127118; Thu, 21 Apr 2016 03:05:27 -0700 (PDT) Received: from SeilPC ([115.145.171.202]) by smtp.gmail.com with ESMTPSA id a77sm3646837pfj.2.2016.04.21.03.05.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 03:05:26 -0700 (PDT) From: "Seil Jeon" To: References: <565DE1DD.2070007@gmail.com> <01e401d19af0$5e6fd170$1b4f7450$@gmail.com> In-Reply-To: Date: Thu, 21 Apr 2016 19:05:17 +0900 Message-ID: <049201d19bb5$4fe79d20$efb6d760$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQICB8bfdrnDgk3PhANVwWUWOfTk8AKWIGJGAbOJBzMAvnZzdJ8LFY4g Content-Language: ko Archived-At: Cc: dmm@ietf.org Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 10:05:30 -0000 Hi Behcet See inline, please. Regards, Seil Jeon -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 Sent: Thursday, April 21, 2016 4:24 PM To: Seil Jeon Cc: dmm@ietf.org; Jouni Korhonen Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon wrote: > Hi Behcet, > > As I was not there, what discussions was given. > However, let me speak a few words. > > The specs. you referenced seems talking about need of different levels = > of mobility support, e.g. high/medium/low mobility and so on. > Within the frame, I think having a proper level of mobility support=20 > based on IP session continuity and IP address reachability for an=20 > application, with the defined source IP address type request will make = > sense in the scope of mobility support in the specs. > Did I say below that it does or does not say these things? What I said is the current thinking is to tie it to the UE asking for = mobility support or not. SJ) Yes, it is based on a terminal-driven approach. We may consider a = network-driven approach, if submitted by a person being interested in. If you have time, I would recommend spending it on coming up with a = solution for the so-called sustained IP address. SJ) I spent my time for it. Behcet > Besides, as you know, the spec. currently remains at 0.2 version,=20 > describing work items briefly and concisely. It doesn't constraint=20 > potentials for on-demand mobility. And we don't know how/where the = direction will be going. > > Regards, > Seil Jeon > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, April 19, 2016 4:52 PM > To: Jouni Korhonen > Cc: dmm@ietf.org > Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > Hello Folks, > > At IETF 95 session, there was some discussion on the mention of on=20 > demand mobility in 3GPP 5G documents, e.g. 23.799. > > It seems like 3GPP meaning of on demand mobility is that the UE asks=20 > or demands mobility support or not. > > So that has nothing to do with the sustained IP addresses. > > Regards, > > Behcet > > On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen=20 > > wrote: >> Folks, >> >> This mail starts two week WGLC for the I-D: >> >> https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 >> >> The WGLC ends 12/15/2015. >> >> Provide your reviews and comments to the mailing list. For the better = >> tracking of issues and proposed changed use the Issue Tracker to=20 >> submit your issues/proposals. >> >> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >